Gitaly · Gitlab 中文文檔

# 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 的高級體系結構概述. [![Gitaly architecture diagram](https://img.kancloud.cn/43/9d/439d4874e71a2e1c780966c7e725f9a0_2048x1536.png)](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` . [![Gitaly standalone software versions diagram](https://img.kancloud.cn/3e/5c/3e5c7e400a6ef2ad74454039c570e336_1038x320.png)](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) .