同感です。来週、@falco さん、ランチャー側でこの問題について警告を出すか、あるいはブロックするように変更することは可能でしょうか？
私も同じ問題に直面しています。yml ファイルを正確に何に名前変更する必要があるのか、詳しく教えていただけますか？
TLD（トップレベルドメイン）とサブドメインを yml ファイル名の一部に含める必要がありますか？このサイトの場合、meta.discourse.org.yml ということでしょうか？
meta_discourse_org.yml に名前を変更してください。
ファイル名にあるドット（.）は拡張子の前にある必要があります。
ご clarification ありがとうございます。ファイル名を変更して再構築しましたが、どの画像でもライトボックスやホバーでキャプションが表示されないままです。
どのログファイルのことでしょうか？同じ問題かどうか確認したいのです。
また、「サイトを HTTPS のみで強制する」が有効で、ファイアウォールでポート 80 がブロックされています。
cd /var/discourse
./launcher enter app
tail -f /shared/log/rails/production.log
Discourse のログに関する記事もご覧ください。
既存の投稿のみで問題が発生し、新しく投稿された画像は正常に表示される場合、以下のコマンドを実行することで解決することがあります。
rake uploads:recover_from_tombstone
rake posts:rebake
こちらもご覧ください。
とても役立ちました、ありがとうございます。
同じエラー「can’t reach '/uploads/default…」が発生しているようです。
ログファイルの次の行は以下の通りです。
Started GET "/posts/950" for 127.0.0.1 at 2020-07-07 08:24:05 +0000
なぜ私の環境では、新しく名前付けられたコンテナやコンテナのローカル IP ではなく、ループバック IP を経由しようとしているのか、原因がわかる方がいらっしゃいますか？
これは、以下の条件を同時に満たす非標準的なインストール環境に特有の問題のようです：
-
./discourse-setupを使用せず、yml ファイルを手動で作成した -
リバースプロキシを使用している
-
そのリバースプロキシが、Docker コンテナ名を使って魔法のように設定されている
この端境例に対処するために、全員に対して現在の決定論的なコンテナ名を変更するのはお勧めしません。ただし、yml ファイル名に単にドットを一つ追加するだけで同様の問題が発生する可能性がある場合は別です。
私は実際にそれを使用しましたが、2 つの Discourse インスタンスを同時に実行しているため、同じ Docker インスタンス内で両方が「app」と呼ばれてしまうのを避けるために、後でファイル名を変更しました。
使用しているドメインに合わせてファイルを有効に戻すのは合理的だと思います。
小規模なコミュニティで 1 つのサーバー上で複数のサイトを運用するのは、おそらく非常に一般的なことです。
名前に関する問題を引き起こしたのはリバースプロキシではなく、Docker 自体です。Docker は自動的にコンテナ名を内部 DNS に追加するためです。問題は、Docker 内の Discourse コンテナ名が、外部 DNS 名と同じだったことです（例：app.yml → meta.discourse.org.yml）。
.yml ファイル内でファイル名が指定されたドメイン名と一致する場合、少なくとも強い警告を表示することを提案します。
画像の寸法を取得するために画像にアクセスできないという問題が、まだ解決していません。
‘/uploads/default/original/1X/9385b0977b09b0f2239c287de980b6fc238d0da0.png’ にアクセスできず、寸法を取得できません。
これは ./discourse-setup を使用した完全な標準インストールでの発生です。
この問題を解決するための他のアイデアはありますか？
Discourse アプリ内で画像のダウンロードを試みるとどうなりますか？
./launcher enter app
wget https://yourdomain.com/uploads/default/original/1X/9385b0977b09b0f2239c287de980b6fc238d0da0.png
名前解決は正しい IP アドレスを指していますか？
apt-get update
apt-get install inetutils-ping
ping yourdiscoursedomain.com
または
apt-get update
apt-get install dnsutils
nslookup yourdiscoursedomain.com
Michael、改めてご協力をいただきありがとうございます。大変感謝しています。
ドメインへの ping は成功していますが、wget が Web プロキシ経由でアクセスしようとしているようです。
こちらのガイドに従い、no-proxy 変数をすべての関連する場所に追加しました。
何か見落としているでしょうか？サーバーが使用している Web プロキシを使わずにコンテナを設定するにはどうすればよいですか？app.yml に no-proxy を追加する必要がありますか？
app.yml ファイルの no-proxy パラメータにドメインを追加し、ビルドし直したところ、必要な通りプロキシを無視するようになりました。
しかし、アプリ内から wget を実行すると、まだエラーが発生します。
WARNING: The certificate of ‘MYDOMAIN.com’ is not trusted.
WARNING: The certificate of ‘MYDOMAIN.com’ doesn’t have a known issuer.
これは、私の SSL 証明書が内部 CA からのものだからです。同じ wget コマンドに --no-check-certificate フラグを付けて実行すると、問題なく動作します。
証明書を信頼するように追加する方法か、チェックを行わないフラグを追加する方法を教えてください。
@Michael_Uray DiscourseコンテナがSSL証明書を信頼できるように、ルートCAをどこに追加すればよいかご存知ですか。
こちらのガイドに従いましたが、これはサーバー自体に適用されるものであり、Discourseを実行しているコンテナには適用されないと思います。
リバースプロキシを使用しない場合は、必ずコンテナ内部に入り、そこで追加する必要があります。ただし、この方法では永続化されないと思います。app.yml に何らかの形で追加するか、または app.yml を介してコンテナ内の適切な CA パスを永続化する方法が必要ではないでしょうか。