48
如何利用容器構建持續交付/持續發布係統？
講師介紹
張春源
希雲技術總監
概述
提到軟件發布確實是很令人頭疼的一個過程，且還是高風險動作。借用一句話：“99%的故障是由於變更引起的”。本次分享內容著重介紹使用容器技術實現自動化構建、部署和測試過程，並使得開發、測試、運維之間能更好的協作，最終可以在幾個小時甚至幾分鍾的時間，實現可重複，且可靠的軟件發布係統。
常見場景
-
在開發測試環境中測試均沒有問題，但上生產環境的時候會有問題。即使我們在開發測試環境中部署上萬遍沒問題，但從來沒有在生產環境中部署過一次，每到在新版本發布時，大家不僅要加班，而且都還很緊張。如果沒有很好的回滾策略，即使發布成功了心還是懸著。
-
移動互聯網飛速發展，業務要求敏捷，要在很短的時間完成從開發到上線的任務。很多企業從開發到上生產的周期都要花好幾個月的時間完成，現有IT架構跟不上業務發展。
-
軟件項目開發完成後，要將開發好的版本交付到客戶的環境中。目前常見的做法是按照長長的安裝文檔，且是通過手動安裝完成，此種模式不僅對安裝實施人員的要求高，且出錯幾率很高。
構建持續交付/持續發布係統需要考慮
1、環境管理
環境包括硬件和軟件，對於軟件環境一定要能對硬件解耦，這樣即使在硬件壞的情況下可以在很短的時間內將軟件環境部署到新的硬件上。除此之外，好的環境管理方式能有效降低在生產環境中部署的風險。
實踐推薦：環境的管理在項目開始的時候，開發團隊和運維團隊就應該全麵合作，後麵的事情就會變的很容易。
2、組件和依賴管理
很多係統都是由多個組件組合起來對外提供服務。組件內部要依賴庫文件，組件之間也有複雜的依賴關係。一套複雜的係統部署起來依賴的處理是非常重要的。組件以及依賴關係的更新，要能以增量的形式進行，並形成不同的版本。
3、配置管理
配置管理記錄了項目演進的過程。好的配置管理係統在非常短的時間內能創建出任何的環境；批量更新線上係統的配置信息且能保證更新失敗回退到能正常運行的版本；不僅能滿足本部門的需求同樣也能滿足其他部門的需求，以及不同環境之間的需求。
4、版本管理
在持續交付和持續發布的過程中，任何一個細節都應被記錄（操作係統，中間件，代碼，配置文件，依賴信息等），並且形成版本。
小提示：程序中不要把在不同環境部署時變化的參數寫死，推薦使用名稱。如：連接外部數據庫地址、用戶、密碼等信息。
5、持續交付管理
在交付的過程中，任何原因都有可能導致部署失敗。失敗不可怕，可怕的是不知道怎麼失敗的。明槍易躲暗箭難防道理讓我們明白，軟件項目的交付要複雜的多，所以建設持續交付係統一定要建立可重複且可靠的部署流水線，較完善的配置管理係統，以及操作審計係統。問題越早發現修複起來的成本越低，且更好地保證成功的發布上線。
為何選擇使用容器
以Docker為代表的容器技術，在短短的時間內發展迅速。容器技術早在2008年已經出現，Docker公司厲害的是提供了將軟件運行環境整體打包的技術-鏡像。
現實中很多不標準化的交付，使用鏡像都可以實現標準化。標準化以後可以更好的實現自動化，並且能更好的促進上遊和下遊的發展。如：開發、測試、運維之間能更好的協助，踐行DevOps文化。
持續交付
原則：可重複、可靠；自動化；版本控製；團隊責任。
1、可重複、可靠
鏡像將軟件的運行環境以及軟件代碼打包起來，我們可以基於同一個鏡像在不同的環境中生成一模一樣的環境。因為容器就是進程，所以一個容器中推薦隻運行一個服務。對於企業而言單容器是幹不成事的，需要利用編排係統將多個鏡像編排起來（鏡像/版本、應用配置文件、啟動優先級設置、日誌處理、數據處理等）形成應用模板。通過應用模板可以重複，且可靠的將應用部署到不同的環境中，實現持續交付第一步。
2、自動化
容器技術在持續集成方麵不僅僅解決了CI的問題，並且很好的解決了CD。利用容器實現持續交付區別於傳統的做法是，原來開發交付出來的都是軟件包和安裝部署文檔；利用容器技術開發人員交付的是應用模板+鏡像，應用模板替代了安裝部署文檔，鏡像技術更可靠的完成了軟件包和軟件運行環境的交付。並利用CI工具實現了，開發人員提交代碼到代碼庫中，通過鉤子可自動觸發構建鏡像。並可以對鏡像以及應用做測試。
3、版本控製
容器要比虛擬機更接近應用層，從叫法上來說虛擬機一般都叫虛擬機，但容器大家都會說是MySQL容器，Tomcat容器。容器更加細化到了應用層。上麵我們也都說到了，環境的變更，應用的版本或者是底層操作係統以及庫的變更都能做到增量式的版本管理。鏡像可以通過Tag來實現版本的管理，應用模板、配置文件、依賴關係等信息同樣在企業實際應用中應嚴格要求通過版本來進行管理。
4、團隊責任
DevOps不是一種工具，是一種文化。整個持續交付流程能順利的建立起來，僅依靠一個人或一個部門基本上建立不起來。在我們給中英人壽保險有限公司利用容器建立持續交付係統的過程深刻的感受到，需要讓實際業務團隊共同的參與，才真正能最大化容器的優勢。容器技術是比較先進，但業務不關心先進性，重點看實際效果。所以DevOps不是個人運維或者開發人員的責任，必須是團隊的責任。
利用容器實現的交付流水線：
持續發布
一切皆模板，服務於應用！
基於容器實現持續發布係統如下：
注解：
-
開發人員將代碼提交至代碼倉庫
-
通過鉤子自動觸發構建鏡像流程
-
鏡像構建完成後，push到鏡像倉庫Registry
-
有新版本進行生成，自動觸發部署流程，部署至測試環境
-
測試工作完成後，標記鏡像狀態為成功，自動觸發部署至準生產環境
-
準生產環境測試完成後，可自動或半自動部署業務
Ｑ＆Ａ
Q1：國內代碼提交，擔心代碼泄露，這個問題有考慮怎麼解決嗎？
A1：代碼存放到企業私有代碼庫中。
Q2：張老師好，鏡像比較大時，部署怎麼解決速度問題？
A2：鏡像大有幾種原因：1.base鏡像大；2.安裝的軟件沒清除；3.構建鏡像時下載軟件用wget，不用add，這幾步做好鏡像大小能控製住。另外鏡像要規劃好，利用好鏡像的分層技術。
Q3：構建鏡像時，wget和add的區別？為什麼用wget？
A3： 每條Dockerfile會生成一層，鏡像是隻讀的。如使用add來下載軟件包，然後在安裝，軟件包刪除不了，處於不同層！使用RUN可以用wget下載後，安裝，再刪除，是同一層執行的操作！
原文發布時間為：2016-11-30
本文來自雲棲社區合作夥伴DBAplus
最後更新：2017-05-11 14:01:34