Docker Composeは、必要な機能を提供していません。DiscourseのDockerfileのテンプレート作成機能は、柔軟なDockerの結果を可能にします。Composeでは、固定されたDockerfileのセットしかなく、それが多数のコンテナにつながる可能性があります。
私のDiscourseセットアップでは、UNIXソケットを使用して、Discourseとnginxを含む単一のコンテナを使用しています。PostgreSQLとRedisはホスト上のサービスです。それはデフォルトのセットアップからかなり逸脱していますが、標準で可能です。
Composeでは、おそらくあまりうまく設計されていないプロファイル機能を使用することで、部分的に可能です。しかし、それでもかなり厄介です。あるいは、バリエーションごとに異なるComposeファイルを提供する必要があります。
あなたは問題を移動させているだけです。
DiscourseのためのクリーンなComposeセットアップは、別々のコンテナで以下のサービスを持つことになります：
- Discourse
- nginx
- PostgreSQL
- Redis
Discourseとnginxはボリュームを共有する必要がありますが、大したことではありません。
PostgreSQLとRedis…これらは、別の場所にホストしたいものであり、それ専用のDiscourseコンテナを持たないようにしたいものです。そして今、docker composeが問題になります。docker compose up -d は、望まないPostgreSQLを起動します。OK、そこで docker compose --profile postgresql up -d とすることで、基本的なDiscourseセットアップとPostgreSQLコンテナを起動します。docker compose --profile postgresql --profile redis up -d で「フル」セルフコンテナDiscourseコンテナセットアップとなります。--profile ... 引数を忘れない方が良いでしょう。そうしないと、さらに問題が発生します。
そのため、より良いUXのために、目的のdocker composeコマンドを作成するためのランチャーを作成します。これで、私たちはある意味元に戻りました。nginxコンテナへの変更がまだできないという点を除いては。
つまり、nginx-httpコンテナとnginx-unixコンテナが必要で、これらは相互に排他的であるべきでしょうか？
確かにプラグイン管理は改善される可能性がありますが、これをdocker composeで行うのは地獄でしょう。