Configuration avancée des Runners GitLab via config.toml

Configuration des Runners (Executors & config.toml)

Comprendre le concept d'Executor

Lorsque vous enregistrez un GitLab Runner, la question la plus importante qui vous est posée est le choix de l'Executor (l'exécuteur). Le Runner n'est que le messager, l'Executor est l'environnement réel dans lequel votre code va s'exécuter.

Trois exécuteurs dominent le marché DevOps :

• Shell : Le code s'exécute directement sur la machine hôte du Runner. Très rapide, mais dangereux car les dépendances s'accumulent sur le serveur et les jobs peuvent interférer entre eux.
• Docker : L'exécuteur standard et incontournable. Chaque job démarre dans un conteneur vierge et isolé, garantissant que "ça marche sur ma machine ET sur le serveur".
• Kubernetes : Pour les infrastructures massives. Le Runner crée dynamiquement des "Pods" sur un cluster Kubernetes pour exécuter les jobs, offrant une scalabilité infinie.

Plongée dans le fichier config.toml

La véritable puissance d'un administrateur se trouve dans la configuration sous-jacente du Runner. Sous Linux, ce fichier se trouve généralement dans /etc/gitlab-runner/config.toml. C'est ici que vous définissez la capacité de charge de votre machine.

Augmenter la concurrence (Parallélisme)

Par défaut, un Runner n'exécute qu'un seul job à la fois. Si vous avez une machine puissante (ex: 8 cœurs, 32 Go de RAM), c'est un énorme gâchis. La variable globale concurrent permet d'augmenter cette limite.

# /etc/gitlab-runner/config.toml
concurrent = 4
check_interval = 3
log_level = "info"

[[runners]]
  name = "Docker-Runner-Production"
  url = "https://gitlab.com/"
  token = "glrt-XxYyZz1234"
  executor = "docker"
  [runners.docker]
    tls_verify = false
    image = "alpine:latest"
    privileged = false
    disable_entrypoint_overwrite = false
    oom_kill_disable = false
    disable_cache = false
    volumes = ["/cache"]
    shm_size = 0

Explication des paramètres critiques :

• concurrent = 4 : Ce Runner peut maintenant traiter jusqu'à 4 jobs de n'importe quel projet simultanément.
• check_interval = 3 : Le Runner demandera à GitLab s'il y a du nouveau travail toutes les 3 secondes.
• volumes = ["/cache"] : Indispensable pour que le système de cache (comme les dépendances Node.js ou Maven) persiste entre deux exécutions de conteneurs.

Le mode "Privileged" : Puissance et Danger

Dans la section [runners.docker], vous remarquerez le paramètre privileged = false. Si vous le passez à true, le conteneur exécutant votre job aura un accès quasi-complet au système hôte.

Appliquer les modifications

Contrairement à beaucoup de services Linux, il n'est pas toujours nécessaire de redémarrer brutalement le Runner après une modification du config.toml. Le processus lit le fichier régulièrement. Cependant, pour forcer la prise en compte immédiate, utilisez la commande :

sudo gitlab-runner restart

Conclusion

Maîtriser les Executors et le fichier de configuration config.toml vous permet de transformer une simple machine de calcul en une flotte de Runners taillés sur mesure pour votre architecture.

Maintenant que vos moteurs tournent à plein régime, il est temps d'écrire des partitions plus complexes. Dans le chapitre suivant, nous allons explorer les mots-clés avancés du fichier .gitlab-ci.yml.