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

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

      談起容器技術，不得不提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詳細分析，請透過“原文連結”參閱作者總結的<容器技術架構、網路和生態詳解>電子書。

溫馨提示：
請搜尋“ICT_Architect”或“掃一掃”二維碼關註公眾號，點選原文連結獲取更多技術資料。

求知若渴, 虛心若愚—Stay hungry, Stay foolish