こんにちは。
S3へのアップロードを設定しようとしていますが、アップロードは正常に機能しているようですが、GETリクエストが奇妙な理由で失敗しています。DiscourseがアップロードされたオブジェクトのURIに「.cn」を追加しているようです。
S3バケットに画像をアップロードした後、公開URLは次のようになります。
https://hobig...bucket-eu.s3.eu-central-1.amazonaws.com/original/1X/5e894113...48918.jpeg
しかし、ブラウザで確認すると、Discourseフォーラムは（「.cn」に注意してください）をロードしようとしています。
https://hobig...bucket-eu.s3.eu-central-1.amazonaws.com.cn/original/1X/5e894113...48918.jpeg
これがなぜ起こるのか、誰か知っていますか？
以下は私の管理者設定です。
アップロード用のS3互換オブジェクトストレージプロバイダーの設定方法に関するこちらおよび/またはこちらの指示に従い、それらの設定をデータベース/UXではなく、ymlファイルに記述してください。
AWSのエンドポイントを設定する必要はありません。CDNは設定したいはずです。
@pfaffman様
同じガイドを誤って2回貼り付けた可能性があるようです。
「ymlファイルの設定」について言及されている場合、どのYAMLファイルについて話しているのか明確にしていただけますか？ もしかして、/var/discourse/containers フォルダにある app.yml ファイルのことでしょうか？
また、S3/CloudFront連携をYAMLファイルで直接設定した場合、Discourseの管理画面で設定した内容よりも優先されますか？
よろしくお願いいたします。
すみません。どちらか一方は Set up file and image uploads to S3 になるはずでした。
S3の設定方法を説明している関連トピックを参照してください。ただし、web_only.ymlに言及されていないため、変更したいのはapp.ymlです。
はい。YAMLファイルに入力すると、UXから非表示になります。
こんにちは @pfaffman さん、
S3バケット、CloudFrontの設定、そしてCloudFrontのオリジンをS3バケットに設定しました。現在のapp.ymlの設定は以下の通りです。
ENV:
DISCOURSE_USE_S3: true
DISCOURSE_S3_REGION: eu-central-1
DISCOURSE_S3_ACCESS_KEY_ID: AKIAWPLPUxxxxxx
DISCOURSE_S3_SECRET_ACCESS_KEY: PaXQu7pKxxxx
DISCOURSE_S3_CDN_URL: https://dsuxxxhrz2qn.cloudfront.net
DISCOURSE_S3_BUCKET: hobigxxxxbucket-eu
./launcher rebuild app でアプリを再構築した後、ウェブサイトにアクセスすると、ローダーが表示されるだけで何も読み込まれません。ネットワークタブを調べたところ、プリコンパイルされた静的アセット（主に.js）を取得できないことがわかりました。これは、それらがS3バケットにないためだと推測しています。こちらで確認できます：forum.hobiguru.com。
移行用のrakeタスクも実行してみましたが、効果はありませんでした。
root@ubuntu-s-1vcpu-1gb-fra1-01-app:/var/www/discourse# rake uploads:migrate_to_s3 --trace
** Invoke uploads:migrate_to_s3 (first_time)
** Invoke environment (first_time)
** Execute environment
** Execute uploads:migrate_to_s3
S3への移行は現在元に戻せません。ご注意ください！
[CTRL+c] でキャンセル、[ENTER] で続行
'default' のアップロードをS3に移行中...
一部のアップロードは新しいスキームに移行されませんでした。手動で修正する必要があります...
rake aborted!
FileStore::ToS3MigrationError: 一部のアップロードは新しいスキームに移行できませんでした。手動で修正する必要があります。(FileStore::ToS3MigrationError)
/var/www/discourse/lib/file_store/to_s3_migration.rb:156:in `migrate_to_s3'
/var/www/discourse/lib/file_store/to_s3_migration.rb:59:in `migrate'
/var/www/discourse/lib/tasks/uploads.rake:126:in `migrate_to_s3'
/var/www/discourse/lib/tasks/uploads.rake:106:in `block in migrate_to_s3_all_sites'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/rails_multisite-6.1.0/lib/rails_multisite/connection_management/null_instance.rb:49:in `with_connection'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/rails_multisite-6.1.0/lib/rails_multisite/connection_management/null_instance.rb:36:in `each_connection'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/rails_multisite-6.1.0/lib/rails_multisite/connection_management.rb:21:in `each_connection'
/var/www/discourse/lib/tasks/uploads.rake:104:in `migrate_to_s3_all_sites'
/var/www/discourse/lib/tasks/uploads.rake:100:in `block in <main>'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/rake-13.2.1/lib/rake/task.rb:281:in `block in execute'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/rake-13.2.1/lib/rake/task.rb:281:in `each'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/rake-13.2.1/lib/rake/task.rb:281:in `execute'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/rake-13.2.1/lib/rake/task.rb:219:in `block in invoke_with_call_chain'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/rake-13.2.1/lib/rake/task.rb:199:in `synchronize'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/rake-13.2.1/lib/rake/task.rb:199:in `invoke_with_call_chain'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/rake-13.2.1/lib/rake/task.rb:188:in `invoke'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/rake-13.2.1/lib/rake/application.rb:188:in `invoke_task'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/rake-13.2.1/lib/rake/application.rb:138:in `block (2 levels) in top_level'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/rake-13.2.1/lib/rake/application.rb:138:in `each'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/rake-13.2.1/lib/rake/application.rb:138:in `block in top_level'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/rake-13.2.1/lib/rake/application.rb:147:in `run_with_threads'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/rake-13.2.1/lib/rake/application.rb:132:in `top_level'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/rake-13.2.1/lib/rake/application.rb:83:in `block in run'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/rake-13.2.1/lib/rake/application.rb:214:in `standard_exception_handling'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/rake-13.2.1/lib/rake/application.rb:80:in `run'
bin/rake:13:in `<top (required)>'
/usr/local/lib/ruby/gems/3.3.0/gems/bundler-2.5.18/lib/bundler/cli/exec.rb:58:in `load'
/usr/local/lib/ruby/gems/3.3.0/gems/bundler-2.5.18/lib/bundler/cli/exec.rb:58:in `kernel_load'
/usr/local/lib/ruby/gems/3.3.0/gems/bundler-2.5.18/lib/bundler/cli/exec.rb:23:in `run'
/usr/local/lib/ruby/gems/3.3.0/gems/bundler-2.5.18/lib/bundler/cli.rb:455:in `exec'
/usr/local/lib/ruby/gems/3.3.0/gems/bundler-2.5.18/lib/bundler/vendor/thor/lib/thor/command.rb:28:in `run'
/usr/local/lib/ruby/gems/3.3.0/gems/bundler-2.5.18/lib/bundler/vendor/thor/lib/thor/invocation.rb:127:in `invoke_command'
/usr/local/lib/ruby/gems/3.3.0/gems/bundler-2.5.18/lib/bundler/vendor/thor/lib/thor.rb:527:in `dispatch'
/usr/local/lib/ruby/gems/3.3.0/gems/bundler-2.5.18/lib/bundler/cli.rb:35:in `dispatch'
/usr/local/lib/ruby/gems/3.3.0/gems/bundler-2.5.18/lib/bundler/vendor/thor/lib/thor/base.rb:584:in `start'
/usr/local/lib/ruby/gems/3.3.0/gems/bundler-2.5.18/lib/bundler/cli.rb:29:in `start'
/usr/local/lib/ruby/gems/3.3.0/gems/bundler-2.5.18/exe/bundle:28:in `block in <top (required)>'
/usr/local/lib/ruby/gems/3.3.0/gems/bundler-2.5.18/lib/bundler/friendly_errors.rb:117:in `with_friendly_errors'
/usr/local/lib/ruby/gems/3.3.0/gems/bundler-2.5.18/exe/bundle:20:in `<top (required)>'
/usr/local/bin/bundle:25:in `load'
当初の目的は、ユーザーのアップロードのみをS3に保存し、CDNはその処理のみを行うことでした。しかし、現在、アプリの静的アセットも意図せずCDN経由で提供されています。
アプリ起動時にすべての静的アセットをS3バケットにアップロードし、その後CDN経由で提供する方法はありますか？それとも、ユーザーのアップロードのみをCDN経由で提供する方法はありますか？あるいは、もっと良い解決策はありますか？
何か明白なことを見落としているのでしょうか？わかりません。
ご協力ありがとうございます！
指示に従わなかったためだと思います。
はい、承知しております。それは可能ですが、うまくいかなかったようですね。こちらが推奨される方法であり、十分に文書化されており、何百人もの人々がこの方法で行っています。
申し訳ありません、おっしゃる通りです。その部分を省略していました。app.ymlに以下を追加したところ、フォーラムは正しく読み込まれるようになりました。
after_assets_precompile:
- exec:
cd: $home
cmd:
- sudo -E -u discourse bundle exec rake s3:upload_assets
- sudo -E -u discourse bundle exec rake s3:expire_missing_assets
それでも、ユーザーのアップロードはまだ正しく機能していません。S3バケットへのアップロード（正しく）の後、画像は次のように提供されます。
//my-bucket-eu.my-bucket-eu/original/1X/7f242572bdb45b65ded727c13366fe490541358f.jpeg
これはもちろん、有効なS3またはCDNパスではありません。
あなたが参照したガイドには、関連性がありそうな次のセクションがあります。
DISCOURSE_CDN_URL は、Discourse ホスト名を指し、リクエストをキャッシュする CDN です。主にプル可能なアセット（CSS やその他のテーマアセット）に使用されます。
DISCOURSE_S3_CDN_URL は、オブジェクトストレージバケットを指し、リクエストをキャッシュする CDN です。主にプッシュ可能なアセット（JS、画像、ユーザーアップロード）に使用されます。
これらは異なる設定にし、管理者が両方を設定することをお勧めします。
しかし、DISCOURSE_CDN_URLに何を設定すればよいか分かりません。DISCOURSE_S3_CDN_URL: https://dsxxxxx2qn.cloudfront.netと同じ値を設定すべきでしょうか、それとも別のCDNインスタンスを作成する必要がありますか？
あるいは、全く別の問題かもしれません
ご協力いただき、誠にありがとうございます！
CDNを設定し、AWS側で希望のドメインを使用する必要があります。DNSでも同様です。
しかし、なぜでしょうか？ 実際にそのURLを見る人はほとんどいません。
ジェイクさん、おっしゃっている意味がよく理解できません。もう少し詳しく説明していただけますか？
CDNのオリジンとしてS3バケットを設定する代わりに、forum.hobiguru.comドメインをオリジンとして設定すべきということでしょうか？もしそうであれば、ディスコースフォーラムがどこにも繋がらないURLを生成しているため、例えば //my-bucket-eu.my-bucket-eu/original/1X/7f242572bdb45b65ded727c13366fe490541358f.jpeg のようなURLが生成されるため、何も変わらないと思います。
DISCOURSE_CDN_URL: https://dsuxuxhrz2qn.cloudfront.net も追加し、アプリの再構築を待っています 
更新：いいえ、これも機能しませんでした
ご協力に心より感謝いたします。
ありがとうございます。
サブドメインは app.yml で名前を付けることはできません。適切なDNS情報なしでは誰も使用できません。また、ファイルの提供はAWSから行われるため、CDNを使用したい場合はそちら側も設定する必要があります。
しかし、繰り返しますが、ユーザーはDiscourseのURLを見ます。管理者以外が何かをしたい場合、それを見ることはほとんどありません。そして、ユーザーはメディアやその他の静的ファイルのURLを実際に見ることはありません。
したがって、CDNを使用しないのであれば、無駄な時間を浪費しているというのが私の見解です。グローバルなオーディエンスがいて、その一部が接続状態の悪い国にいる場合は、それが賢明かもしれません。
私はフィンランドに住んでいます。世界の反対側、オーストラリアにあるサイトがCDN（私から1000km離れた場所にあるサーバーから）を使用しても、私は何のメリットも得られません。本当のボトルネックは、サイトがどのように構築されているか、例えば十分なリソースなしで不要なPHP呼び出しがたくさん使用されているか、ということです。
しかし、基本的に、DNSに少なくとも cdn を設定しない限り、cdn.example.tld というURLを使用することはできません。
こんにちは @Jagster さん
実際には、CDNは全く使用したくありません。ユーザーのアップロードはすべてS3に保存し、そこから直接提供したいのです。CloudFrontはS3を直接使用するよりも確かに良いソリューションですが。
問題が発生したのはS3（特にアセットの提供用で、アップロード用ではありません）の設定を試みたときで、@pfaffman さんがアップロード用のS3互換オブジェクトストレージプロバイダーの設定ガイドに従ってCDNを設定するように提案しました。
あなたのコメントについて：
「サブドメインの名前はapp.ymlでのみ設定することはできません。適切なDNS情報なしでは誰も使用できません。そして、ファイルの提供はAWSから行われるため、CDNを使用したい場合は、AWS側も設定する必要があります。」
申し訳ありませんが、この段落で何を意味しているのかよく理解できませんでした。もう少し詳しく説明していただけますか、あるいは明確にしていただけますか？S3バケットのDNSレコードを設定する必要があるということですか、それともAWS側で調整する必要がある特別なことがあるということですか？
よろしくお願いします！
こんにちは、皆さん
以前の投稿のフォローアップとして、進捗があったことを共有したいと思います。
現在機能していること
ただし、プリコンパイル済みアセットの問題がまだ残っています
プリコンパイル済みアセットは、CDNから正しく提供されていません。
DISCOURSE_CDN_URL をCloudFront URL（例：https://dsuqioxhrz2qn.cloudfront.net）に設定すると、プリコンパイル済みアセットのURLは次のようになります。
https://dsuqioxhrz2qn.cloudfront.net/stylesheets/color_definitions_shades-of-blue_7_1_e6f11758f9c015d1e5ed9b08c437e9c5c267c932.css?__ws=forum.hobiguru.comhttps://dsuqioxhrz2qn.cloudfront.net/stylesheets/discourse-presence_308d905aa5c03567866fec50e9a28d8721ab0463.css問題は、これらのパスが私のS3バケットに存在しないことです。プリコンパイル済みアセットはS3の /assets/* フォルダ（例：/assets/locales、/assets/plugins、/assets/scripts）にアップロードされますが、/stylesheets/ フォルダはありません。そのため、これらのURLの読み込みは403 Forbiddenエラーになります。
一方、DISCOURSE_CDN_URL: https://forum.hobiguru.com に変更すると、フォーラムは正しく機能しますが、アセットはCDNではなくサーバーから提供されます（例：https://forum.hobiguru.com/stylesheets/admin_308d905aa5c03567866fec50e9a28d8721ab0463.css?__ws=forum.hobiguru.com）。
現在のセットアップ（参考用）は次のとおりです。
app.yaml
DISCOURSE_USE_S3: true
DISCOURSE_S3_REGION: eu-central-1
DISCOURSE_S3_ACCESS_KEY_ID: AKIA......LQMB
DISCOURSE_S3_SECRET_ACCESS_KEY: PaXQu7pKN.....fJNY
DISCOURSE_S3_BUCKET: hobiguru-s3-bucket-eu
DISCOURSE_CDN_URL: https://dsuqioxhrz2qn.cloudfront.net # CDN URLがCloudFrontを指していることを確認
DISCOURSE_CDN_URL: https://forum.hobigur.com # これに注意！
プリコンパイルフック：
hooks:
after_assets_precompile:
- exec:
cd: $home
cmd:
- sudo -E -u discourse bundle exec rake s3:upload_assets
- sudo -E -u discourse bundle exec rake s3:expire_missing_assets
アセットをプリコンパイルした後、特定の構造でS3にアップロードされるようですが、CDN経由でロードされる際にオブジェクトへのパスが少しずれているようです。