업그레이드를 위해 우리가 공식적으로 지원하는 플러그인인 Docker Manager는 어떤 다운타임도 발생시키지 않습니다. 이 플러그인은 이미 무중단 업그레이드를 지원하므로 변경이 필요하지 않아야 합니다. 이 #howto에서 다루는 문제는 커맨드 라인에서 수행되는 업그레이드(리빌드)에 관한 것입니다. 이러한 작업은 Ruby 버전이나 Postgres와 같은 기반 의존성을 업그레이드할 필요가 있을 때만, 즉 연간 몇 번 정도만 필요한 경우에만 수행됩니다.
Docker Manager와 같은 모든 Discourse 구성 요소는 리빌드 동안 중단되므로, Docker Manager가 이러한 업그레이드를 처리하도록 만드는 것은 불가능합니다. 따라서 이 토픽에서 제공하는 Nginx 프록시 솔루션과 같이 Discourse 외부의 솔루션이 필요합니다.
음, 여기에는 Discourse의 특성과 더 통합된 다른 옵션들이 있을 것 같습니다. 이 개념을 바로 기각하기보다는, 특히 관리자가 어떤 이유로 사이트를 유지보수를 위해 중단해야 할 때를 고려하여 전반적인 경험을 개선하는 방법에 대해 이야기해 보죠.
떠오르는 아이디어 중 하나는 다음과 같습니다: OP(원글 작성자)가 제안한 Nginx 프록시 솔루션을 Docker 설정에 통합하여, 여기에서 제시된 것처럼 분리된 솔루션을 다루는 것 대신, Discourse 사용자/관리자 및 지원(이 포럼에서 여러분 같은 분들) 모두에게 더 예측 가능하고, 관리하기 쉬우며 일관된 환경을 만드는 것은 어떨까요?
./launcher rebuild app 실행 중 장애를 최소화하려면 멀티 컨테이너 구성이 필요합니다.
이미 관련 문서가 작성되어 있습니다. 보다 복잡한 구성입니다.
단일 컨테이너 모드에서 launcher rebuild를 실행할 때 “오프라인” 페이지를 표시하려면, 컨테이너를 “사이트 오프라인” 전용 특수 컨테이너로 교체해야 합니다. 불가능한 일은 아니지만, 완벽하게 작동하려면 약 2주간의 엔지니어링 작업이 필요합니다. 컨테이너 재빌드가 매우 드물게 발생하고, 이미 장애 없는 재빌드 방법을 문서화해 두고 있으므로, 현재로서는 이 작업을 위한 비용을 감당하기 어렵다고 생각합니다.
두 컨테이너 방식의 설치 환경은 대부분의 경우 최소한의 다운타임으로 업그레이드를 가능하게 합니다. 다만 새로운 컨테이너를 빌드하는 과정에서 마이그레이션이 실행되어 현재 실행 중인 사이트가 충돌하는 경우가 있습니다. 이를 우회하는 방법이 있지만 꽤 복잡하며, 이러한 업데이트는 비교적 드물게 발생합니다.
또는 DNS를 다시 가리키거나(또는 Digital Ocean이 이를 어떻게 부르든, 탄력적 IP를 사용하거나) 웹 서버에 상태 메시지를 담아 두어 AWS에서 이를 어떻게 부르든 드롭렛(또는 해당 인스턴스)을 시작하는 방법도 있습니다.