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

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

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

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

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

upstream app {
  server 127.0.0.1:8080;
  server 127.0.0.1:8081;
}
server {
  listen 443 ssl http2;
  server_name app.example.com;
  location / { proxy_pass http://app; }
}

listen = "0.0.0.0:443"
workers = 4

[reverse_proxy]
enabled = true
connect_timeout_ms = 2000
max_retries = 0

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

[reverse_proxy.tls]
cert = "/etc/letsencrypt/live/app.example.com/fullchain.pem"
key = "/etc/letsencrypt/live/app.example.com/privkey.pem"

[[reverse_proxy.routes]]
domain = "app.example.com"
path_prefix = "/"
upstreams = ["127.0.0.1:8080", "127.0.0.1:8081"]
load_balancing = "weighted-peak-ewma"

[[reverse_proxy.upstreams]]
address = "127.0.0.1:8080"
protocol = "http1"
health_check_path = "/health"
health_check_interval_ms = 5000
health_check_timeout_ms = 1000

[[reverse_proxy.upstreams]]
address = "127.0.0.1:8081"
protocol = "http1"
health_check_path = "/health"
health_check_interval_ms = 5000
health_check_timeout_ms = 1000

[[reverse_proxy.policies]]
name = "default"
hosts = []
path_prefixes = ["/"]
methods = []
max_body_bytes = 1048576
total_timeout_ms = 30000

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

技術指示は必ずしも一対一で一致するわけではありません。この表を使って対応する 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