Docker中gitlab容器版本升级中遇到的问题总结_docker升级gitlab 14.3.6失败

Docker中gitlab容器版本升级中遇到的问题总结

从gitlab 11.3.4升级到gitlab17.2.1过程中遇到的问题以及解决方案总结

---

---

前言

docker中gitlab容器升级，在版本升级过程中由于数据结构，存储方式等变化导致在使用脚本对版本升级时出现各种问题，文章主要记录一下我在gitlab版本升级过程中遇到的各种问题，以及解决方案。
官方升级路径：11.3.4–>11.11.8–>12.0.12–>12.1.17–>12.10.14–>13.0.14–>13.1.14–>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.8–>16.7.9–>16.11.7–>17.2.1
级前期准备。(主要就是备份相关数据和配置文件)
gitlab-rake gitlab:backup:create
cp /etc/gitlab/gitlab.rb /etc/gitlab/gitlab.rb.bak

---

一、gitlab 13.12.15-ce升级到gitlab14.0.12遇到的问题

在gitlab 13.12.15-ce升级到gitlab 14.0.12-ce由于存储方式改变，需要提前将传统存储转至 hash 存储，如果没有提前转换，会报以下错误：
提示：
Legacy storage is no longer supported. Please migrate your data to hashed storage.
Check https://docs.gitlab.com/ee/administration/raketasks/storage.html#migrate-to-hashed-storage for details.

13.12.15 版 默认启用了 hash 存储，软件内部会自动做数据迁移，从传统存储转至 hash 存储，迁移进度查看在 web 页面，” 设置 → 监控 → 后台任务 “，查看。这其中也会出现迁移失败，这时候需要手动检查并修复
手动 存储库迁移操作如下：

##进入gitlab容器后运行以下命令：
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 21 projects in batches of 200. Done!  
（未完成转化项目数可能是任意数字）
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

1.导致部分项目存储未被转为hash存储需要更新下令牌重新转HASH就可以，处理方式如下：

#进入数据库终端
gitlab-rails dbconsole 
#执行清空命令
UPDATE projects SET runners_token = null, runners_token_encrypted = null;
#退出
exit;
 稍等会，然后重新执行 hash转储命令，校验后发现已经迁移成功！ 
gitlab-rake gitlab:storage:migrate_to_hashed

1
2
3
4
5
6
7
8
9

2.如果存储库迁移失败错误原因为 ”项目为 read-only “ 处理方式如下：

#进入控制台
gitlab-rails console
#查找只读库
projects = Project.where(repository_read_only: true)
#更改只读库
projects.each do |p|
  p.update!(repository_read_only:nil)
end
#退出
exit
稍等会，然后重新执行 hash转储命令，校验后发现已经迁移成功！ 
gitlab-rake gitlab:storage:migrate_to_hashed
迁移后，两步认证报错
#清空两步认证信息
gitlab-rails runner 'User.find_each(&:disable_two_factor!)'
#重启服务
gitlab-ctl reconfigure
gitlab-ctl restart
#重启docker
docker restart gitlab

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

二、gitlab 14.0.12升级14.3.6遇到的问题

1.gitlab 14.0.12升级14.3.6提示错误:Error executing action run on resource ‘bash[migrate gitlab-rails]

这个错误是在14.0.12升级14.3.6之后会在监控-后台-后台迁移里面生成多个任务，（升级大概花费半个小时左右）升级完毕等待所有任务执行完毕之后在进行后续升级就不会报错了，升级完成如下所示：

版本升级后，建议登陆查看监控-后台迁移情况，等待后台迁移完成后，在进行停机，删除，更新新版本镜像

三、gitlab 15.4.6升级到15.11.13遇到问题

1.查看日志报错如下：

ERROR: Running exception handlers
There was an error running gitlab-ctl reconfigure:
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.
Running handlers complete

• smtp_tls：当设置为 true 时，GitLab 将使用 SMTP 协议的 TLS 加密方式连接到 SMTP 服务器。这通常与 SMTP 服务器的 465 端口一起使用。
• smtp_enable_starttls_auto：当设置为 true 时，GitLab 将在连接 SMTP 服务器后尝试启动 TLS 加密（如果服务器支持）。这通常与 SMTP 服务器的 587 端口一起使用。

2.解决步骤

• 确定你的 SMTP 服务器配置：
  查看你的 SMTP 提供商的文档，了解他们支持哪种加密方式（TLS 或 STARTTLS）以及相应的端口号。
• 修改 GitLab 配置文件：
  登录到你的 GitLab 服务器。
  编辑 GitLab 的配置文件（通常位于 /etc/gitlab/gitlab.rb）。
  根据你的 SMTP 提供商的要求，将 gitlab_rails[‘smtp_tls’] 或gitlab_rails[‘smtp_enable_starttls_auto’] 设置为 false。例如，如果你的 SMTP 服务器支持 STARTTLS 并使用 587 端口，你可以将 gitlab_rails[‘smtp_tls’] 设置为 false，并确保 gitlab_rails[‘smtp_enable_starttls_auto’] 为 true。
  重新配置 GitLab：
  保存配置文件并退出编辑器。
  运行 sudo gitlab-ctl reconfigure 来应用更改。
  验证配置：
  检查 GitLab 的日志文件（如 /var/log/gitlab/gitlab-rails/production.log），确认没有关于 SMTP 配置的错误。
  可以尝试发送一封测试邮件来验证 SMTP 配置是否成功。

四、gitlab-ce 15.11.13升级到16.3.8遇到问题

1.Unexpected Error:

 ThreadError: can't create Thread: Operation not permitted
1

通过网上搜索，说是因为docker版本低造成没有权限导致的，解决方案如下：
需要在运行容器时添加一下参数，将docker容器提权到root

--privileged=true #添加参数，将docker容器提权到root
1

2.gitlab-ce15.11.13使用的postgresql版本是12.14或者12.xx在升级到gitlab-ce 16.3.8报错

PG::ConnectionBad: could not connect to server: Connection refused
    Is the server running locally and accepting
    connections on Unix domain socket "/var/opt/gitlab/postgresql/.s.PGSQL.5432"?
原因：从 GitLab 16开始就不支持 PostgreSQL 12。在升级到 GitLab 16.0或更高版本之前，
至少将 PostgreSQL 升级到13.xx版本
1
2
3
4
5

因此在gitlab-ce 15.11.13升级到16.3.8前，需要手动将postgresql版本升级到13（正常情况下，版本升级的时候postgresql是会跟着版本升级的，如果遇到没有跟着gitlab版本升级，需要手动升级）操作如下

进入容器
docker exec -it <容器> /bin/bash
查看PostgreSQL版本
/opt/gitlab/embedded/bin/postgres --version
升级到PostgreSQL13.0以上
gitlab-ctl pg-upgrade -V 13
若提示报错： /var/opt/gitlab/postgresql/data.13 is not empty. Move or delete this directory to proceed with upgrade
把data.13删除即可：rm -rf /var/opt/gitlab/postgresql/data.13
再执行：gitlab-ctl pg-upgrade -V 13

如果手动升级，报错could not add execute permission to file "./analyze_new_cluster.sh": Operation not permitted
切换到目录/var/opt/gitlab/postgresql，查看指定的文件的所属用户和组是否为996或者gitlab-psql，如果不是，修改报错文件的所属用户和组
cd /var/opt/gitlab/postgresql
chown gitlab-psql:gitlab-psql analyze_new_cluster.sh
或者
chown 996:996 analyze_new_cluster.sh
此外delete_old_cluster.sh和update_extensions.sql文件可能也需要修改，参考以上命令，
修改完成后，再次执行
gitlab-ctl pg-upgrade -V 13

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

五、关于无法拉取镜像问题处理（2024.07.28）

由于很多docker镜像源被关闭，导致无法正常拉取所需的gitlab镜像，以下是通过测试目前依旧可以使用的镜像源。
在gitlab-ce:14.3.6以及版本以下，我配置使用的阿里云镜像加速可以正常使用
获取方式可以自行登陆阿里云账号–容器镜像服务-镜像工具–镜像加速器中获取相关配置。
pull gitlab-ce:14.9.5时发现依旧超时，经过多次查找验证，发现以下源依旧可以使用，配置如下：
tee /etc/docker/daemon.json <<EOF
{
“registry-mirrors”: [
“https://hub.uuuadc.top”,
“https://docker.anyhub.us.kg”,
“https://dockerhub.jobcher.com”,
“https://dockerhub.icu”,
“https://docker.ckyl.me”,
“https://docker.awsl9527.cn”
]
}
EOF

参考链接：https://zhuanlan.zhihu.com/p/704011584

---

总结

后续踩坑继续增加