講師介紹
張春源
希雲技術總監
概述
提到軟體釋出确實是很令人頭疼的一個過程，且還是高風險動作。借用一句話：“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