D'OpenTofu à Argo CD, avec GitLab comme plan de contrôle AWS

La configuration d'environnements cloud est une opération complexe, qui implique de prendre en compte la mise en réseau, les abonnements, les services et l'ensemble des composants constituant l'infrastructure sous-jacente. Une configuration manuelle est source d'erreurs, manque de cohérence et s'avère difficile à reproduire.

Ce tutoriel explique comment mettre en place un environnement cloud entièrement automatisé en utilisant GitLab comme plateforme opérationnelle centrale. L'intégralité de l'infrastructure cloud est définie sous forme de code (hébergé sur GitLab) et déployée sur AWS avec OpenTofu via des pipelines GitLab CI/CD. Ces pipelines gèrent également le build et le déploiement d'une application web réelle, en appliquant les pratiques GitOps avec Argo CD.

Pourquoi l'Infrastructure as Code et GitOps ?

Avant tout, il est important de comprendre pourquoi l'Infrastructure as Code (IaC) et GitOps sont essentiels, et comment GitLab réunit ces pratiques au sein d'une seule et même plateforme.

L'IaC garantit que les environnements sont :

• Reproductibles : la même configuration peut être déployée n'importe où.
• Versionnés : chaque modification est suivie dans un système de contrôle de version (VCS), Git étant le choix de référence.
• Automatisés : aucune intervention humaine n'est nécessaire.

GitOps étend ces principes au cycle de vie des applications. Plutôt que d'appliquer manuellement des modifications aux clusters Kubernetes (ou à d'autres infrastructures), l'état souhaité des applications est défini dans Git. Un opérateur GitOps comme Argo CD veille en permanence à ce que le cluster reflète le contenu du dépôt. Cette approche assure :

• Une cohérence entre les environnements.
• Une reprise accélérée grâce à des retours à la version précédente aussi simples que l'annulation d'un commit.
• Une meilleure collaboration, car les équipes peuvent vérifier et approuver les modifications via des merge requests.
• Une sécurité renforcée, les déploiements étant effectués sans que les équipes de développement aient besoin d'un accès direct au cluster.

GitLab réunit toutes les capacités nécessaires à cette approche :

• Gestion du code source : suivez l'infrastructure et le code applicatif au même endroit.
• Pipelines CI/CD : automatisez le provisionnement avec OpenTofu et les déploiements avec les manifestes Kubernetes.
• États Terraform : stockez et gérez les fichiers d'état de l'infrastructure en toute sécurité.
• Registre de conteneurs : compilez, stockez et gérez les images de conteneurs aux côtés du code et des pipelines.

Avec GitLab, toutes les étapes, du provisionnement de l'infrastructure cloud à la livraison des applications, s'effectuent sur une seule et même plateforme.

Pour suivre ce tutoriel, vous aurez besoin des éléments suivants :

• Des connaissances de base sur les pipelines GitLab CI/CD et Git
• Des connaissances de base sur l'IaC (Terraform ou OpenTofu) et GitOps
• Un compte AWS
• Un cluster Kubernetes (EKS est provisionné dans le tutoriel)
• Un Dockerfile pour l'application web de démonstration

Poursuivez votre lecture pour découvrir comment reproduire cet exemple dans votre propre environnement GitLab. Le code source de cet exemple est disponible dans le groupe de démos publiques SATEC.

Provisionner un environnement AWS complet (réseau, EKS) avec OpenTofu

La première étape consiste à provisionner l'infrastructure cloud avec OpenTofu (le fork open source de Terraform). Nous pouvons définir de manière déclarative les composants réseau et créer un cluster Amazon EKS.

Pour assurer la reproductibilité et la sécurité de ce processus, nous nous appuyons sur les variables CI/CD de GitLab plutôt que sur des valeurs codées en dur. Ces variables permettent de configurer l'environnement AWS de façon dynamique d'un pipeline à l'autre.

Les variables d'environnement suivantes sont requises et doivent être déclarées sous Paramètres > CI/CD > Variables dans le groupe parent (afin d'être héritées par tous les projets) :

• TF_VAR_region : région AWS où l'infrastructure sera créée (ex. : eu-west-1)
• TF_VAR_instance_type : type d'instance EC2 pour les nœuds de travail (ex. : t3.medium)
• TF_VAR_instance_count : nombre de nœuds de travail dans le cluster
• TF_VAR_cluster_name : nom du cluster EKS à provisionner
• AWS_ACCESS_KEY_ID : clé d'accès AWS pour l'authentification
• AWS_SECRET_ACCESS_KEY : clé secrète AWS pour l'authentification

Toutes les variables sont définies comme protégées dans GitLab, et les plus sensibles, comme la clé d'accès secrète AWS, sont également masquées, ce qui garantit qu'elles ne sont exposées que dans des contextes CI/CD sécurisés. La sécurité peut être renforcée davantage en suivant ce tutoriel sur les variables CI/CD. La séparation du code et de la configuration assure la flexibilité du pipeline et son indépendance face aux environnements.

Une fois configuré, le pipeline OpenTofu peut être exécuté automatiquement pour :

• Provisionner les ressources réseau (VPC, sous-réseaux, passerelles, tables de routage)
• Provisionner le plan de contrôle EKS et les groupes de nœuds de travail
• Déclencher le pipeline de déploiement d'Argo CD et de CertManager dans le nouveau cluster

Le schéma ci-dessus illustre le fonctionnement du processus de provisionnement de l'infrastructure.

1. Un pipeline GitLab est déclenché depuis le dépôt d'infrastructure, qui contient les fichiers de configuration Terraform/OpenTofu.
2. GitLab CI/CD exécute les commandes OpenTofu, en utilisant le backend d'état Terraform intégré pour gérer le fichier d'état de manière sécurisée dans GitLab.
3. OpenTofu se connecte à AWS via des fournisseurs configurés pour créer toutes les ressources nécessaires : le VPC, les sous-réseaux, les passerelles, les équilibreurs de charge et le cluster Amazon EKS réparti sur plusieurs zones de disponibilité.

À l'issue de cette étape, l'environnement AWS et le cluster Kubernetes sont entièrement provisionnés et prêts à fonctionner.

La dernière étape de ce processus (post-déploiement) consiste à déclencher un second pipeline GitLab (hébergé dans un dépôt dédié), chargé de déployer automatiquement Argo CD et CertManager dans le nouveau cluster EKS à l'aide du fournisseur Helm.

Configurer automatiquement les outils Kubernetes (Argo CD, CertManager)

Une fois l'infrastructure AWS et le cluster EKS provisionnés avec succès, l'étape suivante consiste à configurer les outils Kubernetes nécessaires au fonctionnement de l'environnement : Argo CD, CertManager et Ingress NGINX Controller.

Ce processus est entièrement automatisé via un second pipeline GitLab hébergé dans un dépôt distinct.

L'exécution de ce second pipeline est déclenchée automatiquement depuis le pipeline d'infrastructure, via un job de déclenchement, dès que l'étape de provisionnement OpenTofu s'est achevée avec succès.

Concrètement, le déploiement de ces composants essentiels s'effectue de manière transparente dans le cadre du même workflow de bout en bout, sans aucune étape manuelle. Le déploiement lui-même est géré par OpenTofu via le fournisseur Helm, ce qui permet de gérer les charts Helm de façon déclarative sous forme de code via GitLab.

Voici un workflow simplifié :

1. Le premier pipeline fournit le cluster EKS et déclenche le second via un job de déclenchement GitLab.
2. Le second pipeline utilise OpenTofu avec le fournisseur Helm pour :
   • Télécharger le fichier kubeconfig depuis le cluster EKS.
   • Installer Argo CD (pour la gestion GitOps).
   • Installer CertManager (pour la gestion automatisée des certificats TLS).
   • Installer Ingress NGINX Controller (pour le routage du trafic entrant). Remarque : Ingress NGINX Controller est en cours de dépréciation dans l'écosystème Kubernetes ; pour les nouveaux déploiements, il est recommandé d'envisager d'autres options telles que Traefik ou une approche basée sur une passerelle API.
3. Chaque release Helm est définie dans la configuration OpenTofu, ce qui permet les mises à niveau ou les retours à la version précédente via des modifications standard du code d'infrastructure.
4. Enfin, un troisième pipeline est déclenché pour déployer l'application web de démonstration. Ce pipeline applique les manifestes d'application Argo CD qui définissent l'application web et ses ressources associées.

Déployer une application web de démonstration selon les principes GitOps avec Argo CD

Une fois tous les composants Kubernetes essentiels installés (Argo CD, CertManager et Ingress NGINX Controller), la dernière étape du pipeline d'automatisation commence. Cette étape est exécutée automatiquement dès la fin du processus d'installation du chart Helm.

Un troisième pipeline GitLab est déclenché, chargé de déployer une application web de démonstration dans le cluster EKS nouvellement créé via Argo CD.

Le schéma ci-dessous illustre le processus global :

Dans cette étape, GitLab utilise le fichier kubeconfig généré par OpenTofu pour se connecter au cluster et appliquer les manifestes d'application Argo CD qui définissent l'état souhaité de l'application web.

Le pipeline :

• Télécharge et met à jour le fichier kubeconfig pour se connecter au cluster EKS.
• Met à jour les identifiants et les informations du dépôt de façon dynamique via des variables CI/CD.
• Crée l'espace de nommage Kubernetes pour l'application (aws-summit-app).
• Applique les manifestes Argo CD (repository.yaml, application.yaml, cluster-issuer.yaml).
• Crée un secret pour le registre de conteneurs afin de permettre à l'application de récupérer les images de manière sécurisée depuis GitLab à l'aide d'un jeton d'accès.

Toutes ces actions sont effectuées automatiquement via GitLab CI/CD, sans aucune intervention manuelle.

Une fois les manifestes appliqués, le contrôleur Argo CD les détecte et synchronise l'état de l'application avec le dépôt, déployant ainsi l'application web de démonstration dans le cluster EKS.

Le résultat est un environnement Kubernetes entièrement opérationnel, dans lequel :

• L'infrastructure est provisionnée avec OpenTofu.
• Les outils du cluster sont installés de façon déclarative avec Helm.
• Les applications sont déployées et gérées via GitOps avec Argo CD.

Cette approche garantit une automatisation, une traçabilité et une reproductibilité de bout en bout, le tout géré par GitLab.

Compiler et empaqueter une application web de démonstration avec GitLab CI/CD

Avant d'être déployée via Argo CD, l'application doit d'abord être compilée, conteneurisée et publiée dans le registre de conteneurs de GitLab.

Ce processus est géré par un pipeline CI/CD dédié et suit une structure de dépôt GitOps, dans laquelle le code source et les manifestes Kubernetes sont stockés dans des dépôts distincts.

Dans cette configuration, le groupe GitLab est organisé en deux sections principales :

• Apps/ contient les dépôts de code source des applications.
  • Exemple : aws-summit-app/web héberge le code source de l'application web de démonstration.
• Deployments/ contient les dépôts avec les manifestes Kubernetes pour chaque application.
  • Exemple : aws-summit-app/web, sous Deployments/, définit les manifestes Kubernetes permettant de déployer la page web (deployment.yaml, ingress.yaml, service.yaml, etc.).

Cette séparation assure un workflow GitOps clair, car le code applicatif et les configurations de déploiement sont indépendants tout en restant synchronisés grâce à l'automatisation.

Le pipeline CI/CD défini dans le dépôt de l'application automatise les tâches suivantes :

• Build et empaquetage : le pipeline compile le code source et construit l'image Docker à partir du Dockerfile fourni.
• Publication dans le registre de conteneurs de GitLab : l'image est automatiquement taguée et envoyée vers le registre de conteneurs de GitLab intégré.
• Mise à jour des manifestes de déploiement : une fois l'image publiée, le pipeline exécute un job qui met à jour la référence de l'image dans le dépôt de déploiement correspondant (sous Deployments/aws-summit-app/web).

Ces opérations sont effectuées automatiquement par un commit avec le nouveau tag d'image ou la création d'une merge request.

Une fois le commit ou la merge request créés, Argo CD détecte automatiquement la modification dans le dépôt de déploiement et synchronise les manifestes mis à jour avec le cluster Kubernetes afin de garantir le déploiement de la nouvelle version de l'application sans aucune intervention manuelle.

Récapitulatif

Ce tutoriel a montré comment mettre en place un environnement cloud entièrement automatisé avec GitLab comme hub central pour atteindre les objectifs fixés : une infrastructure reproductible, versionnée et automatisée. En combinant OpenTofu pour le provisionnement de l'infrastructure, GitLab CI/CD pour l'orchestration des pipelines et Argo CD pour la livraison d'applications basée sur GitOps, les équipes peuvent gérer l'intégralité du cycle de vie, des ressources cloud aux applications en production, via une plateforme unique.

En tant que partenaire GitLab disposant d'une expertise approfondie en matière d'infrastructure cloud et en pratiques DevSecOps, Clober (groupe SATEC) peut aider les organisations à mettre en œuvre des environnements automatisés similaires, adaptés à leurs besoins spécifiques.

Remarque : cet article de blog est basé sur une démonstration en direct présentée à l'origine lors de l'AWS Summit Madrid 2025 par l'équipe DevSecOps de Clober (groupe SATEC).

Ressources

• Composants GitLab CI/CD
• Registre de conteneurs de GitLab
• Gestion des états Terraform avec GitLab