DevSecOps – Modèle de déploiement bleu / vert

Le but de tout programme de développement logiciel est de mettre en production les modifications du système. Il existe de nombreuses façons de déployer des logiciels en toute sécurité dans un environnement de production. Dans la plupart des cas, ces modèles suivent une stratégie similaire de limitation de l'exposition des modifications logicielles publiées à l'audience globale des utilisateurs. Ceci est fait pour réduire l'impact d'un déploiement qui a échoué, pour offrir une opportunité de rétroaction d'un groupe d'utilisateurs sélectionné ou pour fournir un déploiement sans interruption de service sans temps d'arrêt aux utilisateurs. L'un des plus courants est le modèle de déploiement «bleu / vert».

Un déploiement bleu / vert consiste à segmenter le système de production en deux environnements – l'un (actif) avec le système de production actuel déployé et l'autre (intermédiaire). pour la nouvelle version. Comme le montre la figure 1 ci-dessous, ces environnements commutent les rôles d'une version à la suivante, agissant à leur tour comme cible intermédiaire ou active. Le reste de ce billet de blog présentera la stratégie de déploiement bleu / vert en utilisant le format de modèle de logiciel standard.

• Nom du modèle: Déploiement bleu / vert
• Intention: Réduisez le risque de nouvelle version en déployant sur un environnement parallèle non vivant
• Également connu sous le nom de: Déploiement sans interruption de service
• Motivation (Forces): Le déploiement en production comporte toujours un risque d'échec du déploiement entraînant une panne du système et un impact sur l'utilisateur. En déployant dans un environnement non vivant distinct, la version peut être complétée et vérifiée avant de devenir le site de production. De plus, l'environnement de production d'origine peut être conservé en tant que solution de repli pendant la période de «rodage» de la nouvelle version.
• Applicabilité: Ce modèle est bien adapté aux calendriers de sortie de production rapide basés sur un déploiement continu ( CD) via un pipeline DevOps automatisé. En particulier, ce modèle prend en charge les pratiques de développement agiles avec des cycles de version courts (par exemple 2 à 3 semaines) en permettant des déploiements contrôlés dans un environnement «intermédiaire» avant la version de production complète.
• Structure:

Figure 1. Schéma de déploiement bleu-vert

• Collaboration: Les environnements «bleu» et «vert» font tourner la responsabilité de l'hébergement du application / système de production. L'équilibreur de charge est la clé de la mise en œuvre du modèle pour faciliter la transition du trafic utilisateur d'un environnement à l'autre avec une interruption minimale. L'ajout d'un déploiement automatisé via un pipeline DevOps garantit un mécanisme sécurisé et cohérent de configuration du déploiement.
• Conséquences: Ce modèle nécessite la possibilité de diriger tout le trafic de production vers un environnement (c'est-à-dire un environnement «bleu») tout en le déploiement de la version est en cours vers l'autre cible. Après le déploiement, le trafic des utilisateurs est redirigé vers le système nouvellement déployé (par exemple «vert») tandis que le système de production d'origine est maintenu en tant que solution de repli (par exemple «bleu»). Pour les déploiements ultérieurs, le modèle d'utilisation de l'environnement est alterné.
• Implémentation:

Sur site (au sol)

Pour une norme solution hébergée de centre de données, l'implémentation typique est d'avoir des environnements de longue date qui sont configurés comme un ensemble de serveurs principal («chaud») et secondaire («froid»). Celles-ci sont gérées par l'équilibreur de charge agissant en tant que garde-porte pour le routage du trafic vers les deux environnements. Dans cette configuration, tous les éléments du réseau sont préconfigurés avec les adresses des serveurs cibles (virtuels ou non virtuels) qui ne changent pas pendant ou après la fin de la publication. Les environnements «bleu» et «vert» doivent être identiques, mais peuvent être hébergés dans des emplacements géographiques différents.

Hors site (Cloud)

Pour une solution basée sur le cloud pour ce modèle, l'implémentation typique se fera via des serveurs virtuels hébergés contenus dans un réseau virtuel. Cette option est plus flexible dans la mesure où les ressources peuvent être créées ou détruites selon les besoins (par exemple, voir Variante – Infrastructure en tant que code ci-dessous), et l'adressage réseau est automatiquement mis à jour si nécessaire pour les routeurs virtuels. De plus, les serveurs peuvent être configurés automatiquement pour augmenter la capacité («mise à l'échelle automatique») en fonction des besoins du trafic utilisateur. Semblable à l'implémentation de modèle basé sur le «sol», les ressources utilisées dans les environnements «bleu» et «vert» peuvent être réparties géographiquement.

• Variante – Infrastructure as Code (IaC)

Figure 2. Variante de déploiement bleu-vert – Infrastructure en tant que code (IaC)

dans cette variante du modèle, l'environnement cible de déploiement de la version n'existe pas tant qu'il n'est pas créé par le pipeline DevOps. Cela nécessite que toute la configuration d'environnement nécessaire (y compris le renforcement de la sécurité) soit codée et testée avant le déploiement de la version. En utilisant Infrastructure as Code (IaC), les serveurs cibles et d'autres composants réseau peuvent être prédéfinis et stockés avec la base de code de l'application. De cette manière, l'application et l'environnement cible évoluent toujours ensemble. Dans le déploiement bleu-vert, l’environnement «vert» est d’abord créé, puis l’unité déployable est déployée dans le nouvel environnement. Après le déploiement, l'environnement «bleu» d'origine doit être détruit une fois que l'environnement «vert» est considéré comme stable en production.

Notez que cette variante peut être utilisée dans des implémentations «sol» ou «cloud», mais elle est plus courante pour trouver les approches IaC utilisées dans le développement agile basé sur le cloud.

• Variante – Déploiement basé sur des conteneurs

Figure 3. Variante de déploiement Blue-Green – Containers

Dans cette variante du modèle, la cible de déploiement de version est représentée comme une collection d'un ou plusieurs conteneurs (par exemple Docker). L'environnement cible est géré par le «gestionnaire de conteneurs» qui est responsable de l'exécution et de la gestion de tous les hôtes de conteneurs (par exemple Kubernetes). Le déploiement est géré par l’automatisation du pipeline DevOps, mais dans ce cas, il s’agit d’un conteneur plutôt que d’une «unité déployable» gérée dans un registre de conteneurs. Après la libération, une fois que l'environnement «vert» est considéré comme stable en production, les conteneurs représentés par le groupe de conteneurs «bleu» doivent être détruits.

• Compromis: Selon la variante du modèle utilisé (sol- basé sur le cloud, IaC ou conteneur), il y a des avantages et des inconvénients. Dans le cas des implémentations «au sol», il est nécessaire de maintenir à tout moment un environnement de «staging» distinct. Cela représente une dépense importante, mais est compensé dans une certaine mesure par la prise en charge de la continuité des opérations de basculement. Dans l'approche basée sur l'IaC, il est nécessaire de définir entièrement l'ensemble de l'environnement cible en tant que fichiers de déclaration (Ansible / Chef-Infra / Azure Resource Template / etc.). Cela inclut toute la gestion des secrets, la configuration du réseau et le renforcement de la sécurité du système d'exploitation nécessaires. Pour les déploiements basés sur des conteneurs, un registre et un gestionnaire de conteneurs doivent être ajoutés au modèle de solution, ainsi que la création appropriée des images de conteneur initiales utilisées pour le déploiement.
• Utilisations connues: Ce modèle est bien connu et utilisé par une variété d'équipes de développement logiciel. Il est le plus souvent trouvé avec des équipes de développement agiles utilisant des ressources basées sur le cloud, mais il est également fréquemment mis en œuvre dans des centres de données sur site utilisant des environnements cibles non virtualisés.

Conclusion

Un modèle cohérent pour un déploiement automatisé, tel que présenté ici, fournit à vos équipes un mécanisme prévisible pour les versions de production. Il existe de nombreux modèles liés au bleu / vert, tels que divulgation progressive, déploiement de canaris, basculement de fonction et test A / B . Chacun de ces modèles offre une orientation différente pour un déploiement de production automatisé et sera exploré plus en détail dans les prochains articles de blog.

À propos de l'auteur <! -: blieberman, Architecte principal de solutions – >

Ben Lieberman est actuellement architecte de solutions senior au sein du groupe de livraison DevOps de Perficient Inc.. Le Dr Lieberman a plus de vingt ans d'expérience en développement de logiciels et de systèmes dans un large éventail d'industries, notamment les finances, le gouvernement, les télécommunications, les sciences de la vie, les services de voyage et les systèmes de lancement spatial. Il est très expérimenté sur plusieurs sujets de développement logiciel, y compris l'analyse des exigences, l'analyse et la conception de systèmes, le développement de systèmes sécurisés, la gestion de configuration et le déploiement automatisé (alias DevSecOps). Il possède également une expérience en développement direct dans plusieurs langages, notamment les langages de codage Java, C #, C ++ et Salesforce (APEX), et travaille directement avec les équipes de développement sur les pratiques de livraison agiles. Le Dr Lieberman est un écrivain professionnel accompli avec un livre («The Art of Software Modeling», Auerbach Publishing, 2006) et plus de trois douzaines d'articles professionnels en informatique à son actif. Le Dr Lieberman est titulaire d'un doctorat en biophysique et génétique de l'Université du Colorado, Anschutz Medical Center, Denver, Colorado.

Plus d'informations sur cet auteur