← すべての移行ガイド

競合製品への移行ガイド

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

標準的な TLS、プロキシ、ヘルス、ポリシー、および可観測性が十分である場合、カスタム Pingora エッジサービスを宣言型の Webship ルートに置き換えてください。

Webship 1.1.0 に適用されますRust + YAML

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

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

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

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

代表的なPingora構成
let mut server = Server::new(None)?;
server.bootstrap();
let mut proxy = http_proxy_service(
    &server.configuration, MyProxy::new("127.0.0.1:8080"),
);
proxy.add_tcp("0.0.0.0:443");
server.add_service(proxy);
server.run_forever();
同等のWebship TOML
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 の設定領域を見つけ、実際の設定と実行時の動作を確認してください。

現在の概念または指針Webship設定ターゲット
listener / frontendlisten + [reverse_proxy.protocols]
host + path matcher[[reverse_proxy.routes]]
backend / cluster / service[[reverse_proxy.upstreams]]
health probe[[reverse_proxy.upstreams]].health_check_*
request limits and timeouts[[reverse_proxy.policies]]
certificate and private key[reverse_proxy.tls] / [[sites]] cert + key

可逆の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