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.

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é

Pour vous assurer que le service est bien actif et prêt à recevoir des ordres, utilisez la commande suivante :

gitlab-runner status

Résultat :

Runtime platform                                    arch=amd64 os=linux pid=4521 revision=de7731d1 version=17.10.0
gitlab-runner: Service is running

Si vous voulez voir tous les exécuteurs enregistrés sur cette machine spécifique, listez-les avec :

gitlab-runner list

Résultat :

Listing configured runners                          ConfigFile=/etc/gitlab-runner/config.toml
Runner-Production-01                                Executor=docker Token=glrt-tXy87PaL URL=https://gitlab.example.com

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 :

1. Rendez-vous dans votre projet GitLab.
2. Dans le menu latéral gauche, allez dans Settings > Repository.
3. Cherchez la section Protected branches et cliquez sur le bouton Expand.
4. Sélectionnez la branche à protéger (ex: main ou develop).
5. Définissez qui a le droit de Merge et qui a le droit de Push.
6. 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 :

1. 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.
2. 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.

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"

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"

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.