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

然后在执行下面的命令:

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

当你看到一段显示正常的 JSON 数据返回之后,再次刷新不能进行设置 CI 变量的页面。

将之前“卡住”的 Pipeline 取消,再次触发执行,你会发现一切又都正常了。

额外的问题

在全新部署 GitLab 的时候,可能会出现执行任务失败,直接报错 fragment error

遇到这个问题,大概率是从 Amazon S3 下载的文件出错了,建议重新下载:https://docs.gitlab.com/runner/install/linux-manually.html

这里其实和官方使用滚动更新有关,官方下载页面没有提供文件校验和来让用户进行下载文件确认,所以你无法保证你下载的问题是正确的,只能靠下载完毕执行看行为是否正常。

最后

本篇作为上一篇文章的补足,写的简短了些,应该看着没有之前的长篇大论爽快。

但是如果仔细思考一下,会发现有的事情还是挺有意思的:

  • 防御性编程:不信任任何外部设备,除非它已经被加入信任列表
  • 核心数据使用:不使用明文保存任何核心数据,涉及两台机器,交互的数据使用双因子进行加密,杜绝中间人攻击
  • 敏捷开发:优先完成 MVP 功能,涉及迁移数据这种低频功能开发优先级降低
  • 社区建设:专人跟进专属模块,收集反馈,给出临时解决方案,透露未来的规划,增强客户对软件的信心

如果你也在构建一套对外的工具软件,上面的思路或许也可以借鉴其中一二。

说些题外话,有的时候,人们出于本能会躲开麻烦和折腾的事情,只要它们还没有变成不得不去解决的“麻烦”。但是如果有一天你选择去面对它们,去解决它们,那么你在某一方面的知识水平、技能积累就将会大幅的提高。

比如我一直觉得重新配置一台新的家用服务器很麻烦,从系统设计到入网规划、再到上面跑什么样的虚拟化方案,具体资源分配如何设计….

但是真的当我重新配置了一台新的服务器后,我发现许多问题,我之前已经解决过了,把已有的经验稍微更新一下,就可以快速拿到我想要的结果。而且新的服务器的出现,让我有了许多冗余的“算力”和“储存”空间,我可以再一次将我的自动化流程方案进行升级改造,进一步提高效率、扩展我折腾的边界。

共勉。

—EOF