Migrare da HAProxy a Webship senza un cutover cieco.

Definisci il confine della migrazione prima di modificare il traffico.

Inizia spostando solo il comportamento che Webship può riprodurre e convalidare. Lascia l'autenticazione delle applicazioni, il service discovery, gli script e le regole di cache specializzate sull'origine esistente fino a quando i loro sostituti non superano test simili a quelli di produzione.

Traduci prima il percorso di produzione più piccolo.

Il frammento sorgente identifica il concetto di migrazione; il frammento Webship mostra la forma di destinazione. Sostituisci domini di esempio, indirizzi, certificati, limiti e percorsi di salute con valori convalidati per il tuo ambiente.

frontend https
  bind :443 ssl crt /etc/haproxy/app.pem
  default_backend app
backend app
  balance roundrobin
  server app1 127.0.0.1:8080 check
  server app2 127.0.0.1:8081 check

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

Mappa i concetti, non la sintassi.

Le direttive tecniche non corrispondono sempre uno a uno. Usa questa tabella per individuare l'area di configurazione equivalente di Webship, quindi convalida la configurazione effettiva e il comportamento in runtime.

Usa un cutover reversibile in cinque fasi.

Mantieni il vecchio listener pronto fino a quando Webship non ha superato i controlli di correttezza, capacità, sicurezza, osservabilità e rollback sul traffico rappresentativo.

1. 1

   Comportamento osservabile dell'inventario

   Registra listener, domini, percorsi, upstream, certificati, riscritture, autenticazione, regole della cache, probe di salute, limiti e integrazioni operative.

2. 2

   Tradurre un confine

   Spostare un host o una rotta in TOML rigoroso. Mantenere moduli specifici del fornitore e logica applicativa dietro Webship fino a quando le sostituzioni separate non saranno provate.

3. 3

   Convalida offline e localmente

   Eseguire --check-config e --print-effective-config, ispezionare il risultato redatto, verificare la salute localmente ed esercitare TLS su TCP e UDP quando HTTP/3 è abilitato.

4. 4

   Traffico reale canarino

   Invia un piccolo segmento di traffico osservabile a Webship. Confronta codici di stato, intestazioni, corpi, latenza, salute upstream, comportamento della cache, log e decisioni di sicurezza.

5. 5

   Promuovere con possibilità di rollback

   Aumentare il traffico nelle fasi misurate. Mantenere il bersaglio precedente sano e immediatamente instradabile fino a quando la finestra di osservazione concordata e i gate di carico non saranno superati.

Valida prima. Esegui il rollback tramite routing, non modificando in diretta.

Valida il file candidato, ispeziona la configurazione efficace redatta e verifica l'ascoltatore privato prima di cambiare il traffico. Conserva il vecchio binario, la configurazione, l'ascoltatore e l'obiettivo DNS o del bilanciatore di carico fino alla chiusura della finestra di osservazione.

/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