Passer au contenu principal

CI/CD (GitLab)

Runners : installation et configuration

Un runner est un processus qui recoit des jobs depuis GitLab, les execute dans un environnement configure et reporte les resultats. Les runners sont independants de l'instance GitLab : ils peuvent tourner sur n'importe quelle machine disposant d'une connexion sortante vers GitLab.

Types de runners

  • Instance runners (ex shared runners) : disponibles pour tous les projets de l'instance
  • Group runners : disponibles pour tous les projets d'un groupe et ses sous-groupes
  • Project runners (ex specific runners) : exclusifs a un projet

GitLab.com fournit des instance runners avec des credits CI mensuels selon le plan. En self-hosted, il n'y a pas de runners fournis : on les installe soi-meme.

Installation du runner

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

# Enregistrement
gitlab-runner register   --url https://gitlab.example.com   --token REGISTRATION_TOKEN   --executor docker   --docker-image alpine:latest

Depuis GitLab 16, le token d'enregistrement est un token d'authentification runner (format glrt-...), cree depuis l'interface (Admin > Runners > New runner ou Settings > CI/CD > Runners). L'ancien token partage de groupe/projet est deprecioe.

Executors

  • shell : execute directement sur le systeme hote. Simple, mais sans isolation. A eviter en production sauf cas specifiques.
  • docker : chaque job dans un conteneur isole. Recommande. Necessite Docker sur la machine runner.
  • docker+machine : cree des VMs a la volee (AWS, GCP, Azure) pour chaque job. Autoscaling natif mais deprecie depuis GitLab 17.
  • kubernetes : chaque job dans un pod Kubernetes. Autoscaling elastique, isolation forte.
  • docker-autoscaler : successeur de docker+machine, en GA depuis GitLab 17.
  • instance : executor base sur des VM avec Fleeting, le nouveau framework d'autoscaling.

Tags de runner

Les runners peuvent avoir des tags. Un job qui declare des tags ne sera execute que par un runner possedant ces tags. Utile pour router les jobs vers des runners specialises : GPU, ARM, Windows, environnement de production.

build-gpu:
  tags:
    - gpu
    - cuda
  script:
    - nvidia-smi

Securite des runners

Un runner shell a acces complet au systeme hote. Un runner Docker avec privileged: true peut s'echapper du conteneur. Il faut traiter les runners comme des systemes privilegies, surtout ceux qui ont acces aux projets publics ou a des variables sensibles. Separer les runners non proteges (pour les forks/contributions externes) des runners privilegies (pour le code de production).

Sources