1. 項(xiàng)目概述1.1 我為什么在一開始就盯上了持續(xù)集成先說我自己的經(jīng)歷。以前做項(xiàng)目最怕的不是寫代碼是“發(fā)布當(dāng)天”。早上開會說好了十點(diǎn)上線結(jié)果十點(diǎn)半了組里還有人抱著筆記本在改配置文件另一個同事在群里喊“誰動了數(shù)據(jù)庫連接串”然后整個下午就耗在“代碼在本地是好的、到測試環(huán)境就掛了”“這次明明只改了一個函數(shù)為什么部署包沒更新”這種問題里。后來我認(rèn)真復(fù)盤了一下問題不出在某一個人身上而是整個團(tuán)隊(duì)的交付方式還是手工時代——拉代碼、打包、扔到服務(wù)器、手動重啟每一步都靠人來盯每一步都可能漏。所以當(dāng)某團(tuán)隊(duì)讓我牽頭梳理交付流程時我第一個確定的方向就是持續(xù)集成。持續(xù)集成CI的核心其實(shí)很簡單把代碼提交、靜態(tài)檢查、單元測試、構(gòu)建、產(chǎn)物歸檔這些動作全部自動化每次提交都觸發(fā)一次完整的驗(yàn)證。相當(dāng)于每時每刻都在自動做一次“它能不能上線”的體檢。而在這個體檢流程里最重要的執(zhí)行引擎就是Jenkins。Jenkins這個工具能解決的問題我用一句話概括把“人肉流程”變成“機(jī)器流程”。它有豐富的插件生態(tài)可以對接各類代碼倉庫、構(gòu)建工具、測試框架、部署平臺而且部署方式非常靈活——單機(jī)、集群、容器里都能跑。它也是目前開源社區(qū)里生態(tài)最成熟的持續(xù)集成調(diào)度器之一。網(wǎng)上討論它的文章很多但大多數(shù)只講“怎么裝”很少有人講透“怎么穩(wěn)穩(wěn)地裝、裝完怎么配、配完怎么維護(hù)”。我這一篇就把自己完整跑過一遍的路程整理出來從環(huán)境準(zhǔn)備、部署方案選型、初始化配置到第一個流水線任務(wù)跑通再到權(quán)限安全、備份恢復(fù)、容器化擴(kuò)展這些操作細(xì)節(jié)全部過一遍。1.2 閱讀這篇文章你能得到什么這篇文章不是寫給“已經(jīng)精通CI/CD的高級工程師”看的也不是寫給零基礎(chǔ)完全沒聽過持續(xù)集成的人看的。最適合的讀者是已經(jīng)知道持續(xù)集成大概是什么但真正動手部署Jenkins時缺一份完整實(shí)操參考的開發(fā)者、運(yùn)維工程師、以及團(tuán)隊(duì)里需要牽頭做交付流程梳理的技術(shù)負(fù)責(zé)人?？催^這篇文章之后你會得到幾樣?xùn)|西第一一張清晰的決策列表知道自己該用哪種方式部署Jenkins而不是隨便找一個安裝教程抄一遍第二一套可以直接照抄的初始化配置流程包括管理員賬號、插件源加速、全局工具配置這些容易踩坑的點(diǎn)第三一個完整的最小流水線示例從拉代碼到構(gòu)建到產(chǎn)物歸檔每一步都注釋到位第四一組我在實(shí)際維護(hù)中遇到的故障場景和解決思路比如插件裝不上怎么排查、進(jìn)程突然掛掉怎么恢復(fù)、數(shù)據(jù)怎么備份才是安全的。我的習(xí)慣是先把“為什么”講清楚再給“怎么做”。因?yàn)閱渭兂顩]有意義環(huán)境一變就會抓瞎但只要理解了背后的邏輯換一臺機(jī)器、換一個網(wǎng)絡(luò)環(huán)境你也能自己把問題順出來。2. 部署方案選型的核心邏輯2.1 Jenkins部署方式的三種主流選擇部署Jenkins表面上是“裝個軟件”實(shí)際上背后是“你打算怎么運(yùn)維它”。我先把我試過的三種主流方式羅列出來大家可以直接看對比結(jié)論。第一種是使用發(fā)行版原生包安裝。比如在Ubuntu上用apt安裝Jenkins系統(tǒng)會把init腳本、開機(jī)自啟、日志輪轉(zhuǎn)這些基礎(chǔ)的東西都配好。這種方式的好處是與系統(tǒng)集成度最高升級時包管理器會幫你處理依賴關(guān)系如果你只需要在本機(jī)快速跑起來這是最省心的路。但壞處是Jenkins自身數(shù)據(jù)全部放在一個目錄里系統(tǒng)如果出了亂七八糟的問題數(shù)據(jù)和系統(tǒng)環(huán)境耦合在一起遷移會比較被動。第二種是直接使用jenkins.war包配合外部Servlet容器運(yùn)行比如Tomcat。這種方式在老一代運(yùn)維那里比較流行把war包丟到Tomcat的webapps目錄里就能跑。好處是可以復(fù)用已有的Tomcat運(yùn)維經(jīng)驗(yàn)但代價是出了任何問題都要同時排查Tomcat和Jenkins兩層而且Jenkins對Servlet容器的版本有隱性要求踩過坑的人都知道這里面有多少兼容性問題。我個人的意見是如果不是公司里有強(qiáng)制要求必須復(fù)用Tomcat新項(xiàng)目完全沒必要選這條路徑。第三種是使用Docker容器化部署。這也是我目前在項(xiàng)目里采用的方式。Jenkins官方維護(hù)了若干鏡像比如jenkins/jenkins鏡像提供的是基于官方穩(wěn)定版的鏡像而jenkinsci則有更多歷史版本標(biāo)簽。容器化之后最直觀的好處是分發(fā)和升級都非常干凈數(shù)據(jù)目錄用數(shù)據(jù)卷獨(dú)立掛載想遷移就換個宿主機(jī)重新run一下想升級就把鏡像標(biāo)簽改掉跑一個新的容器連上同一個數(shù)據(jù)卷。但代價是你需要理解Docker的基本概念鏡像、容器、掛載、網(wǎng)絡(luò)。如果團(tuán)隊(duì)里沒有一個人對這些有概念容器化初期會有一點(diǎn)學(xué)習(xí)成本。下面我用一個表格把這三種方式的區(qū)別列出來方便大家做決策。對比維度原生命令行安裝war包 TomcatDocker容器安裝難度低中中低與系統(tǒng)集成度高中低升級與回滾依賴包管理器替換war包切換鏡像數(shù)據(jù)隔離弱弱強(qiáng)故障排查復(fù)雜度中高中遷移便攜性低低高適合場景一次性體驗(yàn) / 小團(tuán)隊(duì)單機(jī)老系統(tǒng)復(fù)用Tomcat需要頻繁升級或換環(huán)境看完這個表其實(shí)就很清楚了如果你只是個人練手用原生命令行裝沒問題十分鐘就能跑起來如果你所在的公司容器化已經(jīng)是事實(shí)標(biāo)準(zhǔn)你最好直接用Docker方案因?yàn)楹竺娌还芙覭8s還是做動態(tài)Agent都能順滑地過渡。而Tomcat這條路除非有明確的存量約束我是不建議新嘗試的。2.2 為什么容器化是多數(shù)團(tuán)隊(duì)的推薦起點(diǎn)有不少人問過我一個問題Docker跑Jenkins數(shù)據(jù)到底放哪里Jenkins有一個環(huán)境變量叫JENKINS_HOME它保存了所有任務(wù)配置、構(gòu)建記錄、插件、用戶信息、憑據(jù)。容器里這個目錄默認(rèn)是鏡像內(nèi)的某個路徑但容器一旦刪除目錄里的一切也跟著沒了。所以我強(qiáng)調(diào)的第一個原則就是JENKINS_HOME必須掛載到宿主機(jī)獨(dú)立目錄或者外部存儲卷。我在實(shí)際操作中用的命令基本長這樣mkdir -p /data/jenkins_home docker run -d \ --name jenkins \ -p 8080:8080 \ -p 50000:50000 \ -v /data/jenkins_home:/var/jenkins_home \ -v /etc/localtime:/etc/localtime:ro \ -e TZAsia/Shanghai \ jenkins/jenkins:lts這里有一個容易被忽略的細(xì)節(jié)端口50000。Jenkins主節(jié)點(diǎn)和構(gòu)建Agent節(jié)點(diǎn)之間默認(rèn)通過這個端口通信。如果以后要加構(gòu)建節(jié)點(diǎn)這個端口就必須保持可用而且防火墻里要放行。我見過有人圖省事只映射了8080最后加Agent的時候怎么都連不上排查半天才發(fā)現(xiàn)是端口沒映射。另一個細(xì)節(jié)是TZ環(huán)境變量。鏡像默認(rèn)的時區(qū)是UTC構(gòu)建日志里的時間戳看起來會跟北京時間差8個小時排查問題的時候非常折磨。掛載宿主機(jī)的時間配置文件或者直接設(shè)置TZ都能解決我更推薦直接設(shè)置環(huán)境變量干凈利落。2.3 關(guān)于硬件配置我的建議部署之前還要想一下資源規(guī)格。我自己在內(nèi)部項(xiàng)目里用的是一個2核4G的實(shí)例跑十幾個普通的構(gòu)建任務(wù)基本沒有壓力。但如果你打算讓Jenkins頻繁執(zhí)行大型前端項(xiàng)目的npm構(gòu)建或者Java項(xiàng)目的Maven打包節(jié)點(diǎn)內(nèi)存建議至少給到4核8G。原因很簡單Jenkins本身是一個常駐JVM進(jìn)程默認(rèn)的JVM堆設(shè)置會占掉不少內(nèi)存而在任務(wù)構(gòu)建高峰期系統(tǒng)里同時會有多個子進(jìn)程在跑內(nèi)存不夠會直接導(dǎo)致構(gòu)建機(jī)器無響應(yīng)。我建議剛上手的人在開始階段不用過度規(guī)劃先把最小配置跑起來等實(shí)際跑的任務(wù)量上來了再根據(jù)監(jiān)控數(shù)據(jù)做擴(kuò)容。說到底Jenkins的性能瓶頸大概率不在主節(jié)點(diǎn)本身而在同時觸發(fā)的構(gòu)建任務(wù)數(shù)和Agent節(jié)點(diǎn)的數(shù)量。主節(jié)點(diǎn)最怕的是同時跑太多重量級構(gòu)建所以后面有條件就盡量把構(gòu)建下沉到獨(dú)立的Agent上執(zhí)行。3. 從零到一Jenkins初始化與核心配置3.1 第一次啟動后你一定會經(jīng)歷的五步無論用哪種方式部署第一次打開Jenkins網(wǎng)頁都會進(jìn)入初始化向?qū)ЬW(wǎng)上很多教程把這一步一帶而過但這里面的每一步都有講究。我按自己實(shí)際走的順序拆開說。第一步是解鎖。安裝過程中會生成一個初始管理員密碼Docker方式可以通過docker log命令查看原生方式一般在安裝日志或指定文件里。拿到密碼輸入進(jìn)去才能繼續(xù)。這一步大家基本不會卡住唯一要提醒的是這個密碼只用于首次解鎖之后你會創(chuàng)建自己的管理員賬號來登錄。別把初始密碼記到筆記里就算完后面的賬號管理要盡早切換。第二步是安裝推薦插件。界面上會給兩個選項(xiàng)“安裝建議的插件”和“選擇插件來安裝”。對沒有明確插件管理經(jīng)驗(yàn)的人我建議先選“安裝建議的插件”把最常用的一組裝好然后在此基礎(chǔ)上按真實(shí)需求增補(bǔ)。不要一上來就裝一堆聽別人說好用的插件插件數(shù)量多了之后每次啟動光掃描更新就能讓人等很久而且插件之間的兼容性問題會在升級時集中爆發(fā)。第三步是創(chuàng)建第一個管理員用戶。這里我多說一句很多人圖省事直接用admin賬號繼續(xù)用這是運(yùn)維上的壞習(xí)慣。正確做法是創(chuàng)建一個帶真實(shí)業(yè)務(wù)含義的管理員賬號比如jenkins-admin然后把默認(rèn)的admin賬號設(shè)置成強(qiáng)密碼放在一邊只在緊急情況下使用。這樣后面無論接入LDAP還是做API Token管理身份邊界都更清晰。第四步是配置實(shí)例地址。系統(tǒng)會預(yù)填一個地址一般就是訪問Jenkins的URL。如果你后面要通過GitLab或GitHub的Webhook回調(diào)Jenkins這個地址必須是從外部能訪問到的地址。我在內(nèi)網(wǎng)環(huán)境里就吃過虧地址填了localhost結(jié)果代碼倉庫那邊回調(diào)總是失敗。記住這里填的是“別人能訪問到你的地址”不是你本機(jī)自我感覺的地址。第五步是初始配置完成后進(jìn)入主界面。到這一步部署還沒有結(jié)束因?yàn)槟氵B一個真正的構(gòu)建任務(wù)都還沒有。下面幾節(jié)我們要把跑任務(wù)前的基本功補(bǔ)上。3.2 插件源加速國內(nèi)環(huán)境部署一定要做的調(diào)整Open Source項(xiàng)目有一個共同的煩惱默認(rèn)下載源在國外。Jenkins的更新中心和插件下載中心默認(rèn)都指向國外地址在國內(nèi)網(wǎng)絡(luò)環(huán)境下經(jīng)常出現(xiàn)插件列表刷不出來、下載到一半超時的現(xiàn)象。這里的解決方案是把它切換到國內(nèi)的鏡像源。具體操作路徑是進(jìn)入“Manage Jenkins” - “Plugins” - “Advanced settings”把最下面“Update Site”里的URL替換成國內(nèi)鏡像地址。我用過之后發(fā)現(xiàn)效果穩(wěn)定的是清華鏡像源具體URL形如https://mirrors.tuna.tsinghua.edu.cn/jenkins/updates/update-center.json。但這個還不算完因?yàn)楹芏嗖寮?shí)際下載時走的還是自身pom里寫的下載地址所以更保險的做法是把鏡像源信息同時寫進(jìn)配置文件。有一種更徹底的方式是直接修改Jenkins主目錄里hudson.model.UpdateCenter.xml這個文件把下載地址整體替換掉。改完之后進(jìn)入插件管理界面點(diǎn)擊“Check now”就能看到插件列表很快刷出來。我實(shí)測下來切換后的下載速度有質(zhì)的提升幾MB的插件幾秒鐘就能拉完。這一步對國內(nèi)使用者來說幾乎等于“不換源就勸退”強(qiáng)烈建議部署完第一時間處理。注意修改Update Center地址后如果點(diǎn)擊檢查發(fā)現(xiàn)還是訪問原地址可以重啟一次Jenkins服務(wù)然后重新進(jìn)入插件管理頁面。3.3 全局工具配置讓Jenkins知道JDK和Maven在哪插件裝好之后還需要配置全局工具。這一步很多新手容易犯的錯是在服務(wù)器上明明已經(jīng)裝了Maven和JDK但Jenkins任務(wù)里就是提示找不到命令。原因在于Jenkins的任務(wù)進(jìn)程環(huán)境變量和當(dāng)前登錄用戶的環(huán)境變量不一定一致尤其是通過Docker啟動時容器基礎(chǔ)上可能壓根沒有你要用的工具。推薦的做法是直接在“Manage Jenkins” - “Tools”里配置工具。以JDK和Maven為例在JDK配置里可以指定一個已有的JDK路徑也可以讓Jenkins自動下載指定版本的JDK這會用到國內(nèi)網(wǎng)絡(luò)如果下載源不穩(wěn)定就手動上傳JDK包。Maven也是同樣的邏輯我可以給出一個最穩(wěn)妥的路徑下載一個Maven二進(jìn)制包解壓到宿主機(jī)目錄然后在“Tools”里把它設(shè)置成固定路徑。配完之后建議先做一個冒煙測試新建一個自由風(fēng)格任務(wù)里面的構(gòu)建步驟寫mvn -v執(zhí)行一次看控制臺輸出是否正常。這樣能確認(rèn)Jenkins和Maven之間的調(diào)用鏈?zhǔn)峭ǖ?。這個冒煙任務(wù)后面還能用來測試Webhook觸發(fā)不要刪留著當(dāng)“探針”用。3.4 憑據(jù)管理從第一次使用賬號密碼說起自動化流程里最不能出差錯的是憑據(jù)。Git拉取代碼要用戶名密碼或SSH Key推送產(chǎn)物到服務(wù)器要私鑰調(diào)接口要Token。這些東西如果直接寫在流水線腳本里風(fēng)險極大我見過不止一個人把密碼提交到代碼倉庫里然后被安全掃描抓出來。Jenkins提供了一套憑據(jù)管理機(jī)制在“Manage Jenkins” - “Credentials”里可以創(chuàng)建全局憑據(jù)。支持的類型包括Username with password、SSH Username with private key、Secret text、Certificate等。我在實(shí)際項(xiàng)目里最常用的組合是Git倉庫用SSH Key云平臺API用Secret text。創(chuàng)建好之后在流水線里通過憑據(jù)ID來引用別人只能看到ID和綁定類型看不到具體值。這里有一個細(xì)節(jié)值得記住憑據(jù)ID在建完之后最好手動改成有意義的字符串比如gitlab-ssh-key不要保留系統(tǒng)自動生成的那串UUID。因?yàn)楹竺婺銜谠絹碓蕉嗟牧魉€腳本里引用這個ID可讀性差會直接增加維護(hù)成本。4. 第一個流水線任務(wù)從自由風(fēng)格到Pipeline4.1 自由風(fēng)格任務(wù)最快看到構(gòu)建結(jié)果的方式對第一次接觸Jenkins的人來說我建議不要一上來就寫聲明式Pipeline雖然那是以后的主流但從自由風(fēng)格任務(wù)起步更容易建立感覺。Dashboard頁面上點(diǎn)“New Item”輸入一個任務(wù)名稱選擇“Freestyle project”然后進(jìn)入配置頁面。一個最小可用的自由風(fēng)格任務(wù)至少要配置三塊第一是源碼管理選擇Git并填上倉庫地址然后在Credentials中選擇前面配好的憑據(jù)第二是構(gòu)建觸發(fā)器最簡單的先選“Poll SCM”或手動點(diǎn)“立即構(gòu)建”觸發(fā)Webhook我們稍后單獨(dú)講第三是構(gòu)建步驟比如“Invoke top-level Maven targets”或直接執(zhí)行Shell命令。以Java項(xiàng)目為例構(gòu)建步驟可以簡單寫成這樣mvn clean package -DskipTests保存之后點(diǎn)擊“立即構(gòu)建”第一次構(gòu)建會從零開始跑。這時候可以左側(cè)面板進(jìn)入“Console Output”觀察實(shí)時日志。我看了無數(shù)次這個日志說句實(shí)在話這個頁面就是你診斷一切構(gòu)建問題的第一現(xiàn)場學(xué)會在這里面快速撈關(guān)鍵行是一項(xiàng)基本能力。第一次構(gòu)建完成后如果Workspace里能看到target目錄和最終的jar包說明這條鏈路已經(jīng)通了?？刂婆_輸出末尾出現(xiàn)Finished: SUCCESS就是一個里程碑式的時刻。但請注意這個任務(wù)現(xiàn)在還只是“能跑”離“自動觸發(fā)”“產(chǎn)物歸檔”還差好幾步。4.2 聲明式Pipeline讓流程變成代碼自由風(fēng)格任務(wù)跑通之后我強(qiáng)烈建議你再往前推進(jìn)一步改成聲明式Pipeline。理由很實(shí)在自由風(fēng)格任務(wù)的配置存在Jenkins內(nèi)部抄到別的環(huán)境非常麻煩而Pipeline把整個流程寫成一份Jenkinsfile放在你的項(xiàng)目倉庫里跟著代碼走換環(huán)境、換機(jī)器、換Jenkins實(shí)例都不怕。一個最小可用的Jenkinsfile大概長這樣pipeline { agent any stages { stage(拉取代碼) { steps { echo 代碼已由SCM模塊處理 } } stage(單元測試) { steps { sh mvn test } } stage(構(gòu)建打包) { steps { sh mvn clean package -DskipTests } } stage(歸檔產(chǎn)物) { steps { archiveArtifacts artifacts: target/*.jar, fingerprint: true } } } }這份文件放到倉庫根目錄后在Jenkins里新建一個“Pipeline”類型任務(wù)在Pipeline配置段里選擇“Pipeline script from SCM”指定倉庫地址和文件路徑保存后點(diǎn)擊構(gòu)建效果跟之前的自由風(fēng)格任務(wù)一致但你現(xiàn)在可以把整個流程和代碼一起進(jìn)行版本管理了。這里有一個經(jīng)驗(yàn)歸檔產(chǎn)物是整個流水線里容易被忽視的一環(huán)。不管你是構(gòu)建jar包、鏡像還是安裝包都應(yīng)該把關(guān)鍵產(chǎn)物通過archiveArtifacts保留下來。因?yàn)楹罄m(xù)你想回滾、想審計某個版本是哪個代碼構(gòu)建出來的靠的就是這些歸檔記錄。不要覺得“反正有構(gòu)建日志”日志會滾動清理而歸檔產(chǎn)物在保留策略內(nèi)是穩(wěn)定存在的。4.3 構(gòu)建觸發(fā)器從手動到自動的關(guān)鍵一步任務(wù)能手動構(gòu)建只是第一步持續(xù)集成的核心在于“自動觸發(fā)”。常用觸發(fā)方式有四種我逐一說明。第一種是定時構(gòu)建配置里可以寫cron表達(dá)式固定每天幾點(diǎn)構(gòu)建一次。適合夜間打包場景比如每天凌晨跑一次全量測試。第二種是Poll SCMJenkins會定期檢查代碼倉庫里是否有新提交有變化就構(gòu)建本質(zhì)上也是輪詢有延遲但簡單。第三種是Webhook觸發(fā)代碼倉庫每次推送代碼時主動調(diào)用Jenkins接口實(shí)時性最強(qiáng)也是現(xiàn)代CI的推薦做法。第四種是上下游任務(wù)觸發(fā)的Pipeline方式在代碼里通過build步驟來聯(lián)動適合有依賴關(guān)系的多個任務(wù)。Webhook的配置要點(diǎn)我之前提過一部分這里再補(bǔ)充一點(diǎn)在項(xiàng)目配置里勾選“GitHub hook trigger for GITScm polling”然后在代碼倉庫的管理端配置Webhook地址指向http://你的Jenkins地址/github-webhook/。如果是其他代碼托管平臺路徑稍有差別但思路是一樣的。我當(dāng)初第一次配Webhook花了很長時間排查問題最后發(fā)現(xiàn)是地址里漏了/github-webhook/這個固定后綴代碼倉庫那邊怎么推都觸發(fā)不了。所以遇到類似問題第一反應(yīng)先檢查回調(diào)地址的后綴拼寫是否完整。4.4 環(huán)境變量與參數(shù)化構(gòu)建讓任務(wù)變得更靈活自動化程度越高越會發(fā)現(xiàn)“硬編碼”是一件讓人頭疼的事。比如你給它寫死了要構(gòu)建的分支是master等你想構(gòu)建release/1.0分支時還得去改配置。解決這個問題的方式是參數(shù)化構(gòu)建。在Pipeline中可以通過parameters指令定義參數(shù)運(yùn)行時由用戶在界面上填寫或選擇。舉一個例子pipeline { agent any parameters { choice(name: BRANCH, choices: [master, develop, release/1.0], description: 請選擇要構(gòu)建的分支) string(name: TAG, defaultValue: , description: 可選指定構(gòu)建標(biāo)簽) } stages { stage(Checkout) { steps { checkout scm } } stage(Print Params) { steps { echo 當(dāng)前分支: ${params.BRANCH} echo 當(dāng)前標(biāo)簽: ${params.TAG} } } } }有了這樣的參數(shù)同一個任務(wù)就可以面對不同的發(fā)布場景。團(tuán)隊(duì)里別的同事只需要在界面上選一個分支點(diǎn)構(gòu)建剩下的流程完全由Pipeline自己跑。這對交付效率的提升是立竿見影的終于不用半夜把運(yùn)維叫起來改配置了。注意參數(shù)化配置應(yīng)該是“默認(rèn)有合理值、支持特殊情況覆蓋”而不是每個任務(wù)都要求人去填一長串字段。填參數(shù)也是心智負(fù)擔(dān)能少填就少填。5. 權(quán)限、安全與維護(hù)5.1 基于角色的權(quán)限控制多團(tuán)隊(duì)協(xié)作不能省當(dāng)團(tuán)隊(duì)里只有你自己在用Jenkins時管理員權(quán)限怎么折騰都行。但當(dāng)人多起來比如后端、前端、測試、運(yùn)維都要進(jìn)同一個Jenkins看構(gòu)建結(jié)果如果你的權(quán)限管理是一團(tuán)漿糊很快就會出亂子有人誤刪了別人的任務(wù)有人改了生產(chǎn)環(huán)境的構(gòu)建配置。這里我建議引入基于角色的權(quán)限控制。Jenkins自帶的“安全”配置里第一件事是把“Authorization”設(shè)置成“Logged-in users can do anything”或更細(xì)粒度的矩陣授權(quán)策略。注意我不會建議你把“Anyone can do anything”保留太久哪怕是在內(nèi)網(wǎng)這也不應(yīng)該長期存在。安全最佳實(shí)踐是默認(rèn)情況下禁止匿名用戶做任何寫操作。更進(jìn)一步可以裝一個Role-based Strategy插件它能實(shí)現(xiàn)“按角色分配任務(wù)和視圖”。比如某一個團(tuán)隊(duì)的角色只能看到自己的項(xiàng)目不允許操作別人的任務(wù)。這種管控在多人協(xié)作場景下幾乎是剛需。我經(jīng)歷過一次“某同事在做測試演練時一下子把所有任務(wù)全刪了”的事故之后就堅定地給每個團(tuán)隊(duì)劃了獨(dú)立視圖和獨(dú)立權(quán)限。5.2 Jenkins主目錄解析數(shù)據(jù)到底存放在哪里JENKINS_HOME是一個核心目錄整個Jenkins的一切狀態(tài)都在里面。我建議每個維護(hù)者都花十分鐘把里面的結(jié)構(gòu)走一遍。最核心的幾個子目錄是jobs目錄存放所有任務(wù)定義和構(gòu)建記錄plugins目錄存放已安裝的插件users目錄存放用戶信息credentials.xml存放憑據(jù)配置config.xml是全局配置文件workspace是構(gòu)建工作目錄。搞懂這個目錄結(jié)構(gòu)有兩個實(shí)際的用處。第一個是備份你不需要什么高級工具直接打包整個JENKINS_HOME目錄就是一份完整的備份第二個是遷移把打包目錄解壓到新機(jī)器的同一個掛載路徑下重啟Jenkins你的任務(wù)和配置就全部回來。我在遷移一個跑了一年多的Jenkins實(shí)例時就是靠這個目錄拷貝完成的整個過程沒有丟失任何配置。當(dāng)然有一點(diǎn)要提醒workspace下面那些臨時構(gòu)建文件其實(shí)沒必要備份備份時可以用排除規(guī)則把workspace、logs這類目錄去掉能明顯減小備份體積。更安全的做法是同時備份所有者和權(quán)限位尤其在Linux下直接壓縮解壓時要留意用戶ID是否一致否則可能出現(xiàn)權(quán)限錯亂導(dǎo)致Jenkins啟動異常。5.3 定期備份與版本升級維護(hù)者的兩條保命繩維護(hù)Jenkins最怕的兩件事一是數(shù)據(jù)丟失二是升級失敗。數(shù)據(jù)丟失的應(yīng)對方式就是備份升級失敗的應(yīng)對方式就是回滾。備份策略我的做法是這樣的用crontab每天凌晨執(zhí)行一次全量打包同時保留最近7天的備份把備份文件存放到另一臺機(jī)器或獨(dú)立存儲上。為什么一定要“異地”因?yàn)槿绻拗鳈C(jī)本身壞了放在同一臺機(jī)器上的備份也是廢的。這個道理看起來簡單但我確實(shí)見過很多團(tuán)隊(duì)把備份文件放在Jenkins同一臺服務(wù)器上結(jié)果服務(wù)器磁盤故障時連備份一起沒了。升級的邏輯則是“先備份再升級”。有人會說升級前一點(diǎn)小事用得著備份嗎實(shí)際體驗(yàn)是插件版本變化對配置文件的兼容性影響有時候非常隱蔽你可能升級完之后發(fā)現(xiàn)某個任務(wù)的配置項(xiàng)失效了構(gòu)建開始報錯。這時候如果你的升級前備份還在直接把舊版本數(shù)據(jù)和舊版本鏡像倒回去十分鐘就能恢復(fù)環(huán)境。這個操作成本很低收益卻極高。5.4 日志管理與系統(tǒng)清理別讓磁盤悄悄爆掉Jenkins是一個日志大戶。每次構(gòu)建的控制臺輸出、任務(wù)的歷史記錄、插件的日志、系統(tǒng)日志日積月累磁盤占用非?？捎^。我遇到過一次最典型的故障構(gòu)建任務(wù)突然大面積失敗報錯是“No space left on device”最初以為是系統(tǒng)盤滿了一查才發(fā)現(xiàn)是JENKINS_HOME里的構(gòu)建日志和workspace占滿了數(shù)據(jù)盤。解決這個問題不能靠“滿了再刪”應(yīng)該建立一套日常清理機(jī)制。Jenkins的任務(wù)配置里可以對構(gòu)建記錄設(shè)置保留策略比如只保留最近10次構(gòu)建記錄舊的自動清理。在全局配置里也可以設(shè)置系統(tǒng)日志的保留條數(shù)和文件大小。另外workspace目錄可以定期寫一個清理腳本把超過一定天數(shù)的臨時目錄清掉。我的建議是把這些清理動作固化成一個定時任務(wù)每月執(zhí)行一次并且輸出清理報告到日志里方便后續(xù)追溯。這些事看起來瑣碎但是只要出一次磁盤故障你就會明白這十分鐘的日常維護(hù)有多值。6. 常見問題與排查技巧實(shí)錄6.1 插件安裝失敗或下載速度慢場景描述插件管理頁面刷新列表超時或者點(diǎn)擊安裝某插件后進(jìn)度條一直不動最后報錯。排查思路第一步檢查Update Center的配置是不是默認(rèn)國外源如果是盡快切換國內(nèi)鏡像源第二步確認(rèn)鏡像源URL是否加對了路徑有的鏡像源需要在URL后追加update-center.json這樣的固定路徑缺少會報404第三步如果改完后還是沒有變化重啟Jenkins再試一次。我遇到過一種特殊情況內(nèi)網(wǎng)環(huán)境與公網(wǎng)隔離根本訪問不了任何外部鏡像源。這種情況下只能走離線安裝路線在另一臺能聯(lián)網(wǎng)的機(jī)器上把插件.hpi文件下載好然后通過插件管理的高級標(biāo)簽頁上傳安裝。注意插件之間也有依賴關(guān)系離線裝之前先把它的依賴插件一并下載否則很可能報“依賴缺失”一類錯誤。6.2 構(gòu)建任務(wù)一直卡在等待狀態(tài)場景描述點(diǎn)擊構(gòu)建之后任務(wù)一直顯示“等待”或者“pending”狀態(tài)面板提示queue里卡住了。排查思路最常見的兩個原因一是沒有可用的執(zhí)行節(jié)點(diǎn)二是執(zhí)行節(jié)點(diǎn)的并發(fā)數(shù)到達(dá)上限。查看“Build Executor Status”區(qū)域看主節(jié)點(diǎn)是否有空閑的executor如果全部是busy狀態(tài)說明同時跑的構(gòu)建太多要么調(diào)大executor數(shù)量要么安排構(gòu)建排隊(duì)。還有一種原因是某個構(gòu)建腳本卡死占著executor不放。這時候需要去對應(yīng)任務(wù)里停止或終止那個構(gòu)建釋放executor。在容器化環(huán)境下還有第三種原因Docker容器啟動時資源限制設(shè)置過低系統(tǒng)因資源耗盡而無法fork新進(jìn)程來執(zhí)行構(gòu)建。這時候看宿主機(jī)日志會發(fā)現(xiàn)OOM相關(guān)記錄通常是給容器調(diào)高內(nèi)存配額就能解決。6.3 Git拉取代碼時報權(quán)限錯誤場景描述流水線在checkout階段報“Permission denied”或“Host key verification failed”。排查思路前者通常是SSH Key沒有配好或憑據(jù)ID引用錯誤后者是第一次連接代碼倉庫時出現(xiàn)的主機(jī)指紋確認(rèn)提示而Jenkins任務(wù)是非交互環(huán)境沒法手動輸入yes。常見的解決辦法是在全局配置里設(shè)置StrictHostKeyChecking為no或者在執(zhí)行構(gòu)建動作前先手動把代碼倉庫主機(jī)加入known_hosts。另一個容易被忽略的點(diǎn)如果你在憑據(jù)里配的是用戶名密碼而不是SSH Key要確認(rèn)代碼托管平臺允許HTTP方式的密碼認(rèn)證。不少平臺已經(jīng)不支持這種老式認(rèn)證必須改用Token或個人訪問令牌。這時候可以把Token作為密碼字段填入憑據(jù)一般都能解決。6.4 Webhook觸發(fā)了但任務(wù)沒反應(yīng)場景描述代碼倉庫已經(jīng)配置好了Webhook推送代碼之后Jenkins這邊沒有自動觸發(fā)構(gòu)建。排查思路第一查Webhook地址是否能從外網(wǎng)訪問我前面強(qiáng)調(diào)過地址里不能有l(wèi)ocalhost第二查Webhook地址后綴是否是/github-webhook/這個路徑是Jenkins內(nèi)部約定的回調(diào)路徑很多人漏掉第三查任務(wù)配置里是否勾選了對應(yīng)的觸發(fā)選項(xiàng)第四查Jenkins日志里有沒有收到POST請求的痕跡。如果日志里根本沒有請求記錄問題大概率出在網(wǎng)絡(luò)路徑上如果有請求記錄但任務(wù)沒觸發(fā)大概率是任務(wù)配置或插件問題。最后一個小技巧很多代碼托管平臺的Webhook管理后臺會保留最近幾次請求記錄和響應(yīng)狀態(tài)進(jìn)去看那些信息排查效率會高很多。7. 進(jìn)階擴(kuò)展容器化時代的Jenkins維護(hù)7.1 流水線中構(gòu)建Docker鏡像從jar包到鏡像在CI流程里如果你只構(gòu)建到j(luò)ar包那還算傳統(tǒng)意義上的CI但如果你能做到“提交代碼 - 自動測試 - 自動構(gòu)建鏡像 - 推送到鏡像倉庫 - 觸發(fā)部署”那就已經(jīng)摸到了CI/CD一體化的邊。Pipeline里要把構(gòu)建出的jar包做成鏡像通常的做法是在Jenkins里配置Docker Host的地址然后在Pipeline中調(diào)用docker build和docker push。如果是通過Docker容器方式啟動的Jenkins本身這里有一個經(jīng)典的坑容器內(nèi)沒有Docker客戶端和守護(hù)進(jìn)程。解決辦法有幾種一種是通過掛載宿主機(jī)的docker.sock文件來讓容器內(nèi)操作宿主機(jī)Docker守護(hù)進(jìn)程另一種是在容器里安裝Docker客戶端然后通過網(wǎng)絡(luò)連接到遠(yuǎn)程Docker引擎。我在內(nèi)部實(shí)驗(yàn)環(huán)境用的是掛載socket的方式命令大概長這樣-v /var/run/docker.sock:/var/run/docker.sock但這種方式有安全代價誰能在Jenkins容器里執(zhí)行命令誰就基本等同于拿到了宿主機(jī)的Docker控制權(quán)。所以線上環(huán)境如果有條件更推薦使用獨(dú)立Agent節(jié)點(diǎn)執(zhí)行這類構(gòu)建不要在Jenkins主容器里直接掛socket。安全性和便利性往往是取舍但越是生產(chǎn)環(huán)境越要偏向安全。7.2 動態(tài)構(gòu)建節(jié)點(diǎn)從單機(jī)到分布式的一點(diǎn)思路當(dāng)構(gòu)建任務(wù)多了以后單機(jī)跑所有構(gòu)建會讓主節(jié)點(diǎn)負(fù)載過高。最常見的演進(jìn)方向是引入構(gòu)建Agent。Agent節(jié)點(diǎn)的職責(zé)是執(zhí)行構(gòu)建任務(wù)主節(jié)點(diǎn)只負(fù)責(zé)調(diào)度、記錄和展示。這樣主節(jié)點(diǎn)可以保持輕量化重型構(gòu)建任務(wù)都下沉到按需創(chuàng)建的Agent上執(zhí)行。容器化時代比較流行的方案是使用Docker插件或Kubernetes插件。Docker插件可以在每次構(gòu)建時動態(tài)創(chuàng)建一個干凈的容器作為Agent任務(wù)結(jié)束后容器自動銷毀保證了構(gòu)建環(huán)境的一致性避免“上次構(gòu)建留下的殘留文件影響這次構(gòu)建”這種老問題。Kubernetes插件則更進(jìn)一步讓Jenkins從K8s集群中動態(tài)申請Pod作為Agent。如果你現(xiàn)在只是在單機(jī)上跑Jenkins我的建議是不用急著上這些重量級方案。先把轉(zhuǎn)發(fā)代理、流水線參數(shù)化、制品歸檔這些基本功打牢等任務(wù)量增長到單機(jī)明顯扛不住的時候再花時間搭A(yù)gent體系。工具的演進(jìn)永遠(yuǎn)跟著實(shí)際瓶頸走不要為“炫技術(shù)”而引入復(fù)雜度。7.3 備份遷移的容器化便捷之處容器化之后做遷移有一個非常直觀的體驗(yàn)只需要把宿主機(jī)上掛載的JENKINS_HOME目錄完整拷貝到新機(jī)器然后在新機(jī)器上用同樣的掛載參數(shù)啟動一個同版本鏡像的容器再重啟服務(wù)整個環(huán)境就回來了。相比傳統(tǒng)安裝方式需要重新裝系統(tǒng)依賴、重新做JDK環(huán)境配置的做法容器化省去的這些環(huán)節(jié)在時間緊張的故障恢復(fù)場景里就是救命。這里有一個細(xì)節(jié)我在遷移時不僅拷貝數(shù)據(jù)還會記錄啟動時的鏡像tag最好把鏡像tag也固定下來。這樣一旦升級后發(fā)現(xiàn)不兼容可以迅速降級回原來的鏡像版本數(shù)據(jù)目錄完全不用動。這個“鏡像版本固定 數(shù)據(jù)獨(dú)立掛載”的組合是我認(rèn)為容器化部署Jenkins最核心的一個實(shí)踐原則。8. 實(shí)例復(fù)盤一次完整的部署落地8.1 現(xiàn)場環(huán)境回顧我以自己實(shí)際做過的某次部署為例把整個過程的決策鏈串起來復(fù)盤一遍。環(huán)境是這樣的某內(nèi)部研發(fā)團(tuán)隊(duì)需要支撐Java后端和Node前端兩條業(yè)務(wù)的構(gòu)建代碼托管在內(nèi)網(wǎng)Git服務(wù)上最終目標(biāo)是把制品交給后續(xù)的發(fā)布平臺來消費(fèi)。沒有外網(wǎng)到內(nèi)網(wǎng)的直接訪問但在內(nèi)網(wǎng)環(huán)境可以訪問到公共鏡像源的鏡像本身網(wǎng)絡(luò)條件不算復(fù)雜但有一點(diǎn)要注意插件下載需要走外部網(wǎng)絡(luò)通道。我選擇的方案是Docker部署。具體步驟為先在一臺內(nèi)網(wǎng)機(jī)器上創(chuàng)建JENKINS_HOME目錄用官方LTS鏡像啟動一個實(shí)例接著處理插件源加速把Update Center換成可訪問的鏡像地址然后配置JDK和Maven的全局工具重點(diǎn)確認(rèn)這些工具的路徑在容器內(nèi)可見再創(chuàng)建憑據(jù)接入內(nèi)網(wǎng)Git最后建第一個自由風(fēng)格任務(wù)做冒煙測試確認(rèn)基礎(chǔ)鏈路可用。這份流程看起來平淡無奇但每一步都踩過一些坑我下面把關(guān)鍵的決斷點(diǎn)展開講一講。8.2 第一次冒煙測試為什么失敗了第一次執(zhí)行冒煙測試時我預(yù)期是“mvn -v”能直接打出版本信息但控制臺輸出是“mvn: command not found”。問題出在工具路徑配置上。我在宿主機(jī)上裝了Maven但容器內(nèi)看不到宿主機(jī)的路徑必須在Jenkins的全局工具配置里指定容器內(nèi)可見的Maven路徑或者直接把Maven解壓到掛載的數(shù)據(jù)卷目錄里讓JENKINS_HOME和工具目錄在同一個卷內(nèi)。第二個問題是時區(qū)。第一次構(gòu)建日志里的時間戳全部顯示UTC我排查構(gòu)建任務(wù)執(zhí)行順序時完全對不上預(yù)期。把TZ環(huán)境變量設(shè)置好重啟容器之后日志時間才與本地時間一致。第三個問題是目錄權(quán)限。Docker容器是以jenkins用戶身份運(yùn)行的默認(rèn)UID為1000。如果宿主機(jī)創(chuàng)建的數(shù)據(jù)目錄所有者是root容器內(nèi)jenkins用戶就沒有寫權(quán)限。解決辦法是把數(shù)據(jù)目錄所有者的UID改成1000或者通過chown將目錄所有權(quán)調(diào)整給UID 1000。這個細(xì)節(jié)如果不注意啟動容器時會看到日志里不斷報目錄無法寫入的異常很多人會誤以為是啟動命令寫錯了實(shí)際上是權(quán)限問題。8.3 上線后的第一個高峰并發(fā)構(gòu)建卡死跑了一段時間后團(tuán)隊(duì)開始在上面執(zhí)行前端、后端兩類任務(wù)的批量構(gòu)建很快出現(xiàn)了高峰期構(gòu)建排隊(duì)嚴(yán)重的情況。查看后發(fā)現(xiàn)是主節(jié)點(diǎn)默認(rèn)的executor數(shù)量只有2同時只能跑兩個任務(wù)。我將主節(jié)點(diǎn)executor數(shù)量調(diào)大到4并用參數(shù)化構(gòu)建讓重量級任務(wù)顯式排隊(duì)問題緩解了不少但接著又出現(xiàn)了一個更隱蔽的問題某個任務(wù)構(gòu)建過程中產(chǎn)生了大量臨時文件主節(jié)點(diǎn)磁盤空間在一天之內(nèi)從40%漲到85%。這次經(jīng)歷堅定了我做定期清理的決心。我把workspace保留天數(shù)調(diào)整為7天把構(gòu)建歷史保留到最近20次設(shè)定了一個每天凌晨執(zhí)行的清理腳本并加了一個磁盤使用率告警。從這以后磁盤容量再也沒有成為運(yùn)維事故的觸發(fā)點(diǎn)。8.4 從主節(jié)點(diǎn)構(gòu)建到獨(dú)立Agent的遷移計劃隨著任務(wù)種類越來越多我越來越覺得在主節(jié)點(diǎn)上直接跑構(gòu)建不是長久之計。計劃把運(yùn)行時的構(gòu)建任務(wù)逐步轉(zhuǎn)移到Docker動態(tài)Agent上主節(jié)點(diǎn)只承擔(dān)調(diào)度和展示。這樣每次構(gòu)建的環(huán)境都是全新的不受歷史殘留影響而且可以針對Java和前端任務(wù)分別定義帶不同工具鏈的Agent容器。這個遷移過程不用急我采用的方式是先把一個新的任務(wù)配置成“在Docker容器中運(yùn)行”驗(yàn)證通過后再逐個遷移。這種漸進(jìn)的切換方式最大的好處是出了任何問題都能快速回退不至于整個CI系統(tǒng)一下子癱瘓。9. 個人經(jīng)驗(yàn)補(bǔ)充兩個值得長期堅持的習(xí)慣最后說兩個我一直堅持的習(xí)慣。第一個習(xí)慣是任何時候修改Jenkins配置之前先導(dǎo)出一份配置文件快照。這個操作成本極低但效果極大。我見過太多人改了一個權(quán)限策略之后整個團(tuán)隊(duì)什么都看不了了最后只能靠回憶往前翻既耗時又容易出錯。如果你在改動前有一個完整備份恢復(fù)只是覆蓋還原目錄的事。第二個習(xí)慣是把Jenkins的維護(hù)要點(diǎn)用文檔記錄下來包括部署時的初始命令、配置文件路徑、插件清單、備份策略、恢復(fù)步驟全部寫成一份運(yùn)行手冊。這看起來不是技術(shù)活但當(dāng)團(tuán)隊(duì)里換人交接時這份手冊就是整個CI系統(tǒng)能否持續(xù)運(yùn)轉(zhuǎn)的定心丸。設(shè)備會變技術(shù)棧會升級但一套被驗(yàn)證過的維護(hù)流程能幫你和你的團(tuán)隊(duì)省下大量重復(fù)踩坑的時間。Jenkins這套系統(tǒng)部署起來其實(shí)不算難難的是你在部署時有沒有把后續(xù)的擴(kuò)展、安全、備份這些事想清楚。把它當(dāng)作一個長期在線的服務(wù)來維護(hù)而不是一個裝完就跑的臨時工具是我從多次實(shí)踐中得到的最重要的心得。