03.06 [總結] 容器技術架構、網絡和生態詳解

Hardy 架構師技術聯盟

關於<容器技術架構、網絡和生態詳解>電子書詳情，感興趣的讀者請點擊文末“原文鏈接”獲取或下載。

談起容器技術，不得不提Docker技術。Docker 是 PaaS 提供商 DotCloud 開源的一個高級容器引擎，源代碼託管在 Github 上，基於Go語言並遵從Apache2.0協議開源。Docker相當於物理行業的集裝箱對物流的影響一樣，成為Container上運行鏡象的統一打包和交換的標準。

我們知道，Docker使用了容器的環境隔離和資源限制技術，把鏡像和運行環境打包到Image中。Register支持容器上傳和下載功能。Docker同時提供了Build，Ship和Run，運維只需要在環境重配置好Docker，剩下的工作就是部署容器，實現Build Once Run Anywhere和Configure Once Run Anything；從而促進了容器技術的爆發。

在架構上，Docker採用Client Server模式和插件式架構設計，Docker的後端採用非常松耦合的架構，模塊之間相互獨立，用戶通過Docker Client與Docker Daemon建立通信，併發送請求給Docker Daemon。Docker Daemon提供Server功能接受Docker Client的請求；隨後通過Engine執行Docker內部的一系列工作，每項工作都是以一個Job的形式的存在。

Docker講底層容器運行時剝離出來，實現更好的平臺無關性。LibContainer是對各種容器的抽象，發展為RunC，並貢獻給OCP組織作為定義容器環境的標準。Docker容器的三大編排工具，Compose、Swarm和Machine。Compose是服務編排工具，是定義和運行Docker主機上多容器應用的工具，通過單獨文件，定義多容器應用並運行容器。

Docker的網絡技術和能力一直是容器技術中最難、也是最不看好的技術之一，Libnetwork是Docker公司正在開發的新的網絡底層架構，由libcontainer和Docker Engine中的網絡相關的代碼合併而成。Libnetwork的目標是引入了容器網絡模型(CNM)，併為應用程序提供一致的編程API接口以及網絡抽象。 Libnetwork的容器網絡模型包含了三個重要概念，Network Sandbox，Endpoint和Network。

Weave創建了Networking Plugin技術，目前成熟的有Networking Plugin和Volume Plugin。

Weave方案包含兩大組件，用戶態Shell腳本和Weave虛擬路由容器。Weave虛擬路由容器需要在每個宿主機上佈置第三方插件，把不同宿主機的Route容器連接起來，使得Docker工具生態無縫集成到Docker。(其他網絡方案介紹，請參看<容器技術架構、網絡和生態詳解>電子書)

Weave創建一個虛擬網絡，鏈接多個主機的Docker容器，並使他們可以被自動發現，對使用該網絡的應用來說，所以容器就像是鏈接在同一個網絡交換機上，無需配置端口映射、鏈路等參數。

容器和容器OS

CoreOS是最為受歡迎的容器虛擬化OS，專為Docker設計和內核裁剪。 CoreOS中有兩個關鍵容器集群管理工具，etcd主要實現集群服務發現、信息共享和數據同步；而Fleet實現集群狀態維護、容器操作和確保服務一致可用。

VMware也推出了容器OS系統Photon，在VMware上創建VM，並且安裝Photon系統即可部署運行容器，並且支持目前主流的Docker、Rkt和PGC容器平臺。Photon可以容器管理認證工具Lightwave配合，可以實現更好的權限管理。

Docker容器和存儲

Docker容器在數據讀寫和存儲上，是採用分層和COW的存儲技術實現，Docker本身的COW文件系統不支持數據持久保存，在容器被刪除或重啟後，之前的文件更改就會丟失(變化的數據被以COW寫到一個新的位置)。

Volume的引入雖然解決了數據丟失問題，但是當容器遷移後，數據卷無法跟隨Docker容器一起遷移，ClusterHQ的Flocker的出現恰恰解決Volume的不足，使得數據跟隨Docker遷移。

Flocker的容器和存儲卷遷移分為全遷移和增量同步兩個過程，配置文件描述Docker部署方式和狀態，運行配置則生效(遷移Redis)；以遷移本地存儲(非共享存儲)為例，整個過程為先打快照，全遷移，增量同步。

Flocker以Docker Volume Plugin的方式部署在Docker中，與Docker集成。目前共享存儲的支持能力比較成熟，支持的產品包括AWS EBS、Scale IO和XtremIO等，並且支持如AWS、Rackspace等雲平臺；本地存儲方式在技術成熟度上並不高。

Flocker通過Storage Driver屏蔽存儲差異，並通過存儲提供的Flocker標準接口實現對底層存儲操作，當主機容器在不同主機間遷移時，Flocker只需要對容器的Volume進行主機的重映射。

Docker與PaaS

隨之容器的發展，CaaS容器即服務的概念也應時而生，其大意就是基礎設施以容器的方式來供給給應用使用。以容器為單位成為PaaS的共識，基於Docker的容器打包和分發有望成為PaaS平臺的標準, Docker將大幅拓寬PaaS的應用範圍，並促進PaaS的快速發展。

基於容器的打包一統新一代PaaS，第三代PaaS，DEIS、Flynn等均基於Docker，挑戰老的PaaS平臺。

PaaS已經出現了數年時間，第一批是Azure和Heroku等公用雲服務，之後出現的Cloud Foundry和OpensShift允許用戶建立自己的PaaS，包括了內部數據中心以及雲環境。現在，第三代PaaS浪潮正在到來。

Flynn是一個開源的PaaS平臺，可自動構建部署任何應用到Docker容器集群上運行，其功能特性與組件設計大量參考了傳統的PaaS平臺Heroku。Flynn目前還不是很穩定。但整個系統非常靈活，相互松耦合，便於任意組件的替換。

Docker與IaaS平臺

主流IaaS雲平臺都支持Docker的運行 (AWS、Google Compute Engine、Rackspace等)。Docker彌合了不同IaaS之間的差異，Docker的輕量和可移動性使得其比較適合用在Hybrid Cloud中。降低了IaaS服務商用戶粘性，使得跨雲服務商遷移更加自由。從而使得IaaS服務商被管道化。如果Container把安全問題解決了，可能就會有比較大的變化。

出現基於Docker的Container as a Service或Orchestration as a Service，如Tutum，可以避免IaaS的鎖定，甚至不用關心是運行在物理設施上，還是運行在哪家IaaS平臺上。

2014年6月Rackspace宣佈和CoreOS合作提供Baremetal as a Service方案OnMetal，結合了雲計算的靈活性和基於container的高性能虛擬化，提供single tenant baremetal cloud serivce。這種模式將影響當前以虛擬機為核心的IaaS平臺，預計後續可能出現同時提供Docker over Baremetal、 Docker over VM和VM三種混合的資源分配和調度雲平臺。

Docker也引發了基於容器的應用集群管理平臺，如Kubernetes得到了微軟、紅帽、IBM、Vmware、Docker、Mesosphere、CoreOS和SaltStack等多家廠商的支持。容器集群管理技術可能導致Openstack邊緣化。

Docker與Openstack

從目前來看，Docker集成到OpenStack的方案主要有下面三種方案。主流觀點認為基於Nova調度和管理Docker容器不能發揮Docker的優勢，而把Docker與Heat集成更能發揮其優勢。

Docker Driver for Nova通過nova-api，docker driver作為hypervisor部署。原理很好理解，nova-computer-api調用virt api 將nova docker driver作為http agent和docker rest api互通，從而控制docker和與容器的通信。另外，glance作為docker register服務的本地節點，提供image服務。這種方式不支持Docker的一些高級特性。

Docker Plugin for Heat通過Heat組件來實現。利用heat來管理docker的資源模板，這樣可以避免nova僅僅在hypervisor層面對docker管理的限制，比如一些docker本身構建的能力，或是docker容器之間的網絡管理等。這種方式能夠充分利用Docker的API，但缺乏quota、 host aggregate 調度機制，不能用Glance來管理鏡像。

Docker與DevOps

基於Docker可以更好的實現DevOps。雖然有許多工具適合DevOps部署，使開發人員和操作更貼近，但Docker是一個與DevOps原則密切相關的框架。使用Docker，開發人員可以專注於他們的代碼，而不必擔心在生產環境中運行它們的負面影響。

DevOps團隊可以將整個容器作為容器處理，文件系統和依賴關係管理的分層方法使得環境的配置更容易維護。在相同的源代碼控制系統（如Git工作流程）中版本化和維護Dockerfiles使得它非常有效地管理多個開發/測試環境。不同環境的多個容器可以在同一VM上運行時被隔離。Docker還可以很好地使用現有的工具，如Jenkins，Chef，Puppet，Ansible，Salt Stack，Nagios和Opsworks。

Docker有可能對DevOps生態系統產生重大影響。它可以從根本上改變開發人員和運營專業人員合作的方式。新興DevOps公司，如CloudMunch，Factor.io，Drone.io可能必須採用Docker並將其帶入他們的CI和CD解決方案。

Docker與微服務架構

基於Docker容器和其生態系統的微服務架構是下一代PaaS的核心，在Docker出現之前，雖然我們談論微服務架構，但是其實是很難實現的。微服務要運行，首先需要一套執行的環境。這套環境不能對外部有依賴性。同時，執行環境的粒度又必須足夠的小，這樣才能稱之為”微“，否則必然是對資源的巨大浪費。一個微服務可以跑在一臺虛擬機上面，但是虛擬機粒度太大，即使最小的虛擬機，也至少也有1個核。服務一個用戶的服務，顯然用不了一個核。同時，虛擬機有沒有一套方便的管理機制，能夠快速的讓這些服務之間能夠組合和重構。

Docker出現以後，我們看到了微服務的一個非常完美的運行環境。一個容器就是一個完整的執行環境，不依賴外部任何的東西，具備獨立性。一臺物理機器可以同時運行成百上千個容器，粒度細。其計算粒度足夠的小。容器可以在秒級進行創建和銷燬，非常適合服務的快速構建和重組。數量眾多的容器編排管理工具，能夠快速的實現 服務的組合和調度。

目前圍繞Docker已形成龐大的生態系統，涵蓋編排/調度、容器/OS、應用部署、網絡/SDN、Hosting/SP、Big Data、配置管理工具、開發工具等。

互聯網廠商/雲服務商加入Docker生態圈，在容器部署、管理、編排等領域發力，搶佔容器集群管理的標準控制權，積極部署Container和倉儲服務，打造基於各自雲服務的應用生態體系。

Docker將催生雲計算服務標準化，可以在系統的構建者和使用者之間劃出一條清晰的界限，將IT系統的交付標準化。譬如遊戲的開發商可以交付標準化的服務給遊戲的發行商，發行商在不依賴開發商的情況下能夠獨立運營系統，或者交由第三方運營系統。

Docker Hub為組件/系統提供商建立了一個部署到Docker 上的生態、App Market 環境。個人應用的普及依賴公有倉庫，企業級應用普及依賴私有倉庫。為私有容器提供安全、高速訪問和多雲聯通。

Docker的挑戰者Rocket

CoreOS 使用 Docker 容器構建其服務，並對 Docker 項目做出巨大貢獻。但2014年CoreOS宣佈正在開發自己的容器引擎Rocket ，因為其不同Docker 的發展方向。CoreOS在 Docker 早期時候認為 Docker 在為開發人員提供一個標準的容器架構，簡化了開發人員的日常工作。後來發現 Docker在獲得很多資金後的使命已經擴張太多，現在不是在談論 Docker 容器，而是 Docker平臺。

Docker的Roadmap表明旨在想要構築一個完整的Docker平臺，包括Machine (系統配置)、Swarm (Docker 化應用的原生集群)、Compose (多容器應用組裝)。Docker的發展方向將對Docker的周邊生態產生複雜影響，後續可能面臨更多來自生態的挑戰，關於Docker詳細分析，請通過“原文鏈接”參閱作者總結的<容器技術架構、網絡和生態詳解>電子書。