标签：gitlab https Omnibus 8.8 GitLab 更新版本 com

引文

虽然本意是想要从更新runner开始的，但是自装完runner之后（我直接装了最新的版本）提示只有GitLab10以后的版本才能使用，才出现接下来的一堆东西。对于这种情况的解决方案无非有两种，更新GitLab版本或者降低Runner的版本，总之是一项向着另一项进行适配罢了，所以我也非常毫不犹豫的选择了更新GitLab的版本（看着不爽hhh），也算是从刚对GitLab入门的小白到稍微了解了一些这个应用的大致状况。

一些有必要预先理解的东西

操作系统 CentOS 7
基于Omnibus的升级
版本更新需要依照主版本号分阶段更新（有一种模式是保持定期更新，每周或每个月进行一次更新，可以稍微缓解下第五条提到的漏洞问题）
多阶段有两个工具可以直接查看，在更新章节（见第七条）
GitLab在期间有很多版本是有漏洞的，如果开放仓库地址最好保持一个安全版本，并需要随时盯着新闻；更新期间可能会经过危险版本，更新期间可能会被注入脚本（我在服务器中更新的时候已经被载入了一个疑似勒索病毒的脚本了）。
记得随时备份仓库哦～
省流：上面的六条看完了就直接看更新吧

目前已知的安装方式

GitLab支持的有四种更新方式

Omnibus CentOS中的yum，ubuntu的apt-get
Source 源码安装
Docker
Helm Kubernetes

如果自身安装的环境不同也可以转换版本，比如原本是用Source进行安装的，可以在更新的时候转换成yum这样的，具体内容这里不展开了（大概就是把数据都备份并移植到另一个环境中，走提供的恢复方法）。

检查服务器上的安装方式

查看自己GitLab版本的方法也比较简单（理论上）

Omnibus gitlab-ctl status
Helm helm status gitlab
Docker docker logs -f gitlab
Source sudo -u git -H bundle exec rake gitlab:env:info RAILS_ENV=production
我就是知道安装方式是什么，诶～任性～

版本漏洞

Major versions are reserved for backwards-incompatible changes. We recommend that you first upgrade to the latest available minor version of your current major version.

在gitlab的更新中不支持跨越主要版本进行更新，只能顺着主要版本依次向上更新，据说是因为每个主版本是可以保留两版本不兼容问题的（？？？）。
GitLab的漏洞层出不穷，你可以在网上找到很多被暴露出的版本漏洞，在每个主要版本的更新期间是会被遭到攻击的，建议安装的时候保持服务器离线，或者在内网环境中安装，否则容易被注入一些病毒如：Linux_386等。

截止2022年12月04日抛出过的问题在15.3、15.4、15.5的一些版本上，具体参考这篇文章，我的最终版本是在15.3.5上，属于其中一个安全版本。

系统支持（片尾有相关链接）

举个例子：

CentOS 8 was EOL on December 31, 2021. In GitLab 14.5 and later, CentOS builds work in AlmaLinux.
CentOS 8已经在2021年年底彻底停止更新了，如果想要搭建的话就只能部署14.6.x版本了。

类似的点一下链接查看，具体看自己的系统版本，不知道自己系统版本是多少的话可以看一下下面的部分。

查看服务器系统（CentOS为例）

cat /etc/centos-release # 查看Linux版本号如果你是ubuntu，去网上搜查看Ubuntu版本号

CentOS Linux release 7.9.2009 (Core)

Anyway～ CentOS 7的EOL(end of life)要到2024年6月，这部分结束。

P.S.
我顺着CentOS 7找到了极狐GitLab，还有针对国人使用的极狐GitLab 旗舰版，单安装的话可以参考使用这个，看起来挺简单的。

服务器配置要求&安装说明

配置方面的参考一下这篇文章就差不多了，安装的话简单介绍一下。

源码编译的部分，需要你下载所有的环境，全部安装到主机中，更新的时候所有的环境依赖也都要相对的跟随gitlab版本进行更新，所以这是所有方法中最麻烦的一种
Docker容器部署&更新，用docker命令即可更新
Helm和docker的流程大体差不多
Omnibus和装大部分包一样，把gitlab当作一个包来装就好了，环境是嵌入在里面的。ls /opt/gitlab/sv可以看到这些包名

准备事项（容错策略）

准备方案分成了软性和硬性两部分内容，软性的部分讲究策略，为了保障更新时的容错率，硬性部分就是具体操作了；在小型企业中，或者说代码不太依赖GitLab的场景下（可能有两到三天不会有人使用GitLab提交代码这样）可以考虑跳过繁琐的测试方案，因为对于效率和操作而言，这是费时且掉san的。但是对于中大型企业，数百人使用，就要尽可能多的规划好可能出现的问题，熟悉且熟练的操作仓库，有一套完美的备选方案，能够迅速响应问题 ——这部分内容GitLab已经给出了非常成熟的引导，我基本上也只能去照抄了emmmmmm

准备内容分三项：

更新前建议
测试方案
版本回滚&备份恢复

更新前建议（搬运）

（生产环境下）复制当前环境出来（系统版本、环境依赖、现GitLab版本），在单独环境中更新并记录过程，确保全流程完全走一遍没有问题之后再更新生产环境的GitLab版本（个人建议写一套更新脚本再去更新，减少仓库不可用的时间）
知道当前GitLab是用什么方式安装的
知道当前操作系统是什么，当前操作系统中支持的最高GitLab版本在哪里（系统兼容部分）。
单机模式还是多节点模式（这里用的multi-node，大概是指分布式）
如果使用GitLab Geo，则需要分享任何和（architectural details）有关的所有的子节点
2-5条应该是和与GitLab Support对接需要参考的问题，不过2-3条还是可以参考的；

原本内容还有6、7两条，但是感觉没什么特别的必要去写，我建议直接进文档里看看咯？

测试方案

测试方案是要确保搭建的GitLab仓库在更新前后都是完全可用的，根据功能被分成了四个基础部分和三个可添加的模块

检查GitLab全局配置：sudo gitlab-rake gitlab:check
确保加密的数据可以被当前使用的secret配置解密（貌似不允许在生产环境中使用该命令）：sudo gitlab-rake gitlab:doctor:secrets
测试界面中是否有问题（访问一下仓库地址）
- 是否可以登录GitLab管理页面（登录一下）
- 以前的项目是否都可见（到仓库里滚一下）
- 项目issues和合并请求是否都可以打开（再欣赏一下别人提出的issues）
- 客户端是否可以从这里克隆项目（git clone https://xxxxxxxxxxxxxxxxx.git）
- 客户端是否可以推送代码到仓库（git push origin master
测试 GitLab CI/CD（Continuous Integration & Continuous Delivery/Deployment）
- Runners pick up jobs（大概就是对应Runner有没有跑tag标中的job）
- Docker镜像可以从（具体配置地点）拉取镜像（合理推测一下整个项目流程，Runner打包项目制作成镜像，下发到线上服务器部署）
Geo
Elasticsearch
mail room
Reply by Email
Service Desk

5、6、7三条关于拓展的我懒得补，你自己看

补充一部分的话可以去看一下gitlab的status，Elasticsearch和文档搜索相关，mail room多半和消息推送相关。

仓库备份

备份的命令有两段，恢复的也有两段；两段分别指仓库和加密文件（实际备份包括了整个实例，想了解的话看这里）

仓库

12.1及以前，使用 gitlab-rake gitlab:back:create 创建备份（注意事项：使用PgBouncer的话要跳过PgBouncer备份、确保上一个备份彻底完成之后再做下一个备份）
12.2及以后，使用 gitlab-backup create 创建备份

secret（自行选择方式备份、Omnibus地址，其它方式安装参考这个）

/etc/gitlab/gitlab-secrets.json
/etc/gitlab/gitlab.rb

如果找不到的话可以试试用find / -iname gitlab看一下

恢复

仓库

12.1及以前，使用 gitlab-rake gitlab:back:restore 恢复（这种方式可能会有一些权限相关的问题，rake拿到的是gitlab user的权限，但是并没有root权限，见已知问题及解决方案）
12.2及以后，使用 gitlab-backup restore 恢复仓库

secret

将备份的secret拷贝至下面的两个路径

/etc/gitlab/gitlab-secrets.json
/etc/gitlab/gitlab.rb

备份目录

默认备份目录：/var/opt/gitlab/backups

仓库备份位置可在配置文件/etc/gitlab/gitlab.rb中进行配置，没有这个文件的话自行创建，没有效果的话考虑一下GitLab的版本问题。

gitlab.rb 配置内容

gitlab_rails[‘manage_backup_path’]=true
gitlab_rails[‘backup_path’]=“/var/opt/gitlab/backups”  #gitlab备份目录
gitlab_rails[‘backup_archive_permissions’]=0644  #生成的备份文件权限
gitlab_rails[‘backup_keep_time’] = 3111000  #备份保留天数，秒计算

具体操作：

vi /etc/gitlab/gitlab.rb

# 此时假设光标在文章开头
/manage_backup_path  

:set hls  # 高亮内容（我的zsh好像并没有高亮，也可能根本不需要这个命令，直接n就完事了...）
*  # 标记当前单词
n  # 选中下一个（同理用?进行反向搜索的时候也是用n跳转上一个，按一次跳转一次）

这个是搜索部分，可以从大堆文本中定位到配置项，如果搜索不到内容的话可以考虑把内容写到配置文件的末尾。

然后生效下配置：

gitlab-ctl reconfigure

备份用于仓库版本回滚或者重装使用。

更新

版本用的比较多的是ce社区版和ee企业版，还有三个其它的版本但是基本上不怎么用，我也就不写了，想了解的话看这里。

指定版本安装

sudo yum install gitlab-ce-X.Y.Z

推荐两个在线工具，一个是官方提供的工具可以直接查询出更新线路，路线比较长的话可以用一下，路线比较短的也可以用一下，路线不长不短的......不长不短的自己顺着更新路径表扒拉着找吧。

更新线路生成工具（很好用）
版本特性表（面试很好用）

添加镜像

sudo cat > /etc/yum.repos.d/gitlab-ce.repo << END
[gitlab-ce]
name=Gitlab CE Repository
baseurl=https://mirrors.tuna.tsinghua.edu.cn/gitlab-ce/yum/el\$releasever/
gpgcheck=0
enabled=1
END

sudo yum makecache

下载

mkdir /usr/yum_cache

for version in 8.11.11 8.12.13 8.17.8 9.5.10 10.8.7 11.11.8 12.0.12 12.1.17 12.10.14 13.0.14 13.1.11 13.8.8 13.12.15 14.0.12 14.3.6 14.9.5 14.10.5 15.0.5 15.3.5
do
    yum install -y --downloadonly --downloaddir=/usr/yum_cache "gitlab-ce-$version"
done

安装

# >>> 符号被我用来表示输出结果

ls /usr/yum_cache
# >>> gitlab-ce-8.8.5-ce.0.el7.x86_64.rpm ... gitlab-ce-15.3.5-ce.0.el7.x86_64.rpm

# 因为尾巴都带有`.0.el7.x86_64.rpm`，所以可以列在模版的范围内（这部分应该可以用yum指定输出后的名字来达成规范）
yum install -y /usr/yum_cache/gitlab-ce-8.11.11-ce.0.el7.x86_64.rpm

此处贴一个没有测试过的顺序安装的脚本，仅供参考使用。

写了两个版本，第一个版本是把安装过程丢到后台执行，用管道符把输出写入日志文件中，使用tail去动态输出日志，不过yum经常卡在一些位置，根本看不到实时的进度，所以就给去掉了。

第二个版本是现在这样的，直接运行，但是每次只能装好一个版本，之后服务器就断连了——不过这样也好，每次更新之后检查一下help页面，确定下安装可以打开，至于更新仓库一些测试......19个版本要更新呢，一个版本要更新30分钟啊喂！！还有我什么时候才能让他们一次跑完啊喂！！好像后台是可以的吧？但是后台貌似会在还没有装完的时候就提前结束了，所以这就是为什么不挂到后台的原因。

# * 在上一个版本使用的时候 下载完安装的时候这里就无法判断下一个版本了，所以目前它只能执行一次更新一个版本，但是可以重复执行，会跳过已经装过的版本，只能算是实现了半自动 *
# 目前这个流程是基于业务积累后的一个理论脚本，没有实际测试过，需要注意 - 可以参考，但不能直接使用 否则后果自负！
# ...诶，我刚刚超帅的有没有，尤其是那个后果自负！嘿嘿～

update_gitlab(){
    last_version=;
    for version in 8.11.11 8.12.13 8.17.8 9.5.10 10.8.7 11.11.8 12.0.12 12.1.17 12.10.14 13.0.14 13.1.11 13.8.8 13.12.15 14.0.12 14.3.6 14.9.5 14.10.5 15.0.5 15.3.5 99.999.9999
    do
        # 检测版本是否预期
        cur_version=`cat /opt/gitlab/embedded/service/gitlab-rails/VERSION`;
        if [ $version == $cur_version ]
            # 版本相等，更新
            then 
                last_version=$version;
                continue;

            # 非预期跳出循环
            else
                if [ $last_version == $cur_version ]
                    # 更新
                    then 
                        echo "目前更新：$cur_version => $version"
                        yum install -y "/usr/yum_cache/gitlab-ce-$version-ce.0.el7.x86_64.rpm" && 
                        echo "\n\n==============================================================================" 
                        echo "=========================== 版本：$version 更新完成 ===========================" 
                        echo "==============================================================================\n\n"
                    else 
                        echo "\n\n==============================================================================" 
                        # 版本小于当前版本直接下一条，大于当前版本则退出（总体来说可以全部continue操作）
                        echo "新版本：$version \n目前版本：$cur_version 版本不相符，跳过安装"
                fi
                continue;
        fi
    done
    unset last_version;
}

# 或许后面可以加一个 & 丢到后台去执行会好一些？我不确定，类似这样：
# update_gitlab &

update_gitlab

运行

unicorn has been deprecated since 13.10 and was removed in 14.0. Starting with GitLab 14.0, Unicorn is no longer supported and users must switch to Puma

大致是说13.10的版本接口不再使用unicorn，14.0彻底不再引用unicorn了，丛14.0后改用puma替代unicorn。

sudo vim /etc/gitlab/gitlab.rb

# 末尾添加 将页面服务改到80端口 - 占用的话换其他的
nginx['listen_port'] = 80  # 嫌麻烦的话可以试试 `echo "nginx['listen_port'] = 80" >> /etc/gitlab/gitlab.rb`，前提是gitlab.rb里nginx['listen_port']没有被配置过
# :wq 保存退出

gitlab-ctl reconfigure && gitlab-ctl start

后续

访问地址检查一下（由于第一次部署到服务器里的时候服务器炸了...就直接跑到虚拟机里了），先放出服务器端口。

浏览器访问10.255.55.2（即：在虚拟机和宿主机同网关下的虚拟机地址，查看用ifconfig |grep inet，找到宿主机和虚拟机broadcast相同的一行，看前面的地址便是，不懂可以参考这个）

注：我的应用在虚拟机里是10.255.55.2，所以直接浏览器访问10.255.55.2即可，也可以选择用WiFi桥接，就是访问网络路径，做前端开发用过webpack或者server开放服务到内网的时候应该有经验，直接访问192.168.0.x这样的（当然我也没有说学组网的不会啊！不，我没有针对，他们都会，你们也会>_<）。

查看一下初始root的密码：

# *注意：这个文件将在首次执行reconfigure后24小时自动删除*
cat /etc/gitlab/initial_root_password

到这里应该差不多就完成了，然后是一些个性化设置，语言设置完了之后后面慢慢摸索就好

语言设置Preferences -> Localization（设置完保存刷新下生效）
ssh 自己搭建gitlab的话应该用过github之类的托管代码平台的吧，所以也应该是知道这个怎么配置的吧，不知道的话直接看这个链接好了，相关内容当你搭建完之后也可以点了解更多查看
- ed2551只是其中一种签名，类似还有
- ED25519
- ED25519_SK (Available in GitLab 14.8 and later.)
- ECDSA_SK (Available in GitLab 14.8 and later.)
- RSA
- DSA (Deprecated in GitLab 11.0.)
- ECDSA
不开放仓库 Menu(一般在左上角) -> Admin -> Settings -> General -> Sign-up restrictions里Sign-up enable选项取消掉（记得保存）
配置Runner 下一章展开

然后还有一些像是Gitlab Geo这样的服务，好像也都是类似插件的方式安装的。

一些报错

error: invalid locale settings; check LANG and LC_* environment variables

环境：新下载了一个Linux镜像，然后跑在了虚拟机中

---- Begin output of /opt/gitlab/embedded/bin/initdb -D /var/opt/gitlab/postgresql/data -E UTF8 ----
STDOUT: The files belonging to this database system will be owned by user "gitlab-psql".
This user must also own the server process.
STDERR: initdb: error: invalid locale settings; check LANG and LC_* environment variables

问题和系统语言相关，使用locale -a检查 LANG 和 LC_* 的环境变量，发现Cannot set LC_CTYPE to default locale: No such file or directory

我的解决方案：

cat /etc/locale.conf知道了我的系统语言是zh_CN.UTF-8；
echo $LC_CTYPE可以看到未指定语言的UTF-8
在/etc/profile后面加两行内容：

LC_CTYPE="zh_CN.UTF-8"
export LC_CTYPE

source /etc/profile

无法访问到虚拟机转发出来的内容

检查防火墙，是否开放映射端口

firewall-cmd --zone=public --add-port=80/tcp --permanent
systemctl reload firewalld

参考文章

gitlab挖矿 - https://blog.51cto.com/yifangyou/4888915
GitLab ExifTool RCE - https://netc.shcmusic.edu.cn/2022/0702/c1811a40089/page.htm
GitLab 2022年9月爆出问题 - https://baijiahao.baidu.com/s?id=1742775605505062957&wfr=spider&for=pc
GitLab 2022年11月问题 - https://www.zzwa.org.cn/4759/

gitlab更新官方文档 - https://docs.gitlab.com/ee/update/package/
gitlab版本升级 - https://blog.csdn.net/wanchaopeng/article/details/124062057
gitlab重大版本 - https://docs.gitlab.com/ee/update/#upgrade-paths
gitlab更新操作 - https://docs.gitlab.com/operator/operator_upgrades.html#upgrading-the-operator
gitlab前置需求 - https://docs.gitlab.com/ee/install/requirements.html
gitlab的版本 - https://docs.gitlab.com/archives/
gitlab12跨版本13升级 - https://zhuanlan.zhihu.com/p/166624536
gitlab Omnibus的启动与关闭 - https://blog.csdn.net/justlpf/article/details/126147349
gitlab-ctl start后没有反应 - https://blog.csdn.net/qq_37967783/article/details/108558898
gitlab | Supported operating systems - https://docs.gitlab.com/ee/administration/package_information/supported_os.html#os-versions-that-are-no-longer-supported
gitlab默认密码 - https://blog.csdn.net/qq_42838143/article/details/121198057

开始部署前的计划 - https://docs.gitlab.com/ee/update/plan_your_upgrade.html#pre-upgrade-and-post-upgrade-checks
检测gitlab全局配置 - https://docs.gitlab.com/ee/administration/raketasks/maintenance.html#check-gitlab-configuration
GitLab CI/CD名词解释 - https://www.jianshu.com/p/fc298001a944
处理GitLab升级时的错误 - https://blog.qiquanji.com/post/445.html
如何重设配置文件（没有备份secret文件怎么办！）- https://docs.gitlab.com/ee/raketasks/backup_restore.html#when-the-secrets-file-is-lost
检测当前仓库编码是否与gitlab-secrets.json配置一致 - https://docs.gitlab.com/ee/administration/raketasks/check.html#verify-database-values-can-be-decrypted-using-the-current-secrets

vim命令 - https://zhuanlan.zhihu.com/p/61515833
redis版本更新 - https://blog.csdn.net/weixin_43903312/article/details/125397126
linux 管道命令 - https://blog.csdn.net/qq_36908872/article/details/127117759
CentOS 防火墙命令 - https://blog.csdn.net/weixin_42688499/article/details/124226669

解决LC_CTYPE - https://blog.csdn.net/weixin_40539892/article/details/80719411

一些在过程中跑题了的文章

K8s安装 - https://blog.csdn.net/triumph12345/article/details/105931753/
K8s介绍 - http://kubernetes.kansea.com/docs/hellonode/
K8s配置文件介绍 - https://blog.csdn.net/qq_34556414/article/details/110000037
Kubectl命令 - https://blog.csdn.net/as_dingjia/article/details/120364679

制作一个CI Runner - https://soulteary.com/2019/08/04/source-code-compilation-gitlab-runner.html
15.3的代码仓库地址 - https://gitlab.com/gitlab-org/gitlab/-/releases/v15.3.0-ee
非Omnibus版本安装转Omnibus安装 - https://docs.gitlab.com/omnibus/update/convert_to_omnibus.html
GitLab 数据备份及恢复(Docker) 这个人的博客还可以 - https://soulteary.com/2020/05/05/gitlab-concise-maintenance-guide-v2020-05.html#gitlab-数据备份及恢复

题外话，我找了好久的gitlab-rake的来源，包括怎么用gem制作一个类似的rake，不过这方面的信息少之又少就没有继续进行下去了，不过我还是扒到了这三个bin，感兴趣的话可以点进去看看，不是二进制的文件，可以用编辑器查看。
用Omnibus安装你可以找到gitlab-rake，而源码安装则是用bundle exec rake，同时指定rails的服务器环境（完整的看了一圈之后感觉Omnibus是真的简单啊。。。）
如果你发现项目中/path_to/gitlab/bin里有gitlab-ctl和gitlab-rake，很有可能就是通过Omnibus安装的

rake的使用 - https://www.mianshigee.com/note/detail/134766vzq/
make到rake的过渡史（为什么使用rake，因为rake方便管理！）- http://t.zoukankan.com/wangyuyu-p-3301473.html
ruby的高级功能（ruby都能干些什么！）- https://www.runoob.com/ruby/ruby-object-oriented.html
gitlab-rake - https://blog.csdn.net/qq_41588098/article/details/125598435

gitlab reconfigure时出现invalid locale settings - https://www.codenong.com/53592993/
invalid locale settings - https://blog.csdn.net/Kangyucheng/article/details/109898756
parallel端口映射（后来才知道共享和Wi-Fi桥接都不需要设置这个...除非想要映射到其他端口？？） - https://www.bilibili.com/read/cv8701763/

标签：gitlab,https,Omnibus,8.8,GitLab,更新,版本,com
From： https://www.cnblogs.com/Arunoido/p/16978195.html

GitLab Omnibus 更新 8.8.5 => 15.3.5

引文