参考架构：高达 1000 RPS 或 50,000 用户

本文描述了极狐GitLab 参考架构，旨在达到每秒 1000 个请求（RPS）的峰值负载，这是基于真实数据的手动和自动用户的典型峰值负载，高达 50,000 名用户。

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

note在部署此架构之前，建议先阅读主要文档，特别是在开始之前和决定使用哪个架构部分。
服务 节点 配置 GCP AWS Azure
外部负载均衡器3 1 16 vCPU，14.4 GB 内存 n1-highcpu-16 c5.4xlarge F16s v2
Consul1 3 2 vCPU，1.8 GB 内存 n1-highcpu-2 c5.large F2s v2
PostgreSQL1 3 32 vCPU，120 GB 内存 n1-standard-32 m5.8xlarge D32s v3
PgBouncer1 3 2 vCPU，1.8 GB 内存 n1-highcpu-2 c5.large F2s v2
内部负载均衡器3 1 16 vCPU，14.4 GB 内存 n1-highcpu-16 c5.4xlarge F16s v2
Redis/Sentinel - 缓存2 3 4 vCPU，15 GB 内存 n1-standard-4 m5.xlarge D4s v3
Redis/Sentinel - 持久化2 3 4 vCPU，15 GB 内存 n1-standard-4 m5.xlarge D4s v3
Gitaly5 3 64 vCPU，240 GB 内存6 n1-standard-64 m5.16xlarge D64s v3
Praefect5 3 4 vCPU，3.6 GB 内存 n1-highcpu-4 c5.xlarge F4s v2
Praefect PostgreSQL1 1+ 2 vCPU，1.8 GB 内存 n1-highcpu-2 c5.large F2s v2
Sidekiq7 4 4 vCPU，15 GB 内存 n1-standard-4 m5.xlarge D4s v3
极狐GitLab Rails7 12 32 vCPU，28.8 GB 内存 n1-highcpu-32 c5.9xlarge F32s v2
监控节点 1 4 vCPU，3.6 GB 内存 n1-highcpu-4 c5.xlarge F4s v2
对象存储4 - - - - -

脚注：

  1. 可以选择运行在信誉良好的第三方外部 PaaS PostgreSQL 解决方案上。有关更多信息，请参见提供您自己的 PostgreSQL 实例。
  2. 可以选择运行在信誉良好的第三方外部 PaaS Redis 解决方案上。有关更多信息，请参见提供您自己的 Redis 实例。
    • Redis 主要是单线程的，并不显著受益于 CPU 内核的增加。对于这种规模的架构，强烈建议拥有单独的缓存和持久化实例，以达到最佳性能。
  3. 可以选择运行在信誉良好的第三方负载均衡服务（LB PaaS）上。有关更多信息，请参见推荐的云提供商和服务。
  4. 应该运行在信誉良好的云提供商或私有化部署解决方案上。有关更多信息，请参见配置对象存储。
  5. Gitaly 集群提供容错的好处，但带来了额外的设置和管理复杂性。在部署 Gitaly 集群之前，请查看现有的技术限制和注意事项。如果你想要分片的 Gitaly，请使用上面列出的 Gitaly 的相同规格。
  6. Gitaly 规格基于良好状态下的使用模式和存储库大小的高百分位数。然而，如果你有大型单体库（大于几个 GB）或额外的工作负载，这些可能会显著影响 Git 和 Gitaly 性能，并可能需要进一步调整。
  7. 可以放置在自动伸缩组（ASGs）中，因为组件不存储任何有状态数据。然而，通常更推荐云原生混合设置，因为某些组件如迁移和邮件室只能在一个节点上运行，这在 Kubernetes 中处理得更好。
note对于所有涉及配置实例的 PaaS 解决方案，建议至少在三个不同的可用区中实施三个节点，以符合弹性云架构实践。

需求

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

测试方法

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

  • API：1000 RPS
  • Web：100 RPS
  • Git（Pull）：100 RPS
  • Git（Push）：20 RPS

上述目标是根据真实客户数据选择的，这些数据对应于包括 CI 和其他工作负载在内的用户总数的环境负载。

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

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

用于测试的负载均衡器是用于 Linux 软件包环境的 HAProxy 或等效的云提供商服务，使用 NGINX Ingress 进行云原生混合。这些选择不代表特定要求或推荐，因为预计大多数信誉良好的负载均衡器可以正常工作。

设置组件

要设置极狐GitLab 及其组件以容纳高达 1000 RPS 或 50,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 通过 HTTP/SSH）。
  10. 配置 Prometheus以监控你的极狐GitLab 环境。
  11. 配置对象存储用于共享数据对象。
  12. 配置高级搜索（可选）以更快、更高级的代码搜索跨越整个极狐GitLab 实例。

服务器在同一个 10.6.0.0/24 私有网络范围内启动，可以自由连接到这些地址。

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

  • 10.6.0.10：外部负载均衡器
  • 10.6.0.11：Consul 1
  • 10.6.0.12：Consul 2
  • 10.6.0.13：Consul 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.40：内部负载均衡器
  • 10.6.0.51：Redis - 缓存主节点
  • 10.6.0.52：Redis - 缓存副本 1
  • 10.6.0.53：Redis - 缓存副本 2
  • 10.6.0.61：Redis - 持久化主节点
  • 10.6.0.62：Redis - 持久化副本 1
  • 10.6.0.63：Redis - 持久化副本 2
  • 10.6.0.91：Gitaly 1
  • 10.6.0.92：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.101：Sidekiq 1
  • 10.6.0.102：Sidekiq 2
  • 10.6.0.103：Sidekiq 3
  • 10.6.0.104：Sidekiq 4
  • 10.6.0.111：极狐GitLab 应用 1
  • 10.6.0.112：极狐GitLab 应用 2
  • 10.6.0.113：极狐GitLab 应用 3
  • 10.6.0.114：极狐GitLab 应用 4
  • 10.6.0.115：极狐GitLab 应用 5
  • 10.6.0.116：极狐GitLab 应用 6
  • 10.6.0.117：极狐GitLab 应用 7
  • 10.6.0.118：极狐GitLab 应用 8
  • 10.6.0.119：极狐GitLab 应用 9
  • 10.6.0.120：极狐GitLab 应用 10
  • 10.6.0.121：极狐GitLab 应用 11
  • 10.6.0.122：极狐GitLab 应用 12
  • 10.6.0.151：Prometheus

配置外部负载均衡器

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

关于使用哪个负载均衡器或其确切配置的细节超出了极狐GitLab 文档的范围，但请参考负载均衡器以获取有关一般要求的更多信息。此部分将重点介绍如何配置所选负载均衡器的细节。

就绪检查

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

端口

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

LB 端口 后端端口 协议
80 80 HTTP (1)
443 443 TCP 或 HTTPS (1) (2)
22 22 TCP
  • (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 文档。

LB 端口 后端端口 协议
80 变化 (1) HTTP
443 变化 (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 主机名将需要与上述其他极狐GitLab HTTP 配置相比的新虚拟 IP 地址。

为替代 SSH 主机名如 altssh.gitlab.example.com 配置 DNS。

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

SSL

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

应用节点终止 SSL

配置你的负载均衡器以将端口 443 上的连接作为 TCP 传递，而不是 HTTP(S) 协议。这将把连接传递给应用节点的 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

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

提供您自己的 PostgreSQL 实例

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

应该使用一个有信誉的提供商或解决方案。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 应用 中介绍了此步骤。
  5. 实现 HA 所需的节点数量可能与服务相比 Linux 软件包不同，并且不需要相应匹配。
  6. 然而，如果希望通过读副本进行数据库负载均衡，以进一步提高性能，建议遵循参考架构的节点数量。

使用 Linux 软件包的独立 PostgreSQL

推荐的 PostgreSQL 集群配置，具有复制和故障转移功能，需要：

  • 至少三个 PostgreSQL 节点。
  • 至少三个 Consul 服务器节点。
  • 至少三个 PgBouncer 节点，负责跟踪和处理主数据库的读写。

  • 启用 数据库负载均衡。

    在每个 PostgreSQL 节点上配置本地 PgBouncer 服务。这与跟踪主数据库的主要 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 部分中记下的值： 

    # Disable all components except Patroni, PgBouncer and Consul
roles(['patroni_role', 'pgbouncer_role'])

# PostgreSQL configuration
postgresql['listen_address'] = '0.0.0.0'

# Sets `max_replication_slots` to double the number of database nodes.
# Patroni uses one extra slot per node when initiating the replication.
patroni['postgresql']['max_replication_slots'] = 6

# Set `max_wal_senders` to one more than the number of replication slots in the cluster.
# This is used to prevent replication from using up all of the
# available database connections.
patroni['postgresql']['max_wal_senders'] = 7

# Prevent database migrations from running on upgrade automatically
gitlab_rails['auto_migrate'] = false

# Configure the Consul agent
consul['enable'] = true
consul['services'] = %w(postgresql)
## Enable service discovery for Prometheus
consul['monitoring_service_discovery'] =  true

# START user configuration
# Please set the real values as explained in Required Information section
#
# Replace PGBOUNCER_PASSWORD_HASH with a generated md5 value
postgresql['pgbouncer_user_password'] = '<pgbouncer_password_hash>'
# Replace POSTGRESQL_REPLICATION_PASSWORD_HASH with a generated md5 value
postgresql['sql_replication_password'] = '<postgresql_replication_password_hash>'
# Replace POSTGRESQL_PASSWORD_HASH with a generated md5 value
postgresql['sql_user_password'] = '<postgresql_password_hash>'

# Set up basic authentication for the Patroni API (use the same username/password in all nodes).
patroni['username'] = '<patroni_api_username>'
patroni['password'] = '<patroni_api_password>'

# Replace 10.6.0.0/24 with Network Address
postgresql['trust_auth_cidr_addresses'] = %w(10.6.0.0/24 127.0.0.1/32)

# Local PgBouncer service for Database Load Balancing
pgbouncer['databases'] = {
   gitlabhq_production: {
      host: "127.0.0.1",
      user: "pgbouncer",
      password: '<pgbouncer_password_hash>'
   }
}

# Set the network addresses that the exporters will listen on for monitoring
node_exporter['listen_address'] = '0.0.0.0:9100'
postgres_exporter['listen_address'] = '0.0.0.0:9187'

## The IPs of the Consul server nodes
## You can also use FQDNs and intermix them with IPs
consul['configuration'] = {
   retry_join: %w(10.6.0.11 10.6.0.12 10.6.0.13),
}
#
# END user configuration

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 primary hostname>     | 10.6.0.21 | Leader | running | 175 |           | *               |
| postgresql-ha | <PostgreSQL secondary 1 hostname> | 10.6.0.22 |        | running | 175 | 0         | *               |
| postgresql-ha | <PostgreSQL secondary 2 hostname> | 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>： 

    # Disable all components except Pgbouncer and Consul agent
roles(['pgbouncer_role'])

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

# Configure Consul agent
consul['watchers'] = %w(postgresql)
consul['configuration'] = {
retry_join: %w(10.6.0.11 10.6.0.12 10.6.0.13)
}

# Enable service discovery for Prometheus
consul['monitoring_service_discovery'] = true

# Set the network addresses that the exporters will listen on
node_exporter['listen_address'] = '0.0.0.0:9100'

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

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

    如果出现错误 execute[generate databases.ini]，这是由于现有的已知问题引起的。您将在下一步后运行第二次 reconfigure 时解决该问题。

  4. 创建 .pgpass 文件，以便 Consul 能够重新加载 PgBouncer。输入两次 PgBouncer 密码时： 

    gitlab-ctl write-pgpass --host 127.0.0.1 --database pgbouncer --user pgbouncer --hostuser gitlab-consul
  5. 再次重新配置极狐GitLab，以解决上一步可能出现的错误。

  6. 确保每个节点都与当前主节点通信： 

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

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

    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)

配置 Redis

在可扩展环境中使用 Redis 是可能的，使用 主 x 副本 拓扑结构，并使用 Redis Sentinel 服务监控并自动启动故障转移过程。

noteRedis 集群必须部署在奇数个节点上，至少为 3 个节点。这是为了确保 Redis Sentinel 可以进行投票作为仲裁的一部分。当配置 Redis 外部（如云提供商服务）时，不适用。
noteRedis 主要是单线程的，增加 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.51: Redis - 缓存主节点
  • 10.6.0.52: Redis - 缓存副本 1
  • 10.6.0.53: Redis - 缓存副本 2
  • 10.6.0.61: Redis - 持久主节点
  • 10.6.0.62: Redis - 持久副本 1
  • 10.6.0.63: Redis - 持久副本 2

提供您自己的 Redis 实例

您可以选择使用 第三方外部服务的 Redis 缓存和持久性实例，并遵循以下指导：

  • 应该使用一个有信誉的提供商或解决方案。AWS ElastiCache 已知可以正常工作。
  • 不支持 Redis 集群模式，但支持具有 HA 的 Redis 独立模式。
  • 您必须根据您的设置设置 Redis 淘汰模式。

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

配置 Redis 缓存集群

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

主节点和副本节点都需要在 redis['password'] 中定义相同的密码。在任何时候进行故障转移时，Sentinel 都可以重新配置一个节点并更改其状态，从主节点到副本节点（或反之亦然）。

配置主 Redis 缓存节点

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

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

    # Specify server role as 'redis_master_role' with Sentinel and enable Consul agent
roles(['redis_sentinel_role', 'redis_master_role', 'consul_role'])

# Set IP bind address and Quorum number for Redis Sentinel service
sentinel['bind'] = '0.0.0.0'
sentinel['quorum'] = 2

# IP address pointing to a local IP that the other machines can reach to.
# You can also set bind to '0.0.0.0' which listen in all interfaces.
# If you really need to bind to an external accessible IP, make
# sure you add extra firewall rules to prevent unauthorized access.
redis['bind'] = '10.6.0.51'

# Define a port so Redis can listen for TCP requests which will allow other
# machines to connect to it.
redis['port'] = 6379

## Port of primary Redis server for Sentinel, uncomment to change to non default. Defaults
## to `6379`.
#redis['master_port'] = 6379

# Set up password authentication for Redis and replicas (use the same password in all nodes).
redis['password'] = 'REDIS_PRIMARY_PASSWORD_OF_FIRST_CLUSTER'
redis['master_password'] = 'REDIS_PRIMARY_PASSWORD_OF_FIRST_CLUSTER'

## Must be the same in every Redis node
redis['master_name'] = 'gitlab-redis-cache'

## The IP of this primary Redis node.
redis['master_ip'] = '10.6.0.51'

# Set the Redis Cache instance as an LRU
# 90% of available RAM in MB
redis['maxmemory'] = '13500mb'
redis['maxmemory_policy'] = "allkeys-lru"
redis['maxmemory_samples'] = 5

## Enable service discovery for Prometheus
consul['monitoring_service_discovery'] =  true

## The IPs of the Consul server nodes
## You can also use FQDNs and intermix them with IPs
consul['configuration'] = {
   retry_join: %w(10.6.0.11 10.6.0.12 10.6.0.13),
}

# Set the network addresses that the exporters will listen on
node_exporter['listen_address'] = '0.0.0.0:9100'
redis_exporter['listen_address'] = '0.0.0.0:9121'
redis_exporter['flags'] = {
     'redis.addr' => 'redis://10.6.0.51:6379',
     'redis.password' => 'redis-password-goes-here',
}

# Prevent database migrations from running on upgrade automatically
gitlab_rails['auto_migrate'] = false

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

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

配置副本 Redis 缓存节点

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

  3. 编辑 /etc/gitlab/gitlab.rb，并通过将 redis_master_node 替换为 redis_replica_node，添加与上一节中的主节点相同的内容： 

    # Specify server role as 'redis_replica_role' with Sentinel and enable Consul agent
roles(['roles_sentinel_role', 'redis_replica_role', 'consul_role'])

# Set IP bind address and Quorum number for Redis Sentinel service
sentinel['bind'] = '0.0.0.0'
sentinel['quorum'] = 2

# IP address pointing to a local IP that the other machines can reach to.
# You can also set bind to '0.0.0.0' which listen in all interfaces.
# If you really need to bind to an external accessible IP, make
# sure you add extra firewall rules to prevent unauthorized access.
redis['bind'] = '10.6.0.52'

# Define a port so Redis can listen for TCP requests which will allow other
# machines to connect to it.
redis['port'] = 6379

## Port of primary Redis server for Sentinel, uncomment to change to non default. Defaults
## to `6379`.
#redis['master_port'] = 6379

# Set up password authentication for Redis and replicas (use the same password in all nodes).
redis['password'] = 'REDIS_PRIMARY_PASSWORD_OF_FIRST_CLUSTER'
redis['master_password'] = 'REDIS_PRIMARY_PASSWORD_OF_FIRST_CLUSTER'

## Must be the same in every Redis node
redis['master_name'] = 'gitlab-redis-cache'

## The IP of the primary Redis node.
redis['master_ip'] = '10.6.0.51'

# Set the Redis Cache instance as an LRU
# 90% of available RAM in MB
redis['maxmemory'] = '13500mb'
redis['maxmemory_policy'] = "allkeys-lru"
redis['maxmemory_samples'] = 5

## Enable service discovery for Prometheus
consul['monitoring_service_discovery'] =  true

## The IPs of the Consul server nodes
## You can also use FQDNs and intermix them with IPs
consul['configuration'] = {
   retry_join: %w(10.6.0.11 10.6.0.12 10.6.0.13),
}

# Set the network addresses that the exporters will listen on
node_exporter['listen_address'] = '0.0.0.0:9100'
redis_exporter['listen_address'] = '0.0.0.0:9121'
redis_exporter['flags'] = {
     'redis.addr' => 'redis://10.6.0.52:6379',
     'redis.password' => 'redis-password-goes-here',
}

# Prevent database migrations from running on upgrade automatically
gitlab_rails['auto_migrate'] = false
  4. 从您配置的第一个 Linux 软件包节点复制 /etc/gitlab/gitlab-secrets.json 文件，并添加或替换此服务器上的同名文件。如果这是您配置的第一个 Linux 软件包节点，则可以跳过此步骤。
  5. 重新配置极狐GitLab 以使更改生效。
  6. 对所有其他副本节点重复这些步骤，并确保正确设置 IP。

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

配置 Redis 持久性集群

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

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

配置主 Redis 持久性节点

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

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

    # Specify server roles as 'redis_master_role' with Sentinel and enable the Consul agent
roles ['redis_sentinel_role', 'redis_master_role', 'consul_role']

# Set IP bind address and Quorum number for Redis Sentinel service
sentinel['bind'] = '0.0.0.0'
sentinel['quorum'] = 2

# IP address pointing to a local IP that the other machines can reach to.
# You can also set bind to '0.0.0.0' which listen in all interfaces.
# If you really need to bind to an external accessible IP, make
# sure you add extra firewall rules to prevent unauthorized access.
redis['bind'] = '10.6.0.61'

# Define a port so Redis can listen for TCP requests which will allow other
# machines to connect to it.
redis['port'] = 6379

## Port of primary Redis server for Sentinel, uncomment to change to non default. Defaults
## to `6379`.
#redis['master_port'] = 6379

# Set up password authentication for Redis and replicas (use the same password in all nodes).
redis['password'] = 'REDIS_PRIMARY_PASSWORD_OF_SECOND_CLUSTER'
redis['master_password'] = 'REDIS_PRIMARY_PASSWORD_OF_SECOND_CLUSTER'

## Must be the same in every Redis node
redis['master_name'] = 'gitlab-redis-persistent'

## The IP of this primary Redis node.
redis['master_ip'] = '10.6.0.61'

## Enable service discovery for Prometheus
consul['monitoring_service_discovery'] =  true

## The IPs of the Consul server nodes
## You can also use FQDNs and intermix them with IPs
consul['configuration'] = {
   retry_join: %w(10.6.0.11 10.6.0.12 10.6.0.13),
}

# Set the network addresses that the exporters will listen on
node_exporter['listen_address'] = '0.0.0.0:9100'
redis_exporter['listen_address'] = '0.0.0.0:9121'

# Prevent database migrations from running on upgrade automatically
gitlab_rails['auto_migrate'] = false
  4. 从您配置的第一个 Linux 软件包节点复制 /etc/gitlab/gitlab-secrets.json 文件，并添加或替换此服务器上的同名文件。如果这是您配置的第一个 Linux 软件包节点，则可以跳过此步骤。
  5. 重新配置极狐GitLab 以使更改生效。

配置副本 Redis 持久性节点

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

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

    # Specify server roles as 'redis_replica_role' with Sentinel and enable Consul agent
roles ['redis_sentinel_role', 'redis_replica_role', 'consul_role']

# Set IP bind address and Quorum number for Redis Sentinel service
sentinel['bind'] = '0.0.0.0'
sentinel['quorum'] = 2

# IP address pointing to a local IP that the other machines can reach to.
# You can also set bind to '0.0.0.0' which listen in all interfaces.
# If you really need to bind to an external accessible IP, make
# sure you add extra firewall rules to prevent unauthorized access.
redis['bind'] = '10.6.0.62'

# Define a port so Redis can listen for TCP requests which will allow other
# machines to connect to it.
redis['port'] = 6379

## Port of primary Redis server for Sentinel, uncomment to change to non default. Defaults
## to `6379`.
#redis['master_port'] = 6379

# The same password for Redis authentication you set up for the primary node.
redis['password'] = 'REDIS_PRIMARY_PASSWORD_OF_SECOND_CLUSTER'
redis['master_password'] = 'REDIS_PRIMARY_PASSWORD_OF_SECOND_CLUSTER'

## Must be the same in every Redis node
redis['master_name'] = 'gitlab-redis-persistent'

# The IP of the primary Redis node.
redis['master_ip'] = '10.6.0.61'

## Enable service discovery for Prometheus
consul['monitoring_service_discovery'] =  true

## The IPs of the Consul server nodes
## You can also use FQDNs and intermix them with IPs
consul['configuration'] = {
   retry_join: %w(10.6.0.11 10.6.0.12 10.6.0.13),
}

# Set the network addresses that the exporters will listen on
node_exporter['listen_address'] = '0.0.0.0:9100'
redis_exporter['listen_address'] = '0.0.0.0:9121'

# Prevent database migrations from running on upgrade automatically
gitlab_rails['auto_migrate'] = false
  4. 从您配置的第一个 Linux 软件包节点复制 /etc/gitlab/gitlab-secrets.json 文件，并添加或替换此服务器上的同名文件。如果这是您配置的第一个 Linux 软件包节点，则可以跳过此步骤。
  5. 重新配置极狐GitLab 以使更改生效。
  6. 对所有其他副本节点重复这些步骤，并确保正确设置 IP。

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

配置 Gitaly 集群

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

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

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

关于以下内容的指导：

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

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

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

配置 Praefect PostgreSQL

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

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

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

以下 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 部分中记录的值： 

    # Disable all components except PostgreSQL and Consul
roles(['postgres_role', 'consul_role'])

# PostgreSQL configuration
postgresql['listen_address'] = '0.0.0.0'

# Prevent database migrations from running on upgrade automatically
gitlab_rails['auto_migrate'] = false

# Configure the Consul agent
## Enable service discovery for Prometheus
consul['monitoring_service_discovery'] =  true

# START user configuration
# Please set the real values as explained in Required Information section
#
# Replace PRAEFECT_POSTGRESQL_PASSWORD_HASH with a generated md5 value
postgresql['sql_user_password'] = "<praefect_postgresql_password_hash>"

# Replace XXX.XXX.XXX.XXX/YY with Network Address
postgresql['trust_auth_cidr_addresses'] = %w(10.6.0.0/24 127.0.0.1/32)

# Set the network addresses that the exporters will listen on for monitoring
node_exporter['listen_address'] = '0.0.0.0:9100'
postgres_exporter['listen_address'] = '0.0.0.0:9187'

## The IPs of the Consul server nodes
## You can also use FQDNs and intermix them with IPs
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 第三方解决方案

如前所述，如果追求完全高可用性，建议为 Praefect 的数据库选择第三方 PostgreSQL 解决方案。

PostgreSQL HA 有许多第三方解决方案。选择的解决方案必须具备以下条件才能与 Praefect 一起工作：

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

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

上述示例可能包括 Amazon RDS。

一旦数据库设置完成，请参阅后续配置。

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 的连接都通过它。本节详细介绍如何配置它。

notePraefect 必须部署在 3 个或更多节点的奇数数量中。这是为了确保节点可以作为法定人数的一部分进行投票。

Praefect 需要几个秘密令牌来确保集群间的通信安全：

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

Gitaly 集群节点通过 virtual storage 在 Praefect 中配置。每个存储包含构成集群的每个 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由于极狐GitLab 需要，您不能从 virtual_storages 中删除 default 条目。
    # 避免在 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

# 开始用户配置
# 请根据所需信息部分的说明设置真实值
#

praefect['configuration'] = {
   # ...
   listen_addr: '0.0.0.0:2305',
   auth: {
      # ...
      #
      # Praefect 外部令牌
      # 这是集群外部的客户端（如极狐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),
}
#
# 结束用户配置

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

  5. Praefect 需要运行一些数据库迁移，就像主要的极狐GitLab 应用程序一样。为此，您应该选择仅一个 Praefect 节点来运行迁移，即 部署节点。该节点必须在其他节点之前配置，如下所示：

    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 服务器节点的要求取决于数据和负载。

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

由于 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

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

# Gitaly
gitaly['enable'] = true

# 配置 Consul 代理
consul['enable'] = true
## 启用 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'

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

#
# 结束用户配置
  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 服务器上。

此外，证书或其证书颁发机构必须按照极狐GitLab 自定义证书配置（并在下面重复）的过程安装在所有 Gitaly 服务器和所有与其通信的 Praefect 客户端上。

注意以下几点：

  • 证书必须指定您用于访问 Praefect 服务器的地址。您必须将主机名或 IP 地址作为主题备用名称添加到证书中。
  • 您可以同时配置具有未加密监听地址 listen_addr 和加密监听地址 tls_listen_addr 的 Praefect 服务器。这允许您在必要时逐步从未加密的流量过渡到加密的流量。要禁用未加密的监听器，请设置 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 文档。
  • 10.6.0.101：Sidekiq 1
  • 10.6.0.102：Sidekiq 2
  • 10.6.0.103：Sidekiq 3
  • 10.6.0.104：Sidekiq 4

要配置 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 连接详细信息
## 第一个将托管缓存数据的集群
gitlab_rails['redis_cache_instance'] = 'redis://:<REDIS_PRIMARY_PASSWORD_OF_FIRST_CLUSTER>@gitlab-redis-cache'

gitlab_rails['redis_cache_sentinels'] = [
  {host: '10.6.0.51', port: 26379},
  {host: '10.6.0.52', port: 26379},
  {host: '10.6.0.53', port: 26379},
]

## 托管所有其他持久数据的第二个集群
redis['master_name'] = 'gitlab-redis-persistent'
redis['master_password'] = '<REDIS_PRIMARY_PASSWORD_OF_SECOND_CLUSTER>'

gitlab_rails['redis_sentinels'] = [
  {host: '10.6.0.61', port: 26379},
  {host: '10.6.0.62', port: 26379},
  {host: '10.6.0.63', 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.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

# 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.151/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>'
}

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

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

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

    只有一个指定的节点应负责迁移，详细信息请参阅极狐GitLab Rails 后配置部分。

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

配置极狐GitLab Rails

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

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

note因为推荐使用对象存储而不是 NFS 存储数据对象，以下示例包含对象存储配置。

以下 IP 将用作示例：

  • 10.6.0.111：极狐GitLab 应用程序 1
  • 10.6.0.112：极狐GitLab 应用程序 2
  • 10.6.0.113：极狐GitLab 应用程序 3
  • 10.6.0.114：极狐GitLab 应用程序 4
  • 10.6.0.115：极狐GitLab 应用程序 5
  • 10.6.0.116：极狐GitLab 应用程序 6
  • 10.6.0.117：极狐GitLab 应用程序 7
  • 10.6.0.118：极狐GitLab 应用程序 8
  • 10.6.0.119：极狐GitLab 应用程序 9
  • 10.6.0.120：极狐GitLab 应用程序 10
  • 10.6.0.121：极狐GitLab 应用程序 11
  • 10.6.0.122：极狐GitLab 应用程序 12

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

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

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

    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 连接详细信息
## 第一个将托管缓存数据的集群
gitlab_rails['redis_cache_instance'] = 'redis://:<REDIS_PRIMARY_PASSWORD_OF_FIRST_CLUSTER>@gitlab-redis-cache'

gitlab_rails['redis_cache_sentinels'] = [
  {host: '10.6.0.51', port: 26379},
  {host: '10.6.0.52', port: 26379},
  {host: '10.6.0.53', port: 26379},
]

## 托管所有其他持久数据的第二个集群
redis['master_name'] = 'gitlab-redis-persistent'
redis['master_password'] = '<REDIS_PRIMARY_PASSWORD_OF_SECOND_CLUSTER>'

gitlab_rails['redis_sentinels'] = [
  {host: '10.6.0.61', port: 26379},
  {host: '10.6.0.62', port: 26379},
  {host: '10.6.0.63', port: 26379},
]

# 设置用于监控的导出器将监听的网络地址
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 指标
gitlab_rails['monitoring_whitelist'] = ['10.6.0.151/32', '127.0.0.0/8']
nginx['status']['options']['allow'] = ['10.6.0.151/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>'
}

  3. 如果您正在使用带有 TLS 支持的 Gitaly，请确保 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. 为确保数据库迁移仅在重新配置期间运行，而不是在升级时自动运行，请执行以下操作： 

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

    只有一个指定的节点应负责迁移，详细信息请参阅极狐GitLab Rails 后配置部分。

  6. 重新配置极狐GitLab以使更改生效。
  7. 启用增量日志记录。

  8. 确认节点可以连接到 Gitaly： 

    sudo gitlab-rake gitlab:gitaly:check

    然后，跟踪日志以查看请求： 

    sudo gitlab-ctl tail gitaly
  9. 可选地，从 Gitaly 服务器确认 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。

当您在 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 的独立监控节点。

以下 IP 将作为示例使用：

  • 10.6.0.151: 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

# Enable service discovery for Prometheus
consul['monitoring_service_discovery'] =  true
consul['configuration'] = {
   retry_join: %w(10.6.0.11 10.6.0.12 10.6.0.13)
}

# Configure Prometheus to scrape services not covered by discovery
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。

配置对象存储

极狐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 集群的推荐最佳实践，请阅读如何 选择最佳集群配置。

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

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

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

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

请参阅 Helm charts 高级配置 文档以获取设置说明，包括有关在 Kubernetes 和后端组件之间同步哪些极狐GitLab 秘密的指南。

NOTE： 这是一个 高级 设置。在 Kubernetes 中运行服务是众所周知的复杂。仅推荐此设置 如果您对 Kubernetes 有扎实的工作知识和经验。本节其余部分假定这一点。

WARNING： Gitaly Cluster 不支持在 Kubernetes 中运行。有关更多详细信息，请参阅 史诗 6127。

集群拓扑

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

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

组件节点组 目标节点池总数 GCP 示例 AWS 示例
Webservice 308 vCPU
385 GB memory (request)
539 GB memory (limit) 		11 x n1-standard-32 11 x c5.9xlarge
Sidekiq 12.6 vCPU
28 GB memory (request)
56 GB memory (limit) 		4 x n1-standard-4 4 x m5.xlarge
Supporting services 8 vCPU
30 GB memory 		2 x n1-standard-4 2 x m5.xlarge
  • 对于此设置，我们 推荐 并定期 测试 Amazon Elastic Kubernetes Service (EKS)。其他 Kubernetes 服务也可能有效，但您的体验可能会有所不同。
  • 为方便起见，提供了 GCP 和 AWS 示例，以达到目标节点池总数。这些大小用于性能测试，但不需要遵循示例。可以根据需要使用不同的节点池设计，只要满足目标，并且所有 pod 都可以部署。
  • Webservice 和 Sidekiq 目标节点池总数仅针对极狐GitLab 组件。所选 Kubernetes 提供商的系统进程还需要额外的资源。给出的示例考虑到了这一点。
  • Supporting 目标节点池总数一般用于容纳多个资源，以支持极狐GitLab 部署以及根据您的要求进行的任何额外部署。与其他节点池类似，选择的 Kubernetes 提供商的系统进程也需要资源。给出的示例考虑到了这一点。
  • 在生产部署中，不需要将 pod 分配到特定节点。然而，建议在每个池中有多个节点，分布在不同的可用性区域，以符合弹性云架构实践。
  • 出于效率原因，建议启用自动扩展，例如集群自动扩展，但通常建议将 Webservice 和 Sidekiq pod 的目标设定在 75% 以上，以确保持续的性能。

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

服务 节点 配置 GCP AWS
Consul1 3 2 vCPU, 1.8 GB memory n1-highcpu-2 c5.large
PostgreSQL1 3 32 vCPU, 120 GB memory n1-standard-32 m5.8xlarge
PgBouncer1 3 2 vCPU, 1.8 GB memory n1-highcpu-2 c5.large
Internal load balancer3 1 16 vCPU, 14.4 GB memory n1-highcpu-16 c5.4xlarge
Redis/Sentinel - Cache2 3 4 vCPU, 15 GB memory n1-standard-4 m5.xlarge
Redis/Sentinel - Persistent2 3 4 vCPU, 15 GB memory n1-standard-4 m5.xlarge
Gitaly5 3 64 vCPU, 240 GB memory6 n1-standard-64 m5.16xlarge
Praefect5 3 4 vCPU, 3.6 GB memory n1-highcpu-4 c5.xlarge
Praefect PostgreSQL1 1+ 2 vCPU, 1.8 GB memory n1-highcpu-2 c5.large
对象存储4 - - - -

脚注：

  1. 可以选择在信誉良好的第三方外部 PaaS PostgreSQL 解决方案上运行。有关更多信息，请参阅 提供您自己的 PostgreSQL 实例。
  2. 可以选择在信誉良好的第三方外部 PaaS Redis 解决方案上运行。有关更多信息，请参阅 提供您自己的 Redis 实例。
    • Redis 主要是单线程的，增加 CPU 核心数量不会显著提升性能。对于这种规模的架构，强烈建议拥有单独的缓存和持久实例，以实现最佳性能。
  3. 可以选择在信誉良好的第三方负载均衡服务（LB PaaS）上运行。有关更多信息，请参阅 推荐的云提供商和服务。
  4. 应该在信誉良好的云提供商或私有化部署解决方案上运行。有关更多信息，请参阅 配置对象存储。
  5. Gitaly Cluster 提供容错优势，但设置和管理的复杂性较高。 在部署 Gitaly Cluster 之前，请查看现有的 技术限制和注意事项。如果您希望分片 Gitaly，请使用上面列出的 Gitaly 规格。
  6. Gitaly 规格基于良好健康状态下使用模式和存储库大小的高百分比。 然而，如果您有 大型单体仓库（超过几个千兆字节）或 额外工作负载，这些可能会显著影响 Git 和 Gitaly 的性能，并可能需要进一步调整。

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

Kubernetes 组件目标

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

Webservice

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

  • 4 个 Puma 工作线程
  • 4 vCPU
  • 5 GB 内存（请求）
  • 7 GB 内存（限制）

对于 1000 RPS 或 50000 用户，我们建议总 Puma 工作线程数量约为 308，因此建议至少运行 77 个 Webservice pod。

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

NGINX

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

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

Sidekiq

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

  • 1 个 Sidekiq 工作线程
  • 900m vCPU
  • 2 GB 内存（请求）
  • 4 GB 内存（限制）

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

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

支持

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

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

如果您希望进行任何额外的部署，例如容器注册表、页面或监控，建议尽可能在该池中部署这些，而不是在 Webservice 或 Sidekiq 池中，因为 Supporting 池专门设计用于容纳多个额外部署。然而，如果您的部署不符合给定的池，可以相应增加节点池。相反，如果在您的使用案例中池过度配置，您可以相应减少。

示例配置文件

极狐GitLab Helm Charts 目标以上 1000 RPS 或 50000 参考架构配置的示例 可以在 Charts 项目中找到。

下一步

在按照本指南操作后，您应该现在有一个新的极狐GitLab 环境，核心功能已按需配置。

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

NOTE： 根据您的环境和需求，可能需要额外的硬件要求或调整以按需设置其他功能。有关更多信息，请参阅各个页面。