안녕하세요.
전체 재빌드 없이 더 새로운 버전으로 업데이트할 수 있을까요?
두 개의 discourse 앱이 사실상 동일한 시나리오를 생각하고 있습니다. 새 이미지가 준비되면 그중 하나에서 두 번째 discourse를 배포할 수 있으며, 컨테이너에 대한 모든 설정/파라미터가 이미 갖춰져 있을 것입니다.
이러한 컨테이너의 경우 남은 작업은 pg db 마이그레이션뿐일 것 같은데, 맞을까요?
이것이 타당하고 가능한 경우, 소스 코드를 해킹하지 않고 어떻게 하면 좋을지 알려주시면 감사하겠습니다.
감사합니다, L.
이미지를 빌드하고, 리포지토리에 푸시한 다음, ./launcher start-cmd app를 실행하여 컨테이너를 시작하는 도커 명령을 가져올 수 있습니다(이때 로컬 리포지토리 대신 본인의 컨테이너 리포지토리를 사용해야 합니다).
그런데 이후에는 데이터베이스 마이그레이션, 에셋 사전 컴파일 등의 작업이 필요합니다.
다운타임을 피하고 싶다면, 두 컨테이너 구성을 사용하면 구 컨테이너가 계속 실행되는 동안 새 컨테이너를 빌드할 수 있으며, 마이그레이션 등의 작업도 자동으로 처리됩니다.
더욱 신중하게 진행하려면 app.yml에서 SKIP_POST_DEPLOYMENT_MIGRATIONS를 설정한 후, 새 컨테이너가 시작된 다음에 rake db:ensure_post_migrations db:migrate를 실행할 수 있습니다. 이렇게 하지 않으면 데이터베이스가 마이그레이션되어 구 컨테이너가 더 이상 이를 사용할 수 없게 될 수 있습니다. 이는 흔한 문제는 아니며, 설사 문제가 발생하더라도 오래 지속되지는 않습니다.
다운타임은 내게 문제가 되지 않습니다.
생각하는 앱 두 개는 거의 동일하지만, 완전히 같은 것은 아닙니다.
두 앱은 서로 다른 사이트, 즉 서로 다른 DB, 볼륨, 포트, 이름 등을 가지지만, 말하자면 동일한 기반 Discourse(그리고 동일한 플러그인, 그 핵심/기반에 결정적으로 중요한 동일한 구성 요소)를 공유합니다.
이상적인 Discourse 환경에서 — 만약 아직 그런 환경이 없다면 — 이러한 시나리오에서 새로 빌드된 이미지가 최초/일회성으로 빌드된 후, Docker 도구를 통해 직접 사용할 수 있게 됩니다. 그리고 해당 새 이미지/Discourse 버전으로 "이전(migrate)"되어야 하는 DB나 기타 항목은, 이러한 “보조” 컨테이너의 시작/부팅 과정에서 — 아마도 환경 변수의 도움으로 — 필요한 DB 마이그레이션을 확인하고 실행하도록 결정하게 됩니다.
가장 큰 장점 — 이미 많은 분들이 생각했을 것인 — 은 두 개(혹은 일부 사용자가 그렇게 한다면 더 많은) 컨테이너/앱에 대해 단일 이미지를 사용하는 것입니다.
제가 설명해 드린 대로 하시면 됩니다. 또한, 이미지를 하나로만 사용하면서 재빌드 없이 실행할 수 있도록 하는 새로운 방식도 개발 중입니다. 다만 공식적으로 지원되지 않으므로, 여기나 GitHub에서 잘 검색해 보셔야 합니다.
안녕하세요, 감사합니다.
새로운 이미지를 로드한 후 rake db:ensure_post_migrations db:migrate를 실행하니 luncher 재빌드 없이 정상적이고 건강한 컨테이너의 새 버전이 생성되는 것 같습니다. 적어도 3.5.0.beta7에서 2025.11.0으로의 업그레이드에서는 말이죠. 이는 저뿐 아니라 다른 분들도 이런 생각을 하게 합니다. 특정 사용자 정의 컨테이너의 부팅/시작 시 이러한 rake 명령(그리고 건강한 업그레이드에 필요한 기타 작업)을 실행하는 것이 가능할까요? 그리고 그렇게 하는 것이 합리적인가요?
자산(asset)을 미리 컴파일하는 것도 원할 가능성이 높습니다