Von HAProxy zu Webship migrieren ohne einen blinden Cutover.

Definieren Sie die Migrationsgrenze, bevor Sie den Traffic ändern.

Beginnen Sie damit, nur das Verhalten zu verschieben, das Webship reproduzieren und validieren kann. Lassen Sie Anwendungs-Authentifizierung, Service Discovery, Skripte und spezialisierte Cache-Regeln auf der bestehenden Quelle, bis ihre Ersatzsysteme tests in produktionsähnlicher Umgebung bestehen.

Übersetzen Sie zuerst den kleinsten Produktionspfad.

Das Quellfragment identifiziert das Migrationskonzept; das Webship-Fragment zeigt die Zielstruktur. Ersetzen Sie Beispieldomänen, Adressen, Zertifikate, Limits und Pfade zur Gesundheit durch Werte, die für Ihre Umgebung validiert sind.

frontend https
  bind :443 ssl crt /etc/haproxy/app.pem
  default_backend app
backend app
  balance roundrobin
  server app1 127.0.0.1:8080 check
  server app2 127.0.0.1:8081 check

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

Konzepte abbilden, nicht Syntax.

Technische Richtlinien stimmen nicht immer eins zu eins überein. Verwenden Sie diese Tabelle, um den entsprechenden Webship Konfigurationsbereich zu finden und überprüfen Sie dann die wirksame Konfiguration und das Laufzeitverhalten.

Verwenden Sie einen umkehrbaren Fünf-Schritte-Wechsel.

Halten Sie den alten Listener bereit, bis Webship die Prüfungen auf Korrektheit, Kapazität, Sicherheit, Beobachtbarkeit und Rückrollbarkeit mit repräsentativem Verkehr bestanden hat.

1. 1

   Inventar beobachtbares Verhalten

   Protokollieren Sie Listener, Domains, Routen, Upstreams, Zertifikate, Umschreibungen, Authentifizierung, Cache-Regeln, Gesundheitsprüfungen, Limits und operative Integrationen.

2. 2

   Übersetze eine Grenze

   Verschiebe einen Host oder Pfad in striktes TOML. Behalte vendorspezifische Module und Anwendungslogik hinter Webship, bis separate Ersatzlösungen bewiesen sind.

3. 3

   Offline und lokal validieren

   Führe --check-config und --print-effective-config aus, inspiziere das zensierte Ergebnis, überprüfe die lokale Gesundheit und teste TLS über TCP und UDP, wenn HTTP/3 aktiviert ist.

4. 4

   Canary-Echtverkehr

   Senden Sie einen kleinen, beobachtbaren Verkehrsausschnitt an Webship. Vergleichen Sie Statuscodes, Header, Inhalte, Latenz, Upstream-Gesundheit, Cache-Verhalten, Protokolle und Sicherheitsentscheidungen.

5. 5

   Fördern mit Rückrollbereitstellung

   Erhöhe den Verkehr in gemessenen Phasen. Halte das vorherige Ziel gesund und sofort routbar, bis das vereinbarte Beobachtungsfenster und die Lastgrenzen überschritten sind.

Zuerst validieren. Rollen Sie zurück durch Routing, nicht durch Bearbeitung live.

Überprüfen Sie die Kandidatendatei, inspizieren Sie die geschwärzte effektive Konfiguration und prüfen Sie den privaten Listener, bevor Sie den Datenverkehr ändern. Bewahren Sie das alte Binary, die Konfiguration, den Listener und das DNS- oder Load-Balancer-Ziel auf, bis das Beobachtungsfenster geschlossen ist.

/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