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

by ·0评论 · 3,676 人阅读 · 隐藏边栏 · 最后更新: 2020/1/7

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个大版，升级后服务总体运维正常，符合预期。这是目前职业生涯干的最复杂的升级了，接下来写写每个版本的具体升级操作。

11.升级到11.4后，部分仓库merge代码时报500，查看数据库有表被锁，将mysql 5.5数据库升级到5.7可解决这个问题

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

您可能还感兴趣的文章！

发表评论

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