Serveurs dédiés pour GitLab™
GitLab auto-hébergé et runners CI/CD sur bare metal
Exécutez GitLab Self-Managed sur un serveur dédié avec du stockage NVMe, et déplacez les jobs CI/CD vers des serveurs de runners séparés connectés via un VLAN privé. Les mêmes serveurs de runners fonctionnent pour GitLab Runner et les runners auto-hébergés GitHub Actions.
GITLAB est une marque déposée de GitLab Inc. aux États-Unis et dans d’autres pays et régions.
-
Stockage NVMe pour les dépôts -
CPU haute fréquence pour les builds CI -
VLAN privé à 10–25 Gbit/s -
Accès root et IP-KVM
AMD Zen 5 jusqu’à 5,7 GHz
Trafic illimité
Disques NVMe d’entreprise
Mémoire ECC DDR5
Exigences matérielles de GitLab et GitLab Runner
La configuration de base pour une instance GitLab à nœud unique est de 8 vCPU et 16 Go de mémoire – un processeur à 4–6 cœurs avec 8–12 threads sur un serveur dédié. L’utilisation du swap sous charge ralentit GitLab, donc 32 Go laissent de la marge pour les tâches en arrière-plan et la croissance.
Prévoyez 40 Go pour le système et PostgreSQL, ainsi que la taille totale de tous les dépôts. Gitaly, le service de dépôts, est très gourmand en E/S et nécessite un stockage SSD plutôt que des systèmes de fichiers réseau ; deux disques NVMe en RAID 1 constituent donc la configuration standard.
Les instances cloud et disques à performance variable sont mal adaptés à GitLab : leur vitesse diminue une fois qu’un quota d’utilisation est épuisé. Un serveur dédié n’a ni quotas ni voisins sur le même matériel, donc ses cœurs et ses disques NVMe ne sont jamais bridés par un fournisseur.
Les jobs CI/CD sont de préférence exécutés sur un serveur séparé plutôt que sur l’instance GitLab. Une compilation lourde ne peut alors pas ralentir Git, l’interface web ou les revues de code, et le code du pipeline ne s’exécute jamais à côté de vos dépôts.
Les compilateurs, les tests et les builds d’images reposent sur la vitesse d’un seul cœur, donc une fréquence élevée raccourcit chaque tâche, et le nombre de cœurs détermine combien de tâches s’exécutent en parallèle. Chaque tâche a besoin de sa propre mémoire, et les couches Docker ainsi que les caches résident sur le NVMe du runner.
Les runners récupèrent le code, les images et les artefacts depuis l’instance via un VLAN privé, jusqu’à 25 Gbit/s — une image Docker complète arrive en quelques secondes, pas en plusieurs minutes. Le port public reste libre pour votre équipe : les pushes Git, les demandes de fusion et l’interface web n’attendent jamais derrière un pipeline.
Tarification des serveurs dédiés pour GitLab et les exécuteurs
Voir toutes les configurations
Louez un serveur dédié pour GitLab
chez INTROSERV
Comment commander un serveur dédié
Sélectionnez une configuration, ajoutez des disques NVMe, choisissez le système d’exploitation, attendez que le serveur soit prêt et installez GitLab.
Lisez la documentation
Installez et sécurisez une instance GitLab à nœud unique
Installation étape par étape de GitLab Self-Managed à partir du paquet Linux officiel, avec HTTPS et la première connexion.
Lire le tutorielServeurs et infrastructure pour GitLab auprès d’un seul fournisseur
-
1
Installez GitLab sur le serveur d’instance
Installez GitLab Self-Managed à partir du package Linux officiel sur un stockage NVMe, avec PostgreSQL et Redis inclus. Configurez ensuite HTTPS, les e-mails sortants et le registre de conteneurs.
-
2
Connecter les serveurs de runner via le VLAN
Commandez des serveurs d’exécution dans le même centre de données et rejoignez-les à un VLAN privé jusqu’à 25 Gbit/s. Les tâches récupèrent le code, les images et les artefacts via le VLAN, et non via le port public.
-
3
Enregistrer les coureurs
Installez GitLab Runner avec l’exécuteur Docker et enregistrez-le auprès de votre instance. Pour les dépôts sur GitHub, les mêmes serveurs exécutent des runners auto-hébergés GitHub Actions.
-
4
Sauvegardez avec le service de sauvegarde INTROSERV
Sauvegardez l’ensemble du serveur d’instance avec le service de sauvegarde INTROSERV – le logiciel NAKIVO et le stockage réunis dans un service prêt à l’emploi. Restaurez l’intégralité du serveur ou un seul fichier lorsque nécessaire.
Passer de GitLab.com à une instance auto-hébergée ?
Licence et assistance GitLab
Licence
GitLab Enterprise Edition est l’installation recommandée : sans licence, elle fonctionne sur le niveau gratuit, et Premium ou Ultimate se débloquent ultérieurement avec un code d’activation, sans réinstallation. Community Edition est l’alternative open source sous licence MIT, avec les mêmes fonctionnalités gratuites. Les abonnements sont vendus par GitLab Inc. ou ses partenaires, et non par INTROSERV.
Assistance
L’assistance pour GitLab elle-même provient du forum et de la documentation GitLab, ou de GitLab Inc. avec un abonnement payant. INTROSERV prend en charge les serveurs Linux sur lesquels GitLab fonctionne : surveillance, sécurité, mises à jour du système d’exploitation et correction des incidents avec un plan de gestion de serveur, ainsi que des tâches ponctuelles sous forme d’administration système à l’heure.
FAQ
-
À quelle vitesse le serveur est-il livré ?
Les configurations instantanées sont prêtes dans les 3 à 6 heures suivant le paiement ; les configurations personnalisées prennent généralement jusqu’à 24 heures. Le délai de livraison est indiqué sur chaque configuration dans le catalogue.
-
Le serveur peut-il être testé d’abord ?
Oui. Une période d’essai payante allant jusqu’à 5 jours est disponible, suffisante pour installer GitLab, pousser un dépôt et exécuter le premier pipeline.
-
Quel système d’exploitation devrais-je choisir ?
Une distribution Linux prise en charge par le package officiel GitLab, telle qu’Ubuntu LTS ou Debian. Le package inclut PostgreSQL, Redis et le serveur web, de sorte que le système n’a besoin d’aucune autre installation.
-
Puis-je utiliser mon propre domaine et certificat HTTPS ?
Oui. Pointez un enregistrement DNS vers le serveur, et le package GitLab peut demander et renouveler automatiquement un certificat Let's Encrypt. Un certificat d’une autre autorité peut être installé à la place.
-
GitLab Pages peut-il s’exécuter sur le même serveur ?
Oui. Pages fonctionne comme un service distinct et a besoin d’un enregistrement DNS générique. Les domaines personnalisés pour Pages ont également besoin d’une deuxième adresse IP, qui peut être ajoutée au serveur.
-
Que se passe-t-il lorsqu’un disque NVMe tombe en panne ?
Avec deux disques en RAID 1, GitLab continue de fonctionner sur le disque restant. Vous ouvrez un ticket d’assistance, INTROSERV remplace le disque dans le centre de données, et le volume se reconstruit.
-
Peut-on ajouter plus de serveurs d’exécution plus tard ?
Oui. Commandez un autre serveur de runner dans le même centre de données, ajoutez-le au VLAN existant et enregistrez-le auprès de votre instance. Les pipelines commencent à l’utiliser dès qu’il est en ligne.
-
Le stockage peut-il être étendu ultérieurement ?
Sur les configurations DC1, DC2 et DC3, oui : les disques destinés aux emplacements libres sont ajoutés via un ticket de support, et le prix mensuel est ajusté en conséquence. Pour les autres configurations, il est préférable de choisir, au moment de la commande, une configuration de disques offrant une certaine marge de manœuvre.
