Migrare da Bun.serve 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.

Bun.serve({
  port: 443,
  tls: { cert: Bun.file("cert.pem"), key: Bun.file("key.pem") },
  routes: {
    "/": new Response(Bun.file("./public/index.html")),
  },
});

listen = "0.0.0.0:443"
workers = 4

[[sites]]
domain = "app.example.com"
root = "/srv/app/public"
listen = "0.0.0.0:443"
cert = "/etc/letsencrypt/live/app.example.com/fullchain.pem"
key = "/etc/letsencrypt/live/app.example.com/privkey.pem"

[sites.protocols]
h1 = true
h2 = true
h3 = true

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