Hébergement GitLab Runner, sur une machine qui est la vôtre
Un runner autogéré à Prague ou Covilhã avec tout le disque pour lui seul, si bien que le cache de couches Docker est encore là à la deuxième pipeline de la journée et que la facture ne bouge pas quand la compilation, elle, bouge.
À qui cela s'adresse
Une équipe qui achète des minutes de calcul
La suite de tests a grossi, donc la pipeline s'est allongée, donc la facture a monté - et le seul levier qu'offre l'abonnement est d'acheter encore plus exactement des mêmes minutes.
Une pipeline qui veut deux fois la même machine
Chaque job démarre sur un disque vide. L'image de base est retéléchargée, les dépendances sont récupérées à nouveau, et téléverser le cache prend plus de temps que l'étape qu'il devait faire gagner.
Un dépôt soumis à une règle de résidence
Le code source, les artefacts et les clés de déploiement passent tous par le runner, et "une flotte partagée, quelque part" est la réponse que votre auditeur ne cesse d'entourer en rouge.
Ce qu'un runner autogéré vous rend
- Un cache de couches Docker chaud sur du NVMe local, pour que la deuxième pipeline de la journée reprenne là où la première s'est arrêtée au lieu de repartir d'un disque vide.
- N'importe quel executor - docker, shell, docker-autoscaler, instance ou kubernetes - choisi par runner plutôt qu'attribué par un abonnement.
- Votre propre parallélisme, posé comme un nombre dans config.toml au lieu d'être acheté comme le palier supérieur.
- Le mode privilégié quand vous avez vraiment besoin de Docker-in-Docker, ce qu'aucune flotte partagée ne vous donnera jamais.
- Une IPv4 sortante statique issue d'AS204057, pour qu'une cible de déploiement, un miroir de paquets ou le pare-feu d'une base de données puisse autoriser le runner par son adresse.
- Ce dont la compilation a réellement besoin sur l'hôte : une vieille chaîne d'outils, un SDK sous licence, ou un jeu de fixtures que personne ne veut télécharger une fois par job.
Dimensionné d'après ce que la pipeline fait vraiment
GitLab ne publie aucune exigence matérielle pour le runner lui-même, et ce n'est pas un oubli : le processus runner est petit, la compilation ne l'est pas. Le nombre qui compte, c'est le job. Partez du job le plus lourd que vous exécutez aujourd'hui, multipliez par le parallélisme voulu, et soyez généreux en disque - le cache de couches et l'espace de travail sont ce qui le remplit, et un disque plein fait échouer une pipeline d'une façon qui ressemble à un test cassé. Une chose qu'un hôte mensuel fixe ne fait pas : disparaître pendant une semaine calme. Les minutes hébergées ne coûtent rien quand personne ne pousse, et ceci coûte pareil. Cela devient rentable à partir du moment où la pipeline tourne presque tous les jours.
Comment installer GitLab Runner sur un hôte neuf
Debian ou Ubuntu, depuis un serveur propre, dans l'ordre que GitLab documente. Tout ce qui suit est leur séquence, pas la nôtre.
-
Ajouter le dépôt de paquets officiel
curl -L "https://packages.gitlab.com/install/repositories/runner/gitlab-runner/script.deb.sh" -o script.deb.sh less script.deb.sh sudo bash script.deb.shGitLab livre le dépôt sous forme de script d'installation et demande de le lire avant de l'exécuter, c'est pourquoi leurs propres instructions le téléchargent d'abord au lieu de le passer directement à un shell.
-
Installer le runner
sudo apt install gitlab-runnerLe paquet crée un utilisateur système gitlab-runner dont le répertoire personnel est créé vide, sans fichiers de squelette. Pour figer une version, installez gitlab-runner et gitlab-runner-helper-images ensemble dans la même version - depuis 17.7.1 ils vont par paire, et n'en nommer qu'un échoue sur une erreur de dépendance.
-
Installer Docker, si les jobs tournent en conteneurs
sudo apt install docker.io sudo systemctl enable --now dockerL'executor docker parle à un Docker Engine local via l'API v1.25, le démon doit donc se trouver sur l'hôte du runner lui-même. Le paquet de la distribution suffit pour commencer ; le dépôt propre de Docker porte les versions plus récentes si une compilation en a besoin.
-
Enregistrer le runner
sudo gitlab-runner register \ --non-interactive \ --url "https://gitlab.com/" \ --token "$RUNNER_TOKEN" \ --executor "docker" \ --docker-image alpine:latest \ --docker-pull-policy "if-not-present" \ --description "docker-runner"Créez d'abord le runner dans GitLab, sous Settings puis CI/CD puis Runners, et il vous rend un jeton d'authentification commençant par glrt- qui va dans --token. Les tags de job et l'option pour les jobs sans tag se règlent dans ce même formulaire : avec les jetons d'authentification ils appartiennent au runner, pas à la commande register. L'ancien flux --registration-token est déprécié et prévu pour suppression dans GitLab 20.0.
-
Régler le parallélisme et démarrer
sudo sed -i "s/^concurrent = .*/concurrent = 4/" /etc/gitlab-runner/config.toml sudo gitlab-runner restart sudo gitlab-runner statusconfig.toml se trouve dans /etc/gitlab-runner quand le runner tourne en root. concurrent est un plafond couvrant tous les runners enregistrés sur cet hôte, pas un réglage par runner, et chaque runner peut porter en dessous sa propre limite plus basse.
-
Le prouver avec un job
stages: [test] smoke: stage: test tags: [docker-runner] script: - cat /etc/os-release - echo "built on $CI_RUNNER_DESCRIPTION"Committez ceci en tant que .gitlab-ci.yml, poussez, et le job devrait arriver sur votre hôte en quelques secondes. S'il reste en file d'attente, les tags ne correspondent pas à ceux posés dans l'interface, ou le runner est verrouillé sur un autre projet.
Vérifié sur la documentation officielle le 2026-08-15 — lire la source
Ce que nous ne sommes pas
- Nous ne sommes pas GitLab. GitLab, GitLab CI/CD et GitLab Runner sont à eux, et rien sur cette page n'est approuvé par eux. Ce que nous vendons, c'est la machine sur laquelle un runner tourne.
- Cette page ne parle pas d'héberger GitLab lui-même. Une instance GitLab autogérée est une machine plus grosse et une autre conversation - demandez et nous la dimensionnons, mais ce n'est pas ce qui est chiffré ici.
- Nous n'écrivons pas votre .gitlab-ci.yml. La pipeline est à vous ; l'hôte, le réseau et l'adresse sont à nous.
- Le runner n'est pas géré pour vous sauf demande. Vous l'installez, ou vous ajoutez notre service d'administration et nous le gardons à jour, enregistré et surveillé.
- Votre abonnement GitLab reste chez GitLab. Un runner autogéré ne consomme pas leurs minutes de calcul, c'est bien le but, mais il ne remplace pas non plus les licences utilisateur.
Les parties que les équipes découvrent tard
- Le flux par jeton d'enregistrement s'en va. Un runner créé dans l'interface rend un jeton d'authentification glrt- que gitlab-runner register accepte comme --token, et --registration-token est prévu pour suppression dans GitLab 20.0.
- Les tags ont suivi. Avec un jeton d'authentification, les tags de job, l'option sans tag et le verrouillage appartiennent à l'objet runner créé dans l'interface, donc les options qui les réglaient autrefois en ligne de commande ne décident plus rien.
- Figer une version signifie figer deux paquets. Depuis 17.7.1, une version explicite de gitlab-runner exige aussi gitlab-runner-helper-images dans la même version, sinon apt refuse l'installation.
- check_interval vaut 3 secondes par défaut. Sur un hôte portant beaucoup de runners enregistrés cela fait énormément de sondages ; augmentez-le avant d'accuser le réseau.
- Docker-in-Docker exige le mode privilégié, ce qui donne en pratique le root de l'hôte au job. Si la pipeline ne fait que construire des images, un constructeur sans root comme Kaniko ou Buildah est le meilleur compromis.
- Les artefacts et les caches continuent de voyager vers GitLab tant que vous ne pointez pas le cache vers votre propre bucket compatible S3. Sur un runner que vous avez déplacé en UE exprès, c'est en général le dernier saut qu'il reste à déplacer.
Minutes de CI hébergées face à un runner à vous
| Minutes de CI hébergées par le fournisseur | Un runner chez DCXV | |
|---|---|---|
| Ce que vous payez | Chaque minute de chaque job, aussi longtemps que le projet existe | Un hôte mensuel fixe, quoi que fasse la pipeline ce mois-là |
| Une compilation qui ralentit | Coûte plus cher chaque mois où elle reste lente | Ne coûte rien de plus - la machine est déjà payée |
| Cache de couches Docker | Froid à chaque job sauf si vous le téléversez et le retéléchargez vous-même | Chaud sur du NVMe local, entre les jobs et entre les journées |
| Parallélisme | Un palier d'abonnement que l'on augmente | Un nombre que vous posez dans votre propre fichier de configuration |
| Où atterrit le checkout | Une flotte partagée, souvent dans une région que vous ne pouvez pas fixer | Une machine à Prague ou Covilhã, sous contrat chypriote |
| Adresse sortante | Une vaste plage partagée que rien ne peut autoriser | Une IPv4 statique issue d'AS204057, la vôtre à autoriser |
| Ce que la machine peut contenir | Ce que l'image du runner apporte par hasard | Toute chaîne d'outils, licence ou jeu de fixtures installé une fois |
Comment cela démarre sur votre hôte
Dites-nous ce que fait la pipeline
Le job le plus lourd que vous exécutez aujourd'hui, combien vous en voulez en parallèle, et s'il construit des images de conteneur. Cela suffit pour dimensionner un hôte sans deviner.
Nous vous remettons la machine
Prague ou Covilhã, accès root et une IPv4 statique, en moins de dix minutes. Apportez votre propre image si le runner y est déjà intégré.
Suivez le pas à pas de cette page
C'est la séquence de l'éditeur, tirée de sa documentation actuelle plutôt que d'un article de blog, et elle prend quelques minutes sur un hôte propre.
Faites un snapshot, puis ajoutez le second
Prenez un snapshot dès que la première pipeline est verte, pour que la machine suivante soit une restauration et non une reconstruction. Un pool grandit en ajoutant des hôtes, pas en en rendant un énorme.
Pourquoi nous choisir
- Sites certifiés Tier III, SLA du site de 99,982 %
- Réseau propre, AS204057, IPv4 et IPv6
- Support 24/7/365 avec environ 10 minutes de réponse moyenne
- Société chypriote, juridiction de l'UE, conforme au RGPD depuis 2007
FAQ
- Quelle est la différence entre un runner partagé et un runner autogéré ?
Un runner partagé est la machine de GitLab et vous payez les minutes qu'elle consacre à votre job. Un runner autogéré est votre machine : vous y installez gitlab-runner, vous l'enregistrez auprès de votre projet, groupe ou instance, et il ne consomme aucune minute de calcul. Les espaces de noms de l'offre gratuite de GitLab reçoivent 400 minutes de calcul par mois, et une pipeline active les épuise en quelques jours
- Comment installer et enregistrer GitLab Runner ?
Ajoutez leur dépôt apt via le script d'installation de packages.gitlab.com, installez le paquet gitlab-runner, puis lancez gitlab-runner register en mode non interactif avec le jeton d'authentification que GitLab vous donne à la création du runner dans l'interface. La séquence complète avec les commandes exactes est sur cette page, tirée de leur documentation et non d'un article de blog
- Enregistre-t-on encore un runner avec le jeton d'enregistrement ?
Non, et c'est le changement qui casse la plupart des anciens guides. Créez d'abord le runner dans l'interface GitLab et elle vous rend un jeton d'authentification commençant par glrt-, que gitlab-runner register accepte comme --token. L'ancien flux --registration-token est déprécié et prévu pour suppression dans GitLab 20.0. Les tags de job, l'option sans tag et le verrouillage appartiennent désormais à l'objet runner créé dans l'interface, pas à la commande register
- Quelle taille de serveur faut-il pour un GitLab Runner ?
GitLab ne publie pas d'exigence matérielle pour le runner lui-même, parce que le processus runner est petit et que votre compilation ne l'est pas. Dimensionnez d'après le job le plus lourd multiplié par le parallélisme voulu. En pratique 4 vCPU, 8 Go et 120 Go de NVMe portent deux ou trois jobs à la fois ; 8 vCPU, 16 Go et 240 Go en portent six à huit. Soyez généreux en disque - le cache de couches Docker et l'espace de travail sont ce qui le remplit
- Ai-je besoin de Docker sur l'hôte du runner ?
Seulement si vous utilisez l'executor docker, ce que font la plupart des gens. Il parle à un Docker Engine local via l'API v1.25, le démon doit donc être installé sur l'hôte du runner lui-même. L'executor shell n'a besoin d'aucun Docker, et les executors instance et docker-autoscaler créent des machines ailleurs
- Plusieurs runners peuvent-ils partager un hôte ?
Oui, et c'est la forme habituelle. Enregistrez-en autant que vous voulez sur la même installation ; le réglage concurrent dans /etc/gitlab-runner/config.toml est un plafond pour l'ensemble, et chaque runner peut porter en dessous sa propre limite plus basse. Surveillez check_interval, à 3 secondes par défaut, qui devient beaucoup de sondages dès qu'un hôte porte une douzaine de runners
Si vous avez besoin d'aide ou avez des questions supplémentaires, veuillez contacter les managers ou écrire à l'équipe de support à support@dcxv.com
Prêt à commencer ?
Facturation mensuelle, sans frais de mise en service, sans engagement