v3.4.0에서 v2026.7.2로 업그레이드하기 전에 알아야 할 사항

지원 자체 호스팅
1

저는 오픈 소스 프로젝트의 일환으로 인수받은, Ubuntu에서 Docker 기반으로 실행되는 Discourse 설치 환경을 관리하고 있습니다. 수년 동안 git pull && ./launcher rebuild app 명령을 실행한 뒤 /admin/update의 관리자 UI를 통해 업그레이드를 진행해 왔습니다. 그러나 2024년 1월 docker_manager로 인해 발생한 파괴적 업그레이드(breaking upgrade) 과정에서 고통스러운 경험을 한 후로, 더 이상 이렇게 가볍게 업그레이드를 진행하지는 않고 있습니다. (해당 커밋에 대한 코멘트는 여기에서, 되돌려진 커밋은 여기에서 확인하실 수 있습니다.)

지금은 2년 반이 지났고, 다시 업그레이드 리듬을 찾아야 하지만, 이전의 실패한 업그레이드 경험 때문에 여전히 조금은 긴장된 상태입니다. 제가 이해하고 싶은 것은 v3.4.0에서 v2026.7.2로 업그레이드를 시도하기 전에 알아야 할 사항이 무엇인지입니다. 저희 사이트는 추가 플러그인을 사용하지 않으며, 제가 인지하고 있는 유일한 특수 설정은 메인 커뮤니티 사이트와 SSO를 위해 Discourse Connect URL을 사용하고 있다는 점입니다.

그냥 아래처럼 단순한가요?

cd /var/discourse
git pull
./launcher rebuild app

그리고 관리자 UI를 통해 업데이트를 하는 것 말입니다. v3.4.0에서 v2026.7.2로 넘어갈 때 주의해야 할 중간 단계가 있을까요?

감사합니다,

Cory

2

아니면 …(긴장되고 있다면) … 백업(어쨌든 필수)을 만들어 완전히 새로운 서버를 설정하고 백업을 복원한 후, 완료되면 도메인을 새 서버로 전환하는 방법도 있습니다.

직면하게 될 가장 큰 문제는 Postgres의 주요 업그레이드(18 버전으로의 업데이트)입니다. 새 서버를 구축하면 이 업그레이드 과정을 거치지 않아도 됩니다.

또한, 의존하고 있는 플러그인이나 테마 컴포넌트가 유지보수되지 않았을 가능성도 있습니다. 특히 덜 활동적인 제3자가 작성한 경우 더욱 그렇습니다.

경험이 많은 Discourse SA(시스템 관리자)들이 업데이트를 커밋하기 전에 부트스트랩할 수 있도록 두 개의 컨테이너를 설정하는 이유가 바로 이 긴장감 때문입니다. (다만, Postgres의 대규모 업데이트 상황에서는 그 효과가 크지 않지만, 이런 업데이트는 드물게 발생합니다.)

3

답변해 주셔서 감사합니다. 이 아이디어가 마음에 들고, 이 방향으로 한번 시도해 볼게요!