Stratégie de déploiement bleu-vert : explications

Qu’est-ce qu’un déploiement bleu-vert ?

Le déploiement bleu-vert est une stratégie qui consiste à exécuter en parallèle les anciennes et les nouvelles versions d’une application dans deux environnements de production identiques. Par exemple, l’ancienne version s’exécute dans l’environnement bleu, tandis que la nouvelle version est testée dans l’environnement vert. Une fois les tests terminés, un routeur ou un répartiteur de charge redirige progressivement les requêtes vers l’environnement vert. Les développeurs effectuent ensuite des tests de fumée avant de basculer définitivement le trafic vers l’environnement vert.

Cette approche utilise deux environnements de production similaires (bleu et vert) pour déployer des mises à jour logicielles.

• Environnement bleu : la version actuelle de l’application en production

• Environnement vert : la nouvelle version de l’application en cours de test

Comment fonctionne le déploiement bleu-vert ?

Voici comment fonctionne le déploiement bleu-vert :

1. Déployer

La nouvelle version de l’application est déployée dans l’environnement vert

2. Tester

La nouvelle version est testée dans l’environnement vert afin de vérifier qu’elle répond à toutes les exigences de performance et de sécurité

3. Basculer

Une fois la nouvelle version stable, le trafic bascule de l’environnement bleu vers l’environnement vert

4. Revenir en arrière

En cas de problème, le trafic peut être redirigé vers l’environnement bleu

Quand le déploiement bleu-vert est-il efficace ?

Le déploiement bleu-vert est particulièrement efficace dans les situations suivantes :

• Les deux environnements sont identiques et isolés.

• Un routeur ou un répartiteur de charge doit être prévu.

• Le système doit prendre en charge les mises à jour continues.

L’importance du déploiement bleu-vert dans les processus DevOps

Pour qu’un pipeline DevOps soit efficace, il est essentiel de déployer du code auprès des utilisateurs finaux de manière efficiente. Le déploiement continu des changements de code permet de publier rapidement des logiciels, mais peut aussi introduire des bugs et des vulnérabilités qui échappent aux contrôles automatisés. Selon l’organisation, le déploiement du code est confié aux développeurs eux-mêmes ou à une équipe opérationnelle qui déploie les artefacts de build issus du pipeline CI/CD.

Dans les deux cas, les équipes doivent pouvoir tester rapidement les nouvelles versions des applications dans un environnement sandbox, les déployer auprès des utilisateurs, puis revenir aux versions précédentes si des problèmes sont détectés en production. La bascule vers la nouvelle version doit être soigneusement planifiée. Les équipes de développement modernes adoptent souvent la philosophie « publier tôt et souvent », qui ne se prête pas aux déploiements plus complexes nécessitant de programmer une interruption de service en dehors des heures de pointe. La bascule doit être rapide afin de réduire au minimum les interruptions.

Le principe du déploiement bleu-vert consiste à configurer deux environnements de production identiques : l’un pour la version précédente, l’autre pour les tests de préproduction de la nouvelle version. Ces environnements peuvent être des appareils physiques différents, des machines virtuelles distinctes ou des environnements d’exploitation disposant chacun d’adresses IP séparées.

Quels sont les avantages des déploiements bleu-vert ?

• Retour en arrière immédiat. Grâce à la quasi-identité des environnements de préproduction et de production, l’approche bleu-vert permet de mieux détecter les bugs. Si les utilisateurs rencontrent des problèmes avec la nouvelle application dans l’environnement vert, les développeurs peuvent rediriger immédiatement les requêtes vers l’ancienne version exécutée dans l’environnement bleu. Le retour en arrière est ainsi instantané, sans interruption de service pour les utilisateurs.

• Mises à niveau fluides. Les déploiements bleu-vert automatisent la transition entre le moment où le logiciel est « écrit » et sa mise en production. Lors de la première mise à niveau, l’environnement vert sert aux tests, puis devient l’environnement de production de la nouvelle version. L’environnement bleu reste en service pendant un certain temps pour permettre un éventuel retour en arrière. Il est ensuite désactivé et utilisé pour les tests de préproduction du déploiement suivant.

• Aucune interruption de service. Dès qu’ils sont prêts, les développeurs peuvent mettre le nouveau code en production pendant les périodes d’utilisation habituelles. Il n’est pas nécessaire d’attendre les heures creuses, comme tard le soir ou le week-end, ni de programmer une interruption de service. Autre avantage : l’environnement de préproduction peut servir à tester la reprise après sinistre ou de sauvegarde.

Inconvénients du déploiement bleu-vert

Dans certains cas, l’approche bleu-vert comporte des risques susceptibles d’accroître la probabilité d’échec ou de panne du déploiement.

• Synchronisation des bases de données : La gestion des modifications de schéma peut s’avérer complexe. Avec le déploiement bleu-vert, les modifications apportées aux bases de données et aux données doivent être synchronisées entre les environnements bleu et vert. L’absence de synchronisation peut entraîner des incohérences.

• Détection des échecs lors de l’assurance qualité et des tests d’acceptation utilisateur : Dans les grandes infrastructures, les tests d’assurance qualité effectués dans les environnements hors production peuvent passer à côté de certaines erreurs ou de certains bugs, qui risquent alors de ne pas être détectés avant le déploiement.

• Nécessité d’un tableau de bord : Cette méthode implique de maintenir deux environnements de production exécutant des versions différentes du code. Il est donc essentiel de suivre l’état des packages et du code pendant le déploiement afin de garder le contrôle et de déclencher les actions nécessaires.

• Conséquences sur les coûts : Le déploiement bleu-vert nécessite deux environnements parallèles, ce qui double de fait les coûts d’exploitation et de maintenance des environnements de production.

Déploiement bleu-vert et répartition de la charge des applications

Les déploiements bleu-vert doivent être mis en œuvre avec soin pour réduire au minimum les répercussions de la bascule pour les utilisateurs. La mise à jour d’un enregistrement DNS est une façon de procéder, mais cette méthode présente des limites, car la propagation DNS n’est pas immédiate.

Une autre approche consiste à utiliser la répartition de charge des applications pour acheminer progressivement le trafic vers l’environnement vert, ce qui permet de contrôler précisément les utilisateurs concernés. Les répartiteurs de charge peuvent rediriger le trafic en cas d’erreurs dans l’environnement vert et être configurés pour attendre un délai fixe avant de désactiver les utilisateurs ou de mettre fin à leurs sessions dans l’environnement bleu.

Dans l’ensemble, cette approche permet une mise à niveau plus fluide et réduit les perturbations par rapport à une méthode qui obligerait les utilisateurs à fermer leur session avant la redirection du trafic. La répartition de charge peut ralentir le processus ou échouer pour un petit nombre d’utilisateurs, mais la plupart ne remarquent aucune interruption de service ni différence.

Autres stratégies de déploiement

• Déploiement bleu-vert : Le déploiement bleu-vert garantit une haute disponibilité et facilite le retour en arrière en cas de découverte de bugs critiques. Il consiste à exécuter deux environnements en parallèle, l’un en production et l’autre en attente, afin de réduire au minimum les interruptions de service de l’application.

• Déploiement A/B : Comme le déploiement bleu-vert, le déploiement A/B dirige une petite partie du trafic vers un serveur ou un environnement distinct. Cette technique sert souvent à évaluer l’utilisation des fonctionnalités et à recueillir les commentaires des utilisateurs sur une nouvelle version.

• Déploiement Canary : Le déploiement Canary met progressivement de nouvelles fonctionnalités à la disposition d’un sous-ensemble d’utilisateurs, en affectant des serveurs spécifiques à différents groupes. Cette approche est utile pour déployer des fonctionnalités par étapes et recueillir des commentaires tout au long de la mise en production. Déploiement progressif : il consiste à remplacer successivement les serveurs qui exécutent l’ancienne version de l’application par des serveurs exécutant la nouvelle. Cette méthode permet de suspendre plus facilement le déploiement si nécessaire.

En quoi les déploiements bleu-vert diffèrent-ils des déploiements Canary ?

Contrairement aux déploiements bleu-vert, les déploiements Canary ne nécessitent pas d’environnements distincts pour les tests et la production. Les équipes DevOps ou opérationnelles déploient le changement auprès d’un petit groupe d’utilisateurs (le « canari »), testent la version, puis décident de la déployer ou non à l’ensemble des utilisateurs.

Comme ils n’utilisent pas d’environnements distincts, les déploiements Canary ne nécessitent qu’une petite quantité d’infrastructure supplémentaire. Ils peuvent être configurés à l’aide d’un nœud ou d’un serveur disponible, juste ce qu’il faut pour prendre en charge une petite partie de l’environnement de production et un faible volume de trafic.

Déploiements bleu-vert avec l’infrastructure as code (IaC)

Les déploiements bleu-vert sont une méthode efficace pour publier rapidement des logiciels tout en réduisant les risques technologiques et commerciaux. Ils nécessitent également une attention particulière à la sécurité. L’architecture complexe des applications et des environnements dans lesquels elles sont déployées — avec des serveurs web, des conteneurs et des microservices — ainsi que les outils d’automatisation des builds, des tests et des déploiements dans le pipeline CI/CD, peuvent entraîner des erreurs de configuration, des environnements non sécurisés et des surprises après la bascule.

La sécurité traditionnelle des applications ne suffit pas à protéger l’infrastructure IaC. Elle se concentre sur l’application après sa mise en production, ce qui signifie que des bugs et des vulnérabilités peuvent affecter les utilisateurs finaux. Les équipes de sécurité travaillent séparément des développeurs. Lorsqu’elles découvrent des problèmes, elles doivent donc compter sur l’équipe de développement pour les corriger, ce qui crée un goulot d’étranglement dans la livraison et des priorités divergentes entre les développeurs et les professionnels de la sécurité. De plus, la sécurité reste une fonction externe au processus de développement au lieu d’être intégrée au pipeline CI/CD.

Déploiement bleu-vert et outils IaC

Heureusement, il existe une solution. Snyk Infrastructure as Code s’intègre parfaitement au pipeline CI/CD pour sécuriser les configurations avant leur mise en production. La solution est conçue pour les développeurs et permet de corriger automatiquement le code en ligne. Snyk IaC comprend des tests automatisés pour les fichiers et plans Terraform, AWS CloudFormation, les configurations Kubernetes et Azure Resource Manager (ARM). Les équipes de développement peuvent exécuter des analyses IaC tout au long des pipelines CI/CD afin de détecter et de corriger rapidement les problèmes de configuration. Les tests de dérive avec DriftCTL détectent également les changements d’infrastructure effectués après le déploiement par des personnes ou des outils en dehors du flux habituel. Les développeurs prennent ainsi en charge la sécurité des builds, des tests et des déploiements, conformément aux principes DevSecOps, en utilisant des outils IaC pour les déploiements bleu-vert.