极狐 GitLab

使用极狐GitLab Geo 配置极狐GitLab chart

极狐GitLab Geo 提供了地理分布式应用程序部署的能力。

虽然可以使用外部数据库服务，但这些文档重点介绍了使用 Linux 软件包 为 PostgreSQL 提供最平台无关的指南，并利用 gitlab-ctl 中包含的自动化功能。

在本指南中，两个集群具有相同的外部 URL。此功能自版本 7.3 起由图表支持。请参阅为 Geo 站点设置统一的 URL。您可以选择为次要站点配置单独的 URL。

有关已知问题，请参阅 Geo 文档。

请参阅 [定义术语](https://gitlab.cn/docs/jh/administration/geo/glossary/) 以描述 Geo 的所有方面（主要是 `site` 和 `node` 之间的区别）。

要求#

要将极狐GitLab Geo 与极狐GitLab Helm chart 一起使用，必须满足以下要求：

  • 使用 外部 PostgreSQL 服务，因为 chart 中包含的 PostgreSQL 未向外部网络公开，并且没有复制所需的 WAL 支持。
  • 提供的数据库必须：
    • 支持复制。
    • 主数据库必须可以被主站点和所有次要数据库节点（用于复制）访问。
    • 次要数据库只需要可以被次要站点访问。
    • 支持主数据库节点和次要数据库节点之间的 SSL。
  • 主站点必须能够通过 HTTP(S) 被所有次要站点访问。次要站点必须能够通过 HTTP(S) 被主站点访问。
  • 有关完整的要求列表，请参阅 运行 Geo 的要求。

概述#

本指南使用通过 Linux 软件包创建的 2 个数据库节点，仅配置所需的 PostgreSQL 服务和 2 个极狐GitLab Helm chart 的部署。这是一个 最小 的所需配置。此文档不包括从应用程序到数据库的 SSL、其他数据库提供程序的支持或将次要站点提升为主站点。

下面的步骤应按顺序进行：

  1. 设置 Linux 软件包数据库节点
  2. 设置 Kubernetes 集群
  3. 收集信息
  4. 配置主数据库
  5. 部署 chart 作为 Geo 主站点
  6. 设置 Geo 主站点
  7. 配置次要数据库
  8. 从主站点复制密钥到次要站点
  9. 部署 chart 作为 Geo 次要站点
  10. 通过主站点添加次要 Geo 站点
  11. 确认操作状态
  12. 为次要站点配置单独的 URL（可选）
  13. 仓库
  14. Cert-manager 和统一 URL

设置 Linux 软件包数据库节点#

在此过程中，需要两个节点。一个是主数据库节点，另一个是次要数据库节点。您可以使用任何机器基础设施提供商，无论是本地还是来自云提供商。

请注意，需要进行通信：

  • 在两个数据库节点之间进行复制。
  • 在每个数据库节点和各自的 Kubernetes 部署之间：
    • 主节点需要暴露 TCP 端口 5432。
    • 次要节点需要暴露 TCP 端口 5432 和 5431。

安装 Linux 软件包支持的操作系统，然后安装 Linux 软件包。安装时不要提供 EXTERNAL_URL 环境变量，因为我们将在重新配置软件包之前提供一个最小的配置文件。

在您安装了操作系统和极狐GitLab 软件包后，可以为将要使用的服务创建配置。在我们这样做之前，必须收集信息。

设置 Kubernetes 集群#

在此过程中，应使用两个 Kubernetes 集群。可以来自任何提供商，无论是本地还是来自云提供商。

请注意，需要进行通信：

  • 与各自的数据库节点：
    • 主节点出站到 TCP 5432。
    • 次要节点出站到 TCP 5432 和 5431。
  • 通过 HTTPS 在两个 Kubernetes Ingress 之间。

每个配置的集群应具有：

  • 足够的资源以支持这些图表的基础安装。
  • 访问持久存储：

收集信息#

要继续配置，需要从各种来源收集以下信息。收集这些信息，并在使用过程中记录在案。

  • 主数据库：
    • IP 地址
    • 主机名（可选）
  • 次要数据库：
    • IP 地址
    • 主机名（可选）
  • 主集群：
    • 外部 URL
    • 内部 URL
    • 节点的 IP 地址
  • 次要集群：
    • 内部 URL
    • 节点的 IP 地址
  • 数据库密码（必须预先决定密码）：
    • gitlab（用于 postgresql['sql_user_password']，global.psql.password）
    • gitlab_geo（用于 geo_postgresql['sql_user_password']，global.geo.psql.password）
    • gitlab_replicator（需要用于复制）
  • 您的极狐GitLab 许可证文件

每个集群的内部 URL 必须是唯一的，以便所有集群可以向所有其他集群发出请求。例如：

  • 所有集群的外部 URL：https://gitlab.example.com
  • 主集群的内部 URL：https://london.gitlab.example.com
  • 次要集群的内部 URL：https://shanghai.gitlab.example.com

本指南不包括 DNS 设置。

gitlab 和 gitlab_geo 数据库用户密码必须以两种形式存在：裸密码和 PostgreSQL 哈希密码。要获取哈希形式，请在某个 Linux 软件包安装实例上执行以下命令，这将要求您输入和确认密码，然后输出适当的哈希值以供记录。

  1. gitlab-ctl pg-password-md5 gitlab
  2. gitlab-ctl pg-password-md5 gitlab_geo

配置主数据库#

此部分在主 Linux 软件包安装数据库节点上执行。

要配置主数据库节点的 Linux 软件包安装，请参考此示例配置：

ruby
1### Geo Primary
2external_url 'http://gitlab.example.com'
3roles ['geo_primary_role']
4# The unique identifier for the Geo node.
5gitlab_rails['geo_node_name'] = 'London Office'
6gitlab_rails['auto_migrate'] = false
7## turn off everything but the DB
8sidekiq['enable']=false
9puma['enable']=false
10gitlab_workhorse['enable']=false
11nginx['enable']=false
12geo_logcursor['enable']=false
13gitaly['enable']=false
14redis['enable']=false
15gitlab_kas['enable']=false
16prometheus_monitoring['enable'] = false
17## Configure the DB for network
18postgresql['enable'] = true
19postgresql['listen_address'] = '0.0.0.0'
20postgresql['sql_user_password'] = 'gitlab_user_password_hash'
21# !! CAUTION !!
22# This list of CIDR addresses should be customized
23# - primary application deployment
24# - secondary database node(s)
25postgresql['md5_auth_cidr_addresses'] = ['0.0.0.0/0']

我们必须替换几个项目：

  • external_url 必须更新以反映我们主站点的主机名。
  • gitlab_rails['geo_node_name'] 必须替换为站点的唯一名称。请参阅 常见设置 中的名称字段。
  • gitlab_user_password_hash 必须替换为 gitlab 密码的哈希形式。
  • postgresql['md5_auth_cidr_addresses'] 可以更新为 CIDR 表示法中的显式 IP 地址或地址块列表。

md5_auth_cidr_addresses 应采用 [ '127.0.0.1/24', '10.41.0.0/16'] 的形式。将 127.0.0.1 包含在此列表中很重要，因为 Linux 软件包中的自动化使用此列表进行连接。此列表中的地址应包括次要数据库的 IP 地址（而不是主机名）以及主 Kubernetes 集群的所有节点。这可以保留为 ['0.0.0.0/0']，但是 这不是最佳实践。

准备好上述配置后：

  1. 将内容放入 /etc/gitlab/gitlab.rb

  2. 运行 gitlab-ctl reconfigure。如果您在服务未监听 TCP 方面遇到任何问题，请尝试直接使用 gitlab-ctl restart postgresql 重新启动它。

  3. 运行 gitlab-ctl set-replication-password 以设置 gitlab_replicator 用户的密码。

  4. 检索主数据库节点的公共证书，这是次要数据库能够复制所需的（保存此输出）：

    shell
    cat ~gitlab-psql/data/server.crt

部署 chart 作为 Geo 主站点#

此部分在主站点的 Kubernetes 集群上执行。

要将此 chart 部署为 Geo 主站点，请从 此示例配置 开始：

  1. 创建一个包含数据库密码的密钥，以供 chart 使用。将下面的 PASSWORD 替换为 gitlab 数据库用户的密码：

    shell
    kubectl --namespace gitlab create secret generic geo --from-literal=postgresql-password=PASSWORD

  2. 基于 示例配置 创建一个 primary.yaml 文件并更新配置以反映正确的值：

    yaml
    1### Geo Primary
2global:
3  # See docs.gitlab.com/charts/charts/globals
4  # Configure host & domain
5  hosts:
6    domain: example.com
7    # optionally configure a static IP for the default LoadBalancer
8    # externalIP:
9    # optionally configure a static IP for the Geo LoadBalancer
10    # externalGeoIP:
11  # configure DB connection
12  psql:
13    host: geo-1.db.example.com
14    port: 5432
15    password:
16      secret: geo
17      key: postgresql-password
18  # configure geo (primary)
19  geo:
20    nodeName: London Office
21    enabled: true
22    role: primary
23# configure Geo Nginx Controller for internal Geo site traffic
24nginx-ingress-geo:
25  enabled: true
26gitlab:
27  webservice:
28    # Use the Geo NGINX controller.
29    ingress:
30      useGeoClass: true
31    # Configure an Ingress for internal Geo traffic
32    extraIngress:
33      enabled: true
34      hostname: gitlab.london.example.com
35# External DB, disable
36postgresql:
37  install: false

  3. 使用此配置部署 chart：

    shell
    helm upgrade --install gitlab-geo gitlab/gitlab --namespace gitlab -f primary.yaml
    假设您正在使用 `gitlab` 命名空间。如果您想使用其他命名空间，您还应该在本文档的其余部分中将其替换为 `--namespace gitlab`。

  4. 等待部署完成，应用程序上线。当应用程序可访问时，登录。

  5. 登录极狐GitLab，并激活您的极狐GitLab 订阅。

    **此步骤是 Geo 功能的必需步骤。**

设置 Geo 主站点#

现在 chart 已部署并上传了许可证，我们可以将其配置为主站点。我们将通过 Toolbox Pod 来完成此操作。

  1. 找到 Toolbox Pod

    shell
    kubectl --namespace gitlab get pods -lapp=toolbox

  2. 使用 kubectl exec 运行 gitlab-rake geo:set_primary_node：

    shell
    kubectl --namespace gitlab exec -ti gitlab-geo-toolbox-XXX -- gitlab-rake geo:set_primary_node

  3. 使用 Rails runner 命令设置主站点的内部 URL。将 https://primary.gitlab.example.com 替换为实际的内部 URL：

    shell
    kubectl --namespace gitlab exec -ti gitlab-geo-toolbox-XXX -- gitlab-rails runner "GeoNode.primary_node.update!(internal_url: 'https://primary.gitlab.example.com')"

  4. 检查 Geo 配置的状态：

    shell
    kubectl --namespace gitlab exec -ti gitlab-geo-toolbox-XXX -- gitlab-rake gitlab:geo:check

    您应该看到类似于下面的输出：

    plaintext
    1WARNING: This version of GitLab depends on gitlab-shell 10.2.0, but you're running Unknown. Please update gitlab-shell.
2Checking Geo ...
3
4GitLab Geo is available ... yes
5GitLab Geo is enabled ... yes
6GitLab Geo secondary database is correctly configured ... not a secondary node
7Database replication enabled? ... not a secondary node
8Database replication working? ... not a secondary node
9GitLab Geo HTTP(S) connectivity ... not a secondary node
10HTTP/HTTPS repository cloning is enabled ... yes
11Machine clock is synchronized ... Exception: getaddrinfo: Servname not supported for ai_socktype
12Git user has default SSH configuration? ... yes
13OpenSSH configured to use AuthorizedKeysCommand ... no
14  Reason:
15  Cannot find OpenSSH configuration file at: /assets/sshd_config
16  Try fixing it:
17  If you are not using our official docker containers,
18  make sure you have OpenSSH server installed and configured correctly on this system
19  For more information see:
20  doc/administration/operations/fast_ssh_key_lookup.md
21GitLab configured to disable writing to authorized_keys file ... yes
22GitLab configured to store new projects in hashed storage? ... yes
23All projects are in hashed storage? ... yes
24
25Checking Geo ... Finished
    • 不用担心 Exception: getaddrinfo: Servname not supported for ai_socktype，因为 Kubernetes 容器无法访问主机时钟。这是可以的。
    • OpenSSH configured to use AuthorizedKeysCommand ... no 是预期的。此 Rake 任务正在检查本地 SSH 服务器，它实际上存在于 gitlab-shell chart 中，部署在其他地方，并且已适当配置。

配置次要数据库#

此部分在次要 Linux 软件包安装数据库节点上执行。

要配置次要数据库节点的 Linux 软件包安装，请参考此示例配置：

ruby
1### Geo Secondary
2# external_url must match the Primary cluster's external_url
3external_url 'http://gitlab.example.com'
4roles ['geo_secondary_role']
5gitlab_rails['enable'] = true
6# The unique identifier for the Geo node.
7gitlab_rails['geo_node_name'] = 'Shanghai Office'
8gitlab_rails['auto_migrate'] = false
9geo_secondary['auto_migrate'] = false
10## turn off everything but the DB
11sidekiq['enable']=false
12puma['enable']=false
13gitlab_workhorse['enable']=false
14nginx['enable']=false
15geo_logcursor['enable']=false
16gitaly['enable']=false
17redis['enable']=false
18prometheus_monitoring['enable'] = false
19gitlab_kas['enable']=false
20## Configure the DBs for network
21postgresql['enable'] = true
22postgresql['listen_address'] = '0.0.0.0'
23postgresql['sql_user_password'] = 'gitlab_user_password_hash'
24# !! CAUTION !!
25# This list of CIDR addresses should be customized
26# - secondary application deployment
27# - secondary database node(s)
28postgresql['md5_auth_cidr_addresses'] = ['0.0.0.0/0']
29geo_postgresql['listen_address'] = '0.0.0.0'
30geo_postgresql['sql_user_password'] = 'gitlab_geo_user_password_hash'
31# !! CAUTION !!
32# This list of CIDR addresses should be customized
33# - secondary application deployment
34# - secondary database node(s)
35geo_postgresql['md5_auth_cidr_addresses'] = ['0.0.0.0/0']
36gitlab_rails['db_password']='gitlab_user_password'

我们必须替换几个项目：

  • gitlab_rails['geo_node_name'] 必须替换为站点的唯一名称。请参阅 常见设置 中的名称字段。
  • gitlab_user_password_hash 必须替换为 gitlab 密码的哈希形式。
  • postgresql['md5_auth_cidr_addresses'] 应更新为显式 IP 地址或 CIDR 表示法中的地址块列表。
  • gitlab_geo_user_password_hash 必须替换为 gitlab_geo 密码的哈希形式。
  • geo_postgresql['md5_auth_cidr_addresses'] 应更新为显式 IP 地址或 CIDR 表示法中的地址块列表。
  • gitlab_user_password 必须更新，这里用于允许 Linux 软件包自动化 PostgreSQL 配置。

md5_auth_cidr_addresses 应采用 [ '127.0.0.1/24', '10.41.0.0/16'] 的形式。将 127.0.0.1 包含在此列表中很重要，因为 Linux 软件包中的自动化使用此列表进行连接。此列表中的地址应包括次要 Kubernetes 集群的所有节点的 IP 地址。这可以保留为 ['0.0.0.0/0']，但是 这不是最佳实践。

准备好上述配置后：

  1. 检查到 主 站点的 PostgreSQL 节点的 TCP 连接性：

    shell
    openssl s_client -connect <primary_node_ip>:5432 </dev/null

    输出应显示以下内容：

    plaintext
    CONNECTED(00000003)
write:errno=0
    如果此步骤失败，您可能使用了错误的 IP 地址，或者防火墙可能阻止了对服务器的访问。检查 IP 地址，注意区分公共和私有地址，并确保如果存在防火墙，则允许 **次要** PostgreSQL 节点连接到 **主** PostgreSQL 节点的 TCP 端口 5432。

  2. 将内容放入 /etc/gitlab/gitlab.rb

  3. 运行 gitlab-ctl reconfigure。如果您在服务未监听 TCP 方面遇到任何问题，请尝试直接使用 gitlab-ctl restart postgresql 重新启动它。

  4. 将主 PostgreSQL 节点的证书内容从上面放入 primary.crt

  5. 在 次要 PostgreSQL 节点上设置 PostgreSQL TLS 验证：

    安装 primary.crt 文件：

    shell
    1install \
2   -D \
3   -o gitlab-psql \
4   -g gitlab-psql \
5   -m 0400 \
6   -T primary.crt ~gitlab-psql/.postgresql/root.crt

    PostgreSQL 现在仅识别该证书进行 TLS 连接验证。只有具有私钥访问权限的人才能复制该证书，该私钥仅存在于 主 PostgreSQL 节点上。

  6. 测试 gitlab-psql 用户是否可以连接到 主 站点的 PostgreSQL（默认的 Linux 软件包数据库名称为 gitlabhq_production）：

    shell
    1sudo \
2   -u gitlab-psql /opt/gitlab/embedded/bin/psql \
3   --list \
4   -U gitlab_replicator \
5   -d "dbname=gitlabhq_production sslmode=verify-ca" \
6   -W \
7   -h <primary_database_node_ip>

    当提示时输入先前收集的 gitlab_replicator 用户的密码。如果一切正常，您应该会看到 主 PostgreSQL 节点的数据库列表。

    如果无法连接，表示 TLS 配置不正确。确保 主 PostgreSQL 节点上的 ~gitlab-psql/data/server.crt 内容与 次要 PostgreSQL 节点上的 ~gitlab-psql/.postgresql/root.crt 内容匹配。

  7. 复制数据库。将 PRIMARY_DATABASE_HOST 替换为主 PostgreSQL 节点的 IP 或主机名：

    shell
    gitlab-ctl replicate-geo-database --slot-name=geo_2 --host=PRIMARY_DATABASE_HOST --sslmode=verify-ca

  8. 复制完成后，我们必须最后一次重新配置 Linux 软件包，以确保次要 PostgreSQL 节点的 pg_hba.conf 正确：

    shell
    gitlab-ctl reconfigure

从主站点复制密钥到次要站点#

现在将一些密钥从主站点的 Kubernetes 部署复制到次要站点的 Kubernetes 部署：

  • gitlab-geo-gitlab-shell-host-keys
  • gitlab-geo-rails-secret
  • gitlab-geo-registry-secret（如果启用了仓库复制）。

  1. 将您的 kubectl 上下文更改为主站点。

  2. 从主部署中收集这些密钥：

    shell
    kubectl get --namespace gitlab -o yaml secret gitlab-geo-gitlab-shell-host-keys > ssh-host-keys.yaml
kubectl get --namespace gitlab -o yaml secret gitlab-geo-rails-secret > rails-secrets.yaml
kubectl get --namespace gitlab -o yaml secret gitlab-geo-registry-secret > registry-secrets.yaml

  3. 将您的 kubectl 上下文更改为次要站点。

  4. 应用这些密钥：

    shell
    kubectl --namespace gitlab apply -f ssh-host-keys.yaml
kubectl --namespace gitlab apply -f rails-secrets.yaml
kubectl --namespace gitlab apply -f registry-secrets.yaml

接下来，创建一个包含数据库密码的密钥。用适当的值替换下面的密码：

shell
kubectl --namespace gitlab create secret generic geo \
   --from-literal=postgresql-password=gitlab_user_password \
   --from-literal=geo-postgresql-password=gitlab_geo_user_password

部署 chart 作为 Geo 次要站点#

此部分在次要站点的 Kubernetes 集群上执行。

要将此 chart 部署为 Geo 次要站点，请从 此示例配置 开始。

  1. 基于 示例配置 创建一个 secondary.yaml 文件并更新配置以反映正确的值：

    yaml
    1## Geo Secondary
2global:
3  # See docs.gitlab.com/charts/charts/globals
4  # Configure host & domain
5  hosts:
6    domain: shanghai.example.com
7    # use a unified URL (same external URL as the primary site)
8    gitlab:
9      name: gitlab.example.com
10  # configure DB connection
11  psql:
12    host: geo-2.db.example.com
13    port: 5432
14    password:
15      secret: geo
16      key: postgresql-password
17  # configure geo (secondary)
18  geo:
19    enabled: true
20    role: secondary
21    nodeName: Shanghai Office
22    psql:
23      host: geo-2.db.example.com
24      port: 5431
25      password:
26        secret: geo
27        key: geo-postgresql-password
28# Optional for secondary sites: Configure Geo Nginx Controller for internal Geo site traffic.
29# nginx-ingress-geo:
30#   enabled: true
31gitlab:
32  webservice:
33    # Configure a Ingress for internal Geo traffic
34    extraIngress:
35      enabled: true
36      hostname: shanghai.gitlab.example.com
37# External DB, disable
38postgresql:
39  install: false

  2. 使用此配置部署 chart：

    shell
    helm upgrade --install gitlab-geo gitlab/gitlab --namespace gitlab -f secondary.yaml

  3. 等待部署完成，应用程序上线。

通过主站点添加次要 Geo 站点#

现在两个数据库都已配置并应用程序已部署，我们必须告诉主站点次要站点的存在：

  1. 访问 主 站点。
  2. 在左侧边栏底部，选择 管理区域。
  3. 选择 Geo > 添加站点。
  4. 添加 次要 站点。使用完整的极狐GitLab URL 作为 URL。
  5. 输入次要站点的 global.geo.nodeName 的名称。这些值必须始终完全匹配，字符对字符。
  6. 输入内部 URL，例如 https://shanghai.gitlab.example.com。
  7. 可选地选择哪些群组或存储分片应由 次要 站点复制。保留为空以复制所有内容。
  8. 选择 添加节点。

在管理面板中添加 次要 站点后，它会自动开始从 主 站点复制缺失数据。此过程称为“回填”。同时，主 站点开始通知每个 次要 站点的任何更改，以便 次要 站点可以及时复制这些更改。

确认操作状态#

最后一步是通过 Toolbox Pod 在次要站点完全配置后仔细检查 Geo 配置。

  1. 找到 Toolbox Pod：

    shell
    kubectl --namespace gitlab get pods -lapp=toolbox

  2. 使用 kubectl exec 附加到 Pod：

    shell
    kubectl --namespace gitlab exec -ti gitlab-geo-toolbox-XXX -- bash -l

  3. 检查 Geo 配置的状态：

    shell
    gitlab-rake gitlab:geo:check

    您应该看到类似于下面的输出：

    plaintext
    1WARNING: This version of GitLab depends on gitlab-shell 10.2.0, but you're running Unknown. Please update gitlab-shell.
2Checking Geo ...
3
4GitLab Geo is available ... yes
5GitLab Geo is enabled ... yes
6GitLab Geo secondary database is correctly configured ... yes
7Database replication enabled? ... yes
8Database replication working? ... yes
9GitLab Geo HTTP(S) connectivity ...
10* Can connect to the primary node ... yes
11HTTP/HTTPS repository cloning is enabled ... yes
12Machine clock is synchronized ... Exception: getaddrinfo: Servname not supported for ai_socktype
13Git user has default SSH configuration? ... yes
14OpenSSH configured to use AuthorizedKeysCommand ... no
15  Reason:
16  Cannot find OpenSSH configuration file at: /assets/sshd_config
17  Try fixing it:
18  If you are not using our official docker containers,
19  make sure you have OpenSSH server installed and configured correctly on this system
20  For more information see:
21  doc/administration/operations/fast_ssh_key_lookup.md
22GitLab configured to disable writing to authorized_keys file ... yes
23GitLab configured to store new projects in hashed storage? ... yes
24All projects are in hashed storage? ... yes
25
26Checking Geo ... Finished
    • 不用担心 Exception: getaddrinfo: Servname not supported for ai_socktype，因为 Kubernetes 容器无法访问主机时钟。这是可以的。
    • OpenSSH configured to use AuthorizedKeysCommand ... no 是预期的。此 Rake 任务正在检查本地 SSH 服务器，它实际上存在于 gitlab-shell chart 中，部署在其他地方，并且已适当配置。

为次要站点配置单独的 URL（可选）#

对于用户来说，主站点和次要站点的单一、统一 URL 通常更方便。例如，您可以：

  • 将两个站点放置在负载均衡器后面。
  • 使用云提供商的 DNS 功能将用户路由到最近的站点。

在某些情况下，您可能希望让用户控制他们访问哪个站点。为此，您可以将次要 Geo 站点配置为使用唯一的外部 URL。例如：

  • 主集群的外部 URL：https://gitlab.example.com
  • 次要集群的外部 URL：https://shanghai.gitlab.example.com

  1. 编辑 secondary.yaml 并更新次要集群的外部 URL，以便 webservice chart 可以处理这些请求：

    yaml
    1global:
2  # See docs.gitlab.com/charts/charts/globals
3  # Configure host & domain
4  hosts:
5    domain: example.com
6    # use a unique external URL for the secondary site
7    gitlab:
8      name: shanghai.gitlab.example.com

  2. 在极狐GitLab 中更新次要站点的外部 URL，以便可以在需要时使用该 URL：

    • 使用管理员 UI：
      1. 访问 主 站点。
      2. 在左侧边栏底部，选择 管理区域。
      3. 选择 Geo > 站点。
      4. 选择铅笔图标以 编辑次要站点。
      5. 编辑外部 URL，例如 https://shanghai.gitlab.example.com。
      6. 选择 保存更改。

  3. 重新部署次要站点的 chart：

    shell
    helm upgrade --install gitlab-geo gitlab/gitlab --namespace gitlab -f secondary.yaml

  4. 等待部署完成，应用程序上线。

仓库#

要同步次要仓库与主仓库，您可以使用通知密钥配置仓库复制。

Cert-manager 和统一 URL#

Geo 的统一 URL 通常与地理位置感知路由一起使用（例如，使用 Amazon Route 53 或 Google Cloud DNS），如果使用 HTTP01 挑战验证域名是否在您的控制下，这可能会导致问题。

当您为一个 Geo 站点请求证书时，Let's Encrypt 必须将 DNS 名称解析为请求的 Geo 站点。如果 DNS 解析到不同的 Geo 站点，则不会颁发或刷新统一 URL 的证书。

为了可靠地使用 cert-manager 创建和刷新证书，请设置挑战名称服务器，以便服务器已知将统一主机名解析为 Geo 站点 IP 地址，或者配置 DNS01 Issuer。