Jenkins容器意外关闭–24小时危机处理

写在前面的话

上线前最后24小时,激动人心的时刻,突然Jenkins重启了。。。。。。

下面记录一下一波三折的过程

一波–Jenkins手动重启?No!

Monitor一直显示着Jenkins所有Pipeline状态,保持常绿,心情舒畅,一键CD应该是没问题了,最后调调小Bug准备下班~~~~

”你们谁重启了Jenkins?“

”¥%??˙˙˙∫??#¥%#¥&**!@#%“

”·?˙???˙?˙???˙∫??˙??˙??˙???????“

”等它重启完再提交吧“

…………

”Monitor怎么没了?“

…………

”我们的PipeLine怎么都没了?“

”快看看Jinkens Log!怎么Log都没了“

”这不是重启,谁给我们ReSet了?“

”是不是Ops操作错误?“

”先看看是不是坏了,先建立一个PipeLine能不能正常创建“

”OK建好了“

求救Dev Ops/Tech Leader

一折–容器内存不足挂了!Volume为什么没有?!

夏:“你看Kubernetes上显示,你们的Jenkins在45分钟前连续内存占用警报,然后容器的down了”

“你们的配置为什么也没了?看来是Volume没配置”

冰:“那为什么还有一个幸存的Pipeline”

……“那是我们自己建立一个实验的”

夏:”那现在容器自动重启了,没问题了,你们自己重新配置一下Pipeline就可以了“

………

XY:”我们负责装一下插件“

HH:”我们负责把Pipeline建好“

XY:”插件装不上,connect error”

夏:“安装插件权限你们有”

经过多次尝试,终于装好了

夏:“可能是资源有限,下载总失败”

10分钟后,距离下班不到1小时

XY:“插件都没问题了”

HH:“Pipeline Ok”

夏:”Credentials配置好了“

ALL:”构建然后上线,尽快搞定“

Keynotes

  • 容器配置一定要将服务的配置文件、数据文件都设置Volume

  • Log文件也很重要,给自己留一条查看问题的路

  • 容器配置好后,最好模拟一次down up,看看care的数据是否还在

二折–红着不能下班#¥%&那就加班吧

一波Build操作,从灰色全部变成了红色

“我们都配置好了,为什么还是无法运行?”

”让装的插件都装了“

”再试一次“

”还是不行“

HH:”是不是装了插件要重启?“

L:”如果提示了就要重启“

HH:”我怕重启了又Rollback了“

L:“放心,重启吧” P.s.反正现在也是空的

重启后所有后端项目都OK了,前端还是一直红

??:“front-end一直报node sass”

Node Sass could not find a binding for your current environment: Linux 64-bit with Node.js 8.x
?
Found bindings for the following environments:
  - Linux 64-bit with Node.js 8.x
?
This usually happens because your environment has changed since running `npm install`.
Run `npm rebuild node-sass` to download the binding for your current environment.
  • 描述问题要清晰,紧急时刻要保证交流效率

  • 先确定流程的每一步,筛选出可能出问题的步骤,逐步验证每一步的正确性

  • 对于工具的使用不能只浮于表面

  • Jenkins构建的Image涉及到Build Number,不应让number重复

  • 对环境的配置/部署尽量使用代码(写到对应的.sh里),而不是直接进入容器操作,以便追踪/复现……

Keynotes

XF:”再Bulid就行了,试试可以么,把其他的也改了,确认一下都没问题么“

XF打开了一个Pipeline,“Set Next Build Number”,设置了10000

”知道,应该包含了Build Number“

XF:”你们知道Jenkins最后构建的image是怎么命名的么?“

XF大佬最后终于出手了

夏:”这个有可能,我们试试能删除么“

L:”把以前build后的删除行么”

…………

冰:“你们Jenkins初始化了?每次构建的Id从1开始了?会不会是和之前的id重复,导致编译后的包无法覆盖”

冰姐闪亮登场

HH:”我又测了一次不行” ——P.s是不是这个时间段,有人又重新构建了一个版本的?无从考证了

夏:”我们这测试访问成功了第二次迭代的接口“

夏:“给我你们没个迭代新增的后端接口”

HH:”后端接口也有问题Postman访问不了“

每个人的电脑在隐身模式下看到的都不一样

一个人的电脑刷新前后看到的不一样

MM:”我这清空了缓存也是第一次迭代的“

HY:”我这清空了浏览器缓存,看起来是第二次迭代的“

娟姐:”你们清除一下浏览器缓存,用隐身模式也行,是不是缓存的问题“

头戴光环的娟姐出现了

”我又上传了一次,怎么成了第一次迭代的了?“

”我们上线了第三次迭代的版本,为什么当前功能是第二次迭代的?“

时间到了上线前最后2小时

三折–人生何处不精彩!staging模拟环境版本神奇Rollback

时间到了上线前最后2小时

”我们上线了第三次迭代的版本,为什么当前功能是第二次迭代的?“

”我又上传了一次,怎么成了第一次迭代的了?“

头戴光环的娟姐出现了

娟姐:”你们清除一下浏览器缓存,用隐身模式也行,是不是缓存的问题“

HY:”我这清空了浏览器缓存,看起来是第二次迭代的“

MM:”我这清空了缓存也是第一次迭代的“

每个人的电脑在隐身模式下看到的都不一样

一个人的电脑刷新前后看到的不一样

HH:”后端接口也有问题Postman访问不了“

夏:“给我你们没个迭代新增的后端接口”

夏:”我们这测试访问成功了第二次迭代的接口“

HH:”我又测了一次不行” ——P.s是不是这个时间段,有人又重新构建了一个版本的?无从考证了

冰姐闪亮登场

冰:“你们Jenkins初始化了?每次构建的Id从1开始了?会不会是和之前的id重复,导致编译后的包无法覆盖”

…………

L:”把以前build后的删除行么”

夏:”这个有可能,我们试试能删除么“

XF大佬最后终于出手了

XF:”你们知道Jenkins最后构建的image是怎么命名的么?“

”知道,应该包含了Build Number“

XF打开了一个Pipeline,“Set Next Build Number”,设置了10000

XF:”再Bulid就行了,试试可以么,把其他的也改了,确认一下都没问题么“

Keynotes

  • 描述问题要清晰,紧急时刻要保证交流效率

  • 先确定流程的每一步,筛选出可能出问题的步骤,逐步验证每一步的正确性

  • 对于工具的使用不能只浮于表面

  • Jenkins构建的Image涉及到Build Number,不应让number重复

  • 对环境的配置/部署尽量使用代码(写到对应的.sh里),而不是直接进入容器操作,以便追踪/复现……

 


| 版权声明: 本站文章采用 CC 4.0 BY-SA 协议 进行许可,转载请附上原文出处链接和本声明。
| 本文链接: Cologic Blog - Jenkins容器意外关闭–24小时危机处理 - https://www.coologic.cn/2019/08/1628/

留下评论