754
基於容器服務的持續集成與雲端交付（二）- 多維度打磨交付能力
前言
在上一篇中，和大家一起討論了傳統軟件交付的問題、持續交付的難點、以及為什麼雲端的容器交付可以協助大家快速的持續交付。
但是當真正的將一個係統通過雲端容器交付的時候會發現不能單純的將Docker作為一種交付工具來對待，更多的時候是作為一個交付平台的基礎設施來看待，還需要關心的是使用Docker後網絡、存儲、安全、性能、監控等等不同方麵帶來的變革。
因為交付的本質是將一套複雜的軟件係統從零到一完成開發、測試、部署、上線的過程，軟件的複雜度直接關係到了交付的難度，特別是現在微服務的架構方式越來越成為主流，給交付也帶了更多的挑戰。
我們不僅要考慮一個係統交付的環境，而且還要考慮針對特定的軟件架構，交付係統的網絡、存儲和安全等等是否能夠滿足需求。本文中將會針對上麵提到的內容，分享我們是怎樣從以上幾個方麵打磨交付能力。
關於容器服務
基於容器的交付方案有非常多的開源選型，K8S、Mesos等等都是目前非常流行的方案，K8S脫胎於Google的Borg係統，在Google內部已經運行多年，成熟度與穩定性上是其他係統無法比擬的；Mesos則在資源分配上有先天的優勢。
阿裏雲容器服務是基於阿裏雲ECS服務構建的CaaS層產品，提供兼容Docker的API、Docker Compose的模板，通過集成阿裏雲已有的IaaS層、SaaS層的的雲原生服務，提供完整的Docker的雲原生的解決方案。對Docker的兼容性以及雲原生的服務能力是容器服務與開源方案最大的區別，當開發者已經開始使用雲服務作為軟件架構的基礎設施的時候，Docker帶來不應該是破舊立新的變化，而應該是更便捷的使用雲服務來實現交付。
係統架構
上麵是容器服務的基本原理圖，用戶可以通過容器服務創建屬於自己的容器服務集群，每個節點上會默認安裝容器服務的Agent，容器服務通過提供高可用的管控服務，用戶可以通過控製台或者API下發指令到容器集群。對外暴漏的API分為服務API與集群API，服務API是完全兼容Docker的API，開發者可以直接通過Docker命令操作遠程的容器集群；集群API是標準的阿裏雲OPEN API，開發者可以通過SDK進行集群的創建、刪除、擴縮容等操作。此外容器服務還同SLB(負載均衡服務)、SLS（日誌服務）、CMS(雲監控服務)、OSS(對象存儲服務)、NAS（NAS共享存儲）等雲原生服務打通，開發者可以在阿裏雲容器服務中便捷的使用雲原生的服務能力。
下麵我們主要在網絡、存儲、監控、日誌等方麵來簡介下阿裏雲容器服務的交付能力。
網絡
網絡在容器的方案中是一個繞不開的老話題，使用容器可以讓每台機器上運行更多的應用提高機器的資源利用率，可以讓應用更簡單的在機器之間遷移等等。
但是對外提供的服務都需要暴漏特定的端口或者服務端點，傳統應用與宿主機共享網絡的方式就很難滿足需求。
Docker默認提供了None、Bridge、Host、Overlay四種網絡模型，其中Host網絡模型就是宿主機與應用共享網絡的架構，但是對於很多開發者而言，Overlay的網絡模型是更常用的網絡方案。Overlay網路是在集群上構建了一個全局的二層的網絡，容器啟動在這個全局的網絡上，每個容器有自己在集群中獨立的IP地址，集群節點上的容器可以直接通過容器的這個獨立IP進行通信，而不需要通過NAT暴漏到主機端口，解耦了與宿主機IP的依賴，因此避免了做NAT的時候多個容器端口衝突的問題。但是Overlay網絡是Vxlan的一種實現，在發送信息或者接收消息的時候會進行封包與解包，這樣會在性能上造成20%左右的網絡損耗。
因此阿裏雲容器服務在VPC網絡中針對Overlay網絡做了性能的優化。在VPC網絡模式下容器互通是結合了阿裏雲VPC服務的自定義路由的功能，通過Docker Network Plugin的配置容器的IP在固定的網段，下圖是VPC+Docker的網絡結構：
網絡請求無需再封包解包，可以直接通過虛擬交換機與虛擬路由器直接進行轉發，降低了網絡的性能損耗。
存儲
Docker的特性，決定了容器本身是非持久化的；容器被刪除後，其中的數據也一並被刪除了。而且使用容器進行部署的應用通常以無狀態的應用為主，大多是水平擴展的，因此一旦涉及到落盤的存儲就需要在不同的容器之間進行共享。
針對落盤的存儲，Docker提供數據卷（Volume），通過掛載宿主機上的目錄來實現持久存儲。但在集群環境中，宿主機上的數據卷有很大的局限性。容器在機器間遷移時，數據無法遷移，不同機器之間不能共享數據卷。容器服務通過Docker Volume Plugin的方式集成了阿裏雲磁盤，OSS，NAS的容器存儲，在容器重啟和遷移的時候也可以自動的掛載，保證了容器持久化存儲的共享和安全。容器服務通過將OSS、NAS的遠程存儲端點映射成為一個主機的磁盤掛載點，開發者可以像使用本地磁盤的方式直接使用不同類型的共享存儲。
對於非落盤的存儲，例如緩存、數據庫等，可以直接使用雲原生的服務例如RDS(關係型數據庫)、KVStore(緩存服務)等等來實現，不建議使用容器化的存儲服務，雲原生的數據存儲服務可靠性更高，性能更好，而且在運維、安全等場景中有先天的優勢。
監控
監控在容器的場景中是一個非常重要的功能，因為容器的場景下需要做宿主機與容器兩個維度的監控，而容器的彈性擴縮容也依托於監控的功能。
為了應對特定的場景實現，我們的監控依托於阿裏雲雲監控服務，提供默認的監控、告警規則配置等服務。與此同時容器服務還提供了非常簡單快速地與第三方開源監控方案（例如InfluxDB、Grafana）集成的能力，用戶可以方便的和自己的監控或報警係統對接。並且，多維度全方位地提供各個層次的聚合監控指標，以期在不同的維度做監控、告警提示、分析以及實現自動化運維。開發者可以在雲監控中查看主機級別、應用級別、服務級別、容器級別等多個維度的監控，依托著四個維度的監控指標，可以進行主機級別的彈性伸縮與容器級別的彈性伸縮。
日誌
日誌是應用排查問題的最後一個手段，當應用容器化之後日誌的收集麵臨了更大的挑戰。需要能夠收集、聚合多個容器的日誌並且容器遷移或者重新部署後日誌仍然可以進行收集，因此傳統的落盤采集式的日誌收集方式就無法滿足需求了。
容器服務提供了集成阿裏雲日誌服務的能力，日誌服務是針對日誌場景的平台化服務。無需開發就可以快速完成日誌收集、分發、投遞與查詢， 適用於日誌中轉、監控、性能診斷、日誌分析、審計等場景。在容器服務中集成的日誌服務，可以方便的把容器日誌發送到日誌服務裏，隻需要在Docker Compose編排模板中添加aliyun.log_store_name: 的標簽就能實現容器日誌的自動采集與上報。日誌的配置與應用是關聯的，日誌的采集與應用的容器是動態鏈接的，容器的變更會觸發日誌插件重新鏈接與容器的關聯關係，當日誌流從容器產生時就會動態地被采集到日誌服務，通過日誌服務進行聚合，如果有更細粒度的分析需求，可以將日誌投遞到MaxCompute（大規模計算）進行數據分析。
尾聲
在上麵我們瀏覽了下阿裏雲容器服務提供的能力，雲端交付的首要條件是能夠交付，然後才是如何交付。阿裏雲容器服務在網絡、存儲、監控方麵對基於容器場景的架構進行了增強。讓複雜的係統在雲端容器交付中成為了可能。此外容器給開發者帶來的最大價值是可能性，容器服務也在機器學習、高性能計算等領域進行了探索，希望越來越多的領域可以在容器的幫助下更好地實現自身的價值。在下一篇文章中，我們將會討論如何從零搭建一個持續交付係統並交付軟件。
個人簡介
莫源，阿裏雲高級研發工程師。在加入阿裏巴巴之前，先後在北京天方地圓科技有限公司、微軟亞洲研究院任職。現主要負責阿裏雲容器服務產品的底層服務發現係統、集群管理係統的研發，從事容器的持續交付、持續集成的方案的設計與實現。在雲計算、分布式係統、圖像識別與虛擬現實方向有多年的開發經驗。
最後更新：2017-07-04 15:02:14