Le déploiement bleu-vert est une stratégie de gestion des rejets qui réduit les temps d'arrêt et les risques en exécutant deux environnements de production identiques, l'un servant actuellement le trafic (bleu) et l'autre au ralenti (vert). Lorsqu'une nouvelle version de l'application est prête, elle est déployée dans l'environnement inactif, testée en profondeur, puis le trafic est commuté. Cette approche élimine le besoin de fenêtres d'entretien, permet un renversement instantané et assure une séparation nette entre l'ancien et le nouveau code.

Pourquoi le déploiement bleu-vert est important

Les méthodes de déploiement traditionnelles, comme les mises à jour en roulement ou les versions canari, exposent encore les utilisateurs à des temps d'arrêt partiels ou à des performances dégradées pendant les transitions. Le déploiement bleu-vert s'attaque à cette situation en maintenant l'ancien environnement pleinement opérationnel jusqu'à ce que le nouveau soit vérifié.

  • Déploiements de temps d'arrêt zéro:[ Aucune fenêtre de temps lorsque l'application n'est pas disponible.
  • Reversement instantané:[ Remettre le trafic à l'ancien environnement en quelques secondes si des problèmes surgissent.
  • Essais isolés en production: Valider la nouvelle version dans des conditions réelles sans affecter les utilisateurs.
  • Transactions de base de données simplifiées: Peut être géré avec une mise en version minutieuse du schéma et une compatibilité arrière.
  • Vacilité de l'équipe améliorée:[ Les développeurs peuvent sortir plus souvent avec moins de peur.

Intégration du déploiement bleu-vert aux pipelines CI/CD

Les pipelines CI/CD automatisent les phases de construction, de test et de déploiement. Combinés au bleu-vert, le pipeline devient l'orchestreur de la commutation d'environnement. Le débit typique ressemble à ceci :

  1. Construire et tester: Le code s'engage à déclencher une construction. Tests unitaires, tests d'intégration et balayages de sécurité exécutés dans le pipeline.
  2. Déployer vers un environnement inactif:[ Le pipeline déploie l'artéfact dans l'environnement qui ne sert pas actuellement de trafic (p. ex. vert si le bleu est actif).
  3. Essais de fumée et d'acceptation:[ Des essais automatisés sont effectués dans le nouvel environnement pour vérifier la fonctionnalité, les performances et la cohérence des données.
  4. Switch Traffic:[ Un bilanur de charge ou un enregistrement DNS est mis à jour pour acheminer tout le trafic utilisateur vers le nouvel environnement.
  5. Validation après le déploiement: Les contrôles et la surveillance de la santé se poursuivent pendant une période de refroidissement.
  6. Nettoyage (facultatif):[ L'ancien environnement est soit conservé comme cible de renversement ou détruit après une période de refroidissement.

Mise en place de deux environnements identiques

La parité d'environnement est cruciale. Les environnements bleu et vert doivent être identiques dans le matériel, la configuration, la topologie du réseau et les données, à l'exception de la version d'application. Utilisez l'infrastructure comme outil de code (IaC) comme Terraform, CloudFormation ou Pulumi pour fournir les deux environnements à partir du même modèle. La réplication de la base de données doit être configurée de manière à ce que les deux environnements partagent le même ensemble de données (ou aient une stratégie de migration qui permet des changements de schéma sûrs).

Considérations relatives aux bases de données

Les services d'État, en particulier les bases de données, facilitent les déploiements bleu-vert.

  • Migrations compatibles avec le retour :[ Appliquer les changements qui fonctionnent avec l'ancien et le nouveau code (p. ex. ajouter des colonnes mais ne pas les déposer).
  • Replication et lecture des répliques:[ Pointez les deux environnements dans la même base de données, mais assurez-vous que les écritures ne se produisent que depuis l'environnement actif.
  • Schema-par-environnement: Isoler les bases de données pour chaque environnement et gérer la synchronisation avec un outil de migration.

Des outils comme Flyway ou Liquibase peuvent gérer des migrations progressives qui sont sûres pour les flux bleu-vert.

Interrupteur automatique de trafic

Le commutateur de trafic peut être mis en œuvre au niveau de l'équilibreur de charge (Layer 7), du DNS (Layer 4/7), ou du routeur. Pour les déploiements cloud-native, les services comme AWS ALB, Google Cloud Load Balancer ou Kubernetes Service+Ingress rendent cela simple. Le pipeline CI/CD devrait déclencher le commutateur via des appels API ou des mises à jour de configuration.

  • Vérifications de santé: Le régulateur de charge doit vérifier que le nouvel environnement est sain avant d'accepter le trafic.
  • Drainage gracieux:[ L'ancien environnement devrait terminer les demandes en vol avant d'être retiré de la rotation.
  • Constante de la session:[ Si votre application utilise des sessions collantes, assurez-vous que le commutateur ne brise pas le contexte utilisateur.

Outils qui simplifient le bleu-vert avec CI/CD

Une variété de plateformes et d'outils de déploiement de CI/CD ont un support natif pour les stratégies bleu-vert. Voici quelques-uns des plus populaires:

Jenkins avec Ansible ou Spinnaker

Vous pouvez définir les étapes de pipeline qui appellent les playbooks Ansible pour mettre à jour la configuration de l'équilibreur de charge ou utiliser Spinnaker , une stratégie intégrée rouge/noir. Spinnaker fournit même une interface utilisateur visuelle pour approbation manuelle avant le commutateur.

GitLab CI avec Auto DevOps

GitLab Auto DevOps comprend une étape intégrée de déploiement --bleu-vert lorsqu'elle est déployée sur Kubernetes. Elle crée deux déploiements (bleu et vert) et un service qui retourne les étiquettes `activeSelector`. La documentation GitLab=»s fournit un guide étape par étape.

Actions GitHub avec AWS CodeDeploy

Un workflow GitHub Actions peut pousser le code vers un seau S3, puis déclencher une révision d'application CodeDeploy. Le groupe de déploiement fournit automatiquement de nouvelles instances, vérifie la santé et le trafic de quarts. La documentation AWS explique la configuration.

Argo Rollouts sur Kubernetes

Argo Rollouts propose des stratégies de déploiement avancées, y compris bleu-vert. Il s'intègre aux contrôleurs d'entrée et aux maillages de service pour automatiser le déplacement du trafic. Les Rollbacks sont déclaratifs et peuvent être déclenchés automatiquement sur la base de mesures. En savoir plus sur Argo Rollouts.

Meilleures pratiques pour les déploiements de production-classe

Mettre en œuvre le bleu vert est plus que de simplement changer de serveur. Pour éviter les pièges communs, suivez ces meilleures pratiques :

Automatiser tout

Les étapes manuelles doivent introduire des erreurs.L'ensemble du pipeline, du bâtiment au passage du trafic, doit être automatisé.Utilisez les définitions de pipelines contrôlées par version (par exemple, `Jenkinsfile`, `.gitlab-ci.yml`, YAMLs de workflow) et assurez-vous que les tests sont effectués automatiquement sur chaque déploiement.

Utiliser les drapeaux de caractéristiques

Combinez le bleu-vert avec les drapeaux de fonction pour découpler le déploiement de la version. Vous pouvez déployer le code avec de nouvelles fonctionnalités cachées et les activer progressivement via les outils de gestion de drapeau (LaunchDarkly, PostHog, Unleash). Cela évite la nécessité de retourner en arrière l'environnement entier si une fonctionnalité échoue.

Mettre en œuvre des tests complets

Les tests de fumée doivent vérifier les réponses HTTP de base, la connectivité de la base de données et les parcours critiques des utilisateurs. Utilisez des outils de surveillance synthétique (p. ex. Checkly, Datadog Synthetics) pour exécuter les tests du navigateur contre l'environnement inactif avant de passer au changement.

Surveiller en permanence

Après le commutateur, surveiller les paramètres d'application, les taux d'erreur, latence et les KPI d'affaires. Utilisez l'alerte (PagerDuty, Opsgenie) pour déclencher le renversement automatique si les seuils d'anomalie sont violés. Par exemple, si les erreurs 5xx augmentent de 50%, retournez le trafic à l'ancien environnement.

Plan pour les éléments d ' État

Les téléchargements de fichiers, les sessions d'utilisateurs et les files d'attente des emplois doivent être traités avec soin. Utilisez le stockage partagé externe (S3, EFS) et les caches distribués (Redis, Memcached) auxquels les deux environnements peuvent accéder.

Définir une période de refroidissement

Après avoir changé de trafic, gardez l'ancien environnement en marche pendant un temps défini (par exemple, 30 minutes) pour permettre un retour rapide si un bug subtil est découvert.

Défis et comment les surmonter

Migrations de schéma de base de données

Le plus grand défi est de gérer les changements de base de données qui brisent la compatibilité en arrière.

  • Utilisez uniquement les migrations additives (ajouter des colonnes, pas les laisser tomber).
  • Enlever les anciennes colonnes dans une migration séparée, post-switch.
  • Déployer les données change avant la nouvelle version de l'application, garantissant que l'ancien code peut encore fonctionner.

Coût

L'exécution de deux environnements de production identiques double le coût de l'infrastructure. Atténuations : utiliser de plus petites instances pour l'environnement inactif pendant les essais, ou utiliser la conteneurisation pour partager les ressources sous-jacentes.

Session et réchauffage de cache

Lorsque le trafic change, les caches sont froids. Préchauffer le nouvel environnement en simulant les requêtes des utilisateurs typiques avant de passer au changement.

Configurations réseau

Les règles de pare-feu, les enregistrements DNS et les certificats SSL doivent être identiques dans tous les environnements. Utilisez IaC pour assurer la cohérence.

Exemple du monde réel : Plateforme de commerce électronique

Un détaillant en ligne avec 10 millions de visiteurs quotidiens a besoin de déployer de nouvelles fonctionnalités chaque semaine sans temps d'arrêt. Ils ont adopté le déploiement bleu-vert avec la configuration suivante:

  • Deux groupes de calibrage automatique AWS (bleu, vert) derrière un ALB.
  • Terraform à fournir une infrastructure identique.
  • GitLab CI pipeline: construire, tester, déployer en vert, exécuter des tests de fumée Playwright, puis déclencher ALB groupe cible commutateur.
  • Redis pour les sessions partagées entre environnements.
  • Migrations de bases de données : compatible avec le rétro-compatible, avec Flyway.
  • Retour automatique si taux d'erreur > 1% dans les 5 premières minutes.

Résultat : la fréquence de déploiement est passée de mensuellement à hebdomadaire, avec zéro incident d'arrêt sur six mois.

Conclusion

Le déploiement bleu-vert, lorsqu'il est intégré à un pipeline moderne de CI/CD, offre un moyen puissant de libérer les logiciels en toute sécurité et fréquemment. Il élimine les temps d'arrêt, permet un retour instantané et donne confiance aux ingénieurs pour pousser les changements rapidement. Bien que des défis comme les migrations de bases de données et le coût de l'infrastructure existent, ils peuvent être gérés avec une planification minutieuse et l'outil approprié. En automatisant l'ensemble du processus – de l'approvisionnement en environnement au changement de trafic – les équipes peuvent obtenir une livraison continue avec un risque minimal.