詳解構(gòu)建微服務(wù)的開源技術(shù)之 Docker
一、前言
Docker 是最近在云計(jì)算領(lǐng)域出現(xiàn)的新技術(shù)。目前，Docker 和以其為代表的容器技術(shù)的熱度已經(jīng)改過了之前的 OpenStack。Docker 以及其所代表的容器技術(shù)的流行，即使因?yàn)檐浖夹g(shù)的進(jìn)步，更是由于其符合云計(jì)算對(duì)軟件領(lǐng)域所帶來新思想。在如今的互聯(lián)網(wǎng)和企業(yè)應(yīng)用開發(fā)領(lǐng)域，微服務(wù)和 DevOps 是兩個(gè)思想頗為深入人心。而 Docker 技術(shù)的出現(xiàn)和其對(duì)整個(gè)容器技術(shù)及其生態(tài)圈發(fā)展的促進(jìn)，解決了這個(gè)微服務(wù)和 DevOps 這兩個(gè)思想實(shí)踐中的很多難題，使得前面兩種思想大規(guī)模地實(shí)現(xiàn)成為了可能。所以，我們有必要地深入了解一下 Docker 這個(gè)技術(shù)，看看它會(huì)對(duì)云計(jì)算時(shí)代的軟件開發(fā)產(chǎn)生什么樣的影響。
本文將介紹如下內(nèi)容
- 什么是容器技術(shù)
- 什么是 Docker
- Docker 是如何實(shí)現(xiàn)的
- 為什么要使用 Docker
至于 Docker 的用法，不在這里做介紹。Docker 的入門使用，可以前往 Docker 官網(wǎng)。各種高級(jí)用法、技巧、經(jīng)驗(yàn)，可以前往技術(shù)網(wǎng)站 CSDN、InfoQ 和 CoreOS、Centurylink Labs 等這些使用 Docker 的云計(jì)算廠商的網(wǎng)站。
二、容器技術(shù)簡(jiǎn)介
容器技術(shù)有時(shí)會(huì)被稱為輕量化虛擬技術(shù)。但不同于基于 Hypervisor 的傳統(tǒng)虛擬化技術(shù)，容器技術(shù)并不會(huì)虛擬硬件。容器本身和容器內(nèi)的進(jìn)程都是運(yùn)行在宿主 Linux 系統(tǒng)的內(nèi)核之上。但與直接運(yùn)行的進(jìn)程不同，運(yùn)行在容器內(nèi)的進(jìn)程會(huì)被隔離和約束。從而以直接運(yùn)行的高效實(shí)現(xiàn)了虛擬技術(shù)的大部分效果。
容器技術(shù)的歷史
容器技術(shù)并不是一個(gè)新鮮事物，早在1979年出現(xiàn)的在 Unix 系統(tǒng)中的 chroot 便是容器技術(shù)的雛形。而隨后出現(xiàn)的 BSD Jail、Solaris Containers 和 OpenVZ 都算是容器技術(shù)的先驅(qū)。但容器技術(shù)開始普及卻是在2007年，這一年 Google 貢獻(xiàn)出 cgroups，并且從 2.6.4 開始，Linux 內(nèi)核包含了這一組件，隨后容器技術(shù)開始逐漸普及。但容器技術(shù)真正大放異彩則要等到2013年 Docker 0.10 版本發(fā)布。
三、Docker 簡(jiǎn)介
在 Docker 出現(xiàn)之前，不僅 Google 大量使用容器技術(shù)，國(guó)內(nèi)的如淘寶也使用容器技術(shù)搭建了自己的應(yīng)用平臺(tái)。影響力最大的開源 PaaS 解決方案 CloudFoundry，也在使用自己的容器解決方案 Warden。而 Docker 發(fā)布之后，因其極有可能成為未來企業(yè)應(yīng)用、互聯(lián)網(wǎng)應(yīng)用和云計(jì)算應(yīng)用的開發(fā)、部署的中心角色，所以得到了幾乎所有的業(yè)界大佬的追捧，Google、VMware、微軟、RedHat 等等都已全力推動(dòng) Docker 技術(shù)的發(fā)展。同時(shí)，圍繞 Docker，出現(xiàn)了一系列以 CoreOS 為代表的新技術(shù)。
Docker 的出現(xiàn)并非創(chuàng)造了一個(gè)新的容器技術(shù)，而是在 LXC (LinuX Container)注1、cgroups、namespaces 技術(shù)之上所構(gòu)建的一種技術(shù)：
- Docker 簡(jiǎn)化了容器的運(yùn)行：它通過一個(gè)簡(jiǎn)單的命令就能夠運(yùn)行起一個(gè)容器docker run [params] [image] [command (optional)]
- Docker 簡(jiǎn)化了容器鏡像的構(gòu)建和分發(fā)：Docker 提供了Dockerfile和docker commit兩種方式構(gòu)建鏡像，并且提供了 Docker image registry 機(jī)制以保存和分發(fā)鏡像
形象地解釋
打一個(gè)比方，集裝箱（容器）對(duì)于遠(yuǎn)洋運(yùn)輸（應(yīng)用運(yùn)行）來說十分重要。集裝箱（容器）能保護(hù)貨物（應(yīng)用），讓其不會(huì)相互碰撞（應(yīng)用沖突）而損壞，也能保障當(dāng)一些危險(xiǎn)貨物發(fā)生規(guī)模不大的爆炸（應(yīng)用崩潰）時(shí)不會(huì)波及其它貨物（應(yīng)用）但是把貨物（應(yīng)用）裝載在集裝箱（容器）中并不是一件簡(jiǎn)單的事情。而出色的碼頭工人（Docker）的出現(xiàn)解決了這一問題。它（Docker）使得貨物裝載到集裝箱（容器）這一過程變得輕而易舉。對(duì)于遠(yuǎn)洋運(yùn)輸（應(yīng)用運(yùn)行）而言，用多艘小貨輪（虛擬機(jī)）代替原來的大貨輪（實(shí)體機(jī)）也能保證貨物（應(yīng)用）彼此之間的安全，但是和集裝箱（容器）比，成本過高，但適合運(yùn)輸某些重要貨物（應(yīng)用）。
四、Docker 的組成
Docker 主要有 Docker Hub 和 Docker 引擎組成。前者是Docker 官方提供的容器鏡像倉庫；后者運(yùn)行在宿主機(jī)上，可分為服務(wù)器端和客戶端兩部分。服務(wù)器端負(fù)責(zé)構(gòu)建、運(yùn)行和分發(fā) Docker 容器等重要工作，客戶端負(fù)責(zé)接收用戶的命令和服務(wù)程序進(jìn)行通信。
除了這兩部分，Dockerfile 也是不得不提的，它雖然不能算作一個(gè)獨(dú)立的組件，但是卻是 Docker 中很重要的部分。通過 Dockerfile，技術(shù)人員可以創(chuàng)建自己的 Docker 容器鏡像。Dockerfile 起到了連接開發(fā)與運(yùn)維的橋梁的作用，非常符合現(xiàn)在 DevOps 的潮流。
Docker Hub
Docker Hub 是 Docker 官方所提供的一個(gè)鏡像倉庫。在運(yùn)行 Docker 容器或構(gòu)建自己的容器鏡像時(shí)，都會(huì)直接或間接地使用到 Docker Hub 中的鏡像。
Docker Engine
Docker Engine 承載了 Docker 容器在宿主機(jī)上運(yùn)行啟停、Docker 鏡像的構(gòu)建等功能等功能。是我們接觸最多的組件。接下來簡(jiǎn)單介紹一下 Docker 常見的命令：
- run運(yùn)行一個(gè)容器，如果鏡像不存在則先下載。常用參數(shù)有-d、-t、-i等
- pull下載容器鏡像
- start/stop啟動(dòng)/停止一個(gè) Docker 容器
- rm刪除一個(gè)容器
- rmi刪除一個(gè)容器鏡像
- commit將容器中的修改提交至鏡像中
- logs顯示容器運(yùn)行的控制臺(tái)輸出
- build從 Dockerfile 構(gòu)建一個(gè)鏡像
- inspect顯示容器運(yùn)行參數(shù)，通過輸入一個(gè) JSON 格式的值來顯示相應(yīng)的結(jié)果
- images顯示當(dāng)前宿主機(jī)上的所有鏡像
Dockerfile
通過編寫 Dockerfile，我們可以構(gòu)建自己的鏡像。看一個(gè) Dockerfile 的例子：
- FROM dockerfile/java:oracle-java8
- MAINTAINER Lifan Yang <yanglifan@gmail.com>
- ADD device.jar /device.jar
- EXPOSE 8080
- ENTRYPOINT java -jar /device.jar
FROM指令的意思是說你的鏡像是基于一個(gè)什么鏡像。dockerfile/java:oracle-java8是一個(gè)鏡像的名字，它也是有一個(gè)基礎(chǔ)鏡像狗狗見。其實(shí)它也是基于例如 Ubuntu、CentOS 這樣的 Base 鏡像。關(guān)于 Base 鏡像的制作方法，Docker 官網(wǎng)上有介紹，需要專門的工具，這里不再作介紹。MAINTAINER指令是可選的。ADD指令是用來將一個(gè)文件或目錄添加到 Docker 鏡像中，前面是源文件，后面是目標(biāo)文件。源文件必須使用相對(duì)路徑。EXPOSE指令用來容器間暴露端口，其指定的端口也會(huì)被-P參數(shù)映射給宿主機(jī)的一個(gè)隨機(jī)端口上。ENTRYPOINT可以用來指定運(yùn)行 Docker 容器時(shí)，在容器中執(zhí)行的命令是什么。如果需要運(yùn)行多個(gè)命令，可以通過 Supervisor 來執(zhí)行。
除了這些指令，還有一些常用的指令。例如，用于在構(gòu)建過程中執(zhí)行命令的CMD指令；用于在容器中設(shè)置環(huán)境變量的ENV指令。詳細(xì)請(qǐng)見 Dockerfile Reference
#p#
五、Docker 的實(shí)現(xiàn)
接下來要介紹 Docker 所使用的幾個(gè)重要技術(shù)：namespaces、cgroups、LXC 和 AUFS。
namespaces
Linux 容器通過 Kernel 的 namespaces 技術(shù)，為一個(gè)或一組進(jìn)程創(chuàng)建獨(dú)立的pid、net等 namespaces，從而與其它進(jìn)程相互隔離。下面將介紹 namespaces 都會(huì)對(duì)哪些資源進(jìn)行分組控制以實(shí)現(xiàn)相互隔離：
pidnamespace
不同容器中進(jìn)程是通過 pid namespace 隔離開的，且不同容器中可以有相同 pid。具有以下特征:
- 每個(gè) namespace 中的 pid 是有自己的 pid=1 的初始進(jìn)程
- 每個(gè) namespace 中的進(jìn)程只能影響自己的同一個(gè) namespace 或子 namespace 中的進(jìn)程
- 因?yàn)?proc包含正在運(yùn)行的進(jìn)程，因此在容器中的/proc目錄只能看到自己 namespace 中的進(jìn)程
- 因?yàn)?namespace 允許嵌套，父 namespace 可以影響子 namespace 的進(jìn)程，所以子 namespace 的進(jìn)程可以在父 namespace 中看到，但是具有不同的 pid
netnamespace
如果僅僅隔離了進(jìn)程空間，還是會(huì)有問題。比如如果你在多個(gè)容器中運(yùn)行 Apache 服務(wù)器，那只能有一個(gè)服務(wù)器使用 80 端口。對(duì)此你有兩個(gè)選擇，讓每個(gè) Apache 服務(wù)器使用不同的端口，或者隔離網(wǎng)絡(luò)空間。
netnamespace 使得每個(gè)容器都有自己的loloopback 接口。同時(shí)，還有一個(gè)通常被命名為eth0的網(wǎng)絡(luò)接口，通過這個(gè)接口，容器可以和 host 或其它容器進(jìn)行通信。eth0interface 會(huì)被分配一個(gè) 172.17.0.XXX 的 IP 地址，容器之間可以通過這個(gè) IP 地址相互通信。
同時(shí)，容器的這個(gè)eth0網(wǎng)卡在 Host 中的名字是一個(gè)類似vethdfb7的略顯古怪的名字。這個(gè)網(wǎng)卡會(huì)和docker0網(wǎng)卡橋接在一起。
ipcnamespace
ipcnamepace 對(duì)于不熟悉 Unix 的人（包括之前的我）吸引力不是很大。畢竟，現(xiàn)在進(jìn)程之間的通信多數(shù)是通過網(wǎng)絡(luò)實(shí)現(xiàn)的。但實(shí)際上，Unixipc有著十分廣泛的應(yīng)用，比如管道就是ipc的一種。對(duì)ipc就不做過多介紹了，總之 Linux Kernel namespaces 可以讓不同容器的ipc相互隔離。
mntnamespace
如名所示，mntnamespace 是處理掛載點(diǎn)的。mntnamespace 可以使不同容器擁有不同的掛載的文件系統(tǒng)和 root 目錄。在一個(gè)mntnamespace 掛載的文件系統(tǒng)只能被同一個(gè) namespace 里的進(jìn)程所見。
utsnamespace
utsnamespace 用于控制 hostname 的隔離。
有了以上幾種隔離，一個(gè)容器就可以對(duì)外展現(xiàn)出一個(gè)獨(dú)立計(jì)算機(jī)的能力，并且不同容器內(nèi)的資源在操作系統(tǒng)層面實(shí)現(xiàn)了隔離。 然而不同 namespace 之間資源還是相互競(jìng)爭(zhēng)的，仍然需要類似 ulimit 來管理每個(gè)容器所能使用的資源 - Docker 采用的是 cgroup。
參考文獻(xiàn)
1 http://blog.dotcloud.com/under-the-hood-linux-kernels-on-dotcloud-part
cgroups
namespaces 對(duì)進(jìn)程分組以實(shí)現(xiàn)資源隔離，但這隔離還是不夠的。一個(gè)進(jìn)程可以通過占用過度的硬件資源的方式去影響另一個(gè)分組中的進(jìn)程。所以，要想實(shí)現(xiàn)完善的資源隔離，不僅要對(duì)資源分組，還要能對(duì)這一組內(nèi)的進(jìn)程所使用的資源進(jìn)行約束。cgroups 就是用來實(shí)現(xiàn)這個(gè)目的的。cgroups 的全稱是 Control Groups，在 2003 年由 Google 的工程師實(shí)現(xiàn)，在 2007 年加入 Linux Kernel。cgroups 可限制進(jìn)程對(duì) CPU、內(nèi)存、塊存儲(chǔ)和網(wǎng)絡(luò)的使用。這里不對(duì) cgroups 的使用方法作介紹，感興趣的同學(xué)可以參考如下：
- SysAdminCasts.com: Introduction to Linux Control Groups (Cgroups)
- Docker.com: Runtime Metrics
雖然 cgroups 提供了對(duì) IO 資源使用的約束的功能，但 Docker 目前(1.3)尚未提供支持。
內(nèi)存
cgroups 可以控制進(jìn)程所能使用的內(nèi)存和 swap 空間的大小。通過-m參數(shù)，Docker 可以限制容器所能使用的最大內(nèi)存數(shù)：
- docker run -m 128m -d container_img cmd_name
CPU
Docker 可以通過 cgroups 限制容器所能使用的 CPU 資源。在執(zhí)行docker run命令時(shí)可以通過參數(shù)--cpu-shares(-c)、--cpuset對(duì) CPU 做出限制。
--cpu-shares(-c)
-c設(shè)置的是一個(gè)相對(duì)值，這個(gè)值將影響到此容器內(nèi)的進(jìn)程所能使用的 CPU 時(shí)間片。新運(yùn)行的 Docker 容器默認(rèn)使用 1024，對(duì)一個(gè)單獨(dú)的 Docker 的容器來說，這個(gè)值沒有任何意義。當(dāng)啟動(dòng)兩個(gè) Docker 容器的時(shí)候，這兩個(gè)容器將平分 CPU 時(shí)間片。如果兩個(gè)容器，一個(gè)不指定-c，另一個(gè)設(shè)置為-c 512，那前者將使用大致 2/3 的計(jì)算能力，另一個(gè)將使用大致 1/3 的計(jì)算能力。但是-c對(duì)容器所能使用 CPU 的運(yùn)行頻率等沒有任何影響。
--cpuset
可讓你指定 Docker 容器中的進(jìn)程運(yùn)行在第幾塊 CPU 上。后面跟一個(gè)數(shù)組或用逗號(hào)分隔的多個(gè)數(shù)字0,1,2。比如下列命令將會(huì)使你的容器運(yùn)行在第一個(gè) CPU 核心上。
- docker run -i -t --cpuset 0 ubuntu:14.04
注：cgroups 使用的是一種偽文件系統(tǒng)形式的接口。這個(gè)偽文件系統(tǒng)實(shí)際存在于內(nèi)存中，但映射在目錄中。用戶通過在這個(gè)目錄中寫入文件來對(duì) cgroups 進(jìn)行操作。
AUFS
注：最新的 Docker 使用 BTRFS 替代 AUFS，但所要實(shí)現(xiàn)的功能相同
AUFS 的全稱是 Another Union File System。AUFS（包括其它 UFS）的一個(gè)重要能力是能使兩個(gè)目錄結(jié)構(gòu)合二為一。這有什么用呢？Docker 的鏡像都是有多個(gè)層組成的，最上層是一個(gè)可讀寫的，而下面的層則是只讀的。通過 AUFS 的目錄融合的能力，實(shí)現(xiàn)了既可隨意讀寫，又保證了下層的內(nèi)容安全的目的。見下圖可以有一個(gè)形象的認(rèn)識(shí)。下圖中的 bootfs 層包含了 Linux Kernel。在其上是某個(gè)特定的 Linux 發(fā)行版本的不同于 Kernel 的文件層，在下圖中是 Debian。再往上有包含 emacs 和 Apache 的兩個(gè)層。這些層在容器運(yùn)行時(shí)都是只讀的。最上面就是容器運(yùn)行時(shí)可讀寫的層了。上面的層可以只讀訪問下面的層里的文件。這樣的層次結(jié)構(gòu)可以通過 Dockerfile 來創(chuàng)建。
那這樣的一個(gè)結(jié)構(gòu)有什么樣的好處呢？主要有下面幾點(diǎn)：
節(jié)省磁盤和內(nèi)存的存儲(chǔ)空間
節(jié)省磁盤存儲(chǔ)空間是因?yàn)椴煌娜萜麋R像之間可以共享相同的層。例如，兩個(gè)不同的 Java 應(yīng)用的容器鏡像，它們都是基于 Ubuntu 14.04 和 JDK7。那在同一臺(tái) Host 中，這兩個(gè)鏡像就會(huì)使用相同的 Ubuntu 14.04 和 JDK7 的層。
節(jié)省內(nèi)存空間是因?yàn)?Linux 為了加快磁盤訪問，會(huì)將一些磁盤上的文件加載到內(nèi)存中。所以，節(jié)省磁盤空間的同時(shí)也就可以間接地解釋內(nèi)存的使用。
加快部署速度
同樣，可共享的鏡像層能加快部署速度。因?yàn)橄嗤膶硬挥帽恢貜?fù)下載部署。
允許對(duì)文件任意改動(dòng)
上傳可讀寫的層可以對(duì)下面的只讀層中的文件做任意修改，但這其實(shí)是 copy-on-write，所以，這種修改對(duì)下面的層其實(shí)是安全的。
#p#
六、Docker 的生態(tài)圈
Docker 再好，單靠 Docker 自身是無法滿足互聯(lián)網(wǎng)和企業(yè)應(yīng)用的各種復(fù)雜需求的。好在 Docker 的出現(xiàn)帶動(dòng)了一些列技術(shù)的發(fā)展，形成了一個(gè)龐大的生態(tài)圈。這個(gè)生態(tài)圈中的產(chǎn)品可大致分為如下幾類：
容器編排管理
以 Google Kubernets 和 Apache Mesos 為代表。主要解決基于容器組成分布式集群應(yīng)用的管理工作，例如對(duì)容器的運(yùn)行狀態(tài)的監(jiān)控、容器自動(dòng)化的故障恢復(fù)、基于容器的應(yīng)用的擴(kuò)容和縮容、服務(wù)發(fā)現(xiàn)。
基于容器的操作系統(tǒng)
以 CoreOS 和 Redhat Atomic 為代表。它們拋棄了 Linux 上面?zhèn)鹘y(tǒng)的包管理機(jī)制，而使用 Docker 作為應(yīng)用的運(yùn)行平臺(tái)。同時(shí)精簡(jiǎn)系統(tǒng)。CoreOS 還引入了 Ectd、Fleet 等組件以更好地支持分布式系統(tǒng)。
基于容器的平臺(tái)
PaaS 平臺(tái)不是什么新鮮的概念，但卻一直處于發(fā)育不良的狀態(tài)。Docker 的出現(xiàn)給 PaaS 的發(fā)展帶來了新的機(jī)遇，Docker 使得 PaaS 應(yīng)用的部署有了統(tǒng)一的格式。以 Flynn 和 Deis 為代表的新的 PaaS 技術(shù)平臺(tái)都是以 Docker 為基礎(chǔ)的。
網(wǎng)絡(luò)
如今的一臺(tái)服務(wù)器可以輕松應(yīng)付幾百上千的 Docker 容器同時(shí)運(yùn)行在其中。可以想見，在一個(gè)服務(wù)器集群中的 Docker 容器會(huì)有多少。如果對(duì)這么多的 Docker 容器所使用的網(wǎng)絡(luò)進(jìn)行組織管理便成為新的挑戰(zhàn)。在這個(gè)領(lǐng)域主要有 Pipework、Weave 和 Flannel 等技術(shù)
配置管理工具
像 Puppet、Ansible 這樣的配置管理工具早在 Docker 出現(xiàn)之前就已被廣泛使用，但 Docker 的出現(xiàn)給這些技術(shù)帶來了新的變化。是否能更好地支持對(duì) Docker 容器集群的配置管理決定了這些技術(shù)今后的發(fā)展。
七、總結(jié)
本文簡(jiǎn)單介紹了 Docker 出現(xiàn)的背景、意義，Docker 的組成和背后的技術(shù)以及其所帶動(dòng)的生態(tài)圈。但作為一個(gè)新出現(xiàn)并在快速發(fā)展的基礎(chǔ)性的技術(shù)，一兩篇文章顯然只能讓人有一個(gè)最基本的認(rèn)識(shí)。同時(shí)，任何技術(shù)也都有其兩面性，Docker 作為一個(gè)新技術(shù)在實(shí)踐中也存在這個(gè)非常多的問題。即便在國(guó)外，Docker 的應(yīng)用也是出于起步階段。所以還有很長(zhǎng)的路要走。但是從最近一年多的發(fā)展看，Docker 無疑是一個(gè)非常有生命力的技術(shù)，必定會(huì)在今后的一段時(shí)間內(nèi)成為一個(gè)熱門、主流的技術(shù)。
雖然 Docker 的出現(xiàn)更多地是改變了服務(wù)器應(yīng)用的部署和運(yùn)維。但作為開發(fā)者來說，部署和運(yùn)維的模型會(huì)對(duì)開發(fā)也產(chǎn)生很重大的影響，而且 Docker 的出現(xiàn)能使開發(fā)人員更好地參與到運(yùn)維中來，這將促使應(yīng)用更快、更好地迭代和發(fā)布。
更重要地是，云計(jì)算毫無疑問是未來互聯(lián)網(wǎng)和企業(yè)應(yīng)用的發(fā)展方向，而 Docker 和其所代表的容器技術(shù)將在未來一段時(shí)間內(nèi)成為云計(jì)算的基礎(chǔ)性技術(shù)。從這個(gè)角度來講，Docker 是我們每一個(gè)從業(yè)人員必須了解甚至熟練掌握的一門技術(shù)。
原文鏈接：http://www.open-open.com/lib/view/open1420027240953.html
