Migruj z Lighttpd do Webship bez ślepego przeniesienia.

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.

server.port = 443
$HTTP["host"] == "app.example.com" {
  proxy.server = ("" => (
    ("host" => "127.0.0.1", "port" => 8080)
  ))
}

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

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.

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