Cloudflareの設定とその他の移行後タスク

こんにちは。vbulletin3からDiscourseへのアドホックな移行を他の人々と協力して進めてきました。今、移行の他の側面について考え始める時が来ました。その一つが、フォーラムを提供しているCloudflareアカウントがあることです。

フォーラムにはたくさんのROM(ROM = Read Only Member、ROM = 閲覧専門のメンバー)と約1000人のアクティブユーザーがいるため、可能であればCloudflareを維持したいと思います。

ここで見つけた唯一のスレッドは2015年のもので、情報が多少含まれているだけなので、CloudflareとDiscourseを適切にセットアップする方法を指定する「公式」ドキュメントを見落としている可能性があるか質問しています。

二次的に、以下のプロセスがあるかどうかを知りたいです。

  • 移行後にDiscourseが統計情報を更新するようにする
  • 移行後にDiscourseの検索インデックスを「更新」するようにする

よろしくお願いいたします :slight_smile:

どのように提供しますか? DNSモードを使用するのが最も簡単です。ほとんどメリットはありませんが、時間をかけたい場合は、それに関するトピックがいくつかあります。ほとんどの場合、Discourseを壊す最適化を無効にします。サーバーの負荷を軽減したい場合は、Bunny.netのような実際のCDNが最適です。

統計情報と検索は機能するはずだと思います。

Cloudflare が「本物のCDN」ではないと示唆するのは、少し見通しが甘いのではないでしょうか?なぜなら、Cloudflare はそうだからです(そしてそれ以上でもあります)。おそらく「従来の」CDN を意味していましたか?

従来のCDNをセットアップするには、より多くの時間を要し、得られるメリットはほぼ同じです。

「いいね!」 1

なるほど!

Cloudflareは、無料版でも多くの人にとって十分な場合が多いため、より安価かもしれません。Cloudflareでサイトを壊してしまった人がいるというアクティブなトピックが常にあり、それを機能させる最も簡単な方法は、レイテンシを増加させるだけになるように、すべての最適化を無効にすることのようです。

従来のCDNと同じメリットを提供するCloudflareの設定方法を説明するトピックを作成できれば、非常に役立つでしょう。おそらく、ロケットローダーを無効にするだけで十分かもしれませんが、製品が変更・改善されるため、正確な設定方法は常に変化しているようです。

議論を引き起こしたくないので、どのCDNが一番かなどについては触れません。

まだ自分で情報を集めている最中ですが、私の理解では、フォーラムは有料プラン(無料版ではないと思われます)を利用していますが、それは本題ではありません。

簡単な質問です :slight_smile: – CloudflareをDiscourseに影響を与えないように設定するにはどうすればよいですか?

その後、それが本当に必要なものなのかどうか(メリットなど)を理解することに満足します :slight_smile:
また、他の2つの些細な質問について、リンクなどを教えていただけると幸いです :heart:

来週、ステージング環境でテストを行う予定なので、何も確定していません!

Discourse.org、または他の誰かによってホストされている場合は、Cloudflareで何かを行う前に、必ず彼らに確認してください。通常は、彼らのサーバーを指すDNS CNAMEを作成するだけです。Discourse.orgにはすでにCDNが配置されているため、心配する必要はありません。

@pfaffmanさん、ありがとうございます。これはセルフホストです。前述のとおり、現在のvbulletinフォーラムで使用されており、これは単にオフラインになり、同じドメイン名から応答するdiscourseに置き換えられます。

「いいね!」 1

Cloudflareにどのような役割(もしあれば)を期待するかによります。

CloudflareをDNSとしてのみ使用したい場合は、フォーラムの「a」レコードのオレンジ色の雲が無効になっていることを確認してください。

実際にDiscourseトラフィックをCloudflareのネットワーク経由で送信したい場合、およびそれが追加する遅延を許容できる場合は、最低限、フォーラム全体のドメインに対して「パフォーマンスを無効にする」ページルールを作成してください。Cloudflareのパフォーマンス最適化は推奨されておらず、サイトを破損させる可能性があることが知られています。

アプリ.ymlに追加する必要があるCloudflareテンプレートがあり、これによりCF-Connecting-IPがクライアントIPとして渡されるため、全員がネットワーク上のノードから発信されているように見えなくなります。

オブジェクトベースのストレージを使用しておらず、オレンジ色の雲が有効な状態で実行している場合は、アセットパスのキャッシングルールを作成できます。

「いいね!」 2

Stephenさん、ありがとうございます。

Cloudflareは、実際のWebサーバーへのリクエストの負荷を軽減するために(現時点ではまだですが)使用されていました。

Discourseのリアルタイム更新の性質(Websocketだと仮定していますが、確認していません)が、Cloudflareのキャッシュなどとどのように問題になる可能性があるのか、最も疑問に思っていました。そのため、ドキュメントがあるか、または誰かからのヒントがあるかと思っていました :slight_smile:

私は何も知らないので、時々途方に暮れてしまいますが、あなたはPHPの性質を探しているのに、実際のデータを取得すること以外はすべてユーザーのデバイスで行われるJavaScriptアプリの性質を得ているようです。

それが、私がVarnishをDiscourseの前に置こうとした試みがひどく失敗した理由です(そして私のスキルも限られているためです)。

もちろん、アセットをCDNから提供することはできますが、それはそれだけです。

「いいね!」 1

はい、Cloudflare はアプリケーションサーバーの負荷を軽減するために何もできません。シングルページ JavaScript アプリケーションとして、Discourse はまったくメリットがありません。

さらに悪いことに、Discourse を Cloudflare の背後に置くと、ブラウザ内のアプリとサーバー間のすべてのリクエストでネットワークホップが追加されるため、応答時間がわずかに増加します。

アップロードはサーバーに保持していますか、それとも S3/S3 のような代替手段を使用していますか?

「いいね!」 1

返信が遅れて申し訳ありません。

Discourseのデザインについてはあまり詳しくありませんが、Redisが一般的なリクエストのキャッシュをすでに管理していることを考えると、それが「Cloudflareがあまり必要とされない」理由を説明しているのかもしれません。

つまり、Discourseのインストール環境の前面にCloudflareを配置しても、ほとんど、あるいは全くメリットがなく、むしろ(ネットワークホップによって)応答が遅くなる可能性がある、ということで合っていますか?

vbulletin3のインストール環境でCloudflareを使用していた唯一の理由は、リクエストの量がサーバーを圧倒する可能性があったためです。これは(推測ですが)vbulletin3のコード設計の貧弱さによるものかもしれません。正直なところ、アプリケーション専用のVMは4vcore、8GB RAMで、DB専用にも同等のスペックのVMがあります。

現代のウェブアプリケーションがこれほど多くのパワーを必要とするとは考えられません。

ところで、平均して約1Kのアクティブユーザーと約5〜6Kの潜在ユーザーがいるDiscourseのインストール環境に必要なハードウェアを評価するための参考資料はありますか?

それは完全には真実ではありません。特に初回読み込み時には、CloudflareはJavaScriptの静的アセットの読み込みを高速化できます。そして、それはGoogleが検索エンジンのペナルティを回避するためにサイトのパフォーマンスを評価する際に考慮する要素の1つです。検索エンジンからユーザーを引き付けるマーケティング的なフォーラムではメリットが大きくなり、アクティブなリピーターが多いフォーラムではデメリットが大きくなります。

いいえ、それはユーザーが非常にアクティブであるか、1日に1回アクセスするだけかによって大きく異なります。私は、1日中大量の写真を交換し、Discourseをチャットボックスとして使用していた50人未満のグループが、非常に高性能なハードウェアをひざまずかせたのを見たことがあります。一方で、週に1回何かを投稿するために訪れる10,000人のフォーラムと、3000万 (!) 以上の潜在ユーザーが、平凡なVPSで動作しているのも見たことがあります。

「いいね!」 3

RGJさん、洞察と情報ありがとうございます。様子を見て、物事がどう進むか見てみましょう。以前のソフトウェアと比較して、大幅な要件の増加が必要ないことを願っています:crossed_fingers: