记录一次拯救jenkins的历程

前因后果

今天维护jenkins的时候手欠了下，点了升级，然后我们的jenkins是放在 docker 里面的，重启就发现提示这个

好家伙，最低要求都jdk11了，本来还打算jdk8再战十年的，别卷了

本来准备下载个jdk11, 覆盖下完事，准备升级下jdk的我发现问题没有这么简单，问题就出在容器这里，容器的状态是一直重启，我这也没办法进到容器里面改文件啊

Jenkins 的 Enrtypoint 如下，jdk 版本不合适会导致主进程无法启动，结果就是容器不能正常启动

改jdk才能打开容器，打开容器才能修改jdk。好家伙，死锁了是吧。

然后这个jdk目录我还没挂载到宿主机，就很难受了

方案一 docker cp（无效）

经过查阅资料，发现 docker cp 是可以无视容器状态

查看下 容器的环境变量

应该就是这里了

下载完jdk

# 把 openjdk 复制过来
docker cp jenkins:/opt/java/openjdk ./
# 替换这里的 openjdk 文件夹（哈哈，我还偷笑了好久，偷梁换柱我可太会了，毕竟容器里不能改环境变量，那就换个马甲就完事了）
docker cp ./openjdk jenkins:/opt/java/openjdk 

结果发现不能解决问题，纳尼？？？

其实我这里一直在纠结一个点，就是 docker cp 能否直接替换文件夹，答案是否定的，这里附上 docker cp 的处理策略

再次把容器里面的 openjdk 挂载到宿主机，用 ./bin/java -version 检查，不出所料 容器里面的还是 jdk8

方案2 find 模糊搜索

这里其实还踩了个坑，就是对 docker 的文件管理不熟悉，导致这块很难受，后面会补上

这块是 查看的容器信息，找了下 mergedDir 结果发现不存在，害，基础不牢，地动山摇啊，流下了没文化的眼泪

既然找不到具体路径，但是我敢肯定，文件肯定是在 /var/ib/docker 里面的

所以我直接模糊搜索是不是就ok了

find /var/lib/docker --name "/opt/jdk/openjdk"
# 结果如下 我这里也是混的，我就把第一个 文件夹下面的替换掉了，然后就解决了
/var/lib/docker/overlay2/063b8b4357c9e02b09a77851650962e15f17e6c9d45a5cc937c201c5677aab46/diff/opt/java/openjdk
/var/lib/docker/overlay2/d3a7db93a3ecee188ecd87a1805f40b7a0ab86bf59c4cccd4ee5624a126afef2/diff/opt/java/openjdk
/var/lib/docker/overlay2/988773a3b7ee3bcc2bda52735623a6c3c1809aac5905c3f025b785e0ef53ea02/diff/opt/opt/java/openjdk

第二个坑 插件报错

现在容器是启动起来了，但是进首页还是报错，害，能起来就不慌了

也看不懂具体的是啥意思，但是可以确定是 githook 这个插件有缺少 ruby-runtime 的问题

查阅资料，进到 plugins 目录，删掉两个 文件就ok，gitlab-hook.jpi和ruby-runtime.jpi

删了重启，okk，打卡下班

总结

其实 容器化这个事情我一直是持存疑的态度的（小团队，个人意见），我这边其实还没遇到容器化才能解决的痛点问题，之前是完全容器化，包括mysql, redis, java, nginx等等，这些都是放在容器里面跑，后面发现不是分布式的项目，用容器其实不太必要，很大程度增加运维成本，后面一步步把容器方案替换掉了，还是用的传统的脚本的方案，jenkins也是如此

再就是暴露了对 docker 底层原理的匮乏，网络，进程，文件管理的理解都存在问题，当初是为了简单，一行指令就可以搭建起来一个环境，但其实给自己挖了很多坑，屏蔽了太多的细节，现在看来对一个我这个阶段的弱鸡没啥意义，当然我也有很多认识的同学去大厂专门做云原生的，另当别论，我这边主要还是做b端开发，我评估了下，k8s应该一年内都不太会用得上

后面我应该还是会深挖作为后端开发需要深挖的知识，mysql，并发，mq，redis这些，再就是一些简单的调优，应该是不会把这些放在容器里了，高可用目前的业务还用不到，容器解决特定问题只是一种载体，也没有必要去神化，好像2022年不谈容器，就很low，真没必要

TODO

jenkins 的备份与恢复