GitLab CI/CD : comprendre la plateforme avant de pipeline

Tu connais GitHub. Tout le monde connaît GitHub. Mais dans le monde pro — surtout en Europe, surtout quand la souveraineté des données entre en jeu — c’est GitLab que tu retrouves partout. Et ce n’est pas un hasard : GitLab est né comme une seule application pour tout le cycle DevOps. Le CI/CD n’est pas un plugin greffé après coup, c’est le cœur du produit.

Ce premier cours pose les fondations. Avant d’écrire une seule ligne de YAML, tu dois comprendre comment GitLab fonctionne, pourquoi son architecture est différente, et comment ses runners exécutent tes pipelines.

Pourquoi GitLab change la donne en DevOps

GitHub est un hébergeur de dépôts Git qui a greffé des features (Actions, Packages, GHCR) au fil du temps. GitLab a pris le chemin inverse : tout est intégré dès le départ — container registry, package registry, security scanning (SAST, DAST, dependency scanning), gestion de projet, feature flags, Terraform state backend.

La différence fondamentale se voit dans l’approche CI/CD. GitHub Actions utilise des workflows indépendants déclenchés par événements, avec un marketplace d’actions communautaires. GitLab CI utilise un fichier unique .gitlab-ci.yml organisé en stages séquentiels contenant des jobs parallèles.

Voici un pipeline GitLab CI minimal qui montre cette structure en stages :

# .gitlab-ci.yml — pipeline en deux stages
stages:
  - build
  - test

build:
  stage: build
  script:
    - make build

test:
  stage: test
  script:
    - make test

💡 Tip DevOps : La philosophie “single application” a un avantage sous-estimé — la corrélation des données. Quand ton issue, ta merge request, ton pipeline et ton scan de sécurité vivent dans le même outil, tu traces un chemin complet du besoin à la production. Avec des outils séparés, cette traçabilité demande du glue code.

🧠 À retenir : GitLab n’est pas “mieux” que GitHub. C’est une philosophie différente. GitLab mise sur l’intégration verticale (tout dans un outil), GitHub sur l’écosystème (marketplace, intégrations tierces). Le bon choix dépend de ton contexte.

Comprendre l’architecture de GitLab CI

Pour bien debugger et prendre les bonnes décisions, tu dois connaître les briques principales.

Rails (Puma) est le cœur applicatif — l’UI, l’API REST et GraphQL. Gitaly gère toutes les opérations Git via gRPC (plus d’accès direct au filesystem depuis GitLab 14+). PostgreSQL stocke tout : users, projets, pipelines, permissions. Redis et Sidekiq gèrent le cache et les jobs asynchrones (emails, webhooks, processing CI).

Le chemin d’un pipeline se résume en 4 temps :

1. Tu pushes → Gitaly notifie Rails → le .gitlab-ci.yml est parsé
2. Rails crée le pipeline, les stages et les jobs en base
3. Un runner poll l’API (POST /api/v4/jobs/request) pour récupérer un job — c’est du pull-based
4. Le runner exécute le job, streame les logs en temps réel, et rapporte le résultat

⚠️ Attention : Le modèle pull-based est un choix de sécurité délibéré. Les runners n’ont besoin que d’un accès HTTPS sortant vers GitLab. Ils peuvent vivre derrière un NAT ou un firewall sans ouvrir de port entrant.

🔥 Cas réel : Dans une banque européenne, les runners de production étaient dans des zones réseau isolées. Grâce au modèle pull, ils se connectaient à GitLab via un proxy HTTPS — zéro ouverture de flux entrant vers la zone sécurisée.

Les commandes essentielles pour démarrer

Un runner s’installe et s’enregistre en quelques commandes. D’abord le package officiel, puis l’enregistrement qui lie le runner à ton instance et configure l’executor :

# Installer le runner
curl -L "https://packages.gitlab.com/install/repositories/runner/gitlab-runner/script.deb.sh" | sudo bash
sudo apt install gitlab-runner

# Enregistrer le runner
sudo gitlab-runner register \
  --url https://gitlab.com/ \
  --registration-token glrt-XXXXXXXXXXXXXXXXXXXX \
  --executor docker \
  --docker-image python:3.12 \
  --description "Mon premier runner" \
  --tag-list "docker,linux"

⚠️ Attention : Depuis GitLab 16+, les registration tokens sont dépréciés. Génère un runner authentication token depuis Settings → CI/CD → Runners → New project runner.

L’executor détermine comment le job tourne. Le Docker executor (le plus courant) lance un conteneur frais par job — isolation garantie. Le Shell executor exécute directement sur l’hôte — simple mais dangereux en multi-tenant. Le Kubernetes executor crée un pod éphémère — le plus scalable. Voici la configuration Docker dans /etc/gitlab-runner/config.toml :

[[runners]]
  name = "docker-runner"
  executor = "docker"
  [runners.docker]
    image = "python:3.12"
    privileged = false
    volumes = ["/cache"]

Les tags dirigent les jobs vers les bons runners. Un job avec tags: [production, aws] ne sera pris que par un runner possédant les deux tags.

💡 Tip DevOps : Adopte une convention de nommage pour tes tags : {executor}-{os}-{env}. Des tags comme docker-linux-staging ou k8s-linux-prod-gpu rendent le routage prévisible et debuggable.

Cas concret : GitLab en entreprise

Voici un scénario classique. Une startup healthtech suisse doit respecter la LPD (loi sur la protection des données) et préparer ISO 27001. Les données doivent rester en Suisse.

La solution : GitLab CE (Community Edition, gratuit et open source) installé sur des serveurs Infomaniak. L’installation Omnibus package tout (Rails, PostgreSQL, Redis, Nginx) en une commande :

sudo EXTERNAL_URL="https://gitlab.example.com" apt install gitlab-ee

Résultat : souveraineté des données gratuite, CI/CD complet, container et package registry inclus. Avec GitHub Enterprise, le même setup coûtait 21$/user/mois + l’infra.

Les trois modes de déploiement GitLab couvrent tous les cas :

• GitLab.com (SaaS) — zéro maintenance, 400 min CI/mois en free tier
• Self-Managed — contrôle total, CE gratuit ou EE payant (min recommandé : 8 vCPU, 16 GB RAM)
• Dedicated — instance isolée managée par GitLab, pour les grands comptes

🔥 Cas réel : Une fintech a migré de GitHub Enterprise à GitLab CE self-hosted en un week-end. La migration des repos + CI/CD a pris moins de temps que la paperasse de compliance FINMA.

Les pièges fréquents

Le YAML qui casse en silence. GitLab parse ton .gitlab-ci.yml côté serveur. Un fichier syntaxiquement valide peut produire un pipeline inattendu (job ignoré, stage manquant). Utilise toujours le Pipeline Editor (Build → Pipeline editor) pour valider avant de pusher.

Les minutes CI qui explosent. Free tier GitLab.com = 400 min/mois. Sur GitHub, les minutes macOS comptent 10x. Un pipeline iOS peut vider ton quota en quelques jours. Monitore ta consommation.

Confondre artefacts et cache. Un artefact est un résultat de job (binaire, rapport), garanti et transmissible entre jobs. Un cache est une optimisation (node_modules/, .venv/), best-effort — il peut disparaître sans prévenir.

Sidekiq qui s’engorge en self-hosted. C’est le premier composant qui tombe sous la charge. Quand les queues gonflent : pipelines bloqués, UI lente, emails en retard. Monitore la taille des queues en priorité.

privileged = true sur le Docker executor. Nécessaire pour Docker-in-Docker, mais un conteneur privilégié a un accès quasi-root sur l’hôte. Préfère kaniko ou buildah pour builder des images sans privilège.

Exercice et synthèse

À toi de jouer

Crée un projet sur GitLab.com et pousse ce .gitlab-ci.yml. Le job build crée un fichier en artefact, le job test le récupère automatiquement :

stages:
  - build
  - test

build:
  stage: build
  image: alpine:latest
  script:
    - mkdir -p build && echo "v1.0" > build/version.txt
  artifacts:
    paths: [build/]

test:
  stage: test
  image: alpine:latest
  script:
    - cat build/version.txt
    - echo "Version $(cat build/version.txt) — tests OK"

Ce que tu dois observer : le pipeline a deux stages séquentiels, le job test accède au fichier créé par build grâce aux artefacts, et les logs sont visibles en temps réel dans l’UI.

Bonus : ajoute un job deploy avec when: manual et environment: staging pour découvrir les déploiements manuels.

À retenir

Les 6 concepts à maîtriser avant le prochain cours :

• Pipeline — l’ensemble du processus CI/CD déclenché par un push, une MR ou un schedule
• Stage — une phase séquentielle (build → test → deploy). Si un stage échoue, les suivants ne tournent pas
• Job — l’unité d’exécution. Les jobs d’un même stage tournent en parallèle
• Runner — l’agent qui poll l’API et exécute les jobs. Modèle pull-based, trois niveaux (shared, group, project)
• Executor — le mécanisme d’exécution : Docker (conteneur éphémère), Shell (hôte direct), Kubernetes (pod éphémère)
• Artefact vs Cache — l’artefact est un résultat garanti, le cache est une optimisation best-effort

🧠 À retenir : Le CI_JOB_TOKEN est un token temporaire généré par job. Il authentifie tes jobs auprès du container registry, du package registry et de l’API GitLab — sans credentials permanents. Il expire à la fin du job.

Dans le prochain cours, tu vas écrire un vrai pipeline avec plusieurs stages, des artefacts partagés, du cache et des règles de déclenchement conditionnelles. On y va ? 🚀