Dockerイメージ discourse/discourse は安全で本番環境対応とみなされますか?

こんにちは!
助けをしてくれた皆さん、特に @featheredtoast さんに感謝の意を表したくて、あえて登録しました。
ほぼ動作するところまでいったのですが、メール送信が機能しませんでした。
Caddy をリバースプロキシとして使用していることが原因だと思われます。

そのため、現在は Docker Compose 環境内の他のサービスとは別に Discourse を使用しています。

Caddy と連携させる方法をご存知でしょうか?ソケット経由の例を使用する必要があると思うのですが、Docker Compose の Discourse 設定内の app.yml をどのように修正すればよいかわかりません。

よろしくお願いいたします - Y

Caddy が送信するメール自体をプロキシしているわけではない限り、それは関係ないと思います。

ソケット経由にする必要はありません。Docker の名前や IP アドレスを直接参照すれば大丈夫です。Discourse working with jwilder /nginx proxy & acme-companion - #7 by Steve_Emerson には、ソケットテンプレートを使用する方法やその他の詳細について記載されています。

結論から言うと、docker-compose 単体ではできません。これは実現してほしい機能ですが、現在の計画では、誰でもカスタマイズしたベースイメージを作成し、それを公開してコミュニティの発展に貢献できるようにすることを目指しています。プラグインの構築には、プラグインのクローン取得、bundle install、npm の実行、そして Ember の再コンパイルが必要です。これらを起動時に行うべきではありません。

そのため、このアプローチの目的の一つは、discourse/discourse と同様に、サポートされている Discourse バージョンと同じ app.yml を使用してイメージを構築できるようにすることです。

サンプルとして、私は個人的なイメージを resenha を使って構築しています。これは、コアの app.yml を更新してプラグインを含める こちら の設定を行い、その後、外部(公開!)の Docker レジストリにプッシュするものです。

外部メールサービスを使用している場合、Caddy リバースプロキシが問題である可能性は低いと思います。現在のランチャービルドとは異なり、discourse/discourse はメール環境変数の設定について促すことはありません(ただし、設定は依然として必須です)。まずはそれらを確認することをお勧めします。

アップロードサイズの制限を変更することに成功しました:

cat fix-upload-size.shchmod +x が必要です):

#!/bin/sh
sed -i 's/client_max_body_size .*;/client_max_body_size 500m;/' /etc/nginx/conf.d/discourse.conf

docker-compose.yml 内:

    volumes:
     - ./fix-upload-size.sh:/etc/runit/1.d/fix-upload-size

ESRバージョンのみを使用して、イメージをビルドすることができました。それより新しいバージョンを使用すると、ビルドプロセスにデータベースとRedisインスタンスが必要になります。これは意図的なものですか?

このイメージを使用している場合、Discourseを最新バージョンにアップグレードする方法はありますか?

私は学部の研究グループのフォーラムでこれを使用しており、最新のDiscourseリリースに更新したいと考えています。しかし、このイメージは3月以来更新されていません。アップグレードの推奨方法はどのようなものでしょうか?

それは、停滞した Web アップグレードのクリアを呼び出す処理を追加した際の意図しない副作用でした。これは FIX: run clear_stuck_web_upgrades during precompile stage · Pull Request #1055 · discourse/discourse_docker を通じて近日中に解決する予定です。

素晴らしい、ありがとうございます!

ただ、もう一つ質問があります。私は「Azure for Students」を利用しており、Container Apps を使っています。アプリ内で何かしらのアップグレードを行っても、Discourse が動作しているインスタンスが何らかの原因で失敗した場合、フォラムが混乱するのではないかと心配です。なぜなら、再起動した際に前のバージョンに戻ってしまう可能性があるからです。

重ねてお礼申し上げます!

それはリスクです。アプリ内でアップグレードするだけでなく、Docker リポジトリからイメージをプルして更新する場合、イメージが最新であることを確認する以外に、回避策はありません。そのような方法は、強くお勧めしません。

それまでの間、私はまだ Docker リポジトリの整理を進めています(ここで解決すべき別の問題もあります)。