Aller au contenu

Cours pratique sur les GitLab Runners

Objectifs

À la fin de ce module, vous serez capable de :

Qu’est-ce qu’un Runner ?

Un Runner est un agent qui exécute les tâches définies dans tes pipelines CI/CD (tests, builds, déploiements, etc.). Sans Runner, le pipeline reste “sur le papier” : c’est le Runner qui fait le travail concret sur une machine !

Version métaphorique :

Imaginez que le pipeline CI/CD est une recette de cuisine. Le Runner, c’est le cuisinier qui lit la recette et prépare le plat. Sans cuisinier (Runner), la recette (pipeline) ne sert à rien : rien n’est cuisiné (exécuté) !

Un Runner permet :

Et heurement, GitLab fournit des Runners partagés par défaut, mais l’on peut en installer pour plus de contrôle.

Pour bien comprendre son rôle, lorsque l’on pushes du code, le Runner :

  1. Récupère ton code
  2. Exécute les tests
  3. Construit notre application
  4. Déploie le résultat

Donc, sans Runner, rien ne se passe !

Fonctionnement général

Cycle d’exécution

  1. GitLab lit le fichier .gitlab-ci.yml que nous connaissons déjà (voir cours su r GitLab)
  2. Il envoie les “jobs” à un ou plusieurs Runners.
  3. Le Runner télécharge le code source, exécute les commandes et renvoie les résultats (logs, artefacts, etc.).

Les 3 types de Runners (déjà cité dans le cours GitLab)

Type Description Exemple
Shared Runner Utilisé par plusieurs projets GitLab Souvent géré par l’administrateur GitLab
Specific Runner Lié à un seul projet Idéal pour un poste étudiant ou un serveur local
Group Runner Disponible pour tous les projets d’un groupe Pour les équipes collaboratives

Comment le Runner exécute le code ?

Un Runner peut utiliser différents executors, c’est-à-dire des modes d’exécution :

Executor Description Usage typique
Shell Exécute directement les commandes sur la machine hôte Simple pour débuter
Docker Lance chaque job dans un conteneur isolé Idéal pour les environnements reproductibles
VirtualBox / SSH Exécute les jobs sur une autre machine Moins courant
Kubernetes Pour les infrastructures avancées Entreprise ou Cloud

Installation d’un Runner sur Windows

Étapes pas à pas

  1. Il faut téléchargez le binaire GitLab Runner : https://gitlab-runner-downloads.s3.amazonaws.com/latest/index.html

  2. Ensuite, ouvrez PowerShell en administrateur et exécutez :

    mkdir C:\GitLab-Runner
cd C:\GitLab-Runner
Invoke-WebRequest -Uri https://gitlab-runner-downloads.s3.amazonaws.com/latest/binaries/gitlab-runner-windows-amd64.exe -OutFile gitlab-runner.exe

  3. Enregistrez le Runner auprès de votre projet GitLab

    • Dans GitLab –> Settings –> CI/CD –> Runners –> Register a new runner (selon la version, ça peut être un peu différent)
    • Copiez l’URL et le token d’enregistrement.

  4. Dans PowerShell, tapez : .\gitlab-runner.exe register et saisissez les différentes valeurs demandées :

     Enter the GitLab instance URL: https://gitlab.com/
 Enter the registration token: <votre_token>
 Enter a description: RunnerWindows
 Enter tags: windows, shell
 Enter executor: shell

  5. Installez le service Windows :

    ```powershell .\gitlab-runner.exe install .\gitlab-runner.exe start ``

  6. Vérifiez dans GitLab –> CI/CD –> Runners : le vôtre doit apparaître en vert !

Installation d’un Runner sur *Ubuntu

Étapes pas à pas

  1. Installez le package officiel

     sudo apt update
 sudo apt install -y curl
 curl -L https://packages.gitlab.com/install/repositories/runner/gitlab-runner/script.deb.sh | sudo bash
 sudo apt install gitlab-runner -y

  2. Enregistrez le Runner : sudo gitlab-runner register et saisissez les différentes valeurs demandées :

     Enter the GitLab instance URL: https://gitlab.com/
 Enter the registration token: <votre_token>
 Enter a description: RunnerLinux
 Enter tags: linux, shell
 Enter executor: shell

  3. Démarrez le service

     sudo systemctl enable gitlab-runner
 sudo systemctl start gitlab-runner
 sudo systemctl status gitlab-runner

  4. Vérifiez dans GitLab –> CI/CD –> Runners : le vôtre doit apparaître en vert !

Premier pipeline exécuté avec votre Runner local

Étape 1 : Créez un projet GitLab nommé runner-test

Étape 2 : Ajoutez un fichier .gitlab-ci.yml

stages:
  - test

test-runner:
  stage: test
  script:
    - echo "Bonjour depuis mon Runner local !"
    - echo "Le système d’exploitation est :"
    - uname -a || ver
  tags:
    - windows
    - linux

Étape 3 : Commitez et poussez le fichier

GitLab déclenche automatiquement le pipeline et attribue le job à votre Runner correspondant (selon le tag).

Résultat attendu :

Comprendre les tags

Les tags permettent d’indiquer à GitLab quel Runner doit exécuter un job.

Élément Exemple
Runner enregistré avec tags: linux, docker
Job .gitlab-ci.yml contient tags: [docker]
Résultat GitLab sélectionne ce Runner précis

Les tags sont comme des étiquettes associés à un job. Gitlab choisit le bon Runner selon l’étiquette qu’il lit sur le job.

Deux Runners, deux environnements

Objectif : Faire exécuter un job différent selon le système d’exploitation.

.gitlab-ci.yml

stages:
  - build

build-windows:
  stage: build
  script:
    - echo "Compilation sous Windows"
    - dir
  tags:
    - windows

build-linux:
  stage: build
  script:
    - echo "Compilation sous Linux"
    - ls -la
  tags:
    - linux

Résultat attendu :

Sécurité et bonnes pratiques

Récapitulatif

Élément Rôle
.gitlab-ci.yml Décrit le pipeline
Runner Exécute les jobs
Tags Permettent à GitLab de choisir le bon Runner
Executor Définit l’environnement d’exécution (Shell, Docker…)

Vous comprenez que sans Runner il n’y a pas d’automatisation ! Le Runner est le moteur invisible qui fait vivre la CI/CD.

Exercice final : Runner Dockerisé

Objectif : installer un Runner qui exécute vos jobs dans des conteneurs Docker

  1. Installer Docker sur Linux : sudo apt install docker.io -y
  2. Ajouter le Runner Docker : sudo gitlab-runner register --executor docker

  3. Répondez :

     Enter the default Docker image: alpine:latest
 Enter tags: docker

  4. Créer un job de test

     docker-job:
 stage: test
 image: alpine:latest
 script:
     - echo "Je tourne dans un conteneur Docker"
 tags:
     - docker

Résultat attendu : GitLab télécharge l’image alpine et exécute le job dans un conteneur.

Pour aller plus loin

Conclusion

Le Runner est le lien entre GitLab et votre machine. Il écoute GitLab, reçoit les ordres, et exécute les jobs.

Vous pouvez en créer plusieurs, les taguer, les sécuriser et les isoler. Sans Runners, vos pipelines resteraient des partitions jamais jouées !

Avec eux, votre automatisation DevOps devient une symphonie complète.

Bonus

TP corrigé : Création d’un Runner Docker partagé (multi-développeurs)

Objectif : Mettre en place un Runner partagé sur une machine Linux (ou serveur Ubuntu) pour exécuter automatiquement les pipelines de plusieurs projets étudiants,
avec isolation Docker pour chaque job.

Architecture cible

        ┌──────────────────────────────────┐
        │          GITLAB SERVER            │
        │   (héberge les dépôts et jobs)   │
        └──────────────────────────────────┘
                      │
                      ▼
        ┌──────────────────────────────────┐
        │         GITLAB RUNNER             │
        │  (sur un serveur partagé Linux)  │
        ├──────────────────────────────────┤
        │ Executor : Docker                │
        │ Image de base : alpine:latest    │
        │ Tags : docker, shared, linux     │
        └──────────────────────────────────┘
                      │
                      ▼
        ┌──────────────────────────────────┐
        │     Conteneurs Docker isolés     │
        │   (1 conteneur par job lancé)    │
        └──────────────────────────────────┘ ---

Pré-requis pour ce TP

  sudo apt install docker.io -y
  sudo systemctl enable docker
  sudo systemctl start docker

Étapes d’installation du Runner partagé

  1. Installer GitLab Runner

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

  2. Enregistrer le Runner partagé : sudo gitlab-runner register

     Enter the GitLab instance URL: https://gitlab.com/
 Enter the registration token: <token du groupe GitLab>
 Enter a description: RunnerDockerPartagé
 Enter tags: docker, shared, linux
 Enter executor: docker
 Enter the default Docker image: alpine:latest

(Utiliser le token de groupe permet de partager le Runner avec tous les projets du même groupe GitLab, pensez-y !)

  1. Vérifier le Runner : sudo gitlab-runner list

Résultat attendu :

Listing configured runners ConfigFile=/etc/gitlab-runner/config.toml
RunnerDockerPartagé  Executor=docker  Token=XXXX  URL=https://gitlab.com/

Le Runner doit aussi apparaître dans GitLab –> Settings –> CI/CD –> Runners (en vert).

Exemple de `.gitlab-ci.yml commun aux apprenant.e.s

stages:
  - test

test-environnement:
  stage: test
  image: alpine:latest
  script:
    - echo "Bonjour depuis le Runner partagé !"
    - echo "Ce job tourne dans un conteneur isolé"
    - uname -a
  tags:
    - docker

Quelques explications sur ce TP

Si on reprend nos métaphores :

Sécurité du Runner partagé

Exemple :

[runners.docker]
  tls_verify = false
  image = "alpine:latest"
  privileged = false
  disable_cache = false
  volumes = ["/cache"]

Vérification finale

Résultat attendu :

Job A --> Exécuté dans conteneur runner-xxxx
Job B --> Exécuté dans conteneur runner-yyyy

Schéma de fonctionnement

Récapitulatif

Concept Rôle Exemple
Runner Exécute les jobs GitLab Machine locale ou serveur
Executor Type d’exécution Shell, Docker, SSH, Kubernetes
Tags Filtrage du Runner linux, docker, windows
Shared Runner Runner partagé entre projets Pour une salle de TP
Specific Runner Runner lié à un projet unique Pour un poste personnel
Pipeline Enchaînement de jobs build -> test -> deploy

Pour aller plus loin

Vous pouvez tester un Runner Docker-in-Docker (dind) pour construire des images dans les pipelines, créer un Runner Windows pour des jobs PowerShell ou bien utiliser des Runners autoscalés sur le cloud (GitLab SaaS + AWS).

Le Runner est le cœur battant de GitLab CI/CD. Sans lui, aucun pipeline ne s’exécute. Avec lui, vos scripts deviennent des actions automatiques, fiables et traçables ! GitLab est le chef d’orchestre, le fichier .gitlab-ci.yml est la partition et le Runner est le musicien qui fait vivre la musique DevOps !

Auteur : Philippe Bouget