Comment auto-héberger GitLab CE sur un VPS

C'est vendredi après-midi, la pull request de votre équipe attend sa revue, et votre ordinateur portable affiche un message familier : GitHub rencontre encore des problèmes.

Peut-être que les Actions sont bloquées.

Peut-être que git push renvoie une erreur 500 pour la troisième fois ce mois-ci.

Le fil de discussion de votre équipe compte déjà huit messages.

La première fois, vous en riez. La deuxième fois, quelqu'un partage le lien de la page d'état de GitHub, et tout le monde part prendre un café. La troisième fois, généralement juste avant une fenêtre de mise en production, quelqu'un finit par poser la question tout haut : Et si on hébergeait le nôtre ?

Pour la plupart des équipes, la réponse honnête est non. L'offre gratuite de GitLab.com convient largement aux petites équipes, et la charge opérationnelle liée à l'exploitation de votre propre serveur de gestion de versions n'est pas nulle.

C'est le genre de compromis qu'on ne fait que pour une vraie raison.

Si votre équipe a l'une de ces raisons, comme un contrat client qui interdit les SaaS tiers, une contrainte de conformité ou une facture de licences par siège qui commence à devenir ridicule, auto-héberger GitLab CE est la solution la plus propre. C'est open source, cela tourne sur un seul VPS et, une fois le réglage fait, la maintenance prend environ une heure par mois.

Chez DreamHost, nous avons hébergé d'innombrables serveurs autogérés, et nous constatons toujours la même chose : les développeurs qui réussissent avec GitLab auto-hébergé choisissent la bonne offre dès le départ, préparent correctement le SSH (Secure Shell Protocol) et le DNS (Domain Name System), puis résistent à l'envie de bricoler une fois que tout est stable.

Pourquoi auto-héberger GitLab plutôt qu'utiliser GitLab.com ?

Vous auto-hébergez GitLab lorsque GitLab.com ou GitHub.com ne peuvent pas répondre à vos besoins en matière de confidentialité, de conformité ou de maîtrise des coûts. Pour la plupart des autres équipes, l'option hébergée est un meilleur compromis.

Trois vraies raisons résistent à l'examen :

1. Confidentialité et souveraineté des données : votre code source réside sur une infrastructure que vous gérez et mettez à jour selon votre propre calendrier. Aucun accès tiers, aucune plateforme partagée, et en cas de faille, les dégâts ne dépassent pas votre propre serveur.
2. Conformité : les secteurs réglementés comme la santé, la finance et l'administration publique ont souvent besoin de maîtriser la localisation des données. GitLab CE auto-hébergé est le moyen le plus simple de garder le code dans un périmètre contrôlé.
3. Maîtrise des coûts à grande échelle : GitLab.com facture par utilisateur actif. D'après la page de tarifs de GitLab, Premium coûte 29 $ par utilisateur et par mois, tandis que le tarif d'Ultimate n'est disponible que sur demande. Une équipe de 50 personnes sur Premium revient à 17 400 $ par an, hors options. Un VPS autogéré plus une heure de maintenance mensuelle coûte souvent moins cher.

Si vous êtes une équipe de deux personnes sans contrainte de confidentialité ni de conformité, la bonne réponse est l'offre gratuite de GitLab. (Oui, nous savons que c'est drôle venant d'un hébergeur).

Avec l'auto-hébergement, vous échangez une facture SaaS mensuelle contre du temps d'exploitation continu. Cet échange n'en vaut la peine que si vous avez une bonne raison de franchir le pas.

Voici quand cette option est pertinente, et quand elle ne l'est pas :

GitLab Community Edition est gratuit sous une licence open source de type MIT. Pas de limite d'utilisateurs, pas de fonctionnalités de base verrouillées, pas d'incitations à passer à l'offre supérieure. Toute la plateforme est à vous.

Quelle configuration matérielle faut-il pour GitLab CE ?

GitLab CE a des seuils matériels clairs, et les respecter fait toute la différence entre une installation réactive et une installation qui s'enlise dans la mémoire swap (l'espace disque que votre système d'exploitation utilise quand la RAM est pleine).

D'après les exigences d'installation officielles de GitLab, le dimensionnement s'exprime en requêtes par seconde plutôt qu'en paliers fixes par utilisateur. La référence publiée est de 8 vCPU et 16 Go de RAM pour jusqu'à 1 000 utilisateurs (environ 20 requêtes par seconde). Les petites équipes peuvent se contenter de moins, jusqu'à un minimum documenté de 2 Go de RAM plus 1 Go de swap pour une évaluation, mais les performances se dégradent en dessous de 4 Go.

Une installation neuve de GitLab consomme environ 4 à 6 Go au repos. Dès que les jobs CI/CD démarrent, la mémoire grimpe vite. Prévoyez donc de la marge, ou attendez-vous à de la lenteur.

Côté stockage, la référence officielle de GitLab est de 40 Go plus la taille des dépôts, mais 50 Go est un point de départ plus sûr en pratique. Les dépôts grossissent et les artefacts de build s'accumulent. Le NVMe, un type de stockage SSD plus rapide, fait une différence notable sur les opérations Git et les lectures du cache CI.

Voici comment ces seuils correspondent aux offres d'hébergement VPS de DreamHost :

L'offre adaptée à la plupart des équipes qui exécutent de vrais pipelines CI/CD est Stack 32, le seul Stack qui atteint la référence de 8 vCPU de GitLab. Stack 16 a la mémoire nécessaire mais deux fois moins de cœurs : considérez-le comme une taille d'essai. Cela semble excessif, jusqu'à ce que vous voyiez le premier build démarrer et Sidekiq, Postgres et un runner s'emballer en même temps*.*

16 Go de RAM vous laissent assez de marge pour la pile de services de GitLab (environ 4 à 6 Go au repos sur une installation par défaut) et quelques workers CI (1 à 2 Go chacun) tournant à plein régime en même temps, sans que personne ne s'en aperçoive dans le chat de l'équipe.

Comment préparer votre VPS avant d'installer GitLab ?

Consacrez 10 minutes à la préparation : cela paie dès le premier redémarrage. Suivez simplement ces étapes :

1. Provisionnez le VPS : choisissez Ubuntu 24.04 LTS. Cette version est prise en charge par les paquets Omnibus officiels de GitLab (l'installateur tout-en-un fourni par GitLab) et bénéficie encore de plusieurs années de mises à jour de sécurité gratuites.
   
2. Pointez un domaine vers l'IP du serveur : créez un enregistrement A (le type d'enregistrement DNS qui associe un domaine à une adresse IP) et laissez-le se propager pendant au moins 15 à 30 minutes avant l'installation. Sans cela, la configuration SSL automatique échouera, car l'autorité de certification n'aura aucun moyen de valider le domaine.
   
3. Mettez à jour les paquets : connectez-vous au VPS avec ssh root@your-server-ip et exécutez sudo apt update && sudo apt upgrade -y.
   
4. Installez les dépendances : exécutez sudo apt install -y curl openssh-server ca-certificates perl postfix. Le paquet postfix est un serveur de messagerie qui gère les e-mails sortants, pour que GitLab puisse envoyer les notifications de merge request et les réinitialisations de mot de passe.
   Lorsque l'installateur vous interroge sur la configuration de la messagerie, choisissez Internet Site et indiquez votre domaine. GitLab peut ainsi envoyer des e-mails immédiatement.
   En production : évitez postfix en local et configurez plutôt un relais SMTP dans gitlab.rb. Les IP de VPS figurent souvent sur des listes de blocage anti-spam, et les e-mails de réinitialisation de mot de passe envoyés via postfix en local finissent souvent dans le dossier spam. SendGrid, Mailgun et les relais SMTP similaires fonctionnent tous : consultez la documentation de configuration SMTP de GitLab.
   
5. Ouvrez les bons ports : configurez un pare-feu avec UFW (l'outil de pare-feu intégré à Ubuntu) et autorisez les ports 80, 443 et 22.

sudo ufw allow http
sudo ufw allow https
sudo ufw allow ssh
sudo ufw enable

Comment installer GitLab CE sur Ubuntu avec le paquet Omnibus ?

Ajoutez le dépôt GitLab CE :

curl -sSL https://packages.gitlab.com/install/repositories/gitlab/gitlab-ce/script.deb.sh | sudo bash

Ensuite, installez GitLab CE en définissant votre domaine comme URL externe :

sudo EXTERNAL_URL="https://gitlab.example.com" apt install gitlab-ce

Indiquer https:// ici demande à GitLab de solliciter automatiquement un certificat Let’s Encrypt pendant l'installation, à condition que les ports 80 et 443 soient ouverts et que le DNS pointe correctement. Si l'un des deux n'est pas prêt, l'installation se termine mais le SSL échoue, et vous passez la demi-heure suivante à dépanner quelque chose qui n'est pas vraiment cassé.

Ensuite, attendez l'étape de reconfiguration.

GitLab exécute gitlab-ctl reconfigure (la commande qui applique les modifications de la configuration de GitLab) automatiquement à la fin de l'installation. Cela prend de cinq à 10 minutes. Et oui, l'étape de reconfiguration prend vraiment autant de temps.

Récupérez le mot de passe root initial :

sudo cat /etc/gitlab/initial_root_password

Ce fichier est généré automatiquement et supprimé au bout de 24 heures : récupérez donc le mot de passe et connectez-vous. Ouvrez votre domaine dans un navigateur, connectez-vous en tant que root et changez immédiatement le mot de passe.

Enfin, vérifiez l'installation.

Depuis l'écran d'accueil de GitLab, créez un projet de test. Poussez-y un commit depuis votre machine locale. Si le push réussit et que le fichier apparaît dans l'interface web, l'installation est saine.

Si l'étape de reconfiguration se bloque, consultez tail -f /var/log/gitlab/reconfigure/*.log. C'est là que se trouve la véritable erreur.

Comment sécuriser une instance GitLab auto-hébergée ?

GitLab est livré avec des paramètres par défaut raisonnables, mais ils sont pensés pour un serveur communautaire ouvert, pas pour l'instance privée de votre équipe. Consacrez-y une heure.

1. Désactivez l'inscription ouverte. L'inscription ouverte est activée par défaut. Dans l'Admin Area, accédez à Settings > General > Sign-up restrictions et décochez la case Sign-up enabled. Sinon, n'importe qui disposant de l'URL peut créer un compte.
2. Activez l'authentification à deux facteurs. Allez dans Admin Area > Settings > General > Sign-in restrictions et imposez la 2FA à tous les utilisateurs. Réduisez le délai de grâce de 48 heures (valeur par défaut) à 8 heures.
3. Limitez la création de projets. Réglez Default Project Creation sur Maintainers ou No one, selon le niveau de verrouillage souhaité.
4. Vérifiez le renouvellement SSL. Par défaut, GitLab renouvelle automatiquement les certificats Let’s Encrypt. Pour le confirmer, exécutez sudo gitlab-ctl renew-le-certs une fois et vérifiez la sortie.
5. Verrouillez le SSH sur le VPS lui-même. Désactivez la connexion root par mot de passe, n'autorisez que l'authentification par clé SSH et (si possible) déplacez SSH hors du port 22. Un serveur Git auto-hébergé n'est jamais plus sûr que la machine sur laquelle il tourne.

Pour aller plus loin, GitLab a publié un guide de durcissement qui couvre l'authentification, le chiffrement et les paramètres de l'instance. Lisez-le une fois, appliquez ce qui correspond à votre modèle de menaces, et passez à autre chose.

Comment sauvegarder et restaurer une instance GitLab auto-hébergée ?

GitLab inclut un outil de sauvegarde intégré. La première fois que vous en aurez besoin, vous serez ravi de l'avoir configuré.

Créez une sauvegarde :

sudo gitlab-backup create

Cette commande dépose une archive tar dans /var/opt/gitlab/backups. Planifiez-la chaque jour via cron avec une durée de rétention de sept jours. Exécutez sudo crontab -e et ajoutez ces deux lignes :

0 2 * * * /opt/gitlab/bin/gitlab-backup create CRON=1
0 3 * * * find /var/opt/gitlab/backups -name "*.tar" -mtime +7 -delete

L'option CRON=1 supprime l'affichage de la progression pour ne pas encombrer les journaux cron.

Conseil de pro : la sauvegarde des données n'inclut ni /etc/gitlab/gitlab-secrets.json ni /etc/gitlab/gitlab.rb.

Ces fichiers contiennent la clé de chiffrement de la base de données, les secrets de l'authentification à deux facteurs et les variables CI/CD. Les secrets de configuration ne font pas partie de la sauvegarde standard et doivent être enregistrés séparément. Si vous restaurez les données sans le fichier de secrets, les comptes à deux facteurs ne fonctionnent plus, les variables chiffrées deviennent illisibles, et vous passez une longue soirée à comprendre pourquoi.

Ajoutez ceci au même cron job :

sudo cp /etc/gitlab/gitlab-secrets.json /etc/gitlab/gitlab.rb /var/opt/gitlab/backups/

Une sauvegarde ne peut être restaurée que sur la même version et la même édition de GitLab (CE vers CE, pas CE vers EE) que celles sur lesquelles elle a été créée.

Mettez à niveau avec prudence : ne restaurez pas une ancienne sauvegarde sur un GitLab fraîchement installé sans d'abord rétrograder l'installation à la version correspondante.

Testez la restauration au moins une fois. Une sauvegarde jamais testée n'est qu'un fichier.

L'auto-hébergement de GitLab vaut-il vraiment le coup pour votre équipe ?

Pour la plupart des équipes, auto-héberger GitLab est une question de contrôle. Le calcul des coûts est parfois favorable, mais la raison pour laquelle les équipes restent en auto-hébergement est rarement une ligne budgétaire.

Voici le temps mensuel réellement nécessaire pour une installation de petite équipe :

• ~30 minutes de mises à jour – mises à niveau apt, versions mineures de GitLab
• ~15 minutes de vérification des sauvegardes – ne faites pas confiance à une sauvegarde que vous n'avez pas restaurée
• ~15 minutes de contrôle de capacité – utilisation du disque, marge de RAM
• ~2x si le CI/CD tourne sur la machine – un runner très sollicité peut doubler la charge

Cela représente environ une heure par mois quand l'activité est calme, ou deux quand elle est soutenue.

À environ 150 $ de l'heure, 12 heures de temps d'exploitation reviennent à environ 1 800 $, soit à peu près cinq sièges GitLab.com Premium.

Une étude de cas de praticiens de Mad Devs explique comment leur équipe économise plus de 10 000 $ par an en utilisant GitLab CE auto-hébergé au lieu de payer des sièges Premium. Ces économies ne se concrétisent que lorsque l'équipe est assez grande pour que les licences par siège pèsent le plus lourd dans le budget.

Cela dit, l'auto-hébergement n'est pas le bon choix pour :

• Équipes de deux à trois personnes sans contraintes de conformité. L'offre gratuite de GitLab.com vous suffit. Le temps d'exploitation dépasse les économies réalisées.
• Équipes où personne n'est à l'aise avec la ligne de commande. À l'aise ne veut pas dire avoir le niveau d'un administrateur système. Cela signifie que vous savez lire des erreurs /var/log/gitlab sans paniquer.
• Équipes dont le principal frein est le recrutement, pas l'outillage. L'auto-hébergement détourne l'attention du produit. Si la vélocité produit est la contrainte, une solution hébergée est le bon choix.

Alors, quand l'auto-hébergement a-t-il du sens ? Voici quelques scénarios :

• Secteurs réglementés avec des exigences explicites de résidence des données ou de chaîne de traçabilité
• Équipes de l'UE ou du Royaume-Uni préoccupées par la souveraineté du code hébergé aux États-Unis
• Équipes de 30 personnes ou plus dont le budget est dominé par les licences par utilisateur
• Contrats clients qui interdisent les SaaS tiers pour le code source

Si votre raison est « GitHub facture par utilisateur », vous y gagnerez probablement. Si votre raison est « je veux garder le contrôle », la réalité de l'exploitation pourrait vous sembler moins romantique que prévu.

Faut-il exécuter les runners GitLab CI/CD sur le même VPS ?

Pour une évaluation, oui. En production, non.

Un runner CI sur la même machine prive l'interface de GitLab de mémoire et de CPU. Le symptôme classique : « GitLab est lent à 9 h », ce qui s'explique généralement par un build qui lance le premier pipeline de la matinée et affame le frontend web. La configuration la plus propre consiste à utiliser un VPS séparé pour le runner (un Stack 8 par runner), enregistré auprès de l'instance GitLab via le réseau.

Si vous devez garder les runners sur la même machine, optez pour Stack 32 et laissez de la marge pour les tâches.

Selon les exigences système des runners de GitLab, le processus du runner lui-même est léger. Les charges de travail qu'il exécute ne le sont pas, et elles partagent le CPU et le disque de la machine avec tout ce que fait GitLab par ailleurs.

Prêt à franchir le pas ?

Revenons à la discussion d'équipe du vendredi après-midi.

Si GitHub passe au jaune et que votre équipe en rit encore avant d'aller prendre un café, pas de souci.

Mais si les pannes de GitHub commencent à devenir un vrai problème ?

Peut-être qu'elles menacent un contrat client ? Qu'elles ressortent lors d'un audit de conformité ? Ou que la facture des licences par utilisateur a fini par dépasser les bornes ?

Auto-héberger GitLab CE devient alors une option tout à fait raisonnable. Il suffit d'un VPS, d'un domaine, d'une installation Omnibus et d'une heure de sécurisation.

La prochaine fois que la page d'état de GitHub s'affolera, vous pourrez continuer à pousser votre code sans problème.

Questions fréquentes sur l'auto-hébergement de GitLab