← Wszystkie przewodniki migracji

Przewodnik migracji konkurencji

Migruj z Bun.serve do Webship bez ślepego przeniesienia.

Oddziel kod aplikacji od obowiązków brzegowych: zachowaj Bun jako źródło, podczas gdy Webship przejmuje TLS, dostarczanie statyczne, HTTP/3, ochronę i trasowanie żądań.

Dotyczy Webship 1.1.0TypeScript

Zdefiniuj granice migracji przed zmianą ruchu.

Rozpocznij od przeniesienia tylko tych zachowań, które Webship potrafi odtworzyć i zweryfikować. Pozostaw uwierzytelnianie aplikacji, odkrywanie usług, skrypty i specjalistyczne reguły pamięci podręcznej na istniejącym źródle do momentu, gdy ich zamienniki przejdą testy produkcyjnie podobne.

Przetłumacz najpierw najmniejszą ścieżkę produkcyjną.

Fragment źródłowy identyfikuje koncepcję migracji; fragment Webship pokazuje docelowy kształt. Zastąp przykładowe domeny, adresy, certyfikaty, limity i ścieżki zdrowotne wartościami zweryfikowanymi dla Twojego środowiska.

Reprezentatywna konfiguracja 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")),
  },
});
Równoważny 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

Mapuj koncepcje, nie składnię.

Dyrektywy techniczne nie zawsze pasują jeden do jednego. Użyj tej tabeli, aby znaleźć odpowiadający obszar konfiguracji Webship, a następnie zweryfikuj efektywną konfigurację i zachowanie w czasie pracy.

Aktualna koncepcja lub dyrektywaCel konfiguracji 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

Użyj odwracalnej, pięciostopniowej zmiany.

Utrzymuj starego słuchacza gotowego, dopóki Webship nie przejdzie przez bramki poprawności, wydajności, bezpieczeństwa, obserwowalności i wycofania na reprezentatywnym ruchu.

  1. 1

    Obserwowalne zachowanie inwentarza

    Zarejestruj nasłuchiwacze, domeny, trasy, upstreamy, certyfikaty, przekierowania, autoryzację, reguły pamięci podręcznej, sondy zdrowia, limity i integracje operacyjne.

  2. 2

    Przetłumacz jedną granicę

    Przenieś jeden host lub trasę do ścisłego TOML. Zachowaj moduły specyficzne dla dostawcy i logikę aplikacji za Webship, aż osobne zamienniki zostaną potwierdzone.

  3. 3

    Weryfikuj offline i lokalnie

    Uruchom --check-config i --print-effective-config, sprawdź zredagowany wynik, zbadaj lokalne zdrowie i testuj TLS zarówno przez TCP, jak i UDP, gdy HTTP/3 jest włączone.

  4. 4

    Ruch rzeczywisty Canary

    Wyślij mały, obserwowalny fragment ruchu do Webship. Porównaj kody statusu, nagłówki, treści, opóźnienia, stan upstream, zachowanie pamięci podręcznej, logi i decyzje dotyczące bezpieczeństwa.

  5. 5

    Promuj z możliwością wycofania

    Zwiększ ruch w mierzonych etapach. Utrzymuj poprzedni cel w stanie zdrowym i natychmiastowym do routingu, aż do zakończenia uzgodnionego okna obserwacji i przejścia bramek obciążenia.

Najpierw zweryfikuj. Cofaj przy użyciu routingu, a nie edytując na żywo.

Zweryfikuj plik kandydata, sprawdź zredagowaną skuteczną konfigurację i zbadaj prywatny nasłuchiwacz przed zmianą ruchu. Zachowaj stary plik binarny, konfigurację, nasłuchiwacz oraz cel DNS lub load-balancera, dopóki nie zakończy się okres obserwacji.

/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