DevOps open source à grande échelle : héberger GitLab soi-même
Le code source est le seul actif que presque toutes les entreprises technologiques s'accordent à juger critique, et c'est aussi celui que la plupart conservent sur une infrastructure qu'elles ne possèdent pas, dans une juridiction qu'elles n'ont pas choisie, sous un contrat qu'elles n'ont pas lu attentivement. Cet arrangement convient généralement. Il vaut néanmoins la peine de savoir ce que coûte l'alternative, car GitLab rend réellement praticable, depuis plus de dix ans, l'hébergement de tout le cycle de développement.
C'est aussi un produit dont l'offre gratuite est plus généreuse et la charge d'exploitation plus lourde que la plupart des gens ne l'imaginent. Il faut comprendre les deux avant de s'engager. Ce guide explique donc ce qu'est réellement GitLab auto-hébergé, ce que l'offre gratuite donne vraiment, et les trois problèmes d'exploitation qui concentrent l'essentiel de la douleur.
Ce qu'est GitLab
Pas un hébergeur Git avec des options greffées dessus. Une application Rails, PostgreSQL, Redis, Gitaly pour le stockage des dépôts, Sidekiq pour les tâches de fond et un registre de conteneurs, empaquetés ensemble en un seul système couvrant la gestion de version, la revue de code, le suivi des tickets, la CI/CD, les registres de paquets et de conteneurs, l'analyse de sécurité et le déploiement.
Cette étendue est tout l'argument. GitHub plus Actions plus Dependabot plus un registre de paquets plus un outil de suivi donne un périmètre fonctionnel comparable, assemblé à partir de pièces. GitLab est une application avec un modèle de permissions et une base de données. C'est soit exactement ce que vous voulez, soit plus que ce dont vous avez besoin, et cela dépend de la part du cycle que vous comptez réellement faire tourner au même endroit.
Le fait architectural important est le même que pour héberger vos statistiques avec Matomo, votre automatisation marketing avec Mautic ou votre messagerie d'équipe avec Mattermost : cela tourne là où vous le posez. Vos dépôts, vos journaux de CI, vos artefacts, votre base de données.
L'état des licences, dit clairement
C'est réellement déroutant et cela mérite d'être précis, parce que la confusion va dans le sens inverse de ce à quoi on s'attend.
Il existe deux distributions du code source. La Community Edition est sous licence MIT. L'Enterprise Edition a sa propre licence, plus restrictive, qui couvre le répertoire ee/ du dépôt. Jusqu'ici cela ressemble au modèle open core habituel.
Ce qui surprend : le paquet Linux que presque tout le monde installe est la version Enterprise Edition, et sans clé de licence appliquée il tourne en offre Free, se comportant comme la Community Edition. Vous n'exécutez donc pas la distribution sous MIT, sauf si vous avez délibérément choisi le paquet CE. En pratique cela compte rarement, mais si votre raison d'auto-héberger est une politique open source stricte plutôt que la maîtrise des données, cela compte énormément, et presque personne ne vérifie.
Les offres commerciales sont Free, Premium à 29 dollars par utilisateur et par mois en facturation annuelle, et Ultimate à tarif sur devis. Premium ajoute la CI/CD avancée, une meilleure gestion de projet et un support prioritaire. Ultimate ajoute la suite sécurité et conformité : tests de sécurité applicative, sécurité de la chaîne d'approvisionnement, analyse des dépendances. Les deux offres payantes incluent désormais des GitLab Credits pour les fonctions d'IA, 12 dollars par utilisateur et par mois sur Premium et 24 sur Ultimate.
Voici le fait qui change le calcul pour la plupart des équipes, et l'exact inverse de la situation Mattermost : l'offre Free en auto-hébergé n'a aucune limite d'utilisateurs. Le plafond de cinq utilisateurs dont les gens ont entendu parler ne s'applique qu'aux groupes privés sur GitLab.com. En auto-hébergé, Free vous donne des utilisateurs illimités, la gestion de version, la CI/CD et les registres, et vous apportez votre stockage et vos runners. Une organisation de cent ingénieurs peut tourner entièrement dessus.
Ce à quoi vous renoncez : l'analyse de sécurité, les rapports de conformité, les règles d'approbation avancées et le support. Si vous relevez du règlement sur la cyberrésilience et voulez l'analyse des dépendances et la génération de SBOM directement dans vos pipelines plutôt qu'assemblées depuis des outils séparés, c'est une discussion Ultimate. Pour la plupart des autres équipes, Free n'est pas un essai. C'est une réponse permanente viable.
La mise en place
Un petit déploiement
GitLab est plus lourd qu'il n'y paraît. La base documentée pour un nœud unique est de 8 vCPU et 16 Go de RAM, et contrairement à la plupart des minima d'éditeur ce chiffre est honnête plutôt qu'optimiste. On peut le comprimer dans 8 Go, mais cela se sent, et le swap devrait être désactivé, car faire swapper cette application est pire que de ne pas avoir la mémoire.
PostgreSQL est la seule base prise en charge. La version dépend de votre version de GitLab : 17.x veut PostgreSQL 14.14 à 16.x, 18.x veut 16.5 à 17.x, et 19.x veut 17.x. Redis 7.2 est recommandé, 7.0 est le minimum, et Valkey 7.2 fait l'affaire en remplacement. Instances autonomes uniquement, car les variantes en cluster et serverless de Redis ne sont pas prises en charge.
Installez avec le paquet Linux. Il existe des charts Helm, un Operator, des images Docker et une voie depuis les sources, mais le paquet Linux est l'option la plus mature et c'est ce sur quoi tourne GitLab.com lui-même. Il embarque PostgreSQL, Redis et Sidekiq, donc une machine et un fichier de configuration suffisent à obtenir une instance qui fonctionne.
# /etc/gitlab/gitlab.rb
external_url 'https://git.example.com'
# Let's Encrypt, on by default when external_url is https
letsencrypt['enable'] = true
letsencrypt['contact_emails'] = ['ops@example.com']
# Keep Puma and Sidekiq honest on a small box
puma['worker_processes'] = 2
sidekiq['max_concurrency'] = 9
# Move artefacts and uploads off local disk early
gitlab_rails['object_store']['enabled'] = true
gitlab_rails['object_store']['connection'] = {
'provider' => 'AWS',
'region' => 'eu-central-1',
'aws_access_key_id' => 'REPLACE_ME',
'aws_secret_access_key' => 'REPLACE_ME'
}
Un gitlab-ctl reconfigure plus tard, vous avez une instance. Réglez external_url correctement dès la première fois, car cette valeur finit gravée dans les URL de clone, les webhooks et les adresses de registre.
Un déploiement de production
GitLab publie des architectures de référence de 1 000 à 50 000 utilisateurs, et elles méritent d'être lues même si vous n'en implémentez aucune, parce qu'elles montrent quel composant devient le goulot d'étranglement en premier.
Le conseil qui fait économiser le plus vient de GitLab lui-même et plaide contre la complexité : en dessous de 3 000 utilisateurs, ils recommandent une stratégie de sauvegarde solide plutôt que la haute disponibilité. La documentation est inhabituellement franche là-dessus, notant qu'une approche par sauvegarde a bien un temps de restauration plus lent, mais qu'elle signifie une architecture bien plus petite et des coûts de maintenance moindres. Au-dessus de 3 000 utilisateurs, ou là où une panne arrête réellement l'entreprise, la haute disponibilité devient la recommandation.
Prenez cela au sérieux. Un nœud unique bien sauvegardé, avec une restauration testée, est en pratique plus fiable qu'un cluster haute disponibilité à moitié compris, et bien moins cher.
Déplacez artefacts, téléversements, objets LFS et images de registre vers un stockage objet dès le départ. Même raisonnement que partout ailleurs : cela garde le nœud sans état, les sauvegardes gérables et la migration possible.
Les trois choses qui tournent mal
Tout ce qui précède figure dans la documentation. Voici ce qui produit des incidents.
Votre sauvegarde ne contient pas ce qui la déchiffre
C'est le paragraphe le plus important de cet article.
gitlab-backup create capture beaucoup : la base de données, les dépôts, les objets LFS, les artefacts de CI et les journaux de jobs, les images de registre, les wikis, les téléversements, le contenu Pages, l'état Terraform, les extraits. Ce qu'il ne capture pas, c'est le répertoire de configuration, et nommément /etc/gitlab/gitlab-secrets.json.
Ce fichier contient la clé de chiffrement de la base. La documentation en énonce la conséquence sans détour : si vous le perdez, l'application GitLab ne pourra déchiffrer aucune valeur chiffrée dans la base. C'est-à-dire les variables CI/CD, les jetons, les secrets de double authentification et les identifiants d'intégration. Vous auriez une sauvegarde qui se restaure dans une instance incapable de lire ses propres secrets.
Également exclus : /etc/gitlab/gitlab.rb, les clés et certificats TLS, les clés d'hôte SSH, et le contenu du stockage objet dès lors qu'il est configuré. Ce dernier point attrape précisément ceux qui ont fait le bon choix d'architecture puis supposé que la sauvegarde le couvrait.
Sauvegardez donc /etc/gitlab séparément, rangez-le ailleurs qu'à côté de l'archive puisqu'il en est la clé, puis restaurez l'ensemble sur une machine jetable et vérifiez que vous pouvez vous connecter et lire une variable de CI. Une sauvegarde non testée n'est pas une sauvegarde, et dans le cas de GitLab une restauration non testée est généralement cassée.
Vous ne pouvez pas monter de version d'un seul bond
GitLab impose des étapes obligatoires de mise à niveau, et ce n'est pas indicatif. Vous ne pouvez pas les sauter. Depuis 17.5 ces étapes sont prévisibles et se situent en x.2, x.5, x.8 et x.11, si bien que passer de 18.0 à 19.2 impose de traverser 18.2, 18.5, 18.8, 18.11 et 19.0.
Chaque étape implique des migrations de fond qui doivent être entièrement terminées avant de passer à la suivante. Lancer la mise à niveau suivante pendant que les migrations tournent encore, c'est ainsi que des instances finissent dans des états que seul le support démêle. Sur une grosse instance, ces migrations peuvent prendre des heures.
Deux conséquences pratiques. Mettez à jour régulièrement, car une année de mises à niveau différées fait un week-end de mises à niveau successives. Et prenez toujours le dernier correctif d'une version mineure cible plutôt que le premier, ce que la documentation dit explicitement. GitLab maintient un outil qui calcule le chemin de mise à niveau pour vous, et il vaut mieux l'utiliser que raisonner soi-même.
Le vrai coût est dans les runners
Le serveur GitLab n'exécute pas votre CI. GitLab Runner est un composant distinct que vous installez, configurez et payez, sur une infrastructure que vous fournissez. L'offre Free auto-hébergée n'inclut aucune minute de calcul, parce qu'il n'y a pas de calcul fourni : vous apportez vos propres machines.
C'est généralement une bonne affaire, car un runner dédié coûte moins cher à la minute qu'une CI hébergée dès qu'il y a du volume, et vous pouvez donner à chaque build le matériel dont il a besoin. Mais c'est du vrai travail d'infrastructure. Vous trancherez sur les executors, shell, Docker ou Kubernetes ; sur l'autoscaling, pour que les runners ne tournent pas à vide à trois heures du matin ; et sur le cache, qui fait la différence entre un pipeline de quatre minutes et un de quatorze.
Budgétez la flotte de runners comme une ligne à part. Les équipes qui modélisent le coût de l'auto-hébergement en ne regardant que le nœud GitLab le sous-estiment largement, puis découvrent le manque sous forme de file de jobs en attente.
Quitter GitHub
L'importateur GitHub est bon, nettement meilleur que la plupart des outils de migration d'éditeurs, et il fait passer les données de dépôt, les branches, les objets LFS, les tickets et les pull requests avec leurs commentaires, revues et réponses de discussion, les pages de wiki, les releases et pièces jointes, les étiquettes, les jalons, les règles de protection de branche et les collaborateurs avec correspondance des rôles.
Les lacunes documentées méritent d'être anticipées. Les organisations et les groupes ne passent pas, la structure de groupes est donc à concevoir plutôt qu'à hériter, ce qui est généralement une amélioration. Les workflows GitHub Actions ne se convertissent pas en GitLab CI. Les commentaires de pull requests antérieurs à 2017 arrivent en fils séparés à cause de contraintes de l'API GitHub, et les dépôts dépassant environ 30 000 commentaires nécessitent l'activation de la méthode alternative d'import des commentaires.
Comme GitHub utilise # à la fois pour les tickets et les pull requests, là où GitLab les distingue, certaines références croisées ne se résoudront pas. Rien n'est perdu, mais des liens dans d'anciennes discussions peuvent pointer sur la mauvaise chose.
Prévoyez la réécriture de la CI comme étant le vrai projet, car c'est ce qu'elle est. Le reste est un import que vous lancez et vérifiez.
L'angle européen
Pour les entreprises opérant en Europe, une dimension de conformité s'ajoute au coût. Code source, pipelines de build et artefacts comptent parmi les choses les plus sensibles que détient une entreprise technologique, et l'endroit où ils résident devient de plus en plus une question qu'on vous pose plutôt qu'une à laquelle vous choisissez de répondre.
L'auto-hébergement les place à l'intérieur d'un périmètre que vous contrôlez, ce qui simplifie d'un même geste l'analyse des transferts au titre du RGPD et les questions de chaîne d'approvisionnement de NIS2, et c'est le même argument de souveraineté autour duquel est bâti le Cloud and AI Development Act.
Le lien le plus net est le règlement sur la cyberrésilience. Si vous mettez du logiciel sur le marché européen, il vous faudra des inventaires de dépendances, un traitement des vulnérabilités et un processus de divulgation coordonnée. Ces obligations se satisfont dans le pipeline de build et non dans un document, et avoir le pipeline, le registre et l'analyse dans un seul système que vous exploitez rend la production des preuves nettement moins pénible que de les rassembler depuis quatre fournisseurs.
Quand s'abstenir
Si vous êtes moins de vingt ingénieurs, sans pression réglementaire ni conviction forte sur l'endroit où vit le code, prenez le SaaS. GitLab.com et GitHub sont tous deux excellents, et le travail d'exploitation coûtera plus cher que l'abonnement.
Si votre organisation est profondément installée dans l'écosystème GitHub, comptez honnêtement ce que vous perdriez. Actions, la marketplace et la simple familiarité de la plateforme chez chaque candidat que vous recrutez sont de vrais actifs, et la réponse n'est pas automatiquement que GitLab l'emporte.
Et si personne ne prend en charge l'instance, ne commencez pas. GitLab récompense celui qui applique les correctifs, surveille la flotte de runners et teste la restauration. Sans cette personne, cela dégénère en une machine non corrigée contenant votre actif le plus précieux, ce qui est pire que le SaaS que vous vouliez quitter.
Se faire aider
Nous déployons et exploitons des infrastructures de développement auto-hébergées pour des entreprises actives en Europe, y compris les parties que personne n'aime : séquences de mise à niveau à travers les étapes obligatoires, flottes de runners avec un autoscaling qui fonctionne, migrations vers le stockage objet, et schémas de sauvegarde qui ont réellement été restaurés.
Si vous voulez une instance GitLab dimensionnée honnêtement, une migration GitHub planifiée par quelqu'un qui a déjà fait la réécriture de CI, ou une revue destinée à savoir si votre sauvegarde actuelle survivrait à une vraie panne, écrivez à office@c9group.dev. Plus d'informations sur notre travail d'infrastructure sur la page d'optimisation des coûts AWS.
Si vous assemblez une pile auto-hébergée complète, le même raisonnement vaut pour les statistiques, l'automatisation marketing et la messagerie d'équipe.
Publié le 8 août 2026 Catégories : DevOps, Open Source, Confidentialité