Blue/Green DevOps : tout savoir sur le déploiement du modèle de publication d’application

L’approche itérative et incrémentale du développement agile de logiciels et d’applications est de plus en plus recherchée par les entreprises. Il est essentiel de s’appuyer sur des pratiques DevOps efficaces pour assurer un déploiement continu, réduire les risques et optimiser les performances. Le concept Blue/Green Devops est l’une des méthodes adoptées par de nombreuses équipes agiles.

Qu’est-ce que le Blue/Green DevOps ?

Le concept DevOps est apparu dans les années 2000. Il s’est imposé comme une véritable philosophie de travail avec l’objectif de déployer rapidement une solution logicielle qualitative, sans interruption de service. Le Blue/Green est un concept apparu en 2010, dans un ouvrage de Jez Humble et David Farley, « Continuous Delivery ».

Le processus CI/CD Blue Green DevOps consiste à avoir deux environnements parallèles de production :

• le Blue est la version active et stable de l’application ou du logiciel ; 
• le Green est une copie exacte du Blue sur laquelle on applique la nouvelle version ou les mises à jour.

Dès lors que l’environnement Green est testé et validé, le trafic bascule progressivement de l’environnement Blue. Cette méthode permet une transition douce et évite les interruptions de service.

Les objectifs du Blue/Green deployment

Le Blue Green deployment s’inscrit dans le concept plus large de Zero Downtime Deployment (ZDD). L’objectif principal pour les équipes DevOps est de minimiser, voire d’éliminer les downtimes pour les utilisateurs finaux lors de la mise à jour d’une application, d’un logiciel ou d’un système. Il permet aussi de valider une nouvelle version dans un environnement sans risque. Les développeurs ont la possibilité d’opérer facilement un rollback en cas de problème.

Les autres stratégies de déploiement logiciel

Dans le contexte DevOps, le déploiement peut prendre plusieurs formes, selon les besoins du projet et les préférences de l’équipe de développement.

Canary, la stratégie de déploiement incrémentale

Avec un déploiement Canary, l’application ou le service est mis en service de manière incrémentale par groupe d’utilisateurs. On les appelle les canaris. L’infrastructure globale de l’environnement cible est alors mise à jour par canaris. La montée en charge est progressive. Le modèle ne nécessite pas de provisionner une deuxième infrastructure.

Rolling Deployment, ou déploiement progressif

Le modèle Rolling implique la publication de mises à jour logicielles sur des sous-ensembles de serveurs de manière incrémentale. Les utilisateurs des anciens serveurs utilisent une ancienne version, tandis que ceux dirigés vers les serveurs mis à jour peuvent consulter la nouvelle version. En l’absence d’incident, le déploiement se poursuit dans l’environnement d’hébergement, jusqu’à ce que tous les serveurs exécutent l’application mise à jour.

Les enjeux du Blue/Green DevOps

Si cette méthode permet aux développeurs et aux équipes DevOps en général de gagner un temps précieux, elle présente toutefois des enjeux à prendre en compte. 

La gestion des sessions utilisateurs

Lors de la bascule de l’environnement Blue à Green, il est essentiel de s’assurer que les sessions utilisateurs en cours ne sont pas perdues. Les utilisateurs ne doivent pas être déconnectés, au risque de perdre leur travail en cours. Cette contrainte nécessite une gestion efficace des sessions et des mécanismes de transfert transparent des sessions entre les environnements.

De même, les données de session, comme les paniers d’achat dans une application e-commerce par exemple, doivent être gérées de manière à ce qu’elles restent cohérentes au moment de la bascule. Des mécanismes de synchronisation de données entre les deux environnements peuvent alors être nécessaires.

Le manque de ressources

Le déploiement Blue/Green est une technique familière dans le monde des DevOps. Pourtant, peu d’entreprises l’utilise. La principale raison est qu’elles ne disposent pas de ressources internes pour prendre en charge les processus CI/CD (continuous integration/continuous delivery).

La gestion des databases

L’approche soulève également des défis concernant la gestion des bases de données. Pour que le Blue/Green deployment fonctionne, les transactions initiées dans la base de données SQL d’un environnement doivent être identiquement appliquées dans l’autre. Sauf que selon le type de base de données impliqué, la méthodologie diffère.

Dans le cas d’une database indépendante, la synchronisation entre les versions Blue et Green n’est pas nécessaire. Il n’y a donc pas de downtime. Toutefois, cela implique un changement de modèle. Une des possibilités est de faire appel à des bases de données noSQL ou de séparer les bases de données par rapport aux deux environnements.

Si les bases de données sont intégrées, le problème ne se pose pas. Cependant, les databases doivent être synchronisées dans les deux sens. Plus complexe à mettre en œuvre, ce modèle réduit toutefois considérablement le risque d’erreurs.

La scalabilité de l’infrastructure

Deux environnements identiques doivent être maintenus simultanément. Le déploiement Blue/Green double ainsi la quantité de ressources nécessaires à l’hébergement de l’application. Il faut alors créer des environnements capables d’évoluer rapidement sans modifier leur configuration de base. Des machines virtuelles, basées sur le cloud et l’autoscaling ou via des conteneurs, et un moteur d’orchestration (comme Kubernetes) peut les mettre à l’échelle.

Quelles sont les étapes du Blue/Green DevOps ?

Le déploiement Blue/Green est une stratégie clé au sein de l’écosystème DevOps. Elle révolutionne la gestion des mises à jour logicielles. En respectant des étapes clés, il est possible d’assurer la stabilité et la fiabilité des applications tout en offrant une grande flexibilité, pour intégrer des améliorations continues.

Duplication de l’infrastructure

Dans l’idéal, il s’agit d’une copie de chaque structure, du serveur d’application à l’interface utilisateur graphique, en passant par le système de stockages, les équilibreurs de charge ou les réseaux. L’infrastructure de l’environnement Green doit être strictement identique à celle de l’environnement Blue.

Mise à jour du serveur dormant

La nouvelle version de l’application peut être déployée dans l’environnement Green. Ce processus est facilité par l’utilisation d’outils d’automatisation, comme des scripts de déploiement ou des outils d’orchestration. Des tests approfondis dans l’environnement Green vont permettre de vérifier que la nouvelle version de l’application fonctionne correctement et ne présente pas de problèmes de compatibilité ou de performance.

Basculement du trafic

Dans une stratégie de Blue/Green Deployment, une nouvelle version d’application est déployée en basculant le trafic de l’ancien environnement, Blue, vers le nouveau, Green. Un dispositif de routage redirige tout le trafic entrant, en conservant le même nom de domaine. Il peut s’agir d’un équilibreur de charge, d’un routeur de réseau régulier ou maillé, ou d’un serveur web. Il suffit de configurer le routeur pour qu’il cesse d’envoyer le trafic sur la version active du serveur et le dirige vers la version à déployer.

Surveillance continue

Le nouvel environnement Green doit être scruté pour vérifier la qualité de ses performances et l’absence d’anomalie. En cas d’incident, le trafic peut être rapidement basculé pour revenir à la version précédente, Blue.

Relégation de la plate-forme inactive

Dès lors que tous les utilisateurs ont quitté la plate-forme Blue, celle-ci est reléguée au rang de serveur inactif. Elle devient un environnement de sauvegarde ou de récupération, et une étape pour la configuration de la prochaine mise à jour à déployer. Lors de la prochaine mise à jour, Green sera le serveur actif, et Blue pourra accueillir la nouvelle version. 

Quels sont les avantages du Blue/Green DevOps ?

La philosophie Blue/Green Deployment offre des avantages significatifs pour les équipes DevOps.

Un niveau élevé de gestion des risques

Un serveur en service peut rencontrer différents types de problèmes, avec ou sans rapport avec des mises à jour. Avec le déploiement Blue/Green, une réplique de toute l’infrastructure est constamment disponible. Les développeurs back-end peuvent donc facilement et rapidement rediriger le trafic réseau d’une version à l’autre.

Une réduction de downtime significative

En basculant simplement le trafic des utilisateurs de l’environnement Blue vers l’environnement Green, les interruptions de service sont minimisées. Les utilisateurs restent connectés à l’application pendant le déploiement. Les temps d’arrêts prévisibles peuvent même être totalement évités. Cela représente un atout pour des institutions financières ou les marchés en ligne, qui jonglent avec des milliers de transactions chaque heure, et pour lesquels un temps d’arrêt, même minime, peut avoir des conséquences critiques.

Le testing en production

Le déploiement Blue/Green permet de tester les fonctionnalités d’un service directement sur un serveur. Vous pouvez ainsi observer exactement son fonctionnement depuis une interface utilisateur. Le serveur étant inactif, aucun risque que les tests aient un impact sur l’expérience client. 

Quels sont les limites et les défis du Blue/Green Deployment ?

Même si le modèle de déploiement Blue/Green a changé la donne, il présente également certaines limites. Répliquer un environnement complet de production d’application peut s’avérer très coûteux, tant financièrement qu’en matière de ressources humaines. De plus, lorsque l’entreprise se développe et que le nombre d’utilisateurs d’un service web augmente, l’infrastructure devient encore plus complexe. 

Les cycles de publication sont de plus en plus courts, et les développeurs doivent lancer des nouvelles mises à jour et des itérations à intervalles réguliers. Grâce au modèle de déploiement Blue/Green, les équipes DevOps parviennent à respecter les délais sans compromettre la qualité du code. À l’heure où presque toutes les applications sont consommées en tant que service par le biais d’une « application web », cette option populaire permet la livraison rapide de logiciels.