사이트를 3.1.0.beta1에서 3.1.0.beta2로 업데이트한 후, 새 버전의 부트스트랩이 완료되었지만 구버전 앱 컨테이너를 제거하고 새 컨테이너를 시작하기 전에, 해당 사이트 중 적어도 하나에서 사용자에게 일반적인 오류 페이지가 표시되기 시작했습니다.
테스트 사이트나 제가 운영하는 다른 사이트에서는 이를 발견하지 못했지만, 실제로 발생했음에도 확인하지 못했을 가능성은 있습니다.
어쨌든 제 경우, 적어도 한 건에서는 ‘제로 다운타임’ 업데이트 프로세스가 성공하지 못했습니다.
제가 GUI 업데이트 도구를 사용하지 않았다는 점을 다시 한번 강조합니다. 저는 멀티 컨테이너 설치 환경을 사용하고 있습니다. 다음 명령을 실행했습니다:
git pull
./launcher bootstrap app
./launcher destroy app && ./launcher start app
./launcher cleanup
(웹 앱의 경우에도 멀티 컨테이너 설치 환경에서 app을 사용합니다. 일반적인 관행은 아니라는 것을 알고 있습니다. web_only를 타이핑하는 것이 싫거든요.)
bootstrap을 시작한 후 앱이 종료되기 전에, 새 데이터베이스를 대상으로 구버전이 실행되던 중 오류 화면만 표시되었습니다. 내용이 무엇이었는지 기억나지 않고, destroy/start를 실행하기 전에 스크린샷을 찍기 위해 멈추는 것으로 더 긴 다운타임을 유발하지는 않았지만, 흰 배경에 텍스트만 있는 화면이었고 시스템 유지보수 페이지도 아니었습니다. 이전에 몇 번 본 적이 있는데, bootstrap이 비동기 “제로 다운타임” 재구성의 일부로 db:migrate를 실행할 때, 여전히 실행 중인 구버전 소프트웨어가 스키마 불일치로 인해 실패하는 경우가 있었습니다.
제가 본 것은 데이터베이스 불일치 상황에서 발생하는 현상이었습니다. 이는 데이터베이스를 손상시키면서 무사히 진행하는 것보다 훨씬 낫습니다. 제가 게시물을 올린 이유는, 포인트 업데이트(여기서는 3.1.0.beta1에서 3.1.0.beta2로)를 적용할 때 3.1.0.beta1 코드와 3.1.0.beta2 db:migrate 실행 후의 데이터베이스 사이에 스키마 호환성 문제가 생길 수 있다는 점을 경고하기 위해서였습니다. 이는 멀티 컨테이너 배포 환경에서 일반적인 낮은 다운타임 업데이트 시 드물지만 간혹 발생하는 현상입니다.
제 경험은 GUI 업데이트 도구에서 ruby와 관련하여 보고된 오류와 다릅니다. 완전히 무관한 문제입니다. 제 게시물이 공지사항에서 일반적인 “문제” 스레드로 이동된 것을 인지하고 있지만, 제가 공지사항에 게시물을 올린 이유는 저와 같은 셀프호스터들이 해당 공지를 볼 때, 이 특정 업데이트가 이러한 영향을 미칠 수 있는 경우임을 경고하기 위해서였다는 점을 명확히 하고 싶습니다.
제 메시지는 버그나 심지어 문제점에 대한 불만이 아니었습니다. 이 특정 릴리스와 관련된 정상적이지만 드문 경우를, 릴리스 노트에 명시되지 않았음에도 불구하고 통보하기 위한 것이었습니다.
Docker 매니저가 이미지 내에서 업데이트할 수 없다는 사실을 인식하지 못한다는 불만은, 제가 다른 셀프호스팅 관리자에게 도움이 되는 통보를 제공하려는 시도와는 완전히 무관합니다.
이러한 무관한 문제들을 독립적인 문제로 독립적인 스레드로 분리하는 것이 훨씬 합리적일 것입니다. @supermathie 편집: 완료
Introducing Post Deployment Migration 의 두 단계 마이그레이션을 수행 중이신가요?
예를 들어 블루/그린 배포를 수행하고 이전 버전이 계속 작동해야 하는 경우, 이 패턴이 매우 중요합니다.
[quote=“Michael K Johnson, post:12, topic:252916, username:mcdanlj”]
저는 이렇게 했습니다:
git pull
./launcher bootstrap app
./launcher destroy app && ./launcher start app
./launcher cleanup
```[/quote]
이것이 질문에 대한 답변이 될 것 같습니다. `launcher` 스크립트는 `SKIP_POST_DEPLOYMENT_MIGRATIONS`를 지원하지 않습니다.
[quote="Michael K Johnson, post:12, topic:252916, username:mcdanlj"]
제 메시지는 버그나 문제점에 대한 불만이 아니었습니다. 다만 이 특정 릴리스와 관련된 일반적이지만 드문 경우를 알리기 위한 것이었고, 릴리스 노트에는 언급되지 않은 내용이었습니다.
[/quote]
다시 한번 말씀드리지만, **저는 버그를 보고하는 것이 아닙니다.** 표준 멀티컨테이너 설치 환경에서 `launcher`를 사용하는 문서화된 일반 프로세스를 따르는 다른 사용자들이, 이번 사례가 일반적인 경험과 다르다는 점을 경고하고 싶을 뿐입니다.
진심으로, 정말로, 정식으로 말씀드리지만, 이것은 버그 리포트가 아닙니다!
`launcher`에서 블루/그린 배포를 원하신다면, 이를 구현하기 위해 `launcher`에 PR을 제공해야 할 것입니다. ☺토픽 제목의 "문제"라는 표현은 제가 붙인 것이 아닙니다. 제 댓글이 공지 스레드에서 이동될 때 그렇게 바뀌었습니다. 이제 제목을 수정해서, 제가 문제를 불평하고 있는 것이 아니라는 점을 분명히 했기를 바랍니다. 
모두 잘 진행되고 있습니다!
다중 컨테이너 기반 블루/그린 배포를 사용하는 사용자는 매우 소수일 것 같지만, 그 방법에 대한 제안은 환영합니다.
그리고 제가 링크한 토픽을 찾는 방법도 궁금합니다. 이미 존재한다는 것을 알고 있지 않는 한 찾기 쉽지 않을 것 같네요.
SKIP_POST_DEPLOYMENT_MIGRATIONS 문서를 본 적은 있습니다. 하지만 제가 정말 놓치고 있었던 것은 launcher를 이용해 제로 다운타임 배포를 수행하는 방법을 보여주는 이 포스트였습니다:
이제 이것이 실현 가능하다는 것을 알게 되었으니, 이에 대해 고민해야 합니다. 만약 실행하게 되면, 제가 취한 조치들을 MKJ's Opinionated Discourse Deployment Configuration 포스트에 업데이트하겠습니다.
여가 시간에 무료로 운영 중인 서비스에서 가용성 99.994%를 제공하고 있는 상황에서, 이 문제로 스트레스를 받는 것이 좀처럼 쉽지 않았습니다. 이번처럼 약 1분 정도의 다운타임이 발생하거나, 보안 업데이트를 위해 호스트를 재부팅하는 경우를 포함하여, 테스트 통과 정책만으로도 이를 달성할 수 있다는 점은 Discourse 개발 품질의 우수성을 입증하는 것입니다.
dashboard.literatecomputing.com에서 사용하는 Ansble 스크립트는 새 컨테이너가 시작된 후 rake 작업을 실행하여 배포 후 마이그레이션을 수행합니다. 이 방식은 web_only.yml에서 SKIP_POST_DEPLOYMENT_MIGRATIONS가 켜져 있어야 한다는 전제에 의존합니다. 저는 이 방식을 제 스크립트로 관리하는 사이트에서만 사용합니다. 왜냐하면 이 방식이 어떻게 작동하는지 이해하지 못하면, 그것은 일종의 시한폭탄이 될 수 있기 때문입니다.
많은 업그레이드에서는 새 컨테이너를 부트스트랩하더라도 현재 실행 중인 컨테이너에 문제가 발생하지 않지만, 일부 업그레이드에서는 문제가 발생합니다. 업그레이드 과정에서 데이터베이스가 마이그레이션되어 SKIP_POST_DEPLOYMENT_MIGRATIONS를 사용하지 않으면 구버전 컨테이너가 데이터베이스를 사용할 수 없게 되는 경우가 그리 드물지 않습니다.