제가 올린 compose 샘플에서 범용 PG 이미지를 사용하지 않은 이유에 대한 참고 사항이었습니다.
음… 하지만 다른 방법들이 더 복잡해지지 않나요?
아, 알겠습니다! 
도커 고수라면 이 모든 게 매우 쉬울 것 같은데요?
지난 며칠간 설명해 왔듯이, 현재 제공된 솔루션을 사용하면 오히려 모든 것이 쉽지 않다는 말씀입니다.
요약하면,
레드리스와 데이터베이스 접근 같은 기본적인 설정을 위한 환경 변수 몇 개만 있으면 되는, bitnami 이미지와 비슷한 단순한 Discourse 이미지가 있으면 충분할 텐데, 무슨 이유에서인지 이건 완전히 불가능하다고 하네요… 
저는 정확히 그 일을 수행하기 위해 개념 증명(Proof of Concept)을 여기에 공유하고 있습니다.
단순한 플러그인이라면 그럴 수 있지만, 모든 플러그인이 특정한 형태를 가진다고 가정할 수는 없습니다. 일부 플러그인은 추가적인 설정, 설치할 추가적인 gem, 또는 추가적인 gem 의존성이나 apt-get install이 필요한 외부 프로그램이 필요합니다. 이러한 것들은 커스텀 이미지에 포함(bake)되어야 합니다.
이것이 구현되는 모습을 보는 것은 훌륭할 것이라 생각하지만, 결코 자명한 일은 아닙니다.
웹 업데이트에 관해 말하자면, Discourse 운영자 역시 CLI나 docker를 전혀 알아야 할 것으로 기대되지 않습니다.
launcher를 사용하여 직접 이미지를 빌드하고(이것은 GitHub Actions로 처리할 수 있습니다), 저장소에 푸시한 후 환경 변수를 설정하여 시작하면 됩니다. 여전히 데이터베이스 마이그레이션, 자산 사전 컴파일, 그리고 S3로의 푸시가 필요합니다. 데이터베이스를 마이그레이션하고 skip_post_deployment_migrations를 설정하여 새 컨테이너가 완전히 실행될 때까지 구 컨테이너가 계속 작동하게 할 수 있으며, 이후 구 컨테이너를 종료하고 나머지 마이그레이션을 실행할 수 있습니다. 하지만 이것은 Discourse에 대해 당신이 알고 싶어하는 것보다 훨씬 더 많은 지식을 가진 사람이 아니면 너무 복잡합니다. 그리고 많은 것들이 잘못될 수 있는데, 당신이 지적한 모든 이유로 인해 현재 해결책은 끔찍하지만, bash가 무엇인지조차 모르는 수천 명의 사용자들에게는 최선의 해결책입니다.
대부분의 경우 ./launcher rebuild app만 실행하면 되며, 몇 년에 한 번씩 데이터베이스를 업그레이드할 필요가 있을 때만 두 번 실행해야 합니다. docker-compose로는 그런 수준의 단순함을 얻을 수 없습니다. 처음부터 docker-compose가 사용 가능했다면 자체 솔루션을 만들 필요 없이 이를 사용할 수 있었을 가능성이 있지만, 그렇게 되지는 않았습니다.
bitnami 이미지를 사용하려면 사용할 수 있지만, 여기서는 그에 대한 도움을 많이 받기 어렵습니다. 많은 사람들에게도 잘 작동할 것이라고 생각합니다.
음… 범용적이고 플랫폼 독립적이어야 하는 언어/환경에서, 하위 OS의 패키지 관리자에 의존하는 것은 다소 기이해 보입니다… 
이전에 언급했던 내용인데, Discourse가 PHP 소프트웨어/포럼 관리를 “오래된” 방식으로 단단히 고집하고 있는 것 같습니다
그러므로 전체 논의를 요약하면 (또는 지루하게 반복하지 않도록 첫 번째 메시지에 포함시켜도 좋을 것 같습니다 ):
- Discourse는 "일반 사용자"에 맞춰 설계되었으며, 전체 설정은 그들의 요구 사항을 충족하는 데 초점을 맞추고 있습니다.
- Ruby(환경)가 다소 특이한 구조를 가지고 있기 때문에, 공식 Discourse 저장소에서 충분히 범용적인 공식 docker 이미지를 제공하는 것은 사실상 불가능합니다.
맞습니까?
조금 다르게 표현하자면
기본적으로 런처(Launcher) 외에는 공식 이미지 제공 방식이 없기 때문에, 런처가 사실상 Discourse를 설정하는 기본이자 (권장되는) 유일한 방법이라고 볼 수 있습니다. 따라서 원래의 주장은 여전히 유효하다고 할 수 있죠
하지만 이는 그저 의미론적인 문제일 뿐입니다.
어쨌든 - 이 주제의 핵심은 다음과 같습니다:
Discourse가 부트스트랩(bootstrap)이 필요하지 않은 Docker 이미지를 자주 배포할 수 있는가
전체 논의 과정을 보면: “아니요, Discourse는 부트스트랩이 필요하지 않은 Docker 이미지를 자주 배포하지 않거나, 그렇게 하기를 원하지 않습니다”, q.e.d. (증명 완료)
따라서 해당 이미지가 제공되지 않을 것이라는 주석을 맨 위에 바로 추가하는 것을 제안하면, 많은 불편함을 줄일 수 있을 것입니다
이것은 잘못된 가정입니다.
우리는 아직 특정 플러그인 번들이 포함된 공식 이미지를 배포하는 것을 우선순위 두지 않았습니다.
고려하고 있는 작업이며, 이를 수행하는 방법에 대한 아이디어도 많이 있지만, 단순히 회사의 우선순위가 아니었을 뿐입니다.
다른 프로젝트에 종사하는 사람의 번역: “미래에 일어날 수도 있지만, 일어나지 않을 수도 있습니다… 우선순위가 아니거나 로드맵에 없기 때문에 실현될 가능성은 거의 없습니다.” 
다만, 진지하게 말하자면 - 이러한 기본적인 설정에 합리적인 플러그인 세트가 번들링되어 있다면 정말 멋질 것 같습니다!
피드백 감사합니다! <3
참고로, 개발용 컴퓨터(devbox)에서 Discourse 이미지를 빌드한 후 서버에 배포하는 방법을 설정했습니다. 이 방법을 사용하면 launcher 스크립트를 사용할 필요가 없습니다.
이와 관련된 추가 논의는 제가 생성한 여기의 풀 리퀘스트에서 확인할 수 있습니다.
이 설정은 Discourse 공식 Docker 환경과 완전히 호환되도록 구성했으므로, 이 솔루션이 지원 중단되거나 깨질 것에 대해 걱정하지 않아도 됩니다.
이 방식이 어떻게 작동하는지 간단히 요약하면, launcher 스크립트가 아닌 Docker 이미지 자체에 부팅 시 bootstrap 명령을 실행하도록 책임을 지우는 것입니다.
좋은 접근법이네요.
그리고: 흥미로운 launcher v2 (GitHub - discourse/launcher: Discourse Launcher CLI · GitHub)!