Qu’est-ce que le déploiement bleu/vert ?

Un environnement est actif et est destiné aux utilisateurs, étiqueté « bleu » et un autre, l’environnement « vert », est utilisé pour le déploiement et les tests d’une nouvelle version. Lorsque la nouvelle version est approuvée, le trafic est instantanément acheminé de l’environnement bleu vers l’environnement vert.

La stratégie a été popularisée et nommée par Jez Humble et David Farley dans leur livre fondateur de 2010, Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation.

Le déploiement bleu/vert est une technique de déploiement continu qui permet d’éliminer les temps d’arrêt et de revenir instantanément à une ancienne version. Il permet de réaliser facilement des tests A/B et crée un environnement de développement sécurisé, sans risque que les utilisateurs finaux tombent sur une version non finalisée.

Bien que l’expression « bleu/vert » soit la plus courante, il existe des variantes. Netflix utilise le système « rouge/noir », mais le concept reste le même. Parfois, les développeurs peuvent souhaiter disposer de plus de deux environnements. Le schéma de dénomination des couleurs est efficace pour différencier deux environnements. Cependant, les entreprises peuvent aussi utiliser des conventions de nommage telles que les numéros de version, les identifiants de compilation ou les titres personnalisés, surtout s’il y a plus de deux environnements impliqués.

Bien que le concept soit simple, il y a plusieurs étapes et variables pour créer un déploiement bleu/vert stable et sûr, qui profite des avantages de la stratégie.

La création d’environnements identiques pour un déploiement bleu/vert peut être réalisée manuellement ou à l’aide d’outils automatisés. L’infrastructure en tant que code, ou IaC, est une approche automatisée du provisionnement. L’IaC utilise des fichiers de configuration lisibles par une machine, comme un ensemble d’instructions ou une recette, pour permettre l’approvisionnement et la configuration automatiques de l’infrastructure informatique selon des spécifications prédéfinies.

L’IaC permet aux développeurs de créer automatiquement une copie de l’environnement bleu, qui est déjà opérationnel, pour l’utiliser comme environnement vert. Les développeurs peuvent ensuite modifier ces modèles en fonction de leurs besoins, en sachant qu’ils partent d’une base fiable. L’utilisation de l’IaC permet de garantir une réplication répétable et précise.

La conteneurisation, qui consiste à regrouper le code de l’application, les dépendances et les API dans une seule « image de conteneur », est une autre approche. L’utilisation de conteneurs garantit que l’ensemble de l’environnement est identique. Kubernetes, une plateforme d’orchestration de conteneurs open source, est couramment utilisée pour la conteneurisation dans les déploiements bleu/vert.

Une fois les environnements créés, l’application est déployée dans l’environnement bleu (en direct).

Un équilibreur de charge est un mécanisme, souvent présent devant les environnements d’application en tant qu’outil au sein des fournisseurs de cloud ou des environnements Kubernetes, qui dirige le trafic de production comme il le souhaite. Dans ce scénario, l’équilibreur de charge dirige le trafic vers l’environnement bleu en direct.

Ensuite, le nouveau code avec les mises à jour de l’application est déployé dans l’environnement de production vert. L’équilibreur de charge dirige le trafic vers l’environnement de production bleu, c’est pourquoi l’environnement vert est un espace sûr pour expérimenter, tester et configurer. 

Lorsque le processus de déploiement dans l’environnement vert est terminé, effectuez toutes les étapes de validation nécessaires. Ces étapes peuvent inclure des analyses de sécurité, des contrôles de performance, des analyses de bugs et plus encore.

Lorsque l’environnement vert est validé et approuvé par toutes les parties prenantes nécessaires, mettez à jour l’équilibreur de charge pour diriger le trafic de l’environnement bleu précédent vers le nouvel environnement vert.

Cette transition sera instantanée : les utilisateurs ne verront à aucun moment une erreur ou un élément autre que les environnements bleu ou vert.

Les mises à jour DNS peuvent être utilisées pour diriger les utilisateurs vers l’environnement souhaité, mais il peut y avoir des retards importants car les mises en cache rafraîchissent l’adresse IP. Pour ces raisons, les équilibreurs de charge sont préférables car les mises à jour prennent effet immédiatement.

Bien que l’étape de validation aurait dû détecter la plupart des bugs ou problèmes de performances potentiels, il est tout de même important de surveiller l’environnement vert tout juste activé. Les logiciels et services d’analyse peuvent vous y aider. La comparaison des activités peut indiquer s’il se passe quelque chose d’inhabituel.

En cas de problème, le trafic des utilisateurs peut être redirigé vers l’environnement bleu pendant que les développeurs résolvent le problème.

La mise hors service d’un environnement bleu désaffecté est facultative ; certaines entreprises souhaiteront peut-être conserver l’environnement bleu indéfiniment au cas où l’environnement vert aurait besoin d’être annulé à un moment ou à un autre. Mais il existe également des raisons financières potentielles pour mettre hors service un environnement bleu lors de son cycle de vie. Par ailleurs, l’environnement bleu peut devenir le prochain environnement expérimental, ou environnement vert.

Le pipeline d’intégration et de livraison continues est « un workflow DevOps automatisé qui rationalise le processus de livraison des logiciels ». Ce pipeline facilite la livraison continue des modifications de code dans les applications.

Il s’agit d’une pratique étroitement intégrée au déploiement bleu/vert : la CI/CD permet un déploiement bleu/vert. De même, les déploiements bleu/vert sont souvent intégrés dans les pipelines CI/CD pour aider à publier des mises à jour logicielles avec zéro temps d’arrêt et un risque réduit.

Les pipelines CI testent et intègrent automatiquement le nouveau code avant qu’il soit intégré dans le référentiel central, réduisant ainsi le risque qu’un code défectueux atteigne le déploiement. Les pipelines CD s’appuient sur une stratégie de déploiement bleu/vert pour optimiser les mises en production rapides sans affecter les utilisateurs. Le déploiement bleu/vert assure une disponibilité quasi continue et un retour en arrière sûr, ce qui joue un rôle important dans la réalisation de l’objectif général de la CI/CD, à savoir des versions de code fréquentes et fiables.

Dérivé de l’expression du canari dans une mine de charbon, le déploiement Canary est un autre moyen de réduire les risques lors du déploiement de nouvelles versions logicielles.

Alors que les déploiements bleu/vert créent deux environnements distincts, chacun d’entre eux hébergeant généralement tout ou rien du trafic, la méthode Canary adopte une approche différente. Les versions Canary n’ont qu’un seul environnement et hébergent plusieurs versions.

Dans le cadre d’un déploiement Canary, les nouvelles versions sont d’abord diffusées auprès d’un petit pourcentage d’utilisateurs. Les développeurs peuvent alors voir si les erreurs augmentent, si les performances diminuent ou si d’autres problèmes surviennent. Ce faible pourcentage d’utilisateurs agit comme le « canari dans la mine de charbon ». En l’absence de problèmes, le trafic vers la nouvelle version augmente régulièrement, ce qui permet de détecter les erreurs.

Le principal avantage d’un déploiement Canary par rapport à un déploiement bleu/vert réside dans le coût de l’infrastructure, car le déploiement Canary n’utilise qu’un seul environnement, alors que le déploiement bleu/vert en utilise deux. Toutefois, les déploiements Canary peuvent également être plus complexes et plus risqués si une restauration est nécessaire, par rapport à la simple redirection d’équilibrage de charge entre les environnements bleu et vert.

La méthode Canary peut être utile si les erreurs potentielles ne sont pas aussi importantes que la mise à disposition d’une nouvelle version auprès des utilisateurs le plus rapidement possible, ou si les développeurs veulent surveiller l’impact grâce à de vrais commentaires sur l’expérience utilisateur.

Cela dit, il existe aussi une approche hybride. Les équilibreurs de charge peuvent diriger une partie du trafic des utilisateurs, par exemple 1 %, vers l’environnement vert tout en laissant 99 % aller vers l’environnement bleu. Cela permet d’associer efficacement les deux stratégies, fournissant des informations sur le déploiement des canaux avec la possibilité d’émettre rapidement et facilement des restaurations.

Le déploiement bleu/vert offre de nombreux avantages, qu’il soit utilisé dans un scénario « tout ou rien » ou dans un déploiement Canary.

L’équilibreur de charge basculant instantanément le trafic vers l’environnement souhaité, les utilisateurs finaux n’ont jamais d’expérience de temps d’arrêt. C’est un avantage majeur pour les instances à haut trafic où les temps d’arrêt peuvent entraîner de graves problèmes commerciaux.

Le fait de disposer de deux environnements distincts, dont l’un est réputé sûr et opérationnel, permet aux développeurs d’annuler instantanément les modifications en cas de problème. Si l’environnement vert présente des problèmes, le trafic peut simplement être redirigé vers l’environnement bleu.

Le fait de disposer de deux environnements distincts simplifie l’analyse des indicateurs, l’analytique et les tests A/B pour les différentes versions. Les données d’analytique et de surveillance peuvent être clairement reliées à l’environnement bleu ou vert, ce qui permet une comparaison et des contrôles de santé simples. Cela contraste avec le déploiement Canary, qui peut être plus difficile à distinguer, car les deux versions sont actives simultanément.

Un environnement expérimental vert permet de tester de manière approfondie les nouvelles versions à l’abri des regards de l’utilisateur final. Les nouvelles versions sont déployées avec un degré de confiance important quant à leur bon fonctionnement. Si ce n’est pas le cas, le trafic peut être instantanément réacheminé vers l’environnement bleu stable.

Si le déploiement bleu/vert offre de nombreux avantages, il présente aussi des inconvénients potentiels et des cas d’utilisation non optimaux que les équipes de développement doivent prendre en compte.

Avec deux environnements entièrement provisionnés en fonctionnement, les coûts d’hébergement et d’infrastructure peuvent augmenter. Il n’est pas nécessaire que ces coûts soient exactement le double du coût d’un environnement unique. Dans certains cas, l’environnement vert aura une empreinte plus réduite, l’environnement bleu pourrait être rapidement mis hors service, ou certaines ressources pourraient être partagées entre les deux environnements. Toutefois, il est probable que les coûts augmentent.

Bien que cela ne soit pas réservé aux déploiements bleu/vert, maintenir la synchronisation des bases de données entre les anciens et les nouveaux environnements peut représenter un défi. Par exemple, dans un système bleu/vert qui implique des modifications fréquentes ou complexes du schéma, il peut être difficile de maintenir la compatibilité.

Pour éviter de perturber l’environnement réel, les modifications apportées au schéma doivent être rétrocompatibles, ce qui signifie que le nouveau système peut fonctionner avec l’ancien. Si ce n’est pas le cas, les environnements peuvent nécessiter des bases de données distinctes qui doivent se synchroniser en temps réel. Cette synchronisation bidirectionnelle présente ses propres risques, tels que des incohérences ou une dégradation des performances.

Pour résoudre ce problème, les outils CI/CD, tels que GitHub Actions, incluent des processus de déploiement de bases de données qui gèrent automatiquement les mises à jour des schémas. Parfois, des modifications de schéma trop complexes peuvent annuler la valeur du déploiement bleu/vert.

Dans les applications à état, celles qui conservent des données persistantes entre les requêtes, les déploiements bleu/vert peuvent poser problème. Les applications dynamiques peuvent inclure des paniers d’achat qui conservent leur contenu après plusieurs visites, ou des journaux de messagerie. Si les bases de données ne sont pas partagées et compatibles entre environnements, ces données peuvent être perdues.

Les applications de microservices sont souvent des systèmes très complexes composés de nombreux composants déployables individuellement. Les développeurs de microservices souhaitant déployer des dizaines de fois par jour, le déploiement Canary est considéré comme un choix plus sûr.