Configurer un GitLab Runner auto-hébergé et publier des fichiers en SFTP

Parfois, on veut une petite configuration pour utiliser GitLab auto-hébergé avec un projet secondaire tout en gardant quelques fonctionnalités CI. Voyons comment publier ces fichiers via SFTP.

Quand j’ai voulu utiliser certaines fonctionnalités de versioning lors du développement de mon site web principal, j’ai naturellement utilisé GitLab. Mais GitLab ne s’arrête pas simplement à cette fonction, c’est une plateforme DevOps complète. Tant qu’à l’utiliser, pourquoi ne pas essayer d’utiliser un peu d’automatisation même si vous êtes seul à travailler sur votre projet.

Donc, parce que mon projet est petit et que, comme indiqué, je suis seul dessus, cet article doit être pris comme une introduction légère à la façon dont GitLab fonctionne avec son GitLab Runner. Je ne vais pas montrer comment faire de la compilation ni même des tests. Nous allons simplement voir comment GitLab utilise un fichier d’orchestration spécifique qui est automatiquement exécuté quand vous faites un git push vers une branche spécifique.

Comment cela fonctionne-t-il ?

GitLab, comme son nom le suggère, est une plateforme basée autour du protocole Git. Mais c’est bien plus que cela. C’est un système complet de développement collaboratif permettant à des équipes de travailler ensemble sur plusieurs projets. Il brille par son intégration des fonctionnalités CI/CD.

Qu’est-ce que la CI/CD ?

Cela signifie Continuous Integration et Continuous Delivery/Deployment (c’est soit delivery, soit deployment, pas les deux, car ils sont opposés comme vous allez le comprendre).

La Continuous Integration est la partie que vous connaissez peut-être déjà. C’est l’organisation en branches de code où les développeurs committent leurs changements et les fusionnent pour procéder à un commit complet vers la branche principale. C’est vraiment ce que Git apporte en plus du versioning, mais automatisé.

La Continuous Delivery est le concept qui consiste à compiler et tester automatiquement à chaque commit vers la branche principale. Une fois les tests terminés et les changements approuvés, le logiciel est prêt à être publié. Mais cela ne veut pas dire qu’il est effectivement publié, il est juste considéré comme prêt.

La Continuous Deployment est comme la Delivery mais, comme son nom l’implique, le logiciel est automatiquement déployé (ce que la delivery ne fait pas). L’ancienne révision est supprimée et la nouvelle est mise en place. Ce type d’organisation va vraiment de pair avec les microservices via conteneur.

Pour ce que nous voulons dans ce petit projet, c’est simplement un Continuous Deployment que nous allons mettre en place. En effet, nous voulons juste pousser automatiquement les fichiers de notre site web vers le SFTP lorsque nous committons des changements. Pas de tests, pas de compilation, pas de merge, etc.

En pratique

La façon dont GitLab exécute toute cette automatisation passe par un GitLab Runner. Ce runner est simplement une autre machine sur laquelle les commandes sont exécutées. Cela peut être un ordinateur complet ou simplement un conteneur, cela n’a pas vraiment d’importance tant que le système dispose du logiciel GitLab Runner installé et connecté à l’instance GitLab principale.

Les runners existent en trois variantes :

• Specific
• Group
• Shared

Je pense que les noms sont évidents mais expliquons-les quand même. Un specific runner sera dédié à un projet spécifique. C’est très bien pour un projet actif et intensif en calcul. Les group et shared runners sont partagés entre plusieurs projets, la différence entre les deux étant que les group runners exécuteront des tâches pour un groupe de projets, alors que les shared runners exécuteront des tâches pour n’importe quels projets configurés pour autoriser leur utilisation.

Pour envoyer ces commandes au runner, GitLab exécute des Jobs via des Pipelines. Un job est simplement une instance d’exécution d’un fichier de configuration contenant une recette qui indique au runner ce qu’il doit faire. Ce fichier de configuration porte le nom .gitlab-ci.yml et doit se trouver à la racine de votre projet git. Comme vous l’avez probablement deviné, le fichier est écrit en YAML. Le pipeline est l’ensemble complet des jobs créés par un fichier spécifique.

Comme nous voulons quelque chose de simple, je vais simplement mettre en place un shared runner. Je n’ai pas beaucoup de projets qui tournent sur mon GitLab et je suis seul à travailler dessus, donc c’est largement suffisant pour moi.

Mise en place du GitLab Runner

Tout d’abord, vous devez installer le logiciel GitLab Runner. Je ne vais pas expliquer comment faire cela parce que la documentation GitLab le fait déjà très bien. Je vous encourage donc à la consulter. Dans mon cas, j’ai installé Docker avant le runner parce que je vais l’utiliser dans mon automatisation. Je l’ai installé dans un conteneur LXC non privilégié sur mon serveur Proxmox parce que c’était la solution la plus rapide et la plus simple pour moi.

Pendant le processus d’installation, une liste d’executors vous sera présentée et il vous sera demandé lequel choisir. Si vous voulez utiliser ma configuration comme base, vous aurez besoin de Docker installé et de le choisir quand cela vous sera demandé.

Est-ce installé chez vous ? Bien, il est maintenant temps d’aller dans le panneau d’administration de votre instance GitLab principale. Pour y accéder, allez dans Menu > Admin.

Vous devez être connecté avec un utilisateur ayant des droits d’administration sur votre GitLab pour que l’option soit disponible.

Une fois là, sous Overview, il y a la page d’administration Runners.

Cliquez sur Register an instance runner puis sur Show runner installation and registration instructions.

Une fenêtre pop-up Install a runner vous sera présentée. Vous pourrez récupérer les informations nécessaires pour enregistrer votre runner nouvellement installé.

Si vous avez déjà installé le logiciel GitLab Runner comme je vous ai dit de le faire, il vous suffit de regarder le bon environnement (évidemment) et de copier la commande située en bas. Cette commande doit être exécutée sur la machine du runner elle-même.

Une fois cela fait, il apparaîtra dans votre instance GitLab avec le statut online. Par défaut, ils sont configurés comme shared, donc nous n’avons rien de plus à faire sur ce point.

Configuration de la CI/CD

Avant de commencer

Nous devons d’abord activer le projet pour qu’il utilise le runner. Pour le configurer, votre utilisateur doit avoir le rôle maintainer ou owner sur le projet cible, les autres rôles ne peuvent pas modifier les paramètres d’un projet.

Donc, allez dans votre instance GitLab, ouvrez votre projet puis allez dans Settings \> CI/CD. Il y a une section appelée Runners qui est repliée par défaut. Cliquez sur Expand. Assurez-vous, dans la colonne de droite, sous la section Shared runners, que Enable Shared runners for this project est activé (comme dans la capture ci-dessous).

Maintenant, les fondations sont posées pour utiliser cette fonction.

Création du fichier de configuration

Ce fichier contient toutes les commandes pour le runner. Il est écrit en YAML et utilise une structure spécifique. Si vous avez déjà joué avec Docker par le passé, vous serez dans un environnement familier. Surtout parce que nous utilisons Docker dans cet exemple.

Vous devez le créer dans le dossier racine de votre projet git. Le nom du fichier doit être .gitlab-ci.yml. Maintenant, chaque fois que vous poussez votre commit, GitLab analysera le fichier et agira en fonction de ce qu’il contient.

Envoi des fichiers via SFTP

Ce que nous voulons faire est vraiment simple comparé à ce dont un studio de développement aurait besoin. Mais ce sera une bonne introduction à la façon d’utiliser ce fichier avec des variables d’environnement définies via GitLab.

Comme nous utilisons Docker, nous pourrions voir ce fichier comme un mélange entre un fichier Docker Compose et un Dockerfile. De cette façon, nous pouvons rassembler le type d’informations nécessaires pour créer ce fichier correctement.

Premièrement, quelle image de base utiliser ? Je vais utiliser Alpine Linux, une petite distribution légère optimisée pour ce type d’environnement.

Deuxièmement, quelles commandes voulons-nous exécuter pour transférer les fichiers ? La méthode la plus simple consiste à utiliser un logiciel appelé LFTP qui peut gérer tout le transfert via une seule ligne de commande. Pour le protocole, nous utiliserons SFTP parce qu’il utilise SSH, qui est déjà disponible sur mon serveur web de test, et je ne veux pas configurer un serveur FTP complet juste pour tester. Parfois, les hébergeurs peuvent limiter l’accès uniquement au SFTP, donc cela pourrait vous être utile.

Tout le processus de choix et d’itération des tests pour finalement trouver le script complet a été assez bien couvert par 't is goud, je vous encourage à le consulter.

Commandes

apk add --no-cache openssh lftp
mkdir /root/.ssh
chmod 700 /root/.ssh
touch /root/.ssh/known_hosts
chmod 600 /root/.ssh/known_hosts
ssh-keyscan -p $SFTP_PORT -H $SFTP_HOST >> /root/.ssh/known_hosts
lftp -e "mirror --delete --parallel=5 --transfer-all --reverse -X .* --verbose website/ /var/www/html; bye" -u $SFTP_USER,$SFTP_PASSWORD sftp://$SFTP_HOST -p $SFTP_PORT

Comme vous pouvez le voir, nous utilisons des variables, nous verrons plus tard comment les créer.

La première ligne est une commande utilisée pour installer OpenSSH afin d’obtenir la compatibilité SFTP côté local et LFTP pour des raisons évidentes.

Les 4 commandes suivantes sont utilisées pour créer le fichier known_hosts parce que ssh-keyscan ne peut pas le créer lui-même dans ce contexte.

SSH-Keyscan est utilisé pour collecter les informations du serveur ssh et les placer dans le fichier known_hosts. Maintenant, il n’est plus nécessaire d’approuver la clé lors de la première connexion au serveur ssh.

LFTP fera tous les transferts. Il utilise différents paramètres :

• -e " " Commande(s) à exécuter - Elles sont placées entre les guillemets doubles
• mirror Miroir du dossier distant sur le dossier local
• --delete Supprime les fichiers et dossiers dans la destination qui ne sont pas présents dans la source
• --parallel=n Nombre N de transferts à exécuter en parallèle
• --transfer-all Force le transfert de tous les fichiers même s’ils existent déjà dans la destination
• --reverse Inverse le dossier source et le dossier de destination - le distant est maintenant la destination
• -X Ignore les fichiers correspondants
• --verbose Affiche toutes les actions exécutées
• source/folder destination/folder Évidemment, l’emplacement des dossiers source et destination
• bye Quitte la commande
• -u USER,PWD Spécifie l’utilisateur et le mot de passe pour se connecter
• sftp://host Adresse SFTP à laquelle se connecter
• -p PORT Port à utiliser pour la connexion

Fichier complet

Décomposons le fichier complet.

image: alpine:latest
before_script:
  - apk add --no-cache openssh lftp
  
build:  
  script:
    - mkdir /root/.ssh
    - chmod 700 /root/.ssh
    - touch /root/.ssh/known_hosts
    - chmod 600 /root/.ssh/known_hosts
    - ssh-keyscan -p $SFTP_PORT -H $SFTP_HOST >> /root/.ssh/known_hosts
    - lftp -e "mirror --delete --parallel=5 --transfer-all --reverse -X .* --verbose website/ /var/www/html; bye" -u $SFTP_USER,$SFTP_PASSWORD sftp://$SFTP_HOST -p $SFTP_PORT
  only:
    - main

Comme vous pouvez le voir, les commandes sont séparées en deux sections et quelques autres lignes sont ajoutées.

La première ligne est l’image que nous avons choisie. J’utilise alpine avec le tag :latest. Vous devriez utiliser une version fixe en production.

N’UTILISEZ PAS LATEST EN PRODUCTION !!! JUSTE POUR LES TESTS

La section before_script contient la commande pour préparer l’image avant son utilisation. Bien sûr, la partie installation du logiciel y est effectuée.

La section build contient ce que je décrirais comme la partie intéressante sur le plan calculatoire. Elle est appelée build parce que c’est dans cette partie que vous feriez le processus de compilation.

Elle contient la section script, c’est assez évident ce que cette partie fait, ce sont toutes les commandes pour construire le logiciel.

Elle contient aussi la section only. Vous y définirez dans quelle branche le commit entraînera l’exécution du job. Dans cet exemple, à chaque commit vers la branche main, le job est exécuté.

Variables

Maintenant, la dernière partie pour finaliser notre configuration de GitLab. Les variables !

Donc, allez dans votre instance GitLab, ouvrez votre projet puis allez dans Settings \> CI/CD. Il y a une section appelée Variables qui est repliée par défaut. Cliquez sur Expand.

Il suffit de cliquer sur Add Variables, d’entrer le nom de la variable dans Key, puis de mettre les données que nous voulons transmettre dans Value et enfin de cliquer sur Add Variable.

Le nom dans key est ce qui sera utilisé dans le script précédé par $.

Cochez Mask variable pour la variable de mot de passe.

Dans cet exemple, nous avons besoin :

• de l’adresse du serveur (SFTP_HOST)
• du port utilisé par SFTP (SFTP_PORT)
• de l’utilisateur utilisé pour la connexion (SFTP_USER)
• du mot de passe de l’utilisateur (SFTP_PASSWORD)

Commit !

Maintenant, tout est prêt. Au prochain commit vers la bonne branche, vous pourrez voir les jobs s’exécuter dans la page CI/CD de votre projet.

Si vous cliquez sur le statut du pipeline, vous pourrez obtenir plus d’informations.

Ensuite, si vous cliquez sur le bouton du bas portant le nom de la section de notre fichier YAML, vous obtiendrez la sortie du job.

C’est tout ! Si vous avez des questions ou des commentaires, n’hésitez pas à me contacter. Maintenant, il est temps de commencer à développer avec un peu moins de tracas !