Migrer de Bun.serve à Webship sans une coupure aveugle.

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.

Bun.serve({
  port: 443,
  tls: { cert: Bun.file("cert.pem"), key: Bun.file("key.pem") },
  routes: {
    "/": new Response(Bun.file("./public/index.html")),
  },
});

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

Cartographiez 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.

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. 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. 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. 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. 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. 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