@Stephen 당신의 주장에는 결함이 있습니다: 멀티 컨테이너 설명서에는 업데이트에 대한 책임을 지고 그 작동 원리를 이해해야 한다는 경고가 가득하며, 위쪽에 있는 긴 설명서는 너무 난해해서 그걸 본 사람은 누구나 결국 포기할 가능성이 큽니다. 제 글 Migrate quickly to separate web and data containers 을 읽어보시고, 이 글이 따라가기 어려워 어려움을 겪을 사람들을 겁먹게 만들지 않거나, 문제가 생겼을 때 백업의 필요성과 백업으로 되돌릴 수 있는 능력을 강조하지 못한다고 말씀해 보세요!
더 나은 성능의 서버로 마이그레이션(보안 패치 적용을 위해)한 직후 ./launcher rebuild app 명령을 실행했을 때, 사이트가 터무니없이 오랜 시간 동안 중단된 상태였고, 그 중 상당 부분이 컨테이너의 postgres 부분을 재빌드하는 데 소요되었다는 사실을 알게 되었을 때 매우 불쾌했습니다. 그때 저는 2container 문서와 이 문서를 발견했는데, 복원하는 데 걸리는 4시간의 다운타임을 피하기 위해 ./launcher rebuild app으로 인한 긴 다운타임을 계속 감수하며 마이그레이션을 다시 하고 싶지 않았습니다. 다소 유능한 사람으로서, 이 구성이 사실상 숨겨져 있다는 사실에 오랫동안 매우 짜증을 냈습니다.
postgres 12 관련 토픽은 훌륭한 참고 자료입니다. postgres 컨테이너만 두 번 재빌드하면 될 상황에서, 사람들이 앱 전체를 여러 번 재빌드해야 하기 때문에 오히려 더 많은 다운타임을 겪게 되거든요. 6일 자동 삭제 기능 때문에 전체 스레드를 다 읽지는 못했지만, 거기서 무능한 멀티 컨테이너 배포가 주요 문제이거나 심지어 문제가 된다고 보는 것은 저에게 전혀 자명하지 않습니다.
(죄송합니다. 여기서는 때때로 "모든 사용자는 무능하다"는 태도에 조금 지칠 때가 있습니다.)