参考架构：最高 200 RPS 或 10,000 用户

此页面介绍了极狐GitLab 参考架构，旨在应对 200 每秒请求数（RPS）的峰值负载，典型的峰值负载高达 10,000 用户，包括手动和自动用户，基于真实数据。

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

note
在部署此架构之前，建议首先阅读主文档，特别是开始之前和决定使用哪个架构部分。
服务 节点 配置 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 8 vCPU，30 GB 内存 n1-standard-8 m5.2xlarge D8s 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/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 16 vCPU，60 GB 内存6 n1-standard-16 m5.4xlarge D16s 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 4 4 vCPU，15 GB 内存 n1-standard-4 m5.xlarge D4s v3
极狐GitLab Rails7 3 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），以提供 HA 能力。尺寸取决于选择的负载均衡器以及其他因素，如网络带宽。有关更多信息，请参考负载均衡器。
  4. 应在知名的云提供商或私有化部署解决方案上运行。有关更多信息，请参见配置对象存储。
  5. Gitaly 集群提供容错的优势，但伴随着额外的设置和管理复杂性。在部署 Gitaly 集群之前，请查看现有的技术限制和考虑。如果您想要分片 Gitaly，请使用上面列出的规格。
  6. Gitaly 规格基于健康状态下使用模式和存储库大小的高百分比。然而，如果您有大型单体代码库（超过几个 GB）或额外的工作负载，这些可能会显著影响 Git 和 Gitaly 性能，并可能需要进一步调整。
  7. 可以放置在自动缩放组（ASG）中，因为组件不存储任何有状态数据。然而，通常更推荐云原生混合设置，因为某些组件如迁移和Mailroom只能在一个节点上运行，在 Kubernetes 中处理得更好。
note
对于所有涉及配置实例的 PaaS 解决方案，建议在三个不同的可用区域中实施至少三个节点，以符合弹性云架构实践。

要求

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

测试方法

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

  • API：200 RPS
  • Web：20 RPS
  • Git（拉取）：20 RPS
  • Git（推送）：4 RPS

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

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

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

设置组件

要设置极狐GitLab 及其组件以支持最高 200 RPS 或 10,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 和通过 HTTP/SSH 的 Git）。
  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.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 hop-by-hop 头。有关更多详细信息，请参阅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 主机名将需要一个新的虚拟 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 必须部署在三个或更多的奇数节点上。这是为了确保节点能够作为法定人数的一部分进行投票。

以下 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'])

## 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'] = {
   server: true,
   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'

# Prevent database migrations from running on upgrade automatically
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. 与 Linux 软件包相比，实现 HA 所需的节点数量可能因服务而异，并不需要完全匹配。
  6. 然而，如果希望通过读取副本进行数据库负载均衡以进一步提高性能，建议遵循参考架构的节点数量。

使用 Linux 软件包的独立 PostgreSQL

推荐的 Linux 软件包配置用于具有复制和故障转移的 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 软件包。按照步骤安装所需的依赖项，并从步骤 2 添加极狐GitLab 软件包库。在第二步安装极狐GitLab时，不要提供 EXTERNAL_URL 值。 

#### PostgreSQL nodes

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['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         | *               |

如果任何节点的“State”列不显示“running”，请在继续之前检查 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 是可能的，采用 Primary x Replica 拓扑结构，并使用 Redis Sentinel 服务来监控并自动启动故障转移过程。

noteRedis 集群必须部署在 3 个或更多奇数节点上。这是为了确保 Redis Sentinel 可以作为仲裁的一部分进行投票。当外部配置 Redis，例如云服务提供商服务时，这不适用。
noteRedis 主要是单线程的，增加 CPU 核心数量对其没有显著的好处。对于这种架构规模，强烈建议根据规格具有独立的缓存和持久实例，以实现最佳性能。有关更多信息，请参阅 扩展文档。

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

Redis 设置的要求如下：

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

在本节中，您将了解如何配置两个与极狐 GitLab 一起使用的外部 Redis 集群。以下 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 缓存和持久性实例 提供以下指导：

  • 应该使用信誉良好的提供商或解决方案。
  • Redis 集群模式特别不支持，但支持具有 HA 的 Redis 独立模式。
  • 您必须根据您的设置设置 Redis 淘汰模式。

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

配置 Redis 缓存集群

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

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

配置主 Redis 缓存节点

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

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

    # Specify server roles as 'redis_master_role' with sentinel and 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.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 登录到 replica Redis 服务器。
  2. 下载并安装 你选择的 Linux 软件包。确保仅遵循页面上的安装步骤 1 和 2，并选择与当前安装相同版本和类型的正确 Linux 软件包（基础版或企业版）。

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

    # Specify server roles as 'redis_sentinel_role' and 'redis_replica_role'
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.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 以使更改生效。再次为所有其他副本节点执行这些步骤，并确保正确设置 IP。

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

配置 Redis 持久化集群

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

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

配置主 Redis 持久化节点

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

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

    # 指定服务器角色为 'redis_master_role'，包含哨兵和 Consul 代理
roles ['redis_sentinel_role', 'redis_master_role', 'consul_role']

# 为 Redis 哨兵服务设置 IP 绑定地址和仲裁号
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 服务器的哨兵端口，取消注释以更改为非默认值。默认是 `6379`。
#redis['master_port'] = 6379

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

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

## 这个主 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 登录到副本 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']

# 为 Redis 哨兵服务设置 IP 绑定地址和仲裁号
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 服务器的哨兵端口，取消注释以更改为非默认值。默认是 `6379`。
#redis['master_port'] = 6379

# 您为主节点设置的相同 Redis 认证密码。
redis['password'] = 'REDIS_PRIMARY_PASSWORD_OF_SECOND_CLUSTER'
redis['master_password'] = 'REDIS_PRIMARY_PASSWORD_OF_SECOND_CLUSTER'

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

# 主 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 节点上，其中一个被指定为主节点，如果主节点发生故障，故障转移会自动进行。

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

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 独立 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 高可用性的第三方解决方案。选择的解决方案必须具备以下条件才能与 Praefect 一起工作：

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

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

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

上面的例子可以包括 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 的连接都要通过它。本节详细介绍如何配置它。

noteConsul 必须部署在三个或更多数量为奇数的节点上。这是为了确保节点可以在法定人数中投票。

Praefect 需要几个秘密令牌来保护集群内的通信：

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

Gitaly 集群节点在 Praefect 中通过 virtual storage 配置。每个存储包含构成集群的每个 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

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

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 节点来运行迁移，即 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

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

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

由于 Gitaly 具有显著的输入和输出需求，我们强烈推荐所有 Gitaly 节点使用固态硬盘（SSDs）。这些 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 文件以配置存储路径，启用网络监听器，并配置 token： 

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

# START 用户配置
# 请设置真实值，如所需信息部分所述
#
## Consul 服务器节点的 IPs
## 您也可以使用 FQDNs 并与 IPs 混合使用
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 身份验证 Token
      # 应与 praefect_internal_token 相同
      token: '<praefect_internal_token>',
   },
   pack_objects_cache: {
      # Gitaly 打包对象缓存
      # 推荐启用以改善性能，但可能显著增加磁盘 I/O
      # 详细信息请参考 https://gitlab.cn/docs/ee/administration/gitaly/configure_gitaly.html#pack-objects-cache
      enabled: true,
   },
}

#
# END 用户配置
  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）时，需要更新 Sidekiq 配置以及 Rails 配置。有关更多信息，请参阅外部 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"])

# External 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 的内部负载均衡器
## Token 是 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.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

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

  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 的内部负载均衡器
# Token 是 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. 复制你配置的第一个 Linux 软件包节点的 SSH 主机密钥（所有格式为 /etc/ssh/ssh_host_*_key* 的文件）并添加或替换此服务器上的同名文件。这确保不会为用户抛出主机不匹配错误，因为他们会命中负载均衡的 Rails 节点。如果这是你正在配置的第一个 Linux 软件包节点，则可以跳过此步骤。

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

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

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

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

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

    sudo gitlab-rake gitlab:gitaly:check

    然后，尾随日志查看请求： 

    sudo gitlab-ctl tail gitaly
  10. 可选地，从 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 软件包来部署，以获得更高的持久性。

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

note这是一个 高级 设置。众所周知，在 Kubernetes 中运行服务是复杂的。仅当 您对 Kubernetes 有深入的工作知识和经验时，才推荐此设置。本节的其余部分假定您具备这些知识。
caution不支持在 Kubernetes 中运行 Gitaly 集群。有关详细信息，请参阅 史诗 6127。

集群拓扑

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

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

组件节点组 目标节点池总数 GCP 示例 AWS 示例
Webservice 80 vCPU
100 GB 内存（请求）
140 GB 内存（限制） 		3 x n1-standard-32 3 x c5.9xlarge
Sidekiq 12.6 vCPU
28 GB 内存（请求）
56 GB 内存（限制） 		4 x n1-standard-4 4 x m5.xlarge
支持服务 8 vCPU
30 GB 内存 		2 x n1-standard-4 2 x m5.xlarge
  • 对于此设置，我们推荐并定期 测试 Amazon Elastic Kubernetes Service (EKS)。其他 Kubernetes 服务也可能有效，但效果可能会有所不同。
  • 为方便起见，给出了 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 8 vCPU, 30 GB 内存 n1-standard-8 m5.2xlarge
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/Sentinel - 缓存2 3 4 vCPU, 15 GB 内存 n1-standard-4 m5.xlarge
Redis/Sentinel - 持久化2 3 4 vCPU, 15 GB 内存 n1-standard-4 m5.xlarge
Gitaly5 3 16 vCPU, 60 GB 内存6 n1-standard-16 m5.4xlarge
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 实例 和 推荐的云提供商和服务。
    • Redis 主要是单线程的，增加 CPU 内核数并不会显著提高性能。对于这种架构规模，强烈建议按照指定的分开缓存和持久化实例，以实现最佳性能。
  3. 推荐使用知名的第三方负载均衡器或服务 (LB PaaS)，它可以提供高可用性功能。大小还取决于所选负载均衡器和其他因素，例如网络带宽。有关更多信息，请参阅 负载均衡器。
  4. 应在知名的云提供商或私有化部署解决方案上运行。有关更多信息，请参阅 配置对象存储。
  5. Gitaly 集群提供了容错的好处，但增加了设置和管理的复杂性。在部署 Gitaly 集群之前，请查看现有的 技术限制和注意事项。如果您需要分片的 Gitaly，请使用上面列出的 Gitaly 规格。
  6. Gitaly 规格基于高百分位的使用模式和健康良好的存储库大小。然而，如果您有 大型单体存储库（大于几个 GB）或 额外工作负载，这些可能会显著影响 Git 和 Gitaly 的性能，因此可能需要进一步调整。
note对于涉及配置实例的所有 PaaS 解决方案，建议在三个不同的可用区内实现至少三个节点，以符合高可用性云架构实践。

Kubernetes 组件目标

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

Webservice

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

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

对于 200 RPS 或 10,000 用户，我们建议总 Puma 工作线程数量约为 80，因此建议至少运行 20 个 Webservice pod。

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

NGINX

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

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

Sidekiq

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

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

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

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

支持节点池

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

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

如果您希望进行任何其他部署，例如 Container Registry、Pages 或 Monitoring，建议尽可能在此池中部署，而不是在 Webservice 或 Sidekiq 池中，因为支持池专门设计用于容纳几个附加部署。但是，如果您的部署不适合给定的池，您可以相应地增加节点池。相反，如果池在您的用例中被过度配置，您可以相应地减少。

示例配置文件

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

下一步

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

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

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