辅助站点的 Geo 代理 - GitLab

Tier: 专业版，旗舰版

Offering: 私有化部署

版本历史

在 GitLab 14.5 中引入，带有一个功能标志名为 geo_secondary_proxy_separate_urls。默认禁用。
在 JihuLab.com、私有化部署上启用（在 GitLab 15.1）。

此功能的可用性由功能标志控制。更多信息，请查看历史记录。geo_secondary_proxy_separate_urls 功能标志计划在未来版本中弃用并移除。

辅助站点表现为完整的读写极狐GitLab 实例。它们透明地将所有操作代理到主站点，但有一些值得注意的例外。

这种行为支持以下用例：

将所有 Geo 站点置于一个 URL 之后，为用户提供一致、无缝且全面的体验，无论用户落在哪个站点。用户无需处理多个极狐GitLab URL。
对流量进行地理负载均衡，而无需担心写入访问。

有关已知问题，请参阅Geo 文档中的代理相关项。

设置 Geo 站点的统一 URL#

辅助站点可以透明地提供读写流量服务。因此，您可以使用单个外部 URL，使请求能够到达主 Geo 站点或任何辅助 Geo 站点。这为用户提供了一致、无缝且全面的体验，无论他们落在哪个站点。用户无需处理多个 URL，甚至不需要知道多个站点的存在。

您可以通过以下方式将流量路由到 Geo 站点：

基于地理位置的 DNS。将流量路由到最近的 Geo 站点，无论是主站点还是辅助站点。
轮询 DNS。
负载均衡器。它必须使用粘性会话，以避免身份验证失败和跨站点请求错误。DNS 路由本质上是粘性的，因此没有这个注意事项。

配置每个站点使用相同的外部 URL#

在设置了从单个 URL 路由到所有 Geo 站点之后，如果您的站点使用不同的 URL，请按照以下步骤操作：

在每个极狐GitLab 站点上，通过 SSH 连接到运行 Rails (Puma、Sidekiq、Log-Cursor) 的每个节点，并将 external_url 设置为单个 URL：
```
shell
sudo -e /etc/gitlab/gitlab.rb
```
重新配置更新的节点以使更改生效：
```
shell
sudo gitlab-ctl reconfigure
```
为了匹配在辅助 Geo 站点上设置的新外部 URL，主数据库需要反映此更改。

在主站点的 Geo 管理页面中，编辑每个使用辅助代理的 Geo 辅助站点，并将 URL 字段设置为单个 URL。确保主站点也使用此 URL。

为了让站点能够相互通信，请确保 Internal URL 字段对每个站点是唯一的。

在 Kubernetes 中，您可以为辅助站点使用与主站点相同的 global.hosts.domain 域名。

为辅助 Geo 站点设置单独的 URL#

您可以针对站点使用不同的外部 URL。您可以使用这种方式为特定的用户群提供特定的站点。或者，您可以允许用户自己选择使用哪个站点，但他们必须了解其选择的影响。

配置辅助 Geo 站点使用与主站点不同的外部 URL#

如果您的辅助站点当前使用与主站点相同的外部 URL，但您想将其更改为不同的 URL：

在辅助站点上，通过 SSH 连接到运行 Rails (Puma、Sidekiq、Log-Cursor) 的每个节点，并将 external_url 设置为辅助站点所需的 URL：
```
shell
sudo -e /etc/gitlab/gitlab.rb
```
重新配置更新的节点以使更改生效：
```
shell
sudo gitlab-ctl reconfigure
```
为了匹配在辅助 Geo 站点上设置的新外部 URL，主数据库需要反映此更改。

在主站点的 Geo 管理页面中，编辑目标辅助站点，并将 URL 字段设置为所需的 URL。

为了让站点能够相互通信，请确保 Internal URL 字段对每个站点是唯一的。如果所需的 URL 对这个站点是唯一的，那么您可以清除 Internal URL 字段。保存后，它会默认为外部 URL。

主 Geo 站点宕机时辅助站点的行为#

考虑到 Web 流量被代理到主站点，当主站点不可访问时，辅助站点的行为有所不同：

UI 和 API 流量会返回与主站点相同的错误（或者如果主站点完全无法访问则失败），因为它们被代理。
对于在特定辅助站点上完全同步的仓库，Git 读操作仍然正常工作，包括通过 HTTP(s) 或 SSH 进行身份验证。但是，由极狐GitLab Runner 执行的 Git 读取会失败。
对于没有复制到辅助站点的仓库，Git 操作会返回与主站点相同的错误，因为它们被代理。
所有 Git 写操作都会返回与主站点相同的错误，因为它们被代理。

由辅助 Geo 站点加速的功能#

发送到辅助 Geo 站点的大多数 HTTP 流量都会被代理到主 Geo 站点。通过这种架构，辅助 Geo 站点能够支持写请求，并避免读写造成的问题。某些读请求由辅助站点本地处理，以提高附近的延迟和带宽。

下表详细说明了通过 Geo 辅助站点 Workhorse 代理测试的组件。它并未涵盖所有数据类型。

在此上下文中，加速读取是指从辅助站点提供服务的读取请求，前提是该组件的数据在辅助站点上是最新的。如果确定辅助站点上的数据已过时，则请求将被转发到主站点。对于下表中未列出的组件，读取请求始终会自动转发到主站点。

功能/组件	是否加速读取？	备注
Rails 静态资源（JavaScript、CSS、字体、图片）	是	位于 /assets/ 下的资源由 Workhorse 直接从辅助站点的本地文件系统提供，不代理到主站点。无论使用统一 URL 还是单独的 URL，这适用于所有辅助站点。在初始浏览器请求之后，这些资源通常也会被浏览器缓存。
项目、Wiki、设计仓库（使用 Web UI）	否
项目、Wiki 仓库（使用 Git）	是	Git 读取从本地辅助站点提供，推送则被代理到主站点。如果仓库在 Geo 辅助站点上本地不存在（例如由于选择性同步排除），请求将被代理到主站点。
项目、个人片段（使用 Web UI）	否
项目、个人片段（使用 Git）	是	Git 读取从本地辅助站点提供，推送则被代理到主站点。如果仓库在 Geo 辅助站点上本地不存在（例如由于选择性同步排除），请求将被代理到主站点。
群组 Wiki 仓库（使用 Web UI）	否
群组 Wiki 仓库（使用 Git）	是	Git 读取从本地辅助站点提供，推送则被代理到主站点。如果仓库在 Geo 辅助站点上本地不存在（例如由于选择性同步排除），请求将被代理到主站点。
用户上传	否
LFS 对象（使用 Web UI）	否
LFS 对象（使用 Git）	是
Pages	否	Pages 可以使用相同的 URL（无访问控制），但必须单独配置，且不进行代理。
高级搜索（使用 Web UI）	否
容器镜像仓库	否	容器镜像仓库仅推荐用于灾难恢复场景。如果辅助站点的容器镜像仓库不是最新的，读取请求将返回旧数据，因为请求不会转发到主站点。加速容器镜像仓库正在计划中。
Dependency Proxy	否	对 Geo 辅助站点 Dependency Proxy 的读取请求始终被代理到主站点。
所有其他数据	否	此表中未列出的组件的读取请求始终会自动转发到主站点。

要请求加速某项功能，请检查 epic 8239 中是否已存在相关议题，并为其投票或评论以表明您的兴趣，或请您的极狐GitLab 代表代为操作。如果不存在适用的议题，请创建一个，并在史诗中提及。

禁用辅助站点 HTTP 代理#

当辅助站点使用统一 URL 时，辅助站点 HTTP 代理默认启用，即其配置了与主站点相同的 external_url。在这种情况下禁用代理通常帮助不大，因为相同的 URL 会根据路由提供完全不同的行为。当在辅助 Geo 站点上禁用 HTTP 代理时，该站点以只读模式运行，有几个重要的限制需要注意。

如果您禁用辅助代理会发生什么#

禁用代理功能标志有以下一般影响。

HTTP 和 Git 请求#

辅助站点不会将 HTTP 请求代理到主站点。相反，它会尝试自行处理这些请求，或者失败。
Git 请求通常成功。Git 推送会被重定向或代理到主站点。
除了 Git 请求，任何可能写入数据的 HTTP 请求都会失败。读取请求通常成功。

功能/组件	是否会成功	备注
项目、Wiki、设计仓库（使用 Web UI）	可能	读取从本地存储的数据提供。写入会导致错误。
项目、Wiki 仓库（使用 Git）	是	Git 读取从本地存储的数据提供，推送则被代理到主站点。如果仓库在 Geo 辅助站点上本地不存在（例如由于选择性同步排除），则会导致“未找到”错误。
项目、个人片段（使用 Web UI）	可能	读取从本地存储的数据提供。写入会导致错误。
项目、个人片段（使用 Git）	是	Git 读取从本地存储的数据提供，推送则被代理到主站点。如果仓库在 Geo 辅助站点上本地不存在（例如由于选择性同步排除），则会导致“未找到”错误。
群组 Wiki 仓库（使用 Web UI）	可能	读取从本地存储的数据提供。写入会导致错误。
群组 Wiki 仓库（使用 Git）	是	Git 读取从本地存储的数据提供，推送则被代理到主站点。如果仓库在 Geo 辅助站点上本地不存在（例如由于选择性同步排除），则会导致“未找到”错误。
用户上传	可能	上传文件从本地存储的数据提供。在辅助站点上尝试上传文件会导致错误。
LFS 对象（使用 Web UI）	可能	读取从本地存储的数据提供。写入会导致错误。
LFS 对象（使用 Git）	是	LFS 对象从本地存储的数据提供，推送则被代理到主站点。如果 LFS 对象在 Geo 辅助站点上本地不存在（例如由于选择性同步排除），则会导致“未找到”错误。
Pages	可能	Pages 可以使用相同的 URL（无访问控制），但必须单独配置，且不进行代理。
高级搜索（使用 Web UI）	否
容器镜像仓库	否	容器镜像仓库仅推荐用于灾难恢复场景。如果辅助站点的容器镜像仓库不是最新的，读取请求将返回旧数据，因为请求不会转发到主站点。加速容器镜像仓库正在计划中。
Dependency Proxy	否
所有其他数据	可能	读取从本地存储的数据提供。写入会导致错误。

您应该使用功能标志，而不是使用 GEO_SECONDARY_PROXY 环境变量。

即使没有统一 URL，HTTP 代理在 GitLab 15.1 中的辅助站点上默认启用。

服务条款接受#

当代理被禁用时，仅访问辅助站点的用户无法正确接受服务条款或其他法律协议。这会产生以下问题：

没有接受记录：如果员工只登录辅助站点，他们对条款和条件的接受将不会被记录在主数据库中，因为当辅助代理被禁用时，写入操作（包括条款接受）不会被代理，即使他们可能会看到条款消息。
法律合规性问题：如果员工仅通过辅助站点访问模式使用极狐GitLab 服务，组织可能缺乏适当的法律保障，因为没有可验证的记录表明他们同意了条款和条件。

作为一种变通方法，您必须至少访问一次主站点才能正确接受条款和条件。在主站点接受后，此信息将通过正常的 Geo 同步复制到辅助站点。

这一限制影响那些要求记录接受条款和条件以满足合规性或法律目的的组织。确保用户可以访问主站点以进行初始条款接受。

在所有辅助站点上禁用代理#

如果您需要在所有辅助站点上禁用代理，最简单的方法是禁用功能标志：

通过 SSH 连接到主 Geo 站点上运行 Puma 或 Sidekiq 的节点，并运行：

shell
sudo gitlab-rails runner "Feature.disable(:geo_secondary_proxy_separate_urls)"

在辅助 Geo 站点上，重启所有运行 Puma 的节点：
```
shell
sudo gitlab-ctl restart puma
```

要还原更改以重新启用辅助站点代理：

通过 SSH 连接到主 Geo 站点上运行 Puma 或 Sidekiq 的节点，并运行：
```
shell
sudo gitlab-rails runner "Feature.enable(:geo_secondary_proxy_separate_urls)"
```
在辅助 Geo 站点上，重启所有运行 Puma 的节点：
```
shell
sudo gitlab-ctl restart puma
```

按站点禁用辅助站点 HTTP 代理#

如果有多个辅助站点，您可以分别在每个辅助站点上禁用 HTTP 代理，按照以下步骤操作：

通过 SSH 连接到辅助 Geo 站点上的每个应用节点（直接服务用户流量），并添加以下环境变量：
```
shell
sudo -e /etc/gitlab/gitlab.rb
```
```
ruby
gitlab_workhorse['env'] = {
  "GEO_SECONDARY_PROXY" => "0"
}
```
重新配置更新的节点以使更改生效：
```
shell
sudo gitlab-ctl reconfigure
```

您可以使用 --set gitlab.webservice.extraEnv.GEO_SECONDARY_PROXY="0"，或者在您的 values 文件中指定以下内容：

yaml
gitlab:
  webservice:
    extraEnv:
      GEO_SECONDARY_PROXY: "0"

禁用辅助站点 Git 代理#

无法禁用以下转发：

通过 SSH 的 Git 推送
当辅助站点上的 Git 仓库已过时时，通过 SSH 的 Git 拉取
通过 HTTP 的 Git 推送
当辅助站点上的 Git 仓库已过时时，通过 HTTP 的 Git 拉取