Le DevOps en pratique avec GitLab - Construire un pipeline CI/CD de bout en bout

Introduction

Dans ce chapitre, nous allons mettre le DevOps en pratique en construisant pas à pas un pipeline GitLab CI/CD pour un projet Terraform qui nous permettra de déployer une machine virtuelle Ubuntu dans Azure. Une fois la VM créée, nous allons automatiser son installation en tant que GitLab Runner, en déployant l’agent et en l’enregistrant automatiquement auprès de la plateforme. Ensuite, nous validerons le fonctionnement de ce runner en exécutant des tests pour confirmer qu’il est bien intégré à GitLab.

Nous avons choisi Microsoft Azure comme plateforme de déploiement pour ce chapitre, mais les principes que nous allons appliquer restent les mêmes, quelle que soit l’infrastructure cloud. Ce qui change principalement, ce sont les noms des composants et la configuration spécifique à chaque provider. Ainsi, ce projet peut facilement être adapté pour AWS, Google Cloud ou toute autre plateforme cloud en ajustant les ressources Terraform en conséquence.

Bien que la documentation de GitLab soit très complète, elle se concentre principalement sur des fonctionnalités individuelles et elle ne propose pas d’exemple de bout en bout couvrant l’ensemble du processus d’automatisation. C’est pourquoi nous allons construire ce pipeline pas à pas, en ajoutant progressivement des fonctionnalités...

Prérequis techniques

Pour suivre ce chapitre, vous aurez besoin d’un compte Microsoft Azure. Si vous n’en avez pas encore, vous pouvez en créer un gratuitement sur le site officiel d’Azure. Microsoft propose une offre de bienvenue avec des crédits permettant d’explorer ses services sans frais pendant une période limitée.

Si vous possédez déjà un compte Azure, sachez que notre projet entraînera des coûts minimes, car nous allons détruire l’infrastructure une fois les tests terminés. Toutefois, il est toujours recommandé de vérifier l’estimation des coûts avant d’exécuter Terraform sur un environnement réel.

Vous pouvez créer votre compte à l’adresse suivante : https://azure.microsoft.com/fr-fr/

Ce chapitre contient beaucoup d’extraits de code ; nous vous invitons à utiliser le dépôt GitHub que nous avons indiqué dans notre avant-propos pour récupérer le répertoire de ce projet.

Présentation de Terraform

Terraform a été lancé en 2014 par HashiCorp, une entreprise américaine spécialisée dans les outils d’automatisation cloud. Cette compagnie est également à l’origine d’autres solutions largement utilisées comme Vault (gestion des secrets), Vagrant (environnements de développement virtualisés) et Packer (automatisation de la création d’images de machines).

Terraform est un outil IaC qui se présente sous la forme d’une interface en ligne de commande (CLI) permettant de définir, déployer et gérer notamment des infrastructures cloud de manière déclarative.

L’approche déclarative se distingue des autres paradigmes de programmation, comme l’impératif et le fonctionnel, par sa manière de définir une configuration. Plutôt que de détailler chaque étape du processus (impératif) ou de manipuler des entrées pour générer des sorties sans modifier l’état global du système (fonctionnel), elle permet de décrire directement le résultat souhaité, en laissant l’outil se charger d’exécuter les modifications nécessaires.

Il fonctionne à l’aide de fichiers de configuration écrits en HCL (HashiCorp Configuration Language) qui décrivent l’état désiré de l’infrastructure (desired state). Lorsqu’un utilisateur applique ces configurations, Terraform compare l’état actuel des composants à déployer ou à mettre à jour avec l’état désiré. Il exécute ensuite les ajouts, modifications ou suppressions nécessaires pour s’assurer que l’infrastructure réelle est conforme à la configuration définie.

1. Les notions de state et de provider

Le state est un élément central de l’outil, car il conserve une représentation de l’infrastructure actuelle et permet à Terraform de suivre les changements d’état des composants déployés. Ce fichier peut être stocké localement ou dans un backend distant pour assurer la cohérence des déploiements et appliquer uniquement les modifications nécessaires....

Préparation de l’environnement

Avant de commencer à écrire le code, nous supposons que vous avez déjà créé un projet dans GitLab et que vous l’avez cloné en local sur votre poste de travail. Si ce n’est pas encore fait, nous vous recommandons de suivre les étapes décrites dans les chapitres précédents pour initialiser un dépôt Git, configurer votre environnement et cloner le projet.

Dans les sections qui suivent, nous allons préparer notre dépôt local et créer progressivement les différents fichiers de configuration nécessaires pour notre déploiement en Terraform.

1. Structurer le dépôt de notre projet

Dans un premier temps, nous allons structurer notre projet en local dans un répertoire dédié nommé terraform, situé à la racine du dépôt. Cette organisation permet de séparer clairement la configuration de l’infrastructure du reste du code et elle facilite la gestion des fichiers Terraform.

Nous vous invitons à travailler à partir d’un dépôt Git sur votre poste de travail, car nous allons apprendre à configurer le backend pour stocker l’état Terraform en local.

Voici l’arborescence de notre projet :

/mon-projet 
│── .gitignore 
│──...

Créer les fichiers de configuration Terraform

Pour que Terraform puisse déployer et gérer notre infrastructure, nous devons rédiger quelques fichiers de configuration. Chacun d’entre eux joue un rôle spécifique : définir le fournisseur et le backend, déclarer les variables, spécifier les ressources à provisionner, assigner des valeurs aux paramètres de configuration et définir les sorties à afficher après l’exécution.

Dans les prochaines sections, nous allons suivre un ordre logique afin de structurer notre projet de manière claire et modulaire :

│── terraform/     # Répertoire contenant les fichiers Terraform 
│   ├── .env       # Variables d'environnement (non versionné) 
│   ├── main.tf      # Configuration principale de Terraform 
│   ├── outputs.tf   # Définition des outputs Terraform 
│   ├── provider.tf         # Configuration du provider Azure 
│   ├── terraform.tfvars    # Variables personnalisées  
│   ├── variables.tf        # Déclaration des variables

Nous commencerons par présenter brièvement le fonctionnement des fichiers Terraform et le langage HCL. Ensuite, nous allons déclarer le provider Terraform et configurer le backend de stockage dans le fichier provider.tf, car ce sont ces composants qui permettent à Terraform de se connecter à la plateforme cloud et de gérer l’état de l’infrastructure. Lorsque cette partie sera complétée, nous définirons les variables et leurs valeurs dans le fichier terraform.tfvars, afin de rendre notre configuration plus flexible et réutilisable.

Une fois ces bases en place, nous détaillerons les ressources principales à créer dans le fichier main.tf, en nous appuyant sur les variables définies précédemment pour éviter...

Autres fichiers nécessaires au projet

Pour assurer une bonne organisation de notre projet Terraform et éviter d’exposer des identifiants d’accès ou d’authentification, il est préférable de créer les deux fichiers suivants : .gitignore et .env.

Comme nous l’avons déjà mentionné dans le chapitre Fondamentaux de Git pour GitLab, .gitignore permet d’exclure certains fichiers contenant des informations sensibles ou temporaires du contrôle de version, comme les states Terraform (.tfstate), les fichiers de verrouillage et les variables d’environnement. Quant au fichier .env, il sert à stocker localement certaines variables nécessaires à l’exécution de Terraform sans les exposer dans le dépôt Git.

Nous allons maintenant créer et configurer ces fichiers pour structurer efficacement notre projet.

1. Créer un fichier .gitignore

Pour créer votre fichier .gitignore qui sera placé à la racine du projet, vous pouvez simplement copier le modèle proposé pour les projets Terraform, qui est disponible dans le dépôt GitHub suivant : https://github.com/github/gitignore/blob/main/Terraform.gitignore

Nous allons seulement y ajouter .env, qui n’était pas présent dans ce modèle, afin d’ignorer les fichiers contenant des variables d’environnement...

Création d’un Service Principal et d’un Secret

Avant de pouvoir exécuter Terraform dans un pipeline CI/CD, nous devons créer un Service Principal (SP) et un secret dans Azure pour nous authentifier et gérer les ressources cloud de manière sécurisée.

Nous allons montrer comment le faire en mode graphique, mais vous pouvez également le faire en Terraform ou avec Azure CLI si vous souhaitez automatiser le processus de bout en bout.

1. Créer un Service Principal et un Secret

Un Service Principal doit être créé dans Microsoft Entra ID (anciennement Azure Active Directory, AAD). Cette inscription génère une identité unique, permettant à des applications ou des outils comme Terraform de s’authentifier et d’interagir avec les ressources Azure sans utiliser de compte utilisateur personnel.

Connectez-vous au portail Azure et recherchez Inscriptions d’application (App registration) dans la barre de recherche des services et appuyez sur le bouton Nouvelle inscription.

Nommez votre application (SP), laissez les options par défaut et appuyez sur S’inscrire.

Sur la page d’accueil de votre nouveau SP, notez les informations suivantes :

ID d’application (client)/Application (client) ID
ID de l’annuaire (locataire)/Directory (tenant) ID

Sous le menu Gérer, sélectionnez Certificats...

Ajout de variables d’environnement dans GitLab

Pour sécuriser notre déploiement et simplifier la gestion des informations sensibles, nous allons définir des variables d’environnement dans GitLab. Comme nous l’avons déjà mentionné, ces variables permettent de stocker des valeurs critiques, comme les identifiants d’authentification Azure ou les paramètres de configuration Terraform, sans les révéler directement dans le code.

1. Créer les variables d’environnement ARM

Pour permettre à Terraform de s’authentifier auprès d’Azure et d’exécuter les commandes nécessaires à la création des ressources, nous allons créer des variables d’environnement dans GitLab. Comme nous avons déjà montré comment le faire dans le chapitre Analyser et tester son code source, nous allons rappeler brièvement la procédure.

Dans les Paramètres du projet, appuyez sur CI/CD et ouvrez la section Variables CI/CD dans la vue centrale. Cliquez ensuite sur le bouton Ajouter une variable.

Pour les variables que nous devons créer, nous allons choisir le type de variable par défaut et nous voulons activer l’option de visibilité Masquée et le flag Développer la référence de la variable :

Masquée : empêche l’affichage des valeurs dans les logs des runners pour éviter l’exposition accidentelle d’informations sensibles ;
Développer la référence de la variable : permet aux variables d’être utilisées dans d’autres variables GitLab, ce qui donne une plus grande flexibilité au fichier de configuration du pipeline.

Pour le secret, il est préférable de cocher l’option Masquée et cachée pour empêcher de copier la valeur à partir de GitLab.

Vous pouvez maintenant récupérer les chaînes de caractères notées précédemment pour le SP, le secret, le tenant et l’identifiant de la souscription pour créer les variables d’environnement suivantes :

Nom de la variable (clé)	Description (valeur)
ARM_CLIENT_ID	ID de l’application (Service Principal)
ARM_CLIENT_SECRET	Secret du Service Principal...

Création du fichier de configuration du pipeline

Maintenant que nous avons défini notre infrastructure avec Terraform et nos variables, il est temps d’automatiser notre déploiement avec les pipelines CI/CD.

Dans cette section, nous allons créer le fichier .gitlab-ci.yml qui va décrire notamment les variables, les stages et les jobs qui vont permettre de valider, planifier et déployer notre infrastructure sur Microsoft Azure.

Nous allons expliquer pas à pas la structure de notre fichier de configuration et à mesure que nous avancerons, nous pourrons ajouter des jobs supplémentaires et utiliser des fonctionnalités plus avancées.

1. Créer le fichier .gitlab-ci.yml

Pour automatiser le déploiement dans un pipeline, créez un fichier .gitlab-ci.yml localement à la racine de votre dépôt. Pour éviter les erreurs d’espacement et de mise en forme, il est recommandé d’installer une extension YAML dans votre IDE pour bénéficier de la coloration syntaxique et améliorer la lisibilité du code.

Ce fichier de configuration nous permettra d’exécuter Terraform dans un environnement GitLab en utilisant des commandes adaptées à l’intégration CI/CD. Plutôt que d’utiliser les commandes classiques (terraform init, terraform plan, terraform apply, etc.), nous allons tirer parti de leur version optimisée pour GitLab. Ces commandes font partie des GitLab Terraform Helpers qui incluent des variables génériques, des commandes ou des images de conteneurs personnalisées.

Les Terraform Helpers permettent une meilleure gestion du state distant et une intégration fluide avec le backend GitLab. En ce qui concerne les commandes, au lieu de commencer par « terraform », elles sont préfixées par « gitlab- », ce qui donne, par exemple : gitlab-terraform plan, gitlab-terraform apply, etc.

En réalité, gitlab-terraform est un script qui encapsule les commandes standard « terraform » pour automatiser certaines interactions telles que l’authentification et la gestion des states via l’API GitLab. Ces commandes assurent une compatibilité optimale avec le backend GitLab, ce qui simplifie le stockage...

Conclusion

Dans ce chapitre, nous avons construit un pipeline GitLab CI/CD complet pour déployer une machine virtuelle Ubuntu dans Azure avec Terraform et automatiser son enregistrement en tant que GitLab Runner. Ce processus nous a permis de mettre en pratique le DevOps en travaillant notamment avec l’Infrastructure as code, l’intégration continue, l’automatisation des tests et le backend permettant de stocker les states Terraform sur GitLab.

Au fil des sections, nous avons structuré notre pipeline en plusieurs jobs distincts pour faciliter le débogage et l’amélioration continue. Nous avons également intégré des outils de validation, de linting et d’analyse de sécurité afin de garantir que notre code Terraform soit conforme aux bonnes pratiques. De plus, certaines fonctionnalités avancées comme l’utilisation du cache et les structures de pipeline DAG et parent-enfant ont aussi été expérimentées.

L’approche que nous avons suivie ici est facilement adaptable à d’autres fournisseurs cloud, comme AWS ou Google Cloud, en ajustant les configurations Terraform en fonction des composants propres à chaque environnement cible.

En appliquant ces principes, nous avons montré comment GitLab peut servir de plateforme centrale pour la gestion de l’infrastructure et l’automatisation des déploiements....

Construire un pipeline CI/CD de bout en bout