本文使用「署名 4.0 国际 (CC BY 4.0)」许可协议,欢迎转载、或重新修改使用,但需要注明来源。 署名 4.0 国际 (CC BY 4.0)
本文作者: 苏洋
创建时间: 2018年09月29日 统计字数: 2114字 阅读时间: 5分钟阅读 本文链接: https://soulteary.com/2018/09/29/after-gitlab-migration.html
上次写完 迁移 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
。
遇到这个问题,大概率是从 AmazonS3
下载的文件出错了,建议重新下载:https://docs.gitlab.com/runner/install/linux-manually.html 。
这里其实和官方使用滚动更新有关,官方下载页面没有提供文件校验和来让用户进行下载文件确认,所以你无法保证你下载的问题是正确的,只能靠下载完毕执行看行为是否正常。
本篇作为上一篇文章的补足,写的简短了些,应该看着没有之前的长篇大论爽快。
但是如果仔细思考一下,会发现有的事情还是挺有意思的:
如果你也在构建一套对外的工具软件,上面的思路或许也可以借鉴其中一二。
说些题外话,有的时候,人们出于本能会躲开麻烦和折腾的事情,只要它们还没有变成不得不去解决的“麻烦”。但是如果有一天你选择去面对它们,去解决它们,那么你在某一方面的知识水平、技能积累就将会大幅的提高。
比如我一直觉得重新配置一台新的家用服务器很麻烦,从系统设计到入网规划、再到上面跑什么样的虚拟化方案,具体资源分配如何设计….
但是真的当我重新配置了一台新的服务器后,我发现许多问题,我之前已经解决过了,把已有的经验稍微更新一下,就可以快速拿到我想要的结果。而且新的服务器的出现,让我有了许多冗余的“算力”和“储存”空间,我可以再一次将我的自动化流程方案进行升级改造,进一步提高效率、扩展我折腾的边界。
共勉。
—EOF