gitlab升级准备

gitlab升级准备

首先说明，只是进行了准备和了解，并没有进行实际的升级。所以其中可能有错误，生产环境谨慎操作。

一、系统版本检查

1、查看当前系统的发行版

[root@gitserver gitlab-rails]# uname -a
[root@sh-chint-git02 ~]# cat /etc/*-release

2、判断gitlab版本

https://blog.csdn.net/liumiaocn/article/details/108139228

• 网页方式
  访问系统的根目录网址加help，例如: http://1.1.1.1/help

• 终端方式

  cd  /opt/gitlab/embedded/service/gitlab-rails/
  

  [root@gitserver gitlab-rails]# grep . *VERSION
  

3、规划升级路线

要升级要新的主版本，先升级到前一个主版本的最后一个次要版本是必须要，因为最后一个次要版本引入了后台迁移(gitlab的一些功能的变化都会在这里做预准备。

使用官方升级路径工具推算出升级路径
https://gitlab-com.gitlab.io/support/toolbox/upgrade-path

二、升级预览

1、为host添加gitlab源，这里建议使用清华源

（1） 备份原有的 GitLab yum 仓库配置文件（可选但建议）：

sudo cp /etc/yum.repos.d/gitlab-ce.repo /etc/yum.repos.d/gitlab-ce.repo.bak

（2） 修改镜像源配置文件

vim /etc/yum.repos.d/gitlab-ce.repo


[gitlab-ce]
name=GitLab CE Repository
baseurl=https://mirrors.tuna.tsinghua.edu.cn/gitlab-ce/yum/el7/
gpgcheck=1 #当 gpgcheck 设置为 1 时，Yum 会检查下载的 RPM 包是否经过 GPG（GNU Privacy Guard）签名，以确保下载的软件包的完整性和来源的可信度。
enabled=1 #当 enabled 设置为 1 时，Yum 会启用该仓库，允许从该仓库下载软件包。
gpgkey=https://packages.gitlab.com/gpg.key

使用官方源

curl -sS https://packages.gitlab.com/install/repositories/gitlab/gitlab-ce/script.rpm.sh | sudo 

（3） 清除 yum 缓存：

sudo yum clean all

这会清除 yum 的缓存，确保下次运行 yum 时会从新的镜像源获取数据。

（4） 更新 yum 缓存：

sudo yum makecache

这会更新 yum 的缓存，使它能够读取新的镜像源信息。

引用

2、升级之前检查

大版本的升级建议先在测试环境升级，无误之后再回到正式环境升级。

（1）gitlab升级前检查
在升级前和升级后分别执行升级前检查和升级后检查 确保GitLab的主要组件正常工作;

（2）检查后台迁移情况
该过程在升级过程中会自动进行
某些版本可能需要进行不同的迁移 在升级到新版本之前完成
引用

3、备份GitLab

（1）停止gitlab服务

sudo gitlab-ctl stop

（2）备份gitlab数据
备份时需要保持gitlab处于正常运行状态，直接执行gitlab-rake gitlab:backup:create进行备份
使用以上命令会在/var/opt/gitlab/backups目录下创建一个名称类似为1530156812_2018_06_28_10.8.4_gitlab_backup.tar的压缩包, 这个压缩包就是Gitlab整个的完整部分, 其中开头的1530156812_2018_06_28_10.8.4是备份创建的日期

sudo gitlab-rake gitlab:backup:create BACKUP=/<your_custom_backup_path>

（3）备份配置文件

/etc/gitlab/gitlab.rb 配置文件须备份
/var/opt/gitlab/nginx/conf nginx配置文件
/etc/postfix/main.cfpostfix 邮件配置备份

4、升级 GitLab。

（1）跳过自动备份(在已经手动备份，不需要自动备份的情况下使用)

sudo touch /etc/gitlab/skip-auto-backup

（2）查询可以获取到的版本

sudo yum list gitlab-ce

（3）升级到规划的下一个版本

sudo yum install gitlab-ce-*.*.*

（4）启动gitlab服务

sudo gitlab-ctl stop

（4）等待后台迁移任务
完成升级之后需要检查后台迁移是否完成

gitlab-rake db:migrate:status # 检查 GitLab 数据库中的迁移任务的执行状态。

（5）再次应用配置
gitlab升级中会自动应用新的配置，但是可以手动应用一下，确保无误

gitlab-ctl reconfigure

（6）再次检查后台是否迁移完成

gitlab-rake db:migrate:status # 检查 GitLab 数据库中的迁移任务的执行状态。

如果有未成功迁移的可以手动执行迁移

gitlab-rake db:migrate # 执行数据库迁移任务的，通常情况下，你不需要手动执行这个命令，因为 GitLab 在安装或升级过程中会自动执行数据库迁移任务。

ps:大型的系统可能需要多天进行背景迁移（后台迁移），据说在后台中可以看到进度。
(7)、进行系统检查
进行系统检查，确认无误可以继续进行下一次迁移

[引用](Upgrade GitLab by using the GitLab package | GitLab)

4、其他注意事项及说明

（1）、GitLab Runner 升级
将 GitLab Runner 升级到相同版本 作为您的 GitLab 版本。两个版本应该相同。

（2）、组件升级问题
在使用 yum install -y gitlab-ce-13.12.15 命令进行 GitLab CE 版本升级时，通常不需要手动升级 GitLab 组件。该命令会自动下载并安装指定版本的 GitLab CE 软件包，并将其安装到系统中。GitLab 组件（包括 GitLab Rails、GitLab Shell 等）会随着 GitLab CE 软件包一起安装和更新。

背景支持

1、gitlab系统检查

# 检查一般配置:
sudo gitlab-rake gitlab:check

# 确认加密的数据库值可以被解密:
sudo gitlab-rake gitlab:doctor:secrets  # 请确保在运行这个命令之前已经停止了 GitLab 服务，以免在检查过程中影响系统运行。命令执行完成后，你可以根据输出来进一步处理任何可能的问题。 

在GitLab UI中，检查:
Users can sign in. 用户可以登录。
项目列表是可见的。
可以访问项目问题和合并请求。
用户可以从GitLab克隆存储库。
用户可以将提交推送到GitLab。

2、后台迁移

后台迁移任务是指在软件升级或者版本更新过程中，系统对数据进行转换、更新或者重新组织的任务。这些任务通常是为了适应新版本的数据模型或者功能变更而执行的。
在进行升级之前，GitLab 会检查是否有尚未完成的后台迁移任务。如果存在这样的任务，GitLab 会提醒你，并建议你在升级之前等待这些任务完成。
这个检查信息的目的是确保在升级过程中不会影响到尚未完成的后台迁移任务。如果存在这样的任务，你可以选择等待它们完成后再进行升级，以避免潜在的问题和数据损失。

具体说明：
在 GitLab 中，有一些数据库迁移任务可能需要一段时间来完成，特别是对于大型的数据库或者数据量较大的情况。这些长时间运行的迁移任务通常会在后台进行，并且可能会影响到 GitLab 的性能和可用性。
在进行升级之前，GitLab 会检查是否有尚未完成的后台迁移任务。如果存在这样的任务，GitLab 会提醒你，并建议你在升级之前等待这些任务完成。
这个检查信息的目的是确保在升级过程中不会影响到尚未完成的后台迁移任务。如果存在这样的任务，你可以选择等待它们完成后再进行升级，以避免潜在的问题和数据损失。
检查是否存在迁移的方法
通过检查 db:migrate:status 命令的输出，你可以确定是否存在后台迁移任务，以及它们的执行状态。如果有未执行的迁移任务，你可以使用 db:migrate 命令来手动执行这些任务，以确保数据库的完整性和一致性。
列出后台是否存在正在运行的migration，检查迁移状态。

gitlab-rake db:migrate:status # 检查 GitLab 数据库中的迁移任务的执行状态。
gitlab-rake db:migrate # 执行数据库迁移任务的，通常情况下，你不需要手动执行这个命令，因为 GitLab 在安装或升级过程中会自动执行数据库迁移任务。

3、应用配置

每次升级完成之后执行 gitlab-ctl reconfigure

在 GitLab 的升级过程中，通常会涉及到一些配置文件的修改或者更新。虽然在升级过程中 GitLab 会尝试自动应用这些配置更改，但有时候可能会出现一些情况导致配置没有正确应用或者需要手动重新加载。

为了确保配置的正确应用，通常建议在升级完成后手动执行 gitlab-ctl reconfigure 命令，以重新加载配置文件并确保新的配置生效。这样可以避免因配置错误而导致的问题，并确保 GitLab 的服务能够正常运行。

虽然在一些情况下 GitLab 可能会尝试自动重新应用配置，但为了安全起见，最好还是在升级完成后手动执行 gitlab-ctl reconfigure，以确保配置的正确应用。这是一种保险措施，可以帮助避免潜在的问题并确保系统的稳定性。

4、处理正在运行的CI/CD管道和作业

经过检查服务器中没有安装此服务gitlab-runner,所以可以省略。

[root@gitserver ~]# sudo gitlab-runner status
sudo: gitlab-runner: command not found
[root@gitserver ~]# sudo /usr/local/bin/gitlab-runner status
sudo: /usr/local/bin/gitlab-runner: command not found

• 规划您的维护。

• 暂停运行器，或通过将以下内容添加到您的/etc/gitlab/gitlab.rb

  nginx['custom_gitlab_server_config'] = "location ^~ /api/v4/jobs/request {\n deny all;\n return 503;\n}\n" # 这会拒绝对 /api/v4/jobs/request 端点的访问，并返回一个 HTTP 503 状态码。
  

• 并使用以下命令重新配置 GitLab：

  sudo gitlab-ctl reconfigure
  

  等到所有作业都完成。

• 检查 GitLab Runner 的状态：

  sudo gitlab-runner status
  

5、升级到特定的版本可能需要人工干预

具体的可以查看gitlab官方文档。

（1）升级到GitLab 14

引用

• 升级到GitLab 14.8或更高版本，需要升级PostgreSQ补丁级别为12.7-13.3