上次写完  迁移 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 参数，使用交互式终端后，再执行上面的操作，比如：

docker exec -it gitlab /bin/bash

然后在执行下面的命令：

gitlab-rails console

等待控制台继续可交互输入内容的时候，输入下面的命令，清理掉这些不可解密使用的变量。

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