Docker 是一個開源的應(yīng)用容器引擎，讓開發(fā)者可以打包他們的應(yīng)用以及依賴包到一個可移植的鏡像中，然后發(fā)布到任何流行的 Linux或Windows 機器上，也可以實現(xiàn)虛擬化。容器是完全使用沙箱機制，相互之間不會有任何接口。

Docker 是一個開源的應(yīng)用容器引擎，讓開發(fā)者可以打包他們的應(yīng)用以及依賴包到一個可移植的容器中，然后發(fā)布到任何流行的Linux機器上，也可以實現(xiàn)虛擬化，容器是完全使用沙箱機制，相互之間不會有任何接口。

一個完整的Docker有以下幾個部分組成：

1.DockerClient客戶端

2.Docker Daemon守護(hù)進(jìn)程

3.Docker Image鏡像

4.DockerContainer容器

Docker 起源

Docker 是 PaaS 提供商 dotCloud 開源的一個基于 LXC 的高級容器引擎，源代碼托管在 Github 上, 基于go語言并遵從Apache2.0協(xié)議開源。

Docker自2013年以來非�；馃�，無論是從 github 上的代碼活躍度，還是Redhat在RHEL6.5中集成對Docker的支持, 就連 Google 的 Compute Engine 也支持 docker 在其之上運行。

一款開源軟件能否在商業(yè)上成功，很大程度上依賴三件事 - 成功的 user case(用例), 活躍的社區(qū)和一個好故事。 dotCloud 自家的 PaaS 產(chǎn)品建立在docker之上，長期維護(hù)且有大量的用戶，社區(qū)也十分活躍，接下來我們看看docker的故事。

• 環(huán)境管理復(fù)雜 - 從各種OS到各種中間件到各種app, 一款產(chǎn)品能夠成功作為開發(fā)者需要關(guān)心的東西太多，且難于管理，這個問題幾乎在所有現(xiàn)代IT相關(guān)行業(yè)都需要面對。

• 云計算時代的到來 - AWS的成功, 引導(dǎo)開發(fā)者將應(yīng)用轉(zhuǎn)移到 cloud 上, 解決了硬件管理的問題，然而中間件相關(guān)的問題依然存在 (所以openstack HEAT和 AWS cloudformation 都著力解決這個問題)。開發(fā)者思路變化提供了可能性。

• 虛擬化手段的變化 - cloud 時代采用標(biāo)配硬件來降低成本，采用虛擬化手段來滿足用戶按需使用的需求以及保證可用性和隔離性。然而無論是KVM還是Xen在 docker 看來，都在浪費資源，因為用戶需要的是高效運行環(huán)境而非OS, GuestOS既浪費資源又難于管理, 更加輕量級的LXC更加靈活和快速

• LXC的移動性 - LXC在 linux 2.6 的 kernel 里就已經(jīng)存在了，但是其設(shè)計之初并非為云計算考慮的，缺少標(biāo)準(zhǔn)化的描述手段和容器的可遷移性，決定其構(gòu)建出的環(huán)境難于遷移和標(biāo)準(zhǔn)化管理(相對于KVM之類image和snapshot的概念)。docker 就在這個問題上做出實質(zhì)性的革新。這是docker最獨特的地方。

面對上述幾個問題，docker設(shè)想是交付運行環(huán)境如同海運，OS如同一個貨輪，每一個在OS基礎(chǔ)上的軟件都如同一個集裝箱，用戶可以通過標(biāo)準(zhǔn)化手段自由組裝運行環(huán)境，同時集裝箱的內(nèi)容可以由用戶自定義，也可以由專業(yè)人員制造。這樣，交付一個軟件，就是一系列標(biāo)準(zhǔn)化組件的集合的交付，如同樂高積木，用戶只需要選擇合適的積木組合，并且在最頂端署上自己的名字(最后一個標(biāo)準(zhǔn)化組件是用戶的app)。這也就是基于docker的PaaS產(chǎn)品的原型。

Docker 架構(gòu)

Docker 使用客戶端-服務(wù)器 (C/S) 架構(gòu)模式，使用遠(yuǎn)程API來管理和創(chuàng)建Docker容器。Docker 容器通過 Docker 鏡像來創(chuàng)建。容器與鏡像的關(guān)系類似于面向?qū)ο缶幊讨械膶ο笈c類。

Docker采用 C/S架構(gòu) Docker daemon 作為服務(wù)端接受來自客戶的請求，并處理這些請求（創(chuàng)建、運行、分發(fā)容器）�？蛻舳撕头�務(wù)端既可以運行在一個機器上，也可通過 socket 或者RESTful API 來進(jìn)行通信。

Docker daemon 一般在宿主主機后臺運行，等待接收來自客戶端的消息。 Docker 客戶端則為用戶提供一系列可執(zhí)行命令，用戶用這些命令實現(xiàn)跟 Docker daemon 交互。

Docker 特性

在docker的網(wǎng)站上提到了docker的典型場景：

• Automating the packaging and deployment of applications（使應(yīng)用的打包與部署自動化）

• Creation of lightweight, private PAAS environments（創(chuàng)建輕量、私密的PAAS環(huán)境）

• Automated testing and continuous integration/deployment（實現(xiàn)自動化測試和持續(xù)的集成/部署）

• Deploying and scaling web apps, databases and backend services（部署與擴展webapp、數(shù)據(jù)庫和后臺服務(wù)）

由于其基于LXC的輕量級虛擬化的特點，docker相比KVM之類最明顯的特點就是啟動快，資源占用小。因此對于構(gòu)建隔離的標(biāo)準(zhǔn)化的運行環(huán)境，輕量級的PaaS(如dokku), 構(gòu)建自動化測試和持續(xù)集成環(huán)境，以及一切可以橫向擴展的應(yīng)用(尤其是需要快速啟停來應(yīng)對峰谷的web應(yīng)用)。

1.構(gòu)建標(biāo)準(zhǔn)化的運行環(huán)境，現(xiàn)有的方案大多是在一個baseOS上運行一套puppet/chef，或者一個image文件，其缺點是前者需要base OS許多前提條件，后者幾乎不可以修改(因為copy on write 的文件格式在運行時rootfs是read only的)。并且后者文件體積大，環(huán)境管理和版本控制本身也是一個問題。

2.PaaS環(huán)境是不言而喻的，其設(shè)計之初和dotcloud的案例都是將其作為PaaS產(chǎn)品的環(huán)境基礎(chǔ)

3.因為其標(biāo)準(zhǔn)化構(gòu)建方法(buildfile)和良好的REST API，自動化測試和持續(xù)集成/部署能夠很好的集成進(jìn)來

4.因為LXC輕量級的特點，其啟動快，而且docker能夠只加載每個container變化的部分，這樣資源占用小，能夠在單機環(huán)境下與KVM之類的虛擬化方案相比能夠更加快速和占用更少資源

Docker 局限

Docker并不是全能的，設(shè)計之初也不是KVM之類虛擬化手段的替代品，簡單總結(jié)幾點：

1.Docker是基于Linux 64bit的，無法在32bit的linux/Windows/unix環(huán)境下使用

2.LXC是基于cgroup等linux kernel功能的，因此container的guest系統(tǒng)只能是linux base的

3.隔離性相比KVM之類的虛擬化方案還是有些欠缺，所有container公用一部分的運行庫

4.網(wǎng)絡(luò)管理相對簡單，主要是基于namespace隔離

5.cgroup的cpu和cpuset提供的cpu功能相比KVM的等虛擬化方案相比難以度量(所以dotcloud主要是按內(nèi)存收費)

6.Docker對disk的管理比較有限

7.container隨著用戶進(jìn)程的停止而銷毀，container中的log等用戶數(shù)據(jù)不便收集

針對1-2，有windows base應(yīng)用的需求的基本可以pass了; 3-5主要是看用戶的需求，到底是需要一個container還是一個VM, 同時也決定了docker作為 IaaS 不太可行。

針對6,7雖然是docker本身不支持的功能，但是可以通過其他手段解決(disk quota, mount --bind)。總之，選用container還是vm, 就是在隔離性和資源復(fù)用性上做權(quán)衡。

另外即便docker 0.7能夠支持非AUFS的文件系統(tǒng)，但是由于其功能還不穩(wěn)定，商業(yè)應(yīng)用或許會存在問題，而AUFS的穩(wěn)定版需要kernel 3.8, 所以如果想復(fù)制dotcloud的成功案例，可能需要考慮升級kernel或者換用ubuntu的server版本(后者提供deb更新)。這也是為什么開源界更傾向于支持ubuntu的原因(kernel版本)

Docker并非適合所有應(yīng)用場景，Docker只能虛擬基于Linux的服務(wù)。Windows Azure 服務(wù)能夠運行Docker實例，但到為止Windows服務(wù)還不能被虛擬化。

可能最大的障礙在于管理實例之間的交互。由于所有應(yīng)用組件被拆分到不同的容器中，所有的服務(wù)器需要以一致的方式彼此通信。這意味著任何人如果選擇復(fù)雜的基礎(chǔ)設(shè)施，那么必須掌握應(yīng)用編程接口管理以及集群工具，比如Swarm、Mesos或者Kubernets以確保機器按照預(yù)期運轉(zhuǎn)并支持故障切換。

Docker在本質(zhì)上是一個附加系統(tǒng)。使用文件系統(tǒng)的不同層構(gòu)建一個應(yīng)用是有可能的。每個組件被添加到之前已經(jīng)創(chuàng)建的組件之上，可以比作為一個文件系統(tǒng)更明智。分層架構(gòu)帶來另一方面的效率提升，當(dāng)你重建存在變化的Docker鏡像時，不需要重建整個Docker鏡像，只需要重建變化的部分。

可能更為重要的是，Docker旨在用于彈性計算。每個Docker實例的運營生命周期有限，實例數(shù)量根據(jù)需求增減。在一個管理適度的系統(tǒng)中，這些實例生而平等，不再需要時便各自消亡了。

針對Docker環(huán)境存在的不足，意味著在開始部署Docker前需要考慮如下幾個問題。首先，Docker實例是無狀態(tài)的。這意味著它們不應(yīng)該承載任何交易數(shù)據(jù)，所有數(shù)據(jù)應(yīng)該保存在數(shù)據(jù)庫服務(wù)器中。

其次，開發(fā)Docker實例并不像創(chuàng)建一臺虛擬機、添加應(yīng)用然后克隆那樣簡單。為成功創(chuàng)建并使用Docker基礎(chǔ)設(shè)施，管理員需要對系統(tǒng)管理的各個方面有一個全面的理解，包括Linux管理、編排及配置工具比如Puppet、Chef以及Salt。這些工具生來就基于命令行以及腳本。

Docker 原理

Docker核心解決的問題是利用LXC來實現(xiàn)類似VM的功能，從而利用更加節(jié)省的硬件資源提供給用戶更多的計算資源。同VM的方式不同, LXC 其并不是一套硬件虛擬化方法 - 無法歸屬到全虛擬化、部分虛擬化和半虛擬化中的任意一個，而是一個操作系統(tǒng)級虛擬化方法, 理解起來可能并不像VM那樣直觀。所以我們從虛擬化到docker要解決的問題出發(fā)，看看他是怎么滿足用戶虛擬化需求的。

用戶需要考慮虛擬化方法，尤其是硬件虛擬化方法，需要借助其解決的主要是以下4個問題:

• 隔離性 - 每個用戶實例之間相互隔離, 互不影響。硬件虛擬化方法給出的方法是VM, LXC給出的方法是container，更細(xì)一點是kernel namespace

• 可配額/可度量 - 每個用戶實例可以按需提供其計算資源，所使用的資源可以被計量。硬件虛擬化方法因為虛擬了CPU, memory可以方便實現(xiàn), LXC則主要是利用cgroups來控制資源

• 移動性 - 用戶的實例可以很方便地復(fù)制、移動和重建。硬件虛擬化方法提供snapshot和image來實現(xiàn)，docker(主要)利用AUFS實現(xiàn)

• 安全性 - 這個話題比較大，這里強調(diào)是host主機的角度盡量保護(hù)container。硬件虛擬化的方法因為虛擬化的水平比較高，用戶進(jìn)程都是在KVM等虛擬機容器中翻譯運行的, 然而對于LXC, 用戶的進(jìn)程是lxc-start進(jìn)程的子進(jìn)程, 只是在Kernel的namespace中隔離的, 因此需要一些kernel的patch來保證用戶的運行環(huán)境不會受到來自host主機的惡意入侵, dotcloud(主要是)利用kernel grsec patch解決的.

Linux Namespace

LXC所實現(xiàn)的隔離性主要是來自kernel的namespace, 其中pid, net, ipc, mnt, uts 等namespace將container的進(jìn)程, 網(wǎng)絡(luò), 消息, 文件系統(tǒng)和hostname 隔離開。

pid namespace

之前提到用戶的進(jìn)程是lxc-start進(jìn)程的子進(jìn)程, 不同用戶的進(jìn)程就是通過pidnamespace隔離開的，且不同 namespace 中可以有相同PID。具有以下特征:

1.每個namespace中的pid是有自己的pid=1的進(jìn)程(類似/sbin/init進(jìn)程)

2.每個namespace中的進(jìn)程只能影響自己的同一個namespace或子namespace中的進(jìn)程

3.因為/proc包含正在運行的進(jìn)程，因此在container中的pseudo-filesystem的/proc目錄只能看到自己namespace中的進(jìn)程

4.因為namespace允許嵌套，父namespace可以影響子namespace的進(jìn)程，所以子namespace的進(jìn)程可以在父namespace中看到，但是具有不同的pid

正是因為以上的特征，所有的LXC進(jìn)程在docker中的父進(jìn)程為docker進(jìn)程，每個lxc進(jìn)程具有不同的namespace。同時由于允許嵌套，因此可以很方便的實現(xiàn) LXC in LXC

net namespace

有了 pid namespace, 每個namespace中的pid能夠相互隔離，但是網(wǎng)絡(luò)端口還是共享host的端口。網(wǎng)絡(luò)隔離是通過netnamespace實現(xiàn)的，

每個net namespace有獨立的 network devices, IP addresses, IP routing tables, /proc/net 目錄。這樣每個container的網(wǎng)絡(luò)就能隔離開來。

LXC在此基礎(chǔ)上有5種網(wǎng)絡(luò)類型，docker默認(rèn)采用veth的方式將container中的虛擬網(wǎng)卡同host上的一個docker bridge連接在一起。

ipc namespace

container中進(jìn)程交互還是采用linux常見的進(jìn)程間交互方法(interprocess communication - IPC), 包括常見的信號量、消息隊列和共享內(nèi)存。然而同VM不同，container 的進(jìn)程間交互實際上還是host上具有相同pid namespace中的進(jìn)程間交互，因此需要在IPC資源申請時加入namespace信息 - 每個IPC資源有一個的 32bit ID。

mnt namespace

類似chroot，將一個進(jìn)程放到一個特定的目錄執(zhí)行。mnt namespace允許不同namespace的進(jìn)程看到的文件結(jié)構(gòu)不同，這樣每個 namespace 中的進(jìn)程所看到的文件目錄就被隔離開了。同chroot不同，每個namespace中的container在/proc/mounts的信息只包含所在namespace的mount point。

uts namespace

UTS(“UNIX Time-sharing System”) namespace允許每個container擁有獨立的hostname和domain name,

使其在網(wǎng)絡(luò)上可以被視作一個獨立的節(jié)點而非Host上的一個進(jìn)程。

usernamespace

每個container可以有不同的 user 和 group id, 也就是說可以以container內(nèi)部的用戶在container內(nèi)部執(zhí)行程序而非Host上的用戶。

有了以上6種namespace從進(jìn)程、網(wǎng)絡(luò)、IPC、文件系統(tǒng)、UTS和用戶角度的隔離，一個container就可以對外展現(xiàn)出一個獨立計算機的能力，并且不同container從OS層面實現(xiàn)了隔離。

然而不同namespace之間資源還是相互競爭的，仍然需要類似ulimit來管理每個container所能使用的資源 - LXC 采用的是cgroup。

Control Groups

cgroups 實現(xiàn)了對資源的配額和度量。 cgroups 的使用非常簡單，提供類似文件的接口，在 /cgroup目錄下新建一個文件夾即可新建一個group，在此文件夾中新建task文件，并將pid寫入該文件，即可實現(xiàn)對該進(jìn)程的資源控制。具體的資源配置選項可以在該文件夾中新建子 subsystem ，{子系統(tǒng)前綴}.{資源項} 是典型的配置方法，

如memory.usage_in_bytes 就定義了該group 在subsystem memory中的一個內(nèi)存限制選項。

另外，cgroups中的 subsystem可以隨意組合，一個subsystem可以在不同的group中，也可以一個group包含多個subsystem - 也就是說一個 subsystem。

關(guān)于術(shù)語定義

A *cgroup* associates a set of tasks with a set of parameters for one

or more subsystems.

A *subsystem* is a module that makes use of the task grouping

facilities provided by cgroups to treat groups of tasks in

particular ways. A subsystem is typically a "resource controller" that

schedules a resource or applies per-cgroup limits, but it may be

anything that wants to act on a group of processes, e.g. a

virtualization subsystem.

我們主要關(guān)心cgroups可以限制哪些資源，即有哪些subsystem是我們關(guān)心。

cpu: 在cgroup中，并不能像硬件虛擬化方案一樣能夠定義CPU能力，但是能夠定義CPU輪轉(zhuǎn)的優(yōu)先級，因此具有較高CPU優(yōu)先級的進(jìn)程會更可能得到CPU運算。

通過將參數(shù)寫入cpu.shares,即可定義改cgroup的CPU優(yōu)先級 - 這里是一個相對權(quán)重，而非絕對值。當(dāng)然在cpu這個subsystem中還有其他可配置項，手冊中有詳細(xì)說明。

cpusets : cpusets 定義了有幾個CPU可以被這個group使用，或者哪幾個CPU可以供這個group使用。在某些場景下，單CPU綁定可以防止多核間緩存切換，從而提高效率

memory : 內(nèi)存相關(guān)的限制

blkio : block IO相關(guān)的統(tǒng)計和限制，byte/operation統(tǒng)計和限制(IOPS等)，讀寫速度限制等，但是這里主要統(tǒng)計的都是同步IO

net_cls，cpuacct ,devices ,freezer 等其他可管理項。

Linux 容器

借助于namespace的隔離機制和cgroup限額功能，LXC提供了一套統(tǒng)一的API和工具來建立和管理container, LXC利用了如下 kernel 的features:

• Kernel namespaces (ipc, uts, mount, pid, network and user)

• Apparmor and SELinux profiles

• Seccomp policies

• Chroots (using pivot_root)

• Kernel capabilities

• Control groups (cgroups)

LXC 向用戶屏蔽了以上 kernel 接口的細(xì)節(jié), 提供了如下的組件大大簡化了用戶的開發(fā)和使用工作:

• The liblxc library

• Several language bindings (python3, lua and Go)

• A set of standard tools to control the containers

• Container templates

LXC 旨在提供一個共享kernel的 OS 級虛擬化方法，在執(zhí)行時不用重復(fù)加載Kernel, 且container的kernel與host共享，因此可以大大加快container的 啟動過程，并顯著減少內(nèi)存消耗。在實際測試中，基于LXC的虛擬化方法的IO和CPU性能幾乎接近 baremetal 的性能, 大多數(shù)數(shù)據(jù)有相比 Xen具有優(yōu)勢。當(dāng)然對于KVM這種也是通過Kernel進(jìn)行隔離的方式, 性能優(yōu)勢或許不是那么明顯, 主要還是內(nèi)存消耗和啟動時間上的差異。在參考文獻(xiàn)中提到了利用iozone進(jìn)行 Disk IO吞吐量測試KVM反而比LXC要快，而且筆者在device mapping driver下重現(xiàn)同樣case的實驗中也確實能得到如此結(jié)論。參考文獻(xiàn)從網(wǎng)絡(luò)虛擬化中虛擬路由的場景(網(wǎng)絡(luò)IO和CPU角度)比較了KVM和LXC, 得到結(jié)論是KVM在性能和隔離性的平衡上比LXC更優(yōu)秀 - KVM在吞吐量上略差于LXC, 但CPU的隔離可管理項比LXC更明確。

關(guān)于CPU, DiskIO, network IO 和 memory 在KVM和LXC中的比較還是需要更多的實驗才能得出可信服的結(jié)論。

AUFS

Docker對container的使用基本是建立在LXC基礎(chǔ)之上的，然而LXC存在的問題是難以移動 - 難以通過標(biāo)準(zhǔn)化的模板制作、重建、復(fù)制和移動 container。

在以VM為基礎(chǔ)的虛擬化手段中，有image和snapshot可以用于VM的復(fù)制、重建以及移動的功能。想要通過container來實現(xiàn)快速的大規(guī)模部署和更新, 這些功能不可或缺。

Docker 正是利用AUFS來實現(xiàn)對container的快速更新 - 在docker0.7中引入了storage driver, 支持AUFS, VFS, device mapper, 也為BTRFS以及ZFS引入提供了可能。但除了AUFS都未經(jīng)過dotcloud的線上使用，因此我們還是從AUFS的角度介紹。

AUFS (AnotherUnionFS) 是一種 Union FS, 簡單來說就是支持將不同目錄掛載到同一個虛擬文件系統(tǒng)下(unite several directories into a single virtual filesystem)的文件系統(tǒng), 更進(jìn)一步地, AUFS支持為每一個成員目錄(AKA branch)設(shè)定'readonly', 'readwrite' 和 'whiteout-able' 權(quán)限, 同時AUFS里有一個類似

分層的概念, 對 readonly 權(quán)限的branch可以邏輯上進(jìn)行修改(增量地, 不影響readonly部分的)。通常 Union FS有兩個用途, 一方面可以實現(xiàn)不借助 LVM， RAID 將多個disk和掛在到一個目錄下, 另一個更常用的就是將一個readonly的branch和一個writeable的branch聯(lián)合在一起，Live CD正是基于此可以允許在 OS image 不變的基礎(chǔ)上允許用戶在其上進(jìn)行一些寫操作。Docker在AUFS上構(gòu)建的container image也正是如此，接下來我們從啟動container中的linux為例介紹docker在AUFS特性的運用。

典型的Linux啟動到運行需要兩個FS - bootfs + rootfs (從功能角度而非文件系統(tǒng)角度)（圖1）

bootfs (boot file system) 主要包含 bootloader 和 kernel,bootloader主要是引導(dǎo)加載kernel, 當(dāng)boot成功后 kernel 被加載到內(nèi)存中后 bootfs就被umount了.

rootfs (root file system) 包含的就是典型 Linux 系統(tǒng)中的 /dev, /proc, /bin, /etc 等標(biāo)準(zhǔn)目錄和文件。