doc-locale/fr-fr/administration/gitaly/_index.md
{{< details >}}
{{< /details >}}
Gitaly fournit un accès de haut niveau par appel de procédure distante (RPC) aux dépôts Git. Il est utilisé par GitLab pour lire et écrire des données Git.
Gitaly est présent dans chaque installation GitLab et coordonne le stockage et la récupération des dépôts Git. Gitaly peut être :
[!note] Gitaly gère uniquement l'accès aux dépôts Git pour GitLab. Les autres types de données GitLab ne sont pas accessibles via Gitaly.
GitLab accède aux dépôts via les stockages de dépôts configurés. Chaque nouveau dépôt est stocké dans l'un des stockages de dépôts en fonction de leurs poids configurés. Chaque stockage de dépôt est soit :
Ce qui suit montre GitLab configuré pour utiliser l'accès direct à Gitaly :
Dans cet exemple :
storage-1, storage-2 ou storage-3.Gitaly et Gitaly Cluster (Praefect) nécessitent un stockage local rapide pour fonctionner efficacement, car ce sont des processus à forte intensité d'E/S. Par conséquent, nous recommandons vivement que tous les nœuds Gitaly utilisent des disques à état solide (SSD). Ces SSD doivent avoir un débit élevé en lecture et en écriture, car Gitaly traite simultanément de nombreux petits fichiers.
À titre de référence, les graphiques suivants montrent les IOPS disque P99 sur l'ensemble de la flotte de production Gitaly sur GitLab.com à une granularité d'une minute. Les données ont été extraites sur une période représentative de sept jours, commençant et se terminant un lundi matin. Notez les pics réguliers d'IOPS lorsque le trafic devient plus intense pendant la semaine de travail. Les données brutes montrent des pics encore plus importants, avec des écritures culminant à 8 000 IOPS. Le débit disque disponible doit gérer ces pics pour éviter les interruptions des requêtes Gitaly.
IOPS disque P99 (lectures) :
IOPS disque P99 (écritures) :
Nous observons généralement :
La majorité de la flotte Gitaly au moment de la rédaction sont des instances t2d-standard-32 avec des disques pd-ssd. Les IOPS maximaux annoncés en écriture et en lecture sont de 60 000.
GitLab.com applique également des limites de simultanéité plus strictes sur les opérations Git coûteuses qui ne sont pas activées par défaut sur les instances GitLab Self-Managed. Les limites de simultanéité assouplies, les opérations sur des monodépôts particulièrement volumineux, ou l'utilisation du cache pack-objects peuvent également augmenter significativement l'activité disque.
En pratique, dans votre propre environnement, l'activité disque que vous observez sur vos instances Gitaly peut varier considérablement par rapport à ces résultats publiés. Si vous fonctionnez dans un environnement cloud, le choix d'instances plus grandes augmente généralement les IOPS disque disponibles. Vous pouvez également choisir de sélectionner un type de disque IOPS provisionné avec un débit garanti. Consultez la documentation de votre fournisseur cloud pour savoir comment configurer correctement les IOPS.
Pour les données de dépôt, seul le stockage local est pris en charge pour Gitaly et Gitaly Cluster (Praefect) pour des raisons de performances et de cohérence. Les alternatives telles que NFS ou les systèmes de fichiers basés sur le cloud ne sont pas prises en charge.
Gitaly implémente une architecture client-serveur :
Ce qui suit illustre l'architecture client-serveur de Gitaly :
%%{init: { "fontFamily": "GitLab Sans" }}%%
flowchart LR
accTitle: Gitaly client-server architecture
accDescr: GitLab clients connect to Gitaly server through gRPC to access local filesystem and object storage.
subgraph Gitaly clients
Rails[GitLab Rails]
Workhorse[GitLab Workhorse]
Shell[GitLab Shell]
Zoekt[Zoekt Indexer]
Elasticsearch[Elasticsearch Indexer]
KAS["GitLab Agent for Kubernetes (KAS)"]
end
subgraph Gitaly
GitalyServer[Gitaly server]
end
FS[Local filesystem]
ObjectStorage[Object storage]
Rails -- gRPC --> Gitaly
Workhorse -- gRPC --> Gitaly
Shell -- gRPC --> Gitaly
Zoekt -- gRPC --> Gitaly
Elasticsearch -- gRPC --> Gitaly
KAS -- gRPC --> Gitaly
GitalyServer --> FS
GitalyServer -- TCP --> Workhorse
GitalyServer -- TCP --> ObjectStorage
Gitaly est préconfiguré avec une installation de package Linux, qui est une configuration adaptée jusqu'à 20 RPS / 1 000 utilisateurs. Pour :
Les installations GitLab pour plus de 2 000 utilisateurs actifs effectuant des opérations d'écriture Git quotidiennes peuvent être mieux adaptées à l'utilisation de Gitaly Cluster (Praefect).
{{< history >}}
gitaly git introduite dans GitLab 17.4.{{< /history >}}
La commande gitaly est une interface en ligne de commande qui fournit des sous-commandes supplémentaires pour les administrateurs Gitaly. Par exemple, l'interface en ligne de commande Gitaly est utilisée pour :
Pour plus d'informations sur les autres sous-commandes, exécutez sudo -u git -- /opt/gitlab/embedded/bin/gitaly --help.
Lors de la sauvegarde ou de la synchronisation de dépôts à l'aide d'outils autres que GitLab, vous devez empêcher les écritures lors de la copie des données du dépôt.
Vous pouvez utiliser les URI de bundle Git avec Gitaly. Pour plus d'informations, consultez la documentation sur les URI de bundle.
GitLab déconseille d'accéder directement aux dépôts Gitaly stockés sur disque avec un client Git ou tout autre outil, car Gitaly est continuellement amélioré et modifié. Ces améliorations peuvent invalider vos hypothèses, entraînant une dégradation des performances, une instabilité, voire une perte de données. Par exemple :
info/refs, qui repose sur le contrôle et la surveillance par Gitaly de l'accès aux dépôts via l'interface gRPC officielle.[!warning] L'accès direct aux dépôts Git est effectué à vos propres risques et n'est pas pris en charge.