Gitlab 迁移，由Helm chart on kubernets cluster 到 Omnibus
环境
迁移前安装方式：Gitlab helm chart on kubernets cluster ，使用对象存储ceph
迁移后安装方式：Gitlab with Omnibus package （rpm），使用本地存储
版本：11.9.8
准备阶段
物理机上安装gitlab，版本与容器内一致，搭建nginx，根据测试环境提前配置好authorized_keys，gitlab.rb
备份阶段
根据容器内自带命令使用Omnibus方式进行备份，文件大小约64G
gitlab-rake gitlab:backup:create
迁移阶段
1、将备份文件从容器拷贝到本地
kubectl -n gitlab cp gitlab-task-runner-68757b79c4-j6g9f:/srv/gitlab/tmp/backups/1588947812_2020_05_08_11.9.8_gitlab_backup.tar /tmp/1588947812_2020_05_08_11.9.8_gitlab_backup.tar
2、将对象存储文件拷贝到本地
kubectl -n gitlab cp gitlab-minio-6dbb7586bf-7522m:/tmp/temp /tmp/export
3、将所有备份文件rsync到物理机
rsync -avzP --password-file=/kdata/key.pas --bwlimit=20000 --port=3334 /kdata/1588947812_2020_05_08_11.9.8_gitlab_backup.tar [email protected]::optsrc/
rsync -avzP --password-file=/kdata/key.pas --port=3334 export [email protected]::optsrc/
恢复阶段
1、将备份文件放到指定目录
mv /opt/src/1588947812_2020_05_08_11.9.8_gitlab_backup.tar /opt/app/gitlab/backups
2、开始恢复
gitlab-ctl stop unicorn
gitlab-ctl stop sidekiq
gitlab-ctl status
gitlab-rake gitlab:backup:restore BACKUP=1588947812_2020_05_08_11.9.8
3、恢复完成后检测
gitlab-ctl restart
gitlab-rake gitlab:check SANITIZE=true
配置阶段
更改数据储存方式，并重置相关CI的所有密钥和token, 修改前备份以下表
进入数据库 gitlab-rails dbconsole，操作如下命令
update "uploads" set store = 1;
UPDATE projects SET runners_token = null, runners_token_encrypted = null;
UPDATE namespaces SET runners_token = null, runners_token_encrypted = null;
UPDATE application_settings SET runners_registration_token_encrypted = null;
DELETE web_hooks where type = 'SystemHook';
重新配置 system hooks
测试阶段
开发进行测试，
0、ssh -T [email protected]
1、验证system hooks，project hooks
2、数据存储正常，包括user，project，namespace 头像，附件等
3、git clone 验证ssh和https，push，pull等
解析切换
功能验证无误后，更改gitlab.web.cn解析
迁移效果：gitlab使用者无感知，能直接使用不做任何修改。
另：假如 原gitlab优化了"禁止写入authorized_keys"未打上勾，那么在恢复时会收到警告
警告：
WARNING
The "Write to authorized_keys file" setting is disabled, which prevents
the file from being rebuilt!
It should be enabled for most GitLab installations. Large installations
may wish to disable it as part of speeding up SSH operations.
See https://docs.gitlab.com/ee/administration/operations/fast_ssh_key_lookup.html
If you did not intentionally disable this option in Admin Area > Settings,
then you may have been affected by the 9.3.0 bug in which the new setting
was disabled by default.
https://gitlab.com/gitlab-org/gitlab-ee/issues/2738
It was reverted in 9.3.1 and fixed in 9.3.3, however, if Settings were
saved while the setting was unchecked, then it is still disabled.
Do you want to permanently enable the "Write to authorized_keys file" setting now
选择no，并设置sshd_config, 追加如下设置，并 service sshd reload ，这样就不需要 /opt/app/gitlab/.ssh/authorized_keys
Match User git # Apply the AuthorizedKeysCommands to the git user only
AuthorizedKeysCommand /opt/gitlab/embedded/service/gitlab-shell/bin/gitlab-shell-authorized-keys-check git %u %k
AuthorizedKeysCommandUser git
Match all # End match, settings apply to all users again
参考：https://docs.gitlab.com/ee/administration/operations/fast_ssh_key_lookup.html
知识点：随着用户数量的增加，常规的SSH操作变得缓慢，这是因为OpenSSH通过线性搜索来搜索授权用户的密钥。在最坏的情况下，例如当用户无权访问GitLab时，OpenSSH将扫描整个文件以搜索密钥。这可能会花费大量时间和磁盘I / O，这将延迟用户尝试推送或拉到存储库的时间。更糟糕的是，如果用户频繁添加或删除密钥，则操作系统可能无法缓存authorized_keys文件，这将导致反复访问磁盘。GitLab Shell通过提供一种通过GitLab数据库中的快速索引查找来授权SSH用户的方法来解决此问题。也就是上面提到的方法
问题：
1、官方文档无跨环境备份恢复记录。
2、要还原备份，还需要还原/etc/gitlab/gitlab-secrets.json （对于Omnibus软件包）或/home/git/gitlab/.secret（对于从源安装）。该文件包含数据库加密密钥， CI / CD变量以及用于两因素身份验证的变量。如果您无法连同应用程序数据备份一起还原此加密密钥文件，则启用了双重身份验证和GitLab Runners的用户将无法访问您的GitLab服务器。线上是基于Gitlab helm chart on kubernets cluster 形式的安装，在线上gitlab的13个容器中未找到同名配置文件，且因为配置文件类型不符合，容器内相互通信皆通过host绑定域名的方式，加密方式文件类型均不相同，无法完成配置文件恢复操作，所以需要重置相关CI的所有密钥和token，不影响gitlab使用。
2、官方推荐基于Gitlab helm chart on kubernets cluster安装的备份命令 kubectl exec -it <gitlab task-runner pod> backup-utility 无效
3、基于Gitlab helm chart on kubernets cluster安装开启了对象存储，而物理机使用本地存储。官方推荐使用命令gitlab-rake gitlab:artifacts:migrate_to_local ，但迁移版本无此命令，只能人工迁移对象存储数据，并修改数据库中存储类型字段。