一、Jenkins是什麼？

目前持續整合(CI)已成為當前許多軟體開發團隊在整個軟體開發生命週期內側重於保證程式碼質量的常見做法。它是一種實踐，旨在緩和和穩固軟體的構建過程。並且能夠幫助您的開發團隊應對如下挑戰：

• 軟體構建自動化：配置完成後，CI系統會依照預先制定的時間表，或者針對某一特定事件，對目標軟體進行構建。
• 構建可持續的自動化檢查：CI系統能持續地獲取新增或修改後簽入的原始碼，也就是說，當軟體開發團隊需要週期性的檢查新增或修改後的程式碼時，CI系統會不斷確認這些新程式碼是否破壞了原有軟體的成功構建。這減少了開發者們在檢查彼此相互依存的程式碼中變化情況需要花費的時間和精力。
• 構建可持續的自動化測試：構建檢查的擴充套件部分，構建後執行預先制定的一套測試規則，完成後觸發通知(Email,RSS等等)給相關的當事人。
• 生成後後續過程的自動化:當自動化檢查和測試成功完成，軟體構建的週期中可能也需要一些額外的任務，諸如生成文件、打包軟體、部署構件到一個執行環境或者軟體倉庫。這樣，構件才能更迅速地提供給使用者使用。

Jenkins是一個可擴充套件的持續整合引擎。主要用於：持續、自動地構建/測試軟體專案以及監控一些定時執行的任務。其擁有的特性包括：

1 . 易於安裝-只要把jenkins.war部署到servlet容器，不需要資料庫支援。

2 . 易於配置-所有配置都是通過其提供的web介面實現。

3 . 整合RSS/E-mail通過RSS釋出構建結果或當構建完成時通過e-mail通知。

4 . 生成JUnit/TestNG測試報告。

5 . 分散式構建支援Jenkins能夠讓多臺計算機一起構建/測試。

6 . 檔案識別:Jenkins能夠跟蹤哪次構建生成哪些jar，哪次構建使用哪個版本的jar等。

7 . 外掛支援:支援擴充套件外掛，你可以開發適合自己團隊使用的工具。

CI系統基本結構圖

該系統的各個組成部分是按如下順序來發揮作用的：

1 . 開發者檢入程式碼到原始碼倉庫。

2 . CI系統會為每一個專案建立了一個單獨的工作區。當預設或請求一次新的構建時，它將把原始碼倉庫的原始碼存放到對應的工作區。

3 . CI系統會在對應的工作區內執行構建過程。

4 . （配置如果存在）構建完成後，CI系統會在一個新的構件中執行定義的一套測試。完成後觸發通知(Email,RSS等等)給相關的當事人。

5 . （配置如果存在）如果構建成功，這個構件會被打包並轉移到一個部署目標(如應用伺服器)或儲存為軟體倉庫中的一個新版本。軟體倉庫可以是CI系統的一部分，也可以是一個外部的倉庫，諸如一個檔案伺服器或者像Java.net、 SourceForge之類的網站。

6 . CI系統通常會根據請求發起相應的操作，諸如即時構建、生成報告，或者檢索一些構建好的構件。

二、Jenkins的安裝與部署

1 . 下載yum源：

sudo wget -O/etc/yum.repos.d/jenkins.repo \https://pkg.jenkins.io/redhat-stable/jenkins.repo

2 . 匯入金鑰：sudo rpm –importhttps://pkg.jenkins.io/redhat-stable/jenkins.io.key

3 . 安裝Jenkins：yum install jenkins

4 . 啟動前檢查是否安裝jdk：java -version（最好是1.8以上的）

5 .修改配置檔案：sudo vim /etc/init.d/jenkins

在candidates=”路徑後新增java路徑/usr/java/jdk1.8.0_144/bin/java.（根據個人Java安裝地址）

vi /etc/sysconfig/jenkins

找到JENKINS_PORT=“8080”（8080是Jenkins預設埠，若被佔用課修改為其他空閒埠）

6 . 關閉防火牆

7 . 啟動應用：sudo service jenkins start

三、Jenkins構建maven專案

1、外掛安裝

• 啟動Jenkins服務以後便可登入瀏覽器訪問，因為我們需要從git上拉取原始碼，所以要在Jenkins上安裝相應的git外掛，同時我們也需要安裝maven類的外掛來支援構建maven專案。

• –》點選系統管理

• –》點選管理外掛

• 在可選外掛中找到Git plugin和Maven Integration plugin相關外掛並安裝外掛安裝完畢後重啟Jenkins

2、新建maven專案

• 新建一個job

• 輸入名稱和專案型別

• 原始碼管理

在原始碼管理項中選擇git並輸入git地址並在Credentials中Add倉庫登入賬號密碼，在下方分支選擇中選擇需要構建的專案分支。

• 構建觸發器

根據實際要求構建符合要求的觸發器，此圖中觸發器Poll SCM的功能是每個一定時間便檢查原始碼是否有更新，若有則自動構建。（*/60****含義是每隔60分鐘檢查一次git原始碼）

• 構建選項

第一行選項是預設的pom檔案在git的root目錄下，如果pom檔案在其他路徑下，則需要輸入相應的路徑/pom.xml；第二行執行的maven命令。

此時maven專案構建基本就完成，進入將maven專案生成docker映象的步驟。

四、Docker映象構建

1、docker配置

在Jenkins中安裝相應的docker外掛（docker-build-step）

在Host伺服器上安裝docker（1.12.6版本慎用）

配置docker的遠端訪問：

• centos下修改docker的配置檔案/usr/lib/systemd/system/docker.service
• 在[Service]的部分新增（此處是暴露的6732埠）

ExecStart=

ExecStart=/usr/bin/dockerd -Htcp://0.0.0.0:6732 -H unix://var/run/docker.sock

• docker重新讀取配置檔案並重啟docker服務

# systemct ldaemon-reload

# systemctl restartdocker

• 進入Jenkins，選擇系統管理–》系統設定–》Docker Builder

• 在Docker URL處填寫暴露的埠tcp://10.10.184.150:6732然後儲存

這樣Jenkins便可呼叫host伺服器中的docker功能

2、建立Docker映象

• 執行指令碼構建容器和映象：在上一步構建war包之後繼續選擇POSTSteps，執行我們放在Jenkins宿主機上/home/skyform/目錄下的構建指令碼

• 儲存後進入操作頁面並點選立即構建

• 此時左下角會出現構建進度條，藍色表示構建成功，紅色表示構建失敗，灰色表示構建未完成

• 構建結束後點擊構建編號，進入結果檢視介面，點選Console Output檢視構建過程

這樣就完成了利用Jenkins來夠構建一個maven專案並將其製作成Docker映象的工作。這個構建過程會根據你的觸發器設定來不斷實施，從而達到監控軟體開發流程，快速顯示問題與部署的目的。保證開發人員以及相關人員省時省力提高開發效率。

五、案例

目前SkyForm產品在進行微服務化改造，我們採用jenkins+docker支撐了SkyForm產品各個微服務的開發、部署、測試的整個過程

SkyForm產品中介軟體docker化：

SkyForm產品微服務docker化（19個）：

SkyForm 5.0微服務通過Jenkins實現持續整合及構建架構:

研發人員將自己的程式碼提交至git倉庫，Jenkins響應設定的觸發器，將提交後的程式碼拉取、編譯、打包至Jenkins宿主機上，然後執行指令碼，通過Docker命令在開發環境（或測試環境）生成響應映象並啟動容器，研發人員此時即可在開發環境（或測試環境）下進行聯調。

Q&A板塊

Q：專案不同的git分支是怎麼打包映象了？比如測試分支和開發，生產分支。    

A：在原始碼管理那塊可以設定不同的分支，需要建立管理不同分支的Jenkins專案。

Q：通過compose啟動的服務在3以後依賴不起作用了，那如何做前置依賴健康的檢測呢，再就是啟動的服務如果服務失敗後會自動重啟，這樣會造成很多失敗的例項，如何清楚這些大量的失敗例項，還有通過swarm做的叢集在做服務釋出的時候會沒有tag這是是哪裡的問題（私有倉庫）？

A：健康檢測目前是通過人工手動檢查dubbo服務註冊的情況，以後可以將這一功能寫到腳本里，例如探測前一服務一個功能是否能正常提供作為服務健康狀況的評定標準，服務失敗自動重啟的只是那個失敗的容器不會導致有大量的失敗容器。

Q：持續整合和持續釋出這塊如何銜接？

A：持續整合與持續釋出這一塊主要是通過自動化部署指令碼去完成，通過將測試通過的映象儲存下來與自動化部署指令碼一起打包做成安裝包，某一服務的升級也只需將容器映象替換重新啟動一個例項即可。

Q：gitlab+jenkins 和gitlab+gitlab runner怎麼選擇？

A：我們主要是基於將程式碼管理與持續整合分割開的理念，加上之前也有jenkins專案經驗來選擇的，基於求穩的心態沒有嘗試gitlab runner而且gitlab runner是每次只要有人push程式碼就會觸發指令碼而這不是我們所期望的，我們是期望定期檢查是否執行迭代或者定期的執行迭代，runner的許可權管理也不如jenkins的更符合我們的訴求。

Q：生產和測試網路是隔離的嗎？Jenkins是部署在哪個網路區域主機上？Jenkins自身是run在容器裡嗎？有沒有遇到Jenkins壓力？

A：是網路隔離的，jenkins是執行在單獨的虛擬機器中，jenkins壓力主要是長久的構建導致磁碟壓力的問題。

Q：指令碼中生成的war包是固定的？如果專案生成不同的war包，每次都需要改指令碼嗎？

A：每個服務都會對應一個部署指令碼，腳本里的資訊要根據部署的服務來更改。

Q：多次釋出專案生成映象，映象版本怎麼控制？歷史映象版本如何管理？

A：版本控制是由git去做，我們在映象這一部分不去做重複的功能。