GitLab CI/CD : comment installer et utiliser un runner

Dans ce tutoriel, je vais vous expliquer comment ajouter un Runner Gitlab afin d’automatiser des actions lors d’un commit sur dépôt.

Toutes la puissance du CI/CD est l’automatisation de tâche lors d’un commit sur un dépôt, cette automatisation se fait l’aide de runner sur GItlab qui sont dédié à ça, il peut être sous Linux ou sous Windows en fonction de vos besoins.

Exemple d’automatisation :

• Lors de la modification d’un Dockerfile, compilation de l’image et envoie vers un registry
• Signature de script PowerShell
• Déploiement de virtualhost sur Nginx
• …

La principale limitation sera votre imagination et aussi un peu la technique car ce n’est pas toujours facile …

Prérequis

Le seul prérequis ici, va être d’avoir une installation de Gitlab fonctionnel, si vous n’en avez pas encore, vous pouvez suivre ce tutoriel : Gitlab : installation avec Docker et docker compose

Déployer un runner avec Docker

Pour faire simple, on va modifier le fichier docker-compose.yml existant pour ajouter un runner à l’installation de Gitlab.

Editer le fichier et ajouter le service :

Télécharger l’image du runner :

sudo docker compose pull

Redémarrer Gitlab et démarrer le runner :

sudo docker compose down && sudo docker compose up -d

Si on regarde dans les logs avec le commande sudo docker compose logs -f on peut voir des erreurs au niveau du Runner ce qui est normal car celui-ci n’est pas encore configuré.

Notre runner est prêt.

Déclarer le runner dans Gitlab et configurer le runner

La première étape avant de configurer notre runner, va être de le déclarer dans Gitlab afin d’avoir son token.

Depuis l’interface Web de Gitlab, cliquer sur Admin 1.

Dans le menu, aller sur CI/CD 1 et cliquer sur Runners 2.

On arrive sur la liste des Runners configurés, celle-ci est vide pour le moment, cliquer sur le bouton New instance runner 1.

Cocher la case : Run untagged jobs 1 puis cliquer sur le bouton Create runner 2.

Sélectionner l’OS (Linux) 1, dans la section Step, copier le token 2.

Retourner en SSH dans le dossier où se trouve le fichier docker-compose.yml et entrer la commande suivante pour configurer le runner :

sudo docker compose exec gitlab-runner gitlab-runner register --non-interactive --url "https://git.domain.tld/" --token "glrt-t1_XXXXXXXXXXXXX" --executor "docker" --docker-image "docker:latest" --description "Docker Runner"

Ici on configure le runner en indiquant, l’URL du Gitlab, le Token et le type, ici un Docker qui va nous permettre de construire des images depuis un Dockerfile par exemple.

Cette commande va aussi créer le fichier de configuration du Runner config.toml

Retourner sur l’interface Web de Gitlan, vous devriez avoir un notification qui indique que le Runner a été créé, cliquer sur le bouton View runners 1.

Dans la liste, nous avons maintenant le runner de visible et en cliquant dessus on accède aux détails.

Pour finir, comme nous sommes dans conteneur, il faut ajuster la configuration du Runner pour qu’il accède au service de l’hôte Docker.

Editer le fichier config.toml

sudo nano runner/config.toml

Passer le paramètre privileged à true et dans volumes, ajouter l’accès au socket docker /var/run/docker.sock:/var/run/docker.sock.

Redémarrer le Runner :

sudo docker compose restart gitlab-runner

Nous en avons terminé avec la configuration du Runner.

Construire une image Docker et l’envoyer sur Docker Hub avec un Runner Gitlab

Pour vous montrez le fonctionne d’un Runner Gitlab et vous faire une démo, je vais vous montrer comment construire un image automatiquement lors d’un commit quand un fichier Dockerfile est présent et envoyer celui-ci sur Docker Hub.

Le dépôt se trouve ici : https://git.rdr-it.com/root/runner-demo

Créer un nouveau dépôt

Pour commencer, j’ai créé un dépôt (repository) runner-demo depuis mon espace sur dockerhub.

Sur Gitlab, je vais également créer un Projet que je vais nommer : runner-demo.

Par défaut l’Auto DevOps est activé sur les projets, Gitlab va tenter de faire des actions automatiquement sans instructions quand il rencontre certain type de fichier comme par exemple un fichier Dockerfile. Cliquer sur le bouton Settings.

Décocher la case Default to Auto DevOps pipeline 1 et cliquer sur Save Changes 2.

Ajout de variable pour l’authentification au registry

Dans notre pipeline qui va être l’exécution automatique, on va souhaiter envoyer l’image générée sur un registry (dépôt), pour utiliser la commande docker push, il est souvent nécessaire d’être authentifié, pour éviter d’avoir à écrire identifiant et mot de passe en clair de le fichier de configuration de l’action automatique, on va ajouter ceci dans des variables au niveau du projet.

Danger

Ne jamais mettre d’identifiant dans des fichiers d’un dépôt Git car si celui-ci est public, ils seront visible par tout le monde.

Dans le projet, cliquer sur Code 1 puis CI/CD 2.

Aller à la section Variables 1 puis cliquer sur Add variable 2.

Dans le champ Key 1 entrer le nom de la variable puis dans le champ Value 2> la valeur et cliquer sur Add variable 3.

Une fois ajoutée, refaire l’opération pour la variable qui va contenir le mot de passe.

Ajout d’un fichier Dockerfile

Pour commencer, je vais ajouter un Dockerfile qui va contenir le « code » de compilation de mon image.

Ajout du fichier .gitlab-ci.yml

Nous allons passer au fichier le plus important de ce tutoriel, qui est le fichier .gitlan-ci.yml, car celui va contenir toutes les informations avec que le Runner exécute l’action automatique (pipeline).

Sur le dépôt commencer par créer un nouveau fichier .gitlab-ci.yml et coller le contenu suivant :

Ce fichier de définition d’un job GitLab CI/CD nommé build. Il est exécuté lors de la phase build du pipeline, en utilisant l’image Docker officielle. Le service docker:dind (Docker-in-Docker) est activé pour permettre la création d’images Docker à l’intérieur du job. Quelques variables sont définies pour configurer le nom et le tag de l’image. Avant l’exécution, le job installe le client Docker, affiche les infos Docker et se connecte au registre Docker Hub à l’aide de variables d’environnement ($CI_HUB_DOCKER_LOGIN et $CI_HUB_DOCKER_PASSWORD). Ensuite, il construit l’image avec deux tags : latest et un tag basé sur la branche ou le tag Git. Enfin, il pousse l’image vers Docker Hub. Ce job ne s’exécute que sur la branche main ou lorsqu’un tag est présent.

Nous avons ajouter le fichier qui va construire l’image Docker automatiquement.

Tester le pipeline

Pour déclencher le pipeline, il vous suffit de modifier le fichier Dockerfile et de commit le fichier.

Vous pouvez voir le déclenchement du pipeline avec un rond bleu qui s’affiche, en cliquant dessus, vous aurez accès aux détails.

On peut suivre les logs en directe du pipeline et vérifier que tout se passe bien.

On peut voir que les images ont été poussées sur le registre du docker hub.

Conclusion

A la base bien que prévu pour les DevOps et non les AdminSys, Gitlab et les Runners sont un outils dispensable pour les AdminSys car nous pouvons utiliser Gitlab et les Runners au quotidien.

A commencer par compilation d’image Docker, cela nous évite d’avoir à passer les commandes soit même et la centralisation sur Gitlab permet à l’équipe Sys de tous être au même niveau.

A titre perso, j’utilise les Runners dans Gitlab :

• Signer tous les scripts PowerShell automatique
• Centralisation des fichiers Bind9
• Centralisation des fichiers de configuration de Nginx et pipeline de test (nginx -t) avant de pousser les fichiers en prod
• Construction d’image Docker
• …

J’espère que ce tutoriel vous aura donné envie d’utiliser GItlab et les Runners.