Guide de migration d'un concurrent
Migrer de HAProxy à Webship sans une coupure aveugle.
Déplacez les frontaux et backends HTTP, les contrôles de santé, l'équilibrage, les délais d'attente et la gestion des certificats dans Webship tout en préservant une voie de retour rapide.
Définissez la limite de migration avant de changer le trafic.
Commencez par déplacer uniquement le comportement que Webship peut reproduire et valider. Laissez l'authentification des applications, la découverte de services, les scripts et les règles de cache spécialisées sur l'origine existante jusqu'à ce que leurs remplacements réussissent des tests similaires à la production.
Traduisez d'abord le plus petit chemin de production.
Le fragment source identifie le concept de migration ; le fragment Webship montre la forme cible. Remplacez les domaines d'exemple, adresses, certificats, limites et chemins de santé par des valeurs validées pour votre environnement.
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 checklisten = "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 = 30000Cartographiez les concepts, pas la syntaxe.
Les directives techniques ne correspondent pas toujours un à un. Utilisez ce tableau pour localiser la zone de configuration équivalente Webship, puis validez la configuration effective et le comportement à l'exécution.
| Concept ou directive actuel(le) | Cible de configuration Webship |
|---|---|
listener / frontend | listen + [reverse_proxy.protocols] |
host + path matcher | [[reverse_proxy.routes]] |
backend / cluster / service | [[reverse_proxy.upstreams]] |
health probe | [[reverse_proxy.upstreams]].health_check_* |
request limits and timeouts | [[reverse_proxy.policies]] |
certificate and private key | [reverse_proxy.tls] / [[sites]] cert + key |
Utilisez un basculement réversible en cinq étapes.
Gardez l'ancien écouteur prêt jusqu'à ce que Webship ait passé les étapes de correction, de capacité, de sécurité, d'observabilité et de retour arrière sur un trafic représentatif.
- 1
Comportement observable de l'inventaire
Enregistrez les écouteurs, domaines, routes, upstreams, certificats, réécritures, authentification, règles de cache, sondes de santé, limites et intégrations opérationnelles.
- 2
Traduire une frontière
Déplacer un hôte ou une route dans un TOML strict. Conserver les modules spécifiques au fournisseur et la logique applicative derrière Webship jusqu'à ce que des remplacements séparés soient prouvés.
- 3
Valider hors ligne et localement
Exécuter --check-config et --print-effective-config, inspecter le résultat expurgé, tester la santé localement, et utiliser TLS sur TCP et UDP lorsque HTTP/3 est activé.
- 4
Trafic réel en canari
Envoyez un petit échantillon de trafic observable vers Webship. Comparez les codes d'état, les en-têtes, les corps, la latence, la santé en amont, le comportement du cache, les journaux et les décisions de sécurité.
- 5
Promouvoir avec possibilité de retour en arrière
Augmenter le trafic dans les étapes mesurées. Maintenir la cible précédente en bonne santé et immédiatement routable jusqu'à ce que la fenêtre d'observation convenue et les passages de charge soient dépassés.
Validez d'abord. Restaurez en utilisant le routage, pas en modifiant le système en direct.
Validez le fichier candidat, inspectez la configuration effective expurgée et examinez l'auditeur privé avant de changer le trafic. Conservez l'ancien binaire, la configuration, l'auditeur, ainsi que la cible DNS ou de l'équilibreur de charge jusqu'à la fin de la fenêtre d'observation.
/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