深入淺出Docker（一）：Docker核心技術(shù)預(yù)覽
原文鏈接：http://www.infoq.com/cn/articles/docker-core-technology-preview/
【編者按】Docker是PaaS供應(yīng)商dotCloud開(kāi)源的一個(gè)基于LXC 的高級(jí)容器引擎，源代碼托管在 GitHub 上,
基于Go語(yǔ)言開(kāi)發(fā)并遵從Apache
2.0協(xié)議開(kāi)源。Docker提供了一種在安全、可重復(fù)的環(huán)境中自動(dòng)部署軟件的方式，它的出現(xiàn)拉開(kāi)了基于云計(jì)算平臺(tái)發(fā)布產(chǎn)品方式的變革序幕。為了更好的促
進(jìn)Docker在國(guó)內(nèi)的發(fā)展以及傳播，我們決定開(kāi)設(shè)《深入淺出Docker》
專(zhuān)欄，邀請(qǐng)Docker相關(guān)的布道師、開(kāi)發(fā)人員、技術(shù)專(zhuān)家來(lái)講述Docker的各方面內(nèi)容，讓讀者對(duì)Docker有更深入的了解，并且能夠積極投入到新技
術(shù)的討論和實(shí)踐中。另外，歡迎加入InfoQ Docker技術(shù)交流群交流Docker的最佳實(shí)踐，QQ群號(hào)：124378115。
1. 背景
1.1. 由PaaS到Container
2013年2月，前Gluster的CEO Ben Golub和dotCloud的CEO Solomon
Hykes坐在一起聊天時(shí)，Solomon談到想把dotCloud內(nèi)部使用的Container容器技術(shù)單獨(dú)拿出來(lái)開(kāi)源，然后圍繞這個(gè)技術(shù)開(kāi)一家新公司
提供技術(shù)支持。28歲的Solomon在使用Python開(kāi)發(fā)dotCloud的PaaS云時(shí)發(fā)現(xiàn)，使用 LXC(Linux Container)
技術(shù)可以打破產(chǎn)品發(fā)布過(guò)程中應(yīng)用開(kāi)發(fā)工程師和系統(tǒng)工程師兩者之間無(wú)法輕松協(xié)作發(fā)布產(chǎn)品的難題。這個(gè)Container容器技術(shù)可以把開(kāi)發(fā)者從日常部署應(yīng)用
的繁雜工作中解脫出來(lái)，讓開(kāi)發(fā)者能專(zhuān)心寫(xiě)好程序；從系統(tǒng)工程師的角度來(lái)看也是一樣，他們迫切需要從各種混亂的部署文檔中解脫出來(lái)，讓系統(tǒng)工程師專(zhuān)注在應(yīng)用
的水平擴(kuò)展、穩(wěn)定發(fā)布的解決方案上。他們?cè)缴钊虢徽?，越覺(jué)得這是一次云技術(shù)的變革，緊接著在2013年3月Docker
0.1發(fā)布，拉開(kāi)了基于云計(jì)算平臺(tái)發(fā)布產(chǎn)品方式的變革序幕。
1.2 Docker簡(jiǎn)介
Docker 是 Docker.Inc 公司開(kāi)源的一個(gè)基于 LXC技術(shù)之上構(gòu)建的Container容器引擎， 源代碼托
管在 GitHub 上, 基于Go語(yǔ)言并遵從Apache2.0協(xié)議開(kāi)源。 Docker在2014年6月召開(kāi)DockerConf
2014技術(shù)大會(huì)吸引了IBM、Google、RedHat等業(yè)界知名公司的關(guān)注和技術(shù)支持，無(wú)論是從 GitHub
上的代碼活躍度，還是Redhat宣布在RHEL7中正式支持Docker, 都給業(yè)界一個(gè)信號(hào)，這是一項(xiàng)創(chuàng)新型的技術(shù)解決方案。 就連 Google 公司的 Compute Engine 也支持 docker 在其之上運(yùn)行, 國(guó)內(nèi)“BAT”先鋒企業(yè)百度Baidu App Engine(BAE)平臺(tái)也是以Docker作為其PaaS云基礎(chǔ)。
Docker產(chǎn)生的目的就是為了解決以下問(wèn)題:
1) 環(huán)境管理復(fù)雜:
從各種OS到各種中間件再到各種App，一款產(chǎn)品能夠成功發(fā)布，作為開(kāi)發(fā)者需要關(guān)心的東西太多，且難于管理，這個(gè)問(wèn)題在軟件行業(yè)中普遍存在并需要直接面
對(duì)。Docker可以簡(jiǎn)化部署多種應(yīng)用實(shí)例工作，比如Web應(yīng)用、后臺(tái)應(yīng)用、數(shù)據(jù)庫(kù)應(yīng)用、大數(shù)據(jù)應(yīng)用比如Hadoop集群、消息隊(duì)列等等都可以打包成一個(gè)
Image部署。如圖所示：
2) 云計(jì)算時(shí)代的到來(lái): AWS的成功, 引導(dǎo)開(kāi)發(fā)者將應(yīng)用轉(zhuǎn)移到云上, 解決了硬件管理的問(wèn)題，然而軟件配置和管理相關(guān)的問(wèn)題依然存在 (AWS cloudformation是這個(gè)方向的業(yè)界標(biāo)準(zhǔn), 樣例模板可參考這里)。Docker的出現(xiàn)正好能幫助軟件開(kāi)發(fā)者開(kāi)闊思路，嘗試新的軟件管理方法來(lái)解決這個(gè)問(wèn)題。
3) 虛擬化手段的變化:
云時(shí)代采用標(biāo)配硬件來(lái)降低成本，采用虛擬化手段來(lái)滿足用戶按需分配的資源需求以及保證可用性和隔離性。然而無(wú)論是KVM還是Xen，在 Docker
看來(lái)都在浪費(fèi)資源，因?yàn)橛脩粜枰氖歉咝н\(yùn)行環(huán)境而非OS, GuestOS既浪費(fèi)資源又難于管理, 更加輕量級(jí)的LXC更加靈活和快速。如圖所示：
4) LXC的便攜性: LXC在 Linux 2.6 的 Kernel
里就已經(jīng)存在了，但是其設(shè)計(jì)之初并非為云計(jì)算考慮的，缺少標(biāo)準(zhǔn)化的描述手段和容器的可便攜性，決定其構(gòu)建出的環(huán)境難于分發(fā)和標(biāo)準(zhǔn)化管理(相對(duì)于KVM之類(lèi)
image和snapshot的概念)。Docker就在這個(gè)問(wèn)題上做出了實(shí)質(zhì)性的創(chuàng)新方法。
1.3 Docker的Hello World
以Fedora 20作為主機(jī)為例，直接安裝docker-io：
$ sudo yum -y install docker-io
啟動(dòng)docker后臺(tái)Daemon:
$ sudo systemctl start docker
跑我們第一個(gè)Hello World容器：
$ sudo docker run -i -t fedora /bin/echo hello world Hello world
可以看到在運(yùn)行命令行后的下一行會(huì)打印出經(jīng)典的Hello World字符串。
2. 核心技術(shù)預(yù)覽
Docker核心是一個(gè)操作系統(tǒng)級(jí)虛擬化方法, 理解起來(lái)可能并不像VM那樣直觀。我們從虛擬化方法的四個(gè)方面：隔離性、可配額/可度量、便攜性、安全性來(lái)詳細(xì)介紹Docker的技術(shù)細(xì)節(jié)。
2.1. 隔離性: Linux Namespace(ns)
每個(gè)用戶實(shí)例之間相互隔離, 互不影響。 一般的硬件虛擬化方法給出的方法是VM，而LXC給出的方法是container，更細(xì)一點(diǎn)講就是kernel namespace。其中pid、net、ipc、mnt、uts、user等namespace將container的進(jìn)程、網(wǎng)絡(luò)、消息、文件系統(tǒng)、UTS("UNIX Time-sharing System")和用戶空間隔離開(kāi)。
1) pid namespace
不同用戶的進(jìn)程就是通過(guò)pid namespace隔離開(kāi)的，且不同 namespace
中可以有相同pid。所有的LXC進(jìn)程在docker中的父進(jìn)程為docker進(jìn)程，每個(gè)lxc進(jìn)程具有不同的namespace。同時(shí)由于允許嵌套，因
此可以很方便的實(shí)現(xiàn) Docker in Docker。
2) net namespace
有了 pid namespace, 每個(gè)namespace中的pid能夠相互隔離，但是網(wǎng)絡(luò)端口還是共享host的端口。網(wǎng)絡(luò)隔離是通過(guò)net
namespace實(shí)現(xiàn)的， 每個(gè)net namespace有獨(dú)立的 network devices, IP addresses, IP
routing tables, /proc/net
目錄。這樣每個(gè)container的網(wǎng)絡(luò)就能隔離開(kāi)來(lái)。docker默認(rèn)采用veth的方式將container中的虛擬網(wǎng)卡同host上的一個(gè)
docker bridge: docker0連接在一起。
3) ipc namespace
container中進(jìn)程交互還是采用Linux常見(jiàn)的進(jìn)程間交互方法(interprocess communication - IPC),
包括常見(jiàn)的信號(hào)量、消息隊(duì)列和共享內(nèi)存。然而同 VM 不同的是，container 的進(jìn)程間交互實(shí)際上還是host上具有相同pid
namespace中的進(jìn)程間交互，因此需要在IPC資源申請(qǐng)時(shí)加入namespace信息 - 每個(gè)IPC資源有一個(gè)唯一的 32 位 ID。
4) mnt namespace
類(lèi)似chroot，將一個(gè)進(jìn)程放到一個(gè)特定的目錄執(zhí)行。mnt namespace允許不同namespace的進(jìn)程看到的文件結(jié)構(gòu)不同，這樣每個(gè)
namespace
中的進(jìn)程所看到的文件目錄就被隔離開(kāi)了。同chroot不同，每個(gè)namespace中的container在/proc/mounts的信息只包含所在
namespace的mount point。
5) 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)程。
6) user namespace
每個(gè)container可以有不同的 user 和 group id, 也就是說(shuō)可以在container內(nèi)部用container內(nèi)部的用戶執(zhí)行程序而非Host上的用戶。
2.2 可配額/可度量 - Control Groups (cgroups)
cgroups 實(shí)現(xiàn)了對(duì)資源的配額和度量。 cgroups 的使用非常簡(jiǎn)單，提供類(lèi)似文件的接口，在
/cgroup目錄下新建一個(gè)文件夾即可新建一個(gè)group，在此文件夾中新建task文件，并將pid寫(xiě)入該文件，即可實(shí)現(xiàn)對(duì)該進(jìn)程的資源控制。
groups可以限制blkio、cpu、cpuacct、cpuset、devices、freezer、memory、net_cls、ns九大子系
統(tǒng)的資源，以下是每個(gè)子系統(tǒng)的詳細(xì)說(shuō)明：
-
blkio 這個(gè)子系統(tǒng)設(shè)置限制每個(gè)塊設(shè)備的輸入輸出控制。例如:磁盤(pán)，光盤(pán)以及usb等等。
-
cpu 這個(gè)子系統(tǒng)使用調(diào)度程序?yàn)閏group任務(wù)提供cpu的訪問(wèn)。
-
cpuacct 產(chǎn)生cgroup任務(wù)的cpu資源報(bào)告。
-
cpuset 如果是多核心的cpu，這個(gè)子系統(tǒng)會(huì)為cgroup任務(wù)分配單獨(dú)的cpu和內(nèi)存。
-
devices 允許或拒絕cgroup任務(wù)對(duì)設(shè)備的訪問(wèn)。
-
freezer 暫停和恢復(fù)cgroup任務(wù)。
-
memory 設(shè)置每個(gè)cgroup的內(nèi)存限制以及產(chǎn)生內(nèi)存資源報(bào)告。
-
net_cls 標(biāo)記每個(gè)網(wǎng)絡(luò)包以供cgroup方便使用。
-
ns 名稱空間子系統(tǒng)。
以上九個(gè)子系統(tǒng)之間也存在著一定的關(guān)系.詳情請(qǐng)參閱官方文檔。
2.3 便攜性: AUFS
AUFS (AnotherUnionFS) 是一種 Union FS, 簡(jiǎn)單來(lái)說(shuō)就是支持將不同目錄掛載到同一個(gè)虛擬文件系統(tǒng)下(unite
several directories into a single virtual filesystem)的文件系統(tǒng), 更進(jìn)一步的理解,
AUFS支持為每一個(gè)成員目錄(類(lèi)似Git Branch)設(shè)定readonly、readwrite 和 whiteout-able 權(quán)限, 同時(shí)
AUFS 里有一個(gè)類(lèi)似分層的概念, 對(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)行一些寫(xiě)操作。Docker 在 AUFS 上構(gòu)建的
container image 也正是如此，接下來(lái)我們從啟動(dòng) container 中的 Linux 為例來(lái)介紹 docker
對(duì)AUFS特性的運(yùn)用。
典型的啟動(dòng)Linux運(yùn)行需要兩個(gè)FS: bootfs + rootfs:
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)目錄和文件。
對(duì)于不同的Linux發(fā)行版, bootfs基本是一致的, 但rootfs會(huì)有差別, 因此不同的發(fā)行版可以公用bootfs 如下圖:
典型的Linux在啟動(dòng)后，首先將 rootfs 設(shè)置為 readonly, 進(jìn)行一系列檢查, 然后將其切換為 "readwrite"
供用戶使用。在Docker中，初始化時(shí)也是將 rootfs 以readonly方式加載并檢查，然而接下來(lái)利用 union mount
的方式將一個(gè) readwrite 文件系統(tǒng)掛載在 readonly 的rootfs之上，并且允許再次將下層的 FS(file system)
設(shè)定為readonly 并且向上疊加, 這樣一組readonly和一個(gè)writeable的結(jié)構(gòu)構(gòu)成一個(gè)container的運(yùn)行時(shí)態(tài),
每一個(gè)FS被稱作一個(gè)FS層。如下圖:
得益于AUFS的特性, 每一個(gè)對(duì)readonly層文件/目錄的修改都只會(huì)存在于上層的writeable層中。這樣由于不存在競(jìng)爭(zhēng), 多個(gè)container可以共享readonly的FS層。 所以Docker將readonly的FS層稱作 "image" - 對(duì)于container而言整個(gè)rootfs都是read-write的，但事實(shí)上所有的修改都寫(xiě)入最上層的writeable層中, image不保存用戶狀態(tài)，只用于模板、新建和復(fù)制使用。
上層的image依賴下層的image，因此Docker中把下層的image稱作父image，沒(méi)有父image的image稱作base
image。因此想要從一個(gè)image啟動(dòng)一個(gè)container，Docker會(huì)先加載這個(gè)image和依賴的父images以及base
image，用戶的進(jìn)程運(yùn)行在writeable的layer中。所有parent image中的數(shù)據(jù)信息以及
ID、網(wǎng)絡(luò)和lxc管理的資源限制等具體container的配置，構(gòu)成一個(gè)Docker概念上的container。如下圖:
2.4 安全性: AppArmor, SELinux, GRSEC
安全永遠(yuǎn)是相對(duì)的，這里有三個(gè)方面可以考慮Docker的安全特性:
-
由kernel namespaces和cgroups實(shí)現(xiàn)的Linux系統(tǒng)固有的安全標(biāo)準(zhǔn);
-
Docker Deamon的安全接口;
-
Linux本身的安全加固解決方案,類(lèi)如AppArmor, SELinux;
由于安全屬于非常具體的技術(shù)，這里不在贅述，請(qǐng)直接參閱Docker官方文檔。
3. 最新子項(xiàng)目介紹
我們?cè)賮?lái)看看Docker社區(qū)還有哪些子項(xiàng)目值得我們?nèi)ズ煤醚芯亢蛯W(xué)習(xí)。基于這個(gè)目的，我把有趣的核心項(xiàng)目給大家羅列出來(lái)，讓熱心的讀者能快速跟進(jìn)自己感興趣的項(xiàng)目:
-
Libswarm，是Solomon Hykes (Docker的CTO) 在DockerCon
2014峰會(huì)上向社區(qū)介紹的新“樂(lè)高積木”工具:
它是用來(lái)統(tǒng)一分布式系統(tǒng)的網(wǎng)絡(luò)接口的API。Libswarm要解決的問(wèn)題是，基于Docker構(gòu)建的分布式應(yīng)用已經(jīng)催生了多個(gè)基于Docker的服務(wù)發(fā)
現(xiàn)(Serivce Discovery)項(xiàng)目，例如etcd, fleet, geard, mesos, shipyard,
serf等等，每一套解決方案都有自己的通訊協(xié)議和使用方法，使用其中的任意一款都會(huì)局限在某一個(gè)特定的技術(shù)范圍內(nèi)。所以Docker的CTO就想用
libswarm暴露出通用的API接口給分布式系統(tǒng)使用，打破既定的協(xié)議限制。目前項(xiàng)目還在早期發(fā)展階段，值得參與。 -
Libchan，是一個(gè)底層的網(wǎng)絡(luò)庫(kù)，為上層 Libswarm
提供支持。相當(dāng)于給Docker加上了ZeroMQ或RabbitMQ，這里自己實(shí)現(xiàn)網(wǎng)絡(luò)庫(kù)的好處是對(duì)Docker做了特別優(yōu)化，更加輕量級(jí)。一般開(kāi)發(fā)者
不會(huì)直接用到它，大家更多的還是使用Libswarm來(lái)和容器交互。喜歡底層實(shí)現(xiàn)的網(wǎng)絡(luò)工程師可能對(duì)此感興趣，不妨一看。 -
Libcontainer，Docker技術(shù)的核心部分，單獨(dú)列出來(lái)也是因?yàn)檫@一塊的功能相對(duì)獨(dú)立，功能代碼的迭代升級(jí)非?？臁Ｏ肓私釪ocker最新的支持特性應(yīng)該多關(guān)注這個(gè)模塊。
4. 總結(jié)
Docker社區(qū)一直在面對(duì)技術(shù)挑戰(zhàn)，從容地給出自己的解決方案。云計(jì)算發(fā)展至今，有很多重要的問(wèn)題沒(méi)有得到妥善解決，Docker正在嘗試讓主流
廠商接受并應(yīng)用它。至此，以上Docker技術(shù)的預(yù)覽到此告一段落，筆者也希望讀者能結(jié)合自己的實(shí)際情況，嘗試使用Docker技術(shù)。因?yàn)橹挥性谟H自體會(huì)
的基礎(chǔ)之上，像Docker這樣的云技術(shù)才會(huì)產(chǎn)生更大的價(jià)值。
5. 作者簡(jiǎn)介
肖德時(shí), Red Hat Engineering Service/HSS 內(nèi)部工具組Team
Leader，Nodejs開(kāi)源項(xiàng)目nodejs-cantas Lead Developer。擅長(zhǎng)企業(yè)內(nèi)部工具的設(shè)計(jì)以及實(shí)現(xiàn)。開(kāi)源課程Rails
Starter的發(fā)起人。rubygem:
lazy_high_charts的Maintainer。twitter賬號(hào)：xds2000，郵箱：xiaods@gmail.com
6. 參考文獻(xiàn):
感謝郭蕾對(duì)本文的審校。