Architecture de GitLab
Une instance GitLab, meme petite, fait tourner un nombre significatif de composants. Comprendre leur role permet de diagnostiquer les pannes, dimensionner les ressources et planifier la haute disponibilite.
Composants principaux
- Puma : serveur d'application Ruby on Rails, expose l'interface web et l'API
- Sidekiq : traitement des jobs asynchrones (emails, pipelines CI, webhooks, imports...)
- GitLab Workhorse : proxy leger (Go) devant Puma, gere les uploads de fichiers volumineux, les operations Git HTTP, les websockets
- NGINX : reverse proxy frontal, TLS termination
- PostgreSQL : base de donnees principale (projets, utilisateurs, MR, issues, CI...)
- Redis : cache, sessions, queues Sidekiq, pub/sub ActionCable
- Gitaly : service gRPC qui abstrait toutes les operations Git sur les depots
- GitLab Shell : gere les connexions SSH et les acces Git over SSH
- Registry : Docker Registry v2, optionnel
- Minio / Object Storage : stockage des artefacts CI, LFS, uploads, packages
Gitaly en detail
Gitaly est le composant le plus souvent mal dimensionne. Il remplace les appels directs a git dans le systeme de fichiers par un service RPC. L'avantage : isolation, observabilite, et possibilite de distribuer les depots sur plusieurs serveurs Gitaly (Gitaly Cluster). L'inconvenient : latence supplementaire et consommation memoire.
En production, Gitaly consomme facilement plusieurs Go de RAM sur une instance active. Le stockage des depots doit etre rapide (NVMe) : Gitaly effectue beaucoup de lectures aleatoires.
Architectures de reference
GitLab publie des architectures de reference dimensionnees par nombre d'utilisateurs :
- 1 000 users : single node, 8 vCPU / 16 GB RAM
- 3 000 users : 4-5 noeuds (PostgreSQL separe, Redis separe)
- 10 000 users : architecture distribuee complete, Gitaly Cluster, PgBouncer, Consul
- 50 000+ users : architectures specialisees, Gitaly Cluster obligatoire
Pour la majorite des organisations (moins de 500 utilisateurs actifs), un single node correctement dimensionne suffit largement. La haute disponibilite a un cout operationnel eleve et se justifie principalement pour les equipes qui ont une dependance critique sur la disponibilite de leur forge.
Stockage objet
GitLab supporte le stockage objet S3-compatible pour les artefacts CI, les backups, les uploads LFS, les packages. En production, externaliser le stockage objet est fortement recommande : ca simplifie les backups, les migrations et la haute disponibilite. Minio fonctionne tres bien en self-hosted.