5.2 - Stratégies de déploiement (blue-green, canary, rolling)
L'objectif 5.2 du Cloud+ CV0-004 couvre les stratégies de livraison sûre des changements. Un déploiement blue-green met en place une nouvelle version (green) à côté de l'ancienne (blue) et bascule tout le trafic d'un coup, permettant un retour arrière instantané en rebasculant. Une livraison canary envoie d'abord le changement à un petit pourcentage d'utilisateurs pour limiter le risque, puis élargit si les métriques restent bonnes. Une mise à jour progressive (rolling) remplace les anciennes instances par de nouvelles quelques-unes à la fois jusqu'à ce que tout soit à jour, évitant l'interruption sans environnement dupliqué complet. L'infrastructure immuable met à jour les serveurs en les remplaçant par de nouvelles images plutôt qu'en les patchant sur place, ce qui se marie naturellement avec ces stratégies. Attends-toi à des mises en situation demandant la bonne stratégie - blue-green, canary ou rolling.
Deux versions complètes, basculer tout le trafic d'un coup = blue-green. Petit groupe d'utilisateurs d'abord = canary. Remplacer les instances par petits lots = mise à jour progressive. Remplacer les serveurs par de nouvelles images = infrastructure immuable.
Questions d'entraînement
1. Déployer une nouvelle version à côté de l'ancienne puis basculer tout le trafic d'un coup décrit quelle stratégie ?
- Mise à jour progressive
- Bleu-vert (bonne réponse)
- Livraison canari
- Test fantôme
Le bleu-vert exploite deux environnements identiques ; on bascule le trafic du bleu (ancien) au vert (nouveau) instantanément, avec retour arrière rapide. Le canari livre d'abord à un petit sous-ensemble.
2. Livrer un changement d'abord à un faible pourcentage d'utilisateurs pour limiter le risque s'appelle :
- Livraison bleu-vert
- Livraison canari (bonne réponse)
- Livraison progressive
- Livraison big-bang
La livraison canari expose la nouvelle version à un petit sous-ensemble, la surveille, puis élargit si tout va bien - limitant l'impact. Le big-bang bascule tout le monde d'un coup.
3. Le même artefact de build est validé en test, puis en préproduction, puis en production sans reconstruction. C'est :
- Dérive de configuration
- Bascule bleu-vert
- Promotion d'artefact (bonne réponse)
- Test de chaos
La promotion d'artefact fait passer un unique build immuable à travers les environnements, pour que ce qui est testé soit exactement ce qui est livré. Reconstruire par étape risquerait d'introduire des différences.
4. Une nouvelle fonctionnalité est déployée mais masquée derrière un interrupteur que vous activez plus tard pour les utilisateurs. Cela utilise un :
- Sonde de santé
- Minuterie de cooldown
- Session collante
- Interrupteur de fonctionnalité (bonne réponse)
Un interrupteur de fonctionnalité (flag) livre le code masqué et permet de l'activer à l'exécution sans redéployer, autorisant un déploiement graduel et un arrêt instantané. Les sondes ne vérifient que la vivacité.
5. Mettre à jour des serveurs en les remplaçant par de nouvelles images au lieu de les corriger en place suit quel principe ?
- Dérive de configuration incontrôlée
- Correctif manuel en place
- Infrastructure immuable (bonne réponse)
- Scalabilité verticale d'instance
L'infrastructure immuable ne modifie jamais un serveur en fonctionnement ; on construit une nouvelle image et on remplace l'ancienne instance, ce qui supprime la dérive et facilite le retour arrière. Le correctif manuel crée de la dérive.
6. Remplacer les anciennes instances par des nouvelles quelques-unes à la fois jusqu'à tout mettre à jour est quelle stratégie ?
- Bascule bleu-vert
- Mise à jour progressive (bonne réponse)
- Livraison canari
- Bascule big-bang
Une mise à jour progressive remplace les instances par petits lots pour maintenir le service, avec peu de capacité supplémentaire. Le bleu-vert garde deux environnements complets et bascule le trafic.