上次写完 迁移 GitLab 数据到全新容器 ，我有在微博里说过这里如果有关联过 CI ，可能会出现一些小问题，比如：原本好好的pipeline显示运行中，但是没日志响应、项目的CI页面打不开，显示500错误。
问题原因
再次查看备份与恢复 的文档，发现 GitLab 在恢复备份过程中，对于下面的文件是不会进行备份和恢复操作的。
/etc/gitlab/gitlab-secrets.json/etc/gitlab/gitlab.rb/home/git/gitlab/config/secrets.yml
而被恢复的数据库中包含双因子加密验证的数据，其中的一个解密因子被保存在了 gitlab-secrets.json 中，如果你不进行手动合并操作，那么你的新 GitLab 应用中涉及到需要双因子解密的数据将都不可用，而 GitLab 在代码中也没有对这类情况作一些额外操作，就导致页面报 500 错误，显示不可访问。
一年前有人已经在官方社区中进行了反馈，但是暂时还没有进行解决。
如何解决
解决方式有两种。
第一种是你手动备份这几个文件，然后在新的应用中进行还原操作，这里除了要注意进行操作的时候，GitLab 要处于停止服务状态，没有什么额外的问题。
但是如果你想得到一个更少历史负担、更少陈旧配置的全新应用，可能接下来的第二种解决方式会更适合你。
第二种方式则是在数据库中清理掉这些需要双因子解密的数据，避免 GitLab 在执行过程中出现异常情况，进而报错拒绝服务。
如何操作
如果你是裸机安装，那么直接执行 gitlab-rails console 就可以进去 Rails 控制台了。
如果你修复是在 Docker 容器中运行的 GitLab 则需要使用 -it 参数，使用交互式终端后，再执行上面的操作，比如：
|
1
|
docker
exec
-
it
gitlab
/
bin
/
bash
|
然后在执行下面的命令：
|
1
|
gitlab
-
rails
console
|
等待控制台继续可交互输入内容的时候，输入下面的命令，清理掉这些不可解密使用的变量。
|
1
2
|
p
=
Project
.
find_by_full_path
(
'project-group/project-name'
)
p
.
variables
.
each
(
&
:
destroy
)
|
当你看到一段显示正常的 JSON 数据返回之后，再次刷新不能进行设置 CI 变量的页面。
将之前“卡住”的 Pipeline 取消，再次触发执行，你会发现一切又都正常了。
额外的问题
在全新部署 GitLab 的时候，可能会出现执行任务失败，直接报错 fragment error 。
遇到这个问题，大概率是从 Amazon S3 下载的文件出错了，建议重新下载：https://docs.gitlab.com/runner/install/linux-manually.html 。
这里其实和官方使用滚动更新有关，官方下载页面没有提供文件校验和来让用户进行下载文件确认，所以你无法保证你下载的问题是正确的，只能靠下载完毕执行看行为是否正常。
最后
本篇作为上一篇文章的补足，写的简短了些，应该看着没有之前的长篇大论爽快。
但是如果仔细思考一下，会发现有的事情还是挺有意思的：
- 防御性编程：不信任任何外部设备，除非它已经被加入信任列表
- 核心数据使用：不使用明文保存任何核心数据，涉及两台机器，交互的数据使用双因子进行加密，杜绝中间人攻击
- 敏捷开发：优先完成 MVP 功能，涉及迁移数据这种低频功能开发优先级降低
- 社区建设：专人跟进专属模块，收集反馈，给出临时解决方案，透露未来的规划，增强客户对软件的信心
如果你也在构建一套对外的工具软件，上面的思路或许也可以借鉴其中一二。
说些题外话，有的时候，人们出于本能会躲开麻烦和折腾的事情，只要它们还没有变成不得不去解决的“麻烦”。但是如果有一天你选择去面对它们，去解决它们，那么你在某一方面的知识水平、技能积累就将会大幅的提高。
比如我一直觉得重新配置一台新的家用服务器很麻烦，从系统设计到入网规划、再到上面跑什么样的虚拟化方案，具体资源分配如何设计….
但是真的当我重新配置了一台新的服务器后，我发现许多问题，我之前已经解决过了，把已有的经验稍微更新一下，就可以快速拿到我想要的结果。而且新的服务器的出现，让我有了许多冗余的“算力”和“储存”空间，我可以再一次将我的自动化流程方案进行升级改造，进一步提高效率、扩展我折腾的边界。
共勉。
—EOF