Docker學習總結（14）——從程式碼到上線， 雲端Docker化持續交付實踐
2016雲棲大會·北京峰會於8月9號在國家會議中心拉開帷幕，在雲棲社群開發者技術專場中，來自阿里雲技術專家羅晶（瑤靖）為在場的聽眾帶來《從程式碼到上線，雲端Docker化持續交付實踐》精彩分享。
關於分享者：
羅晶，花名瑤靖。在加入阿里雲之前，先後在支付寶平臺數據技術事業群、百度基礎架構部任職。現主要負責阿里雲容器服務產品的叢集管理系統的研發，從事容器的持續交付、持續整合的方案設計與實現。
演講內容架構
-
大話持續交付
-
持續交付的前世
-
容器化DevOps
-
持續交付的今生
演講主要內容
持續整合指的是，頻繁地（一天多次）將程式碼整合到主幹。持續整合的目的，就是讓產品可以快速迭代，同時還能保持高質量。它的核心措施是，程式碼整合到主幹之前，必須通過自動化測試。只要有一個測試用例失敗，就不能整合。
持續交付（Continuous delivery）指的是，頻繁地將軟體的新版本，交付給質量團隊或者使用者，以供評審。如果評審通過，程式碼就進入生產階段。
持續交付可以看作持續整合的下一步。它強調的是，不管怎麼更新，軟體是隨時隨地可以交付的。
持續整合和持續交付保證了軟體的持續執行和有效反饋。
不同環境，不同交付運維方式。即便按照流程去做持續交付，系統地搭建出來整個持續整合的系統環境，一樣會遇到七七八八這樣的問題。就算是同一種語言，每一個開發者所依賴語言環境、依賴的包不一樣，就會導致有非常多的編譯環境，維護起來就很困難。
傳統持續交付問題的根源在於：
-
開發者交付的只有程式碼以及程式碼的依賴；
-
運維者需要除了程式碼之外的執行環境，以及執行環境之間的依賴。
交付方式的變革
Docker的出現改變軟體交付的方式。經濟學家說過：沒有集裝箱，不可能有全球化。Docker就像把一堆零散的程式碼和我要的所有東西裝在集裝箱裡，真正去交付給運維時，相當於把這個集裝箱執行起來。它包含所有的環境依賴，所以在任何地方執行集裝箱所達到的結果都是一樣的。因為達到了環境一致性。
Docker之所以這麼火，是由於它的敏捷、可移植、可控的特性決定的。敏捷意味著Docker可以秒級應用啟動、輕量級隔離、細粒度資源控制、低效能損耗；可移植代表著Docker的環境無關的交付、部署方式、可用於軟體生命週期中不同執行環境；可控表示容器級別的資源隔離和流控。
Docker Compose是Docker推出來的一個對多容器的編排技術，簡單好用，便於開發。使用Docker Compose，可以一鍵構建本地開發環境，在團隊中可以共享一份配置檔案。它的優點是：
-
簡單好用，便於開發
-
本地環境沙箱
-
UT環境
-
編排容器、儲存和網路
當然，它也存在不足：面向開發和部署，不支援自動化運維。
Docker Swarm把一組Docker引擎抽象成一個Docker引擎，以前所有在單機上對一個Docker引擎的工作，都可以透明的變成對一組Docker叢集上的節點的操作。Docker Swarm它的優點是：
-
支援標準的 Docker API；
-
靈活、可擴充套件、可插拔的容器排程。
當然，它也存在不足：面向容器、缺少服務生命週期支援。
容器服務上有三個層面的概念：
-
資源層面——叢集，節點。
-
內容層面——Compose模板，映象。
-
應用層面——應用，服務，容器。
容器化DevOps，可以實現：
-
開發環境到生產環境的一致
-
可程式設計基礎設施
-
Infrastructure as Code
-
不可變基礎架構
-
Immutable infrastructure
-
全流程工具化、自動化、持續交付
-
降低試錯成本，鼓勵快速迭代
簡單的容器化持續交付流程如下圖所示：
複雜的容器化持續交付流程：開發人員在除了程式碼 、Config、Test指令碼還要寫Dockerfile。把這些程式碼傳（Push）到程式碼倉庫，有一個CI service通過程式碼倉庫hook告訴你程式碼倉庫有一個新的提交。把程式碼拉下來複制，進行兩件事情 : Build和UT。在build的過程中，會從Docker Registry上面去拉下來( Pull )依賴的image，當build通過了之後會push image到這個Docker Registry單位裡面去。然後CI 會有一個hook去通知CD，deploy Service根據Docker和image描述以及compose描述，把image部署到預發、測試或者生產環境。
持續交付“最後一公里”
釋出時持續交付的“最後一公里”，常見的釋出策略有藍綠髮布、金絲雀釋出（灰度釋出）、ABTest，在國內的開發者中，對這幾個概念有獨立的理解。
Rolling Update
-
依次停止老容器，啟動新容器
-
整個過程自動化，無需使用者手動操作
-
適合於多副本的應用釋出
藍綠髮布（熱部署）
-
不會停止老容器，為新服務啟動新容器
-
需要使用者設定路由權重，實現不同版本應用的上線、下線
-
適合於版本的快速釋出，不會停機影響使用者
金絲雀釋出（灰度）
-
不會停止老容器，為新服務啟動新容器
-
需要使用者設定路由權重，實現不同版本應用的共存
-
支援A/B測試，適合多方案選擇