【前言】

Docker 1.6.0的發(fā)布，絕對(duì)是Docker圈的重磅炸彈。表面上看，這些改動(dòng)大大完善了Docker的功能，然而細(xì)看這些特性，筆者倒是感受到Docker在醞釀著什么驚人的大招。本文詳細(xì)介紹了Docker 1.6.0中一些新的特性。

Docker 1.6.0的發(fā)布，絕對(duì)是Docker圈的重磅炸彈。表面上看，這些改動(dòng)大大完善了Docker的功能，然而細(xì)看這些特性，筆者倒是感受到Docker在醞釀著什么驚人的大招。

首先，來看一下筆者對(duì)Docker 1.6.0新特性的理解。

一.Builder方面

允許從一個(gè)鏡像ID開始build新鏡像

換言之，Dockerfile中的FROM命令后面可以緊跟一個(gè)鏡像ID。好處是Dockerfile的書寫變得靈活，在熟悉Docker鏡像原理的情況下，可以大大提高Docker鏡像build的效率。簡單場(chǎng)景如下，Dockerfile中有兩條RUN命令，第一條命令非常耗時(shí)，且運(yùn)行成功了，而第二條命令失敗。此情形下，完全可以借助前者完成的鏡像繼續(xù)build。當(dāng)然有人會(huì)提到本地image cache的問題同樣可以解決該問題，但是image cache的弊端就是只能本地有效。

Build鏡像時(shí)允許添加限制參數(shù)

這個(gè)改動(dòng)，筆者的感受是：久旱逢甘露，但是僅僅是幾滴。Docker對(duì)于docker run命令的限制，即啟動(dòng)容器時(shí)做的資源等種種限制，目前看來還是差強(qiáng)人意。但需要清楚的是，docker build流程中對(duì)于RUN命令，Docker Daemon本身也會(huì)啟動(dòng)一個(gè)容器，并通過commit容器打成鏡像。此時(shí)，如果對(duì)于運(yùn)行RUN命令的容器沒有限制，后果可想而知。為什么說“甘露”僅僅是幾滴，原因是：docker run命令的限制參數(shù)目前還沒有全部集成至docker build，而通過Docker Daemon來統(tǒng)一化配置又缺乏靈活。

二.Client方面：支持Windows

考慮到廣大的Windows用戶群體，這肯定是好事一樁，但筆者以為Docker官方對(duì)Win粉的愛也只能到這里了。

三. Runtime方面

1.容器label與鏡像label

Label的概念，不知道大家對(duì)她是否似曾相識(shí)。早在很早之前，Docker Daemon就支持添加label，用于記錄Docker Daemon的角色。Label使得Docker Daemon帶有角色，從而Swarm可以方便的通過角色進(jìn)行Docker的管理。而如今，label可以添加到容器和鏡像，原來由Docker外的軟件或者人腦記錄的容器角色，現(xiàn)在可以顯性的放在容器的label中了，大大環(huán)節(jié)容器角色的管理。更大的好處是，label可以在邏輯上關(guān)聯(lián)容器，會(huì)不會(huì)在邏輯上有“組”的概念?

2.容器的–cgroup-parent參數(shù)

將容器A的cgroup指定到容器B的cgroup內(nèi)，從而嵌套情況下，A、B的受限效果將建立管理。容器host網(wǎng)絡(luò)模式或者other container模式使得容器的隔離留有選擇余地，為Docker場(chǎng)景模式的探索帶來更大的可能性。如今cgroup都嵌套之后，容器與容器間的粘性再一次被放到臺(tái)面上，畢竟不是所有容器從邏輯上講是完全隔離的。這一點(diǎn)，絕對(duì)是可挖掘性巨大的特性。

3.logging driver

Docker接管了容器的日志管理。從實(shí)現(xiàn)的角度來說，貌似不難，這個(gè)需求應(yīng)該也是巨大的。只是苦了那些立志占領(lǐng)Docker容器日志市場(chǎng)的小廠商，如logspout就被Docker很禮貌的請(qǐng)出了游戲。

4.通過鏡像ID下載鏡像

這一特性的推出，也許在Private Registry中發(fā)揮的效果更大。熟悉了鏡像原理之后，你會(huì)發(fā)現(xiàn)，公有的環(huán)境下，很少有人會(huì)去關(guān)注repo下tag化鏡像的某個(gè)parent鏡像包含哪些內(nèi)容，這一點(diǎn)也很不現(xiàn)實(shí)。私有registry就不一樣了，私有鏡像的制作，環(huán)節(jié)、內(nèi)容自己應(yīng)該都清楚，如此一來，通過鏡像ID下載鏡像，意義會(huì)逐漸體現(xiàn)出來。

–ulimit參數(shù)–default-ulimit

千呼萬喚等出來，安全利器。先來看看兩者的區(qū)別吧，簡單來講，–ulimit的使用僅僅與docker run命令;若不指定–ulimit，–default-ulimit才會(huì)在docker run的情況下有效。再看這倆參數(shù)的作用：限制容器的資源使用情況，那就不是簡單的CPU、Mem了。相信大家肯定一直聽說，容器技術(shù)有一點(diǎn)弊病就是容器和宿主機(jī)共享內(nèi)核，CPU、Mem等的隔離度有缺陷，其實(shí)共享內(nèi)核的缺陷遠(yuǎn)不僅如此，內(nèi)核的資源是否還應(yīng)該包括，文件數(shù)、進(jìn)程數(shù)、信號(hào)數(shù)、管道數(shù)、系統(tǒng)調(diào)用等?那么問題出現(xiàn)了，namespace和cgroup并沒有考慮到所有的情況，而ulimit可以站出來暫時(shí)讓Docker的安全避避風(fēng)聲。簡單的測(cè)試如下：若調(diào)小–default-ulimit的文件數(shù)參數(shù)之后，進(jìn)入容器查看ulimit –a，open files參數(shù)就變小了，大家可以測(cè)試一番。

容器粘性關(guān)于調(diào)度，容器安全牽扯內(nèi)核，鏡像的靈活，如果您還不知道鏡像是什么原理，就out啦。

有關(guān)Docker 1.6的詳細(xì)介紹，請(qǐng)參考官方博客：

http://blog.docker.com/2015/04/docker-release-1-6/

作者簡介

孫宏亮，DaoCloud初創(chuàng)團(tuán)隊(duì)成員，軟件工程師，浙江大學(xué)VLIS實(shí)驗(yàn)室應(yīng)屆研究生。讀研期間活躍在PaaS和 Docker開源社區(qū)，對(duì)Cloud Foundry有深入研究和豐富實(shí)踐，擅長底層平臺(tái)代碼分析，對(duì)分布式平臺(tái)的架構(gòu)有一定經(jīng)驗(yàn)，撰寫了大量有深度的技術(shù)博客。2014年末以合伙人身份加入 DaoCloud團(tuán)隊(duì)，致力于傳播以Docker為主的容器的技術(shù)，推動(dòng)互聯(lián)網(wǎng)應(yīng)用的容器化步伐。郵箱：allen.sun@daocloud.io