参考架构：最高 60 RPS 或 3,000 用户

本页面描述了极狐GitLab 参考架构，旨在达到每秒 60 次请求（RPS）的峰值负载，典型的峰值负载为 3,000 名用户，包括手动和自动用户，基于真实数据。

这是内置高可用性（HA）的最小架构。如果您需要 HA，但用户数量或总负载较低，请参阅支持的修改以降低用户数量部分，以了解如何在保持 HA 的同时缩小架构规模。

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

服务 节点 配置 GCP AWS Azure
外部负载均衡器3 1 4 vCPU，3.6 GB 内存 n1-highcpu-4 c5n.xlarge F4s v2
Consul1 3 2 vCPU，1.8 GB 内存 n1-highcpu-2 c5.large F2s v2
PostgreSQL1 3 2 vCPU，7.5 GB 内存 n1-standard-2 m5.large D2s v3
PgBouncer1 3 2 vCPU，1.8 GB 内存 n1-highcpu-2 c5.large F2s v2
内部负载均衡器3 1 4 vCPU，3.6 GB 内存 n1-highcpu-4 c5n.xlarge F4s v2
Redis/Sentinel2 3 2 vCPU，7.5 GB 内存 n1-standard-2 m5.large D2s v3
Gitaly5 3 4 vCPU，15 GB 内存6 n1-standard-4 m5.xlarge D4s v3
Praefect5 3 2 vCPU，1.8 GB 内存 n1-highcpu-2 c5.large F2s v2
Praefect PostgreSQL1 1+ 2 vCPU，1.8 GB 内存 n1-highcpu-2 c5.large F2s v2
Sidekiq7 2 4 vCPU，15 GB 内存 n1-standard-4 m5.xlarge D2s v3
极狐GitLab Rails7 3 8 vCPU，7.2 GB 内存 n1-highcpu-8 c5.2xlarge F8s v2
监控节点 1 2 vCPU，1.8 GB 内存 n1-highcpu-2 c5.large F2s v2
对象存储4 - - - - -

脚注：

  1. 可以选择在知名的第三方外部 PaaS PostgreSQL 解决方案上运行。有关详细信息，请参阅提供您自己的 PostgreSQL 实例。
  2. 可以选择在知名的第三方外部 PaaS Redis 解决方案上运行。有关详细信息，请参阅提供您自己的 Redis 实例。
  3. 推荐与知名的第三方负载均衡器或服务（LB PaaS）一起运行，提供 HA 能力。大小取决于所选负载均衡器以及网络带宽等其他因素。有关更多信息，请参阅负载均衡器。
  4. 应在知名的云提供商或私有化部署解决方案上运行。有关更多信息，请参阅配置对象存储。
  5. Gitaly 集群提供容错的优势，但带来了额外的设置和管理复杂性。在部署 Gitaly 集群之前，请查看现有的技术限制和注意事项。如果您想要分片 Gitaly，请使用上面列出的 Gitaly 的相同规格。
  6. 可以放置在 Auto Scaling Groups (ASGs) 中，因为组件不存储任何状态数据。然而，云原生混合设置通常更受欢迎，因为某些组件如迁移和Mailroom只能在一个节点上运行，在 Kubernetes 中处理得更好。
note对于涉及配置实例的所有 PaaS 解决方案，建议在三个不同的可用性区域中实施至少三个节点，以符合弹性云架构实践。

要求

在开始之前，请参阅参考架构的要求。

测试方法

3k 架构旨在涵盖大多数工作流程，并由测试平台团队定期进行烟雾和性能测试，以实现以下端点吞吐量目标：

  • API：60 RPS
  • Web：6 RPS
  • Git（拉取）：6 RPS
  • Git（推送）：1 RPS

上述目标是基于真实客户数据选择的，总环境负载与用户数量相对应，包括 CI 和其他工作负载。

如果您有指标表明您在上述端点目标上定期具有更高的吞吐量，大型 monorepos或显著的其他工作负载，这些可能会显著影响性能环境，并可能需要进一步调整。如果这适用于您，我们强烈建议您参考链接的文档，并联系您的客户成功经理或我们的支持团队以获取进一步指导。

测试通过使用我们的极狐GitLab 性能工具 (GPT)及其数据集定期进行，任何人都可以使用。测试结果在 GPT wiki 上公开提供。有关我们的测试策略的更多信息，请参考文档的这一部分。

用于测试的负载均衡器是用于 Linux 软件包环境的 HAProxy 或具有 NGINX Ingress 的云原生混合云提供商服务。这些选择不代表特定需求或建议，因为大多数知名负载均衡器预计可以正常工作。

设置组件

要设置极狐GitLab 及其组件以适应最高 60 RPS 或 3,000 用户：

  1. 配置外部负载均衡器以处理极狐GitLab 应用服务节点的负载均衡。
  2. 配置内部负载均衡器以处理极狐GitLab 应用程序内部连接的负载均衡。
  3. 配置 Consul用于服务发现和健康检查。
  4. 配置 PostgreSQL，极狐GitLab 的数据库。
  5. 配置 PgBouncer用于数据库连接池和管理。
  6. 配置 Redis，用于存储会话数据、临时缓存信息和后台作业队列。
  7. 配置 Gitaly 集群，提供对 Git 存储库的访问。
  8. 配置 Sidekiq用于后台作业处理。
  9. 配置主要的极狐GitLab Rails 应用程序以运行 Puma、Workhorse、极狐GitLab Shell，并提供所有前端请求（包括 UI、API 和 Git over HTTP/SSH）。
  10. 配置 Prometheus以监控您的极狐GitLab 环境。
  11. 配置用于共享数据对象的对象存储。
  12. 配置高级搜索（可选）以实现更快、更高级的代码搜索。

服务器启动在相同的 10.6.0.0/24 私有网络范围，并且可以在这些地址上自由连接。

以下列表包括每个服务器的描述及其分配的 IP：

  • 10.6.0.10: 外部负载均衡器
  • 10.6.0.11: Consul/Sentinel 1
  • 10.6.0.12: Consul/Sentinel 2
  • 10.6.0.13: Consul/Sentinel 3
  • 10.6.0.21: PostgreSQL 主服务器
  • 10.6.0.22: PostgreSQL 从服务器 1
  • 10.6.0.23: PostgreSQL 从服务器 2
  • 10.6.0.31: PgBouncer 1
  • 10.6.0.32: PgBouncer 2
  • 10.6.0.33: PgBouncer 3
  • 10.6.0.20: 内部负载均衡器
  • 10.6.0.61: Redis 主服务器
  • 10.6.0.62: Redis 副本 1
  • 10.6.0.63: Redis 副本 2
  • 10.6.0.51: Gitaly 1
  • 10.6.0.52: Gitaly 2
  • 10.6.0.93: Gitaly 3
  • 10.6.0.131: Praefect 1
  • 10.6.0.132: Praefect 2
  • 10.6.0.133: Praefect 3
  • 10.6.0.141: Praefect PostgreSQL 1（非 HA）
  • 10.6.0.71: Sidekiq 1
  • 10.6.0.72: Sidekiq 2
  • 10.6.0.41: 极狐GitLab 应用 1
  • 10.6.0.42: 极狐GitLab 应用 2
  • 10.6.0.43: 极狐GitLab 应用 3
  • 10.6.0.81: Prometheus

配置外部负载均衡器

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

关于使用哪个负载均衡器或其确切配置的详细信息超出了极狐GitLab 文档的范围，但请参阅负载均衡器以获取有关一般要求的更多信息。本节将重点介绍为您选择的负载均衡器配置的具体内容。

就绪检查

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

端口

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

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

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

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

替代 SSH 端口

某些组织有政策禁止打开 SSH 端口 22。在这种情况下，配置一个备用 SSH 主机名可能会有所帮助，使用户能够在端口 443 上使用 SSH。备用 SSH 主机名将需要一个新的虚拟 IP 地址，与上面的其他极狐GitLab HTTP 配置相比。

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

LB 端口 后端端口 协议
443 22 TCP

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 文档。

配置内部负载均衡器

在多节点极狐GitLab 配置中，您需要一个内部负载均衡器来路由流量，以选择内部组件（如连接到 PgBouncer 和 Praefect（Gitaly 集群））的连接。

关于使用哪个负载均衡器或其确切配置的详细信息超出了极狐GitLab 文档的范围，但请参阅负载均衡器以获取有关一般要求的更多信息。本节将重点介绍为您选择的负载均衡器配置的具体内容。

以下 IP 将用作示例：

  • 10.6.0.40: 内部负载均衡器

以下是如何使用 HAProxy 的示例： 

global
    log /dev/log local0
    log localhost local1 notice
    log stdout format raw local0

defaults
    log global
    default-server inter 10s fall 3 rise 2
    balance leastconn

frontend internal-pgbouncer-tcp-in
    bind *:6432
    mode tcp
    option tcplog

    default_backend pgbouncer

frontend internal-praefect-tcp-in
    bind *:2305
    mode tcp
    option tcplog
    option clitcpka

    default_backend praefect

backend pgbouncer
    mode tcp
    option tcp-check

    server pgbouncer1 10.6.0.31:6432 check
    server pgbouncer2 10.6.0.32:6432 check
    server pgbouncer3 10.6.0.33:6432 check

backend praefect
    mode tcp
    option tcp-check
    option srvtcpka

    server praefect1 10.6.0.131:2305 check
    server praefect2 10.6.0.132:2305 check
    server praefect3 10.6.0.133:2305 check

请参阅您首选负载均衡器的文档以获取进一步的指导。

配置 Consul

接下来，我们设置 Consul 服务器。

noteConsul 必须以奇数个节点部署，至少 3 个节点。这是为了确保节点可以作为仲裁的一部分进行投票。

以下 IP 将用作示例：

  • 10.6.0.11: Consul 1
  • 10.6.0.12: Consul 2
  • 10.6.0.13: Consul 3

配置 Consul：

  1. SSH 登录到将托管 Consul 的服务器。
  2. 下载并安装您选择的 Linux 软件包。确保仅遵循页面上的安装步骤 1 和 2，并选择正确的 Linux 软件包，与您当前安装的版本和类型（基础版或企业版）相同。

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

    roles(['consul_role'])

## 启用 Prometheus 的服务发现
consul['monitoring_service_discovery'] =  true

## Consul 服务器节点的 IP
## 您也可以使用 FQDN，并将其与 IP 混合使用
consul['configuration'] = {
   server: true,
   retry_join: %w(10.6.0.11 10.6.0.12 10.6.0.13),
}

# 设置导出器将监听的网络地址
node_exporter['listen_address'] = '0.0.0.0:9100'

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

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

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

  6. 对所有其他 Consul 节点重复上述步骤，并确保正确设置 IP。

当第三个 Consul 服务器的配置完成时，将选举出一个 Consul 领导者。查看 Consul 日志 sudo gitlab-ctl tail consul 显示 ...[INFO] consul: New leader elected: ...。

您可以列出当前的 Consul 成员（服务器、客户端）： 

sudo /opt/gitlab/embedded/bin/consul members

您可以验证极狐GitLab 服务正在运行： 

sudo gitlab-ctl status

输出应类似于以下内容： 

run: consul: (pid 30074) 76834s; run: log: (pid 29740) 76844s
run: logrotate: (pid 30925) 3041s; run: log: (pid 29649) 76861s
run: node-exporter: (pid 30093) 76833s; run: log: (pid 29663) 76855s

配置 PostgreSQL

在本节中，将指导您配置一个用于极狐GitLab 的高可用 PostgreSQL 集群。

提供您自己的 PostgreSQL 实例

您可以选择使用用于 PostgreSQL 的第三方外部服务。

应该使用知名的提供商或解决方案。 Amazon RDS 已知可以正常工作。然而，从 14.4.0 开始，Amazon Aurora 与默认启用的负载均衡器不兼容。

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

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

  1. HA Linux 软件包 PostgreSQL 设置包括 PostgreSQL、PgBouncer 和 Consul。使用第三方外部服务时，所有这些组件都不再需要。
  2. 根据数据库要求文档设置 PostgreSQL。
  3. 设置 gitlab 用户名，选择您自己的密码。gitlab 用户需要创建 gitlabhq_production 数据库的权限。
  4. 使用适当的详细信息配置极狐GitLab 应用服务器。此步骤在配置极狐GitLab Rails 应用程序中进行。
  5. 为实现 HA 所需的节点数可能因服务而异，可能与 Linux 软件包不匹配。
  6. 然而，如果希望通过读取副本实现进一步性能提升的数据库负载均衡，建议遵循参考架构的节点数量。

使用 Linux 软件包的独立 PostgreSQL

推荐的 Linux 软件包配置为具有复制和故障转移的 PostgreSQL 集群，要求：

  • 至少三个 PostgreSQL 节点。
  • 至少三个 Consul 服务器节点。
  • 至少三个 PgBouncer 节点，用于跟踪和处理主要数据库的读写请求。

  • 启用数据库负载均衡。

    本地 PgBouncer 服务在每个 PostgreSQL 节点上配置。它与跟踪主数据库的主 PgBouncer 集群分离。

以下 IP 用作示例：

  • 10.6.0.21: PostgreSQL 主服务器
  • 10.6.0.22: PostgreSQL 从服务器 1
  • 10.6.0.23: PostgreSQL 从服务器 2

首先，请确保在每个节点上安装 Linux 极狐GitLab 软件包。按照步骤，安装步骤 1 的必要依赖项，并从步骤 2 添加极狐GitLab 软件包存储库。在第二步安装极狐GitLab 时，不要提供 EXTERNAL_URL 值。

PostgreSQL 节点

  1. SSH 登录到其中一个 PostgreSQL 节点。

  2. 为 PostgreSQL 用户名/密码对生成密码哈希。这假设您使用默认用户名 gitlab（推荐）。命令请求密码和确认。使用此命令输出的值作为下一步中的 <postgresql_password_hash> 值： 

    sudo gitlab-ctl pg-password-md5 gitlab

  3. 为 PgBouncer 用户名/密码对生成密码哈希。这假设您使用默认用户名 pgbouncer（推荐）。命令请求密码和确认。使用此命令输出的值作为下一步中的 <pgbouncer_password_hash> 值： 

    sudo gitlab-ctl pg-password-md5 pgbouncer

  4. 为 PostgreSQL 复制用户名/密码对生成密码哈希。这假设您使用默认用户名 gitlab_replicator（推荐）。命令请求密码和确认。使用此命令输出的值作为下一步中的 <postgresql_replication_password_hash> 值： 

    sudo gitlab-ctl pg-password-md5 gitlab_replicator

  5. 为 Consul 数据库用户名/密码对生成密码哈希。这假设您使用默认用户名 gitlab-consul（推荐）。命令请求密码和确认。使用此命令输出的值作为下一步中的 <consul_password_hash> 值： 

    sudo gitlab-ctl pg-password-md5 gitlab-consul

  6. 在每个数据库节点上，编辑 /etc/gitlab/gitlab.rb，替换在 # START user configuration 部分中提到的值： 

    # 禁用除 Patroni、PgBouncer 和 Consul 外的所有组件
roles(['patroni_role', 'pgbouncer_role'])

# PostgreSQL 配置
postgresql['listen_address'] = '0.0.0.0'

# 将 `max_replication_slots` 设置为数据库节点数量的两倍。
# Patroni 在启动复制时每个节点使用一个额外的插槽。
patroni['postgresql']['max_replication_slots'] = 6

# 将 `max_wal_senders` 设置为集群中复制插槽数量加一个。
# 这用于防止复制用尽所有可用的数据库连接。
patroni['postgresql']['max_wal_senders'] = 7

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

# 配置 Consul 代理
consul['services'] = %w(postgresql)
## 启用 Prometheus 的服务发现
consul['monitoring_service_discovery'] =  true

# START 用户配置
# 请根据所需信息部分中的说明设置真实值
#
# 使用生成的 md5 值替换 PGBOUNCER_PASSWORD_HASH
postgresql['pgbouncer_user_password'] = '<pgbouncer_password_hash>'
# 使用生成的 md5 值替换 POSTGRESQL_REPLICATION_PASSWORD_HASH
postgresql['sql_replication_password'] = '<postgresql_replication_password_hash>'
# 使用生成的 md5 值替换 POSTGRESQL_PASSWORD_HASH
postgresql['sql_user_password'] = '<postgresql_password_hash>'

# 为 Patroni API 设置基本身份验证（在所有节点中使用相同的用户名/密码）。
patroni['username'] = '<patroni_api_username>'
patroni['password'] = '<patroni_api_password>'

# 使用网络地址替换 10.6.0.0/24
postgresql['trust_auth_cidr_addresses'] = %w(10.6.0.0/24 127.0.0.1/32)

# 用于数据库负载均衡的本地 PgBouncer 服务
pgbouncer['databases'] = {
   gitlabhq_production: {
      host: "127.0.0.1",
      user: "pgbouncer",
      password: '<pgbouncer_password_hash>'
   }
}

# 设置导出器将监听的网络地址以进行监控
node_exporter['listen_address'] = '0.0.0.0:9100'
postgres_exporter['listen_address'] = '0.0.0.0:9187'

## Consul 服务器节点的 IP
## 您也可以使用 FQDN，并将其与 IP 混合使用
consul['configuration'] = {
   retry_join: %w(10.6.0.11 10.6.0.12 10.6.0.13),
}
#
# END 用户配置

PostgreSQL，由 Patroni 管理其故障转移，默认使用 pg_rewind 来处理冲突。像大多数故障转移处理方法一样，这有可能导致数据丢失。有关更多信息，请参阅各种 Patroni 复制方法。

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

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

支持高级配置选项，如果需要可以添加。

PostgreSQL 后配置

SSH 登录到主站点上的任意 Patroni 节点：

  1. 检查领导者和集群的状态： 

    gitlab-ctl patroni members

    输出应类似于以下内容： 

    | Cluster       | Member                            |  Host     | Role   | State   | TL  | Lag in MB | Pending restart |
|---------------|-----------------------------------|-----------|--------|---------|-----|-----------|-----------------|
| postgresql-ha | <PostgreSQL 主服务器主机名>     | 10.6.0.21 | Leader | running | 175 |           | *               |
| postgresql-ha | <PostgreSQL 从服务器 1 主机名> | 10.6.0.22 |        | running | 175 | 0         | *               |
| postgresql-ha | <PostgreSQL 从服务器 2 主机名> | 10.6.0.23 |        | running | 175 | 0         | *               |

如果任何节点的“状态”列不显示“运行”，请在继续之前检查PostgreSQL 复制和故障转移故障排除部分。

配置 PgBouncer

现在 PostgreSQL 服务器都已设置好，让我们配置 PgBouncer，以跟踪和处理对主数据库的读写请求。

notePgBouncer 是单线程的，增加 CPU 核心不会显著提高性能。有关更多信息，请参阅扩展文档。

以下 IP 用作示例：

  • 10.6.0.31: PgBouncer 1
  • 10.6.0.32: PgBouncer 2
  • 10.6.0.33: PgBouncer 3

  1. 在每个 PgBouncer 节点上，编辑 /etc/gitlab/gitlab.rb，并替换 <consul_password_hash> 和 <pgbouncer_password_hash>，这些是您之前设置的密码哈希： 

    # 禁用所有组件，除了 Pgbouncer 和 Consul 代理
roles(['pgbouncer_role'])

# 配置 PgBouncer
pgbouncer['admin_users'] = %w(pgbouncer gitlab-consul)
pgbouncer['users'] = {
   'gitlab-consul': {
      password: '<consul_password_hash>'
   },
   'pgbouncer': {
      password: '<pgbouncer_password_hash>'
   }
}

# 配置 Consul 代理
consul['watchers'] = %w(postgresql)
consul['configuration'] = {
retry_join: %w(10.6.0.11 10.6.0.12 10.6.0.13)
}

# 启用 Prometheus 的服务发现
consul['monitoring_service_discovery'] = true

# 设置导出器将监听的网络地址
node_exporter['listen_address'] = '0.0.0.0:9100'
pgbouncer_exporter['listen_address'] = '0.0.0.0:9188'

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

  3. 重新配置极狐GitLab以使更改生效。

  4. 创建一个 .pgpass 文件，使 Consul 能够重新加载 PgBouncer。当要求时输入 PgBouncer 密码两次： 

    gitlab-ctl write-pgpass --host 127.0.0.1 --database pgbouncer --user pgbouncer --hostuser gitlab-consul

  5. 确保每个节点都在与当前主服务器通信： 

    gitlab-ctl pgb-console # 系统将提示您输入 PGBOUNCER_PASSWORD

    如果在输入密码后出现错误 psql: ERROR: Auth failed，请确保您之前使用正确的格式生成了 MD5 密码哈希。正确的格式是将密码和用户名连接在一起：PASSWORDUSERNAME。例如，Sup3rS3cr3tpgbouncer 是生成 pgbouncer 用户的 MD5 密码哈希所需的文本。

  6. 一旦控制台提示可用，运行以下查询： 

    show databases ; show clients ;

    输出应类似于以下内容： 

            name         |  host       | port |      database       | force_user | pool_size | reserve_pool | pool_mode | max_connections | current_connections
---------------------+-------------+------+---------------------+------------+-----------+--------------+-----------+-----------------+---------------------
 gitlabhq_production | MASTER_HOST | 5432 | gitlabhq_production |            |        20 |            0 |           |               0 |                   0
 pgbouncer           |             | 6432 | pgbouncer           | pgbouncer  |         2 |            0 | statement |               0 |                   0
(2 rows)

 type |   user    |      database       |  state  |   addr         | port  | local_addr | local_port |    connect_time     |    request_time     |    ptr    | link | remote_pid | tls
------+-----------+---------------------+---------+----------------+-------+------------+------------+---------------------+---------------------+-----------+------+------------+-----
 C    | pgbouncer | pgbouncer           | active  | 127.0.0.1      | 56846 | 127.0.0.1  |       6432 | 2017-08-21 18:09:59 | 2017-08-21 18:10:48 | 0x22b3880 |      |          0 |
(2 rows)

  7. 验证极狐GitLab 服务正在运行： 

    sudo gitlab-ctl status

    输出应类似于以下内容： 

    run: consul: (pid 31530) 77150s; run: log: (pid 31106) 77182s
run: logrotate: (pid 32613) 3357s; run: log: (pid 30107) 77500s
run: node-exporter: (pid 31550) 77149s; run: log: (pid 30138) 77493s
run: pgbouncer: (pid 32033) 75593s; run: log: (pid 31117) 77175s
run: pgbouncer-exporter: (pid 31558) 77148s; run: log: (pid 31498) 77156s

配置 Redis

使用 Redis 在可扩展环境中，可以使用 Primary x Replica 拓扑和 Redis Sentinel 服务来监控并自动启动故障转移程序。

note
Redis 集群必须部署在奇数数量的节点上，至少为 3 个节点。这是为了确保 Redis Sentinel 可以作为仲裁的一部分进行投票。当外部配置 Redis 时，例如云提供商服务，则不适用。
note
Redis 主要是单线程的，并不会从增加 CPU 内核中显著受益。有关更多信息，请参阅 扩展文档。

如果与 Sentinel 一起使用，Redis 需要身份验证。请参阅 Redis 安全 文档以获取更多信息。我们建议使用 Redis 密码和严格的防火墙规则组合来保护您的 Redis 服务。强烈建议您在将 Redis 与极狐GitLab 一起配置之前阅读 Redis Sentinel 文档，以全面了解拓扑和架构。

Redis 设置的要求如下：

  1. 所有 Redis 节点必须能够相互通信，并接受通过 Redis (6379) 和 Sentinel (26379) 端口的传入连接（除非您更改默认端口）。
  2. 托管极狐GitLab 应用程序的服务器必须能够访问 Redis 节点。
  3. 使用防火墙等选项保护节点不受外部网络（互联网）的访问。

在本节中，您将获得配置两个外部 Redis 集群以与极狐GitLab 一起使用的指导。以下 IP 用作示例：

  • 10.6.0.61：Redis Primary
  • 10.6.0.62：Redis Replica 1
  • 10.6.0.63：Redis Replica 2

提供您自己的 Redis 实例

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

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

配置 Redis 集群

这是安装和设置新 Redis 实例的部分。

主和副本 Redis 节点需要在 redis['password'] 中定义相同的密码。在故障转移期间，Sentinels 可以重新配置节点并将其状态从主节点更改为副本（反之亦然）。

配置主 Redis 节点

  1. SSH 到 Primary Redis 服务器。
  2. 下载和安装您选择的 Linux 软件包。请确保仅遵循页面上的安装步骤 1 和 2，并选择正确的 Linux 软件包，版本和类型（基础版或企业版）与您的当前安装相同。

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

    # 指定服务器角色为 'redis_master_role'，使用 Sentinel 和 Consul 代理
roles ['redis_sentinel_role', 'redis_master_role', 'consul_role']

# 设置 IP 绑定地址和 Redis Sentinel 服务的 Quorum 数量
sentinel['bind'] = '0.0.0.0'
sentinel['quorum'] = 2

# 指向其他机器可以访问的本地 IP 的 IP 地址。
# 您还可以设置绑定为 '0.0.0.0'，它将监听所有接口。
# 如果您确实需要绑定到外部可访问的 IP，请确保添加额外的防火墙规则以防止未经授权的访问。
redis['bind'] = '10.6.0.61'

# 定义一个端口，以便 Redis 可以监听 TCP 请求，使其他机器能够连接到它。
redis['port'] = 6379

## 主 Redis 服务器的 Sentinel 端口，取消注释以更改为非默认值。默认为 `6379`。
#redis['master_port'] = 6379

# 为 Redis 和副本设置密码认证（在所有节点中使用相同的密码）。
redis['password'] = 'REDIS_PRIMARY_PASSWORD'
redis['master_password'] = 'REDIS_PRIMARY_PASSWORD'

## 必须在每个 Redis 节点中相同
redis['master_name'] = 'gitlab-redis'

## 这个主 Redis 节点的 IP。
redis['master_ip'] = '10.6.0.61'

## 为 Prometheus 启用服务发现
consul['monitoring_service_discovery'] =  true

## Consul 服务器节点的 IP
## 您还可以使用 FQDN 并将其与 IP 混合使用
consul['configuration'] = {
   retry_join: %w(10.6.0.11 10.6.0.12 10.6.0.13),
}

# 设置导出器将监听的网络地址
node_exporter['listen_address'] = '0.0.0.0:9100'
redis_exporter['listen_address'] = '0.0.0.0:9121'

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

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

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

配置副本 Redis 节点

  1. SSH 到 replica Redis 服务器。
  2. 下载和安装您选择的 Linux 软件包。请确保仅遵循页面上的安装步骤 1 和 2，并选择正确的 Linux 软件包，版本和类型（基础版或企业版）与您的当前安装相同。

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

    # 指定服务器角色为 'redis_sentinel_role' 和 'redis_replica_role'
roles ['redis_sentinel_role', 'redis_replica_role', 'consul_role']

# 设置 IP 绑定地址和 Redis Sentinel 服务的 Quorum 数量
sentinel['bind'] = '0.0.0.0'
sentinel['quorum'] = 2

# 指向其他机器可以访问的本地 IP 的 IP 地址。
# 您还可以设置绑定为 '0.0.0.0'，它将监听所有接口。
# 如果您确实需要绑定到外部可访问的 IP，请确保添加额外的防火墙规则以防止未经授权的访问。
redis['bind'] = '10.6.0.62'

# 定义一个端口，以便 Redis 可以监听 TCP 请求，使其他机器能够连接到它。
redis['port'] = 6379

## 主 Redis 服务器的 Sentinel 端口，取消注释以更改为非默认值。默认为 `6379`。
#redis['master_port'] = 6379

# 您为主节点设置的 Redis 身份验证的相同密码。
redis['password'] = 'REDIS_PRIMARY_PASSWORD'
redis['master_password'] = 'REDIS_PRIMARY_PASSWORD'

## 必须在每个 Redis 节点中相同
redis['master_name'] = 'gitlab-redis'

# 主 Redis 节点的 IP。
redis['master_ip'] = '10.6.0.61'

## 为 Prometheus 启用服务发现
consul['monitoring_service_discovery'] =  true

## Consul 服务器节点的 IP
## 您还可以使用 FQDN 并将其与 IP 混合使用
consul['configuration'] = {
   retry_join: %w(10.6.0.11 10.6.0.12 10.6.0.13),
}

# 设置导出器将监听的网络地址
node_exporter['listen_address'] = '0.0.0.0:9100'
redis_exporter['listen_address'] = '0.0.0.0:9121'

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

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

  5. 重新配置极狐GitLab 以使更改生效。
  6. 对所有其他副本节点重复这些步骤，并确保正确设置 IP。

支持高级配置选项，如有需要可以添加。

配置 Gitaly 集群

Gitaly 集群 是极狐GitLab 提供并推荐的用于存储 Git 仓库的容错解决方案。在此配置中，每个 Git 仓库都存储在集群中的每个 Gitaly 节点上，其中一个被指定为主节点，如果主节点出现故障，则会自动进行故障转移。

caution
Gitaly 规格基于使用模式和良好健康状态下的仓库大小的高百分位数。
然而，如果您有 大型单体仓库（大于几个千兆字节）或 额外工作负载，这些可能会显著影响环境的性能，并可能需要进一步调整。
如果这适用于您，我们强烈建议参考链接的文档，并与您的 客户成功经理 或我们的 支持团队 联系以获得进一步指导。

Gitaly 集群提供了容错的好处，但带来了额外的设置和管理复杂性。在部署 Gitaly 集群之前，请查看现有的 技术限制和考虑事项。

有关以下方面的指导：

推荐的集群设置包括以下组件：

  • 3 个 Gitaly 节点：Git 仓库的复制存储。
  • 3 个 Praefect 节点：Gitaly 集群的路由器和事务管理器。
  • 1 个 Praefect PostgreSQL 节点：Praefect 的数据库服务器。需要第三方解决方案，以便对 Praefect 数据库连接进行高可用性。
  • 1 个负载均衡器：Praefect 需要负载均衡器。使用 内部负载均衡器。

本节详细介绍如何按顺序配置推荐的标准设置。有关更高级的设置，请参阅 独立的 Gitaly 集群文档。

配置 Praefect PostgreSQL

Praefect 是 Gitaly 集群的路由和事务管理器，需要自己的数据库服务器来存储 Gitaly 集群状态的数据。

如果您希望拥有高可用的设置，Praefect 需要一个第三方 PostgreSQL 数据库。

使用 Linux 软件包的非 HA PostgreSQL 独立 Praefect

以下 IP 用作示例：

  • 10.6.0.141：Praefect PostgreSQL

首先，确保在 Praefect PostgreSQL 节点上安装Linux 极狐GitLab 软件包。按照步骤，从步骤 1 安装必要的依赖项，并从步骤 2 添加极狐GitLab 软件包库。在第二步安装极狐GitLab 时，请勿提供 EXTERNAL_URL 值。

  1. SSH 到 Praefect PostgreSQL 节点。
  2. 创建一个强密码用于 Praefect PostgreSQL 用户。记下此密码作为 <praefect_postgresql_password>。

  3. 为 Praefect PostgreSQL 用户名/密码对生成密码哈希。假设您将使用默认用户名 praefect（推荐）。该命令将请求密码 <praefect_postgresql_password> 和确认。在下一步中使用此命令输出的值作为 <praefect_postgresql_password_hash> 的值： 

    sudo gitlab-ctl pg-password-md5 praefect

  4. 编辑 /etc/gitlab/gitlab.rb，替换 # START user configuration 部分中的值： 

    # 禁用除 PostgreSQL 和 Consul 外的所有组件
roles(['postgres_role', 'consul_role'])

# PostgreSQL 配置
postgresql['listen_address'] = '0.0.0.0'

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

# 配置 Consul 代理
## 为 Prometheus 启用服务发现
consul['monitoring_service_discovery'] =  true

# START user configuration
# 请根据要求信息部分设置实际值
#
# 用生成的 md5 值替换 PRAEFECT_POSTGRESQL_PASSWORD_HASH
postgresql['sql_user_password'] = "<praefect_postgresql_password_hash>"

# 用网络地址替换 XXX.XXX.XXX.XXX/YY
postgresql['trust_auth_cidr_addresses'] = %w(10.6.0.0/24 127.0.0.1/32)

# 设置导出器将监听的网络地址以进行监控
node_exporter['listen_address'] = '0.0.0.0:9100'
postgres_exporter['listen_address'] = '0.0.0.0:9187'

## Consul 服务器节点的 IP
## 您还可以使用 FQDN 并将其与 IP 混合使用
consul['configuration'] = {
   retry_join: %w(10.6.0.11 10.6.0.12 10.6.0.13),
}
#
# END user configuration

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

  6. 重新配置极狐GitLab 以使更改生效。
  7. 按照 后配置。

Praefect HA PostgreSQL 第三方解决方案

如所述，如果目标是实现完整的高可用性，建议使用第三方 PostgreSQL 解决方案来处理 Praefect 的数据库。

PostgreSQL 高可用性有许多第三方解决方案。所选解决方案必须具备以下功能才能与 Praefect 一起使用：

  • 一个静态 IP，用于所有连接，在故障转移时不会改变。
  • 必须支持 LISTEN SQL 功能。
note
通过第三方设置，可以将 Praefect 的数据库与主 极狐GitLab 数据库放在同一服务器上，以方便使用，除非您使用 Geo，在这种情况下需要单独的数据库实例来正确处理复制。在这种设置中，主数据库设置的规格不应需要更改，因为影响应该是最小的。

应使用信誉良好的提供商或解决方案。 Amazon RDS 已知可以正常工作。然而，从 14.4.0 开始，Amazon Aurora 与默认启用的负载均衡器不兼容。

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

数据库设置完成后，按照 后配置。

Praefect PostgreSQL 后配置

设置 Praefect PostgreSQL 服务器后，您需要配置 Praefect 使用的用户和数据库。

我们建议将用户命名为 praefect，数据库命名为 praefect_production，这些可以在 PostgreSQL 中作为标准配置。用户的密码与您之前配置的 <praefect_postgresql_password> 相同。

以下是使用 Linux 软件包 PostgreSQL 设置的工作方式：

  1. SSH 到 Praefect PostgreSQL 节点。

  2. 使用管理权限连接到 PostgreSQL 服务器。这里应该使用 gitlab-psql 用户，因为它在 Linux 软件包中默认添加。数据库 template1 被使用，因为它在所有 PostgreSQL 服务器上默认创建。 

    /opt/gitlab/embedded/bin/psql -U gitlab-psql -d template1 -h POSTGRESQL_SERVER_ADDRESS

  3. 创建新用户 praefect，替换 <praefect_postgresql_password>： 

    CREATE ROLE praefect WITH LOGIN CREATEDB PASSWORD '<praefect_postgresql_password>';

  4. 重新连接到 PostgreSQL 服务器，这次使用 praefect 用户： 

    /opt/gitlab/embedded/bin/psql -U praefect -d template1 -h POSTGRESQL_SERVER_ADDRESS

  5. 创建新数据库 praefect_production： 

    CREATE DATABASE praefect_production WITH ENCODING=UTF8;

配置 Praefect

Praefect 是 Gitaly 集群的路由和事务管理器，所有到 Gitaly 的连接都通过它。本节详细介绍如何配置它。

note
Praefect 必须部署在奇数数量的节点上，至少为 3 个节点。这是为了确保节点可以作为仲裁的一部分进行投票。

Praefect 需要多个密钥来保护集群内的通信：

  • <praefect_external_token>：用于托管在您的 Gitaly 集群上的仓库，并且只能由携带此令牌的 Gitaly 客户端访问。
  • <praefect_internal_token>：用于 Gitaly 集群内部的复制流量。这与 praefect_external_token 不同，因为 Gitaly 客户端不能直接访问 Praefect 集群的内部节点，这可能导致数据丢失。
  • <praefect_postgresql_password>：在前一节中定义的 Praefect PostgreSQL 密码也是此设置的一部分。

在 Praefect 中通过 virtual storage 配置 Gitaly 集群节点。每个存储包含组成集群的每个 Gitaly 节点的详细信息。每个存储还被赋予一个名称，并且此名称在配置的多个区域中使用。在本指南中，存储的名称将是 default。此外，本指南针对新安装，如果升级现有环境以使用 Gitaly 集群，您可能需要使用不同的名称。有关更多信息，请参阅 Praefect 文档。

以下 IP 用作示例：

  • 10.6.0.131：Praefect 1
  • 10.6.0.132：Praefect 2
  • 10.6.0.133：Praefect 3

要配置 Praefect 节点，请在每个节点上：

  1. SSH 到 Praefect 服务器。
  2. 下载和安装您选择的 Linux 软件包。请确保仅遵循页面上的安装步骤 1 和 2。

  3. 编辑 /etc/gitlab/gitlab.rb 文件以配置 Praefect：

    note
    您不能删除 virtual_storages 中的 default 条目，因为 极狐GitLab 需要它。
    # 避免在 Praefect 服务器上运行不必要的服务
gitaly['enable'] = false
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

# Praefect 配置
praefect['enable'] = true

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

# 配置 Consul 代理
consul['enable'] = true
## 为 Prometheus 启用服务发现
consul['monitoring_service_discovery'] = true

# START user configuration
# 请根据要求信息部分设置实际值
#

praefect['configuration'] = {
   # ...
   listen_addr: '0.0.0.0:2305',
   auth: {
      # ...
      #
      # Praefect External Token
      # 这是集群外的客户端（如 GitLab Shell）与 Praefect 集群通信所需的
      token: '<praefect_external_token>',
   },
   # Praefect 数据库设置
   database: {
      # ...
      host: '10.6.0.141',
      port: 5432,
      dbname: 'praefect_production',
      user: 'praefect',
      password: '<praefect_postgresql_password>',
   },
   # Praefect 虚拟存储配置
   # 存储哈希的名称必须与 GitLab 服务器上的 git_data_dirs 中的存储名称匹配（'praefect'），以及 Gitaly 节点上的 gitaly['configuration'][:storage] 中的存储名称（'gitaly-1'）
   virtual_storage: [
      {
         # ...
         name: 'default',
         node: [
            {
               storage: 'gitaly-1',
               address: 'tcp://10.6.0.91:8075',
               token: '<praefect_internal_token>'
            },
            {
               storage: 'gitaly-2',
               address: 'tcp://10.6.0.92:8075',
               token: '<praefect_internal_token>'
            },
            {
               storage: 'gitaly-3',
               address: 'tcp://10.6.0.93:8075',
               token: '<praefect_internal_token>'
            },
         ],
      },
   ],
   # 设置 Praefect 将监听的网络地址以进行监控
   prometheus_listen_addr: '0.0.0.0:9652',
}

# 设置节点导出器将监听的网络地址以进行监控
node_exporter['listen_address'] = '0.0.0.0:9100'

## Consul 服务器节点的 IP
## 您还可以使用 FQDN 并将其与 IP 混合使用
consul['configuration'] = {
   retry_join: %w(10.6.0.11 10.6.0.12 10.6.0.13),
}
#
# END user configuration

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

  5. Praefect 需要运行一些数据库迁移，类似于主极狐GitLab 应用程序。为此，您应该选择一个 Praefect 节点来运行迁移，也称为 Deploy Node。此节点必须在其他节点之前进行配置，如下所示：

    1. 在 /etc/gitlab/gitlab.rb 文件中，将 praefect['auto_migrate'] 设置值从 false 更改为 true

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

    sudo touch /etc/gitlab/skip-auto-reconfigure
    1. 重新配置极狐GitLab 以使更改生效并运行 Praefect 数据库迁移。
  6. 在所有其他 Praefect 节点上，重新配置极狐GitLab 以使更改生效。

配置 Gitaly

组成集群的 Gitaly 服务器节点有依赖于数据和负载的要求。

caution
Gitaly 规格基于使用模式和良好健康状态下的仓库大小的高百分位数。
然而，如果您有 大型单体仓库（大于几个千兆字节）或 额外工作负载，这些可能会显著影响环境的性能，并可能需要进一步调整。
如果这适用于您，我们强烈建议参考链接的文档，并与您的 客户成功经理 或我们的 支持团队 联系以获得进一步指导。

由于 Gitaly 具有显著的输入和输出要求，我们强烈建议所有 Gitaly 节点使用固态硬盘（SSD）。这些 SSD 的读取操作吞吐量应至少为 8,000 输入/输出操作每秒（IOPS），写入操作为 2,000 IOPS。如果您在云提供商上运行环境，请参考他们的文档了解如何正确配置 IOPS。

Gitaly 服务器不得暴露给公共互联网，因为 Gitaly 的网络流量默认未加密。强烈建议使用防火墙来限制对 Gitaly 服务器的访问。另一种选择是使用 TLS。

配置 Gitaly 时，您应该注意以下事项：

  • gitaly['configuration'][:storage] 应配置为反映特定 Gitaly 节点的存储路径
  • auth_token 应与 praefect_internal_token 相同

以下 IP 用作示例：

  • 10.6.0.91：Gitaly 1
  • 10.6.0.92：Gitaly 2
  • 10.6.0.93：Gitaly 3

在每个节点上：

  1. 下载和安装您选择的 Linux 软件包。请确保仅遵循页面上的安装步骤 1 和 2，并且不要提供 EXTERNAL_URL 值。

  2. 编辑 Gitaly 服务器节点的 /etc/gitlab/gitlab.rb 文件以配置存储路径，启用网络监听器，并配置令牌：

    # 避免在 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

# Gitaly
gitaly['enable'] = true

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

# 配置 Consul 代理
consul['enable'] = true
## 为 Prometheus 启用服务发现
consul['monitoring_service_discovery'] = true

# START user configuration
# 请根据要求信息部分设置实际值
#
## Consul 服务器节点的 IP
## 您还可以使用 FQDN 并将其与 IP 混合使用
consul['configuration'] = {
   retry_join: %w(10.6.0.11 10.6.0.12 10.6.0.13),
}

# 设置节点导出器将监听的网络地址以进行监控
node_exporter['listen_address'] = '0.0.0.0:9100'

gitaly['configuration'] = {
   # ...
   #
   # 使 Gitaly 接受所有网络接口上的连接。您必须使用防火墙来限制对该地址/端口的访问。
   # 如果您只想支持 TLS 连接，请注释掉以下行
   listen_addr: '0.0.0.0:8075',
   # 设置 Gitaly 将监听的网络地址以进行监控
   prometheus_listen_addr: '0.0.0.0:9236',
   # Gitaly Auth Token
   # 应与 praefect_internal_token 相同
   auth: {
      # ...
      token: '<praefect_internal_token>',
   },
   # Gitaly Pack-objects 缓存
   # 建议启用以提高性能，但会显著增加磁盘 I/O
   # 有关更多信息，请参阅 https://gitlab.cn/docs/ee/administration/gitaly/configure_gitaly.html#pack-objects-cache
   pack_objects_cache: {
      # ...
      enabled: true,
   },
}

#
# END user configuration
  3. 将以下内容附加到每个相应服务器的 /etc/gitlab/gitlab.rb：

    • 在 Gitaly 节点 1 上： 

      gitaly['configuration'] = {
   # ...
   storage: [
      {
         name: 'gitaly-1',
         path: '/var/opt/gitlab/git-data',
      },
   ],
}

    • 在 Gitaly 节点 2 上： 

      gitaly['configuration'] = {
   # ...
   storage: [
      {
         name: 'gitaly-2',
         path: '/var/opt/gitlab/git-data',
      },
   ],
}

    • 在 Gitaly 节点 3 上： 

      gitaly['configuration'] = {
   # ...
   storage: [
      {
         name: 'gitaly-3',
         path: '/var/opt/gitlab/git-data',
      },
   ],
}

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

  5. 保存文件，然后重新配置极狐GitLab。

Gitaly 集群 TLS 支持

Praefect 支持 TLS 加密。要与监听安全连接的 Praefect 实例通信，您必须：

  • 在极狐GitLab 配置中对应存储项的 gitaly_address 中使用 tls:// URL 方案。
  • 自行提供证书，因为这不会自动提供。每个 Praefect 服务器对应的证书必须安装在该 Praefect 服务器上。

此外，证书或其证书授权机构必须安装在所有 Gitaly 服务器和所有与之通信的 Praefect 客户端上，按照极狐GitLab 自定义证书配置中描述的步骤进行安装（并在下面重复）。

请注意以下几点：

  • 证书必须指定您用来访问 Praefect 服务器的地址。您必须将主机名或 IP 地址作为证书的主题备用名称添加到证书中。
  • 您可以同时配置 Praefect 服务器的未加密监听地址 listen_addr 和加密监听地址 tls_listen_addr。这允许您在必要时逐步从未加密过渡到加密流量。要禁用未加密的监听器，请设置 praefect['configuration'][:listen_addr] = nil。
  • 内部负载均衡器也将访问证书，并需要配置以允许 TLS 透传。请参阅负载均衡器文档了解如何配置。

要使用 TLS 配置 Praefect：

  1. 为 Praefect 服务器创建证书。

  2. 在 Praefect 服务器上，创建 /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

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

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

  4. 保存文件并重新配置。

  5. 在 Praefect 客户端（包括每个 Gitaly 服务器）上，复制证书或其证书授权机构到 /etc/gitlab/trusted-certs： 

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

  6. 在 Praefect 客户端（不包括 Gitaly 服务器）上，编辑 /etc/gitlab/gitlab.rb 中的 git_data_dirs 如下： 

    git_data_dirs({
  "default" => {
    "gitaly_address" => 'tls://LOAD_BALANCER_SERVER_ADDRESS:3305',
    "gitaly_token" => 'PRAEFECT_EXTERNAL_TOKEN'
  }
})

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

配置 Sidekiq

Sidekiq 需要连接到 Redis、PostgreSQL 和 Gitaly 实例。根据推荐，它还需要连接到 对象存储。

NOTE： 由于推荐使用对象存储而不是 NFS 来存储数据对象，以下示例包括对象存储配置。

NOTE： 如果发现环境的 Sidekiq 作业处理速度慢且队列较长，可以相应地进行扩展。有关更多信息，请参阅扩展文档。

NOTE： 配置极狐GitLab 的额外功能（例如容器注册表、SAML 或 LDAP）时，除了 Rails 配置之外，还需要更新 Sidekiq 配置。有关更多信息，请参阅外部 Sidekiq 文档。

以下 IP 将作为示例使用：

  • 10.6.0.71：Sidekiq 1
  • 10.6.0.72：Sidekiq 2

要配置 Sidekiq 节点，请在每个节点上执行以下操作：

  1. SSH 登录到 Sidekiq 服务器。

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

    telnet <GitLab host> 5432 # PostgreSQL
telnet <GitLab host> 8075 # Gitaly
telnet <GitLab host> 6379 # Redis
  3. 下载并安装您选择的 Linux 软件包。确保仅遵循页面上的安装步骤 1 和 2。

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

    # https://gitlab.cn/docs/omnibus/roles/#sidekiq-roles
roles(["sidekiq_role"])

# 外部 URL
## 这应该与外部负载均衡器的 URL 匹配
external_url 'https://gitlab.example.com'

# Redis
redis['master_name'] = 'gitlab-redis'

## 您为主节点设置的 Redis 身份验证的相同密码。
redis['master_password'] = '<redis_primary_password>'

## 带有 `host` 和 `port` 的哨兵列表
gitlab_rails['redis_sentinels'] = [
   {'host' => '10.6.0.11', 'port' => 26379},
   {'host' => '10.6.0.12', 'port' => 26379},
   {'host' => '10.6.0.13', 'port' => 26379},
]

# Gitaly 集群
## git_data_dirs 为 Praefect 虚拟存储配置
## 地址为 Praefect 的内部负载均衡器
## 令牌为 praefect_external_token
git_data_dirs({
  "default" => {
    "gitaly_address" => "tcp://10.6.0.40:2305", # 内部负载均衡器 IP
    "gitaly_token" => '<praefect_external_token>'
  }
})

# PostgreSQL
gitlab_rails['db_host'] = '10.6.0.40' # 内部负载均衡器 IP
gitlab_rails['db_port'] = 6432
gitlab_rails['db_password'] = '<postgresql_user_password>'
gitlab_rails['db_load_balancing'] = { 'hosts' => ['10.6.0.21', '10.6.0.22', '10.6.0.23'] } # PostgreSQL IPs

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

# Sidekiq
sidekiq['listen_address'] = "0.0.0.0"

## 将 Sidekiq 队列进程的数量设置为与可用 CPU 数量相同
sidekiq['queue_groups'] = ['*'] * 4

# 监控
consul['enable'] = true
consul['monitoring_service_discovery'] =  true

consul['configuration'] = {
   retry_join: %w(10.6.0.11 10.6.0.12 10.6.0.13)
}

## 设置导出器将监听的网络地址
node_exporter['listen_address'] = '0.0.0.0:9100'

## 将监控节点的 IP 地址添加到监控白名单
gitlab_rails['monitoring_whitelist'] = ['10.6.0.81/32', '127.0.0.0/8']
gitlab_rails['prometheus_address'] = '10.6.0.81:9090'

# 对象存储
## 这是在 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 后配置部分中详细说明的那样。

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

  8. 验证极狐GitLab 服务是否正在运行： 

    sudo gitlab-ctl status

    输出应类似于以下内容： 

    run: consul: (pid 30114) 77353s; run: log: (pid 29756) 77367s
run: logrotate: (pid 9898) 3561s; run: log: (pid 29653) 77380s
run: node-exporter: (pid 30134) 77353s; run: log: (pid 29706) 77372s
run: sidekiq: (pid 30142) 77351s; run: log: (pid 29638) 77386s

配置极狐GitLab Rails

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

Rails 需要连接到 Redis、PostgreSQL 和 Gitaly 实例。根据推荐，它还需要连接到 对象存储。

NOTE： 由于推荐使用对象存储而不是 NFS 来存储数据对象，以下示例包括对象存储配置。

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

  1. 下载并安装您选择的 Linux 软件包。确保仅遵循页面上的安装步骤 1 和 2。

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

    external_url 'https://gitlab.example.com'

# git_data_dirs 为 Praefect 虚拟存储配置
# 地址为 Praefect 的内部负载均衡器
# 令牌为 praefect_external_token
git_data_dirs({
  "default" => {
    "gitaly_address" => "tcp://10.6.0.40:2305", # 内部负载均衡器 IP
    "gitaly_token" => '<praefect_external_token>'
  }
})

## 禁用极狐GitLab 应用服务器上不会出现的组件
roles(['application_role'])
gitaly['enable'] = false
sidekiq['enable'] = false

## PostgreSQL 连接详细信息
# 在应用节点上禁用 PostgreSQL
postgresql['enable'] = false
gitlab_rails['db_host'] = '10.6.0.20' # 内部负载均衡器 IP
gitlab_rails['db_port'] = 6432
gitlab_rails['db_password'] = '<postgresql_user_password>'
gitlab_rails['db_load_balancing'] = { 'hosts' => ['10.6.0.21', '10.6.0.22', '10.6.0.23'] } # PostgreSQL IPs

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

## Redis 连接详细信息
## 必须在每个哨兵节点中保持一致
redis['master_name'] = 'gitlab-redis'

## 您为 Redis 主节点设置的 Redis 身份验证的相同密码。
redis['master_password'] = '<redis_primary_password>'

## 带有 `host` 和 `port` 的哨兵列表
gitlab_rails['redis_sentinels'] = [
  {'host' => '10.6.0.11', 'port' => 26379},
  {'host' => '10.6.0.12', 'port' => 26379},
  {'host' => '10.6.0.13', 'port' => 26379}
]

## 为 Prometheus 启用服务发现
consul['enable'] = true
consul['monitoring_service_discovery'] =  true

# 设置监控使用的导出器将监听的网络地址
node_exporter['listen_address'] = '0.0.0.0:9100'
gitlab_workhorse['prometheus_listen_addr'] = '0.0.0.0:9229'
sidekiq['listen_address'] = "0.0.0.0"
puma['listen'] = '0.0.0.0'

## Consul 服务器节点的 IP
## 您还可以使用 FQDN，并将它们与 IP 混合使用
consul['configuration'] = {
   retry_join: %w(10.6.0.11 10.6.0.12 10.6.0.13),
}

# 将监控节点的 IP 地址添加到监控白名单，并允许其抓取 NGINX 指标
gitlab_rails['monitoring_whitelist'] = ['10.6.0.81/32', '127.0.0.0/8']
nginx['status']['options']['allow'] = ['10.6.0.81/32', '127.0.0.0/8']
gitlab_rails['prometheus_address'] = '10.6.0.81:9090'

## 如果您已设置 NFS，请取消注释并编辑以下选项
##
## 防止极狐GitLab 在 NFS 数据挂载不可用时启动
##
#high_availability['mountpoint'] = '/var/opt/gitlab/git-data'
##
## 确保 UID 和 GID 在服务器之间匹配，以便通过 NFS 进行权限管理
##
#user['uid'] = 9000
#user['gid'] = 9000
#web_server['uid'] = 9001
#web_server['gid'] = 9001
#registry['uid'] = 9002
#registry['gid'] = 9002

# 对象存储
# 这是在 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>'
}

  3. 如果您正在使用 Gitaly TLS 支持，请确保 git_data_dirs 条目配置为 tls 而不是 tcp： 

    git_data_dirs({
  "default" => {
    "gitaly_address" => "tls://10.6.0.40:2305", # 内部负载均衡器 IP
    "gitaly_token" => '<praefect_external_token>'
  }
})

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

      sudo cp cert.pem /etc/gitlab/trusted-certs/
  4. 从您配置的第一个 Linux 软件包节点复制 /etc/gitlab/gitlab-secrets.json 文件，并添加或替换此服务器上的同名文件。如果这是您配置的第一个 Linux 软件包节点，则可以跳过此步骤。
  5. 从您配置的第一个 Linux 软件包节点复制 SSH 主机密钥（所有名称格式为 /etc/ssh/ssh_host_*_key*），并添加或替换此服务器上的同名文件。这可确保不会为您的用户抛出主机不匹配错误，因为他们将加载均衡的 Rails 节点。如果这是您配置的第一个 Linux 软件包节点，则可以跳过此步骤。

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

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

    只有一个指定的节点应处理迁移，如极狐GitLab Rails 后配置部分中详细说明的那样。

  7. 重新配置极狐GitLab以使更改生效。
  8. 启用增量日志记录。
  9. 运行 sudo gitlab-rake gitlab:gitaly:check 以确认节点可以连接到 Gitaly。

  10. 追踪日志以查看请求： 

    sudo gitlab-ctl tail gitaly

  11. 验证极狐GitLab 服务是否正在运行： 

    sudo gitlab-ctl status

    输出应类似于以下内容： 

    run: consul: (pid 4890) 8647s; run: log: (pid 29962) 79128s
run: gitlab-exporter: (pid 4902) 8647s; run: log: (pid 29913) 79134s
run: gitlab-workhorse: (pid 4904) 8646s; run: log: (pid 29713) 79155s
run: logrotate: (pid 12425) 1446s; run: log: (pid 29798) 79146s
run: nginx: (pid 4925) 8646s; run: log: (pid 29726) 79152s
run: node-exporter: (pid 4931) 8645s; run: log: (pid 29855) 79140s
run: puma: (pid 4936) 8645s; run: log: (pid 29656) 79161s

当您在 external_url 中指定 https 时，如上例所示，极狐GitLab 期望 SSL 证书位于 /etc/gitlab/ssl/。如果证书不存在，NGINX 将无法启动。有关更多信息，请参阅HTTPS 文档。

极狐GitLab Rails 后配置

  1. 确保所有迁移已运行： 

    gitlab-rake gitlab:db:configure

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

  2. 配置数据库中授权 SSH 密钥的快速查找。

配置 Prometheus

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

  1. SSH 登录到监控节点。
  2. 下载并安装您选择的 Linux 软件包。确保仅遵循页面上的安装步骤 1 和 2。

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

    roles(['monitoring_role', 'consul_role'])

external_url 'http://gitlab.example.com'

# Prometheus
prometheus['listen_address'] = '0.0.0.0:9090'
prometheus['monitor_kubernetes'] = false

# 为 Prometheus 启用服务发现
consul['monitoring_service_discovery'] =  true
consul['configuration'] = {
   retry_join: %w(10.6.0.11 10.6.0.12 10.6.0.13)
}

# 配置 Prometheus 以抓取未覆盖的服务
prometheus['scrape_configs'] = [
   {
      'job_name': 'pgbouncer',
      'static_configs' => [
         'targets' => [
         "10.6.0.31:9188",
         "10.6.0.32:9188",
         "10.6.0.33:9188",
         ],
      ],
   },
   {
      'job_name': 'praefect',
      'static_configs' => [
         'targets' => [
         "10.6.0.131:9652",
         "10.6.0.132:9652",
         "10.6.0.133:9652",
         ],
      ],
   },
]

nginx['enable'] = false
  4. 保存文件并重新配置极狐GitLab。

  5. 验证极狐GitLab 服务是否正在运行： 

    sudo gitlab-ctl status

    输出应类似于以下内容： 

    run: consul: (pid 31637) 17337s; run: log: (pid 29748) 78432s
run: logrotate: (pid 31809) 2936s; run: log: (pid 29581) 78462s
run: nginx: (pid 31665) 17335s; run: log: (pid 29556) 78468s
run: prometheus: (pid 31672) 17335s; run: log: (pid 29633) 78456s

配置对象存储

极狐GitLab 支持使用对象存储服务来存储多种数据类型。对于数据对象，推荐使用对象存储而不是NFS，一般来说，在较大的设置中对象存储通常更高效、可靠和可扩展。有关更多信息，请参阅推荐的云提供商和服务。

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

以下示例中使用了统一形式。

对于极狐GitLab，推荐为每种数据类型使用单独的桶。这确保极狐GitLab 存储的各种数据类型之间不会发生冲突。未来计划支持使用单一桶。

启用增量日志记录

极狐GitLab Runner 以块的形式返回作业日志，即使在使用统一对象存储时，Linux 软件包也会暂时将其缓存到 /var/opt/gitlab/gitlab-ci/builds 目录。使用默认配置时，此目录需要通过 NFS 在任何极狐GitLab Rails 和 Sidekiq 节点上共享。

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

配置高级搜索

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

Elasticsearch 集群设计和要求取决于您的具体数据。有关如何在实例旁设置 Elasticsearch 集群的推荐最佳实践，请阅读如何选择最佳集群配置。

支持较低用户数量的修改（HA）

60 RPS 或 3,000 用户的极狐GitLab 参考架构是我们推荐的最小实现高可用性（HA）的架构。然而，对于需要服务于较少用户或较低 RPS 但保持 HA 的环境，您可以对该架构进行几项支持的修改，以减少复杂性和成本。

需要注意的是，要实现极狐GitLab 的 HA，最终需要 60 RPS 或 3,000 用户架构的组成。每个组件都有不同的考虑和规则，架构满足所有这些要求。该架构的较小版本在基础上是相同的，但随着性能要求的降低，支持以下修改：

NOTE： 如果未在下文中说明，则不支持其他修改来降低使用数量。

  • 降低节点规格：根据您的用户数量，您可以根据需要降低所有建议的节点规格。然而，建议不要低于一般要求。
  • 合并选择节点：支持将以下特定组件合并到相同节点上以减少复杂性，但以牺牲一些性能为代价：
    • 极狐GitLab Rails 和 Sidekiq：可以移除 Sidekiq 节点，并在极狐GitLab Rails 节点上启用该组件。
    • PostgreSQL 和 PgBouncer：可以移除 PgBouncer 节点，并在 PostgreSQL 节点上启用它们，内部负载均衡器指向它们。然而，为了启用数据库负载均衡，仍然需要单独的 PgBouncer 数组。
  • 减少节点数量：某些节点类型不需要共识，可以运行较少数量的节点（但要超过一个以实现冗余）：
    • 极狐GitLab Rails 和 Sidekiq：无状态服务没有最低节点数量。两个节点足以实现冗余。
    • PostgreSQL 和 PgBouncer：严格来说不需要法定人数。两个 PostgreSQL 节点和两个 PgBouncer 节点足以实现冗余。
    • Consul、Redis 哨兵和 Praefect：需要奇数个节点，至少三个节点，以实现投票法定人数。
  • 在信誉良好的云 PaaS 解决方案中运行选择组件：支持在信誉良好的云提供商 PaaS 解决方案上运行以下特定组件。通过这样做，还可以移除额外的依赖组件：
    • PostgreSQL：可以在信誉良好的云 PaaS 解决方案（如 Google Cloud SQL 或 Amazon RDS）上运行。在此设置中，不再需要 PgBouncer 和 Consul 节点：
    • Redis：可以在信誉良好的云 PaaS 解决方案（如 Google Memorystore 和 AWS ElastiCache）上运行。在此设置中，不再需要 Redis 哨兵。

使用 Helm Charts 的云原生混合参考架构（替代）

另一种方法是在 Kubernetes 中运行特定的极狐GitLab 组件。支持以下服务：

  • 极狐GitLab Rails
  • Sidekiq
  • NGINX
  • 工具箱
  • 迁移
  • Prometheus

混合安装利用了云原生和传统计算部署的优势。这样，无状态 组件可以从云原生工作负载管理优势中获益，而 有状态 组件则部署在具有 Linux 软件包安装的计算虚拟机中，以获得更高的持久性。

请参阅 Helm Charts 高级配置文档，了解设置说明，包括关于在 Kubernetes 和后端组件之间同步极狐GitLab 密钥的指导。

NOTE： 这是一个高级设置。在 Kubernetes 中运行服务众所周知是复杂的。仅在您拥有丰富的 Kubernetes 工作知识和经验时推荐此设置。本节的其余部分假设您具备这些知识和经验。

WARNING： 不支持在 Kubernetes 中运行 Gitaly 集群。

集群拓扑

以下表格和图表详细介绍了使用与上述典型环境相同格式的混合环境。

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

组件节点组 目标节点池总量 GCP 示例 AWS 示例
Webservice 16 vCPU
20 GB 内存（请求）
28 GB 内存（限制） 		2 x n1-standard-16 2 x c5.4xlarge
Sidekiq 7.2 vCPU
16 GB 内存（请求）
32 GB 内存（限制） 		3 x n1-standard-4 3 x m5.xlarge
支持服务 4 vCPU
15 GB 内存 		2 x n1-standard-2 2 x m5.large
  • 提供了如何达到目标节点池总量的 GCP 和 AWS 示例以供参考。这些大小用于性能测试，但不要求遵循示例。可以根据需要使用不同的节点池设计，只要达到目标并且所有 pod 都可以部署即可。
  • Webservice 和 Sidekiq 目标节点池总量仅针对极狐GitLab 组件。选定的 Kubernetes 提供商的系统进程还需要额外的资源。给出的示例考虑到了这一点。
  • 支持节点池总量一般用于容纳多个支持极狐GitLab 部署的资源以及根据您的需求您可能希望进行的任何额外部署。与其他节点池类似，选定的 Kubernetes 提供商的系统进程也需要资源。给出的示例考虑到了这一点。
  • 在生产部署中，不需要将 pod 分配到特定节点。然而，建议在每个池中有多个节点分布在不同的可用区，以符合弹性云架构实践。
  • 为了提高效率，建议启用自动扩展，例如集群自动扩展器，但通常建议将 Webservice 和 Sidekiq pod 的目标设置为 75% 的底线，以确保持续性能。

接下来是运行在静态计算虚拟机上的后端组件，使用 Linux 软件包（或适用的外部 PaaS 服务）：

服务 节点数量 配置 GCP AWS
Consul1 3 2 vCPU, 1.8 GB 内存 n1-highcpu-2 c5.large
PostgreSQL1 3 2 vCPU, 7.5 GB 内存 n1-standard-2 m5.large
PgBouncer1 3 2 vCPU, 1.8 GB 内存 n1-highcpu-2 c5.large
内部负载均衡器3 1 4 vCPU, 3.6 GB 内存 n1-highcpu-4 c5n.xlarge
Redis/Sentinel2 3 2 vCPU, 7.5 GB 内存 n1-standard-2 m5.large
Gitaly5 3 4 vCPU, 15 GB 内存6 n1-standard-4 m5.xlarge
Praefect5 3 2 vCPU, 1.8 GB 内存 n1-highcpu-2 c5.large
Praefect PostgreSQL1 1+ 2 vCPU, 1.8 GB 内存 n1-highcpu-2 c5.large
对象存储4 - - - -

脚注：

  1. 可以选择在信誉良好的第三方外部 PaaS PostgreSQL 解决方案上运行。有关更多信息，请参阅提供您自己的 PostgreSQL 实例。
  2. 可以选择在信誉良好的第三方外部 PaaS Redis 解决方案上运行。有关更多信息，请参阅提供您自己的 Redis 实例。
  3. 建议使用信誉良好的第三方负载均衡器或服务（LB PaaS），提供 HA 能力。大小取决于选定的负载均衡器和其他因素，如网络带宽。有关更多信息，请参阅负载均衡器。
  4. 应在信誉良好的云提供商或私有化部署解决方案上运行。有关更多信息，请参阅配置对象存储。
  5. Gitaly 集群提供容错优势，但伴随着额外的设置和管理复杂性。在部署 Gitaly 集群之前，请查看现有的技术限制和注意事项。如果您想要分片 Gitaly，请使用上面列出的 Gitaly 规格。
  6. Gitaly 规格基于使用模式和存储库大小的高百分位数处于良好状态。然而，如果您有大型单体存储库（大于几个千兆字节）或额外工作负载，这些可能会显著影响 Git 和 Gitaly 性能，并可能需要进一步调整。

NOTE： 对于涉及配置实例的所有 PaaS 解决方案，建议在三个不同的可用区中实现至少三个节点，以符合弹性云架构实践。

Kubernetes 组件目标

以下部分详细介绍了部署在 Kubernetes 中的极狐GitLab 组件使用的目标。

Webservice

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

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

对于 1000 RPS 或 50,000 名用户，我们建议总 Puma 工作进程数约为 308，因此建议至少运行 77 个 Webservice pods。

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

NGINX

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

这不是严格的要求。只要 NGINX 控制器 pods 有足够的资源来处理网络流量，它们可以根据需要进行部署。

Sidekiq

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

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

与上述标准部署类似，此处使用了 14 个 Sidekiq 工作进程的初始目标。根据您的具体工作流程，可能需要更多的工作进程。

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

支持

支持节点池旨在容纳所有不需要在 Webservice 和 Sidekiq 池中的支持部署。

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

如果您希望进行任何额外的部署，例如容器注册表、Pages 或监控，建议尽可能在此池中部署，而不是在 Webservice 或 Sidekiq 池中，因为支持池专门设计用于容纳多个附加部署。但是，如果您的部署不适合给定的池，您可以相应地增加节点池。反之，如果在您的使用场景中池资源过多，您可以相应地减少。

示例配置文件

针对上述 1000 RPS 或 50,000 参考架构配置的极狐GitLab Helm Charts 示例 可以在 Charts 项目中找到。

下一步

按照本指南，您现在应该有一个新的极狐GitLab 环境，并相应地配置了核心功能。

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

note根据您的环境和需求，可能需要额外的硬件要求或调整，以便按需设置其他功能。请参考各个页面获取更多信息。