在講正文開始前先回顧一下以往傳統的代碼部署方式。
通常運維人員在接到代碼（新項目）上線的任務前都要做大量的準備工作，包括：物理主機、虛擬機、代碼運行環境、數據庫安裝配置、各種帳號創建，、運行後期的系統監控、應用的日誌收集，性能優化等一系列的工作。
想一想這個流程不是很複雜但是很繁瑣，效率低下，如需要調試還需要給開發人員提供線上系統權限等等，細節沒有注意的話，還會造成解決問題的難度等各種問題。
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）要求代碼的線上配置連接數據庫帳號開發不能直接修改，且也不知道。不向開發泄漏線上帳號，分開管理，這裏我就採用git後面有詳細介紹。
4. harbor：
這個是vmware公司開源的docker鏡像倉庫管理系統，比較方便管理維護鏡像
（1）負責構建後鏡像的存儲
5. rancher：
容器編排管理工具
（1）通過API負責接受jenkins的調用，自動創建、更新stack/service
（2）實現服務的擴容縮容
6. saltstack：
（1）這個組建可有可無，爲什麼呢？
主要原因是:在rancher中每個服務的後端有時至少是兩個以上的容器支持對外訪問，分佈在多個服務器上運行，同樣的容一個鏡像要分別pull到宿主機中，這個時間是成倍的（對於容器分佈在不同宿主機上來說），saltstack實現了鏡像的併發下載，也就是說只是耗費了同樣的時間，每個宿主機都同時pull完鏡像，節省了部署的時間。
一、架構圖
二、架構圖說明
項目開發語言是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
注意：
圖5的紅框部分高級配置Auto Confirm 勾選後更新服務後，狀態是正常的，不能回滾。
如果不勾選，在更新服務後，狀態在UI顯示的Upgraded，再次發佈時會造成失敗。
好處就是：如果你沒有把握這次發佈是一定沒問題的，還可以在Rancher管理界面中回滾到之前的狀態。
圖4
圖5
圖6
下圖是項目發佈的Timeline，每次發佈時長都在3分鐘左右，還要看網絡狀況、鏡像大小和構建容器鏡像主機的性能。
圖7
總結
1. 目前這套流程，在測試環境跑了三個小項目，線上環境跑了一個小項目。
2. 項目代碼（svn）和項目配置文件相關（gitlab）應該整合到一起，很好解決。
3. 所有的問題都是在測試環境中不斷髮現問題，解決問題，然後在線上進行完善，以防止出現不可控制的風險發生，畢竟這個技術儲備對於目前的團隊來說還有很大不足。
目前面臨的問題有：
1.沒有測試環節，無法驗證容器鏡像構建完成更新容器後，是否能夠正常提供服務，這樣發到生產環境是危險的。
如果說解決方案，那就是在鏡像構建完畢後，啓動一個單元測試，來驗證結果或者再發佈一個預上線環境用自動化的全方位的測試，測試通過出發更新生產環境的發佈即更新service，否則通知發佈者測試未通過。
2. 整套流程，沒有實現如何回滾到上一版本的方法，其實這個也容易，就是在③步的svn代碼checkout那步加上帶版本號的命令行即可。
本文完