利用容器技術構建持續交付/持續發佈系統

原文連接：https://github.com/billycyzhang/containerization/blob/master/activity-sharing/ci-cd/ci-cd.md

各位好，我是希雲cSphere技術總監張春源；今天和你們分享一下爲什麼會選擇容器技術來構建持續交付/持續發佈系統。

利用容器技術構建持續交付/持續發佈系統

概述

提到軟件發佈確實是很使人頭疼的一個過程，且仍是高風險動做。借用一句話：「99%的故障是因爲變動引發的」。本次分享內容着重介紹使用容器技術實現自動化構建、部署和測試過程，並使得開發、測試、運維之間能更好的協做，最終能夠在幾個小時甚至幾分鐘的時間，實現可重複，且可靠的軟件發佈系統。

常見場景

• 在開發測試環境中測試均沒有問題，但上生產環境的時候會有問題。即便咱們在開發測試環境中部署上萬遍沒問題，但歷來沒有在生產環境中部署過一次，每到在新版本發佈時，你們不只要加班，並且都還很緊張。若是沒有很好的回滾策略，即便發佈成功了心仍是懸着。

• 移動互聯網飛速發展，業務要求敏捷，要在很短的時間完成從開發到上線的任務。不少企業從開發到上生產的週期都要花好幾個月的時間完成，現有IT架構跟不上業務發展。

• 軟件項目開發完成後，要將開發好的版本交付到客戶的環境中。目前常見的作法是按照長長的安裝文檔，且是經過手動安裝完成，此種模式不只對安裝實施人員的要求高，且出錯概率很高。

構建持續交付/持續發佈系統須要考慮

• 環境管理

環境包括硬件和軟件，對於軟件環境必定要能對硬件解耦，這樣即便在硬件壞的狀況下能夠在很短的時間內將軟件環境部署到新的硬件上。除此以外，好的環境管理方式能有效下降在生產環境中部署的風險。

實踐推薦：環境的管理在項目開始的時候，開發團隊和運維團隊就應該全面合做，後面的事情就會變的很容易。

• 組件和依賴管理

不少系統都是由多個組件組合起來對外提供服務。組件內部要依賴庫文件，組件之間也有複雜的依賴關係。一套複雜的系統部署起來依賴的處理是很是重要的。組件以及依賴關係的更新，要能以增量的形式進行，並造成不一樣的版本。

• 配置管理

配置管理記錄了項目演進的過程。好的配置管理系統在很是短的時間內能建立出任何的環境；批量更新線上系統的配置信息且能保證更新失敗回退到能正常運行的版本；不只能知足本部門的需求一樣也能知足其餘部門的需求，以及不一樣環境之間的需求。

• 版本管理

在持續交付和持續發佈的過程當中，任何一個細節都應被記錄（操做系統，中間件，代碼，配置文件，依賴信息等），而且造成版本。

小提示：程序中不要把在不一樣環境部署時變化的參數寫死，推薦使用名稱。如：鏈接外部數據庫地址、用戶、密碼等信息。

• 持續交付管理

在交付的過程當中，任何緣由都有可能致使部署失敗。失敗不可怕，可怕的是不知道怎麼失敗的。明槍易躲暗箭難防道理讓咱們明白，軟件項目的交付要複雜的多，因此建設持續交付系統必定要創建可重複且可靠的部署流水線，較完善的配置管理系統，以及操做審計系統。問題越早發現修復起來的成本越低，且更好地保證成功的發佈上線。

爲什麼選擇使用容器

以Docker爲表明的容器技術，在短短的時間內發展迅速。容器技術早在2008年已經出現，Docker公司厲害的是提供了將軟件運行環境總體打包的技術-鏡像。

現實中不少不標準化的交付，使用鏡像均可以實現標準化。標準化之後能夠更好的實現自動化，而且能更好的促進上游和下游的發展。如：開發、測試、運維之間能更好的協助，踐行DevOps文化。

持續交付

原則：可重複、可靠；自動化；版本控制；團隊責任；

• 可重複、可靠

鏡像將軟件的運行環境以及軟件代碼打包起來，咱們能夠基於同一個鏡像在不一樣的環境中生成如出一轍的環境。由於容器就是進程，因此一個容器中推薦只運行一個服務。對於企業而言單容器是幹不成事的，須要利用編排系統將多個鏡像編排起來（鏡像/版本、應用配置文件、啓動優先級設置、日誌處理、數據處理等）造成應用模板。經過應用模板能夠重複，且可靠的將應用部署到不一樣的環境中，實現持續交付第一步。

• 自動化

容器技術在持續集成方面不只僅解決了CI的問題，而且很好的解決了CD。利用容器實現持續交付區別於傳統的作法是，原來開發交付出來的都是軟件包和安裝部署文檔；利用容器技術開發人員交付的是應用模板+鏡像，應用模板替代了安裝部署文檔，鏡像技術更可靠的完成了軟件包和軟件運行環境的交付。並利用CI工具實現了，開發人員提交代碼到代碼庫中，經過鉤子可自動觸發構建鏡像。並能夠對鏡像以及應用作測試。

• 版本控制

容器要比虛擬機更接近應用層，從叫法上來講虛擬機通常都叫虛擬機，但容器你們都會說是MySQL容器，Tomcat容器。容器更加細化到了應用層。上面咱們也都說到了，環境的變動，應用的版本或者是底層操做系統以及庫的變動都能作到增量式的版本管理。鏡像能夠經過Tag來實現版本的管理，應用模板、配置文件、依賴關係等信息一樣在企業實際應用中應嚴格要求經過版原本進行管理。

• 團隊責任

DevOps不是一種工具，是一種文化。整個持續交付流程能順利的創建起來，僅依靠一我的或一個部門基本上創建不起來。在咱們給中英人壽保險有限公司利用容器創建持續交付系統的過程深入的感覺到，須要讓實際業務團隊共同的參與，才真正能最大化容器的優點。容器技術是比較先進，但業務不關心先進性，重點看實際效果。因此DevOps不是我的運維或者開發人員的責任，必須是團隊的責任。

利用容器實現的交付流水線：

持續發佈

一切皆模板，服務於應用!

基於容器實現持續發佈系統以下：

*註解：

1.開發人員將代碼提交至代碼倉庫

2.經過鉤子自動觸發構建鏡像流程

3.鏡像構建完成後，push到鏡像倉庫Registry

4.有新版本進行生成，自動觸發部署流程，部署至測試環境

5.測試工做完成後，標記鏡像狀態爲成功，自動觸發部署至準生產環境

6.準生產環境測試完成後，可自動或半自動部署業務