Mise à jour : 24 avril 2025
Lecture : 9 min
Découvrez comment automatiser la gestion de votre infrastructure pour accompagner la croissance de votre entreprise grâce à des pipelines CI/CD sécurisés et un scanning de sécurité intégré, à l'aide de GitLab, Terraform/OpenTofu et Ansible.
Les outils d'Infrastructure as Code (IaC), tels que TerraForm/OpenTofu, ou de gestion des configurations, tels qu'Ansible, jouent un rôle clé dans de nombreux workflows critiques. Ces projets commencent parfois par de simples scripts d'automatisations, sans nécessairement suivre les bonnes pratiques de développement logiciel ni répondre aux contrôles réglementaires exigés pour les applications logicielles d'entreprise.
Souvent développées par des ingénieurs système ou des ingénieurs d'infrastructure, ces automatisations sont mises en place sans réelle expertise des approches DevOps, DevSecOps, CI/CD et d'automatisation des tests. Dans les grandes entreprises employant de nombreuses équipes d'ingénieurs parfois cloisonnées, la situation est encore plus compliquée.
Chez GitLab, nous maîtrisons l'approche DevSecOps depuis plus de 10 ans et utilisons notre plateforme DevSecOps unifiée en interne pour automatiser des charges de travail critiques à l'échelle de l'entreprise. Nous accompagnons des milliers de clients qui s'appuient sur notre plateforme GitLab pour une variété de processus : Infrastructure as Code (IaC), automatisation, gestion cloud, ingénierie de plateforme et bien d'autres encore.
Découvrez dans cet article les principales fonctionnalités pour transformer vos puissantes automatisations en pipelines de livraison de logiciels évolutifs et auditables.
Ce projet de démonstration illustre un workflow DevOps complet qui combine la puissance d'OpenTofu avec les pratiques modernes d'Ansible, le tout orchestré via les pipelines CI/CD de GitLab. Il met en scène le provisionnement d'un environnement de test AWS à l'aide de composants OpenTofu intégrés à GitLab, suivi du déploiement d'un serveur web Tomcat à l'aide de la version la plus récente d'Ansible, avec exécution dans un environnement personnalisé et prise en charge des collections.
Le projet tire parti de nombreuses fonctionnalités de GitLab :
L'ensemble du workflow est automatisé par le biais d'un pipeline GitLab qui gère toutes les étapes, du provisionnement de l'infrastructure au déploiement des applications, en passant par les tests de sécurité.
Le projet commence par le provisionnement d'un environnement de test AWS à l'aide d'OpenTofu, en s'appuyant sur l'intégration native des composants OpenTofu de GitLab, qui rationalisent le processus de provisionnement de l'infrastructure. Le pipeline inclut des étapes de validation, de planification et d'application qui garantissent un déploiement approprié de l'infrastructure tout en maintenant les bonnes pratiques IaC de GitLab.
Ce projet tire parti des capacités de l'outil de gestion des fichiers d'état de Terraform intégré à GitLab ainsi que du Terraform Module Registry, tous deux compatibles avec OpenTofu et HashiCorp Terraform. Il est également possible d'utiliser les composants OpenTofu de GitLab avec HashiCorp Terraform en procédant à une légère personnalisation : vous devez créer votre propre image incluant un script nommé gitlab-tofu
pour maintenir sa compatibilité avec les jobs de composants. Vous pouvez ensuite remplacer les commandes tofu
par les commandes Terraform
équivalentes.
L'exemple de composant « OpenTofu Module Release » montre comment créer un module Terraform et le stocker dans Terraform Module Registry dans GitLab. Ce module est ensuite importé dans le fichier provision_lab.tf
directement depuis GitLab pour déployer l'environnement de test sur AWS. Ensuite, il génère un fichier d'inventaire contenant l'adresse IP publique de l'instance provisionnée, qui peut être utilisée dans les étapes de gestion des configurations avec Ansible.
# From .gitlab-ci.yml
- component: gitlab.com/components/opentofu/[email protected]
inputs:
root_dir: tofu
as: 🔍 tofu-module-release
stage: 🏗️ build-tofu-module
module_version: 0.0.1
module_system: aws
module_name: aws-lab
root_dir: tofu/modules/ansible-demo/aws-lab
rules:
- if: "$CI_COMMIT_BRANCH"
when: manual
# From provision_lab.tf
module "aws-lab" {
source = "https://gitlab.com/api/v4/projects/67604719/packages/terraform/modules/aws-lab/aws/0.0.1"
}
Les composants de validation, de planification et de déploiement sont configurés avec le paramètre **auto_define_backend: true**
. Ils s'intègrent automatiquement au backend de stockage d’état Terraform intégré à GitLab et éliminent le besoin de configuration manuelle du backend ou de solutions de stockage d'état externes telles que des compartiments S3.
# From gitlab-ci.yml
- component: gitlab.com/components/opentofu/[email protected]
inputs:
version: 0.55.0
opentofu_version: 1.8.8
root_dir: tofu
state_name: demo
as: ✅ tofu-apply
stage: 🏗️ provision-lab
auto_define_backend: true
rules:
- if: "$CI_COMMIT_BRANCH"
when: manual
La configuration de l'infrastructure crée une instance EC2 CentOS Stream 9 avec des groupes de sécurité appropriés pour autoriser l'accès SSH depuis les runners GitLab et l'accès HTTP au serveur Tomcat.
L'accès SSH et la configuration HTTP sont configurés par le biais des variables d'environnement GitLab CI/CD.
Pour un accès sécurisé au cloud, le projet met en œuvre l'intégration OpenID Connect de GitLab avec AWS, en utilisant des identifiants de connexion temporaires via AWS Security Token Service (STS) :
# From .gitlab-ci.yml
.tofu_aws_setup:
id_tokens:
OIDC_TOKEN:
aud: https://gitlab.com
before_script:
- echo "${OIDC_TOKEN}" > /tmp/web_identity_token
- export AWS_PROFILE=""
- export AWS_ROLE_ARN="${AWS_ROLE_ARN}"
- export AWS_WEB_IDENTITY_TOKEN_FILE="/tmp/web_identity_token"
Les déploiements modernes avec Ansible reposent largement sur l'utilisation d'environnements d'exécution : il s'agit de versions conteneurisées qui encapsulent Ansible avec toutes ses dépendances, y compris les rôles et les collections préinstallés nécessaires. Dans ce projet, un environnement d'exécution personnalisé est créé, basé sur Fedora 39, qui inclut ansible-core, ansible-runner ainsi que des collections spécifiques, telle que ansible.posix, requise dans cet exemple pour configurer le pare-feu et SELinux.
Les rôles et collections tiers de ce projet sont téléchargés en mode natif à partir du dépôt communautaire Ansible Galaxy. Cette approche s'appuie sur l'écosystème de contenu Ansible réutilisable de la communauté, comme le montre la configuration de l'environnement d'exécution. Bien que cette démonstration utilise des ressources Ansible de la communauté, cette mise en œuvre de pipeline est entièrement compatible avec Red Hat Ansible Automation Platform. La structure du pipeline reste identique ; seules les sources de contenu changent. Ainsi, les entreprises qui utilisent la version Enterprise peuvent simplement rediriger leurs sources de contenu d'automatisation vers leur Automation Hub privé au lieu du dépôt Ansible Galaxy par défaut issu de la communauté. Selon la documentation officielle de l'entreprise, vous pouvez réaliser cette opération en configurant votre serveur Automation Hub privé et votre token d'accès dans le fichier ansible.cfg.
# From execution-environment.yml
---
version: 3
images:
base_image:
name: quay.io/fedora/fedora:39
dependencies:
ansible_core:
package_pip: ansible-core
ansible_runner:
package_pip: ansible-runner
system:
- openssh-clients
- sshpass
galaxy:
collections:
- name: ansible.posix
version: ">=2.0.0"
L'environnement d'exécution est défini dans un fichier YAML, généré à l'aide d'ansible-builder, puis faisant l'objet d'un push vers le registre de conteneurs de GitLab. Cette approche garantit des environnements d'exécution cohérents d'un système à l'autre, tout en simplifiant la gestion des dépendances.
# From gitlab-ci.yml
🔨 ansible-build-ee:
stage: 📦 ansible-build-ee
image: docker:24.0.5
needs: []
services:
- docker:24.0.5-dind
before_script:
- apk add --no-cache python3 py3-pip
- pip install ansible-builder
- cd ansible/execution-environment
script:
- ansible-builder build -t ${EE_IMAGE_NAME}:${EE_IMAGE_TAG} --container-runtime docker
- docker tag ${EE_IMAGE_NAME}:${EE_IMAGE_TAG} ${CI_REGISTRY_IMAGE}/${EE_IMAGE_NAME}:${EE_IMAGE_TAG}
- docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY
- docker push ${CI_REGISTRY_IMAGE}/${EE_IMAGE_NAME}:${EE_IMAGE_TAG}
Une fois l'infrastructure provisionnée et l'environnement d'exécution construit, le pipeline déploie Tomcat à l'aide d'Ansible Navigator. L'environnement d'exécution créé à l'étape précédente est utilisé comme image pour le job de déploiement dans le pipeline GitLab.
# From gitlab-ci.yml
🚀 ansible-deploy:
stage: 🚀 ansible-deploy
image: ${CI_REGISTRY_IMAGE}/${EE_IMAGE_NAME}:${EE_IMAGE_TAG}
needs:
- ✅ tofu-apply
extends: [.ssh_private_key_setup, .default_rules]
script:
- ansible-navigator run ansible/playbook.yml
-i ansible/inventory/hosts.ini
--execution-environment false
--mode stdout
--log-level debug
Ce processus récupère le paquet applicatif depuis le dépôt de paquets générique de GitLab, configure les utilisateurs et les autorisations système, et définit Tomcat comme service systemd.
# From playbook.yml
---
- name: Deploy Tomcat Server
hosts: all
become: true
roles:
- role: tomcat
vars:
# Tomcat package and installation
tomcat_package: "https://gitlab.com/api/v4/projects/67604719/packages/generic/apache-tomcat/10.1.39/apache-tomcat-10.1.39.tar.gz"
tomcat_install_dir: "/opt/tomcat"
java_package: "java-17-openjdk-devel"
La sécurité est intégrée tout au long du pipeline avec plusieurs outils de scanning. Ce projet utilise le scanner SAST IaC intégré de GitLab pour détecter les vulnérabilités dans le code Terraform et Ansible. L'analyse des conteneurs est appliquée à l'image de l'environnement d'exécution pour identifier tout problème de sécurité et générer une nomenclature logicielle (SBOM).
# From gitlab-ci.yml
include:
- template: Jobs/SAST-IaC.gitlab-ci.yml
- template: Jobs/Container-Scanning.gitlab-ci.yml
De plus, le projet utilise Ansible Linter et ses résultats sont intégrés à GitLab Code Quality. Cette intégration produit des rapports qui sont affichés directement dans l'interface de GitLab, ce qui facilite l'identification et la résolution des anomalies.
# From gitlab-ci.yml
🔍 ansible-lint:
stage: 🚀 ansible-deploy
image: ${CI_REGISTRY_IMAGE}/${EE_IMAGE_NAME}:${EE_IMAGE_TAG}
needs: []
script:
- ansible-lint ansible/playbook.yml -f codeclimate | python3 -m json.tool | tee gl-code-quality-report.json || true
artifacts:
reports:
codequality:
- gl-code-quality-report.json
Après le déploiement, le pipeline effectue des vérifications de l'état pour s'assurer que le serveur Tomcat fonctionne correctement. Ce job tente d'établir une connexion au port HTTP du serveur et vérifie qu'il renvoie une réponse confirmant que le service est bien actif. Cette étape garantit que le déploiement s'est correctement terminé et que l'application est accessible.
Vous pouvez également tester l'accès de votre navigateur à l'instance provisionnée par Tomcat en utilisant l'adresse IP publique de l'instance provisionnée EC2.
Dernière étape du pipeline : le processus de nettoyage détruit l'environnement de test. Cette opération est mise en œuvre à l'aide du composant de destruction OpenTofu, qui garantit que toutes les ressources créées au cours de l'étape de provisionnement sont correctement supprimées.
GitLab offre une plateforme DevSecOps unifiée et un framework pour gérer, à l'échelle de l'entreprise, les pratiques d'automatisation critiques telles que la gestion des configurations et de l'IaC (Infrastructure as Code). Ce framework inclut le contrôle de version, la planification de projet, la gestion des tickets, la collaboration entre les équipes, les pipelines CI/CD, la gestion du paquet de binaires et du registre de conteneurs, le scanning de sécurité et de nombreuses autres fonctionnalités utiles. Il permet également de renforcer la gouvernance grâce à des contrôles intégrés dans les processus. Si vous cherchez à développer vos pratiques cloud (qu’il s’agisse d’un cloud privé ou public) ou plus généralement, de tout workflow d'automatisation en libre-service doté de règles de gouvernance, envisagez d'utiliser GitLab, TerraForm et Ansible comme les trois piliers d'une plateforme d'automatisation à la fois évolutive et conforme aux exigences de gouvernance.
Lancez-vous avec un essai gratuit de 60 jours de GitLab Ultimate. Inscrivez-vous dès aujourd'hui !