Lors d’un précédent article, nous avons déjà évoqué le « GitOps » et ses avantages face à une gestion d’infrastructure traditionnelle . Nous avons expliqué comment Git est utilisé pour stocker et versionner ce code d’infrastructure en construisant une chaîne de déploiement pour aligner automatiquement des environnements avec du code d’infrastructure. Dans cet article, nous allons aborder la définition du GitOps, ses avantages et quelques idées de solution pour vos projets GitOps.
Qu’est-ce que le GitOps
Le GitOps est une implémentation particulière du déploiement automatisé d’application Cloud Native. Il consiste à réaliser la construction de l’infrastructure en utilisant les mêmes outils utilisés lors du développement d’applications comme Git ou encore les outils de CI/CD (ex. Jenkins, GitLab CI).
Le concept est d’avoir dans un repository Git la description déclarative de l’infrastructure souhaitée en production et un processus automatisé, qui se charge d’aligner en continu l’état souhaité du système avec l’environnement de production. Ainsi pour déployer une nouvelle version d’application ou la mettre à jour, le repository Git doit être mis à jour et le processus automatisé se charge du reste.
Les avantages du GitOps
Quelle solution adoptée pour vos projets GitOps ?
Du côté « infrastructure as code », de multiples outils sont disponibles si bien qu’il n’est pas aisé de s’y retrouver.
● Cloud Templates (AWS CloudFormation, Azure RM, Google Cloud Deployment Manager),
● Harshicorp Terraform,
● AWS CDK, Troposphere, Palumi
● Kubernetes YAML et DSLs, Knative,
● Chef, Puppet, Ansible, Salt, etc.
Chez Astrakhan, nous apprécions particulièrement Terraform, qui propose plus de 500 providers et ainsi une compatibilité avec de multiples Cloud (en autres Azure, AWS, Google Cloud, Alibaba Cloud, Oracle Cloud) et de nombreux services (VMWare, Datadog, GitLab, etc.).
La communauté est très active et maintient en grand nombre des modules pour simplifier le code de l’infrastructure et sa maintenance en masquant la complexité. Un autre de ses avantages est de montrer la liste des modifications à appliquer pour approbation avant de les appliquer. Si cela peut sembler s’inscrire en opposition par rapport au GitOps et le processus d’alignement automatique entre l’état souhaité du système et l’environnement cible, il faut comprendre que cette étape apporte davantage de contrôle avec la possibilité de mettre en place des règles dictant si une approbation est nécessaire ou peut être appliquées automatiquement.
A l’instar d’un SonarQube pour les développements applicatifs, de nouveau outils émergent également pour aider à améliorer la qualité du code de l’infrastructure tels que « Open Policy Agent » (framework pour écrire vos propres politiques de contrôle du code), ou encore checkov (intègre nativement plus de 300 contrôles) et tf-parliament (intègre nativement des contrôles sur les AWS IAM policies).
Concernant l’automatisation du déploiement (la CD), un outil se démarque particulièrement pour implémenter le GitOps et s’inscrit parfaitement dans la philosophie d’utiliser les mêmes outils pour le développement et les opérations. Nous parlons ici de GitLab, qui propose en effet nativement toutes les fonctionnalités nécessaires pour déployer avec Terraform :
● Terraform s’appuie sur un backend pour stocker l’état des ressources qu’il a lui-même provisionnées et leur identifiant unique. Il s’agit du Terraform State. Terraform Cloud propose par ailleurs un service vous permettant de stocker vos Terraform State moyennant la création d’un compte. Il est également possible d’utiliser des services comme AWS S3 ou Google Cloud Storage. La gestion du Terraform State est aussi proposée nativement par GitLab disponible directement sans nécessiter aucune actions ou ressources préalables.
● Ensuite il y a GitLab CI qu’on ne présente plus. Pionnier en termes de « Pipeline as Code », il a été suivi par Bitbucket Pipelines, Azure DevOps ou encore GitHub Action. GitLab CI couvre désormais les besoins de CD en proposant notamment une intégration avec Terraform pour faire remonter les rapports Terraform dans vos « merge requests ».
● Moins connu, la facilité avec laquelle il est possible de profiter d’une « deploy board » en ajoutant simplement le mot clé « environment » dans le code de vos pipeline au niveau du job chargé du déploiement (commande terraform apply). La « deploy board » vous donne accès à l’historique des déploiements pour chaque environnement et composant. Auteur, date, job et pipeline, commit à l’origine de chaque déploiement, tout s’y trouve. En bonus, il est même possible de réexécuter un déploiement passé pour revenir à une version antérieure.
● Pour conserver son environnement aligné avec la description de l’état souhaité du système dans Git, un « Scheduled Pipeline » peut être mis en place pour lancer un pipeline à intervalle régulier, qui se charge de garder l’environnement cible synchronisé.
● Les notifications sont extrêmement paramétrables et vous permettent d’être alerté en cas d’incident de déploiement par mail et/ou autres services.
● GitLab propose une intégration à un second produit de Harshicorp. Il s’agit d’une intégration avec Vault afin d’externaliser et de sécuriser l’accès aux secrets en définissant les conditions permettant de lire les secrets basés sur des informations envoyées par GitLab sous la forme d’un token JWT et vérifiées par des règles à implémenter côté Vault.
● Vos projets d’infrastructure sont peut-être complexes, décomposés en de multiples couches ou encore transverses à de nombreux autres projets et vous avez alors besoin d’autant de pipeline ? La fonctionnalité « Dynamic Child Pipeline » permet dans un premier job de générer le code GitLab CI à exécuter pour chacune de vos couches ou projets. Une excellente idée est de détourner la « Deploy Board » déjà évoquée pour afficher à la fois les déploiement mais aussi les modifications en attente d’approbation.
Source :
– https://www.gitops.tech/
– https://www.terraform.io/
– https://www.openpolicyagent.org/docs/latest/terraform/
– https://github.com/bridgecrewio/checkov
– https://github.com/rdkls/tf-parliament
– https://gitlab.com/gitops-demo/readme
– https://docs.gitlab.com/ee/ci/environments/#defining-environments
– https://docs.gitlab.com/ee/user/infrastructure/terraform_state.html#get-started-using-gitlab-ci
– https://docs.gitlab.com/ee/ci/yaml/
– https://docs.gitlab.com/ee/user/project/deploy_boards.html
– https://docs.gitlab.com/ee/ci/yaml/#environment
– https://docs.gitlab.com/ee/ci/pipelines/schedules.html
– https://docs.gitlab.com/ee/user/profile/notifications.html
– https://docs.gitlab.com/ee/user/project/integrations/microsoft_teams.html
– https://docs.gitlab.com/ee/ci/secrets/
– https://docs.gitlab.com/ee/ci/parent_child_pipelines.html
