最近jenkins遇到了一次事故，還好現(xiàn)階段處于planning階段，對(duì)日常的開發(fā)工作影響較小。來盤點(diǎn)下這次issue。
周五下午的時(shí)候，jenkins pod毫無征兆的頻繁重啟。查看pod的logs發(fā)現(xiàn)啟動(dòng)并沒有異常log，最后一行是
JVM is terminating. Shutting down Jetty
然后就是周而復(fù)始的restart。目前有兩個(gè)問題擺在面前：1. 什么原因?qū)е耲enkins重啟？ 2. jenkins重啟為啥啟動(dòng)不了？
查看volumns所在的磁盤，執(zhí)行l(wèi)s -lt發(fā)現(xiàn)有個(gè)文件當(dāng)時(shí)被修改queue.xml。執(zhí)行cat queue.xml進(jìn)去后發(fā)現(xiàn)里面是描述一些job的情況，按照字面意思應(yīng)該是當(dāng)時(shí)宕機(jī)后正在排隊(duì)執(zhí)行的job。返現(xiàn)其中有個(gè)節(jié)點(diǎn)label寫的是k8s建的動(dòng)態(tài)slave的label，看到這個(gè)地方顯然是有問題的，因?yàn)橐坏﹋enkins重啟， 那些動(dòng)態(tài)slave與jenkins server通信的通道就會(huì)被關(guān)閉，從而導(dǎo)致輪詢找不到node，所以基本上定位了為啥反復(fù)起不來的原因。先備份排隊(duì)job，執(zhí)行"echo '' > queue.xml"，再次重新啟動(dòng)，發(fā)現(xiàn)jenkins能夠正常啟動(dòng)了，而不會(huì)出現(xiàn)因?yàn)閘oad不到動(dòng)態(tài)slave而shut down。
問題2解決了，但是導(dǎo)致宕機(jī)的原因是什么呢？排查這個(gè)jenkins server還是比較穩(wěn)定的，近期的配置改動(dòng)也比較小，懷疑是新的pipeline代碼導(dǎo)致的，帶著這一絲疑慮，找到git倉庫，翻看近期的PR，發(fā)現(xiàn)最近有DEV在修改我們的pipeline code，其中有段判斷異常的地方引起警覺“System.exit(1)”，這個(gè)應(yīng)該就是”兇手“了。我們知道jenkins使用java代碼寫的，也是跑在jvm里面，采用system.exit(1)會(huì)把當(dāng)前的進(jìn)程殺死，如果job又正好在jenkins所在的master機(jī)器上處理任務(wù)的話，就達(dá)到了殺死自己的條件。后來又去比對(duì)了當(dāng)時(shí)宕機(jī)時(shí)間點(diǎn)，改PR執(zhí)行job的觸發(fā)時(shí)間，完全吻合。
此處issue還是帶來了一些警示：
1.代碼一定要review，專業(yè)的人做專業(yè)的事，至少他知道更多的“坑“和risk。
2.流程需要規(guī)范，這次DEV是通過改動(dòng)自己的code跑PR，。繞過了我們對(duì)code的控制，導(dǎo)致jenkins異常。
3.jenkins也需要多種環(huán)境，將我們平時(shí)測(cè)試編寫的job放在備用jenkins上，不要影響生產(chǎn)jenkins。
