Diagramme des stratégies de déploiement : rolling, blue-green et canary

La plupart des pannes commencent par un déploiement. Le code a passé la revue et les tests, puis il rencontre le vrai trafic, les vraies données et les vraies dépendances. Une stratégie de déploiement décide quelle part de votre trafic rencontre la nouvelle version en même temps, à quelle vitesse vous remarquez un problème, et à quelle vitesse vous pouvez revenir en arrière.

Cet article compare les trois stratégies entre lesquelles la plupart des équipes choisissent : rolling update, blue-green et canary. Il montre comment le trafic se déplace dans chaque cas et à quoi ressemble un retour arrière, puis se termine par le diagramme d'un déploiement canary où la décision de continuer ou de revenir en arrière est automatisée.

Rolling update

Remplacez les instances de l'ancienne version par la nouvelle quelques-unes à la fois. Les Deployments Kubernetes le font par défaut : avec la stratégie RollingUpdate, maxSurge et maxUnavailable fixent combien de pods en plus et en moins sont permis pendant le rollout, et les deux valent 25 % par défaut.

• Trafic : pendant le rollout, les deux versions servent des requêtes en même temps, au prorata de leur nombre de pods.
• Retour arrière : un autre rolling update vers l'ancienne version. Des minutes, pas des secondes.
• Coût : presque rien en plus ; au maximum la capacité de surge.
• Risque : chaque utilisateur peut tomber tôt sur la nouvelle version, et les readiness probes sont le seul garde-fou automatique. Une version qui démarre bien mais échoue sous charge est déployée entièrement.

Le rolling update est le bon choix par défaut pour les changements peu risqués et les services internes bien testés et dotés de bonnes probes. Faites vérifier par la readiness probe ce dont le service a besoin pour fonctionner, pas seulement que le processus tourne, sinon le rollout remplacera allègrement des pods sains par des pods cassés.

Blue-green

Faites tourner deux environnements complets. Blue sert la production ; green reçoit la nouvelle version et est testé sur place. Ensuite, le load balancer ou le DNS bascule tout le trafic de blue vers green d'un coup. La description du déploiement blue-green par Martin Fowler est la référence classique.

• Trafic : tout sur blue, puis tout sur green. Jamais les deux, du moins pas longtemps.
• Retour arrière : rebasculer vers blue, qui tourne toujours. Des secondes.
• Coût : le double de capacité tant que les deux sont actifs.
• Risque : la bascule déplace 100 % des utilisateurs d'un coup, donc un problème qui n'apparaît qu'avec le vrai trafic touche tout le monde. La base de données est partagée, donc les changements de schéma doivent fonctionner avec les deux versions.

Canary

Envoyez une petite part du vrai trafic, disons 5 %, vers la nouvelle version, comparez-la avec la version stable et augmentez la part par étapes si elle se comporte bien. Le nom vient du canari dans la mine de charbon ; voir l'article sur le canary release sur le site de Fowler.

• Trafic : réparti par poids, par en-tête ou par segment d'utilisateurs.
• Retour arrière : mettre le poids du canary à zéro. Des secondes, et seuls quelques pour cent des utilisateurs ont été exposés.
• Coût : quelques pods de plus, plus l'outillage de répartition du trafic et d'analyse.
• Risque : le plus faible des trois, si vous surveillez les bonnes métriques. Un canary que personne ne surveille n'est qu'un rolling update lent.

Côte à côte

La dernière ligne est la même partout pour une raison : quelle que soit la stratégie, deux versions du code rencontrent à un moment la même base de données. Utilisez des migrations expand-and-contract : ajoutez d'abord les nouvelles colonnes et tables, déployez du code qui fonctionne avec les deux formes, puis retirez l'ancienne forme dans une version ultérieure.

Du trafic miroir avant le canary

Certaines équipes ajoutent une étape avant le canary : copier une part des requêtes de production vers la nouvelle version et jeter ses réponses. Envoy et Istio savent dupliquer le trafic ainsi. Cela détecte les crashs et les régressions de latence sans aucun impact sur les utilisateurs, mais seulement pour les lectures et les requêtes idempotentes. Les écritures dupliquées répètent leurs effets de bord, comme les e-mails, les paiements et les mouvements de stock : gardez-les hors du miroir ou faites pointer la version miroir vers des dépendances isolées en bac à sable.

Automatiser la décision du canary

La valeur d'un canary vient de la comparaison, et les humains sont mauvais pour surveiller des tableaux de bord pendant une heure. Des outils comme Argo Rollouts et Flagger l'automatisent sur Kubernetes : ils déplacent le trafic par étapes, interrogent votre fournisseur de métriques entre les étapes, et promeuvent ou annulent selon les seuils que vous définissez.

Les bonnes métriques d'analyse sont peu nombreuses et proches de l'utilisateur :

• Le taux d'erreur (réponses 5xx) du canary, comparé à la version stable.
• La latence à un percentile élevé, comme le p99.
• Un signal métier si possible, comme le nombre de paiements finalisés par minute.

Comparez le canary à la version stable, pas à un chiffre fixe, pour qu'une mauvaise nuit d'une dépendance ne fasse pas échouer chaque déploiement.

Le diagramme d'architecture

Comment le lire :

• En haut, le chemin du trafic : les utilisateurs atteignent l'ingress, qui envoie 95 % des requêtes au ReplicaSet stable et 5 % au canary. Les deux remontent leurs métriques.
• En bas, la boucle de contrôle : la CI remet la nouvelle image au contrôleur de rollout. Le contrôleur règle les poids de l'ingress (arête en pointillé), lit le taux d'erreur et la latence p99 des deux versions, et décide.
• La décision : dans les seuils, passer à l'étape suivante ; hors des seuils, annuler et renvoyer tout le trafic vers v1.
• Le bloc Markdown liste les étapes et la règle d'annulation, qui ont leur place dans la revue de la configuration de rollout de chaque service.

Les feature flags, quatrième stratégie

Une stratégie de déploiement contrôle quels serveurs exécutent le nouveau code. Un feature flag contrôle quels utilisateurs voient un nouveau comportement, indépendamment des déploiements. Les équipes qui livrent souvent combinent les deux : déployer en rolling update ou en canary, garder les fonctionnalités risquées derrière un flag et l'activer progressivement. Le flag est le retour arrière le plus rapide, puisque rien n'a besoin d'être redéployé.

Ce qu'il faut mettre sur un diagramme de déploiement

• Les pourcentages de trafic sur les arêtes. Ils changent pendant un rollout ; montrez la première étape.
• Qui modifie les poids. Un contrôleur, un pipeline ou une personne.
• Les critères d'annulation. Des chiffres, pas « si ça a l'air mauvais ».
• La base de données, avec une note indiquant que les changements de schéma suivent l'approche expand-and-contract.

Le diagramme de pipeline CI/CD montre les étapes de build et de test qui précèdent, le diagramme d'architecture Kubernetes couvre le cluster, et le diagramme d'architecture d'observabilité montre d'où viennent les métriques.

Le construire dans Archboard

1. Connectez-vous avec Google ou GitHub et créez un diagramme.
2. Ajoutez une Personne pour les utilisateurs, ainsi qu'un Ingress et deux nœuds ReplicaSet du pack Kubernetes pour la version stable et le canary.
3. Ajoutez Métriques et un Pipeline CI/CD du pack DevOps, et un Conteneur du pack Modèle C4 pour le contrôleur de rollout.
4. Ajoutez une Décision, un Processus et un Début / Fin du pack Logigramme pour la promotion et l'annulation.
5. Étiquetez les arêtes de l'ingress avec les poids du trafic, dessinez les changements de poids en arête pointillée et ajoutez un bloc Markdown du pack Base avec les étapes.

L'exemple utilise 11 nœuds de diagramme et reste dans les limites de l'offre Free.

FAQ

Quelle stratégie de déploiement est la meilleure ? Cela dépend du risque et de l'outillage. Le rolling update convient à la plupart des changements peu risqués ; le canary aux services exposés aux utilisateurs, où une mauvaise version coûte cher ; le blue-green aux systèmes qui ont besoin de bascules instantanées et complètes et peuvent se permettre le double de capacité.

Quelle est la différence entre blue-green et canary ? Le blue-green bascule tout le trafic d'un coup et garde l'ancien environnement pour un retour arrière instantané. Le canary déplace d'abord une petite part du trafic et ne l'élargit que quand la nouvelle version a fait ses preuves.

Comment gérer les migrations de base de données pendant un déploiement ? Rendez chaque changement de schéma rétrocompatible : étendez d'abord, déployez du code qui fonctionne avec les deux formes, puis contractez dans une version ultérieure.

Quelles métriques utiliser pour l'analyse d'un canary ? Le taux d'erreur et la latence à un percentile élevé, comparés à la version stable, plus une métrique métier si vous pouvez la mesurer rapidement.

Les feature flags sont-ils une stratégie de déploiement ? Ce sont une stratégie de mise en production (release). Ils découplent l'activation d'une fonctionnalité du déploiement du code, et se combinent bien avec chacune des trois stratégies de déploiement.

Commencez gratuitement — un siège, sans carte bancaire.