# Gitaly
> 原文：[https://docs.gitlab.com/ee/administration/gitaly/](https://docs.gitlab.com/ee/administration/gitaly/)
* [Architecture](#architecture)
* [Configure Gitaly](#configure-gitaly)
* [Run Gitaly on its own server](#run-gitaly-on-its-own-server)
* [Network architecture](#network-architecture)
* [Install Gitaly](#install-gitaly)
* [Configure authentication](#configure-authentication)
* [Configure Gitaly servers](#configure-gitaly-servers)
* [Configure Gitaly clients](#configure-gitaly-clients)
* [Mixed configuration](#mixed-configuration)
* [Disable Gitaly where not required (optional)](#disable-gitaly-where-not-required-optional)
* [Enable TLS support](#enable-tls-support)
* [Observe type of Gitaly connections](#observe-type-of-gitaly-connections)
* [`gitaly-ruby`](#gitaly-ruby)
* [Configure number of `gitaly-ruby` workers](#configure-number-of-gitaly-ruby-workers)
* [Limit RPC concurrency](#limit-rpc-concurrency)
* [Rotate Gitaly authentication token](#rotate-gitaly-authentication-token)
* [Verify authentication monitoring](#verify-authentication-monitoring)
* [Enable “auth transitioning” mode](#enable-auth-transitioning-mode)
* [Update Gitaly authentication token](#update-gitaly-authentication-token)
* [Ensure there are no authentication failures](#ensure-there-are-no-authentication-failures)
* [Disable “auth transitioning” mode](#disable-auth-transitioning-mode)
* [Verify authentication is enforced](#verify-authentication-is-enforced)
* [Direct Git access bypassing Gitaly](#direct-git-access-bypassing-gitaly)
* [Direct access to Git in GitLab](#direct-access-to-git-in-gitlab)
* [History](#history)
* [How it works](#how-it-works)
* [Transition to Gitaly Cluster](#transition-to-gitaly-cluster)
* [Troubleshooting Gitaly](#troubleshooting-gitaly)
* [Checking versions when using standalone Gitaly servers](#checking-versions-when-using-standalone-gitaly-servers)
* [`gitaly-debug`](#gitaly-debug)
* [Commits, pushes, and clones return a 401](#commits-pushes-and-clones-return-a-401)
* [Client side gRPC logs](#client-side-grpc-logs)
* [Observing `gitaly-ruby` traffic](#observing-gitaly-ruby-traffic)
* [Repository changes fail with a `401 Unauthorized` error](#repository-changes-fail-with-a-401-unauthorized-error)
* [Command line tools cannot connect to Gitaly](#command-line-tools-cannot-connect-to-gitaly)
* [Gitaly not listening on new address after reconfiguring](#gitaly-not-listening-on-new-address-after-reconfiguring)
* [Permission denied errors appearing in Gitaly logs when accessing repositories from a standalone Gitaly server](#permission-denied-errors-appearing-in-gitaly-logs-when-accessing-repositories-from-a-standalone-gitaly-server)
* [Praefect](#praefect)
# Gitaly[](#gitaly "Permalink")
[Gitaly](https://gitlab.com/gitlab-org/gitaly)是提供对 Git 存储库的高级 RPC 访问的服务. 没有它，任何 GitLab 组件都无法读取或写入 Git 数据.
在 Gitaly 文档中：
* **Gitaly 服务器**是指任何本身运行 Gitaly 的节点.
* **Gitaly 客户端**指的是任何运行向 Gitaly 服务器发出请求的进程的节点. 流程包括但不限于：
* [GitLab Rails 应用程序](https://gitlab.com/gitlab-org/gitlab) .
* [GitLab 外壳](https://gitlab.com/gitlab-org/gitlab-shell) .
* [亚搏体育 app Labhorse](https://gitlab.com/gitlab-org/gitlab-workhorse) .
GitLab 最终用户无法直接访问 Gitaly. Gitaly 仅管理 GitLab 的 Git 存储库访问. 其他类型的 GitLab 数据无法使用 Gitaly 访问.
**警告：**从 GitLab 13.0 起，不支持 Gitaly 对 NFS 的支持. 在 GitLab 14.0 中，计划删除对 NFS 的 Gitaly 支持. 尽快升级到[Gitaly Cluster](praefect.html) .
## Architecture[](#architecture "Permalink")
以下是有关如何使用 Gitaly 的高级体系结构概述.
[](img/architecture_v12_4.png)
## Configure Gitaly[](#configure-gitaly "Permalink")
Gitaly 服务本身是通过[TOML 配置文件配置的](reference.html) .
要更改 Gitaly 设置，请执行以下操作：
**对于所有 GitLab**
1. 编辑`/etc/gitlab/gitlab.rb`并添加或更改[Gitaly 设置](https://gitlab.com/gitlab-org/omnibus-gitlab/blob/1dd07197c7e5ae23626aad5a4a070a800b670380/files/gitlab-config-template/gitlab.rb.template#L1622-1676) .
2. 保存文件并[重新配置 GitLab](../restart_gitlab.html#omnibus-gitlab-reconfigure) .
**对于源安装**
1. 编辑`/home/git/gitaly/config.toml`并添加或更改[Gitaly 设置](https://gitlab.com/gitlab-org/gitaly/blob/master/config.toml.example) .
2. 保存文件并[重新启动 GitLab](../restart_gitlab.html#installations-from-source) .
以下配置选项也可用：
* Enabling [TLS support](#enable-tls-support).
* 配置[`gitaly-ruby`工人](#configure-number-of-gitaly-ruby-workers)的[数量](#configure-number-of-gitaly-ruby-workers) .
* Limiting [RPC concurrency](#limit-rpc-concurrency).
## Run Gitaly on its own server[](#run-gitaly-on-its-own-server "Permalink")
默认情况下，Gitaly 与 Gitaly 客户端在同一服务器上运行，并按[上述配置](#configure-gitaly) . 单服务器安装最好由以下默认配置使用：
* [Omnibus GitLab](https://docs.gitlab.com/omnibus/).
* GitLab [源代码安装指南](../../install/installation.html) .
However, Gitaly can be deployed to its own server, which can benefit GitLab installations that span multiple machines.
**注意：**配置为在自己的服务器上运行时， [必须先升级](https://docs.gitlab.com/omnibus/update/) Gitaly 服务器，然后才能在群集中的 Gitaly 客户端上[进行升级](https://docs.gitlab.com/omnibus/update/) .
在自己的服务器上设置 Gitaly 的过程是：
1. [Install Gitaly](#install-gitaly).
2. [Configure authentication](#configure-authentication).
3. [Configure Gitaly servers](#configure-gitaly-servers).
4. [Configure Gitaly clients](#configure-gitaly-clients).
5. [Disable Gitaly where not required](#disable-gitaly-where-not-required-optional) (optional).
在自己的服务器上运行 Gitaly 时，请注意有关 GitLab 版本的以下内容：
* 从 GitLab 11.4 起，除了[Elasticsearch indexer](https://gitlab.com/gitlab-org/gitlab-elasticsearch-indexer)之外，Gitaly 能够满足所有 Git 请求，而无需为 Git 存储库数据共享 NFS 挂载.
* 从 GitLab 11.8 开始，Elasticsearch 索引器还使用 Gitaly 进行数据访问. NFS 仍可用于块级 Git 数据的冗余，但仅需安装在 Gitaly 服务器上.
* 从 GitLab 11.8 到 12.2，可以在不使用 NFS 的 Gitaly 设置中使用 Elasticsearch. 为了在这些版本中使用 Elasticsearch，必须在您的 GitLab 配置中启用[存储库索引器](../../integration/elasticsearch.html#elasticsearch-repository-indexer) .
* [从 GitLab 12.3 开始](https://gitlab.com/gitlab-org/gitlab/-/issues/6481) ，新的索引器是默认的，不需要任何配置.
### Network architecture[](#network-architecture "Permalink")
以下列表描述了 Gitaly 的网络体系结构：
* GitLab Rails shards repositories into [repository storages](../repository_storage_paths.html).
* `/config/gitlab.yml`包含从存储名称到`(Gitaly address, Gitaly token)`对的`(Gitaly address, Gitaly token)` .
* `/config/gitlab.yml`的`storage name` -> `(Gitaly address, Gitaly token)`映射是 Gitaly 网络拓扑的唯一事实来源.
* `(Gitaly address, Gitaly token)`对应于 Gitaly 服务器.
* Gitaly 服务器托管一个或多个存储.
* 一个 Gitaly 客户端可以使用一个或多个 Gitaly 服务器.
* 必须以对**所有** Gitaly 客户端正确解析的方式指定 Gitaly 地址.
* Gitaly 客户包括：
* 美洲狮或独角兽.
* Sidekiq.
* 亚搏体育 app Labhorse.
* GitLab 外壳.
* Elasticsearch 索引器.
* Gitaly 本身.
* 一个 Gitaly 服务器必须能够通过其自身发出 RPC 调用**本身** `(Gitaly address, Gitaly token)`在指定的一对`/config/gitlab.yml` .
* 认证通过静态令牌完成，该令牌在 Gitaly 和 GitLab Rails 节点之间共享.
**危险：** Gitaly 服务器不得暴露于公共互联网，因为默认情况下 Gitaly 的网络流量未加密. 强烈建议使用防火墙，以限制对 Gitaly 服务器的访问. 另一种选择是[使用 TLS](#enable-tls-support) .
在以下各节中，我们描述如何使用秘密令牌`abc123secret`配置两个 Gitaly 服务器：
* `gitaly1.internal`.
* `gitaly2.internal`.
我们假设您的 GitLab 安装具有三个存储库存储：
* `default`.
* `storage1`.
* `storage2`.
如果需要，一台服务器最多只能使用一个存储库.
**注意：** Gitaly 文档中引用的令牌只是管理员选择的任意密码. 它与为 GitLab API 创建的令牌或其他类似的 Web API 令牌无关.
### Install Gitaly[](#install-gitaly "Permalink")
使用 Omnibus GitLab 在每台 Gitaly 服务器上安装 Gitaly 或从源代码安装它：
* 对于 Omnibus GitLab，请[下载并安装](https://about.gitlab.com/install/)所需的 Omnibus GitLab 软件包，但**不要**提供`EXTERNAL_URL=`值.
* 要从源代码安装，请遵循[Install Gitaly 上](../../install/installation.html#install-gitaly)的步骤.
### Configure authentication[](#configure-authentication "Permalink")
Gitaly 和 GitLab 使用两个共享的机密进行身份验证：
* 一种用于向 Gitaly 验证 gRPC 请求的身份.
* A second for authentication callbacks from GitLab Shell to the GitLab internal API.
**对于所有 GitLab**
要配置 Gitaly 令牌：
1. 在 Gitaly 客户端上，编辑`/etc/gitlab/gitlab.rb` ：
```
gitlab_rails['gitaly_token'] = 'abc123secret'
```
2. 保存文件并[重新配置 GitLab](../restart_gitlab.html#omnibus-gitlab-reconfigure) .
3. 在 Gitaly 服务器上，编辑`/etc/gitlab/gitlab.rb` ：
```
gitaly['auth_token'] = 'abc123secret'
```
4. [Reconfigure GitLab](../restart_gitlab.html#omnibus-gitlab-reconfigure).
有两种方法可以配置 GitLab Shell 令牌.
方法 1：
1. 将`/etc/gitlab/gitlab-secrets.json`从 Gitaly 客户端复制到 Gitaly 服务器（和任何其他 Gitaly 客户端）上的相同路径.
2. 在 Gitaly 服务器上[重新配置 GitLab](../restart_gitlab.html#omnibus-gitlab-reconfigure) .
方法 2：
1. 在 Gitaly 客户端上，编辑`/etc/gitlab/gitlab.rb` ：
```
gitlab_shell['secret_token'] = 'shellsecret'
```
2. 保存文件并[重新配置 GitLab](../restart_gitlab.html#omnibus-gitlab-reconfigure) .
3. 在 Gitaly 服务器上，编辑`/etc/gitlab/gitlab.rb` ：
```
gitlab_shell['secret_token'] = 'shellsecret'
```
4. [Reconfigure GitLab](../restart_gitlab.html#omnibus-gitlab-reconfigure).
**对于源安装**
1. 将`/home/git/gitlab/.gitlab_shell_secret`从 Gitaly 客户端复制到 Gitaly 服务器（和任何其他 Gitaly 客户端）上的相同路径.
2. 在 Gitaly 客户端上，编辑`/home/git/gitlab/config/gitlab.yml` ：
```
gitlab:
gitaly:
token: 'abc123secret'
```
3. 保存文件并[重新启动 GitLab](../restart_gitlab.html#installations-from-source) .
4. 在 Gitaly 服务器上，编辑`/home/git/gitaly/config.toml` ：
```
[auth]
token = 'abc123secret'
```
5. 保存文件并[重新启动 GitLab](../restart_gitlab.html#installations-from-source) .
### Configure Gitaly servers[](#configure-gitaly-servers "Permalink")
在 Gitaly 服务器上，您必须配置存储路径并启用网络侦听器.
如果要减少启用身份验证时发生停机的风险，可以暂时禁用强制实施. 有关更多信息，请参阅有关配置[Gitaly 身份验证](https://gitlab.com/gitlab-org/gitaly/blob/master/doc/configuration/README.md#authentication)的文档.
**对于所有 GitLab**
1. Edit `/etc/gitlab/gitlab.rb`:
```
# /etc/gitlab/gitlab.rb
# Avoid running unnecessary services on the Gitaly server
postgresql['enable'] = false
redis['enable'] = false
nginx['enable'] = false
puma['enable'] = false
sidekiq['enable'] = false
gitlab_workhorse['enable'] = false
grafana['enable'] = false
gitlab_exporter['enable'] = false
# If you run a separate monitoring node you can disable these services
alertmanager['enable'] = false
prometheus['enable'] = false
# If you don't run a separate monitoring node you can
# enable Prometheus access & disable these extra services.
# This makes Prometheus listen on all interfaces. You must use firewalls to restrict access to this address/port.
# prometheus['listen_address'] = '0.0.0.0:9090'
# prometheus['monitor_kubernetes'] = false
# If you don't want to run monitoring services uncomment the following (not recommended)
# node_exporter['enable'] = false
# Prevent database connections during 'gitlab-ctl reconfigure'
gitlab_rails['rake_cache_clear'] = false
gitlab_rails['auto_migrate'] = false
# Configure the gitlab-shell API callback URL. Without this, `git push` will
# fail. This can be your 'front door' GitLab URL or an internal load
# balancer.
# Don't forget to copy `/etc/gitlab/gitlab-secrets.json` from Gitaly client to Gitaly server.
gitlab_rails['internal_api_url'] = 'https://gitlab.example.com'
# Make Gitaly accept connections on all network interfaces. You must use
# firewalls to restrict access to this address/port.
# Comment out following line if you only want to support TLS connections
gitaly['listen_addr'] = "0.0.0.0:8075"
```
2. 对于每个相应的 Gitaly 服务器，将以下内容附加到`/etc/gitlab/gitlab.rb` ：
On `gitaly1.internal`:
```
git_data_dirs({
'default' => {
'path' => '/var/opt/gitlab/git-data'
},
'storage1' => {
'path' => '/mnt/gitlab/git-data'
},
})
```
On `gitaly2.internal`:
```
git_data_dirs({
'storage2' => {
'path' => '/srv/gitlab/git-data'
},
})
```
3. 保存文件并[重新配置 GitLab](../restart_gitlab.html#omnibus-gitlab-reconfigure) .
4. 运行`sudo /opt/gitlab/embedded/service/gitlab-shell/bin/check -config /opt/gitlab/embedded/service/gitlab-shell/config.yml`以确认 Gitaly 可以执行对 GitLab 内部 API 的回调.
**对于源安装**
1. Edit `/home/git/gitaly/config.toml`:
```
listen_addr = '0.0.0.0:8075'
internal_socket_dir = '/var/opt/gitlab/gitaly'
[logging]
format = 'json'
level = 'info'
dir = '/var/log/gitaly'
```
2. 对于每个相应的 Gitaly 服务器，将以下内容附加到`/home/git/gitaly/config.toml` ：
On `gitaly1.internal`:
```
[[storage]]
name = 'default'
path = '/var/opt/gitlab/git-data/repositories'
[[storage]]
name = 'storage1'
path = '/mnt/gitlab/git-data/repositories'
```
On `gitaly2.internal`:
```
[[storage]]
name = 'storage2'
path = '/srv/gitlab/git-data/repositories'
```
3. Edit `/home/git/gitlab-shell/config.yml`:
```
gitlab_url: https://gitlab.example.com
```
4. 保存文件并[重新启动 GitLab](../restart_gitlab.html#installations-from-source) .
5. 运行`sudo -u git /home/git/gitlab-shell/bin/check -config /home/git/gitlab-shell/config.yml`以确认 Gitaly 可以执行对 GitLab 内部 API 的回调.
### Configure Gitaly clients[](#configure-gitaly-clients "Permalink")
最后一步，您必须更新 Gitaly 客户端，使其从使用本地 Gitaly 服务切换为使用刚配置的 Gitaly 服务器.
这可能会有风险，因为任何阻止您的 Gitaly 客户端访问 Gitaly 服务器的操作都将导致所有 Gitaly 请求失败. 例如，任何类型的网络，防火墙或名称解析问题.
此外，如果以前手动启用，则必须[禁用 Rugged](../high_availability/nfs.html#improving-nfs-performance-with-gitlab) .
Gitaly 作以下假设：
* 你`gitaly1.internal` Gitaly 服务器可以达到`gitaly1.internal:8075`从 Gitaly 客户端，以及 Gitaly 服务器可以读取和写入`/mnt/gitlab/default`和`/mnt/gitlab/storage1` .
* 你`gitaly2.internal` Gitaly 服务器可以达到`gitaly2.internal:8075`从 Gitaly 客户端，以及 Gitaly 服务器可以读取和写入`/mnt/gitlab/storage2` .
* 您的`gitaly1.internal`和`gitaly2.internal` Gitaly 服务器可以相互访问.
除非您使用特殊的[混合配置进行](#mixed-configuration)设置，否则不能将 Gitaly 服务器定义为本地 Gitaly 服务器（不带`gitaly_address` ），而`gitaly_address`一些服务器定义为远程服务器（带`gitaly_address` ）.
**对于所有 GitLab**
1. Edit `/etc/gitlab/gitlab.rb`:
```
git_data_dirs({
'default' => { 'gitaly_address' => 'tcp://gitaly1.internal:8075' },
'storage1' => { 'gitaly_address' => 'tcp://gitaly1.internal:8075' },
'storage2' => { 'gitaly_address' => 'tcp://gitaly2.internal:8075' },
})
```
2. 保存文件并[重新配置 GitLab](../restart_gitlab.html#omnibus-gitlab-reconfigure) .
3. 运行`sudo gitlab-rake gitlab:gitaly:check`确认 Gitaly 客户端可以连接到 Gitaly 服务器.
4. 拖尾日志以查看请求：
```
sudo gitlab-ctl tail gitaly
```
**对于源安装**
1. Edit `/home/git/gitlab/config/gitlab.yml`:
```
gitlab:
repositories:
storages:
default:
gitaly_address: tcp://gitaly1.internal:8075
path: /some/dummy/path
storage1:
gitaly_address: tcp://gitaly1.internal:8075
path: /some/dummy/path
storage2:
gitaly_address: tcp://gitaly2.internal:8075
path: /some/dummy/path
```
**注意：** `/some/dummy/path`应该设置为存在的本地文件夹，但是该文件夹中不会存储任何数据. 解决[此问题](https://gitlab.com/gitlab-org/gitaly/-/issues/1282)后，将不再需要[此操作](https://gitlab.com/gitlab-org/gitaly/-/issues/1282) .
2. Save the file and [restart GitLab](../restart_gitlab.html#installations-from-source).
3. 运行`sudo -u git -H bundle exec rake gitlab:gitaly:check RAILS_ENV=production`确认 Gitaly 客户端可以连接到 Gitaly 服务器.
4. 拖尾日志以查看请求：
```
tail -f /home/git/gitlab/log/gitaly.log
```
尾随 Gitaly 服务器上的 Gitaly 登录时，您应该会看到请求进入.触发 Gitaly 请求的一种可靠方法是通过 HTTP 或 HTTPS 从 GitLab 克隆存储库.
**危险：**如果已针对每个存储库或全局配置了[服务器挂钩](../server_hooks.html) ，则必须将它们移至 Gitaly 服务器. 如果您有多个 Gitaly 服务器，则将服务器挂钩复制到所有 Gitaly 服务器.
#### Mixed configuration[](#mixed-configuration "Permalink")
GitLab 可以与许多 Gitaly 服务器之一驻留在同一服务器上，但是不支持混合本地和远程配置的配置. 以下设置不正确，因为：
* 所有地址都必须可从其他 Gitaly 服务器访问.
* `storage1`分配了一个`gitaly_address` Unix 套接字，该套接字对于某些 Gitaly 服务器无效.
```
git_data_dirs({
'default' => { 'gitaly_address' => 'tcp://gitaly1.internal:8075' },
'storage1' => { 'path' => '/mnt/gitlab/git-data' },
'storage2' => { 'gitaly_address' => 'tcp://gitaly2.internal:8075' },
})
```
要组合本地和远程 Gitaly 服务器，请为本地 Gitaly 服务器使用一个外部地址. 例如：
```
git_data_dirs({
'default' => { 'gitaly_address' => 'tcp://gitaly1.internal:8075' },
# Address of the GitLab server that has Gitaly running on it
'storage1' => { 'gitaly_address' => 'tcp://gitlab.internal:8075', 'path' => '/mnt/gitlab/git-data' },
'storage2' => { 'gitaly_address' => 'tcp://gitaly2.internal:8075' },
})
```
`path`只能包含在本地 Gitaly 服务器上的存储分片中. 如果不包含，则默认的 Git 存储目录将用于该存储碎片.
### Disable Gitaly where not required (optional)[](#disable-gitaly-where-not-required-optional "Permalink")
如果您将 Gitaly [作为远程服务](#run-gitaly-on-its-own-server)运行，则可能要禁用默认情况下在您的 GitLab 服务器上运行的本地 Gitaly 服务，而仅在需要时运行它.
仅当您在自定义群集配置中运行 GitLab 时，才在 GitLab 实例上禁用 Gitaly 才有意义，在该配置中，Gitaly 在与 GitLab 实例不同的机器上运行. 在群集中的所有计算机上禁用 Gitaly 并不是有效的配置（某些计算机充当 Gitaly 服务器）.
To disable Gitaly on a GitLab server:
**对于所有 GitLab**
1. Edit `/etc/gitlab/gitlab.rb`:
```
gitaly['enable'] = false
```
2. 保存文件并[重新配置 GitLab](../restart_gitlab.html#omnibus-gitlab-reconfigure) .
**对于源安装**
1. Edit `/etc/default/gitlab`:
```
gitaly_enabled=false
```
2. 保存文件并[重新启动 GitLab](../restart_gitlab.html#installations-from-source) .
## Enable TLS support[](#enable-tls-support "Permalink")
在 GitLab 11.8 中[引入](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/22602) .
Gitaly 支持 TLS 加密. 要与侦听安全连接的 Gitaly 实例进行通信，必须在 GitLab 配置中相应存储条目的`gitaly_address`中使用`tls://` URL 方案.
您必须提供自己的证书，因为不会自动提供. 与每个 Gitaly 服务器相对应的证书必须安装在该 Gitaly 服务器上.
此外，证书（或其证书颁发机构）必须安装在所有以下组件上：
* Gitaly 服务器，包括使用证书的 Gitaly 服务器.
* 与之通信的 Gitaly 客户.
该过程记录在[GitLab 自定义证书配置中，](https://docs.gitlab.com/omnibus/settings/ssl.html)并在下面重复进行.
请注意以下几点：
* 证书必须指定用于访问 Gitaly 服务器的地址. 如果你是：
* 通过主机名寻址 Gitaly 服务器，您可以为此使用"公用名"字段，也可以将其添加为"使用者备用名".
* 通过其 IP 地址寻址 Gitaly 服务器，必须将其作为主题备用名称添加到证书中. [gRPC 不支持在证书中使用 IP 地址作为公用名](https://github.com/grpc/grpc/issues/2691) .
* 您可以同时为 Gitaly 服务器配置未加密的侦听地址`listen_addr`和已加密的侦听地址`tls_listen_addr` . 这使您可以根据需要从未加密的流量逐渐过渡到加密的流量.
要使用 TLS 配置 Gitaly：
**对于所有 GitLab**
1. 为 Gitaly 服务器创建证书.
2. 在 Gitaly 客户端上，将证书（或其证书颁发机构）复制到`/etc/gitlab/trusted-certs` ：
```
sudo cp cert.pem /etc/gitlab/trusted-certs/
```
3. 在 Gitaly 客户端上，如下所示在`/etc/gitlab/gitlab.rb`编辑`git_data_dirs` ：
```
git_data_dirs({
'default' => { 'gitaly_address' => 'tls://gitaly1.internal:9999' },
'storage1' => { 'gitaly_address' => 'tls://gitaly1.internal:9999' },
'storage2' => { 'gitaly_address' => 'tls://gitaly2.internal:9999' },
})
```
4. 保存文件并[重新配置 GitLab](../restart_gitlab.html#omnibus-gitlab-reconfigure) .
5. 在 Gitaly 服务器上，创建`/etc/gitlab/ssl`目录，然后在其中复制密钥和证书：
```
sudo mkdir -p /etc/gitlab/ssl
sudo chmod 755 /etc/gitlab/ssl
sudo cp key.pem cert.pem /etc/gitlab/ssl/
sudo chmod 644 key.pem cert.pem
```
6. 将所有 Gitaly 服务器证书（或其证书颁发机构）复制到`/etc/gitlab/trusted-certs`以便 Gitaly 服务器在调用自身或其他 Gitaly 服务器时将信任该证书：
```
sudo cp cert1.pem cert2.pem /etc/gitlab/trusted-certs/
```
7. 编辑`/etc/gitlab/gitlab.rb`并添加：
```
gitaly['tls_listen_addr'] = "0.0.0.0:9999"
gitaly['certificate_path'] = "/etc/gitlab/ssl/cert.pem"
gitaly['key_path'] = "/etc/gitlab/ssl/key.pem"
```
8. 保存文件并[重新配置 GitLab](../restart_gitlab.html#omnibus-gitlab-reconfigure) .
9. 通过[观察 Gitaly 连接的类型，](#observe-type-of-gitaly-connections)验证通过 TLS 提供服务的 Gitaly 通信.
10. （可选）通过以下方式提高安全性：
1. 通过注释或删除禁用非 TLS 连接`gitaly['listen_addr']`中`/etc/gitlab/gitlab.rb` .
2. 保存文件.
3. [重新配置 GitLab](../restart_gitlab.html#omnibus-gitlab-reconfigure) .
**对于源安装**
1. 为 Gitaly 服务器创建证书.
2. 在 Gitaly 客户端上，将证书复制到系统受信任的证书中：
```
sudo cp cert.pem /usr/local/share/ca-certificates/gitaly.crt
sudo update-ca-certificates
```
3. 在 Gitaly 客户端上，如下所示在`/home/git/gitlab/config/gitlab.yml`编辑`storages` ：
```
gitlab:
repositories:
storages:
default:
gitaly_address: tls://gitaly1.internal:9999
path: /some/dummy/path
storage1:
gitaly_address: tls://gitaly1.internal:9999
path: /some/dummy/path
storage2:
gitaly_address: tls://gitaly2.internal:9999
path: /some/dummy/path
```
**注意：** `/some/dummy/path`应该设置为存在的本地文件夹，但是该文件夹中不会存储任何数据. 解决[Gitaly 问题＃1282](https://gitlab.com/gitlab-org/gitaly/-/issues/1282)之后，将不再需要此操作.
4. 保存文件并[重新启动 GitLab](../restart_gitlab.html#installations-from-source) .
5. 在 Gitaly 服务器上，创建或编辑`/etc/default/gitlab`并添加：
```
export SSL_CERT_DIR=/etc/gitlab/ssl
```
6. 在 Gitaly 服务器上，创建`/etc/gitlab/ssl`目录，然后在其中复制密钥和证书：
```
sudo mkdir -p /etc/gitlab/ssl
sudo chmod 755 /etc/gitlab/ssl
sudo cp key.pem cert.pem /etc/gitlab/ssl/
sudo chmod 644 key.pem cert.pem
```
7. 将所有 Gitaly 服务器证书（或其证书颁发机构）复制到系统受信任证书文件夹，以便 Gitaly 服务器在调用自身或其他 Gitaly 服务器时将信任该证书.
```
sudo cp cert.pem /usr/local/share/ca-certificates/gitaly.crt
sudo update-ca-certificates
```
8. 编辑`/home/git/gitaly/config.toml`并添加：
```
tls_listen_addr = '0.0.0.0:9999'
[tls]
certificate_path = '/etc/gitlab/ssl/cert.pem'
key_path = '/etc/gitlab/ssl/key.pem'
```
9. 保存文件并[重新启动 GitLab](../restart_gitlab.html#installations-from-source) .
10. 通过[观察 Gitaly 连接的类型，](#observe-type-of-gitaly-connections)验证通过 TLS 提供服务的 Gitaly 通信.
11. （可选）通过以下方式提高安全性：
1. 通过注释掉或删除`/home/git/gitaly/config.toml` `listen_addr`来禁用非 TLS 连接.
2. 保存文件.
3. [重新启动 GitLab](../restart_gitlab.html#installations-from-source) .
### Observe type of Gitaly connections[](#observe-type-of-gitaly-connections "Permalink")
可以使用[Prometheus](../monitoring/prometheus/index.html)观察 Gitaly 为生产环境提供服务的连接类型. 使用以下 Prometheus 查询：
```
sum(rate(gitaly_connections_total[5m])) by (type)
```
## `gitaly-ruby`[](#gitaly-ruby "Permalink")
开发 Gitaly 是为了替代 GitLab 中的 Ruby 应用程序代码.
为了节省时间并避免重写现有应用程序逻辑的风险，我们选择将一些应用程序代码从 GitLab 复制到 Gitaly.
为了能够运行该代码，创建了`gitaly-ruby` ，它是主要 Gitaly Go 流程的" sidecar"流程. 在`gitaly-ruby`中实现的一些示例如下：
* 处理 Wiki 的 RPC.
* 代表用户创建提交的 RPC，例如合并提交.
### Configure number of `gitaly-ruby` workers[](#configure-number-of-gitaly-ruby-workers "Permalink")
`gitaly-ruby`容量比 Go 中实现的 Gitaly 少得多. 如果您的 Gitaly 服务器必须处理大量请求，则仅设置一个活动的`gitaly-ruby`车的默认设置可能不够.
如果您看到 Gitaly 出现`ResourceExhausted`错误，则很可能是您的`gitaly-ruby`能力不足.
您可以使用以下设置来增加 Gitaly 服务器上的`gitaly-ruby`进程数：
**对于所有 GitLab**
1. Edit `/etc/gitlab/gitlab.rb`:
```
# Default is 2 workers. The minimum is 2; 1 worker is always reserved as
# a passive stand-by.
gitaly['ruby_num_workers'] = 4
```
2. 保存文件并[重新配置 GitLab](../restart_gitlab.html#omnibus-gitlab-reconfigure) .
**对于源安装**
1. Edit `/home/git/gitaly/config.toml`:
```
[gitaly-ruby]
num_workers = 4
```
2. 保存文件并[重新启动 GitLab](../restart_gitlab.html#installations-from-source) .
## Limit RPC concurrency[](#limit-rpc-concurrency "Permalink")
克隆流量可能会对您的 Gitaly 服务造成很大的压力. 大部分工作在以下任一 RPC 中完成：
* `SSHUploadPack` （用于 Git SSH）.
* `PostUploadPack` （用于 Git HTTP）.
为了防止此类工作负载使您的 Gitaly 服务器不堪重负，您可以在 Gitaly 的配置文件中设置并发限制. 例如：
```
# in /etc/gitlab/gitlab.rb
gitaly['concurrency'] = [
{
'rpc' => "/gitaly.SmartHTTPService/PostUploadPack",
'max_per_repo' => 20
},
{
'rpc' => "/gitaly.SSHService/SSHUploadPack",
'max_per_repo' => 20
}
]
```
这限制了给定 RPC 正在进行的 RPC 调用的数量. 该限制适用于每个存储库. 在上面的示例中：
* Gitaly 服务器提供服务的每个存储库最多可以同时`PostUploadPack` 20 个`PostUploadPack` RPC 调用，而`SSHUploadPack`则相同.
* 如果另一个请求进入了已用完其 20 个插槽的存储库，则该请求将排队.
您可以使用 Gitaly 日志和 Prometheus 观察此队列的行为：
* 在 Gitaly 日志中，查找字符串（或结构化日志字段） `acquire_ms` . 具有此字段的消息正在报告有关并发限制器的信息.
* 在 Prometheus 中，查找以下指标：
* `gitaly_rate_limiting_in_progress`.
* `gitaly_rate_limiting_queued`.
* `gitaly_rate_limiting_seconds`.
**注意：**尽管 Prometheus 度量标准的名称包含`rate_limiting` ，但它是并发限制器，而不是速率限制器. 如果 Gitaly 客户端非常快地连续发出 1000 个请求，则并发不会超过 1，并且并发限制器无效.
## Rotate Gitaly authentication token[](#rotate-gitaly-authentication-token "Permalink")
在生产环境中轮换凭证通常需要停机，导致停机或两者兼而有之.
但是，您可以旋转 Gitaly 凭据而不会中断服务. 旋转 Gitaly 身份验证令牌涉及：
* [Verifying authentication monitoring](#verify-authentication-monitoring).
* [Enabling “auth transitioning” mode](#enable-auth-transitioning-mode).
* [Updating Gitaly authentication tokens](#update-gitaly-authentication-token).
* [Ensuring there are no authentication failures](#ensure-there-are-no-authentication-failures).
* [Disabling “auth transitioning” mode](#disable-auth-transitioning-mode).
* [Verifying authentication is enforced](#verify-authentication-is-enforced).
如果您在单个服务器上运行 GitLab，则此过程也适用. 在这种情况下，" Gitaly 服务器"和" Gitaly 客户端"是指同一台计算机.
### Verify authentication monitoring[](#verify-authentication-monitoring "Permalink")
旋转 Gitaly 身份验证令牌之前，请验证您可以使用 Prometheus 监视 GitLab 安装的身份验证行为. 使用以下 Prometheus 查询：
```
sum(rate(gitaly_authentications_total[5m])) by (enforced, status)
```
在正确配置了身份验证并且您拥有实时流量的系统中，您将看到以下内容：
```
{enforced="true",status="ok"} 4424.985419441742
```
可能还存在速率为 0 的其他数字.我们只关心非零数字.
唯一的非零数字应具有`enforced="true",status="ok"` . 如果您还有其他非零数字，则说明您的配置有问题.
`status="ok"`数字反映您当前的请求率. 在上面的示例中，Gitaly 每秒处理大约 4000 个请求.
既然您已经确定可以监视 GitLab 安装的 Gitaly 身份验证行为，则可以开始其余过程.
### Enable “auth transitioning” mode[](#enable-auth-transitioning-mode "Permalink")
通过将 Gitaly 服务器置于"身份验证过渡"模式，从而暂时禁用 Gitaly 服务器上的 Gitaly 身份验证，如下所示：
```
# in /etc/gitlab/gitlab.rb
gitaly['auth_transitioning'] = true
```
进行此更改后，您的[Prometheus 查询](#verify-authentication-monitoring)应返回如下内容：
```
{enforced="false",status="would be ok"} 4424.985419441742
```
因为`enforced="false"` ，所以可以安全地开始部署新令牌.
### Update Gitaly authentication token[](#update-gitaly-authentication-token "Permalink")
要在每个 Gitaly 客户端**和** Gitaly 服务器上更新为新的 Gitaly 身份验证令牌，请执行以下操作：
1. 更新配置：
```
# in /etc/gitlab/gitlab.rb
gitaly['auth_token'] = '<new secret token>'
```
2. 重新启动 Gitaly：
```
gitlab-ctl restart gitaly
```
如果在实施此更改的同时运行[Prometheus 查询](#verify-authentication-monitoring) ，您将看到被`enforced="false",status="denied"`计数器的非零值.
### Ensure there are no authentication failures[](#ensure-there-are-no-authentication-failures "Permalink")
设置新令牌并重新启动所有涉及的服务之后，您将[临时看到以下内容](#verify-authentication-monitoring)的组合：
* `status="would be ok"`.
* `status="denied"`.
在所有 Gitaly 客户端和 Gitaly 服务器获取了新令牌之后，应`enforced="false",status="would be ok"` **唯一的非零费率** `enforced="false",status="would be ok"` .
### Disable “auth transitioning” mode[](#disable-auth-transitioning-mode "Permalink")
要重新启用 Gitaly 身份验证，请禁用"身份验证转换"模式. 如下更新您的 Gitaly 服务器上的配置：
```
# in /etc/gitlab/gitlab.rb
gitaly['auth_transitioning'] = false
```
**警告：**如果不完成此步骤，则**没有 Gitaly 身份验证** .
### Verify authentication is enforced[](#verify-authentication-is-enforced "Permalink")
刷新您的[Prometheus 查询](#verify-authentication-monitoring) . 现在，您应该会看到与开始时相似的结果. 例如：
```
{enforced="true",status="ok"} 4424.985419441742
```
请注意， `enforced="true"`表示正在执行身份验证.
## Direct Git access bypassing Gitaly[](#direct-git-access-bypassing-gitaly "Permalink")
虽然可以使用 Git 客户端直接访问磁盘上存储的 Gitaly 存储库，但由于不断改进和更改 Gitaly，因此不建议这样做. 这些改进可能会使假设无效，从而导致性能下降，不稳定甚至数据丢失.
Gitaly 进行了优化，例如[`info/refs`广告缓存](https://gitlab.com/gitlab-org/gitaly/blob/master/doc/design_diskcache.md) ，它依赖于 Gitaly 通过官方 gRPC 接口控制和监视对存储库的访问. 同样，Praefect 具有优化功能，例如容错和分布式读取，这些优化取决于 gRPC 接口和数据库来确定存储库状态.
由于这些原因， **直接访问存储库需要您自担风险，并且不受支持** .
## Direct access to Git in GitLab[](#direct-access-to-git-in-gitlab "Permalink")
直接访问 Git 使用 GitLab 中称为" Rugged patch"的代码.
### History[](#history "Permalink")
在 Gitaly 存在之前，现在 Gitaly 客户端用来直接访问 Git 存储库的是：
* 如果是单机 Omnibus GitLab 安装，则在本地磁盘上
* 如果是水平缩放的 GitLab 安装，请使用 NFS.
除了运行简单的`git`命令之外，GitLab 还使用了一个名为[Rugged](https://github.com/libgit2/rugged)的 Ruby 库. Rugged 是围绕[libgit2](https://libgit2.org/)的包装， [libgit2](https://libgit2.org/)是 C 库形式的 Git 的独立实现.
随着时间的流逝，很明显 Rugged（特别是与[Unicorn](https://yhbt.net/unicorn/)结合使用）非常有效. 因为`libgit2`是一个库而不是一个外部进程，所以之间的开销很小：
* GitLab 应用程序代码试图在 Git 存储库中查找数据.
* Git 实现本身.
由于 Rugged 和 Unicorn 的组合是如此有效，因此 GitLab 的应用程序代码最终会进行大量重复的 Git 对象查找. 例如，查找`master`在一个请求中提交了十几次. 我们可以编写效率低下的代码而不会降低性能.
当我们将这些 Git 查找迁移到 Gitaly 调用时，我们突然发现每个 Git 查找的固定成本要高得多. 即使 Gitaly 能够重新使用已经在运行的`git`进程（例如，查找提交），您仍然可以：
* 往返于 Gitaly 的网络费用.
* 在 Gitaly 中，是将 Gitaly 连接到`git`进程的 Unix 管道上的写入/读取往返.
使用 GitLab.com 进行测量，我们减少了每个请求的 Gitaly 呼叫次数，直到不再感觉到 Rugged 效率的下降. 这也有助于我们直接在 Git 文件服务器上运行 Gitaly 本身，而不是通过 NFS 挂载. 这给了我们提速，抵消了不再使用 Rugged 带来的负面影响.
不幸的是，GitLab 的其他部署无法像我们在 GitLab.com 上那样删除 NFS，这两个方面都是最糟糕的：
* NFS 的速度较慢.
* The increased inherent overhead of Gitaly.
在 Gitaly 迁移项目期间从 GitLab 中删除的代码影响了这些部署. 作为这些基于 NFS 的部署的性能变通办法，我们重新引入了一些旧的 Rugged 代码. 重新引入的代码被非正式地称为" Rugged patch".
### How it works[](#how-it-works "Permalink")
执行直接 Git 访问的 Ruby 方法位于[功能标志的](../../development/gitaly.html#legacy-rugged-code)后面，默认情况下处于禁用状态. 设置功能标记以获得最佳性能并不方便，因此我们添加了一种自动机制，可以直接访问 Git.
当 GitLab 调用具有"加固补丁"的函数时，它将执行两项检查：
* 数据库中是否设置了此补丁程序的功能标志？ 如果是这样，功能标记设置将控制 GitLab 对"坚固补丁"代码的使用.
* 如果未设置功能标志，则 GitLab 尝试直接访问 Gitaly 服务器下方的文件系统. 如果可以，它将使用" Rugged patch".
这两个检查的结果都被缓存.
为了查看 GitLab 是否可以直接访问存储库文件系统，我们使用以下启发式：
* Gitaly 确保文件系统在其根目录中具有一个带有 UUID 的元数据文件.
* Gitaly 通过`ServerInfo` RPC 将此 UUID 报告给 GitLab.
* GitLab Rails 尝试直接读取元数据文件. 如果存在，并且 UUID 匹配，则假定我们具有直接访问权限.
默认情况下，在 Omnibus GitLab 中启用直接 Git 访问，因为它会在 GitLab 配置文件`config/gitlab.yml`填写正确的存储库路径. 这满足了 UUID 检查.
### Transition to Gitaly Cluster[](#transition-to-gitaly-cluster "Permalink")
为了消除复杂性，我们必须删除 GitLab 中的直接 Git 访问. 但是，只要某些 GitLab 安装需要 NFS 上的 Git 存储库，我们就无法删除它.
我们在 GitLab 中删除直接 Git 访问的工作有两个方面：
* 减少 GitLab 进行的低效率 Gitaly 查询的数量.
* 说服容错或水平扩展的 GitLab 实例的管理员从 NFS 迁移.
第二个方面是唯一真正的解决方案. 为此，我们开发了[Gitaly Cluster](praefect.html) .
## Troubleshooting Gitaly[](#troubleshooting-gitaly "Permalink")
### Checking versions when using standalone Gitaly servers[](#checking-versions-when-using-standalone-gitaly-servers "Permalink")
使用独立的 Gitaly 服务器时，必须确保它们与 GitLab 的版本相同，以确保完全兼容. 检查您的 GitLab 实例上的**管理区域> Gitaly 服务器** ，并确认所有 Gitaly 服务器都是`Up to date` .
[](img/gitlab_gitaly_version_mismatch_v12_4.png)
### `gitaly-debug`[](#gitaly-debug "Permalink")
`gitaly-debug`命令提供用于" Gitaly"和" Git"性能的"生产调试"工具. 它旨在帮助生产工程师和支持工程师调查 Gitaly 性能问题.
如果您使用的是 GitLab 11.6 或更高版本，则此工具应已安装在您的 GitLab / Gitaly 服务器上，位于`/opt/gitlab/embedded/bin/gitaly-debug` . 如果要研究旧版本的 GitLab，可以离线编译此工具，然后将可执行文件复制到服务器：
```
git clone https://gitlab.com/gitlab-org/gitaly.git
cd cmd/gitaly-debug
GOOS=linux GOARCH=amd64 go build -o gitaly-debug
```
要查看`gitaly-debug`的帮助页面以`gitaly-debug`受支持的子命令列表，请运行：
```
gitaly-debug -h
```
### Commits, pushes, and clones return a 401[](#commits-pushes-and-clones-return-a-401 "Permalink")
```
remote: GitLab: 401 Unauthorized
```
您将需要将`gitlab-secrets.json`文件与 Gitaly 客户端（GitLab 应用程序节点）同步.
### Client side gRPC logs[](#client-side-grpc-logs "Permalink")
Gitaly 使用[gRPC](https://grpc.io/) RPC 框架. Ruby gRPC 客户端具有自己的日志文件，当您看到 Gitaly 错误时，该文件可能包含有用的信息. 您可以使用`GRPC_LOG_LEVEL`环境变量控制 gRPC 客户端的日志级别. 默认级别为`WARN` .
您可以使用以下命令运行 gRPC 跟踪：
```
sudo GRPC_TRACE=all GRPC_VERBOSITY=DEBUG gitlab-rake gitlab:gitaly:check
```
### Observing `gitaly-ruby` traffic[](#observing-gitaly-ruby-traffic "Permalink")
[`gitaly-ruby`](#gitaly-ruby)是[`gitaly-ruby`](#gitaly-ruby)的内部实现细节，因此，对`gitaly-ruby`流程内部发生的情况`gitaly-ruby` .
如果已设置 Prometheus 来抓取 Gitaly 进程，则可以通过查询`grpc_client_handled_total`来`grpc_client_handled_total` `gitaly-ruby`各个 RPC 的请求率和错误代码. 严格来说，此度量标准并未区分`gitaly-ruby`和其他 RPC，但实际上（自 GitLab 11.9 起），Gitaly 本身进行的所有 gRPC 调用都是从 Gitaly 主过程到其`gitaly-ruby`边车之一的内部调用.
假设您的`grpc_client_handled_total`计数器仅观察到 Gitaly，以下查询将显示 RPC 在内部（最有可能）实现为对`gitaly-ruby`调用：
```
sum(rate(grpc_client_handled_total[5m])) by (grpc_method) > 0
```
### Repository changes fail with a `401 Unauthorized` error[](#repository-changes-fail-with-a-401-unauthorized-error "Permalink")
如果您在自己的服务器上运行 Gitaly，并注意到用户可以成功克隆和获取存储库（通过 SSH 和 HTTPS），但是在未获得`401 Unauthorized`情况下，无法推送到它们或在 Web UI 中对存储库进行更改消息，那么 Gitaly 可能由于拥有[错误的 secrets 文件](#configure-gitaly-servers)而无法通过 Gitaly 客户端进行身份验证.
确认以下所有内容均正确：
* When any user performs a `git push` to any repository on this Gitaly server, it fails with the following error (note the `401 Unauthorized`):
```
remote: GitLab: 401 Unauthorized
To <REMOTE_URL>
! [remote rejected] branch-name -> branch-name (pre-receive hook declined)
error: failed to push some refs to '<REMOTE_URL>'
```
* 当任何用户使用 GitLab UI 从存储库添加或修改文件时，该文件都会立即失败，并显示红色`401 Unauthorized`横幅.
* 创建一个新项目并[使用 README 对其进行初始化会](../../gitlab-basics/create-project.html#blank-projects)成功创建该项目，但不会创建 README.
* [将日志尾随在](https://docs.gitlab.com/omnibus/settings/logs.html) Gitaly 客户端上并重现该错误时，到达`/api/v4/internal/allowed`端点时会出现`401`错误：
```
# api_json.log
{
"time": "2019-07-18T00:30:14.967Z",
"severity": "INFO",
"duration": 0.57,
"db": 0,
"view": 0.57,
"status": 401,
"method": "POST",
"path": "\/api\/v4\/internal\/allowed",
"params": [
{
"key": "action",
"value": "git-receive-pack"
},
{
"key": "changes",
"value": "REDACTED"
},
{
"key": "gl_repository",
"value": "REDACTED"
},
{
"key": "project",
"value": "\/path\/to\/project.git"
},
{
"key": "protocol",
"value": "web"
},
{
"key": "env",
"value": "{\"GIT_ALTERNATE_OBJECT_DIRECTORIES\":[],\"GIT_ALTERNATE_OBJECT_DIRECTORIES_RELATIVE\":[],\"GIT_OBJECT_DIRECTORY\":null,\"GIT_OBJECT_DIRECTORY_RELATIVE\":null}"
},
{
"key": "user_id",
"value": "2"
},
{
"key": "secret_token",
"value": "[FILTERED]"
}
],
"host": "gitlab.example.com",
"ip": "REDACTED",
"ua": "Ruby",
"route": "\/api\/:version\/internal\/allowed",
"queue_duration": 4.24,
"gitaly_calls": 0,
"gitaly_duration": 0,
"correlation_id": "XPUZqTukaP3"
}
# nginx_access.log
[IP] - - [18/Jul/2019:00:30:14 +0000] "POST /api/v4/internal/allowed HTTP/1.1" 401 30 "" "Ruby"
```
要解决此问题，请确认 Gitaly 服务器上的 gitlab [`gitlab-secrets.json`文件](#configure-gitaly-servers)与 Gitaly 客户端上的[文件](#configure-gitaly-servers)匹配. 如果不匹配，请更新 Gitaly 服务器上的密码文件以匹配 Gitaly 客户端，然后[重新配置](../restart_gitlab.html#omnibus-gitlab-reconfigure) .
### Command line tools cannot connect to Gitaly[](#command-line-tools-cannot-connect-to-gitaly "Permalink")
如果使用命令行（CLI）工具连接到 Gitaly 服务器时遇到问题，并且某些操作导致出现`14: Connect Failed`错误消息，则意味着 gRPC 无法访问您的 Gitaly 服务器.
确认您可以通过 TCP 到达 Gitaly：
```
sudo gitlab-rake gitlab:tcp_check[GITALY_SERVER_IP,GITALY_LISTEN_PORT]
```
如果 TCP 连接失败，请检查您的网络设置和防火墙规则. 如果 TCP 连接成功，则您的网络和防火墙规则正确.
如果您在命令行环境（例如 Bash）中使用代理服务器，则这些代理服务器可能会干扰您的 gRPC 通信.
如果使用 Bash 或兼容的命令行环境，请运行以下命令来确定是否配置了代理服务器：
```
echo $http_proxy
echo $https_proxy
```
如果这些变量中的任何一个都有值，则您的 Gitaly CLI 连接可能正在通过无法连接到 Gitaly 的代理进行路由.
要删除代理设置，请运行以下命令（取决于哪些变量具有值）：
```
unset http_proxy
unset https_proxy
```
### Gitaly not listening on new address after reconfiguring[](#gitaly-not-listening-on-new-address-after-reconfiguring "Permalink")
当更新`gitaly['listen_addr']`或`gitaly['prometheus_listen_addr']`值时，Gitaly 可能会在`sudo gitlab-ctl reconfigure`后继续侦听旧地址.
发生这种情况时，执行`sudo gitlab-ctl restart`将解决此问题. 解决[此问题](https://gitlab.com/gitlab-org/gitaly/-/issues/2521)后，将不再需要[此操作](https://gitlab.com/gitlab-org/gitaly/-/issues/2521) .
### Permission denied errors appearing in Gitaly logs when accessing repositories from a standalone Gitaly server[](#permission-denied-errors-appearing-in-gitaly-logs-when-accessing-repositories-from-a-standalone-gitaly-server "Permalink")
如果即使文件权限正确也发生此错误，则 Gitaly 服务器可能正在发生[时钟漂移](https://en.wikipedia.org/wiki/Clock_drift) .
请确保 Gitaly 客户端和服务器已同步，并在可能的情况下使用 NTP 时间服务器保持同步.
### Praefect[](#praefect "Permalink")
Praefect 是 Gitaly 的路由器和事务管理器，并且是运行 Gitaly 集群的必需组件. 有关更多信息，请参见[Gitaly Cluster](praefect.html) .
- GitLab Docs
- Installation
- Requirements
- GitLab cloud native Helm Chart
- Install GitLab with Docker
- Installation from source
- Install GitLab on Microsoft Azure
- Installing GitLab on Google Cloud Platform
- Installing GitLab on Amazon Web Services (AWS)
- Analytics
- Code Review Analytics
- Productivity Analytics
- Value Stream Analytics
- Kubernetes clusters
- Adding and removing Kubernetes clusters
- Adding EKS clusters
- Adding GKE clusters
- Group-level Kubernetes clusters
- Instance-level Kubernetes clusters
- Canary Deployments
- Cluster Environments
- Deploy Boards
- GitLab Managed Apps
- Crossplane configuration
- Cluster management project (alpha)
- Kubernetes Logs
- Runbooks
- Serverless
- Deploying AWS Lambda function using GitLab CI/CD
- Securing your deployed applications
- Groups
- Contribution Analytics
- Custom group-level project templates
- Epics
- Manage epics
- Group Import/Export
- Insights
- Issues Analytics
- Iterations
- Public access
- SAML SSO for GitLab.com groups
- SCIM provisioning using SAML SSO for GitLab.com groups
- Subgroups
- Roadmap
- Projects
- GitLab Secure
- Security Configuration
- Container Scanning
- Dependency Scanning
- Dependency List
- Static Application Security Testing (SAST)
- Secret Detection
- Dynamic Application Security Testing (DAST)
- GitLab Security Dashboard
- Offline environments
- Standalone Vulnerability pages
- Security scanner integration
- Badges
- Bulk editing issues and merge requests at the project level
- Code Owners
- Compliance
- License Compliance
- Compliance Dashboard
- Create a project
- Description templates
- Deploy Keys
- Deploy Tokens
- File finder
- Project integrations
- Integrations
- Atlassian Bamboo CI Service
- Bugzilla Service
- Custom Issue Tracker service
- Discord Notifications service
- Enabling emails on push
- GitHub project integration
- Hangouts Chat service
- Atlassian HipChat
- Irker IRC Gateway
- GitLab Jira integration
- Mattermost Notifications Service
- Mattermost slash commands
- Microsoft Teams service
- Mock CI Service
- Prometheus integration
- Redmine Service
- Slack Notifications Service
- Slack slash commands
- GitLab Slack application
- Webhooks
- YouTrack Service
- Insights
- Issues
- Crosslinking Issues
- Design Management
- Confidential issues
- Due dates
- Issue Boards
- Issue Data and Actions
- Labels
- Managing issues
- Milestones
- Multiple Assignees for Issues
- Related issues
- Service Desk
- Sorting and ordering issue lists
- Issue weight
- Associate a Zoom meeting with an issue
- Merge requests
- Allow collaboration on merge requests across forks
- Merge Request Approvals
- Browser Performance Testing
- How to create a merge request
- Cherry-pick changes
- Code Quality
- Load Performance Testing
- Merge Request dependencies
- Fast-forward merge requests
- Merge when pipeline succeeds
- Merge request conflict resolution
- Reverting changes
- Reviewing and managing merge requests
- Squash and merge
- Merge requests versions
- Draft merge requests
- Members of a project
- Migrating projects to a GitLab instance
- Import your project from Bitbucket Cloud to GitLab
- Import your project from Bitbucket Server to GitLab
- Migrating from ClearCase
- Migrating from CVS
- Import your project from FogBugz to GitLab
- Gemnasium
- Import your project from GitHub to GitLab
- Project importing from GitLab.com to your private GitLab instance
- Import your project from Gitea to GitLab
- Import your Jira project issues to GitLab
- Migrating from Perforce Helix
- Import Phabricator tasks into a GitLab project
- Import multiple repositories by uploading a manifest file
- Import project from repo by URL
- Migrating from SVN to GitLab
- Migrating from TFVC to Git
- Push Options
- Releases
- Repository
- Branches
- Git Attributes
- File Locking
- Git file blame
- Git file history
- Repository mirroring
- Protected branches
- Protected tags
- Push Rules
- Reduce repository size
- Signing commits with GPG
- Syntax Highlighting
- GitLab Web Editor
- Web IDE
- Requirements Management
- Project settings
- Project import/export
- Project access tokens (Alpha)
- Share Projects with other Groups
- Snippets
- Static Site Editor
- Wiki
- Project operations
- Monitor metrics for your CI/CD environment
- Set up alerts for Prometheus metrics
- Embedding metric charts within GitLab-flavored Markdown
- Embedding Grafana charts
- Using the Metrics Dashboard
- Dashboard YAML properties
- Metrics dashboard settings
- Panel types for dashboards
- Using Variables
- Templating variables for metrics dashboards
- Prometheus Metrics library
- Monitoring AWS Resources
- Monitoring HAProxy
- Monitoring Kubernetes
- Monitoring NGINX
- Monitoring NGINX Ingress Controller
- Monitoring NGINX Ingress Controller with VTS metrics
- Alert Management
- Error Tracking
- Tracing
- Incident Management
- GitLab Status Page
- Feature Flags
- GitLab CI/CD
- GitLab CI/CD pipeline configuration reference
- GitLab CI/CD include examples
- Introduction to CI/CD with GitLab
- Getting started with GitLab CI/CD
- How to enable or disable GitLab CI/CD
- Using SSH keys with GitLab CI/CD
- Migrating from CircleCI
- Migrating from Jenkins
- Auto DevOps
- Getting started with Auto DevOps
- Requirements for Auto DevOps
- Customizing Auto DevOps
- Stages of Auto DevOps
- Upgrading PostgreSQL for Auto DevOps
- Cache dependencies in GitLab CI/CD
- GitLab ChatOps
- Cloud deployment
- Docker integration
- Building Docker images with GitLab CI/CD
- Using Docker images
- Building images with kaniko and GitLab CI/CD
- GitLab CI/CD environment variables
- Predefined environment variables reference
- Where variables can be used
- Deprecated GitLab CI/CD variables
- Environments and deployments
- Protected Environments
- GitLab CI/CD Examples
- Test a Clojure application with GitLab CI/CD
- Using Dpl as deployment tool
- Testing a Phoenix application with GitLab CI/CD
- End-to-end testing with GitLab CI/CD and WebdriverIO
- DevOps and Game Dev with GitLab CI/CD
- Deploy a Spring Boot application to Cloud Foundry with GitLab CI/CD
- How to deploy Maven projects to Artifactory with GitLab CI/CD
- Testing PHP projects
- Running Composer and NPM scripts with deployment via SCP in GitLab CI/CD
- Test and deploy Laravel applications with GitLab CI/CD and Envoy
- Test and deploy a Python application with GitLab CI/CD
- Test and deploy a Ruby application with GitLab CI/CD
- Test and deploy a Scala application to Heroku
- GitLab CI/CD for external repositories
- Using GitLab CI/CD with a Bitbucket Cloud repository
- Using GitLab CI/CD with a GitHub repository
- GitLab Pages
- GitLab Pages
- GitLab Pages domain names, URLs, and baseurls
- Create a GitLab Pages website from scratch
- Custom domains and SSL/TLS Certificates
- GitLab Pages integration with Let's Encrypt
- GitLab Pages Access Control
- Exploring GitLab Pages
- Incremental Rollouts with GitLab CI/CD
- Interactive Web Terminals
- Optimizing GitLab for large repositories
- Metrics Reports
- CI/CD pipelines
- Pipeline Architecture
- Directed Acyclic Graph
- Multi-project pipelines
- Parent-child pipelines
- Pipelines for Merge Requests
- Pipelines for Merged Results
- Merge Trains
- Job artifacts
- Pipeline schedules
- Pipeline settings
- Triggering pipelines through the API
- Review Apps
- Configuring GitLab Runners
- GitLab CI services examples
- Using MySQL
- Using PostgreSQL
- Using Redis
- Troubleshooting CI/CD
- GitLab Package Registry
- GitLab Container Registry
- Dependency Proxy
- GitLab Composer Repository
- GitLab Conan Repository
- GitLab Maven Repository
- GitLab NPM Registry
- GitLab NuGet Repository
- GitLab PyPi Repository
- API Docs
- API resources
- .gitignore API
- GitLab CI YMLs API
- Group and project access requests API
- Appearance API
- Applications API
- Audit Events API
- Avatar API
- Award Emoji API
- Project badges API
- Group badges API
- Branches API
- Broadcast Messages API
- Project clusters API
- Group clusters API
- Instance clusters API
- Commits API
- Container Registry API
- Custom Attributes API
- Dashboard annotations API
- Dependencies API
- Deploy Keys API
- Deployments API
- Discussions API
- Dockerfiles API
- Environments API
- Epics API
- Events
- Feature Flags API
- Feature flag user lists API
- Freeze Periods API
- Geo Nodes API
- Group Activity Analytics API
- Groups API
- Import API
- Issue Boards API
- Group Issue Boards API
- Issues API
- Epic Issues API
- Issues Statistics API
- Jobs API
- Keys API
- Labels API
- Group Labels API
- License
- Licenses API
- Issue links API
- Epic Links API
- Managed Licenses API
- Markdown API
- Group and project members API
- Merge request approvals API
- Merge requests API
- Project milestones API
- Group milestones API
- Namespaces API
- Notes API
- Notification settings API
- Packages API
- Pages domains API
- Pipeline schedules API
- Pipeline triggers API
- Pipelines API
- Project Aliases API
- Project import/export API
- Project repository storage moves API
- Project statistics API
- Project templates API
- Projects API
- Protected branches API
- Protected tags API
- Releases API
- Release links API
- Repositories API
- Repository files API
- Repository submodules API
- Resource label events API
- Resource milestone events API
- Resource weight events API
- Runners API
- SCIM API
- Search API
- Services API
- Application settings API
- Sidekiq Metrics API
- Snippets API
- Project snippets
- Application statistics API
- Suggest Changes API
- System hooks API
- Tags API
- Todos API
- Users API
- Project-level Variables API
- Group-level Variables API
- Version API
- Vulnerabilities API
- Vulnerability Findings API
- Wikis API
- GraphQL API
- Getting started with GitLab GraphQL API
- GraphQL API Resources
- API V3 to API V4
- Validate the .gitlab-ci.yml (API)
- User Docs
- Abuse reports
- User account
- Active sessions
- Deleting a User account
- Permissions
- Personal access tokens
- Profile preferences
- Threads
- GitLab and SSH keys
- GitLab integrations
- Git
- GitLab.com settings
- Infrastructure as code with Terraform and GitLab
- GitLab keyboard shortcuts
- GitLab Markdown
- AsciiDoc
- GitLab Notification Emails
- GitLab Quick Actions
- Autocomplete characters
- Reserved project and group names
- Search through GitLab
- Advanced Global Search
- Advanced Syntax Search
- Time Tracking
- GitLab To-Do List
- Administrator Docs
- Reference architectures
- Reference architecture: up to 1,000 users
- Reference architecture: up to 2,000 users
- Reference architecture: up to 3,000 users
- Reference architecture: up to 5,000 users
- Reference architecture: up to 10,000 users
- Reference architecture: up to 25,000 users
- Reference architecture: up to 50,000 users
- Troubleshooting a reference architecture set up
- Working with the bundled Consul service
- Configuring PostgreSQL for scaling
- Configuring GitLab application (Rails)
- Load Balancer for multi-node GitLab
- Configuring a Monitoring node for Scaling and High Availability
- NFS
- Working with the bundled PgBouncer service
- Configuring Redis for scaling
- Configuring Sidekiq
- Admin Area settings
- Continuous Integration and Deployment Admin settings
- Custom instance-level project templates
- Diff limits administration
- Enable and disable GitLab features deployed behind feature flags
- Geo nodes Admin Area
- GitLab Pages administration
- Health Check
- Job logs
- Labels administration
- Log system
- PlantUML & GitLab
- Repository checks
- Repository storage paths
- Repository storage types
- Account and limit settings
- Service templates
- System hooks
- Changing your time zone
- Uploads administration
- Abuse reports
- Activating and deactivating users
- Audit Events
- Blocking and unblocking users
- Broadcast Messages
- Elasticsearch integration
- Gitaly
- Gitaly Cluster
- Gitaly reference
- Monitoring GitLab
- Monitoring GitLab with Prometheus
- Performance Bar
- Usage statistics
- Object Storage
- Performing Operations in GitLab
- Cleaning up stale Redis sessions
- Fast lookup of authorized SSH keys in the database
- Filesystem Performance Benchmarking
- Moving repositories managed by GitLab
- Run multiple Sidekiq processes
- Sidekiq MemoryKiller
- Switching to Puma
- Understanding Unicorn and unicorn-worker-killer
- User lookup via OpenSSH's AuthorizedPrincipalsCommand
- GitLab Package Registry administration
- GitLab Container Registry administration
- Replication (Geo)
- Geo database replication
- Geo with external PostgreSQL instances
- Geo configuration
- Using a Geo Server
- Updating the Geo nodes
- Geo with Object storage
- Docker Registry for a secondary node
- Geo for multiple nodes
- Geo security review (Q&A)
- Location-aware Git remote URL with AWS Route53
- Tuning Geo
- Removing secondary Geo nodes
- Geo data types support
- Geo Frequently Asked Questions
- Geo Troubleshooting
- Geo validation tests
- Disaster Recovery (Geo)
- Disaster recovery for planned failover
- Bring a demoted primary node back online
- Automatic background verification
- Rake tasks
- Back up and restore GitLab
- Clean up
- Namespaces
- Maintenance Rake tasks
- Geo Rake Tasks
- GitHub import
- Import bare repositories
- Integrity check Rake task
- LDAP Rake tasks
- Listing repository directories
- Praefect Rake tasks
- Project import/export administration
- Repository storage Rake tasks
- Generate sample Prometheus data
- Uploads migrate Rake tasks
- Uploads sanitize Rake tasks
- User management
- Webhooks administration
- X.509 signatures
- Server hooks
- Static objects external storage
- Updating GitLab
- GitLab release and maintenance policy
- Security
- Password Storage
- Custom password length limits
- Restrict allowed SSH key technologies and minimum length
- Rate limits
- Webhooks and insecure internal web services
- Information exclusivity
- How to reset your root password
- How to unlock a locked user from the command line
- User File Uploads
- How we manage the TLS protocol CRIME vulnerability
- User email confirmation at sign-up
- Security of running jobs
- Proxying assets
- CI/CD Environment Variables
- Contributor and Development Docs
- Contribute to GitLab
- Community members & roles
- Implement design & UI elements
- Issues workflow
- Merge requests workflow
- Code Review Guidelines
- Style guides
- GitLab Architecture Overview
- CI/CD development documentation
- Database guides
- Database Review Guidelines
- Database Review Guidelines
- Migration Style Guide
- What requires downtime?
- Understanding EXPLAIN plans
- Rake tasks for developers
- Mass inserting Rails models
- GitLab Documentation guidelines
- Documentation Style Guide
- Documentation structure and template
- Documentation process
- Documentation site architecture
- Global navigation
- GitLab Docs monthly release process
- Telemetry Guide
- Usage Ping Guide
- Snowplow Guide
- Experiment Guide
- Feature flags in development of GitLab
- Feature flags process
- Developing with feature flags
- Feature flag controls
- Document features deployed behind feature flags
- Frontend Development Guidelines
- Accessibility & Readability
- Ajax
- Architecture
- Axios
- Design Patterns
- Frontend Development Process
- DropLab
- Emojis
- Filter
- Frontend FAQ
- GraphQL
- Icons and SVG Illustrations
- InputSetter
- Performance
- Principles
- Security
- Tooling
- Vuex
- Vue
- Geo (development)
- Geo self-service framework (alpha)
- Gitaly developers guide
- GitLab development style guides
- API style guide
- Go standards and style guidelines
- GraphQL API style guide
- Guidelines for shell commands in the GitLab codebase
- HTML style guide
- JavaScript style guide
- Migration Style Guide
- Newlines style guide
- Python Development Guidelines
- SCSS style guide
- Shell scripting standards and style guidelines
- Sidekiq debugging
- Sidekiq Style Guide
- SQL Query Guidelines
- Vue.js style guide
- Instrumenting Ruby code
- Testing standards and style guidelines
- Flaky tests
- Frontend testing standards and style guidelines
- GitLab tests in the Continuous Integration (CI) context
- Review Apps
- Smoke Tests
- Testing best practices
- Testing levels
- Testing Rails migrations at GitLab
- Testing Rake tasks
- End-to-end Testing
- Beginner's guide to writing end-to-end tests
- End-to-end testing Best Practices
- Dynamic Element Validation
- Flows in GitLab QA
- Page objects in GitLab QA
- Resource class in GitLab QA
- Style guide for writing end-to-end tests
- Testing with feature flags
- Translate GitLab to your language
- Internationalization for GitLab
- Translating GitLab
- Proofread Translations
- Merging translations from CrowdIn
- Value Stream Analytics development guide
- GitLab subscription
- Activate GitLab EE with a license