Oh man that’s tragic. So sorry to hear 
「いいね！」 7
https://meta.discourse.org/t/official-cloud-native-docker-image-from-discourse/228568/8
@sam とこのトピックで明確になったように、これは決して解決されないでしょう。ビットナミはちょうどそれをやったのに…
少なくとも、私たちの質問に対する答えは「いいえ」だとわかりました。
そもそもrootを使用しないことについてはどうでしょうか？ fakeroot を使用すると、主な障害は（/varのような）ハードコードされたパスであることがわかります。それ以外は、現在のセットアップが抱えるさまざまなバグや問題を別にすれば、機能するはずです。
コンテナ化に関する一般的な誤解に基づいた、非常に優れたソフトウェアに、これほど設計の悪い必須のセットアップ手順があるのを見るのは残念です。最善の意図をもって行われたことは明らかですが、その結果は、ホビイスト環境以外ではどこにも展開できないものになっています。
「いいね！」 1
画像はディスコースユーザーとして実行されており、公式のものもそうだと思います。
いずれにしても、「企業」の世界が関心を持っているのは素晴らしいことです。ホビイストの世界よりも多くの時間とお金を持っているからです 
エコシステムの改善への貢献をコミュニティはきっと感謝するでしょう！
「いいね！」 1
それは確かに正しくありません。私たちは、マシンフリート全体でNomadを使用してイメージをデプロイしています。現在、AWSとメタルで10,000を超えるDiscourseコンテナが稼働しています。
「いいね！」 3
ツールを実行するにはroot権限が必要であり、ホストの /var へのアクセス権も必要です。
私は、コンテナ設定の改善のために、オープンソースコミュニティや企業と協力することがよくあります。喜んでお手伝いしたり、より合理的なコンテナ化された設定のために資金提供を検討したりさせていただきます。
必須ではありません。ただ、セットアップに手助けが必要な場合は、その方法があるということです。例えば、GKE、EKS、ECSを使用しているクライアントを支援しました。お客様の特定の要件についてサポートが必要な場合は、お気軽にご連絡ください。
/varはハードコーディングされていません。最近、/var/www/discourseにそれがある人と協力しましたが（ウェブに機密データを公開するリスクがあるため、これは非常に悪い考えのように思えましたが、「ポリシー」でした）。
設計が悪いのではなく、10年前に設計したのではなく、今日設計した場合に設計が悪くなるということです。当時は良い設計であり、インフラストラクチャを実行するため、またシステム管理について何も知らない多くの人々にとっても、依然として機能します。
「いいね！」 2
おそらく、ルート権限が必要で、ローカルセットアップを想定していると思われる discourse-setup のような公式ツールに依存していないのでしょう。
discourse-setup のソースを確認してください。Discourse の設定やパフォーマンス調整に慣れている場合は必須ではありません。
Launcher は、結果の yml からイメージをビルドするためのすべての重労働を行います。
「いいね！」 2
すべて実行可能ですが、私には不必要な労力のように思えます。
- すべてのコマンドの前に
fakerootを使用する /varは YAML ファイルを編集することで変更できます:sed -i \"s;host: /var/discourse;host: $PWD/discourse;g\" containers/*.yml--skip-connection-test(スクリプトがリバースプロキシがある場合に接続をチェックできないため、コードを見て発見しました)- SSL オフロードは通常外部で行われるため、無効にする方法を理解する必要がある certbot に関連するものがいくつかあります。
- containers/app.yml のポートを変更して
>= 1024のポートを使用できるようにしますが、それだけでは不十分なようです:Error starting userland proxy: error while calling PortManager.AddPort(): cannot expose privileged port 443
意地悪なことを言いたいわけではありませんが、複数のサービスを単一のコンテナで実行することは、個々のサービスで何が起こっているのかを知る方法がほとんどない、Docker 外でカスタムログパーサーメカニズムを設定する必要がある、有用なヘルスチェックがない、外部データベースに簡単に依存できないなど、常に悪い設計でした。ビジネスで実行する唯一のサービスである場合は可能ですが、他のすべてのサービスがそのように開始すると、コンテナを使用するメリットのほとんどが失われます。
Discourse をルートアクセスなしで Docker 互換環境で動作させるための PR とドキュメントをいくつか提供できますが、サービスを分離して標準的なセットアップを行うことは、メインライン化される保証のない大きなタスクになります。
Discourse の根本的な構築方法に同意できない場合は、別の製品の使用を検討しましたか？
「いいね！」 3
はい、よくわかりました。
Discourse は、セルフホスト用のツールに関して強い意見を持っています。これにより、Discourse をデプロイしたい経験の少ない管理者に対して、効率的なサポートを提供できます。同意するかしないかは別として、私も以前は少し残念に思っていましたが、今はよく理解できます 
ほとんどの人が望むような、すぐに稼働させたいというニーズとは異なる場合、ほとんどの場合は自己責任となります。それを知っていれば、問題ありません
私たちもスタンドアロンの Discourse Docker イメージに対する同じニーズがあります。私たちはそれを MinIO を使用して Kubernetes 上で実行していますが、稼働させるのに少し苦労しましたし、今でもかなりの労力がかかっています。そのために Discourse からもいくつか良い助けを得ました。
私たちの作業はここで入手できます。
https://forge.liiib.re/indiehost/tech/infrastructure/charts/-/tree/master/discourse
（十分なドキュメントがなく、テストもされておらず、時間通りにメンテナンスまたは更新されておらず、おそらく少しカスタム化されていますが、それが現状です）
もし改善に興味がある方がいれば、遠慮なく PR を送ってください。または、ここでチャットしてください: https://matrix.to/#/#libresh:liiib.re
しかし、Discourse チームは Discourse コミュニティバージョンについて強い意見を持っています。同意するかしないかは別として、彼らはほとんどの人にサポートを提供しており、私が少し見た限りでは、それは素晴らしいサポートなので、良い決断だったと思います
「いいね！」 6
これらは、Discourse自体というよりは、Discourseのパッケージ化の根本的な側面です。Discourseは素晴らしいソフトウェアですが、おっしゃる通り、別のソリューションを検討すべきです。
「いいね！」 2
Postgres、Redis（SSLおよびLet’s Encryptも含む）のテンプレートは削除して、ご自身で作成したものを使用いただいて構いません。
「いいね！」 2
共有ありがとうございます。GitHub - literatecomputing/docker-compose-discourse: Launch Discourse with docker-compose and similar と bitnami のイメージも見つけました。主な問題は、これらのソリューションが公式にサポートされていないことです。コミュニティがサポートする代替の Docker セットアップを持つことは、さまざまなカスタム リポジトリを持つのではなく、効率が悪いため、複数の場所に労力を分散させることにならないため、良いアイデアになるのではないかと思います。
「いいね！」 1
おっしゃる通り、設定は変更できます。大きな労力なしで動作させることができれば、既存のツールやドキュメントを改善するために、例えばrootなしで実行できるようにするなどのPRを送ることを試してみます。それは開発チームの意見と一致するでしょうし、より要求の厳しいシステム管理者にとっていくらかの救済をもたらすでしょう。
9年後、idiomatic docker は bitnami の discourse でカバーされているように見えますか？
しかし、このフォーラムの他の場所では、メモリを大量に消費し、サポートされていないという主張があります。クラウドで実行しようとすると、標準的なセットアップでまだ多くの問題があることに驚きました。
最近の redis、postgres、s3互換ストレージなどの多くのサービスは、digitalocean、supabase、awsなどのさまざまなホスト間で簡単にセットアップおよび移動できるため、バックエンドはポータブルです。discourse を実行している vm も、決定論的なビルドで簡単にスケーリング/スワップできるはずです。この理想に非常に近いのに、それが妨げられているのは残念です。
他のユーザーが言ったように、これは驚くべきことです。
このスレッドの早い段階で言及された、これを容易にすることが商業的な機会を妨げる可能性があるというロジックは奇妙です。商業的な関心事は、複雑なビルドを処理するスタッフがいるため、これは誰よりもソロ開発者に影響を与えています。私の個人的なユースケースは、非常に大規模な（非営利の）コミュニティを運営していることです。したがって、規模によるホビイストや収益による商業には該当しません。
「いいね！」 1
うーん、フォーラム/コミュニティボードを設置することを考えていて、もちろんDiscourseを使うことを考えました（エンドユーザーエクスペリエンスが好きなので）、しかしまたしても完全に敵対的なインストール/管理という壁にぶつかりました…
長年、簡単なdocker-composeファイルで全てを実行し、いくつかの追加要素（データベース、S3互換ストレージ用のminioなど）を投入することに非常に愛着を持ってきましたが、いや…Discourseはこの場合、依然として非常に敵対的です。
何かくだらない「ランチャー」で起動するのは、すみませんが許せません。
そして、アップグレードプロセスで次のように述べられています。
新しいベースイメージを手動で実行して作成します:
./launcher rebuild my_image
すみません - イメージを手動で再構築する？マジで何なの…それはdockerを使っているようで、実際には使っていないようなものです…
./launcher rebuild app は動作しますか？それがいつものコマンドです。
また、標準のインストールガイドに従いましたか？
建設的なコメントはありませんが、Mastodonサーバー、Pixelfed、Moodleなどをアップグレードしてみてください。Discourseは信じられないほど簡単です。
1つの手動コマンドが障害となります😳
「いいね！」 2