记一次跨 6 个大版本通宵升级 17 次 GitLab 社区版的经历

0x00.前言

本文是一个系列，本篇为系列文章的第四篇：记一次跨 6 个大版本通宵升级 17 次 GitLab 社区版的经历

第一篇：基于 AlmaLinux 9 安装 GitLab 社区版实战

第二篇：基于 AlmaLinux 9 配置 GitLab 社区版实战

第三篇：基于 AlmaLinux 9 备份 GitLab 社区版实战

本文仍基于在腾讯云购买的轻量机 cn-tx-bj7-a9 上安装，AlmaLinux 9.4 版本，配置为 4C4G60G

上一篇文章基于 AlmaLinux 9 备份 GitLab 社区版实战中介绍了公司内部使用的 GitLab 是如何配置每日执行异地备份的

结尾提及下一篇文章计划介绍生产环境跨 6 个大版本的真实升级经历，没错，这篇文章就来详细回顾一下当时升级的全流程

这里说一下，生产环境的机子是 CentOS 7 版本的，而标题为了统一仍沿用了 AlmaLinux 9（标题已经换掉了）

但并不会影响到整体升级的思路

0x01. 升级背景

好端端跑着的服务，为啥要升级呢？原因自然是 GitLab 曝出新授权漏洞 CVE-2024-45409 需要及时打补丁了

我们接到的通知比较延后，下午收到的通知，晚上就要执行升级

• 好消息是不用担心 SLA，服务可以中断，内部的 GitLab 暂时谁也别想用了而已（用了不保证数据持久）
• 坏消息是看了下当前的版本以及发现 GitLab 不能跨多个大版本进行升级，需要一个版本一个版本的升级

于是开始一边看官方文档，一边捋升级的整体流程

0x02. 升级前备份

万事开头难，毕竟谁都没有搞过，想着还是先备份一下，先整机备份好了

1. VM 是跑在一个 vCenter 实例上，开 case 申请了访问权限后，发现并不能执行快照，好在最终对方还是拍摄了快照
2. 为了保险起见，又执行了 gitlab-backup 操作，这样就会得到一个备份档，上一篇文章中有介绍到具体方法，可以把 secrets and configuration 文件也追加上

没有把第二步的备份档下载到自己的电脑上，而是直接 rsync 传到了另一台异地 VM 上，这样就双保险了

上面这两个层级的备份搞完，差不多就花了 3+ 个小时吧，因为这 VM 在圣何塞……网速实在是不快，好在不会掉线

接下来就可以无所畏惧的计划升级了

参考官方文档：https://docs.gitlab.com/ee/update/

0x03. 使用 Upgrade Path Tool 计划升级

参考官方文档：https://docs.gitlab.com/ee/update/plan_your_upgrade.html

是要先生成 Upgrade Path：https://gitlab-com.gitlab.io/support/toolbox/upgrade-path，也就是跨大版本的逐级升级

• 当前版本：11.4.14，实际上我们用的是 11.4.X，所以会多一步先升级到 11.4.14 的过程
• 目标版本：16.3.9
• 版本：社区版
• 源：CentOS
• Auto Install：自动安装就是在命令后添加 -y，不勾选
• Zero downtime：零宕机时间在要求 SLA 的环境中可以这么搞，代价是逐个升级的版本超级多，不勾选
• N-1：认为最新版本的前一个版本才是最新版本，不勾选

查看摘要

额外提醒最下面那个 glibc 兼容性问题需要留意

具体升级的版本列表如下

一共需要 16 + 1 = 17 次升级，通宵是在劫难逃了

11.11.8 => 12.0.12 => 12.1.17 => 12.10.14 => 13.0.14 => 13.1.11 => 13.8.8 => 13.12.15 => 14.0.12 => 14.3.6 => 14.9.5 => 14.10.5 => 15.0.5 => 15.4.6 => 15.11.13 => 16.3.9

0x04. 逐个升级

为了稳定考虑，没有使用 yum install 在线安装，而是去下载了 rpm 包，这样就能盯着实时升级的进度看了

执行命令为：rpm -Uvh xxx.rpm > version.log

万事开头难，但没想到第一个升级顺利完成了，可以看到 rake 输出的一大堆日志，也并不需要我们做什么

这里还有一个问题，VM 硬盘空间危！

为了给升级留够空间，上传一个 rpm 升级后再上传下一个，一个一个来

但自己早上起来才得知，半夜执行到某个版本后还是 disk full 了，折腾了一大顿好在卸载重装后恢复正常了，不然可就是进退两难的局面了

实测每个 rpm 包先下载到自己 PC 上再上传到 VM，都比直接在 VM 上下载要来的快

以及还是因为并不快的网速，最终从第一天晚上搞到第二天下午才彻底完成了升级：11.4.X -> 16.3.9

作为 admin，在第二天上午还是看到有同事在使用 GitLab 进行 merge，是真不怕提交记录说无就无了

0x05. 检查后台迁移

参照官方文档：https://docs.gitlab.com/ee/update/background_migrations.html

在 rpm 升级完一个版本之后，一定要等待后台迁移完毕之后再升级下个版本

0x06. 再次升级事件

没过几天，就又收到了升级通知，于是继续升级，毕竟被折磨过一回了，もう何も怖くない（已经没什么好怕的了）

16.7.10 => 16.11.10 => 17.X

这里贴一下自己的腾讯云轻量机上部署的实例概览，可以看到详细的版本信息

0x07.后记

一直都想把这次的升级经验拿出来讲讲，趁双十一活动花了接近 2h 终于是给写完了

通宵是不可能通宵的，这辈子都不可能通宵的，狗命要紧，该睡还是得睡的

众所周知，升级打补丁还是放在定期任务里比较合适，就不用临阵抱佛脚了，但道理都懂

下一篇文章开始介绍 GitLab CI/CD 的相关实践，计划从部署GitLab Runner 说起

也欢迎购买轻量机进行尝试，双十一拼团有优惠：https://cloud.tencent.com/act/pro/double11-2024?fromSource=gwzcw.8891816.8891816.8891816

跳转