Migrera från Envoy till Webship utan en blind övergång.

Definiera migrationsgränsen innan trafik ändras.

Börja med att endast flytta det beteende som Webship kan reproducera och validera. Lämna applikationsautentisering, tjänsteupptäckt, skript och specialiserade cache-regler på den befintliga origin tills deras ersättningar passerar produktionsliknande tester.

Översätt den minsta produktionsvägen först.

Källfragmentet identifierar migrationskonceptet; Webship-fragmentet visar målsformen. Byt ut exempel på domäner, adresser, certifikat, begränsningar och hälsostigar med värden som är validerade för din miljö.

static_resources:
  listeners:
    - name: https
      address: { socket_address: { address: 0.0.0.0, port_value: 443 } }
  clusters:
    - name: app
      load_assignment:
        cluster_name: app
        endpoints: []

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

Kartlägg koncept, inte syntax.

Tekniska direktiv matchar inte alltid ett-till-ett. Använd denna tabell för att hitta motsvarande Webship konfigurationsområde, och validera sedan den effektiva konfigurationen och runtime-beteendet.

Använd en reversibel femstegsöverlämning.

Håll den gamla lyssnaren redo tills Webship har passerat korrekthet, kapacitet, säkerhet, observerbarhet och återställningsgrindar på representativ trafik.

1. 1

   Inventera observerbart beteende

   Registrera lyssnare, domäner, rutter, upstreams, certifikat, omskrivningar, autentisering, cache-regler, hälsoprob, begränsningar och operativa integrationer.

2. 2

   Översätt en gräns

   Flytta en host eller rutt in i strikt TOML. Behåll leverantörsspecifika moduler och applikationslogik bakom Webship tills separata ersättningar är bevisade.

3. 3

   Validera offline och lokalt

   Kör --check-config och --print-effective-config, granska det redigerade resultatet, kontrollera hälsan lokalt, och använd TLS över både TCP och UDP när HTTP/3 är aktiverat.

4. 4

   Canary verklig trafik

   Skicka en liten, observerbar trafikdel till Webship. Jämför statuskoder, headers, kroppar, latens, upstream-hälsa, cache-beteende, loggar och säkerhetsbeslut.

5. 5

   Främja med återställningsmöjlighet redo

   Öka trafik i mätta steg. Håll det tidigare målet hälsosamt och omedelbart routbart tills det överenskomna observationsfönstret och lastportarna passerar.

Validera först. Återgå genom att dirigera om, inte genom att redigera live.

Validera kandidatfilen, inspektera den redigerade effektiva konfigurationen och undersök den privata lyssnaren innan du ändrar trafik. Bevara den gamla binären, konfigurationen, lyssnaren och DNS- eller lastbalanseringsmålet tills observationsfönstret stängs.

/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