GitLab实战十——Gitlab 8.11 手动编译升级至 11.4

1. Gitlab升级准备

为了配合新版k8s容器云上线使用,满足开发同事对gitlab新特性的需求,由于目前gitlab版本过低,需针对gitlab做一次跨度很大的升级(8.11 -> 11.4)

升级难点:

  • 原版本(8.11)为编译安装,且集成发布平台,添加了一些自定义的东西,有坑

  • 升级版本跨度很大,且每个版本都需修改数据库表,编译前端资源,风险大

  • 数据量大,好几年的线上数据,如何保持一致不丢失是个问题

升级目标:

  • gitlab ce 8.11.3 -> 11.4

  • centos 6.3 2.6.32 -> centos 7.3 3.18.6

  • mysql 5.5.33不变

升级后新特性:

  • 修复多项安全漏洞,组件优化

  • 新增功能强大的WebIDE,全新Vue前端

  • 新增审查合并请求功能和差异文件树功能,让代码审查更高效

  • 新增定时Pipeline功能

  • 新增可配置的issue看板功能

  • 新增Kubernetes 集成功能

  • 新增安全仪表盘,安全报告交互式反馈

  • 增强导航 Epic 和 Roadmap 视图

  • 增强代码搜索能力,高级搜索语法增强,支持按文件名/路径/扩展名进行过滤

  • 基于变量的CI/CD流控制,一键CI/CD,Auto DevOps

升级前的准备:

  1. 搭建测试环境

    先在centos7.3的机器上把gitlab所需环境部署好,然后拉一个线上数据库做测试,升级数据库表结构,编译前端环境。将各个升级步骤都测试一遍,确认可行性及升级收益

  2. 确定最优方案

    通过测试选择最优升级步骤,计算每个版本升级需要发费的时间,检查点,注意事项,冗余数据清除等,选出最佳升级方案

  3. 评估方案

    与同事领导评估实施的可行性,风险点,确定升级时间点,最终方案


2. Gitlab升级步骤

2.1 在centos7.3新机器上部署gitlab9.3版本,安装好依赖环境

详细操作:CentOS7源码安装GitLab CE 9-3-Stable

版本升级:8.11.3 --> 9.3.11 --> 10.0.6 --> 10.8.7 --> 11.0.6 --> 11.4.14

操作系统:centos 6.3 2.6.32 --> centos 7.3 3.18.6

官网升级文档参考:https://gitlab.com/gitlab-org/gitlab-ce/tree/master/doc/update

2.2 升级步骤:

1).备份数据库,创建新实例

# 数据库已备份此步骤可以忽略
NOTE: If you installed GitLab from source, make sure rsync is installed.
cd /home/git/git
sudo -u git -H bundle exec rake gitlab:backup:create RAILS_ENV=production

查看升级步骤:
sudo -u git -H bundle exec rake db:migrate:status RAILS_ENV=production

查看升级日志:
/home/git/git/log/*.log

2).数据库表结构变更(每次版本升级均需执行)

# 由于前端资源编译太费时已提前编译,直接复制即可
/etc/init.d/gitlab stop && cd /home/git/git

# MySQL installations (note: the line below states '--without postgres')
sudo -u git -H bundle install --without postgres development test --deployment

# Optional: clean up old gems
sudo -u git -H bundle clean

# Run database migrations
sudo -u git -H bundle exec rake db:migrate RAILS_ENV=production

# Compile GetText PO files
sudo -u git -H bundle exec rake gettext:compile RAILS_ENV=production

# Update node dependencies and recompile assets
sudo -u git -H bundle exec rake yarn:install gitlab:assets:clean gitlab:assets:compile RAILS_ENV=production NODE_ENV=production

# Clean up cache
sudo -u git -H bundle exec rake cache:clear RAILS_ENV=production

3).检测各组件功能是否正常(每次版本升级均需执行)

# 命令行检测各组件是否正常
cd /home/git/git
sudo -u git -H bundle exec rake gitlab:env:info RAILS_ENV=production
sudo -u git -H bundle exec rake gitlab:check RAILS_ENV=production

# 打开web端查看各界面是否正常

检查都没错,启动也正常,通过绑定域名访问也没有问题就可以测试相关功能了。

4).gitlab-runner升级(升级到11.4再执行)

先备份 /etc/gitlab-runner/config.toml 文件
# 升级gitlab-runner
curl -L https://packages.gitlab.com/install/repositories/runner/gitlab-runner/script.rpm.sh | sudo bash
yum install -y gitlab-runner

# 覆盖新生成的 /etc/gitlab-runner/config.toml 配置
gitlab-runner restart && gitlab-runner list

gitlab-ci-multi-runner.x86_64 1.5.2-1 --> 11.9.2-1

[root@chegva ~]# cat gitlab-runner.service
[Unit]
Description=GitLab Runner
After=syslog.target network.target
ConditionFileIsExecutable=/usr/lib/gitlab-runner/gitlab-runner

[Service]
StartLimitInterval=5
StartLimitBurst=10
ExecStart=/usr/lib/gitlab-runner/gitlab-runner "run" "--working-directory" "/home/gitlab-runner" "--config" "/etc/gitlab-runner/config.toml" "--service" "gitlab-runner" "--syslog" "--user" "gitlab-runner"

Restart=always
RestartSec=120

[Install]
WantedBy=multi-user.target

5).同步最新代码到新机器,lvs切换新机器,根据检查点检察功能是否正常

2.3 回滚步骤

  1. git数据库恢复备份前状

  2. lvs rs切换成原来机器,检查是否正常

2.4 检查点

  • 本地 & idc机器代码提交、拉取、等git操作是否正常

  • 创建项目与组是否正常

  • 项目及用户添加、删除、授权等操作是否正常

  • gtilab-ci功能构建是否正常

  • web hook功能是否正常

  • 平台ci,发布代码全流程是否正常

  • 各项目代码、信息、数量是否完整、一致


3. Gitlab升级总结

1.事先在测试环境把所有数据库变更做一遍,整理好文档

先把大表做优化,比如events表,很多Push的纪录,迁移前能删的都删掉,gitlab迁移时执行insert语句效率很低

如删除2016年6月前的日志操作纪录,可以节省大量升级时间,副作用就是升级后仓库首页contributions纪录没有了。。。

delete from events where created_at<'2016-06-01' ;

2.事先在测试环境把前端依赖编译打包好,到时提前复制至新机器使用就行

正式升级时,只需要按步骤做数据库表结构变更,不需要再编译前端,可以节省大量时间

3.事先把仓库文件提前copy过来,后续只做增量

4.客户端和数据库统一用utf8mb4字符集,数据库变更时问题会减少许多

升级时数据库需进行授权等操作,建议采用单实例升级,不影响其它线上数据库

历史数据字符集的问题:

由于8.11使用的全是utf8字符集,升级到10.8的时候,很多merge diff 记录中有表情和特殊字符都插入失败,最后测了几遍,客户端和数据库统一用utf8mb4字符集这样最快,生产中最后采用统一字符集后 Index column size too large. The maximum column size is 767 bytes这类的错误都没有出现了

5.web hook 配置变更 ,允许内网使用webhook

6.gitlab-runner 配置变更,允许无tag任务使用share runner

7.预到突发非预期的情况,需查找官方文档,faq,看服务日志,不要乱猜

8.每个版本升级步骤大致相同,可以写成脚本

9.升级后,rd登陆需删除原来的ssh认证信息再登录

重新添加key信息
ssh-keygen -f ~/.ssh/known_hosts -R gitlab.chegva.com(gitlab使用的域名)
ssh-keygen -R 10.108.xxx(lvs的IP)
ssh-add ~/.ssh/id_rsa

10.gitlab 11.4需要git版本>2.7,否则打开仓库branches报503

升级后遇到了2个问题,因为删除了events纪录,个人仓库首页contributions统计展示没有了,不过不影响使用,第2个就是11.4 使用编译升级gitlab ci sidekiq有bug,不知道新版本修复了没有。

参考:shell + python脚本监控gitlab ci停滞任务数

最后整个升级包括验证耗时10小时(晚上10点到早上10点,中间没有休息,遇到问题升级就停止了,只能接着继续,无奈),跨6个大版,升级后服务总体运维正常,符合预期。这是目前职业生涯干的最复杂的升级了,接下来写写每个版本的具体升级操作。

anzhihe安志合个人博客,版权所有丨 如未注明,均为原创 丨转载请注明转自:https://chegva.com/3586.html | ☆★★每天进步一点点,加油!★★☆

您可能还感兴趣的文章!

发表评论

电子邮件地址不会被公开。 必填项已用*标注