それは、私が投稿したコンポーズサンプルが汎用のPG画像を使用していなかった理由についての注記でした。
うーん…他の方法がより複雑になるということはないでしょうか？
わかりました！ 
Dockerの達人であるあなたなら、これらはすべて非常に簡単なのではありませんか？
「いいね！」 3
ここ数日説明しようとしているように、現在の提供されているソリューションでは、まったく簡単ではありません 
長すぎたので要約すると;
Redisやデータベースへのアクセスのような基本的な設定を行うための多くの環境変数を持つ、シンプルなDiscourseイメージ（bitnamiのものに似ている）で十分ですが、なぜかこれは完全に却下されました… 
まさにそれを行うための概念実証をここに共有しています。
シンプルなプラグインであれば可能ですが、プラグインが特定のようになるとは限りません。一部のプラグインは追加の設定、インストールする追加のgem、または追加のgem依存関係、あるいはapt-get installを必要とする外部プログラムを必要とします。それはカスタムイメージに組み込まれるべきです。
これが実現されるのは素晴らしいことですが、簡単ではありません。
Webの更新について、DiscourseオペレーターはCLIやDockerを全く知らないことが期待されています。
「いいね！」 1
ランチャーを備えた独自のイメージを構築し（GitHub Actionsで実行可能）、リポジトリにプッシュし、環境変数で起動するだけです。データベースの移行、アセットの事前コンパイル、S3へのプッシュも必要です。データベースを移行し、skip_post_deployment_migrations を設定すれば、新しいコンテナが起動するまで古いコンテナを稼働させ続けることができます。その後、古いコンテナをシャットダウンし、残りのマイグレーションを実行します。しかし、これは、あなたが知りたいと思っている以上にDiscourseについて知らない人にとっては複雑すぎます。そして、うまくいかないことがたくさんあるため、あなたが概説したすべての理由でひどい現在のソリューションは、bashが何であるかを知らない何千人もの人々にとって最善のソリューションです。
ほとんどの場合、./launcher rebuild app を実行するだけで済みますが、データベースをアップグレードする必要がある場合は数年に一度だけ、2回実行する必要があります。docker-composeでは、そのレベルのシンプルさを実現することはできません。彼らが始めたときにdocker-composeが利用可能であれば、独自のものを開発する代わりにそれを使用できた可能性がありますが、物事はそうはなりませんでした。
ビットナミイメージを使用したい場合は使用できますが、ここではあまり助けを得られません。多くの人にとってもうまくいくと思います。
「いいね！」 1
うーん…普遍的でプラットフォームに依存しないはずの言語/環境にとって、基盤となるOSパッケージマネージャーに依存するのは非常に奇妙ですね… 
これは以前言及したことですが、DiscourseはPHPソフトウェア/フォーラムの管理の「古い」方法にしっかりと根ざしているようです
したがって、議論全体を要約すると（そしておそらく、うんざりするほど繰り返さないように最初のメッセージに入れると :)）：
- Discourseは「普通のユーザー」に合わせて調整され、焦点を当てており、セットアップ全体が彼らのニーズに応えるように調整されています。
- Ruby（環境）はやや奇妙であり、（1）公式Discourseリポジトリで十分に汎用的な公式dockerイメージを提供することは事実上不可能であるため。
正しいですか？
少し違う言い方をします
公式のイメージ提供（デフォルトで）がなく、Discourseのセットアップ方法がランチャー以外にないため、ランチャーがデフォルトであり、基本的に唯一（推奨される）Discourseのセットアップ方法であることから、元の声明は依然として有効であると主張することもできます
しかし、それらは単なる言葉遊びです。
いずれにせよ、トピックは次のとおりです。
Discourseはブートストラップを必要としない頻繁なDockerイメージを出荷できますか？
議論全体から、次のことがわかります。「いいえ、Discourseはブートストラップを必要としない頻繁なDockerイメージを出荷できません/したくありません」、q.e.d.
したがって、そのようなイメージは提供されないというコメントを一番上に追加するという提案は、多くの手間を省くでしょう
これは誤った仮定です
現時点では、特定のプラグインのバンドルを含む公式イメージの出荷を優先していません
これは検討中の作業であり、それを行うための多くのアイデアがありますが、単に会社の優先事項ではありませんでした
「いいね！」 5
他のプロジェクトで作業している人からの翻訳：「将来的には起こるかもしれませんが、起こらないかもしれません…優先事項ではなく、ロードマップにも載っていないことを考えると、起こる可能性はほとんどありません」
しかし、もっと真面目な話をすると、バンドルされた適切なプラグインセットによるこのような基本的なセットアップは非常にクールになるでしょう！
ご意見ありがとうございます！ <3
FYI - Discourse イメージを devbox でビルドし、ランチャースクリプトを使用せずにサーバーにデプロイする方法を設定しました。
詳細については、私が作成したプルリクエストのこちらでさらに議論しています。
Discourse の公式 Docker セットアップと完全に互換性があるように設定したため、このソリューションがサポート対象外になったり、壊れたりする心配はありません。
仕組みの TLDR は、launcher スクリプトの代わりに、起動時にブートストラップコマンドを実行する責任を Docker イメージに持たせたことです。
「いいね！」 1
素晴らしいアプローチですね。
また、興味深いランチャー v2 です (GitHub - discourse/launcher: Discourse Launcher CLI)！
「いいね！」 2