参考架构：最多40 RPS或2000用户

本页描述了针对峰值负载为每秒40次请求（RPS）的GitLab参考架构，基于真实数据的典型峰值负载，最多支持2000名手动和自动化用户。

有关完整的参考架构列表，请参见 可用参考架构。

• 目标负载：API：40 RPS，Web：4 RPS，Git（拉取）：4 RPS，Git（推送）：1 RPS
• 高可用性：否。如需高可用环境，可遵循修改后的 3K 或 60 RPS 参考架构。
• 云原生混合：是
• 不确定使用哪种参考架构？ 前往此指南获取更多信息。

脚注：

1. 提供机器类型示例仅作说明。这些类型用于 验证和测试结果，但不作为规定性默认值。切换到符合要求的其他机器类型（包括有可用的ARM变体）受支持。有关更多信息，请参见 支持的机器类型。
2. 可选择在信誉良好的第三方外部PaaS PostgreSQL解决方案上运行。有关更多信息，请参见 提供您自己的PostgreSQL实例 和 推荐的云提供商和服务。
3. 可选择在信誉良好的第三方外部PaaS Redis解决方案上运行。有关更多信息，请参见 提供您自己的Redis实例 和 推荐的云提供商和服务。
4. 建议使用信誉良好的第三方负载均衡器或服务（LB PaaS）运行。大小取决于所选负载均衡器和网络带宽等其他因素。有关更多信息，请参见 负载均衡器。
5. 应在信誉良好的云提供商或自管理解决方案上运行。有关更多信息，请参见 配置对象存储。
6. Gitaly规格基于正常大小的健康仓库的使用情况。但是，如果您有大型的单体仓库（大于几GB），这会显著影响Git和Gitaly性能，可能需要增加规格。有关更多信息，请参见 大型单体仓库。
7. 可以放置在自动扩展组（ASGs）中，因为该组件不存储任何 状态数据。然而，云原生混合设置 通常更受欢迎，因为某些组件（如 迁移 和 Mailroom）只能在一个节点上运行，这在Kubernetes中处理得更好。

@startuml 2k
skinparam linetype ortho

card "**外部负载均衡器**" as elb #6a9be7

together {
  collections "**GitLab Rails** x2" as gitlab #32CD32
  card "**Sidekiq**" as sidekiq #ff8dd1
}

card "**Prometheus**" as monitor #7FFFD4
card "**Gitaly**" as gitaly #FF8C00
card "**PostgreSQL**" as postgres #4EA7FF
card "**Redis**" as redis #FF6347
cloud "**对象存储**" as object_storage #white

elb -[#6a9be7]-> gitlab
elb -[#6a9be7,norank]--> monitor

gitlab -[#32CD32]--> gitaly
gitlab -[#32CD32]--> postgres
gitlab -[#32CD32]> object_storage
gitlab -[#32CD32]--> redis

sidekiq -[#ff8dd1]> object_storage
sidekiq -[#ff8dd1]--> redis
sidekiq .[#ff8dd1]--> postgres
sidekiq -[hidden]-> monitor

monitor .[#7FFFD4]u-> gitlab
monitor .[#7FFFD4]-> gitaly
monitor .[#7FFFD4]-> postgres
monitor .[#7FFFD4,norank]--> redis
monitor .[#7FFFD4,norank]u--> elb
monitor .[#7FFFD4]u-> sidekiq

@enduml

要求

在继续之前，请查看参考架构的要求。

测试方法

40 RPS / 2000用户的参考架构设计用于满足大多数常见工作流程。GitLab定期针对以下端点吞吐量目标进行冒烟测试和性能测试：

这些目标基于实际客户数据，反映了指定用户数量的总环境负载，包括CI管道和其他工作负载。

有关我们测试方法的更多信息，请参阅验证和测试结果部分。

性能注意事项

如果您的环境存在以下情况，您可能需要进行额外调整：

• 持续高于列出的目标的吞吐量
• 大型单体仓库
• 显著的其他工作负载

在这些情况下，请参阅扩展环境以获取更多信息。如果您认为这些注意事项适用于您，请联系我们以获得所需的额外指导。

负载均衡器配置

我们的测试环境使用：

• Linux包环境的HAProxy
• 云原生混合环境的云提供商等效方案（使用NGINX Ingress）

设置组件

要将GitLab及其组件设置为支持最多40 RPS或2000个用户：

1. 配置外部负载均衡节点，以处理GitLab应用服务节点的负载均衡。
2. 配置PostgreSQL，即GitLab的数据库。
3. 配置Redis，它存储会话数据、临时缓存信息和后台作业队列。
4. 配置Gitaly，它提供对Git仓库的访问。
5. 配置Sidekiq以进行后台作业处理。
6. 配置主GitLab Rails应用，运行Puma、Workhorse、GitLab Shell，并处理所有前端请求（包括UI、API以及通过HTTP/SSH的Git请求）。
7. 配置Prometheus以监控您的GitLab环境。
8. 配置对象存储，用于共享数据对象。
9. 配置高级搜索（可选），以便在整个GitLab实例中进行更快、更高级的代码搜索。

配置外部负载均衡器

在多节点GitLab配置中，您需要一个外部负载均衡器将流量路由到应用服务器。

关于使用哪种负载均衡器或其确切配置的具体信息超出了GitLab文档的范围，但请参阅负载均衡器以了解通用要求的更多信息。本节将重点介绍如何为您选择的负载均衡器配置具体内容。

就绪检查

确保外部负载均衡器仅将流量路由到具有内置监控端点的正常服务。就绪检查都需要在被检查节点上进行额外配置，否则外部负载均衡器将无法连接。

端口

需使用的基本端口如下表所示。

• (1): Web终端 支持要求您的负载均衡器正确处理WebSocket连接。当使用HTTP或HTTPS代理时，这意味着您的负载均衡器必须配置为传递 Connection 和 Upgrade 逐跳头信息。有关更多详情，请参阅 web终端集成指南。
• (2): 当对端口443使用HTTPS协议时，您必须在负载均衡器上添加SSL证书。如果您希望在GitLab应用服务器上终止SSL，则使用TCP协议。

如果您使用带有自定义域名支持的GitLab Pages，则需要一些额外的端口配置。 GitLab Pages需要一个单独的虚拟IP地址。配置DNS以将 /etc/gitlab/gitlab.rb 中的 pages_external_url 指向新的虚拟IP地址。有关更多信息，请参阅 GitLab Pages文档。

• (1): GitLab Pages的后端端口取决于 gitlab_pages['external_http'] 和 gitlab_pages['external_https'] 设置。有关更多详情，请参阅 GitLab Pages文档。
• (2): GitLab Pages的端口443应始终使用TCP协议。用户可以配置带有自定义SSL的自定义域名，如果SSL在负载均衡器处终止，这将无法实现。

备用SSH端口

有些组织有政策禁止开放SSH端口22。在这种情况下，配置一个允许用户使用端口443进行SSH的备用SSH主机名将很有帮助。与之前记录的其他GitLab HTTP配置相比，备用SSH主机名将需要一个新虚拟IP地址。

为备用SSH主机名（例如 altssh.gitlab.example.com）配置DNS。

SSL

下一个问题是您如何在环境中处理SSL。 有以下几种不同的选项：

• 应用节点终止SSL。
• 负载均衡器终止SSL且后端不使用SSL，并且负载均衡器和应用节点之间的通信不安全。
• 负载均衡器终止SSL且后端使用SSL，并且负载均衡器和应用节点之间的通信是安全的。

应用节点终止SSL

将负载均衡器配置为通过 TCP 而非 HTTP(S) 协议传递端口443上的连接。这将把未修改的连接传递给应用节点的NGINX服务。NGINX将拥有SSL证书并监听端口443。

有关管理SSL证书和配置NGINX的详细信息，请参阅 HTTPS文档。

负载均衡器终止SSL且后端不使用SSL

将负载均衡器配置为使用 HTTP(S) 协议而非 TCP。负载均衡器随后将负责管理SSL证书并终止SSL。

由于负载均衡器和GitLab之间的通信不安全，因此需要进行一些额外配置。有关详情，请参阅 代理SSL文档。

负载均衡器终止SSL且后端使用SSL

将负载均衡器配置为使用 HTTP(S) 协议而非 TCP。负载均衡器将负责管理最终用户可见的SSL证书。

在此场景中，负载均衡器和NGINX之间的流量也是安全的。无需为代理SSL添加配置，因为整个连接将是安全的。但是，必须在GitLab中添加配置以配置SSL证书。有关管理SSL证书和配置NGINX的详细信息，请参阅 HTTPS文档。

配置PostgreSQL

在本节中，我们将指导您完成配置用于GitLab的外部PostgreSQL数据库的过程。

提供您自己的 PostgreSQL 实例

您可以选用 第三方外部服务来提供 PostgreSQL。

应使用信誉良好的提供商或解决方案。Google Cloud SQL 和 Amazon RDS 已知可正常工作。然而，Amazon Aurora 与 14.4.0 版本默认启用的负载均衡 不兼容。

更多信息请参阅 推荐云服务商和服务。

如果您使用第三方外部服务：

1. HA Linux 包的 PostgreSQL 设置包含 PostgreSQL、PgBouncer 和 Consul。当使用第三方外部服务时，这些组件均不再需要。
2. 根据 数据库要求文档 配置 PostgreSQL。
3. 创建一个名为 gitlab 的用户并设置密码。该 gitlab 用户需要有创建 gitlabhq_production 数据库的权限。
4. 使用适当的信息配置 GitLab 应用服务器。此步骤将在 配置 GitLab Rails 应用程序 中介绍。

使用 Linux 包部署独立 PostgreSQL

1. 通过 SSH 连接到 PostgreSQL 服务器。

2. 下载并安装 您选择的 Linux 包。请仅添加 GitLab 软件仓库并为您选择的操作系统安装 GitLab。

3. 为 PostgreSQL 生成密码哈希。假设您将使用默认用户名 gitlab（推荐）。该命令会请求密码并确认。使用此命令输出的值作为下一步中 POSTGRESQL_PASSWORD_HASH 的值。

   sudo gitlab-ctl pg-password-md5 gitlab

4. 编辑 /etc/gitlab/gitlab.rb 并添加以下内容，适当更新占位符值：

   • POSTGRESQL_PASSWORD_HASH - 上一步输出的值
   • APPLICATION_SERVER_IP_BLOCKS - 以空格分隔的 GitLab Rails 和 Sidekiq 服务器 IP 子网或地址列表，这些服务器将连接到数据库。示例：%w(123.123.123.123/32 123.123.123.234/32)
   # 仅启用与 PostgreSQL 相关的组件
   roles(['postgres_role'])
   
   # 设置导出器用于监控的监听网络地址
   node_exporter['listen_address'] = '0.0.0.0:9100'
   postgres_exporter['listen_address'] = '0.0.0.0:9187'
   postgres_exporter['dbname'] = 'gitlabhq_production'
   postgres_exporter['password'] = 'POSTGRESQL_PASSWORD_HASH'
   
   # 设置 PostgreSQL 地址和端口
   postgresql['listen_address'] = '0.0.0.0'
   postgresql['port'] = 5432
   
   # 用生成的 md5 值替换 POSTGRESQL_PASSWORD_HASH
   postgresql['sql_user_password'] = 'POSTGRESQL_PASSWORD_HASH'
   
   # 用应用节点的 CIDR 地址替换 APPLICATION_SERVER_IP_BLOCK
   postgresql['trust_auth_cidr_addresses'] = %w(127.0.0.1/32 APPLICATION_SERVER_IP_BLOCK)
   
   # 防止升级时自动运行数据库迁移
   gitlab_rails['auto_migrate'] = false

5. 从您配置的第一个 Linux 包节点复制 /etc/gitlab/gitlab-secrets.json 文件，并在本服务器上添加或替换同名文件。如果这是您配置的第一个 Linux 包，则可跳过此步骤。

6. 重新配置 GitLab 使更改生效。

7. 记录 PostgreSQL 节点的 IP 地址或主机名、端口以及明文密码。这些信息在后续 配置 GitLab 应用服务器 时需要用到。

高级 配置选项 受支持，可根据需要添加。

配置 Redis

在本节中，我们将指导您配置用于 GitLab 的外部 Redis 实例。

提供您自己的Redis实例

您可以可选地使用第三方外部服务作为Redis实例，并遵循以下指导：

• 应为此使用信誉良好的提供商或解决方案。Google Memorystore 和 AWS ElastiCache 已知可正常工作。
• Redis集群模式不被支持，但带有HA的Redis独立模式是被支持的。
• 您必须根据您的设置配置Redis驱逐模式。

有关更多信息，请参阅推荐云提供商和服务。

使用Linux包的独立Redis

Linux包可用于配置独立的Redis服务器。以下是使用Linux包配置Redis服务器的最低必要步骤：

1. 通过SSH连接到Redis服务器。

2. 下载并安装 您选择的Linux包。请务必仅添加GitLab包仓库并为所选操作系统安装GitLab。

3. 编辑 /etc/gitlab/gitlab.rb 并添加以下内容：

   ## 启用Redis
   roles(["redis_master_role"])
   
   redis['bind'] = '0.0.0.0'
   redis['port'] = 6379
   redis['password'] = 'SECRET_PASSWORD_HERE'
   
   # 设置导出器用于监控的网络监听地址
   node_exporter['listen_address'] = '0.0.0.0:9100'
   redis_exporter['listen_address'] = '0.0.0.0:9121'
   redis_exporter['flags'] = {
         'redis.addr' => 'redis://0.0.0.0:6379',
         'redis.password' => 'SECRET_PASSWORD_HERE',
   }
   
   # 防止数据库迁移在升级时自动运行
   gitlab_rails['auto_migrate'] = false

4. 从您配置的第一个Linux包节点复制 /etc/gitlab/gitlab-secrets.json 文件，并在本服务器上添加或替换同名文件。如果这是您正在配置的第一个Linux包节点，则可以跳过此步骤。

5. 重新配置GitLab 以使更改生效。

6. 记录Redis节点的IP地址或主机名、端口以及Redis密码。这些在后续配置GitLab应用服务器 时是必需的。

高级配置选项 受支持，可根据需要添加。

## 配置 Gitaly

[Gitaly](../gitaly/_index.md) 服务节点的需求取决于数据大小，特别是项目数量和这些项目的规模。


  

  

    
Gitaly 规格基于健康状态下的使用模式和仓库大小的较高百分位数。
但是，如果您有大型单体仓库（大于几 GB）或额外工作负载，这会显著影响环境性能，可能需要进一步调整。
如果您认为此情况适用于您，请根据需要联系我们来获取额外指导。




Gitaly 存储对磁盘有一定[要求](../gitaly/_index.md#disk-requirements)。

请注意以下事项：

- GitLab Rails 应用程序将仓库分片到[仓库存储路径](../repository_storage_paths.md)中。
- 一个 Gitaly 服务器可以托管一个或多个存储路径。
- 一个 GitLab 服务器可以使用一个或多个 Gitaly 服务节点。
- 必须指定 Gitaly 地址，以便所有 Gitaly 客户端能够正确解析。
- Gitaly 服务器不得暴露在公共互联网上，因为默认情况下 Gitaly 的网络流量未加密。强烈建议使用防火墙限制对 Gitaly 服务器的访问。另一个选项是[使用 TLS](#gitaly-tls-support)。


  

  

    
整个 Gitaly 文档中提到的令牌是由管理员选择的任意密码。该令牌与为 GitLab API 或其他类似 Web API 创建的令牌无关。




以下步骤描述了如何配置名为 `gitaly1.internal` 且密钥令牌为 `gitalysecret` 的单个 Gitaly 服务器。我们假设您的 GitLab 安装有两个仓库存储：`default` 和 `storage1`。

要配置 Gitaly 服务器，请在用作 Gitaly 的服务器节点上执行以下操作：

1. [下载并安装](../../install/package/_index.md#supported-platforms)您选择的 Linux 软件包。确保仅添加 GitLab 软件包仓库并为所选操作系统安装 GitLab，但**不要**提供 `EXTERNAL_URL` 值。
1. 编辑 Gitaly 服务节点的 `/etc/gitlab/gitlab.rb` 文件以配置存储路径、启用网络监听器并配置令牌：

   

  

  

    
您不能从 gitaly['configuration'][:storage] 中删除 default 条目，因为GitLab 要求它。




   <!--
   对示例的更新必须在以下位置进行：
   - https://gitlab.com/gitlab-org/charts/gitlab/blob/master/doc/advanced/external-gitaly/external-omnibus-gitaly.md#configure-omnibus-gitlab
   - https://gitlab.com/gitlab-org/gitlab/blob/master/doc/administration/gitaly/index.md#gitaly-server-configuration
   - 所有参考架构页面
   -->

   ```ruby
   # 避免在 Gitaly 服务器上运行不必要的服务
   postgresql['enable'] = false
   redis['enable'] = false
   nginx['enable'] = false
   puma['enable'] = false
   sidekiq['enable'] = false
   gitlab_workhorse['enable'] = false
   prometheus['enable'] = false
   alertmanager['enable'] = false
   gitlab_exporter['enable'] = false
   gitlab_kas['enable'] = false

   # 防止升级时自动运行数据库迁移
   gitlab_rails['auto_migrate'] = false

   # 配置 gitlab-shell API 回调 URL。如果没有这个，`git push` 将失败。这可以是您的“前端”GitLab URL 或内部负载均衡器。
   gitlab_rails['internal_api_url'] = 'https://gitlab.example.com'

   # Gitaly
   gitaly['enable'] = true

   # 设置用于监控的导出程序的监听地址
   node_exporter['listen_address'] = '0.0.0.0:9100'

   gitaly['configuration'] = {
      # ...
      #
      # 使 Gitaly 接受所有网络接口上的连接。您必须使用防火墙来限制对此地址/端口的访问。
      # 如果您只想支持 TLS 连接，请注释掉以下行
      listen_addr: '0.0.0.0:8075',
      prometheus_listen_addr: '0.0.0.0:9236',
      # Gitaly 身份验证令牌
      # 应与 praefect_internal_token 相同
      auth: {
         # ...
         #
         # Gitaly 的身份验证令牌用于验证发往 Gitaly 的 gRPC 请求。这必须与 GitLab Rails 应用程序设置中的相应值匹配。
         token: 'gitalysecret',
      },
      # Gitaly Pack-objects 缓存
      # 启用可提高性能，但会显著增加磁盘 I/O
      # 请参阅 https://docs.gitlab.com/ee/administration/gitaly/configure_gitaly.html#pack-objects-cache 了解更多信息
      pack_objects_cache: {
         # ...
         enabled: true,
      },
      storage: [
         {
            name: 'default',
            path: '/var/opt/gitlab/git-data',

{
   "gitaly": {
      "listen_addr": "unix:///var/opt/gitlab/gitaly/gitaly.socket",
      "dir": {
         "default": {
            "path": "/var/opt/gitlab/git-data"
         },
         "repositories": [
            {
               name: 'storage1',
               path: '/mnt/gitlab/git-data',
            },
         ],
      }
   }
}

1. 从你配置的第一个Linux包节点复制 /etc/gitlab/gitlab-secrets.json 文件，并将同名文件添加或替换到此服务器上。如果这是你要配置的第一个Linux包节点，则可以跳过此步骤。

2. 重新配置GitLab，以使更改生效。

3. 确认Gitaly能够对内部API执行回调：

   • 对于GitLab 15.3及更高版本，运行 sudo -u git -- /opt/gitlab/embedded/bin/gitaly check /var/opt/gitlab/gitaly/config.toml。
   • 对于GitLab 15.2及更早版本，运行 sudo -u git -- /opt/gitlab/embedded/bin/gitaly-hooks check /var/opt/gitlab/gitaly/config.toml。

Gitaly的TLS支持

Gitaly支持TLS加密。要与监听安全连接的Gitaly实例通信，必须在GitLab配置中对应存储条目的gitaly_address中使用tls:// URL方案。

您必须自行提供证书，因为系统不会自动提供。该证书或其证书颁发机构必须安装在所有Gitaly节点（包括使用该证书的Gitaly节点）以及所有与之通信的客户端节点上，遵循GitLab自定义证书配置中描述的步骤。

可以同时配置Gitaly服务器，使其拥有未加密的监听地址（listen_addr）和加密的监听地址（tls_listen_addr）。这允许在必要时逐步从未加密流量过渡到加密流量。

要配置Gitaly启用TLS：

1. 创建/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

2. 将证书复制到/etc/gitlab/trusted-certs，这样Gitaly在自我调用时会信任该证书：

   sudo cp /etc/gitlab/ssl/cert.pem /etc/gitlab/trusted-certs/

3. 编辑/etc/gitlab/gitlab.rb并添加：

   gitaly['configuration'] = {
      # ...
      tls_listen_addr: '0.0.0.0:9999',
      tls: {
         certificate_path: '/etc/gitlab/ssl/cert.pem',
         key_path: '/etc/gitlab/ssl/key.pem',
      },
   }

4. 删除gitaly['listen_addr']以仅允许加密连接。

5. 保存文件并重新配置GitLab。

配置 Sidekiq

Sidekiq 需要连接到 Redis、PostgreSQL 和 Gitaly 实例。 还建议连接到 对象存储。

若要配置 Sidekiq 服务器，请在你要用作 Sidekiq 的服务器节点上：

1. 通过 SSH 登录到 Sidekiq 服务器。

2. 确认你可以访问 PostgreSQL、Gitaly 和 Redis 端口：

   telnet <GitLab 主机> 5432 # PostgreSQL
   telnet <GitLab 主机> 8075 # Gitaly
   telnet <GitLab 主机> 6379 # Redis

3. 下载并安装 你选择的 Linux 包。 请务必仅添加 GitLab 软件包仓库并为你的操作系统安装 GitLab。

4. 创建或编辑 /etc/gitlab/gitlab.rb 并使用以下配置：

   # https://docs.gitlab.com/omnibus/roles/#sidekiq-roles
   roles(["sidekiq_role"])
   
   # 外部 URL
   external_url 'https://gitlab.example.com'
   
   ## Redis 连接详情
   gitlab_rails['redis_port'] = '6379'
   gitlab_rails['redis_host'] = '10.1.0.6' # Redis 服务器的 IP/主机名
   gitlab_rails['redis_password'] = 'Redis 密码'
   
   # Gitaly 和 GitLab 使用两个共享密钥进行身份验证，一个用于向 Gitaly 进行 gRPC 请求的身份验证，
   # 另一个存储在 /etc/gitlab/gitlab-secrets.json 中，用于从 GitLab-Shell 到 GitLab 内部 API 的身份验证回调。
   # 以下值必须与 Gitaly 设置中相应的值相同
   gitlab_rails['gitaly_token'] = 'gitalysecret'
   
   gitlab_rails['repositories_storages'] = {
     'default' => { 'gitaly_address' => 'tcp://gitaly1.internal:8075' },
     'storage1' => { 'gitaly_address' => 'tcp://gitaly1.internal:8075' },
     'storage2' => { 'gitaly_address' => 'tcp://gitaly2.internal:8075' },
   }
   
   ## PostgreSQL 连接详情
   gitlab_rails['db_adapter'] = 'postgresql'
   gitlab_rails['db_encoding'] = 'unicode'
   gitlab_rails['db_host'] = '10.1.0.5' # 数据库服务器的 IP/主机名
   gitlab_rails['db_password'] = '数据库密码'
   
   ## 防止升级时自动运行数据库迁移
   gitlab_rails['auto_migrate'] = false
   
   # Sidekiq
   sidekiq['listen_address'] = "0.0.0.0"
   
   ## 将 Sidekiq 队列进程数设置为与可用 CPU 数量相同的数量
   sidekiq['queue_groups'] = ['*'] * 4
   
   ## 设置导出器将监听的网路地址
   node_exporter['listen_address'] = '0.0.0.0:9100'
   
   # 对象存储
   ## 这是配置 GCP 上对象存储的示例
   ## 根据需要替换此配置为你选择的对象存储提供商
   gitlab_rails['object_store']['enabled'] = true
   gitlab_rails['object_store']['connection'] = {
     'provider' => 'Google',
     'google_project' => '<gcp-project-name>',
     'google_json_key_location' => '<path-to-gcp-service-account-key>'
   }
   gitlab_rails['object_store']['objects']['artifacts']['bucket'] = "<gcp-artifacts-bucket-name>"
   gitlab_rails['object_store']['objects']['external_diffs']['bucket'] = "<gcp-external-diffs-bucket-name>"
   gitlab_rails['object_store']['objects']['lfs']['bucket'] = "<gcp-lfs-bucket-name>"
   gitlab_rails['object_store']['objects']['uploads']['bucket'] = "<gcp-uploads-bucket-name>"
   gitlab_rails['object_store']['objects']['packages']['bucket'] = "<gcp-packages-bucket-name>"
   gitlab_rails['object_store']['objects']['dependency_proxy']['bucket'] = "<gcp-dependency-proxy-bucket-name>"
   gitlab_rails['object_store']['objects']['terraform_state']['bucket'] = "<gcp-terraform-state-bucket-name>"
   
   gitlab_rails['backup_upload_connection'] = {
     'provider' => 'Google',
     'google_project' => '<gcp-project-name>',
     'google_json_key_location' => '<path-to-gcp-service-account-key>'
   }
   gitlab_rails['backup_upload_remote_directory'] = "<gcp-backups-state-bucket-name>"
   gitlab_rails['ci_secure_files_object_store_enabled'] = true
   gitlab_rails['ci_secure_files_object_store_remote_directory'] = "gcp-ci_secure_files-bucket-name"
   
   gitlab_rails['ci_secure_files_object_store_connection'] = {
      'provider' => 'Google',
      'google_project' => '<gcp-project-name>',
      'google_json_key_location' => '<path-to-gcp-service-account-key>'
   }

5. 从你配置的第一个Linux包节点复制 /etc/gitlab/gitlab-secrets.json 文件，并将此服务器上同名的文件添加或替换。如果这是你要配置的第一个Linux包节点，则可以跳过此步骤。

6. 为确保数据库迁移仅在重新配置期间运行，而不是在升级时自动运行，请执行：

   sudo touch /etc/gitlab/skip-auto-reconfigure

   只有指定的单个节点应处理迁移，详情见 GitLab Rails post-configuration 部分。

7. 保存文件并重新配置GitLab。

8. 验证GitLab服务正在运行：

   sudo gitlab-ctl status

   输出应类似于以下内容：

   run: logrotate: (pid 192292) 2990s; run: log: (pid 26374) 93048s
   run: node-exporter: (pid 26864) 92997s; run: log: (pid 26446) 93036s
   run: sidekiq: (pid 26870) 92996s; run: log: (pid 26391) 93042s

配置 GitLab Rails

本节介绍如何配置 GitLab 应用程序（Rails）组件。

在我们的架构中，我们使用 Puma Web 服务器运行每个 GitLab Rails 节点，并将工作线程数设置为可用 CPU 的 90%，包含四个线程。对于与其他组件一起运行的 Rails 节点，应相应减少工作线程值。我们发现工作线程值为 50% 能达到良好的平衡，但这取决于工作负载。

在每个节点执行以下操作：

1. 下载并安装 您选择的 Linux 包。请确保仅添加 GitLab 包仓库并为所选操作系统安装 GitLab。

2. 创建或编辑 /etc/gitlab/gitlab.rb 并使用以下配置。
   为了在节点间保持链接的一致性，应用服务器上的 external_url 应指向用户访问 GitLab 时使用的对外 URL。这将是负载均衡器的 URL，它将流量路由到 GitLab 应用服务器：

   external_url 'https://gitlab.example.com'
   
   # Gitaly 和 GitLab 使用两个共享密钥进行身份验证，一个用于向 Gitaly 进行 gRPC 请求的身份验证，另一个存储在 /etc/gitlab/gitlab-secrets.json 中，用于从 GitLab-Shell 到 GitLab 内部 API 的身份验证回调。
   # 以下设置必须与 Gitaly 设置中的对应值相同
   gitlab_rails['gitaly_token'] = 'gitalysecret'
   
   gitlab_rails['repositories_storages'] = {
     'default' => { 'gitaly_address' => 'tcp://gitaly1.internal:8075' },
     'storage1' => { 'gitaly_address' => 'tcp://gitaly1.internal:8075' },
     'storage2' => { 'gitaly_address' => 'tcp://gitaly2.internal:8075' },
   }
   
   ## 禁用在 GitLab 应用服务器上不存在的组件
   roles(['application_role'])
   gitaly['enable'] = false
   sidekiq['enable'] = false
   
   ## PostgreSQL 连接详情
   gitlab_rails['db_adapter'] = 'postgresql'
   gitlab_rails['db_encoding'] = 'unicode'
   gitlab_rails['db_host'] = '10.1.0.5' # 数据库服务器的 IP/主机名
   gitlab_rails['db_password'] = '数据库密码'
   
   ## Redis 连接详情
   gitlab_rails['redis_port'] = '6379'
   gitlab_rails['redis_host'] = '10.1.0.6' # Redis 服务器的 IP/主机名
   gitlab_rails['redis_password'] = 'Redis 密码'
   
   # 设置监控所用的导出器监听的网路地址
   node_exporter['listen_address'] = '0.0.0.0:9100'
   gitlab_workhorse['prometheus_listen_addr'] = '0.0.0.0:9229'
   puma['listen'] = '0.0.0.0'
   
   # 将监控节点的 IP 地址添加到监控白名单中，并允许其抓取 NGINX 指标。将占位符 `<MONITOR NODE IP>` 替换为从监控节点收集到的地址和/或子网
   gitlab_rails['monitoring_whitelist'] = ['<MONITOR NODE IP>/32', '127.0.0.0/8']
   nginx['status']['options']['allow'] = ['<MONITOR NODE IP>/32', '127.0.0.0/8']
   
   # 对象存储
   # 这是配置 GCP 对象存储的示例
   # 根据您的需求替换为您选择的对象存储提供商配置
   gitlab_rails['object_store']['enabled'] = true
   gitlab_rails['object_store']['connection'] = {
     'provider' => 'Google',
     'google_project' => '<gcp-project-name>',
     'google_json_key_location' => '<path-to-gcp-service-account-key>'
   }
   gitlab_rails['object_store']['objects']['artifacts']['bucket'] = "<gcp-artifacts-bucket-name>"
   gitlab_rails['object_store']['objects']['external_diffs']['bucket'] = "<gcp-external-diffs-bucket-name>"
   gitlab_rails['object_store']['objects']['lfs']['bucket'] = "<gcp-lfs-bucket-name>"
   gitlab_rails['object_store']['objects']['uploads']['bucket'] = "<gcp-uploads-bucket-name>"
   gitlab_rails['object_store']['objects']['packages']['bucket'] = "<gcp-packages-bucket-name>"
   gitlab_rails['object_store']['objects']['dependency_proxy']['bucket'] = "<gcp-dependency-proxy-bucket-name>"
   gitlab_rails['object_store']['objects']['terraform_state']['bucket'] = "<gcp-terraform-state-bucket-name>"
   
   gitlab_rails['backup_upload_connection'] = {
     'provider' => 'Google',
     'google_project' => '<gcp-project-name>',
     'google_json_key_location' => '<path-to-gcp-service-account-key>'
   }
   gitlab_rails['backup_upload_remote_directory'] = "<gcp-backups-state-bucket-name>"
   
   gitlab_rails['ci_secure_files_object_store_enabled'] = true
   gitlab_rails['ci_secure_files_object_store_remote_directory'] = "gcp-ci_secure_files-bucket-name"
   
   gitlab_rails['ci_secure_files_object_store_connection'] = {
      'provider' => 'Google',
      'google_project' => '<gcp-project-name>',
      'google_json_key_location' => '<path-to-gcp-service-account-key>'
   }
   
   ## 如果已设置 NFS，请取消注释并编辑以下选项
   ## 

如果NFS数据挂载不可用，阻止GitLab启动

#high_availability[‘mountpoint’] = ‘/var/opt/gitlab/git-data’

确保通过NFS在各服务器间UID和GID匹配以实现权限管理

#user[‘uid’] = 9000 #user[‘gid’] = 9000 #web_server[‘uid’] = 9001 #web_server[‘gid’] = 9001 #registry[‘uid’] = 9002 #registry[‘gid’] = 9002

1. 如果你正在使用[带有TLS支持的Gitaly](#gitaly-tls-support)，请确保 `gitlab_rails['repositories_storages']` 条目配置为 `tls` 而不是 `tcp`：

   ```ruby
   gitlab_rails['repositories_storages'] = {
     'default' => { 'gitaly_address' => 'tls://gitaly1.internal:9999' },
     'storage1' => { 'gitaly_address' => 'tls://gitaly1.internal:9999' },
     'storage2' => { 'gitaly_address' => 'tls://gitaly2.internal:9999' },
   }

1. 将证书复制到 /etc/gitlab/trusted-certs：

   sudo cp cert.pem /etc/gitlab/trusted-certs/

2. 从你配置的第一个Linux包节点复制 /etc/gitlab/gitlab-secrets.json 文件，并在此服务器上添加或替换同名文件。如果你正在配置第一个Linux包节点，则可以跳过此步骤。

3. 从你配置的第一个Rails节点复制SSH主机密钥（所有名称格式为 /etc/ssh/ssh_host_*_key*），并在此服务器上添加或替换同名文件。这可确保用户访问负载均衡的Rails节点时不会出现主机不匹配错误。如果你正在配置第一个Linux包节点，则可以跳过此步骤。

4. 为了确保数据库迁移仅在重新配置时运行，而不是在升级时自动运行，执行：

   sudo touch /etc/gitlab/skip-auto-reconfigure

   仅一个指定的节点应处理迁移，详情见 GitLab Rails 后配置 部分。

5. 重新配置GitLab 以使更改生效。

6. 启用增量日志。

7. 运行 sudo gitlab-rake gitlab:gitaly:check 确认节点可与Gitaly连接。

8. 跟踪日志查看请求：

   sudo gitlab-ctl tail gitaly

当你指定 external_url 为 https 时（如前例所示），GitLab期望SSL证书位于 /etc/gitlab/ssl/。如果证书不存在，NGINX将无法启动。更多信息，请参阅 HTTPS文档。

GitLab Rails 安装后配置

1. 指定一个应用节点在安装和更新期间运行数据库迁移。初始化 GitLab 数据库并确保所有迁移已运行：

   sudo gitlab-rake gitlab:db:configure

   此操作需要将 Rails 节点配置为直接连接到主数据库，绕过 PgBouncer。迁移完成后，必须将该节点重新配置为再次通过 PgBouncer。

2. 配置授权 SSH 密钥的快速查找。

配置 Prometheus

Linux 包可用于配置运行 Prometheus 的独立监控节点：

1. 通过 SSH 连接到监控节点。

2. 下载并安装 您选择的 Linux 包。请确保仅添加 GitLab 包仓库并为所选操作系统安装 GitLab。

3. 编辑 /etc/gitlab/gitlab.rb 并添加以下内容：

   roles(['monitoring_role'])
   nginx['enable'] = false
   
   external_url 'http://gitlab.example.com'
   
   # Prometheus
   prometheus['listen_address'] = '0.0.0.0:9090'
   prometheus['monitor_kubernetes'] = false

4. Prometheus 还需要一些抓取配置来从我们配置了导出器的各个节点拉取所有数据。假设您的节点 IP 如下：

   1.1.1.1: postgres
   1.1.1.2: redis
   1.1.1.3: gitaly1
   1.1.1.4: rails1
   1.1.1.5: rails2
   1.1.1.6: sidekiq

   将以下内容添加到 /etc/gitlab/gitlab.rb：

   prometheus['scrape_configs'] = [
     {
        'job_name': 'postgres',
        'static_configs' => [
        'targets' => ['1.1.1.1:9187'],
        ],
     },
     {
        'job_name': 'redis',
        'static_configs' => [
        'targets' => ['1.1.1.2:9121'],
        ],
     },
     {
        'job_name': 'gitaly',
        'static_configs' => [
        'targets' => ['1.1.1.3:9236'],
        ],
     },
     {
        'job_name': 'gitlab-nginx',
        'static_configs' => [
        'targets' => ['1.1.1.4:8060', '1.1.1.5:8060'],
        ],
     },
     {
        'job_name': 'gitlab-workhorse',
        'static_configs' => [
        'targets' => ['1.1.1.4:9229', '1.1.1.5:9229'],
        ],
     },
     {
        'job_name': 'gitlab-rails',
        'metrics_path': '/-/metrics',
        'static_configs' => [
        'targets' => ['1.1.1.4:8080', '1.1.1.5:8080'],
        ],
     },
     {
        'job_name': 'gitlab-sidekiq',
        'static_configs' => [
        'targets' => ['1.1.1.6:8082'],
        ],
     },
     {
        'job_name': 'static-node',
        'static_configs' => [
        'targets' => ['1.1.1.1:9100', '1.1.1.2:9100', '1.1.1.3:9100', '1.1.1.4:9100', '1.1.1.5:9100', '1.1.1.6:9100'],
        ],
     },
   ]

5. 保存文件并 重新配置 GitLab。

配置对象存储

GitLab 支持使用 对象存储 服务来存储多种类型的数据。它比 NFS 更适合用于数据对象，通常在大规模部署中表现更好，因为对象存储通常更具性能、可靠性和可扩展性。有关更多信息，请参阅 推荐的云服务商和服务。

在 GitLab 中有两种指定对象存储配置的方式：

• 合并形式：单个凭证由所有支持的 object 类型共享。
• 特定存储形式：每个 object 定义自己的对象存储 连接和配置。

以下示例中使用了合并形式（如果可用）。

为每种数据类型使用单独的桶是 GitLab 推荐的方法。这确保了 GitLab 存储的各种数据类型之间不会发生冲突。未来有计划 启用使用单个桶。

启用增量日志记录

GitLab Runner 以分块形式返回作业日志，即使使用合并的对象存储，Linux 包默认也会将这些日志临时缓存在磁盘上的 /var/opt/gitlab/gitlab-ci/builds 目录中。

使用默认配置时，此目录需要通过 NFS 在任何 GitLab Rails 和 Sidekiq 节点上共享。

虽然通过 NFS 共享作业日志是支持的，但可以通过启用增量日志记录（当未部署 NFS 节点时需要）来避免使用 NFS 的要求。增量日志记录使用 Redis 而不是磁盘空间来临时缓存作业日志。

配置高级搜索

您可以使用 Elasticsearch 并启用高级搜索，在整个 GitLab 实例中进行更快、更高级的代码搜索。

Elasticsearch 集群的设计和要求取决于您的特定数据。有关如何设置 Elasticsearch 集群以及与实例配合使用的推荐最佳实践，请参阅如何选择最优集群配置。

基于 Helm Charts 的云原生混合参考架构（替代方案）

另一种方法是使用 Kubernetes 运行特定的 GitLab 组件。支持以下服务：

• GitLab Rails
• Sidekiq
• NGINX
• Toolbox
• Migrations
• Prometheus

混合安装结合了云原生和传统计算部署的优势。通过这种方式，无状态组件可以利用云原生工作负载管理的优势，而有状态组件则部署在带有 Linux 包安装的计算 VM 中，以获得更高的持久性。

有关设置说明，包括如何在 Kubernetes 和后端组件之间同步哪些 GitLab 密钥的指导，请参阅 Helm 图表高级配置文档。

集群拓扑

以下表格和图表详细说明了混合环境，采用与之前记录的典型环境相同的格式。

首先是运行在Kubernetes中的组件。这些组件分布在多个节点组中，尽管您可以根据需要更改整体构成，只要满足最低的CPU和内存要求即可。

• 对于此设置，我们定期进行测试，并推荐Google Kubernetes Engine (GKE) 和 Amazon Elastic Kubernetes Service (EKS)。其他Kubernetes服务也可能适用，但效果可能因情况而异。
• 机器类型示例用于说明目的。这些类型用于验证和测试，但并非强制默认值。支持切换到符合所列要求的其它机器类型。有关更多信息，请参阅支持的机器类型。
• Webservice 和 Sidekiq 的目标节点池总数仅适用于GitLab组件。所选Kubernetes提供商的系统进程需要额外的资源。给出的示例已考虑这一点。
• Supporting 的目标节点池总数通常是为了容纳支持GitLab部署以及根据需求可能进行的任何额外部署所需的多种资源。与其他节点池类似，所选Kubernetes提供商的系统进程也需要资源。给出的示例已考虑这一点。
• 在生产部署中，不需要将Pod分配给特定节点。但是，建议每个池中有多个节点分布在不同可用区，以符合弹性云架构实践。
• 出于效率原因鼓励启用自动伸缩（如Cluster Autoscaler），但通常建议将Webservice和Sidekiq Pod的目标下限设为75%，以确保持续性能。

接下来是在静态计算VM（使用Linux包）或适用的外部PaaS服务上运行的 backend 组件：

脚注：

1. 机器类型示例用于说明目的。这些类型用于验证和测试，但并非强制默认值。支持切换到符合所列要求的其它机器类型，包括可用的ARM变体。有关更多信息，请参阅支持的机器类型。
2. 可以选择在信誉良好的第三方外部PaaS PostgreSQL解决方案上运行。有关更多信息，请参阅提供自己的PostgreSQL实例和推荐的云提供商和服务。
3. 可以选择在信誉良好的第三方外部PaaS Redis解决方案上运行。有关更多信息，请参阅提供自己的Redis实例和推荐的云提供商和服务。
4. 应该在信誉良好的云提供商或自管理解决方案上运行。有关更多信息，请参阅配置对象存储。
5. Gitaly规格基于使用健康状况良好的正常大小仓库。但是，如果您有大型monorepo（大于几吉字节），这会显著影响Git和Gitaly的性能，并且可能需要增加规格。

请参阅 大型单体仓库 获取更多信息。

@startuml 2k
skinparam linetype ortho

card "Kubernetes via Helm Charts" as kubernetes {
  card "**External Load Balancer**" as elb #6a9be7

  together {
    collections "**Webservice**" as gitlab #32CD32
    collections "**Sidekiq**" as sidekiq #ff8dd1
  }

  collections "**Supporting Services**" as support
}

card "**Gitaly**" as gitaly #FF8C00
card "**PostgreSQL**" as postgres #4EA7FF
card "**Redis**" as redis #FF6347
cloud "**Object Storage**" as object_storage #white

elb -[#6a9be7]-> gitlab

gitlab -[#32CD32]--> gitaly
gitlab -[#32CD32]--> postgres
gitlab -[#32CD32]-> object_storage
gitlab -[#32CD32]--> redis

sidekiq -[#ff8dd1]--> gitaly
sidekiq -[#ff8dd1]-> object_storage
sidekiq -[#ff8dd1]--> postgres
sidekiq -[#ff8dd1]--> redis

@enduml

Kubernetes 组件目标

以下部分详细说明了部署在 Kubernetes 中的 GitLab 组件所使用的目标。

Webservice

每个 Webservice pod（Puma 和 Workhorse）建议按以下配置运行：

• 4 个 Puma Worker
• 4 个 vCPU
• 5 GB 内存（请求）
• 7 GB 内存（限制）

对于 40 RPS 或 2000 用户，我们建议总 Puma worker 数量约为 12，因此建议至少运行 3 个 Webservice pod。

有关 Webservice 资源使用的更多信息，请参阅 Charts 文档中 Webservice 资源 部分。

NGINX

还建议将 NGINX 控制器 pod 作为 DaemonSet 部署在 Webservice 节点上。这允许控制器根据它们服务的 Webservice pod 动态扩展，并利用较大机器类型通常具有的更高网络带宽。

这不是严格要求。只要 NGINX 控制器 pod 有足够的资源来处理 Web 流量，就可以按需部署。

Sidekiq

每个 Sidekiq pod 建议按以下配置运行：

• 1 个 Sidekiq worker
• 900m vCPU
• 2 GB 内存（请求）
• 4 GB 内存（限制）

与之前记录的标准部署类似，这里使用了初始目标 4 个 Sidekiq worker。根据您的具体工作流程，可能需要额外的 worker。

有关 Sidekiq 资源使用的更多信息，请参阅 Charts 文档中 Sidekiq 资源 部分。

Supporting

Supporting Node Pool 旨在容纳所有不需要在 Webservice 和 Sidekiq 池中运行的辅助部署。

这包括与云提供商实现相关的各种部署以及支持 GitLab 的部署，例如 GitLab Shell。

若要部署其他部署（如 Container Registry、Pages 或 Monitoring），应尽可能将其部署在 Supporting Node Pool 中，而不是在 Webservice 或 Sidekiq 池中。Supporting Node Pool 已设计为可容纳多个额外部署。但是，如果您的部署不符合给定池的要求，可以相应地增加节点池。相反，如果您的用例中的池过度配置，则可以相应减少。

示例配置文件

针对 40 RPS 或 2000 用户的参考架构配置的 GitLab Helm Charts 示例 可在 Charts 项目中找到。

下一步

遵循本指南后，您现在应该拥有一个全新的 GitLab 环境，核心功能已相应配置。

您可能需要根据需求配置 GitLab 的其他可选功能。有关更多信息，请参阅 安装 GitLab 后的步骤。