前言

在上一篇中，和大家一起討論了傳統軟體交付的問題、持續交付的難點、以及為什麼雲端的容器交付可以協助大家快速的持續交付。

但是當真正的將一個系統通過雲端容器交付的時候會發現不能單純的將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（大規模計算）進行資料分析。

尾聲

原文連結