← Toate ghidurile de migrare

Ghid de migrare al concurenței

Migrează de la Bun.serve la Webship fără o trecere bruscă.

Separă codul aplicației de atribuțiile de la margine: păstrează Bun ca origine în timp ce Webship preia TLS, livrarea statică, HTTP/3, protecția și rutarea cererilor.

Se aplică la Webship 1.1.0TypeScript

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.

Configurare reprezentativă Bun.serve
Bun.serve({
  port: 443,
  tls: { cert: Bun.file("cert.pem"), key: Bun.file("key.pem") },
  routes: {
    "/": new Response(Bun.file("./public/index.html")),
  },
});
Echivalent Webship TOML
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

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.

Concept sau directivă curentăȚinta de configurare Webship
listener / virtual hostlisten + [reverse_proxy.protocols]
document root[[sites]].root
host matcher[[reverse_proxy.routes]]
certificate and private key[reverse_proxy.tls] / [[sites]] cert + key

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