基於 Rancher 的企業 CI/CD 環境搭建

CI(Continuous Integration)持續集成，CD(Continuous Delivery) 持續交付（固然也有叫 Continuous Deployment）一般會採用一些軟件如Jenkins、Drone、Travis、Gocd等來輔助咱們。它們可以與Git SVN等代碼管理倉庫集成，幫助咱們實現一些自動化任務。

CI/CD軟件不少，再加上代碼倉庫不一樣，外加上業務流程的複雜度和不一樣開發語言的特性，會產生變幻無窮的組合。能夠說CI/CD自己就是一個很大的話題，正所謂一千我的眼中就有一千個哈姆雷特，因此咱們此次分享主要仍是關注在與Rancher結合方面。

下面咱們就以jenkins爲例，看Rancher如何與其集成。

首先咱們能夠想到，對於一個CI/CD環境，Rancher能夠提供什麼?

• 快速部署jenkins

• 環境隔離/用戶管理

• 基於Rancher compose進行應用編排

• 提供外部訪問入口

Rancher的Catalog中提供了jenkins部署的樣板：

左側是jenkins-ci server，右側是swam-plugin，這兩個能夠組成一個master/slave模式的集羣。

嘗試性的部署後，能夠看到相似這樣的效果：

選用jenkins-swarm-plugin組成slave節點, 這樣咱們能夠在jenkins跑任務時可以和docker進行更好的集成 。

構建完畢後，能夠在jenkins中看到集羣情況：

那麼使用jenkins來作CI是一種怎樣的表現模式呢? 咱們來經過一張圖來看下：

開發人員 push commit後，代碼倉庫收到提交信息。這時能夠經過倉庫自帶的hook來觸發jenkins build。也能夠經過jenkins的自poll來獲取最新代碼。而後jenkins就自動執行你所設定的各類任務腳本。

插播一句，關於觸發jenkins build 的幾種方式：

• Post commit hook (git原生hook)

• Webhook (github/gitlab都支持，須要hook的server端接收請求

• Jenkins有相應的plugin)

• Build periodically / Poll SCM

CI的過程根據業務的複雜程度，各有不一樣，通常狀況下分爲這幾步：

運行測試用例—編譯lib—製做docker鏡像並push到倉庫—ranchercompose 部署服務。

一般咱們能夠把 rancher-compose 的file直接寫在代碼project中，這樣jenkins能夠直接讀取到，並執行rancher-compose執行部署服務。

在執行rancher-compose時，能夠考慮下面兩種策略：

• 每次根據jenkins的<buid_num>來建立新的stack

• Rancher-compose --force-upgrade --pull 拉取最新鏡像並強制升級

在rancher-compose 執行完畢後，一般交付一個對外訪問的ip:port，可是這個訪問地址通常來講不是固定的，因此咱們的業務服務部署完畢後，自動綁定dns，是一個很是好的體驗。

sync-service 能夠將app-service的服務地址在dns中添加A記錄，這樣咱們只需記住dns，就能夠直接看到CD後的業務服務。這裏的dns-server 最好是能夠支持SRV Record，關於SRV Record，你們能夠理解爲相似AWS Route53的功能。

關於如何取出服務地址並自動添加DNS記錄的原理，能夠參考我以前的一篇文章：http://blog.neunn.com/wordpre... 文中第三部分有詳細描述。

Q & A

Q：你剛纔提到「在執行rancher-compose時，能夠考慮下面兩種策略:每次根據jenkins的<buid_num>來建立新的stack」。這種方式能夠用DNS麼?若是用的話，轉發到哪一個stack上？

A：默認狀況下 <stack.name>.<env.name>.<root_domain>，你也能夠特殊制定一個dns前綴<special_name>.<root_domain>

Q：jenkins裏只能有一個ENV-*？

A：能夠在env下部署多個jenkins，可是考慮企業內部不一樣部門不一樣業務要進行隔離，因此建議每一個env一套jenkins。