pnoeric
(Eric)
1
私はフォーラムのアセットを保存するためにAmazon S3バケットを設定し、それをカスタムドメインに配置してCloudFlare CDNでコンテンツをキャッシュするように設定しました。
私のカスタムドメインはhttp://forum-storage.comのようなもので、https://forum-storage.com.s3-us-east-1.amazonaws.comを指しています。S3バケット自体の名前はforum-storage.comです。
これで全て正常に動作しています。バケットのメインフォルダに画像を追加すると、カスタムURLで取得できます。つまり、http://forum-storage.com/test.jpgにアクセスすると、CloudFlareのヘッダー付きで画像が返されます。
簡単な質問が3つあります…
#1
次に、Discourseにこの新しいURLをS3バケットとして使用するように指示する必要があります。以下の3つのフィールドには何を入力すればよいでしょうか？
#2
現在、フォーラムの投稿には別のS3バケットにある画像と、ローカルに保存されている画像の両方が含まれています（画像URLはバラバラです）。
上記の適切な変更を行えば、これ以降フォーラムに追加される全ての新しいメディアはこの新しいバケットに保存されますが、既存の画像は移動されず、現在保存されている場所から引き続きアクセスされる、という理解で正しいでしょうか？
#3
これで今後追加される全ての画像がこのように動作するようになった場合、この新しいバケットにない古い画像をDiscourseに移動させ（必要に応じて投稿を再構築して）、全てをこの新しいバケットにまとめるにはどうすればよいでしょうか？
目標は、CDNの背後にあるこの新しいバケットに全てをまとめることです。
「いいね！」 1
riking
(Kane York)
2
「いいね！」 8
pnoeric
(Eric)
3
ふむ、わかった。一時的なトラブルですね！
@riking さん、情報ありがとう。
AWS S3 には、バケット名をドメイン名と同じにすれば、そのドメインに単に CNAME レコードを追加するだけで自動的に機能する機能があります（Virtual hosting of general purpose buckets - Amazon Simple Storage Service
そこで今、ドメイン名と異なる名前のバケットにドメインを接続する方法について、あちこちで情報を探しているところです…ふむ
@BryanV さん、https://discourse-uploads.bokeh.org をあなたの S3 バケットにどうやって指し示しましたか？
「いいね！」 1
riking
(Kane York)
4
なるほど、それは良いですね。ただし、バケットの前に CloudFront のような CDN を置いて、そこに CNAME を割り当てる必要があります。そのため、現時点では実用的な機能とは言えません。
CDN を使わない場合、同様に高額な転送料金が発生します。
「いいね！」 3
pnoeric
(Eric)
5
はい、私たちの認識は一致していますね？より明確に言うと、Discourse と S3 を接続する方法は以下の 3 種類があると理解しています。
-
Discourse が S3 クラウドを直接利用する。メリット: 設定が非常に簡単。デメリット: すぐに高額になる。
-
Discourse がカスタムドメイン（例: forum-storage.com）を介して S3 クラウドを利用し、CDN を使用できるようにする。メリット: バケット名がカスタムドメインと完全に一致する場合（例: forum-storage.com.s3-amazon-aws.com）、S3 での設定は非常に簡単。デメリット: SSL に問題が発生する。
-
Discourse がカスタムドメイン（これも CDN 利用のため）を介して S3 クラウドを利用するが、S3 バケット名に余計なドットが含まれないように設定する（例: forum-storage-com.s3-amazon-aws.com）。メリット: SSL が正常に動作する。デメリット: Amazon S3 での設定がそれほど簡単ではない。
つまり、私は最初は #1 を使っていたのですが、請求書を見てから（笑）、#2 という選択肢があることを学び、それを設定してこのトピックを開始しました。しかしすぐに、#2 は実際には選択肢ではないと分かりました。
現在は #3 に取り組んでいます。Amazon の DNS サービスである「Route 53」を使う必要があるようです。まだ手探りの状態ですが、私がググって得た情報はすべて #2 の方法に関するもので、#3 について明確な手順を記した情報は誰も書いていないようです。
もし私の理解が間違っていたり、何か見落としていることがあれば、ご指摘ください…
riking
(Kane York)
6
「いいね！」 1
BryanV
(Bryan Van de ven)
7
@BryanV https://discourse-uploads.bokeh.org を S3 バケットにどうやって指し示しましたか？
Cloudfront CDN 配信の <long id>.cloudfront.net URL を指し示す CNAME レコードを、bokeh.org の DNS 設定に追加しました（当社の場合は Cloudflare を使用していますが、それは問題ありません）。
参考までに、当社の S3 バケット名にはドットが含まれていませんが、それによって CDN のセットアップやバケット作成に特定の問題が発生した記憶はありません（バケット作成には一意な名前が必要であるだけです）。
pnoeric
(Eric)
8
これほどイライラさせられることって、他にないと思います。どうやれば、ドット（ピリオド）が含まれていない Amazon S3 バケット名、カスタムドメイン、CloudFlare をすべて連携させて動作させられるのか、どうしてもわかりません。バケット名にドットを入れられれば、問題はなかったのですが。今はただ、すべてが混乱しすぎています。うっっっ！どなたか助けてください。ドメイン名と一致しない S3 バケットと CloudFlare を設定する簡単な方法をご存知ありませんか？
上記の StackPath の情報を試しましたが、CloudFlare でも似たような設定をしたつもりですが、よくわかりません。動作しませんでした。CloudFlare の Amazon バケットへの CDN 設定方法に関する記事も読みましたが、もちろんバケット名をドメイン名と同じにするように推奨されています。しかし、それは「非常に悪い考え」と言われており、私にはできません。
結局、以下の二択に絞られるようです：
- バケット名がドメイン名（ドット付き）と同じ場合、Amazon S3 がすべて処理してくれます。素晴らしいことですが、SSL に問題が生じるため、避けるべきです。
- バケット名がドメイン名と一致しない場合、すべてが非常に複雑になり、解決策がわかりません。
どなたかアドバイスやサポートをお願いします。それまで、S3 ストレージの請求が毎月100ドル以上来ています。本当に最悪です。今すぐ200ドル払って、この問題をすべて解決してくれる人はいませんか？もう参っちゃいました。
Bill
(Bill)
9
これを読みましたか？私もS3とCloudflareのセットアップで苦労しましたが、結局解決しました。セキュリティ上の利点のためにCloudflareを引き続き使用することはできますが、別途CDNサービスも必要だと確信しています。Cloudflareは通常のCDNとは異なり、仕組みが違います。より安価なS3サービスへの移行をお勧めします。Amazonは高価です。
Falco
(Falco)
10
Cloudflare を使用して S3 バケットをキャッシュするには、リクエストのオリジンヘッダーを操作する必要があります。この機能は Cloudflare のエンタープライズプランで利用可能であるため、他の CDN を使用した方が簡単かもしれません。
「いいね！」 2
バケット名にドットが含まれていることは、画像をCDN経由でキャッシュする以上、無関係なのではありませんか？重要なのは、Cloudflareで配信される画像をカバーする適切な証明書を持っていることです。
彼はCloudflareのサーバー、DNS、そしてその範囲をカバーする証明書に焦点を当てるべきだと思います。ユーザーやブラウザが、これらの画像のソースがS3バケットであることに気づくことはまずないでしょう。Cloudflareが画像そのものをキャッシュ・プロキシするはずです。
riking
(Kane York)
12
Discourse は直接バケット URL を生成し、それらを「ファイルのアップロード」などの内部操作に使用します。それでもこれは重要です。
@riking Discourse に必要なのはバケット名だけでいいですよね？アップロードや管理は、HTTPS が必要かどうかに関わらず、AWS の URL とその証明書を使って行うことができます。では、なぜセキュリティ証明書について話しているのでしょうか？
OP はその後、CDN やキャッシュソリューションが S3 から画像を取得するために必要なことを個別に確認すればいいだけです。セキュリティの有無は、OP や CDN に特別な要件がない限り問題になりませんよね？Discourse は S3 と CDN の間の設定を気にするのでしょうか？
最後に、OP は画像を CDN から有効な証明書付きで配信するようにする必要があります。これは、OP が画像のベース URL を指定する点以外に、Discourse と何か関係があるのでしょうか？CDN やキャッシュが S3 から画像を取得すれば、AWS、バケット、その他諸々は完全に問題外になります。
S3 のバケット名にドットが含まれていると、そこから画像を配信する場合に問題が生じることは理解していますが、OP はそれを意図していません。つまり、CDN との設定に干渉しない限り、Discourse が受け入れる任意のバケット名を選べばよいだけです。
riking
(Kane York)
14
バケット名をドメインに含める URL を回避することは可能ですが、AWS S3 SDK の使用方法や設定の難しさにより、実際には回避されていません。
繰り返しになりますが、これらの操作は CDN をバイパスしており、修正するには Discourse のソースコードを変更するしかありません。修正は可能ですが、現時点では行われていません。また、多くの問題はクリティカルパスでは発生せず、後で表面化するだけです。そのため、この状況が変わるまで、ドットを含むバケット名は使用しないでください。
「いいね！」 1
つまり、非常にシンプルにまとめると……元の投稿者の質問は、以下の 3 つの設定値を何にすべきかというものでした。
(1) バケット名——つまり、ドット（ピリオド）は推奨されていないのでしょうか？それとも許可されていないのでしょうか？おそらく、この点は元の投稿者にとっては問題にならないかもしれません。（彼は CDN が画像をキャッシュし、配信するための方法を別途見つける必要があります。）さて、私たちはここで認識を共有できているでしょうか？
(2) S3 エンドポイント——AWS を使用している場合は空白のまま、何も入力する必要はありません。他のプロバイダーを使用する場合は、そこに記入すればよいのでしょうか？
(3) S3 CDN URL——これは単に、Discourse が画像パスに付与するベース URL でしょうか？もしそうなら、それはシンプルで明確です。元の投稿者は CDN を設定し、そのベース URL をここに提供すればよいのです。
SSL ワイルドカード証明書がここでどう関わるのかはわかりません。元の投稿者には、Discourse の設定にドットが含まれていると証明書が破損するため、それは避けるべきだと伝えられました。しかし、CDN やキャッシュを使用している場合、バケット名は証明書とは無関係である可能性が高いですよね？もし、それが別の方法で Discourse を破損させるのであれば、その点も知っておく価値があります。
pnoeric
(Eric)
16
すべてを詳しく追えているか確信はありませんが、少し視点を広げて、シンプルな要件のセットを提示してみます。
目標:
- Discourse の画像を Discourse サーバー上に保存しない
- 画像を保存するための S3 バケットを用意する（Discourse が対応しているのは S3 であるため）
- 高額な S3 課金を避ける
- CDN は必須ではないが、高額な S3 課金を削減する（あるいは排除する唯一の方法となる）可能性があり、また世界中での可用性向上や、メインサーバーがオフラインになった場合のバックアップなどの利点があるため、あれば嬉しい
もし上記に誤りがあったら教えてください
制限/要件:
- 外部画像ストレージは S3 プロトコルに対応している必要があります（Discourse が S3 プロトコルを使用するため）が、厳密には Amazon の S3 である必要はありません。
- Discourse では、S3 バケット名にドット（.）を含めることはできません。
- 画像ソース（S3 または CDN）は HTTPS で提供されている必要があります。ページが HTTPS なのに画像がそうでない場合、ブラウザが警告を表示するためです。
もし上記に誤りがあったら教えてください
解決策:
以前は、Amazon S3 から直接提供していました。これは非常にうまく機能しましたが、Amazon からの「DataTransfer-Out-Bytes」の課金が非常に高額でした。その結果、Amazon からの請求額が高騰しました！そこで、再びメインサーバーに戻しました。これを解決するための 2 つの可能性のある対策は、Amazon S3 バケットの前に CDN を配置してすべてのデータ転送を CDN に任せること、および/または別の S3 プロバイダーに切り替えることです。
Amazon S3 バケットの上に CloudFlare CDN を配置しようとしましたが、すぐに解決できない多くの問題に直面しました。
他の選択肢は？
Digital Ocean が提供する S3 互換のストレージサービスを最近見ていました。ビルトインの CDN（具体的に何を意味するかはわかりませんが、有望に聞こえます）と手頃な価格設定です。これは Discourse と互換性があるでしょうか？
参考までに、過去 30 日間で S3 から約 300 GB のデータを提供しました。その中にはサイトバックアップも含まれていますが、大部分は静的画像です。Amazon においてこれらをどのように測定すればよいかを特定するのは非常に困難です… 彼らの請求レポートインターフェースは、Amazon AWS の他のすべてのものと同様に、管理する上で本当に混乱を招きます。
pfaffman
(Jay Pfaffman)
17
最もシンプルな解決策は、AWS と KeyCDN を使い、アップロード用のオブジェクトストレージの利用（S3 およびそのクローン）のガイドラインに従うことです。ユーザーが南米にいない場合、KeyCDN は非常に手頃な価格で設定も簡単です。
より低コストな解決策として、BackBlaze S3 と BunnyCDN のセットアップ方法が挙げられます。バックアップの初期テストでは BackBlaze に満足していましたが、アップロードへの利用はまだ試していません。
「いいね！」 1
バケット名内のドットやブラウザの証明書について、完全に脱線してしまいました。しかし、あの議論はすべて無関係だと考えます。どのCDNでもHTTPS設定が可能であり、「ワイルドカード証明書」の問題や、バケット名にドットがあるかないかは、エンドユーザーのブラウザ証明書に関しては全く問題ありません。なぜなら、どのCDNもこれを必ずサポートするからです。
したがって、OP は単に以下の手順を実行すればよいでしょう。
(1) S3 と CDN との互換性のあるストレージソリューションを選択し、Discourse の設定でエンドポイントとバケット名を設定する。
(2) CDN が S3 から画像を取得するように設定する。暗号化の有無は問いません。OP は、CDN が HTTPS 経由でユーザーに画像を提供さえすれば気にしないはずです。
何か見落としている場合は、どなたかご指摘ください。エンドユーザーのブラウザ証明書とバケット名内のドットの問題は、画像をバケットから直接提供する場合にのみ発生する問題だと考えます。CDN から提供する場合には無関係です。
pnoeric
(Eric)
19
追伸：上記で @pfaffman が親切にリンクしてくれたトピックでは、Digital Ocean の S3 製品（「Spaces」）の CDN が「ひどく壊れている」と指摘されています。
また、他の S3 プロバイダーについても、調整が必要な各種設定があることがわかります。
これにより、私が得た教訓は以下の通りです：
- すべてが「S3」プロトコル準拠を謳っていても、設定はプロバイダーによって異なります。
「いいね！」 2
なお、
バケット名にドット（ピリオド）を含めないでください
という点です。ただし、苦痛を楽しむのがお好きなら別ですが。
今すぐ中止