Gitaly
- Tier: Free, Premium, Ultimate
- Offering: GitLab Self-Managed
Gitaly 为 Git 仓库提供高级远程过程调用（RPC）访问接口。 GitLab 使用它来读取和写入 Git 数据。
每个 GitLab 安装中都包含 Gitaly，它负责协调 Git 仓库的存储和检索。Gitaly 可以是：
- 在单实例 Linux 包安装上运行的后台服务（所有 GitLab 组件都在一台机器上）。
- 根据扩展和可用性需求，分离到自己的实例上，并配置为完整的集群架构。
Gitaly 仅管理 GitLab 的 Git 仓库访问。其他类型的 GitLab 数据不通过 Gitaly 访问。
GitLab 通过配置的仓库存储访问仓库。每个新仓库根据其配置的权重存储在其中一个仓库存储中。每个仓库存储可以是：
- 使用存储路径直接访问仓库的 Gitaly 存储，其中每个仓库存储在单个 Gitaly 节点上。所有请求都路由到此节点。
- 由Gitaly Cluster (Praefect)提供的虚拟存储，其中每个仓库可以存储在多个 Gitaly 节点上以实现容错。使用 Gitaly Cluster (Praefect)：
- 读请求在多个 Gitaly 节点之间分发，可以提高性能。
- 写请求会广播到仓库副本。
以下展示了设置为直接访问 Gitaly 的 GitLab：
在此示例中：
- 每个仓库存储在三个 Gitaly 存储之一中：
storage-1、storage-2或storage-3。 - 每个存储由一个 Gitaly 节点提供服务。
- 三个 Gitaly 节点在其文件系统上存储数据。
磁盘要求
Gitaly 和 Gitaly Cluster (Praefect) 需要快速的本地存储才能有效运行，因为它们是重 I/O 的进程。因此，我们强烈建议所有 Gitaly 节点使用固态硬盘（SSD）。这些 SSD 应该具有高读写吞吐量，因为 Gitaly 同时处理许多小文件。
作为参考，以下图表显示了 GitLab.com 上 Gitaly 生产集群的 P99 磁盘 IOPS，粒度为一分钟。数据是从一个具有代表性的七天期间查询的，开始和结束时间都是周一早上。请注意 IOPS 在工作周期间流量增加时的规律性峰值。原始数据显示更大的峰值，写入峰值达到 8000 IOPS。可用的磁盘吞吐量必须能够处理这些峰值，以避免对 Gitaly 请求造成中断。
-
P99 磁盘 IOPS（读取）：
-
P99 磁盘 IOPS（写入）：
我们通常看到：
- 每秒 500 - 1000 次读取，峰值达到每秒 3500 次读取。
- 每秒约 500 次写入，峰值超过每秒 3000 次写入。
截至撰写本文时，大多数 Gitaly 集群是使用 pd-ssd 磁盘的 t2d-standard-32 实例。宣称的最大写入和读取 IOPS 为 60,000。
GitLab.com 还对昂贵的 Git 操作实施了更严格的并发限制，这些限制在 GitLab Self-Managed 实例上默认未启用。放宽的并发限制、对特别大型 monorepo 的操作，或使用pack-objects 缓存也会显著增加磁盘活动。
在实际环境中，您在 Gitaly 实例上观察到的磁盘活动可能与这些发布的结果有很大差异。如果您在云环境中运行，选择更大的实例通常会增加可用的磁盘 IOPS。您也可以选择具有保证吞吐量的预配置 IOPS 磁盘类型。请参考您的云提供商文档以了解如何正确配置 IOPS。
出于性能和一致性原因，对于仓库数据，Gitaly 和 Gitaly Cluster (Praefect) 仅支持本地存储。不支持诸如NFS或基于云的文件系统等替代方案。
Gitaly 架构
Gitaly 实现了客户端-服务器架构：
- Gitaly 服务器是任何运行 Gitaly 本身的节点。
- Gitaly 客户端是任何运行向 Gitaly 服务器发出请求的进程的节点。Gitaly 客户端也称为 Gitaly 消费者，包括：
以下说明了 Gitaly 客户端-服务器架构：
flowchart LR
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
Gitaly 在 Linux 包安装中预配置，该配置适用于最多 20 RPS / 1,000 用户。对于：
- 适用于最多 40 RPS / 2,000 用户的 Linux 包安装，请参阅特定的 Gitaly 配置说明。
- 自编译安装或自定义 Gitaly 安装，请参阅配置 Gitaly。
对于超过 2000 个执行每日 Git 写操作的活动用户的 GitLab 安装，使用 Gitaly Cluster (Praefect) 可能是最合适的。
Gitaly CLI
gitaly 命令是一个命令行界面，为 Gitaly 管理员提供额外的子命令。例如，Gitaly CLI 用于：
- 为仓库配置自定义 Git 钩子。
- 验证 Gitaly 配置文件。
- 验证内部 Gitaly API 是否可访问。
- 对磁盘上的仓库运行 Git 命令。
有关其他子命令的更多信息，请运行 sudo -u git -- /opt/gitlab/embedded/bin/gitaly --help。
备份仓库
使用 GitLab 以外的工具备份或同步仓库时，在复制仓库数据期间必须防止写入。
Bundle URIs
您可以将 Git bundle URIs 与 Gitaly 一起使用。更多信息，请参阅Bundle URIs 文档。
直接访问仓库
GitLab 不建议使用 Git 客户端或任何其他工具直接访问存储在磁盘上的 Gitaly 仓库，因为 Gitaly 正在不断改进和更改。这些改进可能会使您的假设失效，导致性能下降、不稳定甚至数据丢失。例如：
- Gitaly 具有诸如
info/refs公告缓存之类的优化，这些优化依赖于 Gitaly 使用官方 gRPC 接口控制和监控对仓库的访问。 - Gitaly Cluster (Praefect) 具有诸如容错和分布式读取之类的优化，这些优化依赖于 gRPC 接口和数据库来确定仓库状态。
直接访问 Git 仓库需要您自行承担风险，并且不受支持。