问题是什么?
上班第一天,修个了几个bug,本地自测觉的自己处理的很完美,自信的把代码提交了,开始在自动化构建部署后台开始傻瓜点几下,就等部署完成,到测试环境看一下。结果过了一会,去后台看构建结果,发现失败了,这个很常见,可能是超时了,我再试几次,发现都是失败,直觉告诉我,这次应该不是网络超时的原因呢。
此时我想着,去对比下,成功的构建日志和错误的构建日志,看看这之间的差别,到底问题出现在那里呢? 毕竟过年之前,都是正常的,为啥才过一个年,就成这样呢?而且在代码什么都没有改动的,真的很奇怪。
但是既然有这个问题,肯定是那里出现了问题,那就得解决它,不然构建发布不了,咋给测试呢。慢慢找吧,我分别从下面几个方向查找处理的这个问题。
怀疑是npm包的问题
修改Jenkinsfile的构建,更改的npm包的代理仓库,测试发现无用。
查构建日志
- 看当前构建失败的错误日志,看看报错信息
- 对比之前正常的构建日志和现在错误的构建日志,看看两者的区别
- 确定真正的报错信息是什么
查找下来,只有这个是真正导致构建异常的原因,其他报错正常和失败的日志,都同时存在不影响。 就是这个ip-address@9.0.5这个包,需要node版本大于等于12。但是现在10.xx, 版本不匹配导致。 但是我在项目里面找了,package-lock.json找了一圈都没有发现这个包。
求助运维
由于不常用到,Jenkinsfile和dockerfile这些内容,导致对这些问题很陌生。就去求助了运维大哥。跟运维描述了上述问题,为啥都没有修改Jenkinsfile和dockerfile的配置,为啥会出现这个问题。
运维说就是那个包问题,哎,还得自己看看。刚好借这次机会,学习一点点相关知识,看了一下Jenkinsfile和dockerfile的配置,再搜了一下资料,发现docker里面,启动的时候应用的时候,安装了pm2@4.5.6里面就依赖这个ip-address@9.0.5。而这个包,要求的node版本又需要node12。
对各种构建部署步骤,进行修改尝试
-
Jenkinsfile构建里面的node版本是10,那么我把里面的node环境,修改为12尝试下,测试失败,一构建就报错,node-sass的版本和node不兼容,我又不能修改,项目里面的node-sass, 这个改动挺大,不知道会引起什么问题,放弃这个修改。
-
既然jenkins不行,那就修改dockerfile里面的node版本,反正错误就是docker里面用的node10,跟pm2里面的ip-address不兼容导致的,将docker里面的node修改为12版本。
构建是成功了,但是docker里面启动的时候, 又不成功,看日志又是内存溢出。哎,本来以为构建没问题,发布应该也会成功,成功的道路,总是这么艰辛。还得重新再来。
- Jenkinsfile和dockerfile的配置内容还原,感觉路走远了,需要回过头来,再重新梳理,不能调整docker里面的node版本,因为在Jenkinsfile里面的node版本是10, 整个项目的构建都是以10为基准的,而docker的node又调整为12,两者的版本是有差距的,会导致版本不兼容,出现问题。
最终处理
- 既然node版本不能调整,Jenkinsfile和dockerfile需要保持一致,版本要求为10
- 而docker里面安装的pm2的又需要node12。那么只能调整pm2的版本了,但是pm2@4.xx都用了这么久了,突然降低为pm2@3.xx会不会,有什么问题。
- 管不了那么多了,只能先尝试下。再看看有什么问题,有问题再修改。发上去了构建发布都没有问题。
总结
对Jenkins和docker有了浅浅的认识,在整个的自动化部署平台中,Jenkin是根据项目的package进行包的依赖安装,然后将前端code进行打包编译成静态文件,上传到对应的服务器上,然后在docker中,启动对应的前端node服务。
通过这次问题的排查,发现这部分的知识比较欠缺,需要找个教程学习下。 以前总是觉得这部分不需要前端了解,就每次都忽略掉,但真的用到的时候,却啥都不知道,真的是应证那句话,书到用时,方恨少。难倒你的,往往就是你忽略的。
上述只是自己浅浅理解,肯定存在些许错误,如有错误,恳请指正