我们的项目是标准的CI/CD流程,也即是Gitlab+Jenkins+Harbor+Docker的容器自动化部署。 经历了上上周的docker灾难,上周的服务器磁盘空间灾难,这次又发生了jenkins卡住的灾难。 当然,这些灾难有一定的连锁反应,是先发生的docker灾难,然后因为要测试,导致镜像堆满服务器磁盘空间,磁盘空间满,又导致了jenkins卡住的问题。下面将我的解决过程记录下来,希望可以帮到可能会发生同样发生问题的大家。
图1
如上图所示,jenkins的121号版本编译成功之后,修改了几行代码,传到gitlab后,用jenkins进行编译。结果报错,jenkins报错的信息(Console Output)如下:
这是将镜像推送到镜像仓库Harbor发生的问题。
因为之前我观察到Harbor所在阿里云服务器磁盘使用率已达到92%,因此首先查看该服务器的情况。一看不得了,磁盘使用率已是100%。我删除了很多过期镜像,也删除了服务器本地拉取的一些镜像,但磁盘空间没变化,于是花了一些时间解决了这个问题(【docker&linux实战】阿里云服务器磁盘空间满了 – 经云的清净小站 (skycreator.top))。
就在我大呼万岁,准备开庆功宴的时刻,jenkins编译一直进行中。正常只需十几分钟就可以正常部署,这次花了半小时也没打包成功(见下图#123)。我又试了一次,这次1h 38min也没完成(下图#124)。
我打开#123和#124的Console Output,发现jenkins卡在了load build definition from Dockerfile这一行。
我一个游戏程序员,对于jenkins的操作不熟悉啊。于是有病乱投医,我进行了下面一系列的弯弯绕绕的操作。
1.docker版本问题
首先,我怀疑可能和docker版本有关。阿里云上三个服务器的docker版本都是1.24,而我本地windows上是1.26。本地windows上的这个项目docker build可以正常通过,而linux上不能通过,因此自然想到可能是docker的问题。
我们的服务器分为s1,s2,s3。其中s1是项目server,s2是gm后台server,s3是gitlab、Harbor、jenkins所在的server。因为是打包gm后台server,因此,我选择s2升级docker。
升级前先删除旧版本的docker,删除后更新不到新docker了。是的,太郁闷了!旧问题没解决,又产生了新问题。
曾经使用yum安装docker的路子走不通了。难道docker也下载不了了?我有些绝望,甚至想到了将安装包本地下载,再将它拷贝到阿里云上。
幸好,网上找到dnf的安装方法,成功升级了docker。
进入jenkins,再次编译,依然不通过。该方法失败!
2.配置检查
上一个问题无果后,我又想到了可能是docker的配置问题,或许该服务器没有设置私有仓库呢?
打开/etc/docker/daemon.json,里面确实设置了。
查看jenkins的pipeline,将项目server和gm后台server相互对比,也是没区别。
3.代码回退
#123的版本,我提交了一些代码,不会是提交的代码导致卡住吧?
虽然我的内心不认为会是这个原因,但试一试万一成功了呢?
于是,我使用git回退了代码(这里又复习了一下git的回退操作),再次编译,还是卡住。
4.新建任务
既然是jenkins的卡住,我怀疑可能是jenkins的这个任务有问题。于是我新建了一个jenkins任务,复制了gm后台的pipeline。
再次编译,依然故我!
5.改变焦点
由于对jenkins不熟,对于jenkins的docker build一知半解。这次我重新看了看jenkins的pipeline。
// 1.从gitlab上取代码
// 2.镜像编译
sh 'echo 镜像名称:${image_server_gm_server} && docker build -f ./server/Dockerfile -t ${image_server_gm_server} ./server'
sh 'echo 镜像名称:${image_server_gm_web} && docker build -f ./web/Dockerfile -t ${image_server_gm_web} ./web'
// 3.登陆Harbor,向Harbor推送镜像
// 4.登陆gm服务器,从私有仓库拉取镜像
从上下文来看,gitlab上取了代码后,对代码进行了镜像编译。这时,还没登陆镜像仓库,也没有登陆gm服务器。那么代码应该存放于jenkins所在s3服务器,而不是s2啊。
我尝试寻找代码所在位置,在jenkins所在目录的jenkins_home/workspace找到了jenkins的相关任务,任务中即是代码。于是我进入相应文件夹,使用docker build进行编译打包。
卡住了。问题找到了。估计是由于之前磁盘空间满,docker内部某个逻辑没走通,一直卡住,因此只要重启docker,估计问题就能解决。
不过这个s3的docker版本较低,顺便先升级吧。按照之前的操作,升级s3服务器的docker到最新。然后重启docker,再次编译,问题解决,如下图所示:
直接ctrl+c关掉。从浏览器进入jenkins,执行任务编译。成功!
这次虽然解决了问题,但中间弯弯绕绕浪费了好久。若是对jenkins充分了解,时间上可以更快。
这次特别感谢d u x t,他给我提出了不少新思路,让我思路开阔了很多。