GitLab Omnibus 更新 8.8.5 => 15.3.5
引文
虽然本意是想要从更新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。
配置中做两件事,第一件是配置gitlab面板的地址,第二件事是配置gitlab自身所在的域名(后面写runner的时候要用到,也包括了项目克隆本身,如果不配置的话引用就会用默认的gitlab.example.com
)
sudo vim /etc/gitlab/gitlab.rb
# 找到external_url 'http://gitlab.example.com'
# 修改成自己的域名地址,比如我的:
external_url 'http://192.168.0.17'
# 嫌麻烦可以试试 sed -i "s/external_url 'http:\/\/gitlab.example.com'/external_url 'http:\/\/192.168.0.17'/g" /etc/gitlab/gitlab.rb
# 使用 cat /etc/gitlab/gitlab.rb|grep external_url | grep -v "^#“ 检查内容是否修改
# 末尾添加 将页面服务改到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
登录,账号root,密码从上面的地址里拷贝。
到这里应该差不多就完成了,然后是一些个性化设置,语言设置完了之后后面慢慢摸索就好
- 语言设置
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
选项取消掉(记得保存) 设置默认分支setting -> repository -> default branch
修改为master
- 配置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
gitlab 中出现的所有地址都是使用的gitlab.example.com - https://www.likecs.com/show-305674981.html
gitlab 默认分支变成了main - https://blog.csdn.net/z_vicky/article/details/127731977
一些在过程中跑题了的文章
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/
后记
虚拟机太大辣,下次做成docker呜呜呜QAQ