快速理解docker

技術源頭

簡單的說Docker是一個構建在LXC之上的,基于進程容器(Processcontainer)的輕量級VM解決方案，Docker container和普通的虛擬機Image相比, 最大的區別是它并不包含操作系統內核。因此非常輕量。

普通虛擬機將整個操作系統運行在虛擬的硬件平臺上, 進而提供完整的運行環境供應用程序運行, 而Docker則直接在宿主平臺上加載運行應用程序. 本質上他在底層使用LXC啟動一個Linux Container,通過cgroup等機制對不同的container內運行的應用程序進行隔離,權限管理和quota分配等，每個container擁有自己獨立的各種命名空間(亦即資源)包括:PID 進程, MNT 文件系統, NET 網絡, IPC , UTS 主機名 等。

Build,Ship,Run

LXC(linux container)已經出來很多年了，一直不溫不火，docker為啥突然這么火？Docker引入了ship（發布）這個重要概念，打通了build，ship，run這一套軟件開發流程。使軟件開發、發布，運行變得簡單，契合當前時髦的DeveOps的理念。

從技術角度看，基本上你可以認為目前的Docker是LXC的一個高級封裝,提供了各種輔助工具和標準接口方便你使用LXC,你可以依靠LXC和各種腳本實現與docker類似的功能，就像你不使用APT/yum等工具也可以自己搞定軟件安裝一樣，你使用他們的關鍵原因是方便易用！實際使用中，你一般不用關心底層LXC的細節,同時也不排將來docker實現基于非LXC方案的可能性在LXC的基礎上, Docker額外提供的Feature包括：標準統一的打包部署運行方案， 歷史版本控制， Image的重用，Image共享發布等等。

什么阻礙docker的廣泛應用

Docker理念非常好，當前技術也非常熱門，但其實在實際產品中，真正用到docker的非常少。

安全問題，虛擬機的安全是經過驗證的，這種輕量級的通過內存空間的隔離host OS非常容易被攻破，所以目前docker在公有云上的應用非常少。當能docker已經在這方面進行了很多改進，比如運行時的系統調用黑名單，圍繞鏡像的安全也引起了關注。

大型應用/復雜應用使用dockerfile基本是不可能的事情，由于他抽象層次太高，以至于不能應對復雜度的用例。

依賴大量的內核的新特性，而這些內核特性還遠未成熟，在實際的使用過程中，常常出現穩定性問題。

雖然說這項技術還在成熟，總的來說，docker是一項非常有前景的技術。

docker生態系統

2013年是容器和周邊技術高歌猛進的一年，這其中以Docker的流行為代表，以下兩家公司和他們的產品具有標志意義。

2013年，Docker version 0.10：Docker是PaaS提供商dotCloud（最近已經正式改名為Docker Inc.）開源的一個基于LXC的高級容器引擎，源代碼托管在GitHub上，基于Go語言并遵從Apache 2.0協議開源。Docker的出現極大簡化了容器的創建和管理，分層式的AUFS實現了Docker鏡像。

2013年，CoreOS：這家在硅谷某個車庫里成立的創業公司發布了專門為大規模服務器部署定制的Linux精簡系統，目的是為運行以輕量級容器為載體的應用提供一個高度優化的底層系統。

2014年，大量圍繞Docker和CoreOS的創業公司、新近開源的軟件項目、大型企業和互聯網公司的加入，使輕量級容器技術的浪潮更上一層樓。

正如定義所言，Docker是“Container Engine”，它是一個把cgroup、namespace等容器底層技術抽象的一個引擎，為用戶提供了創建和管理容器的便捷界面（包括命令行和API）。

概念明晰了，我們先從技術棧的維度來看Docker和它的生態系統，把從Linux到Docker做四個層面的分層。

Linux操作系統。完整的Linux內核，履行操作的使命：管理硬件，調度任務，提供用戶界面和服務等。

容器的內核實現。這主要包括Linux內核中的cgroup、namespace等，它們為容器（用戶進程）的資源隔離性提供了內核層面的保障。

輕量級容器的基礎工具。通過LXC這樣的工具可以完成容器創建、啟動等基本操作，但使用LXC需要熟知容器內核實現原理。這對于普通用戶來說有一定難度，并且LXC在不同Linux發行版不一致。

容器管理引擎。Docker是這一層的主角。Docker由Docker engine和Docker client組成。Docker engine將神秘的cgroup、復雜的LXC統統隱藏起來，使用簡單的命令即可完成容器的運行和管理。它的另一個獨特之處在于AUFS的運用，Copy on write模式的分層文件系統使容器的鏡像可以像搭積木一樣靈活創建和修改，并在網絡上實現增量分發。Docker client，特別是它的API，為在Docker之上的生態系統發展提供了可能性。

Docker的出現和標準化，為以輕量級容器為核心的生態系統提供了爆發式增長的機會。我們從以下幾個角度來看Docker的生態系統。

Docker和容器宿主

前文提到的Docker Inc.和CoreOS已經賺足眼球，投資者接踵而至，大規模融資此起彼伏。企業級廠商如紅帽、Ubuntu等不甘寂寞，紛紛亮明旗幟，選擇站隊。

6月在舊金山舉行的DockerCon 2014展示了Docker對未來的雄心壯志。在Docker engine逐漸穩定并標準化的背景下，Docker的未來目標是為互聯網基礎架構制定新的標準。最近開源的libcontainer、libchan和libswarm三個項目，吹響了這場戰役的沖鋒號。

在新版本Docker engine中，由Go語言開發的libcontainer庫已取代LXC。我認為，它更大的目的是反向定義容器的實現標準，將底層實現（也許可以完全不用cgroup甚至Linux）都抽象化到libcontainer的接口。

libchan類庫，以標準接口的方式解決容器的互聯互通，實現跨平臺，能更好支持分布式系統和并發編程。

· libswarm是另一個很簡單的類庫，但它將實質性地推動互聯網應用架構的創新。它抽象了應用部署和集群管理的細節，為應用程序賦予了跨云平臺和互聯網級彈性。

CoreOS的口號“A new way to think about servers”，這句話闡明了他們對改造互聯網服務器的目標。CoreOS通過最小化的定制版Linux系統為容器運行提供載體。2014年8月14日，傳來了CoreOS收購Quay.IO并推出CoreOS Enterprise Registry服務的新聞。顯然，CoreOS并不滿足于服務器層的工作，其目標定位在為企業用戶提供完整的容器技術服務棧，提供管理大型容器集群的整體解決方案。在這個類別中生存的是標準定義者，它們是整個Docker生態系統的基礎。

鏡像存儲和容器托管

這包括容器的鏡像存儲和CaaS（Container as a Service）類的容器運行托管，有代表性的公司是StackDock、Orchard、Tutum、Quay.IO、Baremetal.IO等。

這幾家幾乎全都是創業公司，他們圍繞輕量級容器的整個生命周期來設計自己的產品，有的聚焦容器鏡像描述文件（Dockerfile）向導化生成和構建過程的優化（如StackDock），有的提供包括SSD在內的高性能托管環境（如StackDock和Tutum），有的在監控和彈性擴展方面做足文章（如Tutum），也有像Baremetal.IO這樣針對企業級整體解決方案的公司。

容器的鏡像存儲和運行托管是Docker生態體系中非常接近最終用戶的一層。這個類別中的公司也許并沒有高深莫測的技術，也不是標準的定義者，但通過它們與細分市場中客戶的長期溝通合作，積累了大量Docker商用化的經驗和實踐。

基于Docker的微PaaS

鏡像存儲（靜態）和容器托管（動態）都是以容器為單位的。下面我們將要講述以應用為單位，以容器為底層技術實現的微PaaS。

這幾年隨著Microsoft Azure、Cloud Foundry的普及，PaaS的概念已經深入人心。傳統意義上PaaS實例一般都與一個特定的IaaS平臺綁定，提供部署接口、負載平衡、服務綁定等，然而Docker世界中產生的微PaaS，在此基礎上進一步創新。這個領域比較有代表性的是Flynn和Deis.IO，它們都是開源項目。

Flynn分為Layer 0和Layer 1兩層。Layer 0主要做底層硬件和云平臺的抽象，分布式配置、任務調度、服務發現等基礎工作，它為上層的容器運行環境提供了一個抽象的資源平臺。Flynn可以快速部署在AWS上，今后也可擴展到其他公有云和私有云。Layer 1主要服務于應用，是PaaS功能的具體實現層，它提供了基本的管理API和客戶端，實現了Git Receiver、Heroku Buildpacks、Routing和Datastore等PaaS核心功能。Layer 1本身和它所管理的應用，都以容器為載體。

Deis.IO，它的一個亮點是用CoreOS承擔底層資源管理的任務。在部署Deis PaaS環境時，首先安裝的Controller會創建一個CoreOS系統，然后在其之上以容器的方式運行Deis的所有組件。對CoreOS的支持是一個非常聰明的選擇，目前CoreOS已可以運行在多個公有云平臺、虛擬機和物理機環境下，這為Deis提供了與生俱來的跨云平臺能力。

Flynn和Deis的共同特點，是對復雜和大規模分布式應用的原生支持。Heroku創始人Adam Wiggins曾發布著名的“十二要素應用宣言（The Twelve-Factor App）”，這個宣言定義了以服務方式和通過互聯網交付的軟件應該遵循的十二個要素。Flynn和Deis都是十二要素的忠實擁護者，它們的微PaaS平臺與Heroku有極好的兼容性。

微PaaS創業公司層出不窮，競爭十分激烈，但也許走到最后的只是少數。在這一輪容器技術熱潮中，微PaaS正在影響軟件開發和運維流程，改變軟件的交付方式，把十二要素類互聯網應用架構標準化。

Orchestration、Management和Moni-t-oring

圍繞Docker API做Web UI的門檻相對較低，受到了大家的追捧，這一類主要有DockerUI、Shipyard、maDocker等。它們無一例外都調用Docker API和其他類庫，把對容器的管理和監控呈現在Web頁面中，這在某種程度上降低了企業網管對這些新技術的恐懼。

這一領域有三個不得不提的高富帥項目：Google Kubernetes、Cloud Foundry的BOSH和Diego。

Kubernetes是構建在Docker之上的容器集群管理系統，Google在2014年6月將這個項目開源。它可以為用戶提供跨平臺的處理能力，不但能夠在Google的基礎架構中運行，同時可以訪問其他的云計算服務器，如AWS，甚至是私有云。

這個系統一經開源，就得到了IBM、紅帽、微軟、Docker、Mesosphere、CoreOS和SaltStack等廠商的支持：微軟將確保Kubernetes能夠在其Azure云中作為基于Linux的虛擬機系統容器并正常運作；紅帽則將其引入了自己的云產品；IBM的計劃是為Kubernetes與Docker貢獻代碼；CoreOS將在其操作系統發行版中為Kubernetes提供支持；SaltStack正努力簡化Kubernetes運行在其他環境下的部署流程；而Mesosphere則打算將這項技術加入到自己的Mesos同名開源項目當中。Google一呼百應的大將之風展現無遺。

Cloud Foundry的BOSH是部署和運維工具，它通過類似操作系統驅動程序的CPI（Cloud Provider Interface）來實現對多種異構云平臺的支持和抽象，以近乎優雅的方式管理VM模板【注：在Cloud Foundry術語中稱為干細胞（stemcell）】、軟件發布（release）和部署配置腳本文件。最近BOSH推出了一個試驗性質的項目BOSH Release for Docker。

Cloud Foundry在它的DEA（Droplet Execution Agent）中使用基于Warden的容器技術來做PaaS的應用隔離。最新的Diego（Go語言版DEA）項目目標是讓Cloud Foundry在跨運行時環境方面更具有擴展性，這些運行時環境就包括Docker，也可能會原生支持Windows Server。

網絡層的增強和解決方案

容器之間如何互聯互通？Docker引擎中的內聯網絡能否滿足企業級別網絡的需求？當容器像今天的虛擬機一樣在企業環境大規模部署時，復雜的網絡需求如網絡配置管理、安全監控、流量QoS、網絡隔離等一定會出現。

在虛擬化的世界里，這些需求催生了龐大的網絡虛擬化（SDN）產業，在容器的環境中，是否有同樣的挑戰和機會？在這個領域中，目前受關注較多的是Skydock和VNS3開源項目，但整體上還都處在萌芽起步階段。

容器 Docker

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。