之前写过不少 GitLab 相关的内容,从搭建到迁移到优化都有聊过,但是从未系统的聊聊该怎么在日常进行维护,趁着假期为代码仓库升级来聊聊吧。

写在前面

GitLab 是一款优秀的软件,我从 13 年开始用它到现在,并使用它对个人/团队/公司的项目进行管理,从个人到十数人再到百人甚至到几百人、上千人以上的场景下它都未曾掉过链子,软件品质值得信赖。前公司们也不乏使用它的企业版作为公司代码资产管理方案,或者以它为竞品进行内部软件开发。

以下各种维护操作,均基于容器部署方案。并假设搭建的私有 GitLab 软件仓库地址均为:https://gitlab.soulteary.com

GitLab 数据备份及恢复

在做任何维护操作之前,首要的操作是对已有实例进行数据备份。在之前的文章中,我有提过如何备份和恢复,以本次升级为例,备份数据只需要一条命令:

如果你使用 Rsync 对备份目录进行实时同步,那么需要在命令后添加 GZIP_RSYNCABLE=yes 参数,这个参数将传递 --rsyncable 给 gzip 工具。

当然,想要支持 Rsync 实时备份生成的备份文件,需要使用 v12.1 版本以上的 GitLab 。

数据恢复同样只需要一条命令。

如果你在执行之后发现 GitLab CI 页面出现 500 错误,可以参考之前的文章进行修复,当然,更好的方案是使用代码仓库管理这些 CI 变量,可以参考之前的文章进行操作

更多的信息,可以参考官方文档:GitLab 数据备份与恢复

版本升级

日常针对 GitLab 最常见的操作便是进行软件版本升级,升级是一件胆大心细的活。

尤其是使用容器之后,升级变的更加容易了,步骤更少,变更速度更快,所以更加需要确定每一步操作都是正确的,避免来回折腾。

获取当前运行的软件版本

最简单的方式便是访问https://gitlab.soulteary.com/help页面,查看你当前运行的软件版本。

GitLab 当前版本 12.9.3

当然,你也可以选择使用 API 的方式来获取软件版本,调用文档虽然写在 EE 文档中,但是开源版本也是支持的(版本要求 8.13+)。

首先在个人访问令牌页面创建一个有 api 调用权限的 Token(https://gitlab.soulteary.com/profile/personal_access_tokens),然后将下面命令中的 “PRIVATE_ACCESS_TOKEN”进行替换即可。

执行完毕,你将能看到当前软件的版本。

获取当前最新的稳定版本号

获取当前新版本的方式有很多,我们当然可以从官方的发布页面获取。

GitLab 官方发布页面

但是上面这种方案并不是最优的方案,因为你无法获取精确的补丁版本,为了避免出现各种未预期的问题,以及方便出问题后进行排查,我们使用的版本,务必精确版本到 x.y.z ,也就是补丁版本。

我这里推荐一种我个人一直在使用的方式:从软件 master 分支获取最新的 CHANGELOG,锁定大概的最新版本,然后再通过其他线索进行进一步确认。

这样做的好处是在查看版本的过程中,能顺便了解到底有什么样的功能改进,以及安全漏洞修复。

注意,这里获取的版本,可能因为一些人为原因并不是最新的,所以我们还需要进一步确认。

浏览器访问 https://gitlab.com/gitlab-org/gitlab-foss/-/tags ,你会看到最新的 Tag 是 v12.10.3,确实出现了和 CHANGELOG 最新版本不同的状况,为了确认版本,我们通常会进行版本详细对比,来判断到底能否使用更新的版本号。

判断临近版本是否可用

然后针对上面小节的问题,我们可以直接使用看提交的方式来确认版本间是否存在额外问题:

https://gitlab.com/gitlab-org/gitlab-foss/-/commits/v12.10.3

简单浏览提交,可以看到两个小版本差异不大,集中在前端功能修改和简单的文档补充,可以考虑直接使用最新版本。

进行版本详细对比

进行项目版本对比,有一个简单的方案,使用软件自身的 diff 功能,在线查看到底有多少提交,以及文件变动的最终结果是什么。

使用浏览器打开上面的链接,可以看到两个版本之间的差异。如果返回内容比较多,可以通过缩小版本号范围来一点点进行对比。

进行软件升级

之前提到了,我们使用容器方案进行版本维护,所以升级变的十分容易。

一般情况下,GitLab 是前后版本兼容的,我们只需要修改 GitLab 启动配置 docker-compose.yml 中的 image 字段,将版本号更新即可。

这里有个小技巧,我们先使用 docker pull 对软件进行下载,再修改版本,重启服务,可以减少服务不可用时间。

除了在官方镜像列表中翻找我们要使用的版本外,还可以通过添加参数快速查看是否有我们想要的版本。

以本次升级为例:

在软件下载之后执行组合命令,对服务进行关闭、重新启动,以及观察日志即可。

等到你看到 Upgrade has completed 日志后,打开浏览器,再次查看版本,应用就升级完成了。

GitLab 新版本升级完成

启动模版配置

一般而言,我们不需要对 gitlab.rb 文件进行大范围修改,但是一旦遇到定制需求后,官方文档可能出现和上面小节一样的问题,文档同步不及时,此时我们可以通过直接查阅代码仓库中的配置模版来解决问题:

其他

除了上述操作外,我们在维护过程中还可能出现一些问题,比较典型的问题可以参考下面的文章或者官方文档来获取解决方案。

最后

希望今年后面有空,能够将 GitLab 的性能监控、错误追踪、外部账号管理、AutoDevOps / Serverless 等内容都慢慢写出来吧。

–EOF