• 配置新的次要站点
  • 步骤 1. 手动复制 secret GitLab 值
  • 步骤 2. 手动复制主要站点的 SSH 主机密钥
  • 步骤 3. 添加次要站点
  • 步骤 4.（可选）使用自定义证书
    • 入站连接的自定义或自签名证书
    • 连接到使用自定义证书的外部服务
  • 步骤 5. 通过 HTTP/HTTPS 启用 Git 访问
  • 步骤 6. 验证次要站点的正常运行
• 选择性同步
  • 未复制仓库上的 Git 操作
• 升级 Geo
• 故障排除

Geo 配置

配置新的次要站点

确保您设置数据库复制，并且在主要站点和次要站点配置快速查找授权 SSH 密钥。

配置次要站点的基本步骤是：

• 在主要站点和次要站点之间复制所需的配置。
• 在每个次要站点上配置一个跟踪数据库。
• 在每个次要站点上启动极狐GitLab。

我们鼓励您先通读所有步骤，然后再在测试/生产环境中执行它们。

步骤 1. 手动复制 secret GitLab 值

极狐GitLab 在 /etc/gitlab/gitlab-secrets.json 文件中存储了许多 secret 值，这些值在站点的所有节点上必须相同。在有一种方法可以在站点之间自动复制它们之前，必须手动将它们复制到次要站点的所有节点。

1. 通过 SSH 连接到您的主要站点上的 Rails 节点，然后执行以下命令：

   sudo cat /etc/gitlab/gitlab-secrets.json
   

   将以 JSON 格式显示需要复制的 secrets。

2. SSH 进入您的次要 Geo 站点上的每个节点，并以 root 用户身份登录：

   sudo -i
   

3. 备份任何现有的 secrets：

   mv /etc/gitlab/gitlab-secrets.json /etc/gitlab/gitlab-secrets.json.`date +%F`
   

4. 将 /etc/gitlab/gitlab-secrets.json 从主要站点上的 Rails 节点，复制到次要站点上的每个节点，或在节点之间复制并粘贴文件内容：

   sudo editor /etc/gitlab/gitlab-secrets.json
   
   # paste the output of the `cat` command you ran on the primary
   # save and exit
   

5. 确保文件权限正确：

   chown root:root /etc/gitlab/gitlab-secrets.json
   chmod 0600 /etc/gitlab/gitlab-secrets.json
   

6. 重新配置您的次要站点上的每个 Rails、Sidekiq 和 Gitaly 节点，使更改生效：

   gitlab-ctl reconfigure
   gitlab-ctl restart
   

步骤 2. 手动复制主要站点的 SSH 主机密钥

极狐GitLab 与系统安装的 SSH daemon 集成，指定一个用户（通常名为 git），通过该用户处理所有访问请求。

在灾难恢复情况下，极狐GitLab 系统管理员将次要站点提升为主要站点。主域名的 DNS 记录也应更新为指向新的主要站点（以前是次要站点）。这样做可以避免更新 Git 远端和 API URL。

这会导致对新提升的主要站点的所有 SSH 请求由于 SSH 主机密钥不匹配而失败。为防止出现这种情况，必须手动将主 SSH 主机密钥复制到次要站点。

1. 通过 SSH 连接到您的次要站点上的每个节点，并以 root 用户身份登录：

   sudo -i
   

2. 备份任何现有的 SSH 主机密钥：

   find /etc/ssh -iname 'ssh_host_*' -exec cp {} {}.backup.`date +%F` \;
   

3. 从主要站点复制 OpenSSH 主机密钥：

   如果您可以使用 root 用户访问提供 SSH 流量的主要站点上的节点之一（通常是 Rails 应用程序主节点）：

   # Run this from the secondary site, change `<primary_site_fqdn>` for the IP or FQDN of the server
   scp root@<primary_node_fqdn>:/etc/ssh/ssh_host_*_key* /etc/ssh
   

   如果您只能通过具有 sudo 权限的用户访问：

   # Run this from the node on your primary site:
   sudo tar --transform 's/.*\///g' -zcvf ~/geo-host-key.tar.gz /etc/ssh/ssh_host_*_key*
   
   # Run this on each node on your secondary site:
   scp <user_with_sudo>@<primary_site_fqdn>:geo-host-key.tar.gz .
   tar zxvf ~/geo-host-key.tar.gz -C /etc/ssh
   

4. 在您的次要站点上的每个节点上，确保文件权限正确：

   chown root:root /etc/ssh/ssh_host_*_key*
   chmod 0600 /etc/ssh/ssh_host_*_key
   

5. 要验证密钥指纹匹配，请在每个站点的主节点和次要节点上执行以下命令：

   for file in /etc/ssh/ssh_host_*_key; do ssh-keygen -lf $file; done
   

   您应该得到一个类似于这个的输出，并且它们在两个节点上应该是相同的：

   1024 SHA256:FEZX2jQa2bcsd/fn/uxBzxhKdx4Imc4raXrHwsbtP0M root@serverhostname (DSA)
   256 SHA256:uw98R35Uf+fYEQ/UnJD9Br4NXUFPv7JAUln5uHlgSeY root@serverhostname (ECDSA)
   256 SHA256:sqOUWcraZQKd89y/QQv/iynPTOGQxcOTIXU/LsoPmnM root@serverhostname (ED25519)
   2048 SHA256:qwa+rgir2Oy86QI+PZi/QVR+MSmrdrpsuH7YyKknC+s root@serverhostname (RSA)
   

6. 验证您是否拥有现有私钥的正确公钥：

   # This will print the fingerprint for private keys:
   for file in /etc/ssh/ssh_host_*_key; do ssh-keygen -lf $file; done
   
   # This will print the fingerprint for public keys:
   for file in /etc/ssh/ssh_host_*_key.pub; do ssh-keygen -lf $file; done
   

   私钥和公钥命令的输出应生成相同的指纹。

7. 在您的次要站点上的每个节点上重新启动 sshd：

   # Debian or Ubuntu installations
   sudo service ssh reload
   
   # CentOS installations
   sudo service sshd reload
   

8. 验证 SSH 是否仍然有效。

   在新终端中通过 SSH 连接到极狐GitLab 次要服务器。如果无法连接，请根据前面的步骤验证权限是否正确。

步骤 3. 添加次要站点

1. 通过 SSH 连接到您的次要站点上的每个 Rails 和 Sidekiq 节点，并以 root 身份登录：

   sudo -i
   

2. 编辑 /etc/gitlab/gitlab.rb 并为您的站点添加一个独特的名称。您在接下来的步骤中需要它：

   ##
   ## The unique identifier for the Geo site. See
   ## https://docs.gitlab.com/ee/administration/geo_nodes.html#common-settings
   ##
   gitlab_rails['geo_node_name'] = '<site_name_here>'
   

3. 重新配置您的次要站点上的每个 Rails 和 Sidekiq 节点，使更改生效：

   gitlab-ctl reconfigure
   

4. 导航到主节点上的极狐GitLab 实例：
   1. 在左侧边栏上，展开最顶部的向下箭头 (）。
   2. 选择 管理中心。
   3. 在左侧边栏中，选择 Geo > 站点。

   4. 选择 添加站点。

      

   5. 在 /etc/gitlab/gitlab.rb 中使用 gitlab_rails['geo_node_name'] 填写 Name。它们必须始终每个字符完全匹配。
   6. 用 /etc/gitlab/gitlab.rb 中的 external_url 填写 URL。这些值必须始终匹配，但如果一个以 / 结尾而另一个不以 / 结尾，则无关紧要。
   7. 可选。在 内部 URL（可选） 中，输入主站点的内部 URL。
   8. 可选。选择 次要 站点应复制哪些组或存储分片。留空表示复制所有内容。在选择性同步文档中阅读更多内容。
   9. 选择 保存更改，添加 次要 站点。

5. SSH 到您的 次要站点上的每个 Rails 和 Sidekiq 节点，并重新启动服务：

   gitlab-ctl restart
   

   通过运行以下命令检查您的 Geo 设置是否存在任何常见问题：

   gitlab-rake gitlab:geo:check
   

6. 通过 SSH 连接到您的主要站点上的 Rails 或 Sidekiq 服务器，并以 root 身份登录，验证次要站点是否可访问或者您的 Geo 设置存在任何常见问题：

   gitlab-rake gitlab:geo:check
   

添加到 Geo 管理页面并重新启动后，次要站点在称为 backfill 的过程中自动开始从主要站点复制丢失的数据。 同时，主要站点开始通知每个次要站点任何更改，以便次要站点可以立即对这些通知采取行动。

确保次要站点正在运行且可访问。您可以使用与主要站点相同的凭据登录到次要站点。

步骤 4.（可选）使用自定义证书

如果出现以下情况，您可以安全地跳过此步骤：

• 您的主要站点使用公共 CA 颁发的 HTTPS 证书。
• 您的主要站点仅使用 CA 颁发的（非自签名）HTTPS 证书连接到外部服务。

入站连接的自定义或自签名证书

如果您的极狐GitLab Geo 主要站点使用自定义的或自签名证书来保护入站 HTTPS 连接，该证书可以是单域名证书，也可以是多域名证书。

根据您的证书类型安装正确的证书：

• 多域名证书，包括主要站点和次要站点域名：在次要站点中的所有 Rails、Sidekiq 和 Gitaly 节点上的 /etc/gitlab/ssl 安装证书。
• 单域名证书，其中证书特定于每个 Geo 站点域名：为您的次要站点的域名生成一个有效证书，并按照这些说明在次要站点中的所有 Rails、Sidekiq 和 Gitaly 节点上将其安装到 /etc/gitlab/ssl。

连接到使用自定义证书的外部服务

需要将外部服务的自签名证书副本添加到需要访问服务的所有主要站点节点上的信任库中。

为了让次要站点能够访问相同的外部服务，这些证书必须添加到次要站点的信任库中。

如果您的主要站点使用自定义或自签名证书用于入站 HTTPS 连接，则主要站点的证书需要添加到次要站点的信任库：

1. SSH 到您的次要站点上的每个 Rails、Sidekiq 和 Gitaly 节点，并以 root 身份登录：

   sudo -i
   

2. 从主要站点复制受信任的证书：

   如果您可以使用 root 用户访问主要站点上提供 SSH 流量的节点之一：

   scp root@<primary_site_node_fqdn>:/etc/gitlab/trusted-certs/* /etc/gitlab/trusted-certs
   

   如果您只能通过具有 sudo 权限的用户进行访问：

   # Run this from the node on your primary site:
   sudo tar --transform 's/.*\///g' -zcvf ~/geo-trusted-certs.tar.gz /etc/gitlab/trusted-certs/*
   
   # Run this on each node on your secondary site:
   scp <user_with_sudo>@<primary_site_node_fqdn>:geo-trusted-certs.tar.gz .
   tar zxvf ~/geo-trusted-certs.tar.gz -C /etc/gitlab/trusted-certs
   

3. 在您的次要站点中重新配置每个更新的 Rails、Sidekiq 和 Gitaly 节点：

   sudo gitlab-ctl reconfigure
   

步骤 5. 通过 HTTP/HTTPS 启用 Git 访问

Geo 通过 HTTP/HTTPS 同步仓库，因此需要启用此克隆方法。默认情况下启用此功能，但如果将现有站点转换为 Geo，则应检查：

在主要站点上：

1. 在左侧边栏上，展开最顶部的向下箭头 (）。
2. 选择 管理中心。
3. 在左侧边栏中，选择 设置 > 通用。
4. 展开 可见性和访问控制。
5. 如果使用 Git over SSH：
   1. 确保 启用 Git 访问协议 设置为 SSH 和 HTTP(S)。
   2. 在 所有主要站点和次要站点 上，遵循在数据库中快速查找授权的 SSH 密钥。
6. 如果不使用 Git over SSH，将 启用 Git 访问协议 设置为 仅 HTTP(S)。

步骤 6. 验证次要站点的正常运行

您可以使用与主要站点相同的凭据登录到次要站点。登录后：

1. 在左侧边栏上，展开最顶部的向下箭头 (）。
2. 选择 管理中心。
3. 在左侧边栏中，选择 Geo > 站点。
4. 验证它是否被正确识别为次要 Geo 站点，并且 Geo 已启用。

初始复制可能需要一些时间。网站的状态或 ‘backfill’ 可能仍在进行中。您可以从浏览器中的主要站点的 Geo 站点仪表盘监控每个 Geo 站点上的同步过程。

如果您的安装无法正常工作，请查看故障排除文档。

仪表盘中最明显的两个问题是：

1. 数据库复制不能正常工作。
2. 实例到实例通知不起作用。在这种情况下，可以是以下内容：
   • 您正在使用自定义证书或自定义 CA（请参阅故障排除文档）。
   • 该实例有防火墙（检查您的防火墙规则）。

禁用次要站点会停止同步过程。

如果在主要站点上为多个仓库分片自定义了 git_data_dirs，您必须在每个次要站点上复制相同的配置。

目前，以下是同步的：

• Git 仓库。
• Wikis。
• LFS 对象。
• 议题、合并请求、代码片段和评论附件。
• 用户、群组和项目头像。

选择性同步

Geo 支持选择性同步，这允许管理员选择应该由次要站点同步哪些项目。 可以按组或存储分片选择项目的子集。前者非常适合复制属于用户子集的数据，而后者更适合将 Geo 逐步推广到大型极狐GitLab 实例。

需要注意的是选择性同步：

1. 不限制来自次要站点的权限。
2. 不隐藏次要站点的项目元数据。
   • 由于 Geo 当前依赖 PostgreSQL 复制，所有项目元数据都被复制到次要站点，但尚未选择的仓库是空的。
3. 不会减少为 Geo 事件日志生成的事件数量。
   • 只要存在任何次要站点，主要站点就会生成事件。选择性同步限制是在次要站点上实现的，而不是在主要站点上。

未复制仓库上的 Git 操作

对于存在于主要站点但不存在于次要站点上的仓库，支持通过 HTTP(S) 和 SSH 进行 Git 克隆、拉取和推送操作。在以下情况，可能会发生这种情况：

• 选择性同步不包括附加到仓库的项目。
• 正在积极复制仓库，但尚未完成。

升级 Geo

请参阅升级 Geo 站点文档。

故障排除

请参阅故障排除文档。