参考架构：支持高达 40 RPS 或 2000 名用户

本文档描述了极狐GitLab 的参考架构，旨在支持最高 40 次每秒请求（RPS）的峰值负载，通常对应于高达 2000 名用户的峰值负载，包括手动和自动用户，基于真实数据。

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

服务 节点 配置 GCP AWS Azure
外部负载均衡器3 1 4 vCPU，3.6 GB 内存 n1-highcpu-4 c5n.xlarge F4s v2
PostgreSQL1 1 2 vCPU，7.5 GB 内存 n1-standard-2 m5.large D2s v3
Redis2 1 1 vCPU，3.75 GB 内存 n1-standard-1 m5.large D2s v3
Gitaly5 1 4 vCPU，15 GB 内存5 n1-standard-4 m5.xlarge D4s v3
Sidekiq6 1 4 vCPU，15 GB 内存 n1-standard-4 m5.xlarge D4s v3
极狐GitLab Rails6 2 8 vCPU，7.2 GB 内存 n1-highcpu-8 c5.2xlarge F8s v2
监控节点 1 2 vCPU，1.8 GB 内存 n1-highcpu-2 c5.large F2s v2
对象存储4 - - - - -

脚注：

  1. 可以选择运行在知名第三方的外部 PaaS PostgreSQL 解决方案上。有关更多信息，请参阅提供您自己的 PostgreSQL 实例和推荐的云提供商和服务。
  2. 可以选择运行在知名第三方的外部 PaaS Redis 解决方案上。有关更多信息，请参阅提供您自己的 Redis 实例和推荐的云提供商和服务。
  3. 建议与知名的第三方负载均衡器或服务（LB PaaS）一起运行。大小取决于所选负载均衡器和其他因素，例如网络带宽。有关更多信息，请参阅负载均衡器。
  4. 应该运行在知名的云提供商或私有化部署解决方案上。有关更多信息，请参阅配置对象存储。
  5. Gitaly 规格基于正常大小的存储库的使用情况。然而，如果您有大型 monorepos（大于几 GB），这可能会显著影响 Git 和 Gitaly 性能，并且可能需要增加规格。有关更多信息，请参阅大型 monorepos。
  6. 可以放置在自动伸缩组（ASGs）中，因为该组件不存储任何有状态数据。然而，云原生混合设置通常更受欢迎，因为某些组件如 migrations 和 Mailroom 只能在一个节点上运行，这在 Kubernetes 中处理得更好。
note 对于涉及配置实例的所有 PaaS 解决方案，建议在多个可用区上部署它们以获得所需的弹性。

要求

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

测试方法

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

  • API：40 RPS
  • Web：4 RPS
  • Git（Pull）：4 RPS
  • Git（Push）：1 RPS

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

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

测试是通过使用我们的极狐GitLab 性能工具（GPT）及其数据集定期进行的，任何人都可以使用。有关我们的测试策略的更多信息，请参考文档的这一部分。

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

设置组件

为了设置极狐GitLab 及其组件以支持高达 40 RPS 或 2000 名用户：

  1. 配置外部负载均衡节点以处理极狐GitLab 应用服务节点的负载均衡。
  2. 配置 PostgreSQL，极狐GitLab 的数据库。
  3. 配置 Redis，用于存储会话数据、临时缓存信息和后台作业队列。
  4. 配置 Gitaly，用于访问 Git 存储库。
  5. 配置 Sidekiq以进行后台作业处理。
  6. 配置主要的极狐GitLab Rails 应用以运行 Puma、Workhorse、极狐GitLab Shell，并处理所有前端请求（包括 UI、API 和 Git over HTTP/SSH）。
  7. 配置 Prometheus以监控您的极狐GitLab 环境。
  8. 配置用于共享数据对象的对象存储。
  9. 配置高级搜索（可选），用于更快、更高级的整个极狐GitLab 实例代码搜索。

配置外部负载均衡器

在多节点极狐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)：当使用 HTTPS 协议用于端口 443 时，您需要向负载均衡器添加 SSL 证书。如果您希望在极狐GitLab 应用服务器而不是负载均衡器终止 SSL，请使用 TCP 协议。

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

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

备用 SSH 端口

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

为备用 SSH 主机名（如 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 文档。

配置 PostgreSQL

在本节中，您将学习如何配置一个外部 PostgreSQL 数据库以与极狐GitLab 一起使用。

提供您自己的 PostgreSQL 实例

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

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

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

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

  1. HA Linux 软件包 PostgreSQL 设置涵盖 PostgreSQL、PgBouncer 和 Consul。使用第三方外部服务时，这些组件都不再需要。
  2. 根据数据库要求文档设置 PostgreSQL。
  3. 设置带有您选择的密码的 gitlab 用户名。gitlab 用户需要权限来创建 gitlabhq_production 数据库。
  4. 使用适当的详细信息配置极狐GitLab 应用服务器。本步骤在配置极狐GitLab Rails 应用中介绍。

使用 Linux 软件包的独立 PostgreSQL

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

  3. 为 PostgreSQL 生成密码哈希。这假设您将使用默认用户名 gitlab（推荐）。该命令将请求密码和确认。在下一步中使用此命令输出的值作为 POSTGRESQL_PASSWORD_HASH 的值。

    sudo gitlab-ctl pg-password-md5 gitlab

  4. 编辑 /etc/gitlab/gitlab.rb 并添加以下内容，适当更新占位符值。

    • POSTGRESQL_PASSWORD_HASH - 上一步的输出值
    • APPLICATION_SERVER_IP_BLOCKS - 连接数据库的极狐GitLab Rails 和 Sidekiq 服务器的 IP 子网或 IP 地址的空格分隔列表。示例：%w(123.123.123.123/32 123.123.123.234/32) 
    # 禁用除 PostgreSQL 相关组件以外的所有组件
roles(['postgres_role'])

# 设置用于监控的导出器将监听的网络地址
node_exporter['listen_address'] = '0.0.0.0:9100'
postgres_exporter['listen_address'] = '0.0.0.0:9187'
postgres_exporter['dbname'] = 'gitlabhq_production'
postgres_exporter['password'] = 'POSTGRESQL_PASSWORD_HASH'

# 设置 PostgreSQL 地址和端口
postgresql['listen_address'] = '0.0.0.0'
postgresql['port'] = 5432

# 将 POSTGRESQL_PASSWORD_HASH 替换为生成的 md5 值
postgresql['sql_user_password'] = 'POSTGRESQL_PASSWORD_HASH'

# 将 APPLICATION_SERVER_IP_BLOCK 替换为应用节点的 CIDR 地址
postgresql['trust_auth_cidr_addresses'] = %w(127.0.0.1/32 APPLICATION_SERVER_IP_BLOCK)

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

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

  6. 重新配置极狐GitLab以使更改生效。
  7. 记录 PostgreSQL 节点的 IP 地址或主机名、端口和明文密码。这些详细信息将在稍后配置极狐GitLab 应用服务器时需要。

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

配置 Redis

在本节中，您将学习如何配置一个外部 Redis 实例以与极狐GitLab 一起使用。

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

提供您自己的 Redis 实例

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

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

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

使用 Linux 软件包的独立 Redis

Linux 软件包可用于配置独立的 Redis 服务器。以下步骤是配置 Redis 服务器所需的最低限度步骤：

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

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

    ## 启用 Redis
roles(["redis_master_role"])

redis['bind'] = '0.0.0.0'
redis['port'] = 6379
redis['password'] = 'SECRET_PASSWORD_HERE'

# 设置用于监控的导出器将监听的网络地址
node_exporter['listen_address'] = '0.0.0.0:9100'
redis_exporter['listen_address'] = '0.0.0.0:9121'
redis_exporter['flags'] = {
      'redis.addr' => 'redis://0.0.0.0:6379',
      'redis.password' => 'SECRET_PASSWORD_HERE',
}

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

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

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

  6. 记录 Redis 节点的 IP 地址或主机名、端口和 Redis 密码。这些将在稍后配置极狐GitLab 应用服务器时需要。

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

配置 Gitaly

Gitaly 服务器节点要求取决于数据大小，特别是项目数量及其大小。

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

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

请务必注意以下事项：

  • 极狐GitLab Rails 应用将存储库分片到存储库存储路径。
  • 一个 Gitaly 服务器可以托管一个或多个存储路径。
  • 一个极狐GitLab 服务器可以使用一个或多个 Gitaly 服务器节点。
  • 必须指定 Gitaly 地址，以便所有 Gitaly 客户端可以正确解析。
  • Gitaly 服务器不应公开暴露在互联网上，因为 Gitaly 上的网络流量默认是未加密的。强烈建议使用防火墙限制对 Gitaly 服务器的访问。另一个选项是使用 TLS。
note Gitaly 文档中提到的令牌是由管理员选择的任意密码。此令牌与为极狐GitLab API 或其他类似 Web API 生成的令牌无关。

以下步骤描述了如何配置一个名为 gitaly1.internal 的单个 Gitaly 服务器，使用秘密令牌 gitalysecret。我们假设您的极狐GitLab 安装具有两个存储库存储：default 和 storage1。

要配置 Gitaly 服务器，请在您要用作 Gitaly 的服务器节点上执行以下操作：

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

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

    note 您不能从 gitaly['configuration'][:storage] 中删除 default 条目，因为极狐GitLab 需要它。
    # 避免在 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

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

gitaly['configuration'] = {
   # ...
   #
   # 使 Gitaly 接受所有网络接口上的连接。您必须使用防火墙限制对此地址/端口的访问。
   # 如果您只想支持 TLS 连接，请注释掉以下行
   listen_addr: '0.0.0.0:8075',
   prometheus_listen_addr: '0.0.0.0:9236',
   # Gitaly 认证令牌
   # 应与 praefect_internal_token 相同
   auth: {
      # ...
      #
      # Gitaly 的认证令牌用于认证对 Gitaly 的 gRPC 请求。必须与极狐GitLab Rails 应用设置中的相应值匹配。
      token: 'gitalysecret',
   },
   # Gitaly Pack-objects 缓存
   # 推荐启用以提高性能，但可能显著增加磁盘 I/O
   # 有关更多信息，请参阅 https://docs.gitlab.com/ee/administration/gitaly/configure_gitaly.html#pack-objects-cache
   pack_objects_cache: {
      # ...
      enabled: true,
   },
   storage: [
      {
         name: 'default',
         path: '/var/opt/gitlab/git-data',
      },
      {
         name: 'storage1',
         path: '/mnt/gitlab/git-data',
      },
   ],
}

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

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

  5. 确认 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。

Gitaly TLS 支持

Gitaly 支持 TLS 加密。要与监听安全连接的 Gitaly 实例通信，您必须在极狐GitLab 配置中使用 tls:// URL 方案作为相应存储条目的 gitaly_address。

您必须自带证书，因为这不是自动提供的。证书或其证书颁发机构必须安装在所有 Gitaly 节点（包括使用证书的 Gitaly 节点）和所有与其通信的客户端节点上，按照极狐GitLab 自定义证书配置中描述的过程。

note 自签名证书必须指定您用来访问 Gitaly 服务器的地址。如果您通过主机名访问 Gitaly 服务器，请将其添加为主题备用名称。如果您通过其 IP 地址访问 Gitaly 服务器，您必须将其添加为证书的主题备用名称。

可以同时配置 Gitaly 服务器具有未加密的监听地址 (listen_addr) 和加密的监听地址 (tls_listen_addr)。如果需要，这允许逐步从未加密流量过渡到加密流量。

要使用 TLS 配置 Gitaly：

  1. 创建 /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

  2. 将证书复制到 /etc/gitlab/trusted-certs 以便 Gitaly 在调用自身时信任该证书：

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

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

    gitaly['configuration'] = {
   # ...
   tls_listen_addr: '0.0.0.0:9999',
   tls: {
      certificate_path: '/etc/gitlab/ssl/cert.pem',
      key_path: '/etc/gitlab/ssl/key.pem',
   },
}
  4. 删除 gitaly['listen_addr'] 以仅允许加密连接。
  5. 保存文件并重新配置极狐GitLab。

配置 Sidekiq

Sidekiq 需要连接到 Redis、PostgreSQL 和 Gitaly 实例。还需要连接到对象存储，这是推荐的。

note 如果您发现环境的 Sidekiq 作业处理速度较慢且队列较长，您可以相应地进行扩展。有关更多信息，请参阅扩展文档。
note 在配置额外的极狐GitLab 功能（如容器注册表、SAML 或 LDAP）时，除了 Rails 配置外，还需要更新 Sidekiq 配置。有关更多信息，请参阅外部 Sidekiq 文档。

要配置 Sidekiq 服务器，请在您要用于 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://docs.gitlab.com/omnibus/roles/#sidekiq-roles
roles(["sidekiq_role"])

# 外部 URL
external_url 'https://gitlab.example.com'

## Redis 连接详细信息
gitlab_rails['redis_port'] = '6379'
gitlab_rails['redis_host'] = '10.1.0.6' # Redis 服务器的 IP/主机名
gitlab_rails['redis_password'] = 'Redis 密码'

# Gitaly 和极狐GitLab 使用两个共享密钥进行身份验证，一个用于验证到 Gitaly 的 gRPC 请求，另一个存储在 /etc/gitlab/gitlab-secrets.json 中，用于从极狐GitLab-Shell 到极狐GitLab 内部 API 的回调验证。
# 以下内容必须与 Gitaly 设置中的相应值相同
gitlab_rails['gitaly_token'] = 'gitalysecret'

git_data_dirs({
  'default' => { 'gitaly_address' => 'tcp://gitaly1.internal:8075' },
  'storage1' => { 'gitaly_address' => 'tcp://gitaly1.internal:8075' },
  'storage2' => { 'gitaly_address' => 'tcp://gitaly2.internal:8075' },
})

## PostgreSQL 连接详细信息
gitlab_rails['db_adapter'] = 'postgresql'
gitlab_rails['db_encoding'] = 'unicode'
gitlab_rails['db_host'] = '10.1.0.5' # 数据库服务器的 IP/主机名
gitlab_rails['db_password'] = '数据库密码'

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

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

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

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

# 对象存储
## 这是在 GCP 上配置对象存储的示例
## 根据需要替换为您选择的对象存储提供商的配置
gitlab_rails['object_store']['enabled'] = true
gitlab_rails['object_store']['connection'] = {
  'provider' => 'Google',
  'google_project' => '<gcp-project-name>',
  'google_json_key_location' => '<path-to-gcp-service-account-key>'
}
gitlab_rails['object_store']['objects']['artifacts']['bucket'] = "<gcp-artifacts-bucket-name>"
gitlab_rails['object_store']['objects']['external_diffs']['bucket'] = "<gcp-external-diffs-bucket-name>"
gitlab_rails['object_store']['objects']['lfs']['bucket'] = "<gcp-lfs-bucket-name>"
gitlab_rails['object_store']['objects']['uploads']['bucket'] = "<gcp-uploads-bucket-name>"
gitlab_rails['object_store']['objects']['packages']['bucket'] = "<gcp-packages-bucket-name>"
gitlab_rails['object_store']['objects']['dependency_proxy']['bucket'] = "<gcp-dependency-proxy-bucket-name>"
gitlab_rails['object_store']['objects']['terraform_state']['bucket'] = "<gcp-terraform-state-bucket-name>"

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

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

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

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

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

    只有一个指定的节点应处理迁移，如极狐GitLab Rails 后配置部分所述。

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

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

    sudo gitlab-ctl status

    输出应类似于以下内容：

    run: logrotate: (pid 192292) 2990s; run: log: (pid 26374) 93048s
run: node-exporter: (pid 26864) 92997s; run: log: (pid 26446) 93036s
run: sidekiq: (pid 26870) 92996s; run: log: (pid 26391) 93042s

配置极狐GitLab Rails

本节描述了如何配置极狐GitLab 应用（Rails）组件。

在我们的架构中，我们使用 Puma 网络服务器运行每个极狐GitLab Rails 节点，并将其工作线程数量设置为可用 CPU 的 90%，每个工作线程四个线程。对于与其他组件一起运行 Rails 的节点，工作线程值应相应减少。我们已经确定 50% 的工作线程值实现了良好的平衡，但这取决于工作负载。

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

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

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

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

# Gitaly and GitLab use two shared secrets for authentication, one to authenticate gRPC requests
# to Gitaly, and a second stored in /etc/gitlab/gitlab-secrets.json for authentication callbacks from GitLab-Shell to the GitLab internal API.
# The following must be the same as their respective values
# of the Gitaly setup
gitlab_rails['gitaly_token'] = 'gitalysecret'

git_data_dirs({
  'default' => { 'gitaly_address' => 'tcp://gitaly1.internal:8075' },
  'storage1' => { 'gitaly_address' => 'tcp://gitaly1.internal:8075' },
  'storage2' => { 'gitaly_address' => 'tcp://gitaly2.internal:8075' },
})

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

## PostgreSQL connection details
gitlab_rails['db_adapter'] = 'postgresql'
gitlab_rails['db_encoding'] = 'unicode'
gitlab_rails['db_host'] = '10.1.0.5' # IP/hostname of database server
gitlab_rails['db_password'] = 'DB password'

## Redis connection details
gitlab_rails['redis_port'] = '6379'
gitlab_rails['redis_host'] = '10.1.0.6' # IP/hostname of Redis server
gitlab_rails['redis_password'] = 'Redis Password'

# 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. Replace placeholder `monitoring.gitlab.example.com` with
# the address and/or subnets gathered from the monitoring node
gitlab_rails['monitoring_whitelist'] = ['<MONITOR NODE IP>/32', '127.0.0.0/8']
nginx['status']['options']['allow'] = ['<MONITOR NODE IP>/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>'
}

## 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. 如果您使用的是 Gitaly with TLS support，请确保 git_data_dirs 项是用 tls 而不是 tcp 进行配置：

    git_data_dirs({
  'default' => { 'gitaly_address' => 'tls://gitaly1.internal:9999' },
  'storage1' => { 'gitaly_address' => 'tls://gitaly1.internal:9999' },
  'storage2' => { 'gitaly_address' => 'tls://gitaly2.internal:9999' },
})

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

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

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

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

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

    只有一个指定的节点应处理迁移，如极狐GitLab Rails 后配置部分所述。

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

  8. 运行 sudo gitlab-rake gitlab:gitaly:check 以确认节点可以连接到 Gitaly。

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

    sudo gitlab-ctl tail gitaly

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

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

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

    roles(['monitoring_role'])
nginx['enable'] = false

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

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

  4. Prometheus 还需要一些抓取配置来从我们配置了导出程序的各个节点中获取所有数据。假设您的节点 IP 是：

    1.1.1.1: postgres
1.1.1.2: redis
1.1.1.3: gitaly1
1.1.1.4: rails1
1.1.1.5: rails2
1.1.1.6: sidekiq

    将以下内容添加到 /etc/gitlab/gitlab.rb：

    prometheus['scrape_configs'] = [
  {
     'job_name': 'postgres',
     'static_configs' => [
     'targets' => ['1.1.1.1:9187'],
     ],
  },
  {
     'job_name': 'redis',
     'static_configs' => [
     'targets' => ['1.1.1.2:9121'],
     ],
  },
  {
     'job_name': 'gitaly',
     'static_configs' => [
     'targets' => ['1.1.1.3:9236'],
     ],
  },
  {
     'job_name': 'gitlab-nginx',
     'static_configs' => [
     'targets' => ['1.1.1.4:8060', '1.1.1.5:8060'],
     ],
  },
  {
     'job_name': 'gitlab-workhorse',
     'static_configs' => [
     'targets' => ['1.1.1.4:9229', '1.1.1.5:9229'],
     ],
  },
  {
     'job_name': 'gitlab-rails',
     'metrics_path': '/-/metrics',
     'static_configs' => [
     'targets' => ['1.1.1.4:8080', '1.1.1.5:8080'],
     ],
  },
  {
     'job_name': 'gitlab-sidekiq',
     'static_configs' => [
     'targets' => ['1.1.1.6:8082'],
     ],
  },
  {
     'job_name': 'static-node',
     'static_configs' => [
     'targets' => ['1.1.1.1:9100', '1.1.1.2:9100', '1.1.1.3:9100', '1.1.1.4:9100', '1.1.1.5:9100', '1.1.1.6:9100'],
     ],
  },
]
  5. 保存文件并重新配置极狐GitLab。

配置对象存储

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

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

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

为每种数据类型使用单独的存储桶是极狐GitLab 推荐的方法。这确保了极狐GitLab 存储的各种数据类型之间不会发生冲突。未来计划启用使用单个存储桶。

启用增量日志记录

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

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

配置高级搜索

详情： 等级： 专业版，旗舰版 提供： 私有化部署

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

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

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

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

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

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

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

NOTE： 这是一个高级设置。在 Kubernetes 中运行服务是众所周知的复杂。仅当您具备扎实的 Kubernetes 知识和经验时，才推荐使用此设置。 本节的其余部分假定这一点。

NOTE： 2000 参考架构不是高可用设置。要实现 HA，您可以遵循修改后的 3K 或 60 RPS 参考架构。

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

集群拓扑

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

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

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

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

服务 节点 配置 GCP AWS
PostgreSQL1 1 2 vCPU, 7.5 GB 内存 n1-standard-2 m5.large
Redis2 1 1 vCPU, 3.75 GB 内存 n1-standard-1 m5.large
Gitaly 1 4 vCPU, 15 GB 内存 n1-standard-4 m5.xlarge
对象存储3 - - - -

脚注：

  1. 可以选择在声誉良好的第三方外部 PaaS PostgreSQL 解决方案上运行。请参阅 提供您自己的 PostgreSQL 实例 和 推荐的云提供商和服务 以获取更多信息。
  2. 可以选择在声誉良好的第三方外部 PaaS Redis 解决方案上运行。请参阅 提供您自己的 Redis 实例 和 推荐的云提供商和服务 以获取更多信息。
  3. 应在声誉良好的云提供商或私有化部署解决方案上运行。请参阅 配置对象存储 以获取更多信息。

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

Kubernetes 组件目标

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

Webservice

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

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

对于 40 RPS 或 2000 用户，我们建议总 Puma 工作进程数约为 12，因此建议至少运行 3 个 Webservice pod。

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

NGINX

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

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

Sidekiq

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

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

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

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

支持

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

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

如果您希望进行任何其他部署，例如容器注册表、页面或监控，建议将这些部署在此池中，而不是在 Webservice 或 Sidekiq 池中，因为支持池专门设计用于容纳多个附加部署。但是，如果您的部署不符合给定池，您可以相应地增加节点池。相反，如果在您的用例中池过度配置，您可以相应地减少。

示例配置文件

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

下一步

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

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

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