簡単ではないことは承知しています。しかし、コンテナの目的は、一貫性のある移植可能な状態を実現することです。したがって、コンテナが本来あるべきように使用され、あなたにとって機能しているなら、そのコンテナを使用するすべての人にとっても機能する可能性はかなり高いでしょう。
ブートストラップ処理自体をホスト側ではなくコンテナ内部に移動させれば、移植性の向上においてすでに大きな進歩を遂げることができます。他のプロジェクトを終わらせたら、確認してみます。私もコンテナの専門家ではありませんが、いくつか構築した経験があります。ただし、欠点として、インストールに関するドキュメントが存在しないということですね。単に「これを実行してください」とスクリプトを渡すだけという状況です。スクリプトが何を行っているかを再現することはできますが、改善提案の余地はあまり残されていません。
したがって、コミュニティ、特にインストールの仕組みについて内部情報を持っている関係者の方々が助言や協力をする意思があれば、このイニシアチブを開始する用意があります。そうでなければ、求める品質には達しないでしょう。
目標は概ね以下の通りです：
- ローカルでのブートストラップ（コンテナ外）を行わず、セットアップのアトミックなビルドを実現する Dockerfile
- コンテナを root として実行する必要をなくすこと。最善策は fakeroot を使用し、capabilities を追加することです（これらはコマンドライン引数であり、ユーザーは依然として root としてコンテナを起動することを選べます…）
- 環境変数によって制御可能なエントリーポイントスクリプトを作成し、それらの変数を明確に文書化すること
podman-generate-systemdまたは同様の機能を使用して、コンテナの（再）起動や起動時の自動起動を行う systemd ユニットを作成すること（Podman の機能です。Docker にも類似のものがあるかもしれませんが、こちらはより統合的なアプローチです）
これが基本インストールの要件となります。スケーラブルなソリューションについては、docker-compose と Kubernetes のソリューションが必要になります。正直なところ、「すべてに当てはまる」解決策を見つけることは Discourse コミュニティの責任ではないと考えています。なぜなら、特に Kubernetes においては、これらは非常にきめ細かくカスタマイズ可能だからです。したがって、人々がすぐに使い始められるための基本的な compose ソリューションで十分だと考えます。
これにより、移植性が高く、より安全なソリューションが提供され、全体的な採用率と品質が向上します。その間、Discourse が私のコミュニティに本当に必要なものかどうかを確認します。必要であれば、当面は Ubuntu LTS システムを使用します。時間ができたら、そのようなセットアップに時間を投資する予定です。