Docker學習總結(14)——從代碼到上線, 雲端Docker化持續交付實踐

2016雲棲大會·北京峯會於8月9號在國家會議中心拉開帷幕,在雲棲社區開發者技術專場中,來自阿里雲技術專家羅晶(瑤靖)爲在場的聽衆帶來《從代碼到上線,雲端Docker化持續交付實踐》精彩分享。

關於分享者:編程

羅晶,花名瑤靖。在加入阿里雲以前,前後在支付寶平臺數據技術事業羣、百度基礎架構部任職。現主要負責阿里雲容器服務產品的集羣管理系統的研發,從事容器的持續交付、持續集成的方案設計與實現。網絡

演講內容架構架構

  • 大話持續交付運維

  • 持續交付的前世ide

  • 容器化DevOps工具

  • 持續交付的此生性能

演講主要內容測試

持續集成指的是,頻繁地(一天屢次)將代碼集成到主幹。持續集成的目的,就是讓產品能夠快速迭代,同時還能保持高質量。它的核心措施是,代碼集成到主幹以前,必須經過自動化測試。只要有一個測試用例失敗,就不能集成。ui

從代碼到上線, 雲端Docker化持續交付實踐

持續交付(Continuous delivery)指的是,頻繁地將軟件的新版本,交付給質量團隊或者用戶,以供評審。若是評審經過,代碼就進入生產階段。阿里雲

持續交付能夠看做持續集成的下一步。它強調的是,無論怎麼更新,軟件是隨時隨地能夠交付的。

從代碼到上線, 雲端Docker化持續交付實踐

持續集成和持續交付保證了軟件的持續運行和有效反饋。

從代碼到上線, 雲端Docker化持續交付實踐

不一樣環境,不一樣交付運維方式。即使按照流程去作持續交付,系統地搭建出來整個持續集成的系統環境,同樣會遇到七七八八這樣的問題。就算是同一種語言,每個開發者所依賴語言環境、依賴的包不同,就會致使有很是多的編譯環境,維護起來就很困難。

從代碼到上線, 雲端Docker化持續交付實踐

傳統持續交付問題的根源在於:

  • 開發者交付的只有代碼以及代碼的依賴;

  • 運維者須要除了代碼以外的運行環境,以及運行環境之間的依賴。

從代碼到上線, 雲端Docker化持續交付實踐

交付方式的變革

Docker的出現改變軟件交付的方式。經濟學家說過:沒有集裝箱,不可能有全球化。Docker就像把一堆零散的代碼和我要的全部東西裝在集裝箱裏,真正去交付給運維時,至關於把這個集裝箱運行起來。它包含全部的環境依賴,因此在任何地方運行集裝箱所達到的結果都是同樣的。由於達到了環境一致性。

從代碼到上線, 雲端Docker化持續交付實踐

Docker之因此這麼火,是因爲它的敏捷、可移植、可控的特性決定的。敏捷意味着Docker能夠秒級應用啓動、輕量級隔離、細粒度資源控制、低性能損耗;可移植表明着Docker的環境無關的交付、部署方式、可用於軟件生命週期中不一樣運行環境;可控表示容器級別的資源隔離和流控。

從代碼到上線, 雲端Docker化持續交付實踐

Docker Compose是Docker推出來的一個對多容器的編排技術,簡單好用,便於開發。使用Docker Compose,能夠一鍵構建本地開發環境,在團隊中能夠共享一份配置文件。它的優勢是:

  • 簡單好用,便於開發

  • 本地環境沙箱

  • UT環境

  • 編排容器、存儲和網絡

固然,它也存在不足:面向開發和部署,不支持自動化運維。

從代碼到上線, 雲端Docker化持續交付實踐

Docker Swarm把一組Docker引擎抽象成一個Docker引擎,之前全部在單機上對一個Docker引擎的工做,均可以透明的變成對一組Docker集羣上的節點的操做。Docker Swarm它的優勢是:

  • 支持標準的 Docker API;

  • 靈活、可擴展、可插拔的容器調度。

固然,它也存在不足:面向容器、缺乏服務生命週期支持。

從代碼到上線, 雲端Docker化持續交付實踐

容器服務上有三個層面的概念:

  • 資源層面——集羣,節點。

  • 內容層面——Compose模板,鏡像。

  • 應用層面——應用,服務,容器。

從代碼到上線, 雲端Docker化持續交付實踐

容器化DevOps,能夠實現:

  • 開發環境到生產環境的一致

  • 可編程基礎設施

  • Infrastructure as Code

  • 不可變基礎架構

  • Immutable infrastructure

  • 全流程工具化、自動化、持續交付

  • 下降試錯成本,鼓勵快速迭代

從代碼到上線, 雲端Docker化持續交付實踐

簡單的容器化持續交付流程以下圖所示:

從代碼到上線, 雲端Docker化持續交付實踐

複雜的容器化持續交付流程:開發人員在除了代碼 、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部署到預發、測試或者生產環境。

從代碼到上線, 雲端Docker化持續交付實踐

持續交付「最後一千米」

發佈時持續交付的「最後一千米」,常見的發佈策略有藍綠髮布、金絲雀發佈(灰度發佈)、ABTest,在國內的開發者中,對這幾個概念有獨立的理解。

Rolling Update

  • 依次中止老容器,啓動新容器

  • 整個過程自動化,無需用戶手動操做

  • 適合於多副本的應用發佈

從代碼到上線, 雲端Docker化持續交付實踐

藍綠髮布(熱部署)

  • 不會中止老容器,爲新服務啓動新容器

  • 須要用戶設置路由權重,實現不一樣版本應用的上線、下線

  • 適合於版本的快速發佈,不會停機影響用戶

從代碼到上線, 雲端Docker化持續交付實踐

金絲雀發佈(灰度)

  • 不會中止老容器,爲新服務啓動新容器

  • 須要用戶設置路由權重,實現不一樣版本應用的共存

  • 支持A/B測試,適合多方案選擇

從代碼到上線, 雲端Docker化持續交付實踐

相關文章
相關標籤/搜索