Contabo S3のサポート/互換性は追加されますか？それとも、誰かが動作させるための回避策を見つけましたか？
「いいね！」 2
私たち、Discourse のメンテナーは、AWS S3 のみをサポートしています。ここにリストされているプロバイダーは、Discourse と互換性があるかどうか、S3 API の十分な実装があるかどうかを、私たちまたはコミュニティによってテストされました。
OP によると、@tuxed は Contabo をテストし、不十分であると判断しました。Contabo がビジネス上の利益に合致すると判断した場合、S3 への準拠を実装を改善するのは Contabo の責任であり、私たちが行えることではありません。
「いいね！」 4
これはまだバグがありますか？なぜDigitalocean CDNは良くないのですか？
「いいね！」 1
リンクをたどりましたか？
CDNはメタデータについて知らないようです。しかし、試してみて、それが機能するかどうかを確認することができます！もし試したら教えてください。ちょうど先日、それが修正されたかどうか疑問に思っていました。ドキュメントを見た限りでは、すぐに自分で試すつもりはありません。
「いいね！」 2
DigitalOcean上のフォーラムにCDNサポートを追加する簡単な方法を探しています。S3の方が簡単なら、そちらのオプションを選択します。
うまく機能しないことがわかっているセットアップでリスクを冒したくありません。
「いいね！」 2
推奨される解決策は、CDNを使用しないことです。上記の手順に従えば、SpacesやCDNとしてbunny.netのようなものを使用できます。安価で簡単です。
AWS S3はcdckが使用しているものであり、よりテストされサポートされていますが、AWSに慣れていない限り、Spacesバケットは良い解決策です。DigitalOceanのCDNは使用しないでください。
「いいね！」 2
これを経験したばかりです。CDNの設定、当面は画像をローカルに保持します。最初はFastlyで、次に別のものを思い出せません。Bunny.netに落ち着きました。セットアップは非常に簡単です。Discourseに特化したハウツーがあります。私たちはDOでセルフホストしており、100GB以上の画像があります。キャッシュヒット率は65%で、上昇中です。
「いいね！」 2
s3 の墓石ポリシーの設定は aws.amazon のみで機能しますか？
「いいね！」 1
いいえ、問題はBackblazeのみにあります。
「いいね！」 2
3件の投稿が新しいトピックに分割されました：ユーザープロフィール画像のアップロード問題の解決策を探る
ふぅ、どこから始めればいいのか？CloudflareをキャッシュとDNSに、Backblaze B2をストレージに使用しています。なんとか動作させることはできましたが、部分的にしか機能しませんでした。./launcher rebuild appを実行した際にアセットがアップロードされているのを見て、正常に動作しているように見えたので非常に興奮しました。リビルドが正常に完了した後、サイトにアクセスできなくなりました。ページの中央に動くドットが表示されるだけです。
Backblazeの記事「Deliver Public Backblaze B2 Content Through Cloudflare CDN」に基づき、Friendly URLオリジン f000.backblazeb2.com を指すプロキシされたCNAMEレコードを gtech-cdn という名前で設定しました。
CNAME gtech-cdn → f000.backblazeb2.com
記事ではPage Rulesについても言及されていますが、オンオフを切り替えてみても効果はありませんでした。
以下は関連する設定項目です。
DISCOURSE_HOSTNAME: mmhmm.com
DISCOURSE_CDN_URL: https://mmhmm.com
DISCOURSE_USE_S3: true
DISCOURSE_S3_REGION: us-west-000
DISCOURSE_S3_ENDPOINT: https://s3.us-west-000.backblazeb2.com
DISCOURSE_S3_ACCESS_KEY_ID: <secret>
DISCOURSE_S3_SECRET_ACCESS_KEY: <secret>
DISCOURSE_S3_CDN_URL: https://gtech-cdn.mmhmm.com
DISCOURSE_S3_BUCKET: gtech-uploads
DISCOURSE_S3_BACKUP_BUCKET: gtech-uploads/backups
DISCOURSE_BACKUP_LOCATION: s3
**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
私を混乱させていることの一つは、DISCOURSE_S3_CDN_URL と DISCOURSE_CDN_URL の2つの変数に何を設定すべきかということです。提供した情報に基づいて、正しく設定されていますか？
ブラウザの開発者ツールのコンソールを見ると、.js スクリプトで404エラーが発生しています。URLが正しく構築されていないようです。/assets の前に /file/<bucketname> が含まれているべきではないでしょうか？手動で追加して正しいURLを作成すると、機能します。
https://gtech-cdn.mmhmm.com/file/gtech-uploads/assets/google-universal-analytics-v4-e154af4adb3c483a3aba7f9a7229b8881cdc5cf369290923d965a2ad30163ae8.br.js
どんな助けでも感謝します！
「いいね！」 1
https://gtech-cdn.mmhmm.com が解決しないので、まずそれを修正する必要があります。
Cloudflare を CDN としてそのように使用できるかどうかわかりませんが、間違っているかもしれません。
「いいね！」 1
申し訳ありませんが、mmhmm.com は偽のドメインであることを言及すべきでした。ping には応答します。
Cloudflare を CDN として使用できないことについては、理解できていないようです。私がリンクした記事では、CDN として使用する方法が明確に説明されています。それが真実でない場合、DISCOURSE_S3_CDN_URL と DISCOURSE_CDN_URL の 2 つの変数にはどのような値を使用すればよいのでしょうか？
よろしくお願いいたします。
偽のURLを提供した場合、偽の回答しか得られません。
URLは期待されるデータを配信していますか？フォーラムのURLから取得できますか？
S3 CDNは機能するはずだと思います。フォーラムのCDNにはフォーラムのURLを使用していますが、確信が持てません。
通常のCDNはフォーラムとは異なるURLであり、CDNは動的なものを推測する必要があるのではなく、静的なデータであることを期待できます。
「いいね！」 1
私は情報を様々なフォーラムに貼り付けないように最善を尽くしているので、この件に関する私の秘密主義についてはご容赦ください。
フォーラムは「https://mmhmm.com」にあり、これはプロキシ（キャッシュ）されたCloudflare DNSレコードです。DiscourseでBackblazeを使用するように設定する前は、すべて正常に機能していました。
前述のように、「https://gtech-cdn.mmhmm.com」は解決し、pingにも応答します。CNAMEレコードのターゲットであるf000.backblazeb2.comも解決します。そのB2フレンドリーURLのオリジンは、記事で指示されているものです。しかし、問題はそこではありません。問題は、Discourseが.jsファイルのURLを、パスに「/file/gtech-cdn」部分が欠けているため機能しない無効なURLで提供していることです。それらの不完全な.js URLのいずれかを取得し、欠落している情報を手動で追加すると、.jsファイルのテキストは正常に読み込まれます。
もちろん、これらすべてがどのように機能するはずなのか、まだ理解しようとしています。私は視覚的な学習者なので、Cloudflare CDN、Discourse、Backblaze B2間のやり取りで何が起こるべきかを理解するのに役立つフローチャートのようなものが本当に必要です。
ご協力ありがとうございます。
ああ、あと、通常のCDNに関する最後の文章にも触れておきますね。
Backblazeの記事では、バケットごとに2つのページルールを作成するように指示されています（私の場合はバケットは1つしか使用していません）。これは、私の理解が正しければ、処理方法においてファイアウォールルールのようなものです。
ルール1は、https://gtech-cdn.mmhmm.com/file/*/* が標準キャッシュ（Cloudflareの他の場所で1ヶ月に設定されています）を使用するように指定しています。
ルール2は、ルール1のパターンに一致しないものすべてをリダイレクトします（302 - 一時リダイレクト）。
つまり、mmhmm.comにアクセスしても、すべてがキャッシュされるわけではないということです…少なくとも私の理解ではそうです。
編集：これは機能しませんでした。
もう少し詳しく見てみると、明らかな理由から、Backblazeの記事が推奨していたフレンドリURLではなく、CNAMEターゲットとしてS3 URLを使用することにしました。現在、DNSレコードのTTLが期限切れになるのを待っています。
このフックについて：
rake --tasks のダンプに S3 に関連するものは見当たりません。これはまだ関連性があるか、それともプラグインを見落としていますか？
手動で実行した際にも、以下のような表示が出ています：
uploads:migrate_to_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.2.0/gems/rails_multisite-6.0.0/lib/rails_multisite/connection_management/null_instance.rb:49:in `with_connection'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/rails_multisite-6.0.0/lib/rails_multisite/connection_management/null_instance.rb:36:in `each_connection'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/rails_multisite-6.0.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>'
/usr/local/bin/bundle:25:in `load'
/usr/local/bin/bundle:25:in `<main>'
Tasks: TOP => uploads:migrate_to_s3
(See full trace by running task with --trace)
root@ubuntu-s-2vcpu-4gb-nyc2-01-app:/var/www/discourse#
root@ubuntu-s-2vcpu-4gb-nyc2-01-app:/var/www/discourse# rake uploads:migrate_to_s3
Please note that migrating to S3 is currently not reversible!
6件の投稿が新しいトピックに分割されました: Cloudflare R2: セットアップのナビゲーションと設定エラーの処理
Cloudflareが機能するようになりました。
Cloudflare R2: Navigating Setup and Handling Configuration Errors - #13 by pfaffman を参照してください。
「いいね！」 2