Déployer un changement sans temps d'arrêt

Goal

Une nouvelle image servant le trafic sans interruption, et un retour automatique à la précédente si elle ne devient pas saine.

Before you start

• Un déploiement avec une vérification de santé de type exec qui s’exécute réellement. La disponibilité est incernable sans une telle vérification, et la précondition est vérifiée.
• Aucun volume nommé en lecture-écriture, aucun montage liant inscriptible et aucun port de nœud publié : deux versions ne peuvent pas partager ces éléments.
• Votre propre attestation que deux versions peuvent brièvement s’exécuter en même temps. Cela n’est jamais déduit.

Dashboard

Steps

1. Ouvrez le déploiement et choisissez Stratégie de mise à jour.
2. Choisissez la stratégie progressive, confirmez que les versions concurrentes sont autorisées, et définissez les comptes de surcharge et d’indisponibilité.
3. Définissez le délai d’attente de santé, le temps de séjour et la limite pour l’ensemble de la mise à jour progressive.
4. Choisissez ce qui se passe si elle ne se termine pas : pause, ou retour en arrière.
5. Changez l’image et déployez.

YAML manifest

Steps

1. Ajoutez un bloc update à la spécification, avec la stratégie, l’attestation et les temporisations.
2. Changez l’image dans le même document.
3. Appliquez-le. Les noms de champs et les valeurs par défaut se trouvent dans la référence du déploiement.

REST API

Steps

1. PUT /api/v1/deployments/{name} portant la politique de mise à jour et la nouvelle image.
2. GET /api/v1/deployments/{name} pour observer les répliques se relayer.
3. POST /api/v1/deployments/{name}/rollback pour revenir manuellement à la révision précédente.

CLI

Steps

1. odysseus rollback et odysseus history inspectent et inversent une mise à jour progressive.
2. La modification elle-même passe par l’API ou le tableau de bord : odysseus deploy écrit le chemin plat hérité que le plan de contrôle ne réconcilie plus, et l’indique lors de son exécution.

Verify

Le nombre de répliques ne descend jamais en dessous du minimum que vous avez déclaré pendant le changement, et le déploiement se termine sur la nouvelle image avec chaque réplique en bonne santé.

Changer uniquement le nombre de répliques n’est pas une mise à jour progressive, et n’en nécessite pas une. Élargir ou réduire la flotte ajoute ou supprime des conteneurs et laisse ceux déjà en cours d’exécution en place, la seule chose à vérifier est donc le nouveau nombre. La plateforme décide si un conteneur existant doit être remplacé en le comparant à la forme à partir de laquelle il a été construit, et le nombre de répliques ne fait pas partie de cette forme — c’est combien, pas quoi.

Evidence this worked

GET /api/v1/deployments/{name}/history répertorie la révision qui a été créée, et l’image actuelle du déploiement est la nouvelle. Un rollback déclenché laisse la révision précédente courante — l’historique est ce qui vous permet de distinguer « ça a fonctionné » de « ça a été annulé pour vous ».

When it fails

• La mise à jour progressive est refusée à l’application. Une stratégie graduelle a quatre préconditions et le refus nomme celle qui a échoué. La plus courante est l’attestation manquante indiquant que deux versions peuvent coexister.
• La vérification de santé est présente mais ne produit aucune sonde. C’est refusé maintenant, et c’est pourquoi la précondition est devenue significative — voir vérifications de santé et récupération des processus.
• La mise à jour progressive s’arrête en cours de route. Elle a atteint la limite que vous avez définie et a exécuté l’action d’échec que vous avez choisie.
• Chaque code : rejets et altérations.