从gitlab12.6.4升级到gitlab15.11.7

hunter0081

已于 2023-07-31 16:05:29 修改

阅读量3.2k

点赞数 3

文章标签： gitlab

于 2023-07-10 18:08:10 首次发布

本文链接：https://blog.csdn.net/cfh0081/article/details/131393441

版权

从gitlab12.6.4升级到gitlab15.11.7

一、升级前准备工作
二、升级操作

当前正在使用gitlab版本是12.6.4，是在2020年1月15日采用本机安装形式使用的，转眼间将近两年半了，考虑更新到15.11.7版本，并切换到采用docker方式部署，便于后续维护。考虑到中间跨度版本比较多，升级不会那么顺利，所以采用gitlab12.6.4版本安装包，在另外一台服务器上部署了一套gitlab服务，并使用当前正在使用的gitlab服务前面备份的包进行恢复，将相对较新的历史状态同步到了新服务上。

一、升级前准备工作

1.验证通用配置

执行下面命令，确保当前通用配置无阻碍升级问题：

sudo gitlab-rake gitlab:check

2.GitLab网页验证如下事项

(1) 用户可正常登录；

(2) 仓库项目列表可正常展示；

(3) 仓库项目问题列表及合并请求正常可用；

(4) 用户能正常从GitLab克隆仓库到本地；

(5) 用户可正常推送提交到GitLab。

3.执行备份操作

执行下面的命令进行备份，备份完毕之后，还需要将“/etc/gitlab/”目录下的“gitlab.rb”和“gitlab-secrets.json”文件进行手动拷贝备份，备份操作细节可参考GitLab基础：备份与恢复指南。

gitlab-backup create

在进行上述准备工作中，如发现存在问题，请先定位解决之后，再执行后续操作。

4.确定跨版本升级顺序

跨版本升级顺序如下：

GitLab 8: 8.11.Z > 8.12.0 > 8.17.7
GitLab 9: 9.0.13 > 9.5.10
GitLab 10: 10.0.7 > 10.8.7
GitLab 11: 11.0.6 > 11.11.8
GitLab 12: 12.0.12 > 12.1.17 > 12.10.14
GitLab 13: 13.0.14 > 13.1.11 > 13.8.8 > 13.12.15
GitLab 14: 14.0.12 > 14.3.6 > 14.9.5 > 14.10.5
GitLab 15: 15.0.5 > 15.1.6 (for GitLab instances with multiple web nodes) > 15.4.6 > 15.11.x
GitLab 16: latest 16.Y.Z

详情请参见官方升级顺序说明的“Upgrade paths”章节，后续可能会用到的参考链接罗列如下。
gitlab-ce docker url
containers-registries.conf.5.md
rpm安装包下载
 gitlab reconfigure 卡住 ruby_block[wait for redis service socket] action run
Run GitLab Runner in a container

二、升级操作

1.gitlab 12版本相关更新

查看gitlab 12版本子版本更新说明信息，和升级相关的重要信息摘录下如，详情可参考官方说明信息。

(1)12.8
PostgreSQL 11.7 is being shipped with the package in addition to 10.12 and 9.6.17. Both fresh installs and upgrades will still continue to use 10.12, but users can manually upgrade to 11.7 following the upgrade docs.
(2)12.10
PostgreSQL will automatically be upgraded to 11.x except for the following cases:
you are running the database in high_availability using repmgr.
your database nodes are part of GitLab Geo configuration.
you have specifically opted out using the /etc/gitlab/disable-postgresql-upgrade file outlined below.
To opt out you must execute the following before performing the upgrade of GitLab.
sudo touch /etc/gitlab/disable-postgresql-upgrade
Further details and procedures for upgrading PostgreSQL after install if not completed automatically can be found in the Database Settings notes.

考虑到12.8已经支持PostgreSQL 11.7，因此在升级过程中增加了12.8.9版本，避免后续因为数据库版本不兼容，而导致升级失败。在执行该升级之前，先运行下面的命令检查是否准备妥当（需要在gitlab正常启动情况下运行）：

gitlab-rake gitlab:check

实际执行之后，不符合信息结果如下：

Uploads directory tmp has correct permissions? ... no
  Try fixing it:
  sudo chown -R git /var/opt/gitlab/gitlab-rails/uploads
  sudo find /var/opt/gitlab/gitlab-rails/uploads -type f -exec chmod 0644 {} \;
  sudo find /var/opt/gitlab/gitlab-rails/uploads -type d -not -path /var/opt/gitlab/gitlab-rails/uploads -exec chmod 0700 {} \;
  For more information see:
  doc/install/installation.md in section "GitLab"
  Please fix the error above and rerun the checks.
Init script exists? ... skipped (omnibus-gitlab has no init script)
Init script up-to-date? ... skipped (omnibus-gitlab has no init script)
Projects have namespace: ...

根据上述提示信息，执行相应命令修复问题。另外，为了避免每次都备份浪费时间，执行下面命令跳过备份操作。

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

(1) 升级到12.8.9版本

在root帐户下运行下面命令：

gitlab-ctl stop
rpm -Uvh gitlab-ce-12.8.9-ce.0.el7.x86_64.rpm

运行结果如下：

Upgrade complete! If your GitLab server is misbehaving try running
  sudo gitlab-ctl restart
before anything else.
The automatic database backup was skipped as requested.
You may enable it again anytime by running the following command:
  sudo rm /etc/gitlab/skip-auto-backup


GitLab now ships with a newer version of PostgreSQL (11.7), but it is not yet
enabled by default. To upgrade, please see:
https://docs.gitlab.com/omnibus/settings/database.html#upgrade-packaged-postgresql-server

执行如下命令：

gitlab-ctl reconfigure
gitlab-ctl restart

然后可参考前面“升级前准备工作”的内容，检查升级完成后，服务是否正常，并进行备份操作。
前述操作完成后，先执行下面命令确保环境是正常的：

gitlab-rake gitlab:check

接下来运行下面的命令升级PostgreSQL版本：

gitlab-ctl pg-upgrade -V 11

执行完毕结果如下：

==== Upgrade has completed ====
Please verify everything is working and run the following if so
sudo rm -rf /var/opt/gitlab/postgresql/data.10
sudo rm -f /var/opt/gitlab/postgresql-version.old

验证正常即可调用上述命令，删除相关文件，如果想了解pg-upgrade详细用法，可执行下面命令查看：

gitlab-ctl pg-upgrade -h

(2) 升级到12.10.14版本

在root帐户下运行下面命令（先确保环境是正常的，再停止服务，最后执行新版本安装操作）：

gitlab-rake gitlab:check
gitlab-ctl stop
rpm -Uvh gitlab-ce-12.10.14-ce.0.el7.x86_64.rpm

运行结果如下：

Upgrade complete! If your GitLab server is misbehaving try running
  sudo gitlab-ctl restart
before anything else.
The automatic database backup was skipped as requested.
You may enable it again anytime by running the following command:
  sudo rm /etc/gitlab/skip-auto-backup

继续执行下面命令：

gitlab-ctl reconfigure
gitlab-ctl restart

参考前面“升级前准备工作”的内容，检查升级完成后，服务是否正常。

2.gitlab 13版本相关更新

(1) 升级到13.0.14版本

在root帐户下运行下面命令：

gitlab-rake gitlab:check
gitlab-ctl stop
rpm -Uvh gitlab-ce-13.0.14-ce.0.el7.x86_64.rpm

运行结果如下：

Upgrade complete! If your GitLab server is misbehaving try running
  sudo gitlab-ctl restart
before anything else.
The automatic database backup was skipped as requested.
You may enable it again anytime by running the following command:
  sudo rm /etc/gitlab/skip-auto-backup

实际运行发现存在异常，未找到解决方案，直接继续往下一个版本升级，出错信息可参考gitlab官方问题链接。
继续执行下面命令：

gitlab-ctl reconfigure
gitlab-ctl restart

(2) 升级到13.1.11版本

在root帐户下运行下面命令：

gitlab-rake gitlab:check
gitlab-ctl stop
rpm -Uvh gitlab-ce-13.1.11-ce.0.el7.x86_64.rpm

运行结果如下：

Upgrade complete! If your GitLab server is misbehaving try running
  sudo gitlab-ctl restart
before anything else.
The automatic database backup was skipped as requested.
You may enable it again anytime by running the following command:
  sudo rm /etc/gitlab/skip-auto-backup

使用“gitlab-ctl tail”命令查看发现新的报错：

==> /var/log/gitlab/gitlab-workhorse/current <==
{"correlation_id":"sn2YhtGFWO5","duration_ms":0,"error":"badgateway: failed to receive response: dial unix /var/opt/gitlab/gitlab-rails/sockets/gitlab.socket: connect: connection refused","level":"error","method":"GET","msg":"error","time":"2023-06-08T19:59:39+08:00","uri":"/"}
{"correlation_id":"sn2YhtGFWO5","duration_ms":0,"host":"192.168.13.119","level":"info","method":"GET","msg":"access","proto":"HTTP/1.1","referrer":"","remote_addr":"127.0.0.1:0","remote_ip":"127.0.0.1","status":502,"system":"http","time":"2023-06-08T19:59:39+08:00","uri":"/","user_agent":"Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/109.0.0.0 Safari/537.36","written_bytes":2940}

调用“vim /etc/gitlab/gitlab.rb”命令，将配置中原本的

# puma['port'] = 8080

调整成下面的形式解决问题，问题核心是puma使用的端口8080被jenkins占用了，无法正常提供服务。

puma['port'] = 8282

解决思路参考了官方对应的问题链接。
运行正常之后调用“gitlab-rake gitlab:check”有如下报错：

All projects are in hashed storage? ... no
  Try fixing it:
  Please migrate all projects to hashed storage
  as legacy storage is deprecated in 13.0 and support will be removed in 14.0.
  For more information see:
  doc/administration/repository_storage_types.md

先执行备份命令：

gitlab-backup create

备份，方便失败后恢复。

执行下面命令，进行存储库迁移：

gitlab-rake gitlab:storage:migrate_to_hashed

执行成功后，再次执行，会提示如下内容：

#There are no projects requiring storage migration. Nothing to do!

全部迁移成功，以下命令查看所列出的项目总数与页面的理应一致

gitlab-rake gitlab:storage:hashed_projects

查看，全部迁移成功以下两条命令应该为 0

gitlab-rake gitlab:storage:legacy_projects
gitlab-rake gitlab:storage:legacy_attachments

列出传统存储的项目以及附件

gitlab-rake gitlab:storage:list_legacy_projects
gitlab-rake gitlab:storage:list_legacy_attachments

但实际上这边遇到了一个奇怪的问题，每次迁移时都提示成功，多次执行都返回如下内容：

Enqueuing migration of 41 projects in batches of 200. Done!

解决办法如下：
如果传统存储转HASH显示成功，实际没有成功的情况，可以更新下令牌重新转HASH就可以。
具体如下：

#进入数据库终端
gitlab-rails dbconsole
 
#执行清空命令
UPDATE projects SET runners_token = null, runners_token_encrypted = null;
 
#退出
exit;

然后重新执行 hash转储命令，校验后发现已经迁移成功！

gitlab-rake gitlab:storage:migrate_to_hashed

解决上述问题主要参考了gitlab 13.x 升级至 14.x 哈希存储转换问题和
Repository storage Rake tasks。
执行下面命令重启：

gitlab-ctl restart

(3) 升级到13.5.7版本

在root帐户下运行下面命令：

gitlab-rake gitlab:check
gitlab-ctl stop
rpm -Uvh gitlab-ce-13.5.7-ce.0.el7.x86_64.rpm

运行结果如下：

Upgrade complete! If your GitLab server is misbehaving try running
  sudo gitlab-ctl restart
before anything else.
The automatic database backup was skipped as requested.
You may enable it again anytime by running the following command:
  sudo rm /etc/gitlab/skip-auto-backup

运行下面命令重启：

gitlab-ctl restart

整体检查是否正常，发现使用帐号密码无法正常登录到gitlab网站，需要验证email，先更新email配置再发送邮件验证，邮件配置可参考将redhat6.8下面的gitlab 8.8.9迁移到centos7.6并升级到gitlab 12.1.4版本。
执行下面命令升级postgresql版本：

sudo gitlab-ctl pg-upgrade -V 12

执行结果如下：

==== Upgrade has completed ====
Please verify everything is working and run the following if so
sudo rm -rf /var/opt/gitlab/postgresql/data.11
sudo rm -f /var/opt/gitlab/postgresql-version.old

整体检查正常后，调用上述命令删除老旧文件。

(4) 升级到13.8.8版本

在root帐户下运行下面命令：

gitlab-rake gitlab:check
gitlab-ctl stop
rpm -Uvh gitlab-ce-13.8.8-ce.0.el7.x86_64.rpm

运行结果如下：

Upgrade complete! If your GitLab server is misbehaving try running
  sudo gitlab-ctl restart
before anything else.
The automatic database backup was skipped as requested.
You may enable it again anytime by running the following command:
  sudo rm /etc/gitlab/skip-auto-backup

Help us improve the upgrade experience, let us know how we did with a 1 minute survey:
https://gitlab.fra1.qualtrics.com/jfe/form/SV_0Hwcx9ncPfygMfj?installation=omnibus&release=13-8

调用下面命令重启相关服务：

gitlab-ctl restart

整体检查是否正常：

gitlab-rake gitlab:check

执行备份命令备份：

gitlab-backup create

方便失败后恢复。

3.切换到docker方式运行

准备切换到docker方式运行，主要参考官方文档installation-using-docker。
注意：如果使用podman代替docker执行，请确保podman版本是4.4.2或更高的版本，否则后续在拉取部分gitlab镜像的时候会直接报错，无法正常拉取。
调用下面命令拉取镜像，完整镜像地址为“docker.io/gitlab/gitlab-ce:13.8.8-ce.0”：

docker pull gitlab/gitlab-ce:13.8.8-ce.0

将需要用到的docker内部的文件夹权限提前配置好（如果中途有变化，也需要一并调整）：

sudo chmod -R 777 /srv/gitlab/config
sudo chmod -R 777 /srv/gitlab/logs
sudo chmod -R 777 /srv/gitlab/data

配置邮件相关参数样例如下：
gitlab_rails[‘gitlab_email_from’] = ‘gitlab@example.com’
gitlab_rails[‘smtp_enable’] = true
gitlab_rails[‘smtp_address’] = “smtp.mxhichina.com”
gitlab_rails[‘smtp_port’] = 465
gitlab_rails[‘smtp_user_name’] = “gitlab@example.com”
gitlab_rails[‘smtp_password’] = “yourPassword”
gitlab_rails[‘smtp_domain’] = “mxhichina.com”
gitlab_rails[‘smtp_authentication’] = “login”
gitlab_rails[‘smtp_enable_starttls_auto’] = true
gitlab_rails[‘smtp_tls’] = true
gitlab_rails[‘smtp_openssl_verify_mode’] = ‘none’
参照上面的例子，结合gitlab采用docker compose启动样例，可直接调用下面的命令生成需要的文件（下面是样例，需要根据实际情况做必要的调整，可参考Configuration options for the GitLab Linux package）：

cat > /root/sh/gitlab/docker-compose.yml << EOF
version: '1'
services:
  gitlab:
    image: 'docker.io/gitlab/gitlab-ce:13.8.8-ce.0'
    restart: always
    hostname: 'gitlab.example.com'
    environment:
      GITLAB_OMNIBUS_CONFIG: |
        external_url 'http://gitlab.example.com'
        # gitlab_rails['gitlab_shell_ssh_port'] = 2224
        gitlab_rails['gitlab_email_from'] = 'gitlab@example.com'
        gitlab_rails['smtp_enable'] = true
        gitlab_rails['smtp_address'] = "smtp.mxhichina.com"
        gitlab_rails['smtp_port'] = 465
        gitlab_rails['smtp_user_name'] = "gitlab@example.com"
        gitlab_rails['smtp_password'] = "yourPassword"
        gitlab_rails['smtp_domain'] = "mxhichina.com"
        gitlab_rails['smtp_authentication'] = "login"
        gitlab_rails['smtp_enable_starttls_auto'] = true
        gitlab_rails['smtp_tls'] = true
        gitlab_rails['smtp_openssl_verify_mode'] = 'none'
    ports:
      - '80:80'
      - '2224:22'
    volumes:
      - '/srv/gitlab/config:/etc/gitlab'
      - '/srv/gitlab/logs:/var/log/gitlab'
      - '/srv/gitlab/data:/var/opt/gitlab'
    shm_size: '256m'
    privileged: true
EOF

在“/root/sh/gitlab/”目录下执行命令：

docker compose up -d

其他相关命令说明如下：
停止容器：

docker compose down

看看容器日志有没有什么异常或报错：

docker compose logs -f -t --tail 100

进入容器：

docker exec -it gitlab-gitlab-1 /bin/bash

重启容器：

docker restart gitlab-gitlab-1

(1) 确保gitlab 22端口可正常访问

调用下面命令先进入容器控制台：

docker exec -it gitlab-gitlab-1 /bin/bash

在容器中执行下面命令获取Gitlab 容器中 git 用户的 UID 以及 GID：

cat /etc/passwd | awk -F':' '{if($1=="git") printf("uid: %s; gid: %s\n"), $3, $4}'

在容器中获取到git用户的UID及GID之后（默认应该是998），可以使用下面的命令：

cat /etc/passwd | grep 998

查看该用户ID是否被占用。可以通过下面的命令查看组ID是否被占用：

cat /etc/group | grep 998

如果已经被占用，则需要修改成其他ID，我本机当前占用的用户ID是“polkitd”，group ID也是“render”，修改UID可调用下面命令：

usermod -u 1000 polkitd

直接报错：

usermod: user polkitd is currently used by process 659

查看进程：

ps -ef|grep 659

杀掉进程后再重新调用上面命令修改UID：

kill -9 659

接下来调用下面命令更新相关文件信息：

find / -user 998 -exec chown -h polkitd {} \;

修改GID（render）调用下面命令：

groupmod -g 1000 render

接下来调用下面命令更新相关文件信息：

find / -group 998 -exec chgrp -h render {} \;

修改GID和UID可参考Linux中修改用户UID和组GID的方法。

使用下面指令创建git 用户并指定home目录为 /home/git （在 root 用户下）：

groupadd -g 998 git
useradd -m -u 998 -g git -s /bin/sh -d /home/git git

git用户组和用户相关操作样例如下：

passwd git   # 修改密码
su - git     # 切换git用户
userdel git  # 删除用户
groupdel git # 删除用户组

在宿主机上执行下面命令，将容器中的文件映射到/home/git中：

su - git
mkdir -p /srv/gitlab/data/.ssh
ln -sf /srv/gitlab/data/.ssh /home/git/.ssh

调用下面命令，切换到 git 用户并生成密钥对：

su - git
ssh-keygen #然后一路回车

然后将公钥加入 authorized_keys

cat ~/.ssh/id_rsa.pub >> ~/.ssh/authorized_keys

在本机的 /opt/gitlab/embedded/service/gitlab-shell/bin 目录下创建一个名为 gitlab-shell 的脚本，命令如下：

sudo mkdir -p /opt/gitlab/embedded/service/gitlab-shell/bin

使用命令“vim /opt/gitlab/embedded/service/gitlab-shell/bin/gitlab-shell”编辑内容如下（使用cat << EOF形式生成文件如有变量会出现变量被替换的负作用，这一点需要考虑）：

#!/bin/sh

ssh -i /home/git/.ssh/id_rsa -p 2224 -o StrictHostKeyChecking=no git@127.0.0.1 "SSH_ORIGINAL_COMMAND=\"$SSH_ORIGINAL_COMMAND\" $0 $@"

最后，重启容器即可生效：

docker compose up -d

上述操作参考链接如下：
Docker运行Gitlab与Host共享22端口（使用该方式更优 20230614 10：46）
Docker-Gitlab 与主机共用 ssh 的 22 端口
 使用docker方式安装的gitlab配置ssh
docker安装gitlab并用nginx代理访问

(2) 使用前面备份的13.8.8版本的备份数据恢复到新的docker容器服务

根据实现情况调整容器内gitlab服务备份文件存放目录配置：

gitlab_rails['backup_path'] = "/var/opt/gitlab/backups"

调用下面命令恢复数据：

gitlab-rake gitlab:backup:restore BACKUP=1686296972_2023_06_09_13.8.8

报错信息如下：

Restoring PostgreSQL database gitlabhq_production ... ERROR:  must be owner of extension pg_trgm
ERROR:  must be owner of extension btree_gist
ERROR:  must be owner of extension btree_gist
ERROR:  must be owner of extension pg_trgm

解决方案如下：
1.使用下面命令修改 postgresql.conf

vim /var/opt/gitlab/postgresql/data/postgresql.conf

修改对应配置如下：

listen_addresses = '*'

说明：修改端口监听地址，默认监控 localhost，* 代表 all
2.修改 pg_hba.conf

vim /var/opt/gitlab/postgresql/data/pg_hba.conf

增加配置：

local   all         all                               trust
host    all         all                               127.0.0.1/32 trust

3.在容器中重启 gitlab

gitlab-ctl restart

4.修改 postgresql 权限

$ su - gitlab-psql
$ /opt/gitlab/embedded/bin/psql -h 127.0.0.1 gitlabhq_production

gitlabhq_production=# ALTER USER gitlab WITH SUPERUSER;
ALTER ROLE
gitlabhq_production=# \q

$ exit

上面执行"su - gitlab-psql"如果没有配置privileged 参数会出现下面错误：

su: System error

解决方案如下：
docker运行时增加–privileged参数，样例如下：
docker run --name xxx --privileged xxx
参考链接如下：
Docker 容器中运行 su 出现 system error 问题排查
 docker-compose 中 volumes、environment、privileged、network_mode的使用
 Gitlab 数据备份和还原（填坑版）
When the secrets file is lost
Restore GitLab

其他说明：使用nginx代理gitlab 22端口使用gitlab有问题，当前采用直接在DNS域名解析那里处理，问题已解决；（20230616 12：43）

(3) docker容器运行服务13.8.8备份数据

Docker compose升级官方文档说明如下：

Upgrade GitLab using Docker compose
To upgrade GitLab that was installed using Docker Compose:
Take a backup. As a minimum, back up the database and the GitLab secrets file.
docker exec -t gitlab-gitlab-1 gitlab-backup create
或者分两步执行：
docker exec -it gitlab-gitlab-1 /bin/bash
gitlab-backup create

Download the newest release and upgrade your GitLab instance:
docker compose pull
docker compose up -d

参考链接：
docker升级
 docker容器中的gitlab升级详解

依次调用下面命令拉了所有需要的镜像文件：

docker pull gitlab/gitlab-ce:13.12.15-ce.0
docker pull gitlab/gitlab-ce:14.0.12-ce.0
docker pull gitlab/gitlab-ce:14.3.6-ce.0
docker pull gitlab/gitlab-ce:14.9.5-ce.0
docker pull gitlab/gitlab-ce:14.10.5-ce.0
docker pull gitlab/gitlab-ce:15.0.5-ce.0
docker pull gitlab/gitlab-ce:15.1.6-ce.0
docker pull gitlab/gitlab-ce:15.4.6-ce.0
docker pull gitlab/gitlab-ce:15.11.7-ce.0

4.使用 Docker compose 升级极狐GitLab

要升级使用 Docker Compose 安装的极狐GitLab：
进行备份，作为最低要求，备份数据库和极狐GitLab secrets 文件。
下载最新版本并升级您的极狐GitLab 实例：

docker compose pull
docker compose up -d

如果您使用标签代替，则需要先编辑 docker-compose.yml，具体步骤如下：
(1) 检查没问题可停止服务

docker exec -it gitlab-gitlab-1 /bin/bash
gitlab-rake gitlab:check
docker compose stop

(2) 下载镜像

docker pull gitlab/gitlab-ce:13.12.15-ce.0

(3) 更新docker-compose.yml文件，增加版本编号和image名称，如下所示：

version: '2'
services:
gitlab:
  image: 'docker.io/gitlab/gitlab-ce:13.12.15-ce.0'
......

(4) 重启服务

docker compose up -d

(5) 查看日志确认进展

docker compose logs -f -t --tail 100

参考链接：
极狐GitLab Docker 镜像

5.podman 4.4.2以下的版本拉取image在拉取1GB数据层的时候会报错问题规避

podman 4.4.2以下的版本拉取image在拉取1GB数据层的时候会报错，当前安装docker-ce进行规避。
注意：如果是在anolis os 8（或者centos8）上安装docker报下面这类的错误：

问题: 安装的软件包的问题 buildah-1:1.26.2-1.0.1.module+an8.7.0+11008+881d4b66.x86_64
  - 软件包 buildah-1:1.26.2-1.0.1.module+an8.7.0+11008+881d4b66.x86_64 需要 runc >= 1.0.0-26，但没有提供者可以被安装
  - 软件包 buildah-1:1.29.1-2.0.1.module+an8.8.0+11084+6fc06be3.x86_64 需要 runc >= 1.0.0-26，但没有提供者可以被安装
  - 软件包 buildah-1:1.27.3-1.0.1.module+an8.7.0+11023+66eacf17.x86_64 需要 runc >= 1.0.0-26，但没有提供者可以被安装
  - 软件包 containerd.io-1.6.4-3.1.el8.x86_64 与 runc（由 runc-1:1.1.3-3.0.1.module+an8.7.0+11008+881d4b66.x86_64 提供）冲突
  - 软件包 containerd.io-1.6.4-3.1.el8.x86_64 淘汰了 runc 提供的 runc-1:1.1.3-3.0.1.module+an8.7.0+11008+881d4b66.x86_64
  - 软件包 containerd.io-1.6.4-3.1.el8.x86_64 与 runc（由 runc-1:1.1.4-1.0.1.module+an8.7.0+11023+66eacf17.x86_64 提供）冲突
  - 软件包 containerd.io-1.6.4-3.1.el8.x86_64 淘汰了 runc 提供的 runc-1:1.1.4-1.0.1.module+an8.7.0+11023+66eacf17.x86_64

那大概率是系统中还有自带的podman，需要执行下面命令卸载后再进行安装操作：

yum erase -y podman buildah

1.先进行必要升级：

yum update -y

2.安装 Docker 所需依赖：

yum install -y yum-utils device-mapper-persistent-data lvm2

3.添加阿里云的仓库：

yum-config-manager --add-repo http://mirrors.aliyun.com/docker-ce/linux/centos/docker-ce.repo

4.安装 Docker：

yum -y install docker-ce

5.启动 Docker：

systemctl start docker

6.将 Docker 服务设为开机自启动：

systemctl enable docker

参考链接：
Linux(CentOS8)上安装 Docker 详细步骤

6.docker运行gitlab版本升级及遇到的相关问题

(1) 升级到13.12.15-ce.0后，进入页面发现如下内容：

Service templates are deprecated and will be removed in GitLab 14.0.
You should migrate to Project integration management, available at Settings > Integrations.

参考已经搭建的gitlab服务网址链接解决（下面的链接需要替换成实际部署的域名）：
http://gitlab.example.com/help/user/admin_area/settings/project_integration_management
参照操作后继续。

参照前面提到的使用docker compose升级的步骤，依次向上升级，直到到达目标版本。

升级到15.11.7-ce.0报错信息如下：
gitlab-gitlab-1 | 2023-06-25T02:24:20.635482265Z [2023-06-25T02:24:20+00:00] FATAL: RuntimeError: gitlab_rails[‘smtp_tls’] and gitlab_rails[‘smtp_enable_starttls_auto’] are mutually exclusive. Set one of them to false. SMTP providers usually use port 465 for TLS and port 587 for STARTTLS.
gitlab-gitlab-1 exited with code 0

Seems to be that in your /etc/gitlab/gitlab.rb you have both the above options configured with true, so as the message says, you need to edit gitlab.rb file and set one of them to false. Then after editing, run: gitlab-ctl reconfigure gitlab-ctl restart

参照上面提示信息解决了问题，问题解决参考链接：
Error upgrade to: 15.11.4

(2) 使用docker compose方式启动容器后直接使用docker重启容器方式邮件功能失效

当前使用docker compose启动gitlab容器，中间需要重启容器，直接使用docker restart 命令重启了容器，然后发现邮件功能无法正常使用（考虑与该行为有关），后续统一使用docker compose管理，避免使用docker命令直接管理容器。docker compose相关操作样例如下：
重启单个容器：
docker compose restart gitlab
设置在杀死容器之前等待停止的时间(以秒为单位)：
docker compose restart -t 30 worker
参考链接：
docker-compose重新启动单个容器

(3) 点击前面配置了hook工程Settings中Webhooks直接跳转到500页面

执行标题中描述的操作后，使用下面命令查看日志：

docker compose logs -f -t --tail 100

发现对应错误信息如下：
> /var/log/gitlab/gitlab-rails/production.log <

ActionView::Template::Error ():
5: .row
6: .col-md-8.col-lg-7
7: %strong.light-header
8: = hook.url
9: - if hook.rate_limited?
10: = gl_badge_tag(_(‘Disabled’), variant: :danger, size: :sm)
11: - elsif hook.permanently_disabled?
搜索到解决方案如下：
1.执行下面命令进入容器

docker exec -it gitlab-gitlab-1 /bin/bash

2.使用下面命令进入数据库控制台

gitlab-rails db

从gitlab出错的工程中获取到工程ID：
在这里插入图片描述
在数据库控制台执行“select id from web_hooks where project_id=13;”，获取到对应的hook ID。

gitlabhq_production=# select id from web_hooks where project_id=13;
 id 
----
 10
 12
 28
(3 rows)

3.获取访问token
可以使用项目级的访问token，也可使用全局性的token，下图是获取项目级token入口：
在这里插入图片描述
4.在linux终端上使用curl命令调用api执行删除操作
curl --header “Private-Token: the_token_you_got” -X DELETE http://gitlab.example.com/api/v4/projects/13/hooks/10
curl --header “Private-Token: the_token_you_got” -X DELETE http://gitlab.example.com/api/v4/projects/13/hooks/12
curl --header “Private-Token: the_token_you_got” -X DELETE http://gitlab.example.com/api/v4/projects/13/hooks/28
至此问题解决，重新刷新gitlab上有问题的工程页面及可正常跳转。

问题解决参考链接：
GitLab - 升级gitlab 版本后项目的webhook等页面显示500问题

(4) 使用gitlab-ci打包完成后报“Uploading artifacts as “archive” to coordinator… 413 Request Entity Too Large”错误

具体修改配置方式见下图：
在这里插入图片描述
调整完毕后再看一下效果。
参考链接：
https://gitlab.com/gitlab-org/gitlab-runner/-/issues/2584

hunter0081

关注

3
点赞
踩
10

收藏

觉得还不错? 一键收藏
0
评论
从gitlab12.6.4升级到gitlab15.11.7

当前正在使用gitlab版本是12.6.4，是在2020年1月15日采用本机安装形式使用的，转眼间将近两年半了，考虑更新到15.11.7版本，并切换到采用docker方式部署，便于后续维护。考虑到中间跨度版本比较多，升级不会那么顺利，所以采用gitlab12.6.4版本安装包，在另外一台服务器上部署了一套gitlab服务，并使用当前正在使用的gitlab服务前面备份的包进行恢复，将相对较新的历史状态同步到了新服务上。
复制链接

扫一扫