Migreer van NGINX naar Webship zonder een blinde omschakeling.

Definieer de migratiegrens voordat het verkeer wordt veranderd.

Begin met het verplaatsen van alleen het gedrag dat Webship kan reproduceren en valideren. Laat applicatie-authenticatie, serviceherkenning, scripts en gespecialiseerde cacheregels op de bestaande oorsprong totdat hun vervangingen tests in productielike omstandigheden doorstaan.

Vertaal eerst het kleinste productiepad.

Het bronfragment identificeert het migratieconcept; het Webship-fragment toont de doelvorm. Vervang voorbeeld-domeinen, adressen, certificaten, limieten en health-paden door waarden die gevalideerd zijn voor je omgeving.

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

Koppel concepten, niet syntax.

Technische richtlijnen komen niet altijd één-op-één overeen. Gebruik deze tabel om het equivalente Webship configuratiegebied te vinden en valideer vervolgens de effectieve configuratie en runtime-gedrag.

Gebruik een omkeerbare vijf-stappen overschakeling.

Houd de oude listener gereed totdat Webship de correctheid, capaciteit, beveiliging, observeerbaarheid en rollback-poorten op representatief verkeer heeft doorstaan.

1. 1

   Inventariseer waarneembaar gedrag

   Registreer luisteraars, domeinen, routes, upstreams, certificaten, herschrijvingen, authenticatie, cache regels, gezondheidsprobes, limieten en operationele integraties.

2. 2

   Vertaal één grens

   Verplaats één host of route naar strikt TOML. Behoud leveranciersspecifieke modules en applicatielogica achter Webship totdat afzonderlijke vervangingen zijn bewezen.

3. 3

   Valideer offline en lokaal

   Voer --check-config en --print-effective-config uit, inspecteer het geredigeerde resultaat, controleer lokaal de gezondheid en gebruik TLS over zowel TCP als UDP wanneer HTTP/3 is ingeschakeld.

4. 4

   Canary echt verkeer

   Stuur een klein, observeerbaar verkeersfragment naar Webship. Vergelijk statuscodes, headers, inhoud, latentie, upstream gezondheid, cachegedrag, logs en beveiligingsbeslissingen.

5. 5

   Promoot met terugroloptie gereed

   Verhoog het verkeer in de gemeten fasen. Houd het vorige doel gezond en onmiddellijk routeerbaar totdat het overeengekomen observatieraam en de belastingsdrempels zijn gepasseerd.

Valideer eerst. Rol terug door te routeren, niet door live te bewerken.

Valideer het kandidaatbestand, inspecteer de geanonimiseerde werkende configuratie en onderzoek de privéluisteraar voordat je het verkeer wijzigt. Bewaar de oude binary, configuratie, luisteraar en DNS- of load-balancerdoel totdat het observatievenster sluit.

/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