GitLab 7.2.1 升级到 7.14.3 过程中遇到的坑

背景：在此次升级之前，我们线上的 GitLab 7.2.1 版本已经跑了3年之久，其中结合我们自己的 CI/CD 流程添加了一些自定义的 feature，整个 CI/CD 流程运行的也十分顺畅。不过随着微服务、Docker、Kubernetes、Service Mesh 等概念的兴起，各个技术栈也都跟着不断的革新， CI/CD 领域也不例外， 其中 GitLab 内置了支持 Kubernetes 的功能， Jenkins 也推出了基于 Kubernetes 的全新 CI/CD 解决方案 Jenkins-X。
各个技术公司都在积极地了解并参与到这次技术革新中，我们当然也一样，为了更好地支持公司业务的发展和技术的更新，GitLab 的更新已经是势在必行。我们的第一步计划就是 GitLab 7.2.1 升级到 7.14.3 。
在这次 7.2.1 到 7.14.3 的升级过程中，我们获得了不少经验与教训，尤其是在数据迁移方面。其中一个教训就是一定要考虑到数据的完整性以及如何验证数据的完整性。在这次升级操作前我们理所当然地认为使用 rsync 先做全量同步，升级时再做增量同步，数据迁移方面就没有任何问题了。然而结果却还是没有逃过墨菲定律的暗示。
下面我们将简单的描述整个升级方案和遇到的问题：
1、备份
所有升级操作都在全新的服务器上进行，原有的 GitLab 服务器和 DB 用作备份。
选择在全新的服务器上进行升级，主要是基于以下几个方面的考虑：

• 使用原有的服务数据做备份和恢复方案，恢复速度是最快的

• 因为 GitLab 很久没有做过升级，再加上升级过程中要考虑自定义 patch 的兼容性，这给整个升级增加了一定的复杂性和不确定性

• 如果选择在原有服务器上做升级，假如升级中意外失败了并且无法恢复，这会影响上千个研发人员，这个结果是我们承担不起的。 虽然我们在测试环境做了多次升级演练，但是也不敢确保线上升级一定不出问题，所以这种方案就没有考虑

2、新服务器上搭建和线上相同的 GitLab 7.2.1 环境
3、全量迁移 GitLab 7.2.1 数据（repo，db）
考虑到从 GitLab Server 主服务器同步会对线上 GitLab 造成性能影响，repo 的全量同步是从 GitLab 备库同步的。
4、停 7.2.1 版本的 GitLab 服务
5、增量迁移数据（repo，db），使用 rsync 命令从 GitLab 主服务器增量同步 repo 到新服务器上，db 从线上数据库增量同步到新的 db
6、启动新服务器上的 7.2.1 GitLab
7、升级新服务器上的 7.2.1 到 7.14.3
8、功能验证
按照上述的操作步骤，预计3个小时内就可以完成整体升级。然而真实情况却是一波多折，中间发生了几个意外情况。
意外 1：由于忽略了 GitLab 主服务器上会有 git gc 操作，导致在 GitLab 主机上执行 rsync 增量同步的时间远远超过了预计的时间。
现象：
按照计划在 GitLab 主服务器上做 repo 数据的增量同步时 ，发现 rsync 执行的时间非常长，在预计的时间内并没有执行完。
分析：
在测试环境中 rsync 的增量同步时间仅仅是 10几分钟，仔细观察 rsync 同步 repo 过程日志发现，同步的数据是按照 repo 名字的首字母的顺序依次逐个同步的，然后我们对比了整个 repo 列表，按照当前的同步速度估计大概还需要 4-5 个小时完成增量同步任务，这结果太让人崩溃了。
之后我们对比了线上 GitLab 服务器上的 repo 和 新服务器上的 repo 各个文件与它们的 sha1 值，发现它们的值确实不一样。期间同事突然提醒线上的 GitLab 会有 gc 操作 （触发 git gc 有关的两个参数是 gc.auto default value is 6700，gc.autopacklimit default 50，超过这2个默认值就会触发 gc），gc 后会有很多小文件的合并。新服务器上做完 repo 全量迁移后没有再实时同步数据 ，然而主 GitLab 服务器由于升级前运行了 24 小时，这期间开放人员的 fetch/merge 等操作会触发 gc，这也是导致主 GitLab 服务器上 repo 数据和 新服务器上 repo 数据的差异的原因。
因此在执行 rsync 同步的时候，它已经不是简单的增量了，而会做很多差异对比，这个时间甚至比全量同步的时间更长。
解决方法：
想清楚这个问题后，我们剩下的任务就是如何加快同步速度，于是我们把剩下的 repo 列表整理好并分批次的放到多个 rsync 进程来同步，通过 iftop 查看，此时的千兆带宽也已打满，已经达到同步的最大速度。这大大加快了同步过程，没过多久整个 repo 数据就同步完成了。
思考：

• 由于 gc 的差别导致迁移增量数据的速度受影响，可以考虑在主机上实时的同步 repo 数据到新服务器 （注意限流）。

• 可以考虑原地升级，不做数据迁移。

• rsync 是文件级别的拷贝，可以考虑 block 级别的拷贝。

意外 2：rsync 长时间的文件同步会有文件损坏的可能。
现象：
数据同步完成后，登录 GitLab 首页会提示 500 Internal error。
分析：
查看 GitLab 日志发现下面的错误：

根据这个错误的相关信息找到了对应的 repo，我们对比了 repo 下的各个文件的 sha1 值，发现没有任何差别。通过查询网上资料，有人提示有可能是文件损坏，可以通过使用 git fsck 做校验，执行结果如下：

从结果可以看出 objects 下的 pack 文件缺失损坏了，而在 rsync 执行过程中却没有报任何错误信息。
解决方法：
删除了损坏的 repo 并重新同步有问题的 repo。
思考：
rsync 在长时间的数据同步过程中出现的这种通过对比 checksum 也发现不了的数据损坏该如何快速的发现？ 
意外 3：升级后有的 ldap 账户登录提示用户不存在。
现象：
个别 ldap 账号登录提示账户不存在。
分析：
查看当时的日志：

然后我们对比了 LDAP 中的账号信息和 GitLab 中的个人信息，发现个人的 identity 中的 OU 变了，查看了多个有问题的用户，发现他们的问题和现象都是一致的，经过了解才知道这些人都是同一批的实习生，实习期结束后被分配到各个业务线，所以 LDAP 中的个人信息也跟着变化了。这个问题在 7.2.1 的版本是没有问题的，在高版本会有这个问题。
查看了 GitLab 关于 LDAP 相关信息，找到了 “Please bring LDAP group sync to CE” （https://gitlab.com/gitlab-org/gitlab-ce/issues/43239），从这个 issue 里了解到 LDAP 同步 group 信息一直是企业版的功能，很多企业都期望 GitLab 把这个功能在社区版也开发，不过很遗憾这个诉求还没有实现。 
解决方法：
我们实现了一个定时任务， 定期会调用 LDAP 相关的接口查询到所有人员的 identity 信息，并与 GitLab 中的个人信息做diff，如果有变化则做更新 GitLab 中的个人信息。
意外 4：有个历史 commit 的 timestamp 错误导致含有这个 commit 的 branch 发布失败。
现象：
QA 人员反馈他们的项目发布一直失败，在 GitLab 页面浏览他们项目分支的时候页面会报 500 错误。
分析：
查看报 500 错误的日志显示如下：

提示 commit 的时间有问题，开发人员在本地查看这个 commit 的信息，发现这个 commit 的提交时间是 2048/11/2，这个错误的时间戳在 7.2.1 版本是没有问题的。查询 GitLab 的 issue 也发现有人提过相同的 issue，问题出在了底层的 libgit2 解析时间戳溢出，这个问题在高版本 8.4 以上已经解决了。
后来从 commit 的提交者那里了解到，这个 commit 是他在家里的虚拟机中提交的，当时也没有注意到时间的差别。
解决方法：
抛弃所有的提交历史，新建一个项目，并把老项目的 master 代码 copy 到新项目，并基于 master 重新拉分支。同时有问题的项目禁止提交，只允许读。
我们也试过重写 commit 的 timestamp 然后重新提交，不过并没有生效，所以最后只能抛弃所有的提交历史。
通过这次 GitLab 7.2.1 到 7.14.3 升级的经验积累，让我们对下次升级更有把握，也希望这次升级的小经验可以帮到其他正考虑升级 GitLab 的同学。

Kubernetes线下实战培训

Kubernetes应用实战培训将于2018年12月21日在北京开课，3天时间带你系统学习Kubernetes 。本次培训包括：容器特性、镜像、网络；Docker特性、架构、组件、概念、Runtime；Docker安全；Docker实践；Kubernetes架构、核心组件、基本功能；Kubernetes设计理念、架构设计、基本功能、常用对象、设计原则；Kubernetes的实践、运行时、网络、插件已经落地经验；微服务架构、DevOps等，点击下方图片查看详情。