Flux de travail GitOps avec les actions GitHub chez Vonage

Nous avons récemment remanié un pipeline de construction et de déploiement clé pour notre plateforme Vonage Contact Center. Nous avons profité de l'occasion pour faire évoluer ce pipeline vers une conception GitOps conforme à la sécurité. Dans ce billet de blog, j'expliquerai ce que l'on entend par GitOps, et comment notre pipeline a été repensé pour bénéficier de ce concept.

Concepts Gitops : Qu'est-ce que GitOps ?

D'une manière générale, GitOps est une collaboration des meilleures pratiques de DevOps et de sécurité. La principale différence entre DevOps et GitOps est l'ajout de l'IaC (Infrastructure as Code) qui est stocké avec le code du projet dans le SCM (Source Code Management), généralement Git.

GitOps est un cadre plutôt qu'un logiciel ou un outil individuel. À mon avis, c'est l'une de ses forces. Avec GitOps, vous avez la liberté et la flexibilité d'adapter la mise en œuvre pour qu'elle corresponde au mieux à votre organisation et améliore vos processus.

GitOps est composé de trois concepts distincts :

1. Infrastructure as Code (IaC)

Les outils IaC permettent de concevoir et de configurer l'infrastructure une seule fois et de la déployer de manière répétée, avec des fonctions de gestion de l'état qui empêchent les ressources actives de s'écarter de leur configuration initiale. Une fois définies, ces données de configuration peuvent être conservées sous contrôle de source, ce qui permet de maintenir une source unique de vérité pour l'infrastructure (ainsi que les autorisations et les politiques de sécurité associées).

En outre, avec une structure de référentiel bien conçue, les concepts de sécurité du moindre privilège et de la séparation des tâches sont facilement mis en œuvre pour ces données.

2. Demandes de retrait (PR)

Toutes les modifications du code doivent être contrôlées par des PR. Cette protection s'applique au code de l'application ainsi qu'au code de l'IaC décrivant l'infrastructure de soutien.

Les développeurs devraient avoir la permission de fusionner du code via des PR dans le référentiel d'application, mais ils ne devraient pas avoir de permissions directes pour faire des mises à jour dans le pipeline GitOps ou les référentiels d'infrastructure.

3. Intégration continue / Livraison continue (CI/CD)

GitOps automatise les processus CI/CD grâce à l'intégration et à la livraison continues. L'intégration continue est déclenchée par une poussée vers la branche principale. Le déploiement est déclenché manuellement ou automatiquement après la réussite des contrôles de qualité.

Les tests de sécurité peuvent être intégrés dans le cycle de vie du développement logiciel (SDLC) beaucoup plus facilement avec GitOps. En outre, le cycle d'itération étant beaucoup plus rapide, l'adoption de la sécurité s'en trouve facilitée et les frictions réduites. Cela encourage à mettre l'accent sur la prévention plutôt que sur la détection, ce que l'on appelle communément le "glissement vers la gauche".

Comment nous avons mis en place GitOps

Contexte

Notre objectif était de construire un pipeline GitOps CI/CD pour la livraison de composants Micro-FrontEnd dans les environnements hébergés dans le nuage de Vonage Contact Centre. Le pipeline remplace une version antérieure et, en tant que tel, il fallait une conception qui réduise de manière significative les frictions de développement et les temps de déploiement, améliore la sécurité et, par conséquent, le DevEx (Developer Experience).

Recherche et exigences

Comme il s'agissait de notre première exposition pratique à GitOps, nous avons effectué des recherches initiales sur le cadre de GitOps et avons réalisé un pic pour tester quelques approches différentes. Compte tenu de la nature de nos besoins et des contraintes inévitables au travail, nous avons choisi d'adopter le modèle événementiel de GitHub Actions avec une combinaison d'outils CLI natifs, pour nous permettre de contrôler les mises à jour dans l'infrastructure hébergée dans le nuage (dans ce cas, des CDN, des fonctions de code sans serveur et une base de données NoSQL). Dans notre architecture GitOps, nous n'avons besoin que d'un seul événement. Le déploiement de l'application est déclenché par un événement GitHub repository_dispatch provenant du référentiel Applications et ciblé sur le référentiel GitOps, où il déclenche automatiquement le déploiement.

Une fois que nous avons été convaincus que GitOps était une solution viable, nous avons affiné nos exigences :

• Améliorer la posture de sécurité en adhérant aux principes du moindre privilège et de la séparation des tâches.

• Fournir aux développeurs un retour d'information sur le déploiement en temps utile

• Réduire les frictions liées au déploiement et, par conséquent, améliorer les délais de déploiement et le DevEx

• Mesures de soutien au déploiement

• Utiliser des pipelines GitOps CI/CD faciles à maintenir

• Évolutivité horizontale (intégration transparente de nouvelles applications dans le pipeline GitOps).

• Tirer parti de l'outillage interne et l'améliorer lorsque cela s'avère judicieux

Architecture GitOps

Référentiels d'infrastructure

Terraform a été notre outil de choix pour le déploiement et la gestion de l'infrastructure en nuage sur laquelle les composants de l'EMF seraient hébergés. Cette approche IaC est utile pour contrôler une infrastructure qui ne change pas souvent.

Chacune des ressources nécessaires pour héberger les composants de l'EMF a été capturée dans des modules Terraform, avec les objets de sécurité et de permissions nécessaires. Un pipeline CI/CD Terraform préexistant est utilisé pour maintenir ces composants.

Référentiels d'applications

Les développeurs (et le référentiel d'applications de l'EMF lui-même) ont des permissions étroites sur les outils et les systèmes de développement. Par conséquent, un flux de travail CI défini à l'aide des actions Github prend en charge ces responsabilités, en fournissant des fonctionnalités classiques de construction et de qualité dans un processus automatisé et modélisé. Les artefacts de construction produits par ce processus sont poussés vers un référentiel de paquets (jFrog Artifactory).

Application CI Workflow

Un workflow CD dans le même dépôt offre au développeur la possibilité de déployer l'application. Concrètement, il s'agit d'un événement GitHub repository_dispatch envoyé au dépôt GitOps cible, suivi d'une étape d'attente.

Exemple d'action GitHub déclenchant le déploiement de l'application :

- name: Deploy MFE ${{ env.MFE_NAME }} version ${{ env.MFE_VERSION }} to ${{ env.MFE_ENVIRONMENT }}
  uses: peter-evans/repository-dispatch@11ba7d3f32dc7cc919d1c43f1fec1c05260c26b5 # v2.0.0
  with:
    token: ${{ secrets.GITOPS_GITHUB_TOKEN }}
    repository: ${{ env.GITOPS_REPOSITORY }}
    event-type: deploy-mfe-trigger
    client-payload: '{
                        "type": "deploy-mfe-trigger",
                        "timestamp": "${{ env.DATEANDTIME }}",
                        "user": "${{ github.actor }}",
                        "mfe": "${{ env.MFE_NAME }}",
                        "version": "${{ env.MFE_VERSION }}",
                        "environment": "${{ env.ENVIRONMENT }}",
                        "cache_invalidation_keys": "${{ env.CACHE_INVALIDATION_KEYS }}",
                        "repository": "${{ github.repository }}",
                        "ref": "${{ github.ref }}",
                        "sha": "${{ github.sha }}"
                    }'

Application CD GitOps Workflow

Dépôt GitOps IaC

Ce dépôt constitue la base de notre cadre GitOps. Il dispose des permissions nécessaires pour se déployer chez un fournisseur de cloud donné. Notez qu'il est séparé des dépôts d'applications de l'EMF, adhérant ainsi aux principes de sécurité du moindre privilège et de la séparation des tâches (ainsi que du déplacement de la sécurité vers la gauche).

Les événements de déploiement sont reçus du flux de travail du CD de l'application et traités automatiquement. Le processus GitOps comporte essentiellement trois étapes distinctes :

1. Processus GitHub repository_dispatch événements

   1. accepter/rejeter

   2. mettre à jour la configuration de l'IaC sur la base des métadonnées de l'événement

   3. augmenter les RP

2. Fusionner automatiquement les PR

   1. effectuer des contrôles de qualité

   2. fusionner les RP si les contrôles de qualité sont réussis

3. Déployer l'application

   1. copier l'artefact de construction dans le stockage en nuage

   2. Mise à jour de la table de la base de données

   3. invalider le cache CDN

GitOps Operations Deployment Workflow

Outil de déploiement de l'infrastructure en nuage

Nous avons créé un outil CLI qui s'interface avec notre fournisseur de cloud et permet des déploiements d'applications en toute transparence.

L'abstraction de la logique de déploiement dans ce nouveau projet CLI nous a permis de gérer les détails fins de la logique de déploiement tout en garantissant que les nouvelles fonctionnalités sont testées avant d'être lancées dans le pipeline de production.

Cadre de projet Micro-FrontEnd CLI

Il s'agit d'un outil interne qui fournit un cadre CI/CD pour le développement en plusieurs langues. Nous utilisons cet outil pour raccourcir la partie "cruft" de la création et de la mise à jour de nos projets logiciels - il fournit des éléments tels que le code de composant squelette, des options de configuration communes et des modèles de pipeline CI/CD. Il prend en charge une grande variété de langages d'exécution et de types de composants.

Nous avons décidé très tôt d'améliorer l'outil pour supporter le nouveau cadre GitOps pour les MFE, pour améliorer l'expérience des développeurs lors de la création de nouveaux MFE, et aussi pour aider à la migration des composants MFE existants vers le nouveau pipeline CI/CD. Les changements que nous avons apportés à cet outil signifient qu'il créera automatiquement les flux de travail CI/CD GitOps requis pour les projets Micro-FrontEnd.

Pour adopter le pipeline GitOps dans un projet nouveau ou déjà existant, vous devez rendre le projet avec l'outil CLI.

Où irions-nous ensuite ?

Ce projet nous a donné une grande chance de nous familiariser avec les concepts de GitOps et nous a permis d'avoir un aperçu des domaines dans lesquels nous pourrions encore nous améliorer. Voici quelques-unes des choses que nous pourrions entreprendre par la suite :

• Travailler en étroite collaboration avec les équipes de sécurité de Vonage pour définir les exigences de conformité en matière de sécurité en tant que configuration (YAML, Terraform, ...). Lorsque cela fait partie du SDLC (et des cycles continus de révision/raffinement), vous êtes certain de respecter la conformité et de pouvoir en fournir la preuve.

• Envisager d'utiliser GitHub Actions runners self-hosted, pour nous donner plus de contrôle sur la mise à l'échelle, la configuration et les coûts. Cette étape doit être considérée avec attention car elle introduit un compromis entre la sécurité des runners, le coût et la maintenabilité.

• Créer/adopter une application GitOps GitHub similaire aux opérations disponibles pour K8s.

Réflexions finales

J'espère que ce blog a été instructif et qu'il a démontré certains des avantages de l'adoption de GitOps dans votre pipeline de développement.

N'oubliez pas de nous suivre sur Twitter et rejoignez notre canal Slack pour plus d'informations.

Merci de votre lecture !