Comment la technique Blue/Green garantit un déploiement cohérent et continu

Déploiement dans le cloud : quelques modèles

Les stratégies de déploiement sont certes spécifiques à chaque entreprise ou application, mais cinq catégories se dégagent – comme l’a d’ailleurs identifié un expert du secteur :

• Déploiement Rip-and-Replace : Les équipes opérationnelles connaissent bien l'approche Rip-and-Replace (on jette et on remplace), remplacer le vieux par le neuf. Cette méthode de déploiement fonctionne mieux avec une infrastructure stable dans le temps.
• Mise à jour en continu (« Rolling upgrade ») : Le nouveau code est inséré dans l'ancien, dans un environnement unique. Étant donné la nature graduelle d'une mise à niveau continue, les utilisateurs passent progressivement, plutôt qu'en une seule fois, au nouveau code.
• Déploiement Blue/Green : Ce modèle de déploiement implique la mise en place de deux infrastructures parallèles - l'ancien et le nouvel environnement. Les équipes opérationnelles assurent une transition du nombre d'utilisateurs de l'ancien au nouveau, après une période de test bêta.
• Déploiement « Canary » : Identique au modèle de déploiement Blue/Green, le test Canary exécute en même temps le nouveau et l'ancien code. Cependant, seul un petit groupe d'utilisateurs ont accès à la nouvelle version pour effectuer des tests en direct.
• Déploiement par versions : Cette variante du modèle de déploiement Canary maintient différentes versions de code indéfiniment, les utilisateurs ayant la possibilité de choisir une version.

À l'exception des mises à jour Rip-and-Replace, ces stratégies impliquent un déploiement parallèle, en ce sens qu'elles nécessitent d’héberger simultanément différentes versions d'applications dans un environnement de production. Le clonage de ressources est particulièrement facile avec les services cloud.

Quels sont les services cloud pour automatiser ces déploiements en parallèle

Un modèle de déploiement Blue/Green est peut-être l'option la plus utilisée pour les applications virtualisées. Les modèles Canary et par versions sont des variantes de cette approche. La configuration Blue/Green ne nécessite presque pas de temps d'arrêt, et avec les services cloud, il existe un moyen simple de passer d'une version à l'autre, à la fois pour la mise à niveau et le roll back. Il est également simple de répliquer complètement un environnement de production pendant le test. Le déploiement Blue/Green sur le cloud n'exige aucun investissement en capital.
AWS est représentatif des services cloud.

AWS fournit quelques détails pour un déploiement Blue/Green. Il se repose sur plusieurs services cloud :

• DNS : Le DNS dirige le trafic utilisateur vers chaque environnement - par exemple, vers beta.myapp.io ou prod.myapp.io. Chez AWS, le service se nomme Route 53.
• Load balancing et mise à l'échelle : Le modèle de déploiement doit inclure une capacité de dimensionnement de l'infrastructure, surtout lorsque les testeurs augmentent la charge. AWS a deux outils de load balancing, Application Load Balancer et Network Load Balancer, et propose un service de dimensionnement automatique.
• Templates de ressources : Les templates facilitent les déploiements automatisés, qui vont de pair avec des approches types, comme le modèle Blue/Green – CloudFormation chez AWS.
• Orchestration des ressources : Les administrateurs de cloud ont la possibilité d’utiliser des déploiements programmables, notamment pour cloner des environnements complets. Par exemple, AWS propose OpsWorks et Elastic Beanstalk. Elastic Beanstalk, qui supporte Java, PHP, .NET, Node.js, Python et Ruby, peut cloner un environnement en un seul clic à partir de l’AWS Management Console.
• Monitoring de service : Le déploiement n'est qu'un début. Le code actif doit être contrôlé pour s'assurer que les indicateurs restent dans les limites établies. En cas de pannes de service ou d'anomalies au niveau des performances, des alertes doivent se déclencher. AWS propose CloudWatch pour cela.

Une fois les environnements Blue/Green configurés, il convient de changer celui qui est en production en direct (green) via un changement de DNS. Il s'agit d'une opération simple sur la console AWS via Route 53. En raison de la mise en cache DNS et des paramètres TTL, les transitions DNS sont graduelles, à mesure que l'ancienne adresse (Blue) est remplacée par la nouvelle adresse IP sur les serveurs. Pour un transfert plus rapide, l'administrateur peut utiliser Elastic Load Balancing (ELB) et Auto Scaling en attachant le groupe Green au pool ELB de production et en le dimensionnant, tout en décommissionnant les instances du groupe Blue.

Automatiser le cycle de déploiement Blue/Green

Les équipes DevOps qui ont adopté les pipelines CI/CD peuvent automatiser le modèle de déploiement Blue/Green via un service de déploiement programmable. Sur AWS, ce produit s'appelle CodeDeploy (pour EC2) et l'option cloud de type serverless Lambda. Il intègre le type Blue/Green. Un service de déploiement programmable repose sur le load balancing et le dimensionnement du fournisseur de cloud pour répliquer les environnements et assurer la transition Blue et Green.

Chez AWS, on peut configurer CodeDeploy pour un mode Blue/Green à l'aide de la console AWS. Le service clone automatiquement l'environnement de production dans un autre groupe Auto Scaling. Les développeurs taggent le logiciel poussé vers un référentiel de code, comme GitHub, ou vers S3, avec une étiquette qui correspond à un environnement Blue ou Green. CodeDeploy détermine ensuite la cible et déploie le code dans l'environnement approprié. Lorsque le nouveau code est déployé dans un pipeline CI/CD, CodeDeploy peut immédiatement acheminer le trafic vers le nouvel environnement.

Le processus fonctionne un peu différemment avec les fonctions Lambda  qu’avec EC2. Avec Lambda, CodeDeploy crée des environnements parallèles Blue/Green, et les utilisateurs doivent sélectionner l'une des trois options pour déplacer le trafic de l'ancien vers le nouveau : Canary, linéaire ou d’un seul coup. Ces approches sont bien connues des spécialistes du déploiement et ne sont pas spécifiques au serverless :

• Canary déplace le trafic en deux paliers, avec une part et un intervalle configurables. Par exemple, 15 % de la circulation passe au Green pendant une journée pour test, après quoi les 85 % restants changent.
• Linéaire amène le trafic vers le nouveau déploiement par paliers égaux, avec un temps défini entre chaque déploiement. Par exemple, en cinq étapes, 20 % du trafic passe à l'environnement de production Green toutes les huit heures.
• Le déploiement massif et unique coupe tout le trafic du Blue au Green d'un seul coup.

Déploiement dans le cloud : quelles sont les autres alternatives

Mais il n’y pas qu’AWS : d'autres fournisseurs de cloud proposent également un modèle de déploiement Blue/Green. Par exemple, Microsoft propose Azure Service Fabric, avec, par défaut, des possibilités de  déploiements en continu (rolling),  de multiples versions d'applications. On peut également utiliser PowerShell pour automatiser le passage de l’environnement Blue vers le Green. Azure App Service permet également de réaliser cette transition.

De son côté, App Engine, le PaaS de Google offre également des fonctions qui permettent de gérer ce type de déploiement, comme la répartition du trafic qui dirige des connexions entrantes vers un environnement ou un autre. Google Kubernetes Engine (GKE), son implémentation de l’orchestrateur Kubernetes, met à disposition une option intéressante pour les déploiements Blue/Green. L'outil open source Spinnaker CI/CD peut déclencher la création d’un pipeline automatisé qui inclut un environnement de test Canary pour le nouveau code avant le déploiement en production. D'autres modèles de déploiement, avec Spinnaker ou Jenkins, peuvent être adaptés pour un déploiement Blue/Green.