Les méthodes traditionnelles de développement logiciel, souvent qualifiées de « big bang », s’avèrent incompatibles avec les exigences actuelles de flexibilité, d’agilité et de déploiement continu propres aux plateformes cloud et DevOps.
Il ne suffit plus de se contenter d’une simple liste de contrôle des étapes manuelles à suivre lors du déploiement d’une version en production. Une telle approche ne permet pas d’atteindre une véritable agilité ni de mettre en œuvre une stratégie DevOps efficace.
Le déploiement bleu-vert : une introduction
Le déploiement bleu-vert est une technique de déploiement logiciel qui vise à réduire les interruptions de service et les risques liés à la mise en production de nouvelles versions. Elle repose sur la création de deux environnements identiques : l’un actif (bleu) et l’autre inactif (vert).
L’environnement actif est celui où la version actuelle du logiciel fonctionne et où les utilisateurs génèrent du trafic de production. L’environnement inactif sert de zone de préparation pour la nouvelle version du logiciel, où elle est déployée et testée.
Une fois que la nouvelle version a été validée, le trafic est redirigé de l’environnement actif vers l’environnement inactif, qui devient alors le nouvel environnement actif. Cette procédure peut être répétée selon les besoins.
Source: docs.aws.amazon.com
Le contexte DevOps
Le déploiement bleu-vert s’intègre parfaitement à la philosophie et aux pratiques DevOps. Il facilite la livraison et le déploiement continus de logiciels tout en minimisant les interruptions de service pour les utilisateurs et en réduisant les risques d’échec d’une mise en production.
La présence de deux environnements identiques permet de tester et de déployer de nouvelles versions sans impacter l’environnement de production en cours. Cette approche favorise des cycles de mise en production plus rapides et plus fréquents, un élément clé des pratiques DevOps.
De plus, la capacité de basculer rapidement le trafic entre les environnements est un atout essentiel pour assurer une restauration rapide en cas de problème, une autre composante importante des environnements DevOps.
Les principes fondamentaux du déploiement bleu-vert
#1. Deux environnements rigoureusement identiques
La mise en œuvre d’un déploiement bleu-vert exige la création de deux environnements qui soient des répliques parfaites l’un de l’autre, tant du point de vue des données que des processus. L’un est l’environnement actif (bleu), tandis que l’autre est l’environnement inactif (vert).
L’environnement bleu est celui où les utilisateurs de production effectuent leurs tâches quotidiennes. L’environnement vert, bien que constamment synchronisé avec le bleu, sert de terrain d’essai où les équipes de test exécutent leurs cas de test. Bien qu’il ne s’agisse pas d’un environnement de production direct, les tests sont menés dans des conditions réelles puisque l’environnement est une copie fidèle de celui de production.
#2. Le basculement du trafic
Après validation de la nouvelle version du logiciel, le trafic est redirigé de l’environnement actif vers l’environnement inactif, qui devient à son tour le nouvel environnement actif.
La transition est instantanée, marquant la fin du déploiement. Aucune interruption de service n’est à déplorer. Les utilisateurs ne sont pas tenus d’effectuer la moindre action pour accéder au nouvel environnement ; ils sont automatiquement redirigés, simultanément.
Source: aws.amazon.com
#3. La restauration rapide
La possibilité de basculer rapidement le trafic entre les environnements permet également une restauration rapide en cas de problème. Cela assure un temps d’arrêt minimal et garantit la haute disponibilité de l’application.
En cas d’anomalie dans l’environnement vert, tous les utilisateurs sont immédiatement redirigés vers l’environnement bleu stable d’origine, sans la moindre perturbation.
#4. Les tests automatisés
Les tests automatisés sont une composante essentielle du déploiement bleu-vert. Ils garantissent que la nouvelle version du logiciel est rigoureusement testée avant d’être mise en production.
L’absence d’un volume significatif de tests automatisés (tests unitaires, tests fonctionnels et tests de régression au minimum) compromet l’efficacité du déploiement bleu-vert. L’absence de tels tests ralentira considérablement le processus.
Le temps nécessaire pour tester le nouvel environnement (vert) sera tel qu’au moment où le basculement sera envisageable, la version sera déjà obsolète, selon les critères d’un cycle de développement logiciel.
#5. La livraison continue
Le déploiement bleu-vert s’inscrit dans un pipeline de livraison continue, ce qui se traduit par des mises en production plus fréquentes et plus rapides.
Le basculement peut être effectué dès que la nouvelle version du logiciel est prête à être testée dans l’environnement vert. Le déploiement étant déjà réalisé, seule la transition de trafic est nécessaire, ce qui rend le processus rapide et potentiellement quotidien. Bien entendu, ceci suppose une rapidité équivalente des activités de test.
Le cycle de vie typique
Le déploiement bleu-vert suit un cycle de vie spécifique comprenant plusieurs étapes et processus :
- Création d’une nouvelle version du logiciel. Cette étape comprend la compilation du code, l’exécution de tests automatisés et la génération d’un artefact déployable.
- Déploiement de la nouvelle version dans l’environnement inactif (vert). Cela inclut la configuration de l’environnement, le déploiement de l’artefact et la configuration des paramètres nécessaires.
- Exécution de tests automatisés dans l’environnement vert, pour vérifier le bon fonctionnement de la nouvelle version (tests fonctionnels, tests de régression, tests d’intégration et, idéalement, tests de performance).
- Basculement du trafic de l’environnement actif (bleu) vers l’environnement inactif (vert). Cette étape nécessite la mise à jour de l’équilibreur de charge ou des paramètres DNS pour diriger le trafic vers l’environnement vert, de préférence via des processus automatisés.
- Surveillance de l’application après le basculement pour s’assurer de son bon fonctionnement, en suivant les erreurs, les problèmes de performance et autres anomalies.
- Restauration (facultative et à éviter autant que possible) du trafic vers l’environnement bleu en cas de problème critique détecté. Cela permet une restauration immédiate, sans interruption pour les utilisateurs. Il suffit de mettre à jour l’équilibreur de charge ou les paramètres DNS pour rediriger le trafic vers l’environnement bleu.
- Après résolution des problèmes, retour du trafic vers l’environnement vert, via la mise à jour de l’équilibreur de charge ou des paramètres DNS.
- Enfin, une fois que la nouvelle version du logiciel est stable, désactivation de l’ancienne version exécutée dans l’environnement bleu, qui sera nécessaire pour construire la prochaine version du système.
Mise en œuvre de pipelines CI/CD
L’intégration du déploiement bleu-vert dans un pipeline DevOps CI/CD doit se faire naturellement.
Une condition préalable est la mise en place des deux environnements identiques. Puisqu’il s’agit d’un processus automatisé, il est recommandé d’utiliser des outils d’infrastructure as code comme AWS CloudFormation ou Terraform pour créer, recréer ou mettre à jour les environnements de manière automatisée.
Cette étape franchie, la création d’un processus de déploiement entièrement automatisé est facilitée. Il suffit de réutiliser les pipelines existants pour la création des environnements bleu et vert, en y intégrant les processus de test.
Le basculement de trafic peut être automatisé avec des outils comme Elastic Load Balancer d’AWS ou NGINX. Cela implique de mettre à jour l’équilibreur de charge ou les paramètres DNS pour diriger le trafic vers l’environnement vert une fois la nouvelle version validée.
La dernière étape est la mise en place d’une surveillance, en utilisant des outils comme AWS CloudWatch, New Relic ou Datadog.
Il est également recommandé de réutiliser les pipelines existants pour la désactivation de l’ancien environnement bleu. Le choix de la méthode (destruction et recréation ou mise à jour des scripts) dépend des besoins, mais la destruction et la recréation est souvent l’option la plus sûre.
Meilleures pratiques de déploiement bleu-vert
Voici quelques conseils pour optimiser votre déploiement bleu-vert :
Adopter une stratégie de migration de base de données robuste
Lors du déploiement d’une nouvelle version du logiciel, il est essentiel de s’assurer que le schéma de la base de données est correctement mis à jour. L’utilisation d’outils de migration de base de données comme Flyway ou Liquibase est vivement recommandée.
Intégrer un outil d’analyse Canary
Bien que le déploiement Canary soit une approche alternative, certaines de ses techniques peuvent être utiles pour affiner le déploiement bleu-vert.
L’utilisation d’un outil d’analyse Canary comme Kayenta ou Spinnaker permet d’analyser les performances de la nouvelle version du logiciel en conditions réelles, en la comparant aux performances de l’ancienne version.
Un framework de basculement de fonctionnalités tel que Togglz permet d’activer ou de désactiver des fonctionnalités dans la nouvelle version, facilitant ainsi un déploiement progressif et une restauration rapide en cas de besoin.
Utiliser un équilibreur de charge avec des vérifications d’état
L’utilisation d’un équilibreur de charge comme AWS Elastic Load Balancer ou NGINX avec des vérifications d’état permet de garantir que le trafic est dirigé uniquement vers des instances saines, assurant ainsi la haute disponibilité de l’application et minimisant les interruptions de service.
Mettre en place un plan de restauration avec restauration automatisée
La mise en place d’un plan de restauration en cas de problème, combinée à l’automatisation du processus de restauration avec des outils comme AWS CodeDeploy ou Octopus Deploy, garantit une réduction des temps d’arrêt et la haute disponibilité de l’application.
Ceci s’applique en particulier à l’environnement vert lorsque des problèmes critiques sont détectés avec la nouvelle version.
Un plan de restauration pour l’environnement bleu n’est pas nécessaire car il reste inchangé lors du basculement, et il est possible de revenir à cet environnement stable instantanément.
Défis liés au déploiement bleu-vert
La mise en œuvre du déploiement bleu-vert peut présenter certains défis :
- La configuration et la gestion de deux environnements identiques peuvent être complexes et chronophages, nécessitant une expertise en matière d’infrastructure as code (Terraform, CloudFormation). Une équipe de développement senior est nécessaire pour relever ces défis techniques.
- La mise à jour du schéma de la base de données lors du déploiement d’une nouvelle version peut être complexe, en particulier si le schéma est complexe. La mise en place de processus de déploiement de base de données robustes est indispensable.
- L’analyse des performances de la nouvelle version du logiciel en environnement réel peut être délicate, nécessitant une expertise dans l’utilisation d’outils d’analyse Canary (Kayenta, Spinnaker).
- La mise en œuvre des bascules de fonctionnalités peut être complexe, surtout si l’application comporte un grand nombre de fonctionnalités. Une planification et une coordination rigoureuses entre les équipes de développement sont nécessaires.
- Les tests de la nouvelle version du logiciel en environnement réel peuvent être complexes, en particulier si l’application a de nombreux utilisateurs ou serveurs. L’automatisation des tests est essentielle, ainsi qu’une forte coordination entre les équipes de développement et de test.
- La mise en place d’une solution de surveillance efficace est un défi, mais elle est essentielle pour des opérations DevOps optimales. Il est crucial d’investir du temps dans la construction de cette solution avec des outils éprouvés (AWS CloudWatch, New Relic, Datadog).
Différence entre déploiement bleu-vert et déploiement Canary
La différence avec les processus de déploiement traditionnels est claire (il n’y a pas deux environnements parallèles avec différentes versions logicielles). La différence avec le déploiement Canary est peut-être plus intéressante.
Le déploiement bleu-vert implique deux environnements (bleu et vert), constamment synchronisés en termes de données. Après validation, le trafic est basculé de l’environnement actif vers l’environnement inactif, qui devient le nouvel environnement actif. Le déploiement ne prend pas de temps et il n’y a pas d’arrêt de production. Les utilisateurs travaillent en permanence sur l’environnement actif et ne remarquent pas le changement.
Le déploiement Canary consiste à déployer la nouvelle version du logiciel auprès d’un petit groupe d’utilisateurs, tandis que la majorité continue d’utiliser l’ancienne version. Il s’agit d’un déploiement progressif plutôt que d’un basculement complet. Les testeurs sont des utilisateurs directs de la production (un sous-ensemble défini), qui testent activement la nouvelle version. Une fois validée, la nouvelle version est déployée auprès de tous les utilisateurs.
Alors, quel est le meilleur ?
La réponse d’un consultant « ça dépend » est la plus appropriée ici.
Si la priorité de votre système est la haute disponibilité, le déploiement bleu-vert est le choix le plus judicieux.
Si vous privilégiez un retour d’information plus rapide et un déploiement plus contrôlé (mais plus lent) de la nouvelle version, le déploiement Canary présente des avantages par rapport au bleu-vert.
L’important est que les deux soient suffisamment agiles pour être considérés comme adaptés à la mise en place de systèmes DevOps sérieux.
Études de cas
Netflix utilise le déploiement bleu-vert pour déployer de nouvelles versions de son service de streaming, assurant ainsi une expérience utilisateur ininterrompue. Netflix utilise également le déploiement Canary pour d’autres cas, démontrant la possibilité de combiner différentes approches DevOps.
Amazon et Etsy utilisent également le déploiement bleu-vert pour déployer des mises à jour sur leur plateforme de commerce électronique.
LinkedIn utilise le déploiement bleu-vert pour déployer de nouvelles versions de sa plateforme de réseau social.
IBM utilise enfin le déploiement bleu-vert pour mettre à jour sa plateforme cloud.
Ces entreprises ont mis en œuvre avec succès le déploiement bleu-vert et servent d’exemples pertinents.
Derniers mots
Tout comme le déploiement Canary, le déploiement bleu-vert vise à optimiser les processus et les méthodologies agiles pour fournir de nouvelles versions de logiciel de manière transparente, sans que personne ne s’en aperçoive. C’est l’objectif ultime. Des mises à jour sont déployées constamment, mais personne ne le sait, personne ne le remarque et au final, personne ne s’en préoccupe.
Il peut être frustrant pour l’équipe de développement que leurs dernières versions ne fassent pas l’objet de discussions au sein de l’entreprise. Mais c’est peut-être le meilleur service que l’on puisse offrir. Personne n’en parle, mais tout le monde l’utilise au quotidien.
Pour aller plus loin, consultez les questions les plus fréquentes lors des entretiens DevOps.