参考架构：最多 100 RPS 或 5,000 用户

本文描述了极狐GitLab 为应对每秒 100 个请求 (RPS) 的峰值负载而设计的参考架构——基于真实数据的典型峰值负载可达 5,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 4 vCPU, 15 GB 内存 n1-standard-4 m5.xlarge D4s v3
PgBouncer1 3 2 vCPU, 1.8 GB 内存 n1-highcpu-2 c5.large F2s v2
内部负载均衡器3 1 4 vCPU, 3.6 GB 内存 n1-highcpu-4 c5n.xlarge F4s v2
Redis/Sentinel2 3 2 vCPU, 7.5 GB 内存 n1-standard-2 m5.large D2s v3
Gitaly5 3 8 vCPU, 30 GB 内存6 n1-standard-8 m5.2xlarge D8s v3
Praefect5 3 2 vCPU, 1.8 GB 内存 n1-highcpu-2 c5.large F2s v2
Praefect PostgreSQL1 1+ 2 vCPU, 1.8 GB 内存 n1-highcpu-2 c5.large F2s v2
Sidekiq7 2 4 vCPU, 15 GB 内存 n1-standard-4 m5.xlarge D2s v3
极狐GitLab Rails7 3 16 vCPU, 14.4 GB 内存 n1-highcpu-16 c5.4xlarge F16s v2
监控节点 1 2 vCPU, 1.8 GB 内存 n1-highcpu-2 c5.large F2s v2
对象存储4 - - - - -

脚注：

  1. 可以选择在信誉良好的第三方外部 PaaS PostgreSQL 解决方案上运行。有关更多信息，请参阅提供您自己的 PostgreSQL 实例。
  2. 可以选择在信誉良好的第三方外部 PaaS Redis 解决方案上运行。有关更多信息，请参阅提供您自己的 Redis 实例。
  3. 建议与信誉良好的第三方负载均衡器或服务（LB PaaS）一起运行，这些服务可以提供 HA 功能。此外，大小取决于所选负载均衡器和其他因素，如网络带宽。有关更多信息，请参阅负载均衡器。
  4. 应在信誉良好的云提供商或私有化部署解决方案上运行。有关更多信息，请参阅配置对象存储。
  5. Gitaly 集群提供容错的好处，但增加了设置和管理的复杂性。在部署 Gitaly 集群之前，请查看现有的技术限制和注意事项。如果您想要分片 Gitaly，请使用上面列出的 Gitaly 规格。
  6. Gitaly 规格基于良好状态下使用模式和存储库大小的高百分位数。然而，如果您有大型单体库（大于几 GB）或额外的工作负载，这些可能显著影响 Git 和 Gitaly 性能，并可能需要进一步调整。
  7. 可以放置在自动扩展组 (ASG) 中，因为组件不存储任何有状态数据。然而，云原生混合设置通常更受欢迎，因为某些组件如迁移和Mailroom只能在一个节点上运行，这在 Kubernetes 中处理得更好。
note
对于涉及配置实例的所有 PaaS 解决方案，建议在三个不同的可用区中实施至少三个节点，以符合弹性云架构实践。

需求

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

测试方法

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

  • API：100 RPS
  • Web：10 RPS
  • Git（拉取）：10 RPS
  • Git（推送）：2 RPS

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

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

用于测试的负载均衡器是 HAProxy 用于 Linux 软件包环境或等效的云提供商服务，配有 NGINX Ingress 用于云原生混合体。这些选择不代表具体的要求或建议，因为大多数信誉良好的负载均衡器预计可以工作。

设置组件

为了设置极狐GitLab 及其组件以支持最多 100 RPS 或 5,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/Sentinel 1
  • 10.6.0.12: Consul/Sentinel 2
  • 10.6.0.13: Consul/Sentinel 3
  • 10.6.0.21: PostgreSQL 主节点
  • 10.6.0.22: PostgreSQL 副本 1
  • 10.6.0.23: PostgreSQL 副本 2
  • 10.6.0.31: PgBouncer 1
  • 10.6.0.32: PgBouncer 2
  • 10.6.0.33: PgBouncer 3
  • 10.6.0.20: 内部负载均衡器
  • 10.6.0.61: Redis 主节点
  • 10.6.0.62: Redis 副本 1
  • 10.6.0.63: Redis 副本 2
  • 10.6.0.51: Gitaly 1
  • 10.6.0.52: Gitaly 2
  • 10.6.0.93: Gitaly 3
  • 10.6.0.131: Praefect 1
  • 10.6.0.132: Praefect 2
  • 10.6.0.133: Praefect 3
  • 10.6.0.141: Praefect PostgreSQL 1（非 HA）
  • 10.6.0.71: Sidekiq 1
  • 10.6.0.72: Sidekiq 2
  • 10.6.0.41: 极狐GitLab 应用 1
  • 10.6.0.42: 极狐GitLab 应用 2
  • 10.6.0.43: 极狐GitLab 应用 3
  • 10.6.0.81: Prometheus

配置外部负载均衡器

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

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

就绪检查

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

端口

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

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

如果您使用极狐GitLab Pages 支持自定义域，您将需要一些额外的端口配置。极狐GitLab Pages 需要一个单独的虚拟 IP 地址。将 /etc/gitlab/gitlab.rb 中的 pages_external_url 配置为指向新的虚拟 IP 地址。

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

替代 SSH 端口

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

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

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

SSL

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

应用节点终止 SSL

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

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

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

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

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

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

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

在这种情况下，负载均衡器和 NGINX 之间的流量也将是安全的。由于连接将始终是安全的，因此不需要为代理 SSL 添加配置。然而，需要在极狐GitLab 中添加配置以配置 SSL 证书。有关管理 SSL 证书和配置 NGINX 的详细信息，请参阅 HTTPS 文档。

配置内部负载均衡器

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

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

以下 IP 用作示例：

  • 10.6.0.40: 内部负载均衡器

您可以使用 HAProxy 进行如下配置： 

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

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

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

    default_backend pgbouncer

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

    default_backend praefect

backend pgbouncer
    mode tcp
    option tcp-check

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

backend praefect
    mode tcp
    option tcp-check
    option srvtcpka

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

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

配置 Consul

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

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

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

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

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

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

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

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

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

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

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

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

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

sudo gitlab-ctl status

输出应类似于以下内容： 

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

配置 PostgreSQL

本节将指导您配置一个高可用的 PostgreSQL 集群以供极狐GitLab 使用。

提供您自己的 PostgreSQL 实例

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

应使用信誉良好的提供商或解决方案。AWS RDS 已知可用。然而，从 14.4.0 开始，亚马逊 Aurora 与默认启用的负载均衡不兼容。

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

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

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

使用 Linux 软件包的独立 PostgreSQL

推荐的 Linux 软件包配置为具有复制和故障切换的 PostgreSQL 集群需要：

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

  • 启用数据库负载均衡。

    每个 PostgreSQL 节点上配置一个本地 PgBouncer 服务。这与跟踪主节点的主要 PgBouncer 集群分开。

以下 IP 用作示例：

  • 10.6.0.21: PostgreSQL 主节点
  • 10.6.0.22: PostgreSQL 副本 1
  • 10.6.0.23: PostgreSQL 副本 2

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

PostgreSQL 节点

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

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

    sudo gitlab-ctl pg-password-md5 gitlab

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

    sudo gitlab-ctl pg-password-md5 pgbouncer

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

    sudo gitlab-ctl pg-password-md5 gitlab_replicator

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

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

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

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

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

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

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

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

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

# START user configuration
# 请按照要求信息部分设置真实值
#
# 将 PGBOUNCER_PASSWORD_HASH 替换为生成的 md5 值
postgresql['pgbouncer_user_password'] = '<pgbouncer_password_hash>'
# 将 POSTGRESQL_REPLICATION_PASSWORD_HASH 替换为生成的 md5 值
postgresql['sql_replication_password'] = '<postgresql_replication_password_hash>'
# 将 POSTGRESQL_PASSWORD_HASH 替换为生成的 md5 值
postgresql['sql_user_password'] = '<postgresql_password_hash>'

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

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

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

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

## Consul 服务器节点的 IP
## 您还可以使用 FQDN 并将其与 IP 混合使用
consul['configuration'] = {
   retry_join: %w(10.6.0.11 10.6.0.12 10.6.0.13),
}
#
# END 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'
pgbouncer_exporter['listen_address'] = '0.0.0.0:9188'

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

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

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

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

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

    gitlab-ctl pgb-console # You will be prompted for PGBOUNCER_PASSWORD

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

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

    show databases ; show clients ;

    输出应类似于以下内容： 

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

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

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

    sudo gitlab-ctl status

    输出应类似于以下内容： 

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

配置 Redis

在可扩展环境中使用 Redis 可以通过 主 x 副本 拓扑结构实现，并使用 Redis Sentinel 服务来监视和自动启动故障转移过程。

noteRedis 集群必须部署在 3 个或更多节点的奇数个数中。这是为了确保 Redis Sentinel 可以作为法定人数的一部分进行投票。配置外部 Redis 时（例如云提供商服务），不适用此项。
noteRedis 主要是单线程的，增加 CPU 核心并不能显著提高性能。有关更多信息，请参阅扩展文档。

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

Redis 设置的要求如下：

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

在本节中，您将被引导完成配置两个外部 Redis 集群以与极狐GitLab 一起使用。以下 IP 将作为示例使用：

  • 10.6.0.61: Redis 主节点
  • 10.6.0.62: Redis 副本 1
  • 10.6.0.63: Redis 副本 2

提供您自己的 Redis 实例

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

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

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

配置 Redis 集群

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

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

配置主 Redis 节点

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

配置副本 Redis 节点

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

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

    # Specify server roles as 'redis_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.62'

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

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

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

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

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

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

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

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

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

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

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

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

配置 Gitaly 集群

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

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

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

如果您需要指导：

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

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

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

配置 Praefect PostgreSQL

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

如果您想要设置高可用性，Praefect 需要一个第三方 PostgreSQL 数据库。

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

以下 IP 用作示例：

  • 10.6.0.141: Praefect PostgreSQL

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

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

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

    sudo gitlab-ctl pg-password-md5 praefect

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

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

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

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

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

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

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

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

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

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

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

  7. 参见 后续配置。

Praefect HA PostgreSQL 第三方解决方案

如前所述，如果目标是完全高可用性，建议为 Praefect 的数据库使用第三方 PostgreSQL 解决方案。

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

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

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

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

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

Praefect PostgreSQL 后续配置

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

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

这是在 Linux 软件包 PostgreSQL 设置中的操作方式：

  1. SSH 登录到 Praefect PostgreSQL 节点。

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

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

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

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

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

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

  5. 创建新数据库 praefect_production： 

    CREATE DATABASE praefect_production WITH ENCODING=UTF8;

配置 Praefect

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

note
Praefect 必须以 3 个或更多节点的奇数数量部署。这是为了确保节点可以作为仲裁的一部分投票。

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

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

Gitaly 集群节点在 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 需要它。
    # Avoid running unnecessary services on the Praefect server
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 Configuration
praefect['enable'] = true

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

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

# START user configuration
# Please set the real values as explained in Required Information section
#

praefect['configuration'] = {
   # ...
   listen_addr: '0.0.0.0:2305',
   auth: {
      # ...
      #
      # Praefect External Token
      # This is needed by clients outside the cluster (like GitLab Shell) to communicate with the Praefect cluster
      token: '<praefect_external_token>',
   },
   # Praefect Database Settings
   database: {
      # ...
      host: '10.6.0.141',
      port: 5432,
      dbname: 'praefect_production',
      user: 'praefect',
      password: '<praefect_postgresql_password>',
   },
   # Praefect Virtual Storage config
   # Name of storage hash must match storage name in git_data_dirs on GitLab
   # server ('praefect') and in gitaly['configuration'][:storage] on Gitaly nodes ('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>'
            },
         ],
      },
   ],
   # Set the network address Praefect will listen on for monitoring
   prometheus_listen_addr: '0.0.0.0:9652',
}

# Set the network address the node exporter will listen on for monitoring
node_exporter['listen_address'] = '0.0.0.0:9100'

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

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

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

由于 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 文件以配置存储路径，启用网络监听器，并配置令牌： 

    # Avoid running unnecessary services on the Gitaly server
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

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

# Configure the gitlab-shell API callback URL. Without this, `git push` will
# fail. This can be your 'front door' GitLab URL or an internal load
# balancer.
gitlab_rails['internal_api_url'] = 'https://gitlab.example.com'

# Gitaly
gitaly['enable'] = true

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

# START user configuration
# Please set the real values as explained in Required Information section
#
## 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 address that the node exporter will listen on for monitoring
node_exporter['listen_address'] = '0.0.0.0:9100'

gitaly['configuration'] = {
   # Make Gitaly accept connections on all network interfaces. You must use
   # firewalls to restrict access to this address/port.
   # Comment out following line if you only want to support TLS connections
   listen_addr: '0.0.0.0:8075',
   # Set the network address that Gitaly will listen on for monitoring
   prometheus_listen_addr: '0.0.0.0:9236',
   auth: {
      # Gitaly Auth Token
      # Should be the same as praefect_internal_token
      token: '<praefect_internal_token>',
   },
   pack_objects_cache: {
      # Gitaly Pack-objects cache
      # Recommended to be enabled for improved performance but can notably increase disk I/O
      # Refer to https://docs.gitlab.com/ee/administration/gitaly/configure_gitaly.html#pack-objects-cache for more info
      enabled: true,
   },
}

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

    • 在 Gitaly 节点 1 上： 

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

    • 在 Gitaly 节点 2 上： 

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

    • 在 Gitaly 节点 3 上： 

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

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

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

Gitaly 集群 TLS 支持

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

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

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

注意以下事项：

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

要使用 TLS 配置 Praefect：

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

  2. 在 Praefect 服务器上，创建 /etc/gitlab/ssl 目录并将密钥和证书复制到那里： 

    sudo mkdir -p /etc/gitlab/ssl
sudo chmod 755 /etc/gitlab/ssl
sudo cp key.pem cert.pem /etc/gitlab/ssl/
sudo chmod 644 key.pem cert.pem

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

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

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

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

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

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

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

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

配置 Sidekiq

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

note因为建议使用对象存储 而不是 NFS 来存储数据对象，以下示例包括对象存储配置。
note如果您发现环境中的 Sidekiq 作业处理速度缓慢且队列较长，可以根据需要添加更多节点。您还可以调整 Sidekiq 节点以运行多个 Sidekiq 进程。
note在配置其他极狐GitLab 功能（如容器注册表、SAML 或 LDAP）时，除了 Rails 配置，还需要更新 Sidekiq 配置。有关更多信息，请参阅外部 Sidekiq 文档。
  • 10.6.0.71: Sidekiq 1
  • 10.6.0.72: Sidekiq 2

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

  1. SSH 登录到 Sidekiq 服务器。

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

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

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

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

# External URL
## This should match the URL of the external load balancer
external_url 'https://gitlab.example.com'

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

## The same password for Redis authentication you set up for the master node.
redis['master_password'] = '<redis_primary_password>'

## A list of sentinels with `host` and `port`
gitlab_rails['redis_sentinels'] = [
   {'host' => '10.6.0.11', 'port' => 26379},
   {'host' => '10.6.0.12', 'port' => 26379},
   {'host' => '10.6.0.13', 'port' => 26379},
]

# Gitaly 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.40' # 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.81/32', '127.0.0.0/8']
gitlab_rails['prometheus_address'] = '10.6.0.81:9090'

# 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 以使更改生效。

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

    sudo gitlab-ctl status

    输出应类似于以下内容： 

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

配置极狐GitLab Rails

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

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

note因为建议使用对象存储 而不是 NFS 来存储数据对象，以下示例包括对象存储配置。

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

  1. 下载并安装 你选择的 Linux 软件包。确保仅按照页面上的安装步骤 1 和 2 操作。

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

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

# git_data_dirs 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
## Must be the same in every sentinel node
redis['master_name'] = 'gitlab-redis'

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

## A list of sentinels with `host` and `port`
gitlab_rails['redis_sentinels'] = [
  {'host' => '10.6.0.11', 'port' => 26379},
  {'host' => '10.6.0.12', 'port' => 26379},
  {'host' => '10.6.0.13', 'port' => 26379}
]

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

# 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'
sidekiq['listen_address'] = "0.0.0.0"
puma['listen'] = '0.0.0.0'

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

# 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.81/32', '127.0.0.0/8']
nginx['status']['options']['allow'] = ['10.6.0.81/32', '127.0.0.0/8']
gitlab_rails['prometheus_address'] = '10.6.0.81:9090'

#############################
###     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>'
}

## Uncomment and edit the following options if you have set up NFS
##
## Prevent GitLab from starting if NFS data mounts are not available
##
#high_availability['mountpoint'] = '/var/opt/gitlab/git-data'
##
## Ensure UIDs and GIDs match between servers for permissions via NFS
##
#user['uid'] = 9000
#user['gid'] = 9000
#web_server['uid'] = 9001
#web_server['gid'] = 9001
#registry['uid'] = 9002
#registry['gid'] = 9002

  3. 如果您正在使用带有 TLS 支持的 Gitaly，请确保 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. 运行 sudo gitlab-rake gitlab:gitaly:check 以确认节点可以连接到 Gitaly。

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

    sudo gitlab-ctl tail gitaly

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

    sudo gitlab-ctl status

    输出应类似于以下内容： 

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

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

极狐GitLab Rails 后配置

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

    gitlab-rake gitlab:db:configure

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

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

配置 Prometheus

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

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

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

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

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

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

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

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

    sudo gitlab-ctl status

    输出应类似于以下内容： 

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

配置对象存储

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

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

以下示例在可用时使用统一形式。

对于每种数据类型使用单独的存储桶是极狐GitLab 的推荐方法。这可以确保极狐GitLab 存储的各种类型数据之间没有冲突。未来计划启用使用单个存储桶。

启用增量日志记录

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

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

配置高级搜索

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

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

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

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

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

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

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

note这是一个高级设置。在 Kubernetes 中运行服务已被广泛认为是复杂的。只有在您具有丰富的 Kubernetes 工作知识和经验时，才推荐此设置。本节其余部分假定这一点。
cautionGitaly 集群不支持在 Kubernetes 中运行。

集群拓扑

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

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

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

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

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

脚注：

  1. 可以选择在信誉良好的第三方外部 PaaS PostgreSQL 解决方案上运行。有关更多信息，请参阅提供您自己的 PostgreSQL 实例。
  2. 可以选择在信誉良好的第三方外部 PaaS Redis 解决方案上运行。有关更多信息，请参阅提供您自己的 Redis 实例。
  3. 推荐使用信誉良好的第三方负载均衡器或服务（LB PaaS）。大小还取决于所选负载均衡器和其他因素，如网络带宽。有关更多信息，请参阅负载均衡器。
  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 内存（限制）

对于 100 RPS 或 5,000 名用户，我们建议总 Puma 工作进程数约为 36，因此建议至少运行 9 个 Webservice pod。

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

NGINX

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

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

Sidekiq

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

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

与上述标准部署类似，此处使用了初始目标为 8 个 Sidekiq 工作进程。根据您的特定工作流，可能需要额外的工作进程。

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

支持

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

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

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

示例配置文件

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

下一步

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

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

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