Découvrez toutes les bests practices SmartBooster dans ce guide d’installation et de configuration de Runner Gitlab sur un hébergement OVH.
Nous détaillerons les étapes à suivre pour l’installer les outils sur un serveur OVH et optimiser son fonctionnement pour lancer plusieurs pipelines en parallèle.
Mise à jour du 30 Avril 2026 : L’article a été mise à jour pour prendre en compte les nouvelles commandes de la dernière version d’Ubuntu 25.04 cela comprend :
- la nouvelle offre des VPS OVH pour 2026
- la nouvelle manière de modifier le port d’écoute SSH sur version Ubuntu 24.04 et supérieur
- le process pour déposer sa clé ssh a été remplacer de ssh-copy-id par la création du authorized_keys pour plus de stabilité
- les commandes d’install Docker et Gitlab Runner avec l’ajustement des repositories officiels
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).
Nous avons rédigé un article complet pour vous expliquer Comment déployer votre code plus rapidement avec Gitlab CI !
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.
Vous pouvez soit laisser vide ou bien 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 tiers VPS-2 (6 vCore & 12 Go de RAM) qui vous fournira une solution suffisante en termes de spécifications techniques
Cette offre 2026 affiche des performance jusqu’à 30% plus rapide comparé à son homologue l’offre Essential 2 datant de 2021. Plus de détail dans notre comparatif de performances dans la suite de l’article.
Vos fidèles runners vont vous suivrent pendant de nombreuses années. Il sera important de suivre les mises à jour de l’OS, à l’heure actuelle Ubuntu 25.04, pour garantir que tous les derniers patchs de sécurité soient appliqués.
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
Toutes les commandes doivent être exécutées dans un contexte root. Pour cela, effectuer un sudo su une fois connecté sur votre serveur.
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 upgradeEmpécher l’accès SSH avec le port d’écoute par défaut
Ancienne façon de faire pour Ubuntu antérieur à 24.04
# 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 sshdPour Ubuntu 24.04 et versions ultérieures
Pour les dernières versions d’Ubuntu, la configuration SSH est désormais gérée dans le fichier ssh.socket.
Pour mettre à jour le port SSH, éditez la ligne ListenStream dans le fichier ssh.socket avec la commande suivante :
sudo nano /lib/systemd/system/ssh.socketVotre fichier ressemblera aux exemples suivants, en fonction de la version d’Ubuntu installé :
[Socket]
## Remplacer la valeur par un nombre compris entre 49152 et 65535.
ListenStream=49152
Accept=noou
[Socket]
## Remplacer la valeur par un nombre compris entre 49152 et 65535.
ListenStream=0.0.0.0:49152
ListenStream=[::]:22
BindIPv6Only=ipv6-only
Accept=no
FreeBind=yesEnregistrez vos modifications et exécutez les commandes suivantes :
sudo systemctl daemon-reload
sudo systemctl restart ssh.socketConserver la valeur du nouveau port renseigné que vous devrez mettre dans votre config dans l’étape suivante.
Modification du mot de passe root
Par mesure de sécurité changer le mot de passe auto généré du user root.
sudo su
passwd
# renseigner le nouveau mot de passe et sa confirmation
# stocker sa valeur dans un gestionnaire de mot de passe sécurisé (ex: Lastpass)Même s’il n’est pas possible de se connecter en ssh car la config PermitRootLogin de /etc/ssh/sshd_config est par défaut sur prohibit-password, cela garantit que le mot de passe interne n’est plus sur sa valeur par défaut.
Accès rapide au VPS grâce au .ssh/config
La prochaine bonne pratique que nous allons faire est de créer un utilisateur dédié et d’y renseigner notre clé publique SSH pour nous connecter directement avec la .ssh/config
Cette méthode est la plus sécurisé et évitera de renseigner notre mot de passe par la suite.
Copier la valeur de votre clé publique sur votre poste :
cat ~/.ssh/id_ed25519.pub | xclip -selection clipboardPuis sur le serveur lancer les commandes suivantes
adduser username # username à remplacer par le nom de votre user
usermod -aG sudo username
mkdir -p /home/username/.ssh
nano /home/username/.ssh/authorized_keys
# Collez le contenu de votre clé publique sauvegardez, puis vérifiez les permissions :
chmod 755 /home/username/.ssh
chmod 644 /home/username/.ssh/authorized_keysMaintenant, mettez à jour votre .ssh/config pour vous connecter plus rapidement au serveur
Host runners
Hostname XX.XX.XX.XX
User username
IdentityFile ~/.ssh/id_ed25519
Port 51001 # à remplacer par le port que vous avez choisi dans l'étape précédente
Maintenant vous pouvez directement vous connecter avec la commande ssh runners
Enlever la connexion root et par mot de passe
On peut maintenant enlever la connexion par mot de passe (avec au passage le Pluggable Authentication Modules qu’on désactive) pour être en full authentication via clé ssh.
nano /etc/ssh/sshd_config
# Localisez les options suivantes et mettre no :
PasswordAuthentication no
UsePAM no
PermitRootLogin no
# Vérifier s'il y a d'autre config cloud préinstallée qui surcharge ces paramètres dans ce dossier
ls -al /etc/ssh/sshd_config.d/
# Faite un nano sur chaque fichier et remettre PasswordAuthentication à no si besoin
# puis redémarrer le service
systemctl restart sshdProtection contre les intrusions
Recommandation OVH :
Fail2ban est un framework de prévention contre les intrusions dont le but est de bloquer les adresses IP depuis lesquelles des bots ou des attaquants tentent de pénétrer dans votre système. Ce paquet est recommandé, voire indispensable dans certains cas, pour protéger votre serveur des attaques de types Brute Force ou Denial of Service.
sudo apt 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 restartInstallation du Gitlab Runner
Installation de Docker : notre piste de course
- Installer les prérequis et ajouter la clé GPG officielle
sudo apt update
sudo apt install ca-certificates curl
sudo install -m 0755 -d /etc/apt/keyrings
sudo curl -fsSL https://download.docker.com/linux/ubuntu/gpg -o /etc/apt/keyrings/docker.asc
sudo chmod a+r /etc/apt/keyrings/docker.asc- Ajouter le dépôt Docker
sudo tee /etc/apt/sources.list.d/docker.sources <<EOF
Types: deb
URIs: https://download.docker.com/linux/ubuntu
Suites: noble
Components: stable
Architectures: amd64
Signed-By: /etc/apt/keyrings/docker.asc
EOF
sudo apt update- Installer Docker
sudo apt install docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin- Vérifier l’installation
sudo docker run hello-world- Ajouter le user créé précédament au groupe docker
usermod -aG docker username # username à remplacer par le nom de votre user TOOOODODOODODODOOOOTéléchargement et configuration du Gitlab Runner
curl -L "https://packages.gitlab.com/install/repositories/runner/gitlab-runner/script.deb.sh" -o script.deb.sh
sudo bash script.deb.sh
# fix nécessaire à faire sur la source apt car la version plucky déclenche l'erreur "Error: Unable to locate package gitlab-runner"
sudo sed -i 's/plucky/noble/g' /etc/apt/sources.list.d/runner_gitlab-runner.list
sudo apt update
sudo apt install gitlab-runner
# Vérifier l'install du gitlab-runner
gitlab-runner --versionÀ ce stade la lib est installé, maintenant nous devons configurer son accès à docker.
sudo usermod -aG docker gitlab-runner
# Puis vérifiez que ça a bien fonctionné :
sudo -u gitlab-runner docker psRendez-vous ensuite sur votre instance Gitlab pour créer une instance de runner :
https://gitlab.your-company.com/admin/runners/new
Nous vous conseillons de mettre l’année d’achat ainsi que l’OS du VPS dans la description de votre runner pour un meilleur suivi des versions.
Laisser le choix de Operating systems sur Linux et copier la commande mentionner à l’étape 1.
Puis retourner sur votre VPS et lancer la commande copiée depuis Gitlab
gitlab-runner register --url https://gitlab.your-company.com --token glrt-XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXLaissez-vous guider par la commande et renseigner docker comme choix d’executor.
À ce stade vous pouvez déjà testé votre nouveau gitlab-runner en renseignant les tags du runner dans les fichiers .gitlab-ci.yml de vos projets.
Configurer la concurrence des jobs
Dernière étape finaliser la configuration auto généré par la commande register.
Par défaut le gitlab-runner register initialise la concurrence des jobs à 1 : Cela signifie que votre runner ne peut gérer qu’une pipeline à la fois.
Si votre équipe de développeur est conséquante et que vous travaillez sur plusieurs projets en parallèle il peut être intéressant d’augmenter cette valeur.
sudo nano /etc/gitlab-runner/config.toml
# changer la valeur de concurrent à 4 pour avoir plusieurs jobs en parallèle et sauvegarder
# Penser bien à relancer le gitlab-runner à chaque modif de la config.toml pour appliquer les modifications
sudo gitlab-runner restartN’hésitez pas à consulter la documentation avancée des runners Gitlab pour plus de détails.
Bravo, l’installation et la configuration de votre runner est maintenant terminé !
Comparatif de performance entre versions des VPS et des runners
Nous vous partageons quelque retour de performance que nous avons constaté suite à notre dernière mise à jour des VPS d’OVH et des différentes librairies évoquées dans ce guide.
Les temps indiqués sont des moyennes effectués sur un projet Symfony/Js conséquant d’environ 100k lignes contenant plusieurs jobs de CI avec des stages de build d’assets et suite de tests.
| Spécification du VPS OVH | Version Docker | Version Gitlab Runner | Temps job Build & QA | Temps job de tests |
|---|---|---|---|---|
| Ubuntu 21.04, 2 vCores, 4 Go de RAM | 20.10.8 | 14.3.0 | 5 minutes 20 secondes | 4 minutes 18 secondes |
| Ubuntu 25.04, 6 vCores, 12 Go de RAM | 29.4.1 | 18.11.1 | 3 minutes 15 secondes | 3 minutes 12 secondes |
| Gain de performance | ≃ +40 % plus rapide | ≃ +25 % plus rapide |
Outre le bénéfice des mise à jour de sécurité, mettre à jour son VPS ainsi que les libs utilisées apporte un gain non négligeable sur vos temps de CI/CD.
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 vous conseillons lors de vos mise à jour VPS et runner de commander un nouveau VPS dédié à cette mise à jour.
Cela vous garantie de laisser l’ancien VPS actif sans risque d’intéruption avec les commandes de mise à jour. L’install fourni par le nouveau VPS vous permettra de bénéficier automatiquement des mise à jour de la dernière version d’Ubuntu disponible qui vous serviera de base pour les autres commandes.
Ainsi vous pourrez laisser les deux VPS en parallèle le temps de bien valider que le nouveau VPS fonctionne correctement.
Nous espérons que cet article aura éclairci votre compréhension de la mise en place et mise à jour de vos runners Gitlab, et restons disponibles si vous avez d’autres questions.
