Docker容器: 那些你不知道的事

NO IMAGE

先說說我們知道的事,Docker 是 PaaS 提供商 DotCloud 開源的一個高階容器引擎,原始碼託管在 Github 上,基於go語言並遵從Apache2.0協議開源。Docker相當於物理行業的集裝箱對物流的影響一樣,成為Container上執行鏡象的統一打包和交換的標準,Docker介紹請參看文章容器演進和技術基礎介紹。

我們知道,Docker使用了容器的環境隔離和資源限制技術,把映象和執行環境打包到Image中。Register支援容器上傳和下載功能。

我們知道,Docker同時提供了Build,Ship和Run,運維只需要在環境重配置好Docker,剩下的工作就是部署容器,實現Build Once Run Anywhere和Configure Once Run Anything;從而促進了容器技術的爆發。

Docker採用Client Server模式和外掛式架構設計,Docker的後端採用非常鬆耦合的架構,模組之間相互獨立,具體請參看文章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主機上多容器應用的工具,通過單獨檔案,定義多容器應用並執行容器。

Machine是機器管理工具,簡化容器安裝和部署,通過簡單命令實現對Docker容器的啟動、升級和網路配置。

Swarm是Docker容器的機器管理工具,使得Docker機器能夠有效的被管理起來,另外,Docker還有個打包工具叫DockerFile。

我們也知道,Docker的網路技術和能力一直是容器技術中最難、也是最不看好的技術之一,由於容器技術本身的網路能力具有侷限性,參看文章Docker原生網路和實現原理。所以目前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容器,並使他們可以被自動發現,對使用該網路的應用來說,所以容器就像是連結在同一個網路交換機上,無需配置埠對映、鏈路等引數。

或許我們知道,只有滿足要求的Docker相關程式碼,資源才允許釋出。這是Docker安全特性的要求,為了提升Docker的安全性,Notary安全過濾器被引入到Docker中,保證網際網路使用者操作的規範性和安全性。

但是,下面的內容您就不一定知道,那麼下面我們就重點談談我們不知道或知道不多的Docker知識。

容器和容器OS

CoreOS支援叢集管理,是最為受歡迎的容器虛擬化OS,專為Docker設計和核心裁剪。 CoreOS中有兩個關鍵容器叢集管理工具,etcd主要實現叢集服務發現、資訊共享和資料同步;而Fleet實現叢集狀態維護、容器操作和確保服務一致可用。

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

Docker容器和儲存

Docker容器在資料讀寫和儲存上,是採用分層和COW的儲存技術實現,具體請參看文章Docker攜手AUFS陪你共度七巧節。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進行主機的重對映。

Rex-Ray和Dogged是Docker開源儲存專案,旨在抽象容器卷管理,通過Docker storage API和Storage Driver遮蔽儲存差異,以容器為粒度管理和發放儲存,簡化容器管理。

在容器持久化容器方面,EMC已經搶佔先機,通過與Flock合作,並且直接參與Docker開源專案Rex-Ray和Dogged,已經事實上控制了儲存虛擬化介面標準,對儲存和Docker容器的發展上已經獲得更多話語權。

隨著Docker技術的飛速發展,容器類似於虛擬機器對陣列的介面需求將隨之而來,Rex-Ray和Dogged技術例證。

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和Kubernetes

Kubernetes源於Google內部叢集管理專案Omega,為了幫助開發者快速部署和管理基於Docker的大規模應用,但Docker容器叢集的管理不僅僅只有Kubernetes。

Kubernetes實現容器叢集管理、資源排程和監控、容器生命週期管理、Service管理、負載均衡管理;可以執行在公有云、私有云和裸機上。支援微軟、紅帽、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的生態系統

早在2014年Linux Foundation 北美峰會上公佈的最活躍開源雲專案排名,Docker僅次於Openstack排在第二位。

目前圍繞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的周邊生態產生複雜影響,後續可能面臨更多來自生態的挑戰。請搜尋“ICT_Architect”關注“架構師技術聯盟”公眾號,獲取更多精彩內容。