参考架构：支持高达 500 RPS 或 25,000 用户

此页面描述了极狐GitLab 参考架构，旨在应对 500 次每秒请求 (RPS) 的峰值负载——基于真实数据的手动和自动高达 25,000 用户的典型峰值负载。

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

note在部署此架构之前，建议首先阅读 主要文档，特别是开始之前和决定使用哪个架构部分。
服务 节点 配置 GCP AWS Azure
外部负载均衡器3 1 8 vCPU, 7.2 GB 内存 n1-highcpu-8 c5n.2xlarge F8s v2
Consul1 3 2 vCPU, 1.8 GB 内存 n1-highcpu-2 c5.large F2s v2
PostgreSQL1 3 16 vCPU, 60 GB 内存 n1-standard-16 m5.4xlarge D16s v3
PgBouncer1 3 2 vCPU, 1.8 GB 内存 n1-highcpu-2 c5.large F2s v2
内部负载均衡器3 1 8 vCPU, 7.2 GB 内存 n1-highcpu-8 c5n.2xlarge F8s 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 32 vCPU, 120 GB 内存6 n1-standard-32 m5.8xlarge D32s 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 5 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. 由于组件不存储任何有状态数据，可以将其放置在自动扩展组 (ASG) 中。然而，通常更偏好云原生混合设置，因为某些组件（如迁移和邮件室）只能在一个节点上运行，这在 Kubernetes 中处理得更好。
note对于涉及配置实例的所有 PaaS 解决方案，建议在三个不同的可用性区域中实现至少三个节点，以符合弹性云架构实践。

要求

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

测试方法

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

  • API：500 RPS
  • Web：50 RPS
  • Git（拉取）：50 RPS
  • Git（推送）：10 RPS

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

如果您有指标建议显示您在上述端点目标下的吞吐量定期较高，大型单体仓库或显著的附加工作负载可能会显著影响性能环境，并且可能需要进一步调整。如果这适用于您，我们强烈建议您参考链接的文档，并联系您的客户成功经理或我们的支持团队以获得进一步指导。

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

设置组件

要设置极狐GitLab及其组件以容纳 500 RPS 或 25,000 名用户：

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

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

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

  • 10.6.0.10：外部负载均衡器
  • 10.6.0.11：Consul 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.151：Prometheus

配置外部负载均衡器

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

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

就绪检查

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

端口

下表显示了要使用的基本端口。

LB Port Backend Port Protocol
80 80 HTTP (1)
443 443 TCP or HTTPS (1) (2)
22 22 TCP
  • (1): Web terminal 支持需要您的负载均衡器正确处理 WebSocket 连接。当使用 HTTP 或 HTTPS 代理时，这意味着您的负载均衡器必须配置为通过 Connection 和 Upgrade hop-by-hop 头。请参阅 web terminal 集成指南了解更多详情。
  • (2): 当使用 HTTPS 协议在端口 443 时，您需要在负载均衡器上添加 SSL 证书。如果您希望在极狐GitLab 应用服务器上终止 SSL，请使用 TCP 协议。

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

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

替代 SSH 端口

一些组织有不开放 SSH 端口 22 的政策。在这种情况下，配置一个允许用户在端口 443 使用 SSH 的替代 SSH 主机名可能会有所帮助。替代 SSH 主机名将需要一个与上述其他极狐GitLab HTTP 配置不同的新虚拟 IP 地址。

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

LB Port Backend Port Protocol
443 22 TCP

SSL

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

应用节点终止 SSL

将负载均衡器配置为将端口 443 上的连接作为 TCP 传递，而不是 HTTP(S) 协议。这将把连接传递给应用节点的 NGINX 服务，不做任何更改。NGINX 将拥有 SSL 证书并监听端口 443。

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

负载均衡器终止 SSL，后端没有 SSL

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

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

负载均衡器终止 SSL，后端有 SSL

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

在这种情况下，负载均衡器和 NGINX 之间的通信也将是安全的。由于连接将是全程安全的，因此无需为代理 SSL 添加配置。但是，需要在极狐GitLab 中添加配置以设置 SSL 证书。请参阅 HTTPS 文档了解管理 SSL 证书和配置 NGINX 的详细信息。

配置内部负载均衡器

内部负载均衡器用于平衡极狐GitLab 环境所需的任何内部连接，例如连接到 PgBouncer 和 Praefect (Gitaly Cluster)。

它是与外部负载均衡器分开的节点，且不应有任何外部访问权限。

以下 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 服务器。

note
Consul 必须部署在 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'])

## 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. 实现 HA 所需的节点数量可能会根据服务与 Linux 软件包相比有所不同，并不需要相应匹配。
  6. 然而，如果为了进一步提高性能而需要通过读取副本进行数据库负载均衡，建议遵循参考架构中的节点数量。

使用 Linux 软件包的独立 PostgreSQL

推荐的用于复制和故障转移的 PostgreSQL 集群的 Linux 软件包配置需要：

  • 至少三个 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 节点

  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 # You will be prompted for 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. 使用防火墙保护节点不受外部网络（Internet）的访问。

在本节中，您将被指导配置两个外部 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 集群模式明确不支持，但支持具有高可用性的 Redis 独立模式。
  • 您必须根据您的设置配置 Redis 驱逐模式。

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

配置 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_sentinel_role' 'redis_master_role'
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.
# 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 (use the same password in all nodes).
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' 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.
# Set bind to '0.0.0.0' to listen on 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['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 节点都需要在 redis['password'] 中定义相同的密码。在故障转移期间的任何时间，Sentinel 都可以重新配置节点并将其状态从主节点更改为副本节点（反之亦然）。

配置主 Redis 持久化节点

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

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

    # Specify server roles as 'redis_sentinel_role' and 'redis_master_role'
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 role as 'redis_replica_role' 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['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'
redis_exporter['flags'] = {
     'redis.addr' => 'redis://10.6.0.62: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。

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

配置 Gitaly 集群

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

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

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

关于以下方面的指导：

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

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

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

配置 Praefect PostgreSQL

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

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

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

以下 IP 将用作示例：

  • 10.6.0.141：Praefect PostgreSQL

首先，确保在 Praefect PostgreSQL 节点上安装 Linux 极狐GitLab 软件包。按照步骤安装必要的依赖项，并从步骤 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 开始默认启用的负载均衡不兼容。

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

一旦数据库设置完成，遵循后配置。

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您不能从 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 节点来运行迁移，即 部署节点。此节点必须按照以下步骤首先配置：

    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 打包对象缓存
      # 建议启用以提高性能，但可能显著增加磁盘 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 服务器上。

此外，证书或其证书颁发机构必须安装在所有 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
## This should match the URL of the external load balancer
external_url 'https://gitlab.example.com'

# Redis
## Redis connection details
## First cluster that will host the cache data
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},
]

## Second cluster that hosts all other persistent data
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 Cluster
## git_data_dirs get configured for the Praefect virtual storage
## Address is Internal Load Balancer for Praefect
## Token is praefect_external_token
git_data_dirs({
  "default" => {
    "gitaly_address" => "tcp://10.6.0.40:2305", # internal load balancer IP
    "gitaly_token" => '<praefect_external_token>'
  }
})

# PostgreSQL
gitlab_rails['db_host'] = '10.6.0.20' # internal load balancer 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

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

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

## Set number of Sidekiq queue processes to the same number as available CPUs
sidekiq['queue_groups'] = ['*'] * 4

# Monitoring
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)
}

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

## Add the monitoring node's IP address to the monitoring whitelist
gitlab_rails['monitoring_whitelist'] = ['10.6.0.151/32', '127.0.0.0/8']

# Object Storage
# This is an example for configuring Object Storage on GCP
# Replace this config with your chosen Object Storage provider as desired
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

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

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

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

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

# git_data_dirs get configured for the Praefect virtual storage
# Address is Internal Load Balancer for Praefect
# Token is praefect_external_token
git_data_dirs({
  "default" => {
    "gitaly_address" => "tcp://10.6.0.40:2305", # internal load balancer IP
    "gitaly_token" => '<praefect_external_token>'
  }
})

## Disable components that will not be on the GitLab application server
roles(['application_role'])
gitaly['enable'] = false
sidekiq['enable'] = false

## PostgreSQL connection details
# Disable PostgreSQL on the application node
postgresql['enable'] = false
gitlab_rails['db_host'] = '10.6.0.20' # internal load balancer 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

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

## Redis connection details
## First cluster that will host the cache data
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},
]

## Second cluster that hosts all other persistent data
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},
]

# Set the network addresses that the exporters used for monitoring will listen on
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'

# Add the monitoring node's IP address to the monitoring whitelist and allow it to
# scrape the NGINX metrics
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']

#############################
###     Object storage    ###
#############################

# This is an example for configuring Object Storage on GCP
# Replace this config with your chosen Object Storage provider as desired
gitlab_rails['object_store']['enabled'] = true
gitlab_rails['object_store']['connection'] = {
  'provider' => 'Google',
  'google_project' => '<gcp-project-name>',
  'google_json_key_location' => '<path-to-gcp-service-account-key>'
}
gitlab_rails['object_store']['objects']['artifacts']['bucket'] = "<gcp-artifacts-bucket-name>"
gitlab_rails['object_store']['objects']['external_diffs']['bucket'] = "<gcp-external-diffs-bucket-name>"
gitlab_rails['object_store']['objects']['lfs']['bucket'] = "<gcp-lfs-bucket-name>"
gitlab_rails['object_store']['objects']['uploads']['bucket'] = "<gcp-uploads-bucket-name>"
gitlab_rails['object_store']['objects']['packages']['bucket'] = "<gcp-packages-bucket-name>"
gitlab_rails['object_store']['objects']['dependency_proxy']['bucket'] = "<gcp-dependency-proxy-bucket-name>"
gitlab_rails['object_store']['objects']['terraform_state']['bucket'] = "<gcp-terraform-state-bucket-name>"

gitlab_rails['backup_upload_connection'] = {
  'provider' => 'Google',
  'google_project' => '<gcp-project-name>',
  'google_json_key_location' => '<path-to-gcp-service-account-key>'
}
gitlab_rails['backup_upload_remote_directory'] = "<gcp-backups-state-bucket-name>"
gitlab_rails['ci_secure_files_object_store_enabled'] = true
gitlab_rails['ci_secure_files_object_store_remote_directory'] = "gcp-ci_secure_files-bucket-name"

gitlab_rails['ci_secure_files_object_store_connection'] = {
   'provider' => 'Google',
   'google_project' => '<gcp-project-name>',
   'google_json_key_location' => '<path-to-gcp-service-account-key>'
}

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

    git_data_dirs({
  "default" => {
    "gitaly_address" => "tls://10.6.0.40:2305", # internal load balancer 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 的云原生混合参考架构（替代方案）

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

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

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

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

note这是一个高级设置。在 Kubernetes 中运行服务众所周知是复杂的。只有在您对 Kubernetes 有深入的工作知识和经验时才推荐这种设置。本节剩余部分假设这一点。
cautionGitaly 集群不支持在 Kubernetes 中运行。有关更多详细信息，请参阅 史诗 6127。

集群拓扑

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

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

组件节点组 目标节点池总计 GCP 示例 AWS 示例
Webservice 140 vCPU
175 GB 内存（请求）
245 GB 内存（限制） 		5 x n1-standard-32 5 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 16 vCPU, 60 GB 内存 n1-standard-16 m5.4xlarge
PgBouncer1 3 2 vCPU, 1.8 GB 内存 n1-highcpu-2 c5.large
内部负载均衡器3 1 8 vCPU, 7.2 GB 内存 n1-highcpu-8 c5.2xlarge
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 32 vCPU, 120 GB 内存6 n1-standard-32 m5.8xlarge
Praefect5 3 4 vCPU, 3.6 GB 内存 n1-highcpu-4 c5.xlarge
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 规格基于良好健康状态下的高百分位使用模式和存储库大小。然而，如果您有大型单体仓库（大于几个千兆字节）或额外的工作负载，这些可能会显著影响 Git 和 Gitaly 性能，并且可能需要进一步调整。
note对于所有涉及配置实例的 PaaS 解决方案，建议在三个不同的可用区中实施至少三个节点，以符合弹性云架构实践。

Kubernetes 组件目标

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

Webservice

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

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

对于 500 RPS 或 25,000 用户，我们建议总共使用大约 140 个 Puma worker，因此建议至少运行 35 个 Webservice pods。

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

NGINX

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

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

Sidekiq

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

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

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

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

支持

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

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

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

示例配置文件

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

下一步

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

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

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