Gitlab Runner - Installation et configuration sous OVH

Découvrez toutes les bests practices Smartbooster dans ce guide d'installation et de configuration de Runner Gitlab.

Nous détaillerons les étapes à suivre pour l'installer sur un serveur OVH et optimiser son fonctionnement pour lancer plusieurs pipelines en parallèle.

Qu'est-ce qu'un Gitlab Runner ?

Les Gitlab Runners sont des exécutables utilisés par Gitlab dans les processus d'intégration continue et/ou déploiement continue (aussi appelé CI/CD).

Techniquement leur rôle est de lancer le code définit dans les jobs des pipelines CI/CD : build de l'application, analyse de qualité de code, script de déploiement ou interaction avec un serveur.

Si vous utilisez Gitlab en mode Saas, des runners sont déjà mis à votre disposition, les GitLab Build Cloud runners. Ces runners sont automatiquement accessibles pour tous vos projets sur gitlab.com et partagés par l'ensemble des utilisateurs.

Il suffit de renseigner un tag dans la liste des Available shared runners sur votre job.

Cependant, si vous utilisez une instance Gitlab privée déployé sur un serveur, vous n'aurez pas accès à ces GitLab Build Cloud runners. Il est alors nécessaire d'installer et d'enregistrer vos propres runners sur votre instance Gitlab.

Nous vous proposons dans cet article notre installation sécurisée SmartBooster.

Quel serveur pour installer son Runner Gitlab ?

Comme tout processus web, les Gitlab Runner doivent être accessibles depuis internet pour être appelé par vos pipelines.

Les runners peuvent être installés sur des serveurs linux, windows ou même encore sur le poste d'un développeur.

Pour des raisons de sécurité et d'accessibilité, nous conseillons d'installer vos runners sur des petits serveurs isolés. Comme dans une approche Cloud, où il est important de cloisonner ses projets, nous faisons de même avec les runners pour garantir que leur exécution ne va pas perturber les environnements de recette ou de production des projets.

Chez SmartBooster, nous avons choisi d'héberger nos runners sur les serveurs OVH pour leur niveau de performance ainsi que leur localisation française garantissant un respect de la RGPD.

Nous partons sur la gamme Serveurs privés virtuels (VPS) car elle permet de répondre aux attentes suivantes :

• serveur sécurisé grâce à son système d'encapsulation
• bon rapport coût financier / performance (avec possibilité d'upscale facilement selon votre charge CI/CD)
• contrôle total du serveur pour paramétrer au mieux l'installation et la configuration de notre runner

Nous vous conseillons de prendre l'offre Essential (2 vCore + 4 Go) qui vous fournira une base suffisante en termes de spécifications techniques.

Une fois votre VPS sélectionné, vous pouvez mettre à jour son nom pour clairement l'identifier comme serveur responsable de vos runners :

Maintenant que nous avons notre serveur de disponible, il est temps de préparer le terrain pour l'arrivée de notre runner.

Comment sécuriser un Runner pour Gitlab ?

Comme énoncé plus haut, le serveur où se trouve votre runner va avoir des interactions avec votre instance Gitlab pendant les CI/CD.

Il est primordial de sécuriser l'accès à ce serveur. Personne d'extérieur à votre organisation ne doit pouvoir s'y connecter, car cela pourrait être un point d'entrée direct sur votre code (potentiellement récupérable dans les builds de vos pipelines).

Il faut donc mettre en place les préconisations de sécurité fournie par OVH pour les serveurs VPS.

Connectez-vous au VPS via les identifiants fournis par mail lors de la commande ssh nom_d_utilisateur@IPv4_de_votre_VPS

Mise à jour de la liste des paquets

## mise à jour de la liste des paquets
apt-get update
## mise à jour des paquets eux-mêmes
apt-get upgrade

Empécher l'accès SSH avec le port d’écoute par défaut

# Modifier le port d’écoute par défaut du service SSH
nano /etc/ssh/sshd_config
## Trouver la ligne du Port et mettre à jour son numéro
## Pour des raisons de sécurité, utilisez un nombre compris entre 49152 et 65535.
## ex : Port 51001
## Redémarrez le service sshd
systemctl restart sshd

Modification du mot de passe root

passwd
# renseigner le nouveau mot de passe et sa confirmation 
# stocker sa valeur dans un gestionnaire de mot de passe sécurisé (ex: Lastpass)

Accès rapide au VPS grâce au .ssh/config

adduser smartbooster
usermod -aG sudo smartbooster

# se déconnecter du serveur et uploader sa clé ssh
ssh-copy-id smartbooster@XX.XX.XX.XX

# mettez à jour votre .ssh/config pour vous connecter plus rapidement au server
Host runners
    Hostname XX.XX.XX.XX
    User smartbooster    
    IdentityFile ~/.ssh/id_rsa
    Port 51001

# maintenant vous pouvez directement faire ssh runners

Enlever la connexion root

nano /etc/ssh/sshd_config
# Localisez les options suivantes et mettre no :
PasswordAuthentication no
UsePAM no 
PermitRootLogin no

# puis redémarrer le service
systemctl restart sshd

Protection contre les intrusions

apt-get install fail2ban
cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.conf.backup
# ajuster si besoin les configs de fail2ban
## nano /etc/fail2ban/jail.conf
/etc/init.d/fail2ban restart

Installation du Gitlab Runner

Installation de Docker : notre piste de course

apt-get update
apt-get install \
    apt-transport-https \
    ca-certificates \
    curl \
    gnupg \
    lsb-release

curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /usr/share/keyrings/docker-archive-keyring.gpg

echo \
  "deb [arch=amd64 signed-by=/usr/share/keyrings/docker-archive-keyring.gpg] https://download.docker.com/linux/ubuntu \
  $(lsb_release -cs) stable" | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null

apt-get update
apt-get install docker-ce docker-ce-cli containerd.io

# Check que Docker fonctionne
docker run hello-world

# Ajout du user ssh au groupe docker
usermod -aG docker smartbooster

Téléchargement et configuration du Gitlab Runner

# Download the binary for ubuntu
curl -L --output /usr/local/bin/gitlab-runner https://gitlab-runner-downloads.s3.amazonaws.com/latest/binaries/gitlab-runner-linux-amd64

# Give it permissions to execute
chmod +x /usr/local/bin/gitlab-runner

# Create a GitLab CI user
useradd --comment 'GitLab Runner' --create-home gitlab-runner --shell /bin/bash

# Install and run as service
gitlab-runner start

# Ajout du user gitlab-runner au groupe docker
usermod -aG docker gitlab-runner

# Command to register runner
gitlab-runner register

Configurer la concurrence des jobs

https://docs.gitlab.com/runner/configuration/advanced-configuration.html

sudo nano /etc/gitlab-runner/config.toml
# changer la valeur de concurrent et sauvegarder

sudo gitlab-runner restart

Conclusion

Dans cet article nous avons abordé l'installation et la configuration d'un Gitlab Runner ainsi que la sécurisation de son accès sur OVH.

Nous utilisons Docker comme executor de nos runners. Cela nous permet de couvrir la partie CI de nos pipelines ainsi que la partie CD avec le déploiement chez notre hébergeur Clever Cloud, via leur image docker officielle.

Selon votre stack et votre workflow DevOps actuel, les executors et le nombre de runner dont vous avez besoin peuvent varier.

Nous pouvons vous accompagner dans cette mise en place des Gitlab Runners pour simplifier au maximum votre infrastructure et minimiser le temps de maintenance de ces derniers.

Nous espérons que cet article aura éclairci votre compréhension de la mise en place de runner sur Gitlab, sommes disponibles si vous avez d'autres questions.