こんにちは！
最新のアップデート後、なぜインストールが CDN からアセットを提供しなくなったのか、理由がわかりません。CloudFront を使用しており、アップロードとアセットの両方を正常に提供できていたのですが、最新のアップデートではアセットがサーバーから提供されているようです。
もう一つ問題があります。DISCOURSE_CDN_URL 変数を渡すと、Discourse が s3:upload_assets タスクによって生成またはアップロードされていないアセット（例えばスタイルシートなど）を要求し始めます。これにより、サイトが完全に壊れ、白いページが表示されてしまいます。この投稿で同様のことが言及されています。
ご協力いただけますと幸いです。
よろしくお願いいたします！
@falco さん、これは新しいバグでしょうか？何か壊してしまったのでしょうか？
@eatcodetravel 何かお手伝いするためには、もっと詳細な情報が必要です。
S3 および CDN に関連する設定と環境変数の正確な値は何ですか？
@Falco もちろんです、どのような情報が必要ですか？当社のセットアップはオープンソースで、現在使用している設定は以下の通りです。
DISCOURSE_CDN_URL を削除しました。これは DISCOURSE_S3_CDN_URL と同じ値に設定されていましたが、サイトが破損していました（存在しないアセットを S3 から取得しようとしていたため）。
以前問題を抱えていたサイトを振り返ってみると、使用していたCDNのURLからhttps://を省略していたようです。なぜそれが以前は機能していたのか、あるいは一度も機能していなかったとしたら、壊れた値を追加した際にどうして気づかなかったのかがよくわかりません。
@eatcodetravel、もちろんSMTPのパスワードやS3のキーは伏せる必要がありますが、問題の原因を特定してもらうためには、少なくともCDNの値を共有する必要があると思います。
はい、ここに書きますね。他の設定は AWS SDK で検証されるので、CDN_URL だけだと思います。
DISCOURSE_S3_CDN_URL: 'https://community-cdn-prod.debtcollective.org'
DISCOURSE_S3_REGION: 'us-west-1'
DISCOURSE_CDN_URL も以前は ‘https://community-cdn-prod.debtcollective.org’ に設定されていました。私が削除する前です。
私たちのセットアップで大きな変更はありません。単により大きな EC2 インスタンスに移行しただけです。
@Falco さん、さらに情報が必要でしたらお知らせください。喜んでご質問にお答えします。
現在、通常の CDN ではなく S3 CDN を使用しているようですね。この構成がサポートされているかどうかわかりません。
他の 3 つの組み合わせは問題なく動作します：
DISCOURSE_CDN_URL のみDISCOURSE_CDN_URL と DISCOURSE_S3_CDN_URL の両方それが過去に私が経験した他のCDNの問題を説明しているかもしれません。
はい、DISCOURSE_CDN_URL を削除せざるを得ませんでした。rake s3:upload_assets タスクによって S3 にアップロードされていないアセットの要求が始まり、サイトが完全に機能しなくなったのです。もしかすると、ここが変更された部分で、rake s3:upload_assets を再度正しく動作するように更新する必要があるかもしれません。
はい、DISCOURSE_CDN_URL と DISCOURSE_S3_CDN_URL の両方に同じ CDN URL を使用することは可能ですが、各アセットの URL に基づいて正しいソースを選択するために、CDN 側で大量のログイン設定を行う必要があります。例えば、CSS はアプリから、JS は S3 から取得するなど、これは一例に過ぎず、実際には数十ものケースがあります。
そのため、DISCOURSE_CDN_URL を Web アプリへの「プロキシ」、DISCOURSE_S3_CDN_URL をオブジェクトストレージバケットへのプロキシとして設定することが期待されます。
ああ、わかりました。これは最近変更されたことでしょうか？CloudFront が S3 バケットの代わりに、当社のアプリのリバースプロキシとして機能するかどうかはわかりません。
メタで CloudFront を使用されているようですが、何か特別な設定が必要でしょうか、それとも Discourse 自体がすべてを処理するのでしょうか？
このページを検証すると、2 つの異なる Cloudfront URL が存在することがわかります。そのため、前述の通り、2 つのディストリビューションを使用しています。1 つは通常の CDN 用、もう 1 つは S3 用です。
タイトルにある OP の問題は次の通りです。CSS はアプリから、JS は S3 から提供されます。すべてのアセットがどこから来ているかを認識し、必要な場所にアクセスできる CDN、あるいは 2 つの CDN が必要です。だからこそ、結局のところ 2 つの異なる設定が必要になるのです。
理解できた今では完全に納得できますが、これがドキュメント化されているかどうかはわかりません。また、少なくとも私はそうだったのですが、トラブルに巻き込まれる可能性が高いです。なぜなら、move-uploads-to-s3 の rake タスクには s3_cdn の設定が必須だからです。これが、S3 への移行を試みて何度も諦めてしまった理由です。
「S3 CDN を設定する場合は、必ずアセット CDN も設定してください」といった警告があれば、とても親切だと思いました。
わかりました、ご説明ありがとうございます。これが必須とは知りませんでした。なぜ CSS がアプリから提供される必要があるのでしょうか？rake s3:upload_assets タスクでアップロードできないのでしょうか？
CloudFront でこれを達成する方法について調査し、その結果や課題をここにまとめます。
@Falco さん、とても助かりました。ありがとうございます。
いや、私の説明が下手だったかもしれません。可能です。ただし、このスレッドや他のトピックでも示されているように、設定が面倒です。
@eatcodetravel さんのサイトは現在、S3_CDN だけを設定して動作していますが、その場合、レンダリングをブロックする CSS が自サーバーから提供される一方、投稿内の画像はそうではないという奇妙な状態になります。これは理にかなっていません。
「管理 > カスタマイズ」機能があるからです。管理者パネルで CSS を変更できるようになっています。また、テーマに埋め込まれたカスタム JS スニペットも、私の知る限りアプリから提供されます。
@falco さん、これをよりよく文書化する方法はありませんか？もしかしたら「ここにはドラゴンが住んでいます」というような形で？
結局、Web サーバを指す 2 番目の CloudFront ディストリビューションを追加し、もう一方は S3 のみで使用するようにすることでこの問題を解決しました。@Falco さんからのフィードバックに感謝しますが、これはもう少し明確にドキュメント化されるべきだと思います。