Migrovat z OpenResty na Webship bez slepého přepnutí.

Definujte hranici migrace před změnou provozu.

Začněte přesouváním pouze chování, které Webship dokáže reprodukovat a ověřit. Nechte autentizaci aplikace, objevování služeb, skripty a specializovaná cache pravidla na stávajícím původu, dokud jejich náhrady neprojdou testy podobnými produkčním.

Nejprve přeložte nejmenší výrobní cestu.

Zdrojový fragment identifikuje migrační koncept; fragment Webship ukazuje cílový tvar. Nahraďte příkladné domény, adresy, certifikáty, limity a zdravotní cesty hodnotami ověřenými pro vaše prostředí.

server {
  listen 443 ssl;
  server_name app.example.com;
  location / {
    access_by_lua_file /etc/openresty/auth.lua;
    proxy_pass http://127.0.0.1:8080;
  }
}

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

Mapujte koncepty, ne syntaxi.

Technická vodítka se ne vždy shodují jeden ku jednomu. Použijte tuto tabulku k nalezení ekvivalentní konfigurační oblasti Webship, poté ověřte účinnou konfiguraci a runtime chování.

Použijte reverzibilní pětikrokový přechod.

Držte starého posluchače připraveného, dokud Webship neprojde kontrolou správnosti, kapacity, bezpečnosti, sledovatelnosti a možností návratu zpět na reprezentativním provozu.

1. 1

   Inventář pozorovatelného chování

   Zaznamenejte posluchače, domény, trasy, upstreamy, certifikáty, přepisování, autentizaci, pravidla cache, zdravotní sondy, limity a operační integrace.

2. 2

   Přeložte jednu hranici

   Přesuňte jeden hostitel nebo trasu do přísného TOML. Zachovejte moduly specifické pro dodavatele a aplikační logiku za Webship, dokud nebudou ověřeny samostatné náhrady.

3. 3

   Ověřte offline a lokálně

   Spusťte --check-config a --print-effective-config, zkontrolujte zredigovaný výsledek, prověřte stav lokálně a testujte TLS přes TCP i UDP, když je HTTP/3 povoleno.

4. 4

   Kanárkový skutečný provoz

   Pošlete malý, pozorovatelný úsek provozu do Webship. Porovnejte stavové kódy, hlavičky, těla, latenci, stav upstream, chování cache, záznamy a bezpečnostní rozhodnutí.

5. 5

   Propagovat s připraveným návratem

   Zvyšte provoz ve měřených fázích. Udržujte předchozí cíl zdravý a okamžitě směrovatelný až do uplynutí dohodnutého okna pozorování a průchodu zatížením.

Nejdříve ověřte. Vrácení zpět proveďte směrováním, ne úpravou živého provozu.

Ověřte kandidátský soubor, zkontrolujte redigovanou účinnou konfiguraci a prozkoumejte soukromého posluchače před změnou provozu. Zachovejte starý binární soubor, konfiguraci, posluchače a cíle DNS nebo load-balanceru, dokud neuplyne doba pozorování.

/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