6月16日，Docker 1.7.0 發(fā)布，重磅炸彈在Docker圈引起巨大轟動(dòng)，同時(shí)也為6月22日在舊金山舉辦的DockerCon大會(huì)獻(xiàn)禮。在本文中，DaoCloud團(tuán)隊(duì)成員孫宏亮帶領(lǐng)您深度解析Docker 1.7.0。

[[137542]]

早在Docker 1.6.0之際，Docker官方的工程師即宣稱：1.7.0版本將會(huì)帶來很大的變化，包括：Docker的bug修改以及功能添加;并且還體現(xiàn)在Docker的架構(gòu)上，如網(wǎng)絡(luò)模塊等。

話不多說，趕緊讓我們進(jìn)入Docker 1.7.0的深度解析。從Docker的版本變更日志來看，Docker 1.7.0在四個(gè)方面會(huì)有或多或少的變動(dòng)，分別是：Docker運(yùn)行時(shí)(Runtime)，Docker的代碼變化，Docker的builder模塊，以及Docker的bug修復(fù)。

本文主要涉及Docker 1.7.0的runtime。

1. 增添了一個(gè)仍然處于試驗(yàn)階段的特性：支持out of process的數(shù)據(jù)卷插件。

何為試驗(yàn)性質(zhì)的特性，換言之Docker的這部分特性還不支持在生產(chǎn)環(huán)境中采用，這些特性更多的希望用戶僅僅在測(cè)試環(huán)境，以及沙箱環(huán)境中采用。試驗(yàn)性特性完全是Docker 1.7.0的一大亮點(diǎn)。

在以上的基礎(chǔ)上理解out-of-process，就容易很多，插件本身與Docker Daemon無耦合，即插即用，在Docker Daemon范疇之外發(fā)揮作用。

目前Docker的試驗(yàn)性特性可以從兩個(gè)方面來描述，首先Docker目前已經(jīng)支持用戶自定義第三方插件的使用;另外在這基礎(chǔ)上，Docker自身支持了容器數(shù)據(jù)卷volume插件。此外，Docker還定義了一整套與插件相關(guān)的API，方便用戶使用。當(dāng)然，相信后續(xù)在該領(lǐng)域，不論是Docker 官方，還是整個(gè)社區(qū)，都會(huì)不斷有新的插件誕生。值得一提的，在數(shù)據(jù)卷volume插件方面，出現(xiàn)了Flocker的身影，這也意味著容器的數(shù)據(jù)存儲(chǔ)問題，真正被提上臺(tái)面，并由相應(yīng)合理的解決方案。

2.從docker daemon的角度，添加了userland-proxy的起停開關(guān)。

首先介紹userland- proxy一直以來的作用。眾所周知，在Docker的橋接bridge網(wǎng)絡(luò)模式下，Docker容器時(shí)是通過宿主機(jī)上的NAT模式，建立與宿主機(jī)之外世界的通信。然而在宿主機(jī)上，一般情況下，進(jìn)程可以通過三種方式訪問容器，分別為：:, :,以及<0.0.0.0>:。實(shí)際上，最后一種方式的成功訪問完全得益于userland-proxy，即 Docker Daemon在啟動(dòng)一個(gè)Docker容器時(shí)，每為容器在宿主機(jī)上映射一個(gè)端口，都會(huì)啟動(dòng)一個(gè)docker-proxy進(jìn)程，實(shí)現(xiàn)宿主機(jī)上0.0.0.0地址上對(duì)容器的訪問代理。

當(dāng)時(shí)引入userland-proxy時(shí)，也許是因?yàn)樵O(shè)計(jì)者意識(shí)到了0.0.0.0地址對(duì)容器訪問上的功能缺陷。然而，在docker- proxy加入Docker之后相當(dāng)長(zhǎng)的一段時(shí)間內(nèi)。Docker愛好者普遍感受到，很多場(chǎng)景下，docker-proxy并非必需，甚至?xí)硪恍┢渌谋锥恕?/p>

影響較大的場(chǎng)景主要有兩種。

第一，單個(gè)容器需要和宿主機(jī)有多個(gè)端口的映射。此場(chǎng)景下，若容器需要映射1000個(gè)端口甚至更多，那么宿主機(jī)上就會(huì)創(chuàng)建1000個(gè)甚至更多的 docker-proxy進(jìn)程。據(jù)不完全測(cè)試，每一個(gè)docker-proxy占用的內(nèi)存是4-10MB不等。如此一來，直接消耗至少4-10GB內(nèi)存，以及至少1000個(gè)進(jìn)程，無論是從系統(tǒng)內(nèi)存，還是從系統(tǒng)CPU資源來分析，這都會(huì)是很大的負(fù)擔(dān)。

第二，眾多容器同時(shí)存在于宿主機(jī)的情況，單個(gè)容器映射端口極少。這種場(chǎng)景下，關(guān)于宿主機(jī)資源的消耗并沒有如第一種場(chǎng)景下那樣暴力，而且一種較為慢性的方式侵噬資源。

如今，Docker Daemon引入- -userland-proxy這個(gè)flag，將以上場(chǎng)景的控制權(quán)完全交給了用戶，由用戶決定是否開啟，也為用戶的場(chǎng)景的proxy代理提供了靈活性。

3. docker exec命令增加- -user參數(shù)，用戶控制docker exec在容器中執(zhí)行命令時(shí)所處的用戶。

自從docker 1.3.0引入docker exec之后，用戶對(duì)容器的操縱能力被大大釋放，容器對(duì)用戶而言不再是一個(gè)運(yùn)行的黑盒。然而，docker exec帶來巨大好處的同時(shí)，我們也能看到這其中的一些瑕疵，當(dāng)然Docker社區(qū)也在不斷地完善docker exec。

首先，docker exec在容器中運(yùn)行的進(jìn)程會(huì)以root權(quán)限運(yùn)行，在權(quán)限方面缺乏靈活性的同時(shí)，容器的安全很有可能失控。參數(shù)- -user恰好彌補(bǔ)了這方面的不足。其次，docker exec的存在打破了容器內(nèi)進(jìn)程呈現(xiàn)樹狀關(guān)系的現(xiàn)狀，而設(shè)計(jì)初期Docker容器的很多概念均以樹的思想從init process入手，因此目前docker exec的進(jìn)程并不能和原生態(tài)容器進(jìn)程完全一樣地被Docker Daemon管理。

#p#

4. 增強(qiáng)Docker容器網(wǎng)關(guān)地址的配置廣度。

Docker 1.7.0發(fā)布之前，在bridge橋接模式下，Docker容器的網(wǎng)關(guān)地址是默認(rèn)生成的，一般為Docker環(huán)境中的docker0網(wǎng)橋地址。從容器通信的角度而言，默認(rèn)的方式已經(jīng)可以滿足需要。但是，我們依然可以發(fā)現(xiàn)，這種模式存在一些弊端，比如網(wǎng)絡(luò)配置的靈活性以及網(wǎng)絡(luò)安全性。

Docker容器的網(wǎng)絡(luò)一直廣受關(guān)注，缺乏可配置的特性，在如今的軟件發(fā)展中，幾乎就意味著封閉。 --default-gateway 以及--default-gateway-v6 這兩個(gè)參數(shù)，很大程度上提高了用戶自定義容器網(wǎng)絡(luò)的靈活性，用戶更多場(chǎng)景的覆蓋，似乎從Docker的發(fā)展中若影若現(xiàn)。結(jié)合最近幾次新版本，功能的增強(qiáng)與豐富，不難猜測(cè)，Docker的企業(yè)化以及生產(chǎn)化，已經(jīng)更上一層樓。

默認(rèn)網(wǎng)關(guān)的設(shè)置，為什么說會(huì)和容器的網(wǎng)絡(luò)安全相關(guān)呢?過去很長(zhǎng)一段時(shí)間內(nèi)，docker0作為容器的網(wǎng)關(guān)地址，這種方式將容器與宿主機(jī)的耦合關(guān)系體現(xiàn)的很徹底。docker0作為宿主機(jī)上的網(wǎng)絡(luò)接口，充當(dāng)容器與宿主機(jī)的橋梁。然而，也正是橋梁的存在，使得容器內(nèi)部進(jìn)程很容易穿過網(wǎng)關(guān)，到達(dá)宿主機(jī)，此過程并非對(duì)用戶透明。

5. 容器CFS quota的支持

完善Docker對(duì)內(nèi)核cgoups的支持，指的是對(duì)于一個(gè)組內(nèi)的進(jìn)程組在一個(gè)周期內(nèi)被內(nèi)核CFS調(diào)度算法調(diào)度的時(shí)間限額，單位為微秒。該配置項(xiàng)在cgroups中相應(yīng)的文件為/sys/fs/cgroup/cpu/cpu.cfs_quota_us。

6. 容器磁盤IO限制的支持

眾所周知，容器將會(huì)為用戶提供一個(gè)隔離的運(yùn)行環(huán)境，容器內(nèi)部的進(jìn)程或者進(jìn)程組使用資源時(shí)將受到限制，這樣的資源，包括：內(nèi)存資源(物理內(nèi)存以及swap)，CPU資源(CPU時(shí)間片以及CPU核等)，磁盤空間資源等，以上這部分內(nèi)容或多或少，Docker的新版本之前或多或少都可以實(shí)現(xiàn)，然而隔離維度依舊不夠完美，這次Docker添加了—blkio-weight參數(shù)，實(shí)現(xiàn)對(duì)容器磁盤 IO限制的支持。隔離更加完備，用戶也不再需要擔(dān)心容器間磁盤IO資源的競(jìng)爭(zhēng)。

7. ZFS支持

Docker 1.7.0 正式宣布支持ZFS文件系統(tǒng)。此舉也意味著Docker容器文件系統(tǒng)的支持從原先的5種增加到6種。此前，Docker支持 aufs，devmapper，btrfs，ovelayfs，vfs(用于支持volume)，如今添加對(duì)ZFS的支持。ZFS的支持，不禁讓人聯(lián)想到與Docker的數(shù)據(jù)卷volume插件的Flocker。錯(cuò)進(jìn)錯(cuò)出，似乎關(guān)系較為微妙。

值得一提的是，除了支持ZFS之外，筆者發(fā)現(xiàn)在負(fù)責(zé)容器文件系統(tǒng)的graph模塊中，添加了driver_windows.go,雖然內(nèi)容極其簡(jiǎn)易，并非完全實(shí)現(xiàn)對(duì)windows的全盤支持，但是至少讓大家看到Docker支持windows的步伐在不斷邁進(jìn)。

8. docker logs的功能擴(kuò)展

查看容器日志，相信很多Docker愛好者都體驗(yàn)過，這也是用戶查看容器運(yùn)行狀態(tài)的重要依據(jù)。

可以簡(jiǎn)單了解Docker容器日志的原理：對(duì)于每一個(gè)創(chuàng)建的Docker容器，Docker Daemon均會(huì)在內(nèi)部創(chuàng)建一個(gè)goroutine來監(jiān)聽容器內(nèi)部進(jìn)程的標(biāo)準(zhǔn)輸出stdout以及標(biāo)準(zhǔn)錯(cuò)誤stderr，并將內(nèi)容傳遞至日志文件中。每當(dāng)用戶發(fā)通過Docker Client發(fā)起查看容器日志的請(qǐng)求docker logs之后，Docker Daemon會(huì)將日志文件的內(nèi)容傳遞至Docker Client顯示。

docker logs的發(fā)展，幾乎可以分為4個(gè)階段：Docker誕生初期的原生態(tài)日志打印;允許用戶follow容器的日志;開啟容器容器的tail功能，以及容器日志的since功能，打印從某一個(gè)時(shí)間戳開始之后的容器日志。

雖然容器日志的功能在逐漸增強(qiáng)，但是不可否認(rèn)的是，容器日志是容器本身與Docker Daemon耦合最大的模塊之一，而這涉及Docker設(shè)計(jì)之初的計(jì)劃，絕非完美，但的確是短時(shí)間內(nèi)最易用的方案。

9. 容器與宿主機(jī)共享UTS命名空間的支持

不同的場(chǎng)景下，容器與宿主機(jī)可以完全隔離，容器也可能與宿主機(jī)存在共享信息的情況，Docker網(wǎng)絡(luò)的host模式就是一個(gè)很好的例子，該模式下的容器共享宿主機(jī)的網(wǎng)絡(luò)命名空間。

共享UTS命名空間的支持，意味著容器與宿主機(jī)的關(guān)系越來越微妙。也許目前很多Docker愛好者已經(jīng)習(xí)慣容器與宿主機(jī)完全隔離的運(yùn)行，當(dāng)然也會(huì)有一些用戶曾經(jīng)抱怨完全隔離的運(yùn)行環(huán)境并不能平滑的將傳統(tǒng)遺留業(yè)務(wù)容器化。那么，目前Docker在兼顧兩者的情況下，更多地在滿足后者的需求，不久的將來，Docker容器的運(yùn)用場(chǎng)景必將更加豐富，這也是Docker走向企業(yè)化以及生產(chǎn)化必須要趟的路。

總體而言，Docker 1.7.0給筆者的感受是：功能上逐漸向企業(yè)需求靠攏，在production-ready的路上不斷優(yōu)化，另外在安全方面在不涉及內(nèi)核基礎(chǔ)上也不斷完善。

原文鏈接：http://dockone.io/article/451