本以为 《GitLab 简明维护指南(v2020.05)》 足够解决接下来的所有问题,没想到在 v12 版本中, GitLab 官方因为一些变更引入了“升级额外操作”的步骤。

也就是说,常规的修改低版本应用版本号到高版本版本号,由 Ruby 升级脚本执行升级操作的模式不完全生效了。

而且在升级过程中,也会遇到一些额外的小问题,这里我们就来聊聊如何在有“升级额外操作”的背景下进行应用升级。

写在前面

因为我们使用的是容器方案,所以升级还是比较轻松的。如果你还未曾搭建 GitLab ,可以参考以往文章中的gitlab标签的文章内容。

确认升级路线

官方首先明确了几种不同的升级路线图,其中各自有一些关键升级版本。

目标版本13.2.0

当前版本大于等于 11.5.0,则需要使用的升级路线为:

其中,11.1112.012.1013.0 四个版本是必须的。

目标版本13.0.1

当前版本大于等于 11.10.8,则需要使用的升级路线为:

其中,11.1112.012.10 三个版本是必须的。

目标版本12.10.6

当前版本大于等于 11.3.4,则需要使用的升级路线为:

其中,11.1112.0 两个版本是必须的。

目标版本12.9.5

当前版本大于等于 10.4.5,则需要使用的升级路线为:

其中,10.811.1112.012.9.5 四个版本是必须的。

目标版本12.2.5

当前版本大于等于 9.2.6,则需要使用的升级路线为:

其中,9.510.811.1112.012.2 五个版本是必须的。

升级实践

当明确升级路线后,升级只需要跟随上面的路径进行操作即可,排除各种问题升级成功后,你将会看到类似下面的日志。

下面来聊聊,你可能遇到的一些问题。

小插曲一:错误的升级版本指定

我最初升级时,不知道 v12 版本有这么多“讲究”,直接将我当前使用的  gitlab/gitlab-ce:12.10.3-ce.0修改为了最新的 gitlab/gitlab-ce: 13.2.2-ce.0,意料之中,遇到了许多的不兼容问题。

所幸的是,程序有异常检查,判断版本不符合要求,并未允许执行升级操作,不停输出类似下面的日志,提示我们检查升级文档。

没有关系,按照官方路线修改版本号进行升级即可。当然,这里建议你执行了完整数据备份。

小插曲二:程序生成配置错误

在容器环境下, gitlab.rb 配置是由程序读取环境变量自动生成的,因为跨版本,所以这里的配置可能混杂了多个版本的内容,而产生版本不兼容的问题。

实际运行会遇到这样的报错:

解决方案也比较简单,让程序在某个可运行的版本下,重新生成一份配置就好了。

小插曲三:不支持的环境变量配置项

在读取环境变量的过程中,也可能会遇到一些已经被废弃的配置项而产生的运行异常停止,比如下面这样:

解决方案:将提示中的不支持的配置项目删除掉或者注释掉就好了。

比如 # gitlab_monitor['enable'] = false

小插曲四:GitLab CI Shell 模式停止工作

在升级完毕后,会遇到部分 Shell 模式的 CI停止工作。

这是因为新版本的GitLab会在调用 CI 的时候,发送 --login 参数,如果用户目录包含 .bashrc.bash_logout 文件,则会被加载执行,这些文件中可能存在一些意外退出执行过程的命令,如 .bash_logout 可能存在下面的内容。

解决方案:删除或注释掉内容即可。

最后

最近事多,先写到这里吧。

–EOF