Création d'un pipeline de déploiement multi-cloud dynamique et évolutif avec GitLab

L'équipe de solutions de Volterra conçoit et maintient de nombreux cas d'utilisation potentiels de la plateforme Volterra pour démontrer sa valeur potentielle. Ces cas d'utilisation sont souvent transformés en guides pédagogiques que les clients utilisent pour acquérir une première expérience pratique avec Volterra.

L'équipe de solutions souhaitait une méthode plus rapide et automatisée pour déployer nos cas d'utilisation à la demande en interne avec le moins d'intervention humaine possible. Nos déploiements couvraient un environnement multi-cloud hybride utilisant à la fois des plateformes IaaS (AWS, Azure et GCP) et des environnements de centre de données privé (VMware vSphere et Vagrant KVM). Nous voulions simplifier la gestion de ces environnements en fournissant un outil unique capable de créer des déploiements dans n’importe quel environnement sans que les utilisateurs individuels aient besoin de créer des comptes d’accès supplémentaires ou de gérer des informations d’identification d’utilisateur supplémentaires pour chaque plate-forme de virtualisation ou fournisseur IaaS. Cet outil devait également être évolutif pour prendre en charge plusieurs utilisateurs et déploiements simultanés.

En résumé, le problème central que nous souhaitions résoudre était de créer un outil de déploiement de cas d’utilisation de solutions automatisé, capable de faire évoluer et de gérer des déploiements simultanés dans des environnements multi-cloud hybrides avec le moins d’intervention de l’utilisateur possible.

Le projet Carbone Altéré (AC)

À cette fin, nous avons créé un projet appelé Altered-Carbon, souvent abrégé en AC. Le projet AC est un pipeline GitLab dynamique capable de créer plus de 20 cas d'utilisation de solutions Volterra différents. Grâce à l’automatisation des pipelines, nous avons créé des « déploiements par bouton-poussoir » à commande unique permettant aux utilisateurs de déployer facilement plusieurs clusters de cas d’utilisation à la demande ou via des tâches cron quotidiennes planifiées.

Pour référence, dans AC, nous désignons chaque déploiement par une PILE et chaque cas d'utilisation unique par un MANCHE .

Développement de projet

Nous avons commencé le développement du projet AC en automatisant le cas d'utilisation hello-cloud dans le premier SLEEVE. Le cas d'utilisation hello-cloud crée un site Volterra dans AWS et Azure, puis combine ces sites dans un cluster Volterra VK8s (Kubernetes virtuel) et déploie une application de 10 pods sur les deux sites à l'aide des VK8s. Nous avons commencé le processus en créant des modèles Terraform supplémentaires et des scripts shell utilisant l'API Volterra afin de créer un flux de travail GitLab entièrement automatisé que les pipelines CI/CD pourraient gérer. Nous nous sommes ensuite mis au travail pour rendre cette méthodologie de déploiement réutilisable et évolutive.

L’ajout de conventions de dénomination uniques était le prochain problème que nous avons abordé dans notre conception. Pour permettre plusieurs déploiements du cas d'utilisation sur un seul environnement de locataire Volterra, nous devions nous assurer que nos ressources créées dans chaque PILE avaient des noms uniques et n'essaieraient pas de créer des ressources avec des noms dupliquant d'autres PILE dans le même environnement de locataire Volterra. Pour résoudre d’éventuels conflits de conventions de dénomination, nous avons commencé à incorporer l’idée de variables environnementales uniques fournies par l’utilisateur dans les déclencheurs de pipeline qui deviendraient essentiels au projet. La variable d'environnement STACK_NAME a été introduite et utilisée par Terraform pour inclure une chaîne définie par l'utilisateur dans les noms de toutes les ressources associées à une PILE spécifique. Au lieu de se déclencher lors de la validation, les conditions de déclenchement des tâches des pipelines AC ont été définies pour s'exécuter uniquement lorsqu'elles sont déclenchées par un appel d'API d'utilisateurs GitLab à l'aide d'un jeton de déclenchement CI du projet GitLab permettant au pipeline d'être contrôlé par une entrée humaine ou des appels d'API externes. En utilisant des appels d’API similaires à l’exemple suivant, nous avons permis aux utilisateurs d’atteindre notre objectif de créer plusieurs déploiements sans conflits de ressources avec une seule commande.

Nous avons ensuite essayé de créer des options de déploiement supplémentaires à partir de ce modèle. Les déploiements sur les sites AWS et Azure de hello-cloud étaient également des cas d'utilisation individuels que nous souhaitions déployer indépendamment avec AC. Cela nous a amené à rencontrer notre premier problème majeur avec GitLab. Dans les pipelines CI/CD de GitLab, tous les travaux d'un pipeline de projets sont connectés. Cela était contre-intuitif, car de nombreuses tâches nécessaires à notre déploiement Hello Cloud ne seraient pas nécessaires dans nos déploiements de sites AWS ou Azure. Nous voulions essentiellement qu’un pipeline CI de projet GitLab contienne plusieurs pipelines indépendants qui pourraient être déclenchés à la demande avec des ensembles distincts de tâches CI lorsque cela était nécessaire.

Pour résoudre ce problème, nous avons introduit la variable d’environnement SLEEVE dans la structure du pipeline qui incorporait les options GitLab CI/CD uniquement/sauf . Cela permettait de limiter les tâches CI déclenchées sur n'importe quel pipeline en fonction de la valeur du SLEEVE fourni dans le déclencheur du pipeline. Finalement, nous avions nos 3 options SLEEVE initiales : simple-aws, simple-azure et hello-cloud. Chaque SLEEVE définirait le cas d'utilisation qu'un utilisateur souhaite déployer (contrôlant ainsi les tâches CI dans un pipeline déclenché) et un STACK_NAME pour nommer les ressources créées par tout pipeline déclenché. La structure de commande suivante incorporant les deux variables d'environnement a servi de commande AC la plus basique qui est encore utilisée aujourd'hui :

L'image suivante montre une visualisation de la manière dont la modification de la variable d'environnement SLEEVE modifiera les tâches déclenchées à chaque exécution du pipeline AC.

Pipeline SLEEVE « simple-aws » :

Pipeline SLEEVE « hello-cloud » :

Nous avons également introduit des tâches supplémentaires qui seraient déclenchées si la variable d’environnement DESTROY était fournie dans n’importe quel déclencheur de pipeline. Cela fournirait une option inverse pour supprimer les ressources créées par AC. Voici un exemple de ce qui supprimerait les ressources d'une PILE existante :

D’autres variables environnementales étaient stockées dans GitLab avec des valeurs par défaut qui pouvaient être remplacées en ajoutant des valeurs dans la commande de déclenchement. Par exemple, l’URL de l’API de nos environnements locataires Volterra était stockée dans la variable d’environnement VOLTERRA TENANT. Si un utilisateur ajoutait la variable d’environnement VOLTERRA TENANT à sa commande API, cela remplacerait la valeur par défaut et redirigerait le déploiement vers l’emplacement souhaité. Cela s'est avéré très important pour notre capacité de test interne, car l'équipe de solutions gère des dizaines d'environnements locataires Volterra et a besoin de pouvoir basculer entre eux en fonction de la tâche à accomplir :

Ces variables d'environnement facultatives pourraient être utilisées pour ajouter un plus grand niveau de contrôle sur les déploiements lorsque cela est nécessaire, mais permettaient une option de déploiement par défaut plus simpliste pour les utilisateurs qui ne souhaitaient pas gérer cette surcharge supplémentaire. Cela nous a également permis de basculer facilement entre les déploiements dans les environnements de préparation et de production, ce qui s'est avéré essentiel pour notre plus gros consommateur de courant alternatif.

Cas d'utilisation des solutions : Test de régression nocturne

Comme mentionné précédemment, chaque MANCHON dans AC représentait un cas d’utilisation Volterra qui serait souvent la première interaction des clients avec le produit. S’assurer que ces cas d’utilisation étaient fonctionnels et sans bugs était essentiel pour fournir une première impression forte du produit. Avant la création d'AC, tester les cas d'utilisation pour confirmer qu'ils étaient fonctionnels et à jour avec les dernières versions du logiciel Volterra et de l'API était une tâche fastidieuse. Les parties manuelles requises pour chaque cas d’utilisation créaient une limitation sur les tests de régression, qui n’étaient pas effectués assez souvent et étaient sujets à des erreurs humaines.

Cependant, avec l'automatisation AC, les tâches planifiées quotidiennement pourraient être utilisées pour déclencher un déploiement de n'importe quel cas d'utilisation spécifique avec un SLEEVE, puis supprimer les ressources créées une fois le déploiement terminé ou échoué. Cette méthode a été utilisée dans les environnements de préparation et de production pour tester si les modifications récentes dans l'un ou l'autre avaient affecté le déploiement du cas d'utilisation ou provoqué des bogues dans le logiciel Volterra. Nous serions alors en mesure de mettre à jour les bugs trouvés dans nos guides de cas d'utilisation ou de détecter rapidement les bugs du logiciel Volterra et de soumettre des tickets de résolution.

Nous avons créé un référentiel et un pipeline distincts avec des tâches planifiées qui utiliseraient les commandes de déclenchement de l'API GitLab pour générer simultanément plusieurs piles à l'aide de différents SLEEVE. Chaque test de fumée commencerait par déclencher la création d'une pile avec un pipeline AC indépendant. Le travail de test de fumée obtiendrait ensuite l'ID du pipeline à partir de la sortie standard de l'appel de déclenchement du pipeline et de l'API GitLab pour surveiller l'état du pipeline qu'il a déclenché. Une fois le pipeline terminé (avec succès ou échec), il exécute ensuite le pipeline de destruction sur la même PILE qu'il a créée pour supprimer les ressources après le test.

L'image suivante détaille ce processus et montre les tâches qu'il déclenche dans AC pour ses commandes de création et de destruction :

Lorsqu'un pipeline de test de fumée a échoué, nous avons pu fournir les variables environnementales qui pourraient être utilisées dans un déclencheur AC pour reproduire le problème. Cela pourrait être fourni dans nos tickets de problèmes techniques, permettant à nos développeurs de recréer facilement les déploiements ayant échoué. Ensuite, à mesure que davantage de SLEEVES ont été terminés, nous avons ajouté de plus en plus de tâches aux pipelines CI, permettant une plus grande couverture de test. Pour améliorer encore la visibilité de ces tests, nous avons ajouté une intégration Slack et avons fait en sorte que les tâches de test de fumée envoient le message de réussite ou d'échec de chaque exécution de pipeline avec des liens et des détails vers les pages Web CI correspondantes dans les projets Altered-Carbon et Smoke-Test.

Tenue de registres de pile et navigation dans l'URL Web du pipeline

La complexité du projet a augmenté à mesure qu'AC évoluait, ajoutait des utilisateurs supplémentaires de l'équipe de solutions et créait de plus en plus de piles. Cela a commencé à créer des problèmes fondamentaux lors de la navigation dans l'interface utilisateur Web de GitLab Pipeline. Nous utilisions les pipelines GitLab d'une manière très peu traditionnelle, ce qui rendait l'interface utilisateur Web du pipeline GitLab difficile à utiliser pour tracer les exécutions de pipeline individuelles liées aux STACK que nous créions.

Les pipelines GitLab qui gèrent les déploiements via les workflows GitOps semblent les mieux adaptés lorsqu'ils sont utilisés sur un ensemble statique défini de clusters. Dans ce cas, chaque exécution d’un pipeline GitLab affecterait les mêmes clusters et ressources à chaque fois. Dans ce cas, l'historique de déploiement de ces clusters correspond à l'historique du pipeline visualisé dans l'interface utilisateur Web de GitLab. Cependant, AC est dynamique et gère un ensemble de ressources en constante évolution, où chaque exécution de pipeline peut utiliser un ensemble de tâches totalement différent, gérant différentes piles de ressources, dans différents fournisseurs de virtualisation. Cette différenciation créée par les conventions SLEEVE et STACK signifie qu’il est très difficile de déterminer quel pipeline correspond à quelle pile. Par exemple, nous pouvons jeter un œil à l'interface utilisateur Web du pipeline CI/CD de GitLab pour AC :

De ce point de vue, nous ne pouvons pas déterminer quelle PILE ou MANCHON un pipeline est en train de changer sans visualiser chaque pipeline individuellement. Lorsque des centaines de pipelines sont exécutés par jour, il peut être fastidieux de trouver l'exécution de pipeline spécifique qui a créé ou détruit une PILE en particulier ou de localiser des détails spécifiques sur ladite PILE. Pour résoudre ce problème dès le début du développement du courant alternatif, nous avons ajouté un système simple de tenue de registres. Un travail s’exécuterait avant tout pipeline appelé stack-records. Ce travail collecterait les détails sur la pile lors de la création et générerait un fichier json qui serait téléchargé dans notre bucket de stockage S3 utilisé pour stocker nos sauvegardes tfstate. Ci-dessous, nous voyons un exemple d’enregistrement de pile :

Les fichiers stack-record.json incluent des détails sur chaque pile tels que :

• Quel environnement locataire Volterra a été utilisé.
• Quel MANCHON a été utilisé.
• Si la PILE était actuellement en cours d'exécution dans l'état « appliquer » ou si ses ressources ont été supprimées avec l'état « détruire ».
• Quel utilisateur GitLab a créé la pile.
• Un groupe de travail répertoriant d’autres utilisateurs ayant accès à la modification d’une PILE.
• Et surtout, un tableau de pipelines qui inclurait l'URL Web de chaque exécution de pipeline sur la pile, qui a déclenché le pipeline, si le pipeline a appliqué ou détruit une pile et quand le pipeline a été déclenché.

Cela a fourni un historique enregistré de toutes les URL de pipeline associées à une pile et un script CLI simple pouvant accéder à ces fichiers via des appels API S3 a été créé pour simplifier davantage le processus. Nos utilisateurs consommant de la climatisation pourraient utiliser ces documents pour suivre l'historique des piles et voir quand ces piles ont été modifiées en visualisant les enregistrements des piles.

Les enregistrements de pile nous ont également permis d’implémenter certains niveaux de contrôle utilisateur et de détection des erreurs sur les pipelines que nous déployons. Par exemple, une modification apportée au logiciel Volterra après la création d'AC nous a obligé à commencer à limiter les noms de clusters de sites (une valeur dérivée de la valeur STACK NAME) utilisés dans la création de sites Volterra à une limite de 17 caractères. Nous avons donc ajouté une vérification sur le travail d’enregistrement de la pile qui provoquerait l’échec des pipelines avant d’exécuter les étapes de déploiement si le NOM DE LA PILE violait la limite de caractères. D'autres contrôles personnalisés ont été ajoutés, tels que l'ajout de niveaux d'autorisation utilisateur dans AC qui limitent les utilisateurs ayant accès à la modification de piles spécifiques contrôlées par AC.

• Autorisations de niveau administrateur où les deux principaux développeurs d'AC ont la possibilité de créer ou de détruire n'importe quelle pile à des fins de débogage. -Le niveau propriétaire ou créateur est destiné à un utilisateur GitLab qui crée initialement une PILE. Leur valeur de courrier électronique GitLab est enregistrée dans les enregistrements de la pile en tant que créateur et a la capacité de créer ou de détruire une pile.
• Ensuite, nous avons des autorisations au niveau du groupe de travail, l’e-mail de l’utilisateur GitLab peut être ajouté dans le tableau du groupe de travail d’enregistrement de la pile, accordant aux utilisateurs autres que le créateur la possibilité d’appliquer ou de détruire une PILE.
• Un utilisateur sans aucun de ces niveaux d’autorisation ne pourra pas modifier une pile. Si un tel utilisateur tente de modifier une pile sur laquelle il n'a aucune autorisation, le travail d'enregistrement de la pile échouera avant que les ressources ne soient déployées.

Utilisation interne et couverture des tests actuels

Aujourd'hui, AC est devenu un élément central de l'équipe de solutions, fournissant la plupart de nos tests de régression et de notre automatisation. Nous trouvons que ses principales utilisations sont les tests de fumée de régression, les tests d'échelle, les tests de facturation de produits et les déploiements simplifiés utilisés dans les démonstrations de produits.

Les déploiements automatisés ont trouvé leur plus grand consommateur dans nos tests de régression nocturnes. Chaque nuit, nous testons chacun de nos SLEEVES dans un environnement de production et de préparation en déclenchant un déploiement, puis en supprimant les ressources créées. Lorsque des changements surviennent, nous sommes rapidement en mesure de les détecter et de soumettre des rapports de bogues pour mettre à jour nos guides. Notre couverture de tests actuelle comprend :

• Passerelle Kubernetes sécurisée.
• Sécurité des application Web.
• Applications Network Edge qui déploient notre application standard à 10 pods « hipster-co » et une application à pod unique plus légère.
• Bonjour-Cloud.
• Interface réseau unique à nœud unique CE pour sites Volterra sur AWS, GCP, Azure, VSphere et KVM/Vagrant.
• Interface réseau double à nœud unique CE pour sites Volterra sur AWS, GCP, Azure, VSphere et KVM/Vagrant.
• Déploiements de sites Volterra à interface réseau unique à nœud unique CE mis à l'échelle (à l'aide de GCP, VSphere et KVM), créant un certain nombre de sites Volterra à interface réseau unique à nœud unique CE pour tester les capacités de mise à l'échelle de Volterra.
• Interface réseau multi-nœud CE à nœud unique pour sites Volterra sur AWS, GCP, Azure, VSphere et KVM/Vagrant.
• Interface réseau unique multi-nœuds CE pour sites Volterra sur AWS, GCP, Azure, VSphere et KVM/Vagrant.
• Interface multi-nœuds multi-réseaux CE sur sites Volterra via AWS, GCP, Azure, VSphere et KVM/Vagrant.

Nous disposons également de manchons de test d'échelle spécialisés qui automatisent le processus de déploiement jusqu'à 400 sites à la fois pour tester les capacités de mise à l'échelle du logiciel Volterra et ont été testés à l'aide de GCP, vSphere et KVM.

Le déploiement automatisé rapide des cas d’utilisation permet aux membres de l’équipe de solutions de se concentrer sur d’autres tâches, améliorant ainsi l’efficacité interne. L'équipe de solutions utilise souvent AC pour déployer des dizaines de sites KVM, GCP et vSphere pour l'enregistrement de démonstrations vidéo, ce qui nous fait gagner du temps dans la création de sites Volterra à utiliser pour créer une infrastructure plus complexe, en s'appuyant sur l'automatisation que nous avons mise en place. Ceci est également utilisé pour les tâches cron quotidiennes qui testent les fonctionnalités de facturation de la plate-forme Volterra en automatisant le déploiement d'AWS, la sécurité des applications Web, la passerelle Kubernetes sécurisée et les cas d'utilisation application de périphérie réseau sur un locataire Volterra spécialisé qui enregistre les informations de facturation.

Plans futurs et feuille de route

Notre utilisation d’AC donne déjà des résultats très positifs et il reste encore de nombreuses fonctionnalités et améliorations à ajouter au projet dans un avenir proche.

L’ajout le plus important au projet est l’ajout constant de nouvelles options SLEEVE pour couvrir des déploiements de cas d’utilisation supplémentaires. Pour chaque nouveau SLEEVE ajouté, nous ajoutons un nouveau travail à nos tests de fumée de régression nocturnes, offrant ainsi plus de couverture pour les projets de déploiement de solutions. La plupart des manchons précédents se concentraient sur les cas d'utilisation d'un seul nœud et d'une seule interface réseau, mais nous avons récemment étendu notre couverture SLEEVE aux clusters de sites Volterra multi-nœuds et aux cas d'utilisation d'interface multi-réseau sur les plateformes AWS, Azure, GCP, VMWare et KVM/Vagrant.

Nous cherchons également à améliorer notre système d’enregistrement des piles. Nous augmenterons le niveau de détail de nos enregistrements AC et ajouterons des fonctionnalités de recherche améliorées avec l’incorporation de magasins de bases de données RDS pour nos enregistrements. L'objectif est que nous puissions fournir des recherches plus rapides dans notre environnement AC et des fonctionnalités de recherche plus sélectives telles que les recherches de pile basées sur l'état de la pile, les créateurs de pile, etc. L’utilisation de ces enregistrements pour construire une interface utilisateur personnalisée afin de visualiser plus efficacement les déploiements créés avec AC est également sur notre feuille de route.