GitLab CI/CD

De wiki.nexiat.fr
Aller à la navigation Aller à la recherche
Fiche express
Type Plateforme d'intégration et de déploiement continus (CI/CD)
Éditeur GitLab Inc. (composant de GitLab, CE/EE)
Format YAML (.gitlab-ci.yml)
Exécuteurs GitLab Runner (shell, Docker, Kubernetes, etc.)
Alternatives Jenkins, GitHub Actions
Voir aussi Terraform — Concepts fondamentaux · Ansible · Frontière IaC — Terraform, Ansible, GitOps

GitLab CI/CD est la plateforme d'intégration et de déploiement continus intégrée à GitLab. Contrairement à Jenkins, qui reste un serveur autonome à brancher sur un dépôt Git externe, GitLab CI/CD est nativement couplé au dépôt : le pipeline est défini par un fichier versionné à la racine du projet, .gitlab-ci.yml, et s'exécute automatiquement à chaque événement Git (push, merge request, tag, planification).

Modèle général

Un pipeline est déclenché par un événement Git et se compose de stages exécutés séquentiellement ; chaque stage regroupe des jobs exécutés en parallèle. Un job échoué bloque par défaut le passage au stage suivant.

<mermaid> flowchart LR 

   subgraph build[Stage: build]
     B1[job: compile]
   end
   subgraph test[Stage: test]
     T1[job: unit-tests]
     T2[job: lint]
   end
   subgraph deploy[Stage: deploy]
     D1[job: terraform-apply]
     D2[job: ansible-deploy]
   end
   build --> test --> deploy

</mermaid>

.gitlab-ci.yml

stages:
  - build
  - test
  - deploy

variables:
  TF_ROOT: infra/

build-job:
  stage: build
  image: golang:1.22
  script:
    - go build ./...
  artifacts:
    paths:
      - bin/

unit-tests:
  stage: test
  image: golang:1.22
  script:
    - go test ./...

terraform-apply:
  stage: deploy
  image: hashicorp/terraform:1.7
  script:
    - cd $TF_ROOT
    - terraform init
    - terraform apply -auto-approve
  environment:
    name: production
  rules:
    - if: '$CI_COMMIT_BRANCH == "main"'
      when: manual

ansible-deploy:
  stage: deploy
  image: registry.example.org/ansible-runner:latest
  script:
    - ansible-playbook -i inventory/prod site.yml
  needs: ["terraform-apply"]
  • stages — liste ordonnée des phases du pipeline.
  • jobs — unités d'exécution (une entrée de premier niveau, hors mots-clés réservés) rattachées à un stage via stage:.
  • script — suite de commandes shell exécutées dans le contexte du job.
  • artifacts — fichiers produits par un job et transmis aux jobs suivants (ou téléchargeables depuis l'interface).
  • rules (remplace l'ancien only/except) — conditionne l'exécution ou le déclenchement manuel (when: manual) d'un job selon la branche, le tag, l'événement, une variable...
  • needs — définit des dépendances explicites entre jobs, indépendamment de l'ordre des stages (exécution accélérée, DAG plutôt que séquence stricte).

Runners

Un GitLab Runner est l'agent qui exécute réellement les jobs. Il peut être :

  • partagé (shared) — fourni par l'instance GitLab, mutualisé entre projets ;
  • spécifique (specific) — enregistré sur un projet ou un groupe, dédié (typiquement pour un accès réseau particulier, un GPU, un environnement on-prem).

Chaque runner utilise un executor : shell (exécution directe sur la machine hôte), docker (chaque job dans un conteneur éphémère, le plus courant), docker+machine/docker-autoscaler (provisionnement à la volée), ou kubernetes (chaque job devient un pod). Le choix de l'image (image:) et des tags permet de router un job vers le runner adéquat.

Pipelines de déploiement infra

GitLab CI/CD sert couramment de point d'orchestration pour les outils IaC déjà couverts par ce wiki :

  • un job terraform plan en merge request (revue du diff avant fusion), suivi d'un job terraform apply manuel sur la branche principale — voir Terraform — Concepts fondamentaux pour le cycle plan/apply et la gestion du state (à héberger dans un backend distant, jamais dans le pipeline) ;
  • un job ansible-playbook pour la configuration post-provisionnement — voir Ansible ;
  • la notion d'environment: permet de suivre les déploiements par environnement (staging, production) et d'afficher l'historique de déploiement dans l'interface GitLab.

Le partage des responsabilités entre provisionnement, configuration et déploiement continu reste valable ici : GitLab CI/CD est un bon orchestrateur push (il déclenche des actions), mais pour des workloads Kubernetes vivant en continu, un modèle pull de type GitOps (voir ArgoCD, FluxCD) offre une réconciliation permanente que ne fournit pas nativement un pipeline CI classique.

Réutilisation : include et extends

include:
  - project: 'infra/ci-templates'
    file: '/templates/terraform.yml'

.deploy-base:
  image: alpine:3.19
  before_script:
    - apk add --no-cache curl

deploy-staging:
  extends: .deploy-base
  stage: deploy
  script:
    - ./deploy.sh staging
  • include — importe des définitions de jobs depuis un autre fichier ou projet (mutualisation de templates CI entre dépôts).
  • extends — hérite des attributs d'un job « caché » (préfixé par un point, non exécuté seul).

Face à Jenkins et GitHub Actions

Dimension GitLab CI/CD Jenkins GitHub Actions
Format YAML déclaratif DSL Groovy (Jenkinsfile) ou UI YAML déclaratif
Couplage SCM Natif (GitLab) Externe, à connecter (webhooks, plugins) Natif (GitHub)
Exécuteurs GitLab Runner (auto-hébergé ou SaaS) Agents Jenkins (maître/agent) Runners GitHub (auto-hébergés ou SaaS)
Écosystème Intégré à la forge (MR, registre, environnements) Vaste catalogue de plugins, mature Marketplace d'actions réutilisables
Historique Plus récent, conçu YAML-first Le plus ancien (2011, ex-Hudson) Plus récent, conçu YAML-first

Le choix se fait rarement sur des critères techniques purs : il suit la forge Git déjà en place (GitLab, GitHub) ou, pour Jenkins, un existant à maintenir plutôt qu'un nouveau projet.

Voir aussi

Récupérée de "https://wiki.nexiat.fr/index.php?title=GitLab_CI/CD&oldid=2540"