在講正文開始前先回顧一下以往傳統的代碼部署方式。

通常運維人員在接到代碼（新項目）上線的任務前都要做大量的準備工作，包括：物理主機、虛擬機、代碼運行環境、數據庫安裝配置、各種帳號創建，、運行後期的系統監控、應用的日誌收集，性能優化等一系列的工作。

想一想這個流程不是很復雜，但是很繁瑣，效率低下，如需要調試還需要給開發人員提供線上系統權限等等，細節沒有註意的話，還會造成解決問題的難度等各種問題。

OK，說完以上的問題，那接下來就有相對應的解決方案。

在經過兩個月的不間斷的測試下，一套我自認為比較好的方案就這樣誕生了。

方案大概的架構組成：

jenkins+saltstack+svn+gitlab+harbor+rancher

各個組件的功能描述：

1. jenkins

（1）負責監控SVN代碼、gitlab中配置文件的變動

（2）負載執行鏡像的構建、上傳下載

（3）通過Rancher插件系統構建stack/service

（4）發送構建結果通知

2. svn：

（1）開發提交代碼倉庫（部門項目一直習慣使用svn管理代碼）

3. gitlab：

（1）保存項目配置文件

（2）nginx定制配置文件

（3）Dockerfile文件

說明：

為什麽這裏會有svn和gitlab兩個代碼工具呢？我來解釋一下，主要是

（1）部門的開發一直以來都在使用svn，還不是特別習慣git方式。

（2）要求代碼的線上配置連接數據庫帳號開發不能直接修改，且也不知道。不向開發泄漏線上帳號，分開管理，這裏我就采用

4. harbor：

這個是vmware公司開源的docker鏡像倉庫管理系統，比較方便管理維護鏡像

（1）負責構建後鏡像的存儲

5. rancher：

容器編排管理工具

（1）通過API負責接受jenkins的調用，自動創建、更新stack/service

（2）實現服務的擴容縮容

6. saltstack：

（1）這個組建可有可無，為什麽呢？

主要原因是:在rancher中每個服務的後端有時至少是兩個以上的容器支持對外訪問，分布在多個服務器上運行，同樣的容一個鏡像要分別pull到宿主機中，這個時間是成倍的（對於容器分布在不同宿主機上來說），saltstack實現了鏡像的並發下載，也就是說只是耗費了同樣的時間，每個宿主機都同時

一、架構圖

二、架構圖說明

項目開發語言是php，使用了比較流行的laravel框架，項目中用到的laravel插件使用composer安裝，npm安裝全局模塊，編譯生成js樣式文件

① 開發人員提交代碼到svn，運維人員更改nginx配置、項目env配置並提交到gitlab

②svn、gitlab鉤子會觸發jenkins執行下載對應項目的env、nginx配置文件、Dockerfile和最新版本的代碼

③jenkins執行shell腳本：composer安裝laravel插件和npm安裝模塊，編譯生成js文件。完好的代碼通過docker build Dockerfile 指令打包成鏡像

④上傳構建好的鏡像push到harbor鏡像倉庫

⑤jenkins借助Rancher的插件通過API與rancher交互更新service達到更升級容器的目的（也就是更新代碼版本），其中pull鏡像的這一步會通過saltstack並行從harbor上下拉之前構建好的鏡像到多個主機上

以上流程完整的實現了CI\CD，這裏主要是jenkins部分是關鍵位置之一。

下面通過關鍵配置的截圖來展示一個清晰的思路

三、jenkins詳細配置

（1）新建一個使用自由風格的項目，名稱根據項目命名。同時勾選要在那個slave節點上進行項目構建，見圖1紅框部分

圖1：

源碼管理部分，這裏就是架構圖中的gitlab保存的項目配置文件，gitlab可以在Rancher的Catalog中進行安裝，在gitlab中創建一個項目，創新用戶有相對應的權限。Jienkins添加gitlab賬戶。配置見圖2

圖2

這一步是關鍵性的，也就是架構圖中流程序號③做的工作，代碼、鏡像、上傳下載都是在那一臺slave節點完成的，這個slave節點同時配置成saltstack master服務，Rancher的計算節點配置成minion節點，這主要是為了並行下載鏡像

圖3

Rancher 插件的配置部分，其中API Endpoint、Rancher API Key、 和Rancher Enviroment Id

需要在Rancher的管理界面上創建API>秘鑰>添加賬號APIKey增加到jenkins中，使用API為https://xx.xx.xx.xx:8080/v2-beta 見圖4 、5 、6

圖4

圖5

圖6

下圖是項目發布的Timeline，每次發布時長都在3分鐘左右，還要看網絡狀況、鏡像大小和構建容器鏡像主機的性能。

圖7

總結

1. 目前這套流程，在測試環境跑了三個小項目，線上環境跑了一個小項目。

2. 項目代碼（svn）和項目配置文件相關（gitlab）應該整合到一起，很好解決。

3. 所有的問題都是在測試環境中不斷發現問題，解決問題，然後在線上進行完善，以防止出現不可控制的風險發生，畢竟這個技術儲備對於目前的團隊來說還有很大不足。

目前面臨的問題有：

1.沒有測試環節，無法驗證容器鏡像構建完成更新容器後，是否能夠正常提供服務，這樣發到生產環境是危險的。

如果說解決方案，那就是在鏡像構建完畢後，啟動一個單元測試，來驗證結果或者再發布一個預上線環境用自動化的全方位的測試，測試通過出發更新生產環境的發布即更新service，否則通知發布者測試未通過。

2. 整套流程，沒有實現如何回滾到上一版本的方法，其實這個也容易，就是在③步的svn代碼checkout那步加上帶版本號的命令行即可。

本文完

基於Jenkins+Gitlab+Harbor+Rancher架構的CICD實現