doc-locale/fr-fr/install/requirements.md
{{< details >}}
{{< /details >}}
GitLab a des exigences d'installation spécifiques.
L'espace de stockage nécessaire dépend en grande partie de la taille des dépôts que vous souhaitez avoir dans GitLab. À titre indicatif, vous devriez disposer d'au moins autant d'espace libre que la taille combinée de tous vos dépôts.
Le package Linux nécessite environ 2,5 Go d'espace de stockage pour l'installation. Combiné avec PostgreSQL, les journaux, les fichiers temporaires et la surcharge du système d'exploitation, prévoyez au moins 40 Go d'espace disque pour une installation GitLab de base sans données de dépôt. Pour plus de flexibilité en matière de stockage, envisagez de monter votre disque dur via la gestion de volumes logiques. Vous devriez disposer d'un disque dur d'au moins 7 200 RPM ou d'un disque SSD pour réduire les temps de réponse.
Étant donné que les performances du système de fichiers peuvent affecter les performances globales de GitLab, vous devriez éviter d'utiliser des systèmes de fichiers basés sur le cloud pour le stockage.
Les exigences en matière de CPU dépendent du nombre d'utilisateurs et de la charge de travail attendue. La charge de travail inclut l'activité de vos utilisateurs, l'utilisation de l'automatisation et de la mise en miroir, ainsi que la taille du dépôt.
Pour un maximum de 20 requêtes par seconde ou 1 000 utilisateurs, vous devriez disposer de 8 vCPU. Pour plus d'utilisateurs ou une charge de travail plus élevée, consultez les architectures de référence.
Les exigences en matière de mémoire dépendent du nombre d'utilisateurs et de la charge de travail attendue. La charge de travail inclut l'activité de vos utilisateurs, l'utilisation de l'automatisation et de la mise en miroir, ainsi que la taille du dépôt.
Pour un maximum de 20 requêtes par seconde ou 1 000 utilisateurs, vous devriez disposer de 16 Go de mémoire. Pour plus d'utilisateurs ou une charge de travail plus élevée, consultez les architectures de référence.
Dans certains cas, GitLab peut fonctionner avec au moins 8 Go de mémoire. Pour plus d'informations, consultez l'exécution de GitLab dans un environnement à mémoire limitée.
PostgreSQL est la seule base de données prise en charge et est fournie avec le package Linux. Vous pouvez également utiliser une base de données PostgreSQL externe qui doit être configurée correctement.
Pour les versions suivantes de GitLab, utilisez ces versions de PostgreSQL :
| Version de GitLab | Version du chart Helm | Version minimale de PostgreSQL | Version maximale de PostgreSQL |
|---|---|---|---|
| 19.x | 10.x | 17.x | 17.x |
| 18.x | 9.x | 16.5 | 17.x (testé avec GitLab 17.10 et versions ultérieures) |
| 17.x | 8.x | 14.14 | 16.x (testé avec GitLab 16.10 et versions ultérieures) |
| 16.x | 7.x | 13.6 | 15.x (testé avec GitLab 16.1 et versions ultérieures) |
Les versions mineures de PostgreSQL n'incluent que des correctifs de bogues et de sécurité. Utilisez toujours la dernière version mineure pour éviter les problèmes connus dans PostgreSQL. Pour plus d'informations, consultez l'ticket 364763.
Pour utiliser une version majeure de PostgreSQL ultérieure à celle spécifiée, vérifiez si une version ultérieure est fournie avec le package Linux.
En fonction du nombre d'utilisateurs, le serveur PostgreSQL doit disposer de :
Pour installer des extensions, PostgreSQL nécessite des privilèges de super-utilisateur. Pour obtenir des instructions, consultez Gérer les extensions PostgreSQL.
| Extension | Version minimale de GitLab | Type | Base de données |
|---|---|---|---|
amcheck | 18.4 | Obligatoire | Principale |
btree_gist | 13.1 | Obligatoire | Principale |
pg_trgm | 8.6 | Obligatoire | Principale |
plpgsql | 11.7 | Obligatoire | Principale, bases de données de suivi secondaires Geo (version minimale 9.0) |
pg_stat_statements | - | Recommandé | Tous |
Pour GitLab Geo , vous devriez utiliser le package Linux ou des fournisseurs cloud validés pour installer GitLab. La compatibilité avec d'autres bases de données externes n'est pas garantie.
Pour plus d'informations, consultez les exigences pour l'exécution de Geo.
Lorsque vous modifiez les données de paramètres régionaux dans glibc, les fichiers de base de données PostgreSQL ne sont plus entièrement compatibles entre différents systèmes d'exploitation. Pour éviter la corruption d'index, vérifiez la compatibilité des paramètres régionaux lorsque vous :
Pour plus d'informations, consultez la mise à niveau des systèmes d'exploitation pour PostgreSQL.
Vous devriez créer ou utiliser des bases de données exclusivement pour GitLab, Geo , Gitaly Cluster (Praefect) ou d'autres composants. Ne créez pas et ne modifiez pas de bases de données, de schémas, d'utilisateurs ou d'autres propriétés, sauf lorsque vous suivez :
L'application GitLab principale utilise trois schémas :
public par défautgitlab_partitions_static (créé automatiquement)gitlab_partitions_dynamic (créé automatiquement)Lors des migrations de bases de données Rails, GitLab peut créer ou modifier des schémas ou des tables. Les migrations de bases de données sont testées par rapport à la définition du schéma dans la base de code GitLab. Si vous modifiez un schéma, les mises à niveau de GitLab pourraient échouer.
Voici quelques paramètres obligatoires pour les instances PostgreSQL gérées en externe.
| Paramètre ajustable | Valeur requise | Plus d'informations |
|---|---|---|
work_mem | minimum 8 MB | Cette valeur est la valeur par défaut du package Linux. Dans les déploiements de grande envergure, si les requêtes créent des fichiers temporaires, vous devriez augmenter ce paramètre. |
maintenance_work_mem | minimum 64 MB | Vous avez besoin de davantage pour les serveurs de base de données plus importants. |
max_connections | minimum 400 | Calculez en fonction de vos composants GitLab. Consultez la page Régler PostgreSQL pour obtenir des conseils détaillés. |
shared_buffers | minimum 2 GB | Vous avez besoin de plus pour les serveurs de base de données plus importants. La valeur par défaut du package Linux est définie à 25 % de la RAM du serveur. |
statement_timeout | 15000 à 60000 | Un délai d'expiration des instructions évite les problèmes incontrôlés liés aux verrous et au rejet de nouveaux clients par la base de données. Vous devriez utiliser des valeurs comprises entre 15 et 60 secondes (15 000 à 60 000 millisecondes), où une minute correspond au paramètre de délai d'expiration du rack Puma. |
hot_standby_feedback | on | Pour les configurations avec plusieurs nœuds et un équilibrage de charge de base de données configuré, assurez-vous que tous les nœuds réplica ont hot_standby_feedback activé pour éviter l'accumulation de retard. |
Vous pouvez configurer certains paramètres PostgreSQL pour la base de données spécifique, plutôt que pour toutes les bases de données sur le serveur.
statement_timeout sur une base de données ou un utilisateur spécifique, mais pas en tant qu'indicateur de base de données. Par exemple : ALTER DATABASE gitlab SET statement_timeout = '60s';Les paramètres Puma recommandés dépendent de votre installation. Par défaut, le package Linux utilise les paramètres recommandés.
Pour ajuster les paramètres Puma :
webservice.Le nombre recommandé de workers Puma dépend en grande partie de la capacité du CPU et de la mémoire. Par défaut, le package Linux utilise le nombre recommandé de workers. Pour plus d'informations sur la façon dont ce nombre est calculé, consultez puma.rb.
Un nœud ne doit jamais avoir moins de deux workers Puma. Par exemple, un nœud devrait avoir :
Par défaut, chaque worker Puma est limité à 1,2 Go de mémoire. Vous pouvez ajuster ce paramètre dans /etc/gitlab/gitlab.rb.
Vous pouvez également augmenter le nombre de workers Puma, à condition que la capacité CPU et mémoire soit suffisante. Un plus grand nombre de workers réduirait les temps de réponse et améliorerait la capacité à gérer les requêtes parallèles. Effectuez des tests pour vérifier le nombre optimal de workers pour votre installation.
Le nombre recommandé de threads Puma dépend de la mémoire totale du système. Un nœud devrait utiliser :
Un plus grand nombre de threads entraînerait un swap excessif et des performances réduites.
Redis ou Valkey stocke toutes les sessions utilisateur et les tâches en arrière-plan et nécessite environ 25 ko par utilisateur en moyenne.
Redis 7.2 ou Valkey 7.2 est requis. Pour plus d'informations sur les dates de fin de vie, consultez la documentation Redis.
Sidekiq utilise un processus multi-thread pour les tâches en arrière-plan. Ce processus consomme initialement plus de 200 Mo de mémoire et peut augmenter avec le temps en raison de fuites mémoire.
Sur un serveur très actif avec plus de 10 000 utilisateurs facturables, le processus Sidekiq peut consommer plus de 1 Go de mémoire.
Par défaut, Prometheus et ses exportateurs associés sont activés pour surveiller GitLab. Ces processus consomment environ 200 Mo de mémoire.
Pour plus d'informations, consultez la surveillance de GitLab avec Prometheus.
GitLab prend en charge les navigateurs web suivants :
GitLab prend en charge :
L'exécution de GitLab avec JavaScript désactivé dans ces navigateurs n'est pas prise en charge.