Migrează de la NGINX la Webship fără o trecere bruscă.

Definiți limita migrației înainte de a schimba traficul.

Începeți prin a muta doar comportamentul Webship care poate fi reprodus și validat. Lăsați autentificarea aplicației, descoperirea serviciilor, scripturile și regulile speciale de cache pe originea existentă până când înlocuirile lor trec testele similare cu cele de producție.

Traduceți mai întâi cea mai mică cale de producție.

Fragmentul sursă identifică conceptul de migrare; fragmentul Webship arată forma țintă. Înlocuiește domeniile, adresele, certificatele, limitele și căile de sănătate exemplu cu valori validate pentru mediul tău.

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

Mapează conceptele, nu sintaxa.

Directiva tehnică nu se potrivește întotdeauna unu-la-unu. Folosește acest tabel pentru a localiza zona echivalentă de configurare Webship, apoi validează configurația efectivă și comportamentul la rulare.

Folosiți un transfer reversibil în cinci pași.

Păstrați vechiul ascultător gata până când Webship a trecut de verificările de corectitudine, capacitate, securitate, observabilitate și rollback pe trafic reprezentativ.

1. 1

   Comportament observabil al inventarului

   Înregistrați ascultători, domenii, rute, upstream-uri, certificate, rescrieri, autentificare, reguli de cache, probe de sănătate, limite și integrări operaționale.

2. 2

   Tradu un singur boundary

   Mută un singur host sau rută în TOML strict. Păstrează modulele și logica aplicației specifice furnizorului în spatele Webship până când înlocuirile separate sunt dovedite.

3. 3

   Validați offline și local

   Rulează --check-config și --print-effective-config, inspectează rezultatul cenzurat, verifică sănătatea local și exercită TLS atât peste TCP, cât și UDP atunci când HTTP/3 este activat.

4. 4

   Trafic real canary

   Trimiteți o mică secțiune de trafic observabil la Webship. Comparați codurile de stare, antetele, corpurile, latența, sănătatea upstream, comportamentul cache, jurnalele și deciziile de securitate.

5. 5

   Promovează cu revenire pregătită

   Crește traficul în etapele măsurate. Menține ținta anterioară sănătoasă și imediat rutabilă până când fereastra de observație și porțile de încărcare convenite trec.

Validați mai întâi. Revenirea se face prin rutare, nu prin editarea în direct.

Validați fișierul candidat, inspectați configurația efectivă redactată și testați ascultătorul privat înainte de a schimba traficul. Păstrați vechiul fișier binar, configurația, ascultătorul și ținta DNS sau a echilibratorului de sarcină până la încheierea ferestrei de observație.

/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