Le déploiement bleu/vert, qu'est-ce que c'est ?

Le déploiement bleu/vert est un modèle de publication d'application qui permet de transférer progressivement le trafic utilisateur depuis la version antérieure d'une application ou d'un microservice vers une nouvelle version pratiquement identique, ces deux versions s'exécutant en même temps dans l'environnement de production.

L'ancienne version représente l'environnement bleu, tandis que la nouvelle version représente l'environnement vert. Une fois que le transfert du trafic entre l'environnement bleu et l'environnement vert est achevé, il est possible de conserver l'ancienne version en vue d'une éventuelle restauration, ou de la retirer de l'environnement de production afin de la mettre à jour pour en faire un modèle pour une prochaine mise à jour.

Ce modèle de déploiement continu présente cependant des inconvénients. Tous les environnements n'ont pas les mêmes exigences en matière de disponibilité ni les ressources nécessaires pour mener à bien des processus CI/CD tels que le déploiement bleu/vert. Heureusement, à mesure que les entreprises passent au numérique, de plus en plus d'applications évoluent pour prendre en charge la distribution continue.

Le principe est le suivant : imaginons que vous avez développé une application cloud-native simple, un jeu mobile par exemple, dans lequel les utilisateurs gagnent des points en appuyant sur des ballons de différentes couleurs qui traversent l'écran. Le cœur du jeu est pris en charge par plusieurs microservices basés sur des conteneurs qui gèrent les trophées, les scores, la mécanique du jeu, la communication et l'identification des joueurs.

Des centaines d'utilisateurs ont commencé à jouer au lancement de la première version. Ils enregistrent des milliers de transactions par minute. Votre équipe DevOps vous a conseillé de publier des versions le plus tôt et le plus souvent possible, c'est pourquoi vous êtes sur le point de publier une mise à jour mineure du microservice lié à la mécanique du jeu qui augmente la taille et la vitesse du ballon rouge.

Au lieu d'attendre minuit, le moment où le moins de joueurs sont actifs, pour publier la mise à jour dans l'environnement de production, vous préférez suivre un modèle de déploiement bleu/vert pour mettre à jour l'application pendant son pic d'utilisation. Et vous n'enregistrerez aucun temps d'arrêt.

Parce que vous avez récupéré le microservice chargé de la mécanique du jeu dans l'environnement de production (bleu) et que vous l'avez copié dans un conteneur identique, mais distinct (vert), tout s'est passé de manière fluide. Une fois la taille et la vitesse du ballon rouge augmentées dans l'environnement vert, la mise à jour est passée par une étape d'assurance qualité et de préproduction (peut-être automatisée par un projet Open Source de test de résistance tel que Jenkins), avant sa publication dans l'environnement de production, en parallèle de l'environnement bleu actif.

L'équipe d'exploitation peut alors se servir d'un module d'équilibrage de charge pour rediriger la prochaine transaction de chaque utilisateur depuis l'environnement bleu vers l'environnement vert. Et une fois que la totalité du trafic en production a été basculée vers l'environnement vert, l'environnement bleu peut être désactivé. Celui-ci peut alors être conservé pour servir d'option de récupération après sinistre, ou pour être utilisé comme conteneur pour la prochaine mise à jour.

Kubernetes est l'outil idéal pour tous les éléments associés au processus de déploiement bleu/vert, notamment les applications cloud-native, les microservices, les conteneurs, l'intégration continue, la distribution continue, le déploiement continu, l'ingénierie de la fiabilité des sites et les processus DevOps. Kubernetes est une plateforme Open Source qui automatise l'exploitation des conteneurs Linux®. Elle permet d'orchestrer les conteneurs de microservices d'applications cloud-native. En outre, elle est prise en charge par de nombreux modèles d'architectures que les développeurs peuvent réutiliser au lieu de créer des architectures d'applications en partant de zéro.

Kubernetes utilise notamment le modèle de déploiement déclaratif. Puisque les microservices sont par essence de petite taille, il est possible de les multiplier très rapidement. Le modèle de déploiement déclaratif permet de réduire l'effort manuel nécessaire au déploiement de nouveaux pods, l'unité la plus simple et la plus petite de l'architecture Kubernetes.

Parce que nous avons amélioré la plateforme Kubernetes d'entreprise de référence, Red Hat® OpenShift, en y intégrant des fonctionnalités de CI/CD. Nous avons aussi créé la documentation étape par étape des invites en ligne de commande et des arguments qui permettent d'effectuer des déploiements bleu/vert au sein de votre environnement Red Hat OpenShift.

De plus, avec une plateforme Kubernetes d'entreprise qui reste entièrement Open Source, vous gardez un contrôle total, y compris sur les éléments qui s'y exécutent. C'est ce qui vous permet d'assurer le fonctionnement de vos applications et services, où qu'ils soient et quelle que soit l'infrastructure dont ils dépendent.

N'hésitez donc pas à examiner, modifier et améliorer le code source qui est au cœur de nos technologies. Avec une infrastructure qui repose sur les produits et technologies Red Hat, utilisés par plus de 90 % des entreprises du classement Fortune 500*, rares sont les tâches que vous ne pouvez pas accomplir.