记录一下最近做的 GitLab 迁移和升级的事情。

高危操作警告
升级及迁移存在风险，若您在操作生产环境，请提前做好升级计划和升级方案，以防升级失败造成服务不可用或数据丢失。

要做什么

1、从裸机 CentOS6 GitLab-Omnibus 迁移到 Docker 环境中。
2、跨版本升级 GitLab 版本，从 11.x 到 13.x。

准备怎么做

根据需求，计划先做同版本迁移，再做跨版本升级。

迁移

在新机器上准备一个 Docker 环境，因为是通过 Docker Compose 拉起容器的，所以还需要安装 Docker Compose。

根据 GitLab Docs 中提及的 Install GitLab using Docker Compose 准备好 docker-compose.yml。注意文件中的 image 版本应该和原机器 GitLab 版本保持一致。

以 CE 版本（GitLab 社区版，非极狐版）为例，具体的 Tag 可以在 DockerHub 中找到。

备份

我们需要在老机器上备份三个文件。

/etc/gitlab/gitlab-secrets.json
/etc/gitlab/gitlab.rb
以及使用 GitLabShell 命令创建的最新备份文件，正常情况下，会在/var/opt/gitlab/backups 中生成 TIMESTAMP_gitlab_GITLABVERSION_backup.tar 的备份文件。

1
2
3
4
# GitLab 12.2及以上版本
gitlab-rake gitlab:backup:create
# GitLab 12.1及以下版本
gitlab-rake gitlab:backup:create

恢复

将老机器上的三个文件放到对应的位置上，因为新机器使用 Docker 方式部署，具体位置需要根据 docker-compose.yml 和 gitlab.rb 中的配置为准。

需要额外注意的是，gitlab/backups 中的备份文件应该授予 git:git 的用户和组，因为是 docker 环境，直接给 lxd:docker 即可。

准备工作就绪，开始执行恢复，进入到拉起 gitlab 容器，并进入容器的 bash。

断开 GitLab 连接到数据库的服务，并保持 GitLab 其他服务是运行状态。

1
2
3
gitlab-ctl stop unicorn
gitlab-ctl stop sidekiq
gitlab-ctl status

还原备份，这里 TIMESTAMP_gitlab_GITLABVERSION 是之前传过来的备份的名字。

1
2
3
4
# GitLab 12.2及以上版本
gitlab-backup restore BACKUP=TIMESTAMP_gitlab_GITLABVERSION
# GitLab 12.1及以下版本
gitlab-rake gitlab:backup:restore BACKUP=TIMESTAMP_gitlab_GITLABVERSION

等待还原，期间会出现几次交互式问题，选是即可。注意，GitLab 的备份恢复是以 Overwrite 的方式进行的，会删掉之前所有的数据。

数据恢复完毕，重启和验证业务。

1
2
3
gitlab-ctl reconfigure
sudo gitlab-ctl restart
sudo gitlab-rake gitlab:check SANITIZE=true

打开浏览器登录 GitLab，验证业务是否正常，Runner 注册是否正常。若正常，则迁移成功。

升级

确定升级路线

因为是跨大版本升级，首先需要确定升级路线，例如我的现场：
当前版本：11.3.1
目标版本：13.12.15

升级路线：11.3.1 -> 11.11.8 -> 12.0.12 -> 12.1.17 -> 12.10.14 -> 13.0.14 -> 13.1.11 -> 13.8.8 -> 13.12.15

20220508213223

GitLab 需要按照官方规定的版本之间进行跨大版本升级，所以我们确定好了当前版本之后，只要先就近升级到规定版本之后，一路按照升级路线升级即可。

升级及业务验证

GitLab For Docker 的升级非常简单，只要换 image 即可。

进入 docker-compose 目录，更换对应版本的 image。

1
2
3
docker-compose pull
docker-compose down
docker-compose up -d

docker-compose ps看一下容器的运行状态，使用docker-compose logs -f看一下容器的日志，保证 GitLab 能正常起来。

我们可以通过以下命令，了解数据迁移情况。（需要在 Docker 中执行）

1
2
gitlab-rails runner -e production 'puts Gitlab::BackgroundMigration.remaining'
gitlab-rails runner -e production 'puts Gitlab::Database::BackgroundMigrationJob.pending.count'

当 Web 端准备就绪之后，还需要登录到 Admin Area 上，找到 Monitoring > Background Migrations 观察表迁移状态，数据量不同迁移（Migrations）所需要的时间也不同，PS：可以通过调整 Sidekiq workers 数量提高速度。

需要注意的是，必须等待迁移完全结束之后，才能算到目标版本的升级成功，此时方可继续升级到下一个版本，如果不等他执行迁移结束就继续升级，会出现报错。

建议每升级完一步，都进行一次业务验证，及时发现升级中的问题。

扩展阅读