Docker 是一個(gè)開源的應(yīng)用容器引擎，讓開發(fā)者可以打包他們的應(yīng)用以及依賴包到一個(gè)可移植的鏡像中，然后發(fā)布到任何流行的 Linux或Windows 機(jī)器上，也可以實(shí)現(xiàn)虛擬化。容器是完全使用沙箱機(jī)制，相互之間不會(huì)有任何接口。
Docker 是一個(gè)開源的應(yīng)用容器引擎，讓開發(fā)者可以打包他們的應(yīng)用以及依賴包到一個(gè)可移植的容器中，然后發(fā)布到任何流行的Linux機(jī)器上，也可以實(shí)現(xiàn)虛擬化，容器是完全使用沙箱機(jī)制，相互之間不會(huì)有任何接口。
一個(gè)完整的Docker有以下幾個(gè)部分組成：
1.DockerClient客戶端
2.Docker Daemon守護(hù)進(jìn)程
3.Docker Image鏡像
4.DockerContainer容器
Docker 起源
Docker 是 PaaS 提供商 dotCloud 開源的一個(gè)基于 LXC 的高級(jí)容器引擎，源代碼托管在 Github 上, 基于go語(yǔ)言并遵從Apache2.0協(xié)議開源。
Docker自2013年以來非常火熱，無論是從 github 上的代碼活躍度，還是Redhat在RHEL6.5中集成對(duì)Docker的支持, 就連 Google 的 Compute Engine 也支持 docker 在其之上運(yùn)行。
一款開源軟件能否在商業(yè)上成功，很大程度上依賴三件事 - 成功的 user case(用例), 活躍的社區(qū)和一個(gè)好故事。 dotCloud 自家的 PaaS 產(chǎn)品建立在docker之上，長(zhǎng)期維護(hù)且有大量的用戶，社區(qū)也十分活躍，接下來我們看看docker的故事。
• 環(huán)境管理復(fù)雜 - 從各種OS到各種中間件到各種app, 一款產(chǎn)品能夠成功作為開發(fā)者需要關(guān)心的東西太多，且難于管理，這個(gè)問題幾乎在所有現(xiàn)代IT相關(guān)行業(yè)都需要面對(duì)。
• 云計(jì)算時(shí)代的到來 - AWS的成功, 引導(dǎo)開發(fā)者將應(yīng)用轉(zhuǎn)移到 cloud 上, 解決了硬件管理的問題，然而中間件相關(guān)的問題依然存在 (所以openstack HEAT和 AWS cloudformation 都著力解決這個(gè)問題)。開發(fā)者思路變化提供了可能性。
• 虛擬化手段的變化 - cloud 時(shí)代采用標(biāo)配硬件來降低成本，采用虛擬化手段來滿足用戶按需使用的需求以及保證可用性和隔離性。然而無論是KVM還是Xen在 docker 看來，都在浪費(fèi)資源，因?yàn)橛脩粜枰氖歉咝н\(yùn)行環(huán)境而非OS, GuestOS既浪費(fèi)資源又難于管理, 更加輕量級(jí)的LXC更加靈活和快速
• LXC的移動(dòng)性 - LXC在 linux 2.6 的 kernel 里就已經(jīng)存在了，但是其設(shè)計(jì)之初并非為云計(jì)算考慮的，缺少標(biāo)準(zhǔn)化的描述手段和容器的可遷移性，決定其構(gòu)建出的環(huán)境難于遷移和標(biāo)準(zhǔn)化管理(相對(duì)于KVM之類image和snapshot的概念)。docker 就在這個(gè)問題上做出實(shí)質(zhì)性的革新。這是docker最獨(dú)特的地方。
面對(duì)上述幾個(gè)問題，docker設(shè)想是交付運(yùn)行環(huán)境如同海運(yùn)，OS如同一個(gè)貨輪，每一個(gè)在OS基礎(chǔ)上的軟件都如同一個(gè)集裝箱，用戶可以通過標(biāo)準(zhǔn)化手段自由組裝運(yùn)行環(huán)境，同時(shí)集裝箱的內(nèi)容可以由用戶自定義，也可以由專業(yè)人員制造。這樣，交付一個(gè)軟件，就是一系列標(biāo)準(zhǔn)化組件的集合的交付，如同樂高積木，用戶只需要選擇合適的積木組合，并且在最頂端署上自己的名字(最后一個(gè)標(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ū)ο缶幊讨械膶?duì)象與類。
|
Docker |
面向?qū)ο?/p> |
|
容器 |
對(duì)象 |
|
鏡像 |
類 |
Docker采用 C/S架構(gòu) Docker daemon 作為服務(wù)端接受來自客戶的請(qǐng)求，并處理這些請(qǐng)求（創(chuàng)建、運(yùn)行、分發(fā)容器）。客戶端和服務(wù)端既可以運(yùn)行在一個(gè)機(jī)器上，也可通過 socket 或者RESTful API 來進(jìn)行通信。
Docker daemon 一般在宿主主機(jī)后臺(tái)運(yùn)行，等待接收來自客戶端的消息。 Docker 客戶端則為用戶提供一系列可執(zhí)行命令，用戶用這些命令實(shí)現(xiàn)跟 Docker daemon 交互。
Docker 特性
在docker的網(wǎng)站上提到了docker的典型場(chǎng)景：
• Automating the packaging and deployment of applications（使應(yīng)用的打包與部署自動(dòng)化）
• Creation of lightweight, private PAAS environments（創(chuàng)建輕量、私密的PAAS環(huán)境）
• Automated testing and continuous integration/deployment（實(shí)現(xiàn)自動(dòng)化測(cè)試和持續(xù)的集成/部署）
• Deploying and scaling web apps, databases and backend services（部署與擴(kuò)展webapp、數(shù)據(jù)庫(kù)和后臺(tái)服務(wù)）
由于其基于LXC的輕量級(jí)虛擬化的特點(diǎn)，docker相比KVM之類最明顯的特點(diǎn)就是啟動(dòng)快，資源占用小。因此對(duì)于構(gòu)建隔離的標(biāo)準(zhǔn)化的運(yùn)行環(huán)境，輕量級(jí)的PaaS(如dokku), 構(gòu)建自動(dòng)化測(cè)試和持續(xù)集成環(huán)境，以及一切可以橫向擴(kuò)展的應(yīng)用(尤其是需要快速啟停來應(yīng)對(duì)峰谷的web應(yīng)用)。
1.構(gòu)建標(biāo)準(zhǔn)化的運(yùn)行環(huán)境，現(xiàn)有的方案大多是在一個(gè)baseOS上運(yùn)行一套puppet/chef，或者一個(gè)image文件，其缺點(diǎn)是前者需要base OS許多前提條件，后者幾乎不可以修改(因?yàn)閏opy on write 的文件格式在運(yùn)行時(shí)rootfs是read only的)。并且后者文件體積大，環(huán)境管理和版本控制本身也是一個(gè)問題。
2.PaaS環(huán)境是不言而喻的，其設(shè)計(jì)之初和dotcloud的案例都是將其作為PaaS產(chǎn)品的環(huán)境基礎(chǔ)
3.因?yàn)槠錁?biāo)準(zhǔn)化構(gòu)建方法(buildfile)和良好的REST API，自動(dòng)化測(cè)試和持續(xù)集成/部署能夠很好的集成進(jìn)來
4.因?yàn)長(zhǎng)XC輕量級(jí)的特點(diǎn)，其啟動(dòng)快，而且docker能夠只加載每個(gè)container變化的部分，這樣資源占用小，能夠在單機(jī)環(huán)境下與KVM之類的虛擬化方案相比能夠更加快速和占用更少資源
Docker 局限
Docker并不是全能的，設(shè)計(jì)之初也不是KVM之類虛擬化手段的替代品，簡(jiǎn)單總結(jié)幾點(diǎn)：
1.Docker是基于Linux 64bit的，無法在32bit的linux/Windows/unix環(huán)境下使用
2.LXC是基于cgroup等linux kernel功能的，因此container的guest系統(tǒng)只能是linux base的
3.隔離性相比KVM之類的虛擬化方案還是有些欠缺，所有container公用一部分的運(yùn)行庫(kù)
4.網(wǎng)絡(luò)管理相對(duì)簡(jiǎn)單，主要是基于namespace隔離
5.cgroup的cpu和cpuset提供的cpu功能相比KVM的等虛擬化方案相比難以度量(所以dotcloud主要是按內(nèi)存收費(fèi))
6.Docker對(duì)disk的管理比較有限
7.container隨著用戶進(jìn)程的停止而銷毀，container中的log等用戶數(shù)據(jù)不便收集
針對(duì)1-2，有windows base應(yīng)用的需求的基本可以pass了; 3-5主要是看用戶的需求，到底是需要一個(gè)container還是一個(gè)VM, 同時(shí)也決定了docker作為 IaaS 不太可行。
針對(duì)6,7雖然是docker本身不支持的功能，但是可以通過其他手段解決(disk quota, mount --bind)�？傊x用container還是vm, 就是在隔離性和資源復(fù)用性上做權(quán)衡。
另外即便docker 0.7能夠支持非AUFS的文件系統(tǒng)，但是由于其功能還不穩(wěn)定，商業(yè)應(yīng)用或許會(huì)存在問題，而AUFS的穩(wěn)定版需要kernel 3.8, 所以如果想復(fù)制dotcloud的成功案例，可能需要考慮升級(jí)kernel或者換用ubuntu的server版本(后者提供deb更新)。這也是為什么開源界更傾向于支持ubuntu的原因(kernel版本)
Docker并非適合所有應(yīng)用場(chǎng)景，Docker只能虛擬基于Linux的服務(wù)。Windows Azure 服務(wù)能夠運(yùn)行Docker實(shí)例，但到為止Windows服務(wù)還不能被虛擬化。
可能最大的障礙在于管理實(shí)例之間的交互。由于所有應(yīng)用組件被拆分到不同的容器中，所有的服務(wù)器需要以一致的方式彼此通信。這意味著任何人如果選擇復(fù)雜的基礎(chǔ)設(shè)施，那么必須掌握應(yīng)用編程接口管理以及集群工具，比如Swarm、Mesos或者Kubernets以確保機(jī)器按照預(yù)期運(yùn)轉(zhuǎn)并支持故障切換。
Docker在本質(zhì)上是一個(gè)附加系統(tǒng)。使用文件系統(tǒng)的不同層構(gòu)建一個(gè)應(yīng)用是有可能的。每個(gè)組件被添加到之前已經(jīng)創(chuàng)建的組件之上，可以比作為一個(gè)文件系統(tǒng)更明智。分層架構(gòu)帶來另一方面的效率提升，當(dāng)你重建存在變化的Docker鏡像時(shí)，不需要重建整個(gè)Docker鏡像，只需要重建變化的部分。
可能更為重要的是，Docker旨在用于彈性計(jì)算。每個(gè)Docker實(shí)例的運(yùn)營(yíng)生命周期有限，實(shí)例數(shù)量根據(jù)需求增減。在一個(gè)管理適度的系統(tǒng)中，這些實(shí)例生而平等，不再需要時(shí)便各自消亡了。
針對(duì)Docker環(huán)境存在的不足，意味著在開始部署Docker前需要考慮如下幾個(gè)問題。首先，Docker實(shí)例是無狀態(tài)的。這意味著它們不應(yīng)該承載任何交易數(shù)據(jù)，所有數(shù)據(jù)應(yīng)該保存在數(shù)據(jù)庫(kù)服務(wù)器中。
其次，開發(fā)Docker實(shí)例并不像創(chuàng)建一臺(tái)虛擬機(jī)、添加應(yīng)用然后克隆那樣簡(jiǎn)單。為成功創(chuàng)建并使用Docker基礎(chǔ)設(shè)施，管理員需要對(duì)系統(tǒng)管理的各個(gè)方面有一個(gè)全面的理解，包括Linux管理、編排及配置工具比如Puppet、Chef以及Salt。這些工具生來就基于命令行以及腳本。
Docker 原理
Docker核心解決的問題是利用LXC來實(shí)現(xiàn)類似VM的功能，從而利用更加節(jié)省的硬件資源提供給用戶更多的計(jì)算資源。同VM的方式不同, LXC 其并不是一套硬件虛擬化方法 - 無法歸屬到全虛擬化、部分虛擬化和半虛擬化中的任意一個(gè)，而是一個(gè)操作系統(tǒng)級(jí)虛擬化方法, 理解起來可能并不像VM那樣直觀。所以我們從虛擬化到docker要解決的問題出發(fā)，看看他是怎么滿足用戶虛擬化需求的。
用戶需要考慮虛擬化方法，尤其是硬件虛擬化方法，需要借助其解決的主要是以下4個(gè)問題:
• 隔離性 - 每個(gè)用戶實(shí)例之間相互隔離, 互不影響。硬件虛擬化方法給出的方法是VM, LXC給出的方法是container，更細(xì)一點(diǎn)是kernel namespace
• 可配額/可度量 - 每個(gè)用戶實(shí)例可以按需提供其計(jì)算資源，所使用的資源可以被計(jì)量。硬件虛擬化方法因?yàn)樘摂M了CPU, memory可以方便實(shí)現(xiàn), LXC則主要是利用cgroups來控制資源
• 移動(dòng)性 - 用戶的實(shí)例可以很方便地復(fù)制、移動(dòng)和重建。硬件虛擬化方法提供snapshot和image來實(shí)現(xiàn)，docker(主要)利用AUFS實(shí)現(xiàn)
• 安全性 - 這個(gè)話題比較大，這里強(qiáng)調(diào)是host主機(jī)的角度盡量保護(hù)container。硬件虛擬化的方法因?yàn)樘摂M化的水平比較高，用戶進(jìn)程都是在KVM等虛擬機(jī)容器中翻譯運(yùn)行的, 然而對(duì)于LXC, 用戶的進(jìn)程是lxc-start進(jìn)程的子進(jìn)程, 只是在Kernel的namespace中隔離的, 因此需要一些kernel的patch來保證用戶的運(yùn)行環(huán)境不會(huì)受到來自host主機(jī)的惡意入侵, dotcloud(主要是)利用kernel grsec patch解決的.
Linux Namespace
LXC所實(shí)現(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.每個(gè)namespace中的pid是有自己的pid=1的進(jìn)程(類似/sbin/init進(jìn)程)
2.每個(gè)namespace中的進(jìn)程只能影響自己的同一個(gè)namespace或子namespace中的進(jìn)程
3.因?yàn)?proc包含正在運(yùn)行的進(jìn)程，因此在container中的pseudo-filesystem的/proc目錄只能看到自己namespace中的進(jìn)程
4.因?yàn)閚amespace允許嵌套，父namespace可以影響子namespace的進(jìn)程，所以子namespace的進(jìn)程可以在父namespace中看到，但是具有不同的pid
正是因?yàn)橐陨系奶卣�，所有的LXC進(jìn)程在docker中的父進(jìn)程為docker進(jìn)程，每個(gè)lxc進(jìn)程具有不同的namespace。同時(shí)由于允許嵌套，因此可以很方便的實(shí)現(xiàn) LXC in LXC
net namespace
有了 pid namespace, 每個(gè)namespace中的pid能夠相互隔離，但是網(wǎng)絡(luò)端口還是共享host的端口。網(wǎng)絡(luò)隔離是通過netnamespace實(shí)現(xiàn)的，
每個(gè)net namespace有獨(dú)立的 network devices, IP addresses, IP routing tables, /proc/net 目錄。這樣每個(gè)container的網(wǎng)絡(luò)就能隔離開來。
LXC在此基礎(chǔ)上有5種網(wǎng)絡(luò)類型，docker默認(rèn)采用veth的方式將container中的虛擬網(wǎng)卡同host上的一個(gè)docker bridge連接在一起。
ipc namespace
container中進(jìn)程交互還是采用linux常見的進(jìn)程間交互方法(interprocess communication - IPC), 包括常見的信號(hào)量、消息隊(duì)列和共享內(nèi)存。然而同VM不同，container 的進(jìn)程間交互實(shí)際上還是host上具有相同pid namespace中的進(jìn)程間交互，因此需要在IPC資源申請(qǐng)時(shí)加入namespace信息 - 每個(gè)IPC資源有一個(gè)的 32bit ID。
mnt namespace
類似chroot，將一個(gè)進(jìn)程放到一個(gè)特定的目錄執(zhí)行。mnt namespace允許不同namespace的進(jìn)程看到的文件結(jié)構(gòu)不同，這樣每個(gè) namespace 中的進(jìn)程所看到的文件目錄就被隔離開了。同chroot不同，每個(gè)namespace中的container在/proc/mounts的信息只包含所在namespace的mount point。
uts namespace
UTS(“UNIX Time-sharing System”) namespace允許每個(gè)container擁有獨(dú)立的hostname和domain name,
使其在網(wǎng)絡(luò)上可以被視作一個(gè)獨(dú)立的節(jié)點(diǎn)而非Host上的一個(gè)進(jìn)程。
usernamespace
每個(gè)container可以有不同的 user 和 group id, 也就是說可以以container內(nèi)部的用戶在container內(nèi)部執(zhí)行程序而非Host上的用戶。
有了以上6種namespace從進(jìn)程、網(wǎng)絡(luò)、IPC、文件系統(tǒng)、UTS和用戶角度的隔離，一個(gè)container就可以對(duì)外展現(xiàn)出一個(gè)獨(dú)立計(jì)算機(jī)的能力，并且不同container從OS層面實(shí)現(xiàn)了隔離。
然而不同namespace之間資源還是相互競(jìng)爭(zhēng)的，仍然需要類似ulimit來管理每個(gè)container所能使用的資源 - LXC 采用的是cgroup。
Control Groups
cgroups 實(shí)現(xiàn)了對(duì)資源的配額和度量。 cgroups 的使用非常簡(jiǎn)單，提供類似文件的接口，在 /cgroup目錄下新建一個(gè)文件夾即可新建一個(gè)group，在此文件夾中新建task文件，并將pid寫入該文件，即可實(shí)現(xiàn)對(duì)該進(jìn)程的資源控制。具體的資源配置選項(xiàng)可以在該文件夾中新建子 subsystem ，{子系統(tǒng)前綴}.{資源項(xiàng)} 是典型的配置方法，
如memory.usage_in_bytes 就定義了該group 在subsystem memory中的一個(gè)內(nèi)存限制選項(xiàng)。
另外，cgroups中的 subsystem可以隨意組合，一個(gè)subsystem可以在不同的group中，也可以一個(gè)group包含多個(gè)subsystem - 也就是說一個(gè) subsystem。
關(guān)于術(shù)語(yǔ)定義
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)先級(jí)，因此具有較高CPU優(yōu)先級(jí)的進(jìn)程會(huì)更可能得到CPU運(yùn)算。
通過將參數(shù)寫入cpu.shares,即可定義改cgroup的CPU優(yōu)先級(jí) - 這里是一個(gè)相對(duì)權(quán)重，而非絕對(duì)值。當(dāng)然在cpu這個(gè)subsystem中還有其他可配置項(xiàng)，手冊(cè)中有詳細(xì)說明。
cpusets : cpusets 定義了有幾個(gè)CPU可以被這個(gè)group使用，或者哪幾個(gè)CPU可以供這個(gè)group使用。在某些場(chǎng)景下，單CPU綁定可以防止多核間緩存切換，從而提高效率
memory : 內(nèi)存相關(guān)的限制
blkio : block IO相關(guān)的統(tǒng)計(jì)和限制，byte/operation統(tǒng)計(jì)和限制(IOPS等)，讀寫速度限制等，但是這里主要統(tǒng)計(jì)的都是同步IO
net_cls，cpuacct ,devices ,freezer 等其他可管理項(xiàng)。
Linux 容器
借助于namespace的隔離機(jī)制和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é), 提供了如下的組件大大簡(jiǎn)化了用戶的開發(fā)和使用工作:
• The liblxc library
• Several language bindings (python3, lua and Go)
• A set of standard tools to control the containers
• Container templates
LXC 旨在提供一個(gè)共享kernel的 OS 級(jí)虛擬化方法，在執(zhí)行時(shí)不用重復(fù)加載Kernel, 且container的kernel與host共享，因此可以大大加快container的 啟動(dòng)過程，并顯著減少內(nèi)存消耗。在實(shí)際測(cè)試中，基于LXC的虛擬化方法的IO和CPU性能幾乎接近 baremetal 的性能, 大多數(shù)數(shù)據(jù)有相比 Xen具有優(yōu)勢(shì)。當(dāng)然對(duì)于KVM這種也是通過Kernel進(jìn)行隔離的方式, 性能優(yōu)勢(shì)或許不是那么明顯, 主要還是內(nèi)存消耗和啟動(dòng)時(shí)間上的差異。在參考文獻(xiàn)中提到了利用iozone進(jìn)行 Disk IO吞吐量測(cè)試KVM反而比LXC要快，而且筆者在device mapping driver下重現(xiàn)同樣case的實(shí)驗(yàn)中也確實(shí)能得到如此結(jié)論。參考文獻(xiàn)從網(wǎng)絡(luò)虛擬化中虛擬路由的場(chǎng)景(網(wǎng)絡(luò)IO和CPU角度)比較了KVM和LXC, 得到結(jié)論是KVM在性能和隔離性的平衡上比LXC更優(yōu)秀 - KVM在吞吐量上略差于LXC, 但CPU的隔離可管理項(xiàng)比LXC更明確。
關(guān)于CPU, DiskIO, network IO 和 memory 在KVM和LXC中的比較還是需要更多的實(shí)驗(yàn)才能得出可信服的結(jié)論。
AUFS
Docker對(duì)container的使用基本是建立在LXC基礎(chǔ)之上的，然而LXC存在的問題是難以移動(dòng) - 難以通過標(biāo)準(zhǔn)化的模板制作、重建、復(fù)制和移動(dòng) container。
在以VM為基礎(chǔ)的虛擬化手段中，有image和snapshot可以用于VM的復(fù)制、重建以及移動(dòng)的功能。想要通過container來實(shí)現(xiàn)快速的大規(guī)模部署和更新, 這些功能不可或缺。
Docker 正是利用AUFS來實(shí)現(xiàn)對(duì)container的快速更新 - 在docker0.7中引入了storage driver, 支持AUFS, VFS, device mapper, 也為BTRFS以及ZFS引入提供了可能。但除了AUFS都未經(jīng)過dotcloud的線上使用，因此我們還是從AUFS的角度介紹。
AUFS (AnotherUnionFS) 是一種 Union FS, 簡(jiǎn)單來說就是支持將不同目錄掛載到同一個(gè)虛擬文件系統(tǒng)下(unite several directories into a single virtual filesystem)的文件系統(tǒng), 更進(jìn)一步地, AUFS支持為每一個(gè)成員目錄(AKA branch)設(shè)定'readonly', 'readwrite' 和 'whiteout-able' 權(quán)限, 同時(shí)AUFS里有一個(gè)類似
分層的概念, 對(duì) readonly 權(quán)限的branch可以邏輯上進(jìn)行修改(增量地, 不影響readonly部分的)。通常 Union FS有兩個(gè)用途, 一方面可以實(shí)現(xiàn)不借助 LVM， RAID 將多個(gè)disk和掛在到一個(gè)目錄下, 另一個(gè)更常用的就是將一個(gè)readonly的branch和一個(gè)writeable的branch聯(lián)合在一起，Live CD正是基于此可以允許在 OS image 不變的基礎(chǔ)上允許用戶在其上進(jìn)行一些寫操作。Docker在AUFS上構(gòu)建的container image也正是如此，接下來我們從啟動(dòng)container中的linux為例介紹docker在AUFS特性的運(yùn)用。
典型的Linux啟動(dòng)到運(yùn)行需要兩個(gè)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)目錄和文件。
