记一次令人心悸的 GitLab 升级经历

本贴最后更新于 1725 天前,其中的信息可能已经渤澥桑田

起因

今天日常连接上 VPN,上 GitLab 私服,对离职人员进行 block,3 个月无更新的项目进行 archive 操作,将新项目分好组,并通知其余负责人。

然后!然后我想到了最近三个月都没有更新 GitLab 了,12.5.1 版本,最新的是 12.8 版本,想着更新一下,然后问题就来了。

经过

按照常规操作,https://packages.gitlab.com/gitlab/gitlab-ce,从这个网站 wget 下最新的 GitLab Rpm 包,准备更新。

首先进行了版本查看(由于 GitLab 在数据恢复的时候必须保持版本一致),并记录了当前的 GitLab 版本号 gitlab-ce-12.5.3-ce.0.el7.x86_64

然后进行了数据备份操作 gitlab-rake gitlab:backup:create 并将备份后的文件本地保留一份到 ~ 目录下,scp 出去一份到自己的服务器上

最后感觉万无一失的开始搞 yum install -y gitlab-ce-12.8xxxxx,然后看着日志滚动刷屏,我淡然的感觉应该没什么问题,因为更了不下 5 个版本了,就出去抽烟了。

等抽烟回来一看,卧槽,Exception 眉头一皱发现事情不简单了。略慌,然后我打开网址查看,并没有什么问题,当我查看当前 Gitlan 版本的时候显示:12.5.
心里想,重启一下应该就好了,gitlab-ctl restart,然后 gitlab 页面就 502,后面就是 500.

image.png

然后我就赶紧通知各个部门经理啥的,着手进行修复工作。

首先尝试 yum undo 来进行回滚操作,操作失败
然后尝试在重新升级一次 yum install -y xxx 失败
最后仗着感觉自己备份了,就开始删 Gitlab,gitlab-ctl uninstall
rm -rf /opt/gitlab,rm -rf /etc/gitlab yum remove gitlab-ce。万幸的是,gitlab-ctl uninstall 的时候自动把 /etc/gitlab 下的 gitlab.rb,xxx,json 自动备份到了 ~ 目录下,以至于最后恢复成功,没有发生惨案

然后我根据记录下的版本号 gitlab-ce-12.5.3-ce.0.el7.x86_64 重新下载了 rpm 包,重新安装。
安装后必须用 gitlab-ctl reconfigure 来加载各种配置,启动 redis,nginx,xxx等各种依赖服务 这里遇到了两个问题,注意,重装的时候会遇到这问题的,导致我来来回回删装删装了两个小时妄图安装成功

遇到的问题: redis 连接不上,xxx file not found.

第一个解决方式:
image.png

第二个,xxx file not found
这个我调了好久搜了好久,issue 都感觉搜遍了,最后从 stackoverFlow 找到了解决途径
image.png
于是呼我就去改了 ruby 脚本

接下来一切正常,然后安装完了一个新的 gitlab 也能跑起来了,现在到了恢复的时候,首先,gitlab 要在运行中,然后停止以下两个服务

 gitlab-ctl stop unicorn
 gitlab-ctl stop sidekq

然后我以为 直接去把 tar 包拖过来运行 gitlab-rake gitlab:backup:restore BACKUP=xxxxx 就可以恢复了。

然后!!!我慌了!我进去看了,人员/组织/项目都恢复了(我以为项目恢复了,结果只恢复了名称)
image.png

看到了吗 No repository,我真的慌了。心想,完了,这他妈可能是备份的不好使。

最后研究出了结果,我找到了在第一次运行 gitlab-ctl uninstall 时在 ~ 目录下留下的一堆文件,把他们盖到了 /etc/gitlab 下,然后又进行了一次恢复。

结果

最后我手冰凉,腿都软了,发誓以后这个服务器我绝对再也不登陆了。再也不更新了。爱咋咋地吧。好在一切都恢复好了。淦。这是我从业 3 年以来经历过最最最最最最最最最最最最凶险的 4 个小时。卧槽。。。心有余悸。

总结

记录 gitlab 版本,备份数据文件,备份/etc/gitlab,备份/opt/gitlab。
如果支持快照,那必须搞个快照。在操作之前,最好新起一个环境,模拟这次操作,如果有问题,那么恭喜你,还好你没直接在正式环境搞。如果没问题,多试两次。如果到正式环境上出现了问题,不要慌,先打报告,让别人心里有数,然后自己努力的去解决。解决不掉有快照的话,万事大吉。

祝愿

祝愿各位职业生涯内不会遇到我这种问题。

  • GitLab

    GitLab 是利用 Ruby 一个开源的版本管理系统,实现一个自托管的 Git 项目仓库,可通过 Web 界面操作公开或私有项目。

    46 引用 • 72 回帖 • 3 关注
  • 运维

    互联网运维工作,以服务为中心,以稳定、安全、高效为三个基本点,确保公司的互联网业务能够 7×24 小时为用户提供高质量的服务。

    149 引用 • 257 回帖
  • 一些有用的避坑指南。

    69 引用 • 93 回帖

相关帖子

欢迎来到这里!

我们正在构建一个小众社区,大家在这里相互信任,以平等 • 自由 • 奔放的价值观进行分享交流。最终,希望大家能够找到与自己志同道合的伙伴,共同成长。

注册 关于
请输入回帖内容 ...
  • 88250 1

    平安就好,你的宝贵经验已转发社区公众号 🍇

  • 其他回帖
  • 我每次升级服务,都要在本地测一次,测试环境测一次,线上再测试一次才敢升级 😂

  • Leif160519 1

    1.企业中依赖的重要系统,能不升级就不升级,保证能用就行,除非升级能解决现有的重要 bug

    2.“我以为”是运维大忌,主观性太强,容易误操作

    3.重大变更之前,做好数据备份,想好执行步骤和可能的意外情况,想好如果出现问题,如何快速回滚让系统恢复正常,让公司损失最小,影响面降到最低

    4.每一个命令回车之前,想一想,执行后会有什么效果,最好能知道命令的含义,实在不行,没有经验就自己模拟一个环境自己先测试(如果是虚拟化的机器,可以提前打快照准备好退路)

    5.有时候自己是出于好心,但是却能办了坏事,这种心态,还是憋着为好

    以上,经验之谈,大佬勿喷

  • 本来以为你只负责前端和后端,没想到还负责运维 😂
    话说贵司没有发布平台和灰度部署机制嘛,还需要各种手动运维,风险极高

    1 回复
  • 查看全部回帖