Průvodce migrací konkurence
Migrovat z Bun.serve na Webship bez slepého přepnutí.
Oddělte aplikační kód od okrajových úloh: zachovejte Bun jako výchozí bod, zatímco Webship převezme TLS, statické doručování, HTTP/3, ochranu a směrování požadavků.
Definujte hranici migrace před změnou provozu.
Začněte přesouváním pouze chování, které Webship dokáže reprodukovat a ověřit. Nechte autentizaci aplikace, objevování služeb, skripty a specializovaná cache pravidla na stávajícím původu, dokud jejich náhrady neprojdou testy podobnými produkčním.
Nejprve přeložte nejmenší výrobní cestu.
Zdrojový fragment identifikuje migrační koncept; fragment Webship ukazuje cílový tvar. Nahraďte příkladné domény, adresy, certifikáty, limity a zdravotní cesty hodnotami ověřenými pro vaše prostředí.
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 = trueMapujte koncepty, ne syntaxi.
Technická vodítka se ne vždy shodují jeden ku jednomu. Použijte tuto tabulku k nalezení ekvivalentní konfigurační oblasti Webship, poté ověřte účinnou konfiguraci a runtime chování.
| Současný koncept nebo směrnice | Cíl konfigurace Webship |
|---|---|
listener / virtual host | listen + [reverse_proxy.protocols] |
document root | [[sites]].root |
host matcher | [[reverse_proxy.routes]] |
certificate and private key | [reverse_proxy.tls] / [[sites]] cert + key |
Použijte reverzibilní pětikrokový přechod.
Držte starého posluchače připraveného, dokud Webship neprojde kontrolou správnosti, kapacity, bezpečnosti, sledovatelnosti a možností návratu zpět na reprezentativním provozu.
- 1
Inventář pozorovatelného chování
Zaznamenejte posluchače, domény, trasy, upstreamy, certifikáty, přepisování, autentizaci, pravidla cache, zdravotní sondy, limity a operační integrace.
- 2
Přeložte jednu hranici
Přesuňte jeden hostitel nebo trasu do přísného TOML. Zachovejte moduly specifické pro dodavatele a aplikační logiku za Webship, dokud nebudou ověřeny samostatné náhrady.
- 3
Ověřte offline a lokálně
Spusťte --check-config a --print-effective-config, zkontrolujte zredigovaný výsledek, prověřte stav lokálně a testujte TLS přes TCP i UDP, když je HTTP/3 povoleno.
- 4
Kanárkový skutečný provoz
Pošlete malý, pozorovatelný úsek provozu do Webship. Porovnejte stavové kódy, hlavičky, těla, latenci, stav upstream, chování cache, záznamy a bezpečnostní rozhodnutí.
- 5
Propagovat s připraveným návratem
Zvyšte provoz ve měřených fázích. Udržujte předchozí cíl zdravý a okamžitě směrovatelný až do uplynutí dohodnutého okna pozorování a průchodu zatížením.
Nejdříve ověřte. Vrácení zpět proveďte směrováním, ne úpravou živého provozu.
Ověřte kandidátský soubor, zkontrolujte redigovanou účinnou konfiguraci a prozkoumejte soukromého posluchače před změnou provozu. Zachovejte starý binární soubor, konfiguraci, posluchače a cíle DNS nebo load-balanceru, dokud neuplyne doba pozorování.
/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