ありがとうございます！その時は編集権限がなかったためモデレーターの注意を促しましたが、投稿のおかげで今は権限があります。皮肉なものですね。
しかし、MinIOセクション外にグローバルな注釈を作成する前に、Discourse全体で、この投稿が私の編集のきっかけとなったような、非ドメインベースのパスがもうサポートされていないことを確認できますか？
Discourse全体でパスモード（つまり minio.server.com/BUCKET/foo/bar/... のパス）をサポートしておらず、ドメインパス（つまり BUCKET.minio.server.com/foo/bar/... ）のみをサポートしていることがわかっている場合、それをウィキのグローバル通知にすることができます。喜んでそうします。ただし、単純なコミュニティメンバーである私よりもはるかに上位の人から、これがDiscourseの要件であると聞く必要があります。もしそうであれば、編集して追加します。そうでなければ…まあ、MinIOの要件に注釈として残しておくだけです。
MinIO は、現在非推奨となっている S3 パススタイルを使用していた実績のある唯一の人気のある S3 クローンであるため、グローバルな警告ではなく、MinIO セクションにのみ警告があれば十分だと思います。
Falcoさん、ありがとうございます。MinIOの要件に残しておきましたが、上記のリンクされたスレッドが私が再度確認している理由を参照しているため、その注意書きのセクションにも強く強調しておきました。
問題が発生しているようです。
以下を入力しました。
after_assets_precompile:
- exec:
cd: $home
cmd:
- sudo -E -u discourse bundle exec rake s3:upload_assets
再構築しました。
FAILED
--------------------
Pups::ExecError: cd /var/www/discourse & sudo -E -u discourse bundle exec rake s3:upload_assets failed with return #<Process::Status: pid 2064 exit 1>
Location of failure: /usr/local/lib/ruby/gems/2.7.0/gems/pups-1.1.1/lib/pups/exec_command.rb:117:in `spawn'
exec failed with the params {"cd"=>"$home", "cmd"=>["sudo -E -u discourse bundle exec rake s3:upload_assets"]}
bootstrap failed with exit code 1
** FAILED TO BOOTSTRAP ** please scroll up and look for earlier error messages, there may be more than one.
./discourse-doctor may help diagnose the problem.
指示に従っていただけますか。
OPにS3の古いアセットをクリーンアップするステップを追加しました。GCP以外ではすべて機能するはずです。
rake s3:migrate_to_s3 で 170,000 件のファイルのほとんどがアップロードされましたが、12 件で次のようなエラーが発生したと思います。
: Unsupported value for canned acl 'private' (Aws::S3::Errors::InvalidArgument)
それらは PM にあったのでしょうか？それらを修正するために何かできることはありますか？
こんにちは、@Falco さん。これは意味が通りますか？このトピックで30日後に削除する機能を有効にできるように、返信が処理されているか確認しています。
プライベートとしてマークされているアップロードをいくつか確認しましたが、通常のトピックにあったため、なぜセキュアとしてマークされていたのかわかりませんでした。（セキュアなアップロードは設定されていませんでしたか？）
上記を参照してください。
セキュアアップロードはAWS S3のみに対応しているため、クローンでは機能しません。
なるほど。OPの冒頭にその情報を追記しました。S3やセキュアアップロードが有効になっていないサイトで、ローカルアップロードがどのようにセキュアとしてマークされたのか、何か心当たりはありますか？
誰かが一時的にそれを有効にしてから、機能しないことに気づいて元に戻したのではないでしょうか？
Cloudflare R2へのアップロードに関するこの問題は、Upload.where(secure: true).update_all(secure: false)で解決できる可能性があると思います。このメッセージが削除される前に対応できるように努めます（ただし、OPにメモを追加しました）。
うーん、セキュアなアップロードがありません。Cloudflare R2 を試してみようと思います。無料枠がかなり寛大で、（ベータ版ですが）S3移行ツールもあります。結局R2は大丈夫だったか @pfaffman さん、確認しましたか？
画像をアップロードしようとしたときか、新しい画像をアップロードしたときか、もう思い出せません。もう一度考えてみると、新品のサイトでテストしたと思います。
別のS3プラットフォームへの移行は非常にトリッキーです。それに関するトピックはいくつかありますが、Cloudflare R2を使用したい場合は、まずテストサイトで試してみることをお勧めします。うまく機能しない可能性が非常に高いです。
それはある程度機能しますが、本番環境での使用にはまだ準備ができていません。
古いDiscourse 2.7のローカル開発環境が残っており、それは問題なく動作していました。つまり、画像アップロード、CDNの使用、Cloudflare R2用に設定した場合のプライベートバケットへのバックアップなどです。最新の2.9（私たちのフォーラムが使用しているもの）に更新したところ、Jobs::UpdateGravatarのキャッチアップ処理で失敗するようです。これは、Cloudflareに対してバケット表記を誤って使用しており、Gravatarのリモート画像をR2にキャッシュしようとしています。例（R2のバケット名は ‘uploads’ です）：
Upload Update (0.3ms) UPDATE "uploads" SET "url" = '//uploads.123123redact.r2.cloudflarestorage.com/original/1X/123123example.jpeg', "updated_at" = '2022-12-12 20:44:02.929494', "etag" = '9c02b086b2aa5e2088ed44e1017fa63e' WHERE "uploads"."id" = 3
そのため、UIを起動すると、ローカルテスト/開発環境のアバターは次のように表示されます。
//uploads.123123redact.r2.cloudflarestorage.com/original/1X/123123example.jpeg
したがって、私の推測では、S3はこのバケットのドット表記で問題なく、Cloudflare R2はそうではないか、あるいはGravatarキャッシュがS3 CDN値を使用する必要があるのかもしれません。惜しいですが、かなり近いようです。
Cloudflareから、R2ではオブジェクトACLが正しく実装されるまで、サポートされていないプロパティに値が返された場合に200を返すように変更したとの返信がありました。これは明らかに理想的ではありませんが（公開バケットにあり、APIはプライベートにするように要求しています）、この問題についてはこれで「機能する」ということです。
おお！それは有望そうですね。アップロード専用のバケットが必要になるかもしれませんが、バックアップのファイル名を推測するのはかなり難しいでしょうね。
近いうちに確認してみます。
アップロードとバックアップのバケットを別々に使用しており、バックアップ用のR2バケットは公開設定になっておらず、Discourseは管理UI経由でそこに圧縮バックアップを正常に書き込めたため、うまくいっているように見えました。ダウンロードして確認したところ、問題ないように見えました（実際の復元と同じではありませんが、月曜日としては十分です）。アップロードバケットについては、S3_CDNのカスタムドメイン設定でテストし、うまく機能しているようです。
正直なところ、2.9のEmber CLIでUIがレンダリングされない原因はよくわかりません（管理者ユーザー作成後に画面が真っ白になります）が、おそらくすぐに間違いに気づかれるでしょう。
編集：ああ、プラグインのJavaScriptアセットをPseudo-S3/R2から読み込もうとしているようです。例えば、assets/locales/en.br.jsのようなもので多くの404エラーが発生しています。
bundle exec rake s3:upload_assetsを実行しても何も起こらないので、これが現時点での最大のヒントです。
編集2：はい、アセット関連の問題です。DISCOURSE_S3_CDN_URLをクリアするとUIがロードされます。とりあえず、アセットを手動でアップロードしてみます。
編集3：この問題は、アプリがアセットをプリコンパイルする必要があることと、DISCOURSE_S3_CDN_URLの指定先に関連しているようです。ローカルの開発環境では通常はありません。@pfaffmanさんが見つけるであろうことに関心があります。これは、after_assets_precompileフックを使用してR2を使用する、適切なDockerでデプロイされたセルフホストインスタンスでは機能すると思います。
ええ。ローカル開発環境でCDNですか？機能するとは想像できません。本番環境へのデプロイには機能するはずですが。
はい、後から考えると開発環境では驚くことではありません。予想外だったのは、DISCOURSE_S3_CDN_URL を Cloudflare R2 CDN に設定し、DISCOURSE_CDN_URL を空白（またはローカルや ngrok）に設定した場合でも、アップロード/画像だけでなく、プリコンパイル済みアセットなどのために Cloudflare のプル URL を使用しようとしたことだと思います。本番環境の適切なコンテナでは問題なく動作すると思うので、すぐに試してみるかもしれません。私の計画は、メディアアップロードを一時的に TL4 に設定し、app.yaml の ID などを Cloudflare に切り替え、テストして、問題なければ R2 に設定し、その後既存のすべての S3 オブジェクトを rclone で転送します。その後、投稿を再ベイクすれば、すべてうまくいくはずです 
。