当組織は Web アプリケーションとフォーラム、そして Bitwarden などのいくつかの他のアプリケーションを運用しています。開発環境と本番環境の整合性（dev/prod parity）を保ち、Docker Compose を用いたシンプルな開発セットアップを実現するため、すべてのアプリケーションをコンテナ化しています。本番環境でも非常に似た compose ファイルを使用しており、基本的なユースケースには非常にうまく機能しています。
フォーラムを Discourse に切り替えたいと考えていますが、開発環境と本番環境の整合性を保ちつつ、シンプルな開発セットアップを維持する方法がわからず困っています。
公式ドキュメントによると、Discourse は Docker を使ってインストールおよび実行されますが、他の Docker コンテナのようなコンテナのパラダイムには完全に適合していないようです。つまり、他のアプリケーションコンテナのようにデータベースや Redis コンテナに接続して、compose や Swarm、Kubernetes スタンクに追加して実行することはできません。また、コミュニティを分断しないよう努めるため、代替ソリューションや提案は強く推奨されていません。そのため、私はこのアプローチ自体を疑問視しているわけではありません。
Discourse を他のスタックと同じように実行・管理するのではなく、本番環境では専用 VM を運用し、異なる方法で管理する必要があることを受け入れました。しかし、私の根本的な目標である「本番環境とある程度整合性の取れた、シンプルな開発セットアップ」をどう実現するかについて、知見を求めています。
現状の開発セットアップは「Docker をインストールし、リポジトリをクローンして docker-compose up を実行する」というものです。ローカルインストールガイド を正しく理解しているなら、Discourse 自体を手動でクローンしてセットアップする前に、Ruby や Postgres などの 9 つのシステム依存関係が必要です。私の考えでは、Docker（および Docker Compose）の利点の一つは、Postgres や Redis などをローカルシステム上で実行する必要がないこと（また、Windows の開発者がこれらをセットアップする際に生じる関連する問題も回避できること）です。スタックを実行するだけで、プロセスは使い捨てコンテナに隔離されます。この利点を維持する方法はあるでしょうか？
もう一つの欠点は、我々がボランティアの少人数チームであるため、他の開発者の多くが Windows 10 Home を使用している点です。私の知る限り、Windows 10 Home は WSL をサポートしていないため、これらの開発者は Windows 向けのインストール手順に従うことができません（Docker 自体は Windows 10 Home で動作します）。