本文使用「署名 4.0 国际 (CC BY 4.0)」许可协议，欢迎转载、或重新修改使用，但需要注明来源。 [署名 4.0 国际 (CC BY 4.0)](https://creativecommons.org/licenses/by/4.0/deed.zh)

本文作者: 苏洋

创建时间: 2018年09月29日
统计字数: 2127字
阅读时间: 5分钟阅读
本文链接: https://soulteary.com/2018/09/29/after-gitlab-migration.html

-----



# GitLab 迁移之后的事情

上次写完 [ 迁移 GitLab 数据到全新容器 ](https://soulteary.com/2018/09/27/migrate-your-gitlab.html) ，我有在微博里说过这里如果有关联过 CI ，可能会出现一些小问题，比如：**原本好好的pipeline显示运行中，但是没日志响应**、**项目的CI页面打不开，显示500错误**。

## 问题原因

再次查看[备份与恢复](https://docs.gitlab.com/ce/raketasks/backup_restore.html#backup-restore) 的文档，发现 GitLab 在恢复备份过程中，对于下面的文件是不会进行备份和恢复操作的。

- `/etc/gitlab/gitlab-secrets.json`
- `/etc/gitlab/gitlab.rb`
- `/home/git/gitlab/config/secrets.yml `

而被恢复的数据库中包含双因子加密验证的数据，其中的一个解密因子被保存在了 `gitlab-secrets.json` 中，如果你不进行手动合并操作，那么你的新 `GitLab` 应用中涉及到需要双因子解密的数据将都不可用，而 `GitLab` 在代码中也没有对这类情况作一些额外操作，就导致页面报 500 错误，显示不可访问。

一年前有人已经在官方社区中[进行了反馈](https://gitlab.com/gitlab-org/gitlab-ce/issues/29400)，但是暂时还没有进行解决。

## 如何解决

解决方式有两种。

第一种是你手动备份这几个文件，然后在新的应用中进行还原操作，这里除了要注意进行操作的时候，`GitLab` 要处于停止服务状态，没有什么额外的问题。

但是如果你想得到一个更少历史负担、更少陈旧配置的全新应用，可能接下来的第二种解决方式会更适合你。

第二种方式则是在数据库中清理掉这些需要双因子解密的数据，避免 `GitLab` 在执行过程中出现异常情况，进而报错拒绝服务。

## 如何操作

如果你是裸机安装，那么直接执行 `gitlab-rails console` 就可以进去 `Rails 控制台`了。

如果你修复是在 Docker 容器中运行的 `GitLab` 则需要使用 `-it` 参数，使用交互式终端后，再执行上面的操作，比如：

```bash
docker exec -it gitlab /bin/bash
```

然后在执行下面的命令：

```bash
gitlab-rails console
```

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

```bash
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](https://docs.gitlab.com/runner/install/linux-manually.html) 。

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

## 最后

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

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

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

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

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

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

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

共勉。

--EOF