Configurer les GitLab Runners : Le moteur de vos automatisations
Le moteur de vos automatisations
Un GitLab Runner est une instance d'exécution qui traite les tâches (jobs) envoyées par GitLab. Comme nous l'avons vu précédemment, GitLab est le "cerveau" qui stocke le code et les Runners sont les bras qui compilent, testent et déploient vos applications.
De nos jours, la flexibilité est totale : vous pouvez installer des Runners sur vos propres serveurs (Ubuntu), sur des machines Windows, ou utiliser des instances éphémères dans le cloud. Une fois installé, un Runner doit être enregistré auprès de votre instance GitLab pour commencer à travailler.
Information importante
Pour rappel, nous avons déjà configuré les Runners lors de la mise en place initiale de notre environnement GitLab. Si vous n'avez pas encore effectué cette installation ou si votre Runner n'est pas actif, je vous invite à revenir sur les chapitres précédents pour finaliser cette étape avant de poursuivre.
Types de Runners : Partagés vs Spécifiques
Selon vos besoins techniques et de sécurité, vous pouvez choisir entre deux grandes catégories de Runners.
Les Runners Partagés (Shared Runners)
Ces machines sont disponibles pour tous les projets de votre instance GitLab. Ils sont parfaits pour les tâches génériques (tests unitaires, analyse de code) qui ne nécessitent pas de configuration matérielle particulière. Ils permettent de centraliser la maintenance : une seule mise à jour du Runner profite à toute l'équipe.
Les Runners Spécifiques (Specific Runners)
Ils sont dédiés à un seul projet. C'est le choix idéal si votre application nécessite des dépendances lourdes, un accès matériel spécifique (GPU) ou des clés de sécurité que vous ne souhaitez pas partager. Ils fonctionnent sur le principe FIFO (First In, First Out) : le premier job arrivé est le premier servi.
Vérifier l'état d'un Runner enregistré
Information
Ces commandes de diagnostic doivent être tapées directement sur la machine physique (ou virtuelle) qui héberge le Runner, et non sur votre serveur GitLab principal.
Pour vous assurer que le service est bien actif et prêt à recevoir des ordres, utilisez la commande suivante :
gitlab-runner statusRésultat :
Runtime platform arch=amd64 os=linux pid=4521 revision=de7731d1 version=17.10.0
gitlab-runner: Service is runningSi vous voulez voir tous les exécuteurs enregistrés sur cette machine spécifique, listez-les avec :
gitlab-runner listRésultat :
Listing configured runners ConfigFile=/etc/gitlab-runner/config.toml
Runner-Production-01 Executor=docker Token=glrt-tXy87PaL URL=https://gitlab.example.comLe conseil du SysAdmin
Si le statut affiche Service is running, cela signifie que votre "ouvrier" est bien réveillé. Si vous voulez vérifier s'il est bien connecté au "cerveau", c'est dans l'interface web de GitLab (Settings > CI/CD > Runners) qu'il faudra regarder si la pastille est verte.
Verrouiller un Runner spécifique
Pour éviter qu'un Runner dédié ne soit activé par erreur sur d'autres projets, vous pouvez le "verrouiller".
Rendez-vous dans votre projet, puis dans Settings > CI/CD. Dépliez la section Runners. Vous y verrez vos Runners activés. Cliquez sur l'icône du crayon (éditer) à côté du Runner concerné.
Sur l'écran de configuration, cochez l'option Lock to current projects et validez avec Save changes. Ce Runner ne pourra désormais plus être assigné à un autre dépôt sans une action manuelle de votre part.
Sécurité : Les Runners Protégés (Protected)
De nos jours, la sécurité des déploiements est prioritaire. Un Runner Protégé ne peut exécuter des jobs que sur des branches elles-mêmes protégées, comme la branche main.
C'est une protection cruciale : cela empêche un utilisateur malveillant de créer une branche de test pour tenter d'extraire des secrets de production (mots de passe, clés d'API) via le Runner. Pour l'activer, suivez la même procédure d'édition que pour le verrouillage et cochez Protected.
"Un Runner protégé est le gardien de votre branche main"
Qu'est-ce qu'une branche protégée ?
Par défaut, n'importe quel utilisateur ayant le rôle Developer peut pousser du code ou supprimer une branche sur un dépôt. Dans un contexte professionnel, laisser la branche principale (souvent main) sans surveillance est un risque majeur pour la stabilité de la production.
Une branche protégée est une branche sur laquelle GitLab applique des restrictions de sécurité strictes. Elle permet de garantir que :
- Le Push direct est interdit : Personne ne peut envoyer de code directement sur la branche sans passer par une Merge Request validée.
- La suppression est impossible : Même par erreur, la branche ne peut pas être effacée du serveur.
- Le contrôle des fusions : Seuls les utilisateurs ayant le rôle Maintainer (ou des rôles spécifiques autorisés) peuvent valider l'intégration du code.
Comment activer la protection d'une branche ?
GitLab protège généralement la branche par défaut lors de la création du projet, mais vous pouvez configurer ces règles manuellement :
- Rendez-vous dans votre projet GitLab.
- Dans le menu latéral gauche, allez dans Settings > Repository.
- Cherchez la section Protected branches et cliquez sur le bouton Expand.
- Sélectionnez la branche à protéger (ex: main ou develop).
- Définissez qui a le droit de Merge et qui a le droit de Push.
- Cliquez sur le bouton Protect pour valider.
"Activer les branches protégées"
Configurer et utiliser les Tags GitLab Runners
Pourquoi utiliser des Tags ?
Dans une infrastructure DevOps complète, vous disposez souvent de plusieurs Runners avec des capacités différentes. Les Tags (étiquettes) sont le mécanisme qui permet de faire correspondre un job spécifique avec le Runner le plus adapté.
Sans tags, GitLab envoie les jobs au premier Runner disponible qui accepte les jobs sans étiquette, ce qui peut mener à des échecs.
Comment configurer des Tags sur un Runner ?
La gestion des tags a radicalement changé. Elle se fait désormais en amont, directement depuis l'interface web de GitLab, avant d'enregistrer physiquement votre machine :
-
Création du Runner sur GitLab :
- Allez dans Settings > CI/CD > Runners.
- Cliquez sur le bouton bleu New project runner.
- Dans la section Tags, saisissez vos mots-clés (ex: docker, linux).
- Cochez éventuellement Run untagged jobs si vous voulez qu'il accepte aussi les tâches sans étiquette.
- Cliquez sur Create runner.
- Enregistrement sur votre machine : GitLab vous fournira alors une commande toute prête avec un jeton (token). Copiez-la et collez-la dans le terminal de votre serveur (ou PC Windows). Les tags définis à l'étape 1 y seront automatiquement rattachés.
Information
Pour rappel, nous avons déjà effectué cette procédure lors de l'installation initiale au début de ce cours. Si votre Runner est déjà en ligne, vous pouvez modifier ses tags à tout moment en cliquant sur l'icône du crayon dans la liste de vos Runners sur GitLab.
Comment utiliser les Tags dans votre pipeline ?
Une fois vos Runners étiquetés, vous devez indiquer à votre fichier .gitlab-ci.yml quel Runner utiliser pour chaque job grâce au mot-clé tags.
Exemple de configuration YAML :
stages:
- test
- deploy
job_linux:
stage: test
tags:
- docker # Ce job cherchera un Runner possédant le tag "docker"
script:
- echo "Exécution sur Linux Docker"
job_windows:
stage: test
tags:
- windows # Ce job attendra qu'un Runner Windows soit disponible
script:
- echo "Exécution sur serveur Windows"Règle de sélection
Pour qu'un Runner accepte un job, il doit posséder tous les tags listés dans le job. Si vous mettez les tags "docker" et "linux", un Runner qui n'a que le tag "docker" ignorera la tâche.
Gérer les jobs sans étiquettes (Untagged)
Par défaut, les jobs dans votre fichier .gitlab-ci.yml peuvent utiliser des tags pour cibler un Runner précis. Mais que faire si un job n'a pas de tag ?
Vous pouvez configurer un Runner pour qu'il accepte de prendre en charge ces jobs "orphelins". Dans l'écran d'édition du Runner, cochez l'option Run untagged jobs.
"Utile pour s'assurer que tous les petits jobs de test sont bien exécutés"
Le conseil du SysAdmin
Il est recommandé de toujours utiliser des Tags pour vos Runners. Cela permet de piloter précisément quel environnement de travail est utilisé pour chaque étape de votre pipeline.
Conclusion
La configuration des Runners est le dernier maillon technique pour rendre votre forge logicielle totalement autonome. Vous savez maintenant isoler vos ressources, sécuriser vos déploiements sur main et gérer la distribution des tâches.
De plus, l'utilisation rigoureuse des Tags est une pratique de "Clean CI". Elle garantit que chaque tâche s'exécute dans l'environnement prévu.
Votre infrastructure est prête. Dans le prochain chapitre, nous allons voir comment passer à la vitesse supérieure avec les usages avancés de GitLab CI.
Espace commentaire
Écrire un commentaire
Rejoignez la discussion
Vous devez être connecté pour poster un message.
15 commentaires
Concept des Shared vs Specific Runners, trop pertinent. On est passés aux Specific Runners pour toutes nos APIs critiques qui dépendent d'une version spécifique de JDK et qui ont besoin de leur propre mémoire allouée. La garantie FIFO est vitale pour le latency budget.
J'ai vu ce pattern avec nos vieux projets Java et l'approche dédiée (Specific) a vraiment réduit les flakiness lors des tests de performance.
Par contre, il faut gérer le resource cleanup : un Runner dédié qui crashe, ça peut bloquer le pipeline pour tout le monde si le mécanisme de reap n'est pas parfait.
⚠️ Attention sur la distinction Shared/Specific. Si le job ne demande rien de spécifique (juste
npm cietjest), un Shared Runner fera l'affaire 99% du temps. L'over-engineering des Specific Runners, ça coûte cher en maintenance.On a mis en place nos Specific Runners sur des machines avec accès GPU (NVIDIA). Sans ça, les tests ML/AI sont des cauchemars de timeout. Le confinement est un plus sécurité, surtout quand on touche à des librairies externes non maîtrisées.
Super rappel sur la commande
gitlab-runner status. C'est le diagnostic de base.Mais l'info de l'interface web (pastille verte) reste le single source of truth. C'est ce qui nous dit si l'enregistrement auprès de GitLab a réussi, même si le service est
runninglocalement.Le principe FIFO pour les Specific Runners est bien expliqué. Ça sécurise l'accès, mais attention à ne pas throttler volontairement les pipelines ! Si vous avez un flux de jobs très lourd, la queue de Specific Runners peut devenir un point de contention majeur.
Avez-vous considéré le
docker executoravancé ? On utilise des images customisées pour injecter des dépendances système spécifiques (e.g., unbuild-essentialprécis, ou des bibliothèqueslibstdc++versionnées) au lieu de se fier aux images de base des Runners.Je valide l'approche des
docker executorpour la flexibilité matérielle. Ça nous a permis d'isoler totalement les environnements.Petite question : si je configure un
restart policyspécifique au niveau du service OS, est-ce que ça va entrer en conflit avec la logique de lifecycle management intégrée àgitlab-runnerlui-même ?Le 'Conseil du SysAdmin' est gold. On oublie trop souvent qu'un service OS étant 'running' n'équivaut pas à 'registered et operational' dans l'instance GitLab. Vraiment crucial de vérifier les deux endroits.
Confirmer que la commande
gitlab-runner listdoit être faite sur la machine et non sur le client SSH, sinon tout le monde va bugger. Petit détail, mais critique en contexte de troubleshooting.Le verrouillage (locking) des Runners spécifiques est une bonne pratique DevSecOps. Ça empêche les job rogue de contourner l'environnement sécurisé que vous avez mis en place (ex: accès aux secrets de production).
J'ai dû passer par là il y a deux ans. Le piège, c'est d'oublier de synchroniser la configuration TOML. Si on change le
tagsou l'executorlocalement, ça ne se répercute pas automatiquement sur le fichier de configuration global.Pour les Runners qui doivent se connecter à des systèmes ultra-critiques, on ajoute un layer de vérification par certificate et on désactive toute communication HTTP/S simple. On passe en mTLS pour le handshake du Runner.
Les Runners dédiés qui gèrent des données sensibles doivent absolument être sur un réseau isolé et ne communiquer qu'avec les endpoints nécessaires. Le Shared Runner ne doit jamais avoir de droits de débogage sur la production.
Si on parle de performance, l'optimisation du
builddans le job lui-même (cache de dépendances, parallélisation des tests) aura toujours plus d'impact que de passer de Shared à Specific Runner. C'est la règle d'or CI.