GitLab 迁移和升级小记
记录一下最近做的 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 | GitLab 12.2及以上版本 |
恢复
将老机器上的三个文件放到对应的位置上,因为新机器使用 Docker 方式部署,具体位置需要根据 docker-compose.yml 和 gitlab.rb 中的配置为准。
需要额外注意的是,gitlab/backups 中的备份文件应该授予 git:git 的用户和组,因为是 docker 环境,直接给 lxd:docker 即可。
准备工作就绪,开始执行恢复,进入到拉起 gitlab 容器,并进入容器的 bash。
断开 GitLab 连接到数据库的服务,并保持 GitLab 其他服务是运行状态。
1 | gitlab-ctl stop unicorn |
还原备份,这里 TIMESTAMP_gitlab_GITLABVERSION 是之前传过来的备份的名字。
1 | GitLab 12.2及以上版本 |
等待还原,期间会出现几次交互式问题,选是即可。注意,GitLab 的备份恢复是以 Overwrite 的方式进行的,会删掉之前所有的数据。
数据恢复完毕,重启和验证业务。
1 | gitlab-ctl reconfigure |
打开浏览器登录 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
GitLab 需要按照官方规定的版本之间进行跨大版本升级,所以我们确定好了当前版本之后,只要先就近升级到规定版本之后,一路按照升级路线升级即可。
升级及业务验证
GitLab For Docker 的升级非常简单,只要换 image 即可。
进入 docker-compose 目录,更换对应版本的 image。
1 | docker-compose pull |
docker-compose ps
看一下容器的运行状态,使用docker-compose logs -f
看一下容器的日志,保证 GitLab 能正常起来。
我们可以通过以下命令,了解数据迁移情况。(需要在 Docker 中执行)
1 | gitlab-rails runner -e production 'puts Gitlab::BackgroundMigration.remaining' |
当 Web 端准备就绪之后,还需要登录到 Admin Area 上,找到 Monitoring > Background Migrations 观察表迁移状态,数据量不同迁移(Migrations)所需要的时间也不同,PS:可以通过调整 Sidekiq workers 数量提高速度。
需要注意的是,必须等待迁移完全结束之后,才能算到目标版本的升级成功,此时方可继续升级到下一个版本,如果不等他执行迁移结束就继续升级,会出现报错。
建议每升级完一步,都进行一次业务验证,及时发现升级中的问题。