電商測試環境Jenkins multibranch pipeline實踐


一、背景情況

  1. 整個項目組有32個java應用,10個javascript應用以及若干其他應用,並且還有增加的趨勢;
  2. 3套測試環境,測試發布非常頻繁,並且有同一個應用不同分支並行測試的情況;
  3. 版本管理器gitlab在公司內網局域網,測試環境在公網的青雲主機上;
  4. Java應用在測試環境,可能有單節點或多節點部署;
  5. Java應用非常多,內存吃緊,需要合理部署應用在主機上,並且增加限制內存使用的啟動參數;
  6. Java應用有多種部署及啟動方式,有tomcat部署的,有一個整的jar包方式部署的,有jar包與配置文件分離並且主要配置都在配置管理中心的部署方式;
  7. 代碼管理分支策略方式為,從master分支切出功能開發分支,並且其他分支提交到master分支的變更及時合並到此開發分支用以消除代碼沖突,此分支發布生產環境之后,合並到master分支;
  8. 配置文件繁多,不同的環境配置文件不同;


二、multibranch pipeline介紹及實現構想
1、簡單介紹:
A、先介紹下什么是Jenkins 2.0,Jenkins 2.0的精髓是 Pipeline as Code,是幫助Jenkins實現CI到CD轉變的重要角色。什么是Pipeline,簡單來說,就是一套運行於Jenkins上的工作流框架,將原本獨立運行於單個或者多個節點的任務連接起來,實現單個任務難以完成的復雜發布流程。Pipeline的實現方式是一套Groovy DSL,任何發布流程都可以表述為一段Groovy腳本,並且Jenkins支持從代碼庫直接讀取腳本,從而實現了Pipeline as Code的理念。
B、multiBranch Pipeline的使用首先需要在每個分支代碼的根目錄下存放Jenkinsfile(Pipeline的定義文件),我們可以理解下maven的pom.xml文件,Jenkinsfile作為pipeline的管理文件也需要在源代碼中進行直接的配置管理。這就要求devops工程師(QA、運維等)首先要有代碼庫的權限,或者至少賦能給dev工程師jenkinsfile的設計能力。
2、Groovy DSL定義了測試環境發布的所有步驟,包括:合並master分支,選擇配置文件與替換,編譯構建,上傳構建后的應用包文件,部署應用;
3、上傳包文件有唯一的shell腳本,不同測試環境的不同應用的包對應上傳到包文件中轉主機上不同的路徑;
4、部署應用,都使用ansible的playbook劇本控制,java應用包括結束進程,替換應用包,重啟應用。靜態頁面只需要替換。由於各個應用的部署方式差別較大,所有暫時每個應用都有單獨ansible劇本,部署到不同環境參數有不同變量;
5、Groovy DSL流程固定,將其中變量作為參數列出來,再增加新的應用需要發布的時候,直接用模板,只需要修改變量參數即可使用;
6、Jenkinsfile保存在gitlab中項目代碼的master分支根目錄,不會丟失,不會被篡改,對Jenkins服務器依賴小不需要額外備份;
7、每個應用只需要配置一個Jenkins的項目即可部署到多個環境,其中實現選擇功能,使用"Extended Choice Parameter"插件;
8、發布不同的分支直接選擇即可;
9、每套環境有多台主機,ansible的劇本根據各個主機上是否有次應用的目錄來確定是否將應用部署到主機上,不需要配置的時候指定主機;
10、使用cksum進行CRC校驗;
11、打印出部署的java應用的進程ID。 
三、整體拓撲結構

  1. Jenkins、nexus和gitlab都在公司內網局域網,測試環境都是青雲雲主機;
  2. 測試環境由一台專門的中轉主機(transfer station),打包之后的包文件先上傳到這個中轉主機上,然后再分發到對應的測試環境的主機;
  3. 測試環境的主機,啟動java應用進程,結束java應用進程,刪除舊的包,傳輸新的包,全部是Jenkins的主機通過ansible控制;
  4. Multibranch pipeline方式,gitlab上項目的master分支,增加Jenkinsfile文件。
  5. 通過Jenkins的pipeline流水線作業,完成了從編譯構建到部署的全部過程,即持續部署(continue deploy)。
  6. 為了簡化過程,gitlab用戶名密碼保存在Jenkins主機的linux系統上,Jenkins主機ansible也是給測試環境主機分組並且用ssh密鑰登錄。
  7. 總結:Jenkinsfile文件放在gitlab項目master分支的根目錄;Jenkins系統上配置multibranch pipeline項目;上傳文件的shell腳本和部署應用的ansible playbook腳本都存放在Jenkins的主機上,Jenkinsfile中定義了調用這兩個腳本。


四、發布過程涉及到的步驟
1、合並master分支代碼;
2、替換不同環境的配置文件;
3、編譯構建;
4、上傳編譯的包文件到linux主機;
5、結束應用的舊進程,替換包文件,重啟應用。

五、Groovy DSL實現

1、Jenkins pipeline的代碼實現,先將所有的變量都單獨抽取出來,使用腳本編程方式。因為有合並master分支到測試分支的需要,所以得獲取到Jenkins項目的環境變量:gitlab URL和分支名字;選擇環境的變量使用"Extended Choice Parameter"插件;

2、合並master分支並且提交

3、替換配置文件,這里需要判斷提供的路徑指向的是目錄還是文件

4、maven構建

5、上傳構建完成后生產的包,調用shell腳本,其中包的相對路徑、Jenkins的job名字和部署到的環境為三個參數變量

6、部署,需要三個參數,分布是Jenkins的job名字,部署到的環境,以及部署此java應用的ansible playbook劇本的絕對路徑,因為劇本保存在Jenkins的主機上。

六、上傳腳本


Shell腳本做了三件事:

  1. 根據Jenkinsfile調用腳本的時候給的包路徑的參數,判斷是否需要歸檔打包,如果需要打包則tar歸檔打包;
  2. Cksum在Jenkins主機上進行CRC校驗;
  3. 上傳包到中轉主機的指定的路徑,此處用scp通過公網上傳。

 

七、ansible部署劇本

1、判讀是否存在此應用的路徑,記錄結果,忽略報錯

2、kill此應用的進程,如果步驟1的判斷結果result是succeeded的時候

3、刪掉舊的包文件,由於此處部署測試環境,無需備份保留,可以直接刪除,條件也是步驟1的判斷結果result是succeeded

4、從包中轉機器下載包文件,條件也是步驟1的判斷結果result是succeeded

5、cksum進行CRC校驗

6、重新啟動應用,捕獲報錯信息

7、返回進程ID

 
注意:
上傳包的shell腳本和部署應用的ansible劇本中,很多命名都是統一了方式。

八、Jenkins配置job

1、新建multibranch pipeline項目

2、配置gitlab地址

3、構建配置

4、配置完畢之后保存,然后掃描分支

5、掃描出來分支,點進去,構建,這里會顯示所有的變量

6、在控制台的輸出中,能看到CRC校驗值以及進程ID

 


免責聲明!

本站轉載的文章為個人學習借鑒使用,本站對版權不負任何法律責任。如果侵犯了您的隱私權益,請聯系本站郵箱yoyou2525@163.com刪除。



 
粵ICP備18138465號   © 2018-2025 CODEPRJ.COM