Ubuntu 20.04 LTS와 22.04 LTS를 처음부터 설치할 때 발생하는 문제점에 관한 문서를 확인했습니다.
18.04 LTS에서 20.04 또는 22.04로 제자리 업그레이드(in-place upgrade)를 진행해 본 분이 계신가요?
당장 급한 상황은 아니지만, 지금부터 4월 사이에 더 새로운 릴리스로 전환해야 할 것 같아 알아보고 있습니다.
Ubuntu 20.04 LTS와 22.04 LTS를 처음부터 설치할 때 발생하는 문제점에 관한 문서를 확인했습니다.
18.04 LTS에서 20.04 또는 22.04로 제자리 업그레이드(in-place upgrade)를 진행해 본 분이 계신가요?
당장 급한 상황은 아니지만, 지금부터 4월 사이에 더 새로운 릴리스로 전환해야 할 것 같아 알아보고 있습니다.
어떤 문제인가요? 저는 스크립트를 변경하지 않았고 문제도 없는 것 같습니다. 오늘 늦게 22.04가 정상 작동하는지 다시 확인해 보겠습니다.
22.04는 정상적으로 작동합니다. 어제 테스트할 일이 있어서 확인해 보았습니다.
감사합니다!
정리하자면, 저는 CLI를 통해 Ubuntu를 더 높은 버전(20.04 LTS 또는 22.04 LTS)으로 업그레이드하는 것에 대해 고민 중이었습니다. 여기에는 SSL 버전 문제 및 기타 구성 요소(아마도 Ruby on Rails?)와 관련된 문서들이 몇 가지 있습니다.
결국, 문제가 없는 곳에 문제를 만들려는 의도는 아닙니다. 또한 운영체제 의존성이 있는 경우 제 Discourse 설치 환경에 문제가 생기기를 원하지도 않습니다.
유용한 정보를 공유해 주셔서 감사합니다.
아직 "일부 문서"가 정확히 무엇인지 말씀해 주시지 않으셨지만, 개발 환경 실행에 관한 내용을 말씀하시는 건가요?
Docker에서 표준 설치를 실행 중이시라면 문제가 없어야 합니다.
여기서 찾아 읽고 본 링크는 다음과 같습니다:
개발용 설치에 대한 참고 사항도 확인했습니다. 관련이 없다고 판단해 제외했습니다.
22.04.1 LTS를 클린 설치한 환경에서는 문제가 발생하지 않습니다:
이들은 클린 설치 대신 OS 업그레이드를 수행했습니다.
이는 개발용 설치입니다.
OS 업데이트 실행을 신뢰하지 않고 클린 설치를 하려는 제 생각이 제가 생각했던 것만큼 터무니없지 않은 것 같습니다.
클린 설치의 또 다른 장점은 DNS(또는 정적 IP)만 변경하면 작동하던 버전으로 쉽게 되돌릴 수 있다는 점입니다(대부분의 경우 DNS 업데이트를 기다리는 것보다 훨씬 빠르기 때문에 정적 IP를 권장합니다).
우리가 서로 다른 맥락에서 이야기하고 있는 건 아닌지 모르겠네요. ![]()
제 원래 질문은 18.04에서 20.04 또는 22.04로 CLI를 통해 직접 업그레이드하는 옵션이 있는지, 그리고 그렇게 할 경우 어떤 영향이 있는지를 알고 싶었던 것입니다.
클린 설치나 새로운 EC2 인스턴스를 생성하는 방식, 그리고 Discourse의 백업 및 복구를 시도하는 접근법은 이해하고 있습니다.
여기에는 리스크와 노력 사이의 트레이드오프가 있습니다.
제자리 업그레이드를 수행하면 OS 업데이트 후 Discourse 환경이 실행되지 않을 위험이 있습니다. 그러면 무엇이 문제인지 파악하는 데 시간을 보내야 하고, 복구하려면 이곳의 전문가들의 도움이 필요할 수도 있습니다.
새로운 환경을 구축하면 전환 시점까지 커뮤니티에 영향을 주지 않는 것이 보장됩니다. 하지만 이 방식은 훨씬 더 많은 노력이 필요하다고 느껴집니다.
이상적인 시나리오는 OS 업그레이드가 문제없이 작동하고, Discourse가 아무 문제 없이 재시작되는 것입니다.
아, 죄송합니다.
링크하신 게시물들 중 일부는 그런 문제가 발생할 가능성이 매우 높다고 조언하고 있습니다.
새 서버로 이전하는 방법에 대한 토픽이 있었는데 지금은 찾을 수 없습니다. 기본적으로 /var/discourse 디렉토리를 rsync로 복사하고, docker를 설치한 후 재빌드하면 됩니다. /var/discourse의 모든 내용을 복사하지 않고 일부만 복사하면 시간을 조금 절약할 수 있지만, 전체를 복사하더라도 OS 업그레이드가 실패하는 것을 기다리는 것보다 훨씬 적은 시간이 걸립니다. ![]()
저는 확실한 방법을 선호합니다. 이 지점에서 이 주제에 대해 업그레이드보다 거의 같은 시간을 보냈네요. ![]()
어떤 경로를 선택하시든 행운을 빕니다!
이것은 모두 위험 감수 성향과 감당할 수 있는 다운타임의 양에 달려 있습니다. 새로운 VPS를 생성하고 인스턴스를 읽기 전용으로 설정한 다음 Docker를 설치하는 것이 다운타임이 가장 짧은 방법입니다. OS 업그레이드는 다운타임이 보장되며, 문제를 해결하는 과정은 그 시간을 더 길게 만듭니다.
아니면 다른 방식으로 플레이할 수도 있겠네요!