メンテナンスページの回避策 - これって可能？

サポート インストール
22

うん、段階的にやるのがいいよ：

  1. 多少強力なサーバーを入手する
  2. 2つのコンテナのインストールを動作させる

この時点で満足ならここで止めてもいいし、そうでなければ：

  1. 上記の@Lillyの優れたガイドを使ってメンテナンスページを実装する。:+1:
23

ハハ、この部分について説明する時間を取らなかったのですが、質問してくれてよかったです（説明すべきでしたよ。説明すべきことが多く、Cloudflare は複雑ですから！）

ワーカーのルートページが設定されると、フォーラム上のすべての画像の読み込みやページビューがそのワーカーを介してルーティングされます。

Cloudflare の無料 CDN プランには、ワーカーのルートに対して 1日あたり 100,000 リクエストの制限が含まれています。

したがって、比較的活発なフォーラムの場合、1日以内に無料枠の上限に達しないようにするため、常時オンにしておくのは避けたほうがよいでしょう。 これはワーカーのルートのことであって、メンテナンスページのことではありません。メンテナンスページは常時表示しておくことができます。ワーカーのルートが設定されていない限り、メンテナンスページにはアクセスされません。 これは、ステップ 2 でルートを割り当てた部分（設定と削除が簡単です）にすぎません。 Cloudflare の有料プランを使用していない限り、メンテナンス作業を行っている間のみルートを有効にしておくのがよい習慣です。

  1. ドメインの Cloudflare ワーカー ルートページに移動し、ルートの右側にあるボタンをクリックします。

Screenshot 2026-08-01 at 5.06.14 PM
Screenshot 2026-08-01 at 5.06.14 PM1652×552 43.9 KB

  1. 編集画面の下部で、remove（削除）ボタンをクリックして、ワーカーページをルートから切り離します。

Screenshot 2026-08-01 at 5.09.01 PM
Screenshot 2026-08-01 at 5.09.01 PM742×658 40.5 KB

  1. 心配しないでください。 ワーカーコード自体は削除されず、ルーティングルールのみが削除されます。 次にリビルド/アップデートを実行するときは、上記のステップ 2のように再度追加すればよいです。

Cloudflare の有料プランを使用している場合は、何も心配する必要はありません。 ただし、その場合はワーカーページではなく Cloudflare のエラーページを使用できます…（Cloudflare がかなり複雑だと言いましたよね？LOL）

:warning: 以下は高度な管理者設定です

無料プランでアップデートを完全に自動化したい場合は、Cloudflare API トークンとゾーン ID、および curl コマンドを使用してワーカーの route id を取得する必要があります。 次に、ワーカーのルートを自動的にオン/オフするためのいくつかの追加の処理を /root/update-web.sh スクリプトに追記します。

#!/bin/bash
cd /var/discourse

CF_TOKEN="your_actual_token_here" #<---Cloudflare API トークン
ZONE_ID="xxxx" #<---Cloudflare プロファイルページから取得
ROUTE_ID="xxxx"
WORKER_NAME="my-site-maintenance-page"

echo "➡️ 最新の Discourse Docker スクリプトを取得中..."
git pull

echo "➡️ 背景で新しい Web コンテナをブートストラップ中..."
./launcher bootstrap web_only

if [ $? -eq 0 ]; then
    echo "✅ ブートストラップ成功！"
    
    # Cloudflare メンテナンスワーカーを有効化
    echo "🚧 メンテナンスページを有効化中..."
    curl -s -X PUT "https://api.cloudflare.com/client/v4/zones/$ZONE_ID/workers/routes/$ROUTE_ID" \
         -H "Authorization: Bearer $CF_TOKEN" \
         -H "Content-Type: application/json" \
         --data '{"pattern":"*your-site.com/*","script":"'$WORKER_NAME'"}' > /dev/null

    # コンテナを切り替える（30秒のダウンタイムウィンドウ）
    echo "🔄 コンテナを切り替え中..."
    ./launcher destroy web_only && ./launcher start web_only
    
    # Cloudflare メンテナンスワーカーを無効化
    echo "🌍 メンテナンスページを無効化中..."
    curl -s -X PUT "https://api.cloudflare.com/client/v4/zones/$ZONE_ID/workers/routes/$ROUTE_ID" \
         -H "Authorization: Bearer $CF_TOKEN" \
         -H "Content-Type: application/json" \
         --data '{"pattern":"*your-site.com/*","script":null}' > /dev/null

    echo "🚀 完了！ ダウンタイムなしでサイトが更新されました。"
else
    echo "❌ ブートストラップ失敗！ 現在のサイトをオンライン状態に保つため、切り替えを中止します。"
fi

私はすべての自動化には興味がなく、アップデート/リビルド時に立ち会いたいので、以前のスクリプトバージョンを使用しています。 アップデートを実行する直前にワーカーのルートを追加し、その後削除するだけです。 これには数秒しかかかりません。

私の一般的な手順は以下の通りです：

  1. Cloudflare でワーカーのルートを追加
  2. Hetzner に SSH 接続
  3. システムのアップデートを実行（例：sudo apt update && sudo apt upgrade -y、必要に応じてサーバーを再起動）
  4. 再起動が必要だった場合は再度 SSH 接続
  5. ./update-web.sh を実行
  6. Cloudflare でワーカーのルートを削除
24

Visual Basicで昔々「Hello World」を1回やったことがある程度で、コーディングや開発の世界についてはほとんど何も知りません。でも、WordPressやMastodon/Pixelfedサーバー、そして何となくDiscourseの管理はそれなりにできるんです。それに、AIというものが存在します（ただし、宣伝されているほど初心者に優しいわけではありません）。

Dockerを使っているDiscourseでは、これが現実的に可能かどうかはわかりませんが、通常のNginx-Varnish-WordPress環境では、Pleskサーバーが50xエラーを検知してエラーページを表示するシステムを構築したことがあります。実際には3つの構成があり、Varnishがダウンした場合はフロントエンドのNginxが生成したスナップショットコンテンツを表示し、WordPress関連のバックエンドがダウンした場合はVarnishがキャッシュされていないコンテンツにスナップショットを使用し、3つ目はフロントエンドのNginxが応答しない場合のエラーページです。

Varnishの仕組みはDiscourseでは使えませんが、Dockerの世界でも50xエラーが発生した際にエラーページを表示するような複雑なシステム（スパイダーウェブのようなもの）を構築できない理由は見当たりません。

ただし、そのようなシステムは非常にエラーを引き起こしやすいものになるでしょう。そして、ユーザーが数十人を超えた場合に何が起こるのか、私には全く見当もつきません。

もちろん、最も明らかな解決策もあります：Discourseの前にNginxを配置するということです。2コンテナ構成に移行する以前、私はその方法を使っていました。