- Geo configuration
- Geo configuration
- Configuring a new secondary node
- Step 1. Manually replicate secret GitLab values
- Step 2. Manually replicate the primary node’s SSH host keys
- Step 3. Add the secondary node
- Step 4. Enabling Hashed Storage
- Step 5. (Optional) Configuring the secondary node to trust the primary node
- Step 6. Enable Git access over HTTP/HTTPS
- Step 7. Verify proper functioning of the secondary node
- Selective synchronization
- Upgrading Geo
- Troubleshooting
- Configuring a new secondary node
Geo configuration
原文:https://docs.gitlab.com/ee/administration/geo/replication/configuration.html
- Configuring a new secondary node
- Step 1. Manually replicate secret GitLab values
- Step 2. Manually replicate the primary node’s SSH host keys
- Step 3. Add the secondary node
- Step 4. Enabling Hashed Storage
- Step 5. (Optional) Configuring the secondary node to trust the primary node
- Step 6. Enable Git access over HTTP/HTTPS
- Step 7. Verify proper functioning of the secondary node
- Selective synchronization
- Upgrading Geo
- Troubleshooting
Geo configuration
Configuring a new secondary node
注意:这是设置辅助地理节点的最后一步. 设置过程的各个阶段必须按记录的顺序完成. 在尝试此阶段中的步骤之前,请完成所有之前的阶段 .
配置辅助节点的基本步骤是:
- 在主节点和辅助节点之间复制所需的配置.
- 在每个辅助节点上配置跟踪数据库.
- 在每个辅助节点上启动 GitLab.
我们鼓励您先阅读所有步骤,然后再在测试/生产环境中执行这些步骤.
注意: 不要为辅助节点设置任何自定义身份验证. 这将由主节点处理. 任何需要访问” 管理区域”的更改都必须在主节点中完成,因为辅助节点是只读副本.
Step 1. Manually replicate secret GitLab values
GitLab 在/etc/gitlab/gitlab-secrets.json
文件中存储了许多秘密值,这些秘密值在所有节点上都必须相同. 除非有一种方法可以在节点之间自动复制它们(请参阅问题#3789 ),否则必须将它们手动复制到辅助节点.
SSH 进入主节点,并执行以下命令:
sudo cat /etc/gitlab/gitlab-secrets.json
这将以 JSON 格式显示需要复制的机密.
SSH 进入辅助节点并以
root
用户身份登录:sudo -i
备份所有现有机密:
mv /etc/gitlab/gitlab-secrets.json /etc/gitlab/gitlab-secrets.json.`date +%F`
将
/etc/gitlab/gitlab-secrets.json
从主节点复制到辅助节点,或在节点之间复制并粘贴文件内容:sudo editor /etc/gitlab/gitlab-secrets.json
# paste the output of the `cat` command you ran on the primary
# save and exit
确保文件权限正确:
chown root:root /etc/gitlab/gitlab-secrets.json
chmod 0600 /etc/gitlab/gitlab-secrets.json
重新配置辅助节点以使更改生效:
gitlab-ctl reconfigure
gitlab-ctl restart
Step 2. Manually replicate the primary node’s SSH host keys
GitLab 与系统安装的 SSH 守护程序集成,指定一个用户(通常名为git
)来处理所有访问请求.
在灾难恢复情况下,GitLab 系统管理员会将辅助节点升级为主要节点. 主域的 DNS 记录也应更新为指向新的主节点(以前是辅助节点). 这样做可以避免更新 Git 遥控器和 API URL 的麻烦.
由于 SSH 主机密钥不匹配,这将导致对新提升的主节点的所有 SSH 请求失败. 为防止这种情况,必须将主 SSH 主机密钥手动复制到辅助节点.
SSH 进入辅助节点并以
root
用户身份登录:sudo -i
备份所有现有的 SSH 主机密钥:
find /etc/ssh -iname ssh_host_* -exec cp {} {}.backup.`date +%F` \;
从主节点复制 OpenSSH 主机密钥:
如果可以使用root用户访问主节点:
# Run this from the secondary node, change `<primary_node_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 your primary node:
sudo tar --transform 's/.*\///g' -zcvf ~/geo-host-key.tar.gz /etc/ssh/ssh_host_*_key*
# Run this from your secondary node:
scp <user_with_sudo>@<primary_node_fqdn>:geo-host-key.tar.gz .
tar zxvf ~/geo-host-key.tar.gz -C /etc/ssh
在辅助节点上,确保文件权限正确:
chown root:root /etc/ssh/ssh_host_*_key*
chmod 0600 /etc/ssh/ssh_host_*_key*
要验证密钥指纹是否匹配,请在两个节点上执行以下命令:
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)
验证您对现有的私钥具有正确的公钥:
# 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
注意:私钥和公钥命令的输出应生成相同的指纹.
在辅助节点上重新启动
sshd
:# Debian or Ubuntu installations
sudo service ssh reload
# CentOS installations
sudo service sshd reload
Step 3. Add the secondary node
SSH 到您的 GitLab 辅助服务器并以 root 用户身份登录:
sudo -i
编辑
/etc/gitlab/gitlab.rb
并为您的节点添加一个唯一的名称. 在接下来的步骤中,您将需要此:# The unique identifier for the Geo node.
gitlab_rails['geo_node_name'] = '<node_name_here>'
重新配置辅助节点以使更改生效:
gitlab-ctl reconfigure
访问主节点的 管理区> 浏览器中的地理位置 (
/admin/geo/nodes
).- 单击新建节点按钮.
- 填写姓名与
gitlab_rails['geo_node_name']
在/etc/gitlab/gitlab.rb
. 这些值必须始终完全匹配,一个字符一个字符. - 在
/etc/gitlab/gitlab.rb
external_url
填写URL . 这些值必须始终匹配,但是一个以/
结尾而另一个不以/
无关紧要. - 不要选中” 这是主节点”复选框.
- (可选)选择辅助节点应复制的组或存储分片. 保留空白以复制所有内容. 阅读更多有关选择性同步的信息 .
- 单击添加节点按钮以添加辅助节点.
SSH 到您的 GitLab 辅助服务器并重新启动服务:
gitlab-ctl restart
通过运行以下命令,检查您的地理设置是否存在任何常见问题:
gitlab-rake gitlab:geo:check
SSH 到您的主服务器中,并以 root 用户身份登录以验证辅助节点是否可以访问或您的地理设置存在任何常见问题:
gitlab-rake gitlab:geo:check
一旦添加到管理面板并重新启动, 辅助节点将在称为backfill的过程中自动开始从主节点复制丢失的数据. 同时, 主节点将开始将每个更改通知每个辅助节点,以便辅助节点可以立即对那些通知进行操作.
确保辅助节点正在运行并且可访问. 您可以使用与主节点相同的凭据登录到辅助节点.
Step 4. Enabling Hashed Storage
使用哈希存储可显着改善地理复制. 项目和组重命名不再需要节点之间的同步.
- 访问主节点的 管理区> 浏览器中的设置>存储库 (
/admin/application_settings/repository
). - 在” 存储库存储”部分中,选中” 对新创建和重命名的项目使用哈希存储路径” .
Step 5. (Optional) Configuring the secondary node to trust the primary node
如果您的主节点使用 CA 颁发的 HTTPS 证书,则可以安全地跳过此步骤.
如果主节点正在使用自签名证书以获得HTTPS支持,则需要将该证书添加到辅助节点的信任存储中. 从主节点上检索证书,然后在辅助节点上遵循这些说明 .
Step 6. Enable Git access over HTTP/HTTPS
Geo 通过 HTTP / HTTPS 同步存储库,因此需要启用此克隆方法. 导航 管理区> 在主节点上进行设置 ( /admin/application_settings/general
),并将Enabled Git access protocols
设置为Both SSH and HTTP(S)
或Only HTTP(S)
.
Step 7. Verify proper functioning of the secondary node
现在已配置辅助节点!
您可以使用与主节点相同的凭据登录到辅助节点. 访问辅助节点的 管理区> 浏览器中的Geo ( /admin/geo/nodes
),以检查是否正确地将其标识为辅助 Geo 节点,以及是否启用了 Geo.
初始复制或”回填”可能仍在进行中. 您可以从浏览器中主节点的” 地理节点”仪表板监视每个地理节点上的同步过程.
如果您的安装无法正常工作,请查看故障排除文档 .
仪表板中最明显的两个最明显的问题是:
- 数据库复制无法正常工作.
- 实例间实例通知不起作用. 在这种情况下,可能是以下情况:
- 您正在使用自定义证书或自定义 CA(请参阅故障排除文档 ).
- 该实例已进行防火墙保护(请检查您的防火墙规则).
请注意,禁用辅助节点将停止同步过程.
请注意,如果在主节点上为多个存储库分片定制了git_data_dirs
则必须在每个辅助节点上复制相同的配置.
将您的用户指向“使用地理服务器”指南 .
当前,这是同步的:
- Git 存储库.
- Wikis.
- LFS 对象.
- 问题,合并请求,摘要和评论附件.
- 用户,组和项目化身.
Selective synchronization
Geo 支持选择性同步,这使管理员可以选择辅助节点应同步哪些项目. 可以按组或按存储碎片选择项目的子集. 前者是复制属于用户子集的数据的理想选择,而后者更适合将 Geo 逐步推广到大型 GitLab 实例.
重要的是要注意选择性同步:
- 不限制来自辅助节点的权限.
- 不从辅助节点隐藏项目元数据.
- 由于 Geo 当前依赖于 PostgreSQL 复制,因此所有项目元数据都将复制到辅助节点,但是尚未选择的存储库将为空.
- 不减少为地理事件日志生成的事件数.
- 只要存在任何辅助节点, 主节点都会生成事件. 选择性同步限制是在辅助节点而非主节点上实现的.
Git operations on unreplicated repositories
在 HTTP(S)的 GitLab 12.10 和 SSH 的 GitLab 13.0 中引入 .
存在于主节点上但不存在于辅助节点上的存储库支持通过 HTTP(S)和 SSH 进行 Git 克隆,拉入和推送操作. 在以下情况下可能会发生这种情况:
- 选择性同步不包括附加到存储库的项目.
- 存储库正在积极地复制,但尚未完成.
Upgrading Geo
请参阅更新地理节点文档 .
Troubleshooting
请参阅故障排除文档 .