Le DevOps en pratique avec GitLab - Travailler avec les GitLab Runners

Introduction

Dans le chapitre Les pipelines CI/CD dans GitLab, nous avons appris les notions fondamentales des pipelines GitLab. Après avoir exécuté un pipeline simple de type Hello world, nous avons vu comment écrire un fichier de configuration avec les différents mots-clés que GitLab met à notre disposition.

Le présent chapitre sera consacré aux GitLab Runners que nous avons déjà évoqués brièvement dans le chapitre précédent. Nous verrons de plus près comment ces composants exécutent les jobs définies dans les différentes étapes du fichier .gitlab-ci.yml. Notre parcours commencera par une définition des runners ainsi qu’une présentation de leur rôle et leur fonctionnement dans GitLab.

Nous apprendrons ensuite comment installer, configurer et enregistrer un runner sur la plateforme. En guise de conclusion, nous verrons certains aspects qu’il est important de prendre en compte pour les GitLab Runners comme la performance, le monitoring et la sécurité.

Comprendre la notion de GitLab Runner

Ainsi que nous l’avons déjà indiqué dans le chapitre Les pipelines CI/CD dans GitLab, un pipeline est une série de tâches exécutées sur le code source d’un projet. Ce processus comprend généralement une combinaison de trois étapes : build, test et deploy.

Chacune de ces étapes comprend des jobs qui nécessitent une plateforme d’exécution, ainsi qu’un ensemble d’outils spécifiques (interface en ligne de commande, gestionnaires de packages, etc.) pour être effectuée. La prise en charge de ces travaux est confiée aux GitLab Runners.

1. Définition d’un GitLab Runner

Un GitLab Runner est un petit programme utilisé pour exécuter des tâches dans les pipelines CI/CD de GitLab. Il agit comme un agent qui prend en charge l’exécution des jobs définis dans les fichiers .gitlab-ci.yml.

Dans ce chapitre, lorsqu’il est question de « tâches » CI/CD, nous faisons référence aux commandes des blocs script d’un job. Comme il peut y avoir plusieurs jobs dans un pipeline, il nous a semblé plus juste de parler de « tâches » en général.

Les runners sont responsables d’interpréter les instructions, de gérer les environnements dans lesquels les jobs sont exécutés et de renvoyer les résultats à l’interface de GitLab. Ils peuvent être configurés pour fonctionner dans différents environnements, notamment sur des machines physiques, des machines virtuelles, des conteneurs Docker ou même dans des environnements cloud.

Chaque GitLab Runner peut être enregistré pour un projet, un groupe ou une instance GitLab ; tout dépend des besoins des utilisateurs. Les runners utilisent différents « exécuteurs » (executors) pour gérer les tâches, comme Docker, Shell, Kubernetes ou VirtualBox que nous présenterons à la section Comprendre la notion d’exécuteur....

Les trois types de GitLab Runners

Les runners peuvent être attribués de différentes manières pour exécuter les tâches des pipelines, mais cette organisation suit le même principe que les autres ressources dans GitLab, c’est-à-dire qu’elle se fait au niveau du projet, du groupe ou de l’instance.

Quel que soit leur type, les runners fonctionnent généralement selon le principe « premier arrivé, premier servi » (First In, First Out, FIFO), mais ce comportement peut être modifié par des configurations spécifiques comme les priorités des jobs ou des règles définies par les administrateurs. Voyons de plus près en quoi consistent les trois types de runners.

1. Les runners de projet

Les runners de projet, également appelé runners spécifiques, sont configurés pour être assignés à un projet particulier et ils n’exécutent que les tâches des pipelines de ce dernier. Ils sont isolés du reste de la plateforme, ce qui garantit qu’ils ne traiteront pas de tâches provenant d’autres projets.

Ce type de runner présente l’avantage d’offrir aux utilisateurs la possibilité de configurer et de gérer leur propre infrastructure de runners sans impacter le reste de la plateforme. Par exemple, un développeur peut installer...

Comprendre la notion d’exécuteur

Jusqu’à présent, nous avons vu que l’application GitLab planifie et coordonne les pipelines dont les travaux sont pris en charge par les runners. Ces derniers sont des processus gérés par un agent qui exécute les instructions définies dans le fichier .gitlab-ci.yml. Il nous reste maintenant à examiner le composant qui permet d’exécuter les tâches confiées aux runners : les exécuteurs.

Le rôle d’un exécuteur est de recevoir et traiter les tâches des pipelines, après quoi il retourne le résultat et l’état (réussite, échec ou autre) à GitLab.

Le concept d’exécuteur fait référence à l’environnement d’exécution qu’un processus de runner utilise pour traiter les tâches CI/CD reçues. Il doit être spécifié lors de l’enregistrement initial d’un nouveau runner dans GitLab. Comme nous l’avons indiqué plus haut, plusieurs processus de runner ayant chacun leur propre exécuteur peuvent être pris en charge à partir d’une seule machine ayant l’agent GitLab Runner d’installé.

1. Les types d’exécuteurs

En date de rédaction de cet ouvrage, GitLab supporte dix types d’exécuteurs dont les principaux sont : SSH, Shell, Parallels, VirtualBox, Docker, Docker Autoscaler, Docker Machine (auto-scaling) et Kubernetes. Vous pouvez aussi utiliser vos propres exécuteurs si vous avez des besoins spécifiques.

2. Les exécuteurs Docker

a. Docker Engine

Un runner qui utilise l’exécuteur Docker traite les tâches CI/CD dans des conteneurs lancés à partir d’une image Docker spécifiée dans le fichier .gitlabci.yml (comme nous l’avons vu avec le mot-clé image). Cet exécuteur fournit un environnement facilement reproductible qui contient les outils nécessaires pour prendre en charge les jobs définies dans un pipeline. L’utilisation de l’exécuteur Docker nécessite que Docker Engine soit installé sur la même machine que l’agent GitLab Runner.

Pour rappel, le Docker Engine est une plateforme qui permet de créer, gérer...

Comprendre la notion d’étiquette

Les étiquettes permettent de restreindre les GitLab Runners aux tâches spécifiques qu’ils peuvent exécuter. Ces tags sont attribués aux runners et associés aux jobs qui portent les mêmes étiquettes. Ces dernières peuvent indiquer la plateforme du runner ou les outils qu’il contient. Elles peuvent aussi désigner des étapes du processus CI/CD (« build », « test », « deploy »), un environnement de déploiement (« staging », « qa », « prod ») ou une plateforme d’exécution (« linux », « mac-os », « windows »).

1. Attribuer une étiquette à un runner

L’utilisation du mot-clé tags à un job CI/CD permet de s’assurer que le runner choisi dispose des outils nécessaires et d’un environnement adapté pour exécuter cette tâche spécifique. Par exemple, si une tâche requiert une version particulière de Python ou un système d’exploitation spécifique comme Linux, un runner portant le tag correspondant sera automatiquement sélectionné pour l’exécuter :

build-on-linux: 
  stage: build 
  script:...

Installer et enregistrer un GitLab Runner

Dans cette section, nous allons apprendre à installer un agent GitLab Runner sur un poste de travail Windows et l’enregistrer ensuite sur GitLab. L’avantage d’avoir un runner local est que cette approche vous permet d’exécuter vos pipelines sans utiliser les ressources de traitement des runners de la plateforme. Cette pratique vous donne la possibilité d’avoir un environnement de développement où vous pouvez faire vos tests avant de fusionner vos changements en production.

L’installation d’un runner se fait en quatre étapes :

créer un objet GitLab Runner sur la plateforme ;
récupérer les binaires d’installation ;
installer l’agent GitLab Runner ;
enregistrer le GitLab Runner sur la plateforme.

1. Installation sur un poste de travail Windows

Commençons par l’installation d’un agent GitLab Runner sur un poste Windows avec un exécuteur Shell, car il s’agit d’une solution simple et rapide qui ne nécessite pas la création d’une machine virtuelle. Nous pourrons ensuite en faire l’essai avec un exemple simple en PowerShell.

Si vous préférez créer un runner sur une machine Linux, les étapes sont les mêmes. Au lieu de le faire en PowerShell, vous utiliserez Bash et vous allez récupérer le binaire avec une commande curl qui vous sera fournie par GitLab.

Notons au passage que la procédure qui suit utilise la nouvelle méthode d’enregistrement d’un runner avec un jeton d’authentification (authentication token) au lieu d’un jeton d’enregistrement (registration token) dont la prise en charge est désormais obsolète. Ce changement a été introduit avec la version 15.6 des GitLab Runners pour simplifier et améliorer la sécurité du processus d’enregistrement.

a. Créer un nouveau runner de projet

Dans GitLab, créez un nouveau projet au besoin pour Windows et ouvrez les Paramètres du projet. Appuyez sur CI/CD et cliquez sur la section Runners. Sous Runners de projet, cliquez sur le bouton Nouvel runner de projet.

Sur la page Nouvel runner...

Sécurité et surveillance des GitLab Runners

Il y a deux points importants de sécurité qui découlent directement des choix effectués lors de l’installation et de la configuration des runners : l’exécuteur du runner et la gestion des secrets (informations sensibles ou confidentielles) dans vos pipelines CI/CD.

1. La sécurité et les exécuteurs

Le choix d’un exécuteur (runner) dans GitLab a un impact direct sur la sécurité du code source et de l’infrastructure sous-jacente. Chaque type d’exécuteur offre un niveau différent d’isolation et de protection, si bien qu’une configuration inadéquate peut entraîner des risques, comme des fuites de données ou des accès non autorisés aux ressources système. Voici quelques aspects à prendre en considération pour certains exécuteurs :

Exécuteur Shell : donne un accès direct au système de fichiers de la machine hôte, ce qui peut entraîner un partage ou une persistance involontaire de fichiers entre différentes tâches si le nettoyage n’est pas correctement configuré.

Si le runner est enregistré avec des privilèges élevés, il peut avoir un accès administrateur susceptible d’entraîner des risques de sécurité.

Exécuteur Docker : fournit une isolation grâce aux conteneurs, ce qui limite l’accès direct au système hôte. La sécurisation d’un exécuteur Docker doit tenir compte des deux points suivants :

Les conteneurs ne doivent pas être configurés en mode « privilégié »...

Optimiser la performance des GitLab Runners

Lorsque GitLab est utilisé par de nombreuses équipes et que les runners sont très sollicités, leur optimisation est essentielle pour maintenir leur performance et leur efficacité.

Plusieurs facteurs doivent être pris en considération, notamment la taille des dépôts, le type de runner utilisé, ainsi que la gestion des dépendances, qu’elles concernent les tâches des pipelines ou les applications elles-mêmes. Ces éléments jouent un rôle important pour assurer la fluidité de l’exécution des jobs et la rapidité des livraisons.

1. La taille et les modes de clonage d’un dépôt

Il est important de noter que des dépôts volumineux peuvent entraîner des limitations, notamment lors des opérations de clonage ou de traitement par un runner.

Pour réduire ces contraintes, les GitLab Runners intègrent des solutions d’optimisation comme la récupération incrémentale (incremental fetching) et le clonage Git superficiel (Git shallow clone).

a. Récupération incrémentale (incremental fetching)

Lorsqu’un dépôt est cloné pour la première fois dans un pipeline, GitLab effectue un clone complet du contenu. Par la suite, si la récupération incrémentale est activée, le runner utilise la commande git fetch pour récupérer uniquement les nouveaux commits qui ont été ajoutés depuis la dernière exécution. Cette approche permet d’éviter de cloner à nouveau l’ensemble des fichiers du dépôt Git pour chaque job.

Pour activer cette fonctionnalité, vous pouvez utiliser la variable GIT_STRATEGY au niveau global avec la valeur fetch dans le fichier .gitlab-ci.yml.

variables: 
  GIT_STRATEGY: fetch

Nous n’avons pas encore abordé le mot-clé variables que nous allons présenter dans le chapitre Aller plus loin avec les pipelines CI/CD. Retenez pour l’instant qu’il permet de définir des variables d’environnement pour les pipelines afin de personnaliser les jobs. Les variables peuvent être déclarées...

Conclusion

Dans ce chapitre, nous avons exploré le rôle des GitLab Runners dans les pipelines CI/CD et nous avons vu qu’ils peuvent être installés en tant que programmes autonomes sur diverses plateformes.

Les runners se déclinent en trois types principaux, chacun opérant à différents niveaux : projet, groupe ou instance. Cette hiérarchisation permet une gestion granulaire des tâches et des ressources au sein de l’écosystème GitLab.

Nous avons continué notre parcours en examinant les divers environnements d’exécution des runners que GitLab nomme des « exécuteurs » dont les principaux sont Docker, Shell, Kubernetes, VirtualBox et SSH.

Comprendre le fonctionnement des runners est une compétence essentielle pour apprendre à les configurer correctement et éviter des problèmes de performance dans les pipelines. N’hésitez pas à installer et enregistrer de nouveaux runners pour voir quelles plateformes d’exécution répondent le mieux à vos besoins.

Dans le chapitre Analyser et tester son code source, nous allons approfondir le volet intégration continue (CI) en ajoutant des tests et des analyses de code source à nos pipelines.