ブラインドカットオーバーなしで Bun.serve から Webship へ移行

トラフィックを変更する前に、移行境界を定義してください。

まず、Webship が再現および検証できる動作だけを移動します。アプリケーション認証、サービスディスカバリ、スクリプト、専門的なキャッシュルールは、置き換えが本番同様のテストを通過するまで、既存のオリジンに残しておきます。

最小の本番パスを最初に翻訳してください。

ソースフラグメントは移行の概念を識別します。Webship フラグメントはターゲットの形状を示します。例のドメイン、アドレス、証明書、制限、およびヘルスパスを、環境で検証された値に置き換えてください。

Bun.serve({
  port: 443,
  tls: { cert: Bun.file("cert.pem"), key: Bun.file("key.pem") },
  routes: {
    "/": new Response(Bun.file("./public/index.html")),
  },
});

listen = "0.0.0.0:443"
workers = 4

[[sites]]
domain = "app.example.com"
root = "/srv/app/public"
listen = "0.0.0.0:443"
cert = "/etc/letsencrypt/live/app.example.com/fullchain.pem"
key = "/etc/letsencrypt/live/app.example.com/privkey.pem"

[sites.protocols]
h1 = true
h2 = true
h3 = true

構文ではなく概念を対応させる

技術指示は必ずしも一対一で一致するわけではありません。この表を使って対応する Webship の設定領域を見つけ、実際の設定と実行時の動作を確認してください。

可逆の5ステップのカットオーバーを使用してください。

代表的なトラフィックで Webship が正確さ、容量、セキュリティ、監視性、およびロールバックのゲートを通過するまで、古いリスナーを準備したままにしてください。

1. 1

   在庫の観察可能な行動

   リスナー、ドメイン、ルート、アップストリーム、証明書、リライト、認証、キャッシュルール、ヘルスプローブ、制限、および運用統合を記録します。

2. 2

   1つの境界を翻訳する

   1台のホストまたはルートを厳密なTOMLに移動します。Webshipの背後でベンダー固有のモジュールとアプリケーションロジックを保持し、別の置き換えが証明されるまで維持します。

3. 3

   オフラインおよびローカルで検証する

   --check-configおよび--print-effective-configを実行し、編集された結果を確認し、ローカルで健全性を検査し、HTTP/3が有効な場合はTCPおよびUDPの両方でTLSを使用して操作します。

4. 4

   カナリア実トラフィック

   小さく観測可能なトラフィックのスライスをWebshipに送信します。ステータスコード、ヘッダー、本文、レイテンシ、アップストリームの状態、キャッシュの動作、ログ、セキュリティの判断を比較します。

5. 5

   ロールバック準備が整った状態で昇格させる

   測定された段階でのトラフィックを増加させます。以前のターゲットは健全で、合意された観察ウィンドウと負荷ゲートを通過するまで即座にルーティング可能な状態に保ちます。

まず検証してください。ライブを編集するのではなく、ルーティングでロールバックしてください。

候補ファイルを検証し、編集された有効な設定を確認し、トラフィックを変更する前にプライベートリスナーを調査してください。観察ウィンドウが閉じるまで、古いバイナリ、設定、リスナー、およびDNSまたはロードバランサのターゲットを保持してください。

/usr/local/bin/webship --check-config --config /etc/webship/production.toml
/usr/local/bin/webship --print-effective-config --config /etc/webship/production.toml
curl --http3-only --insecure https://127.0.0.1:443/health