随着片面云时代到来，很多公司都走上了容器化路途，老刘所在的公司也不例外。作为一家初创型的互联网公司，容器化确实带来了很多便捷，也降低了公司成本，不过老刘却有一个苦恼，以前每天和他一同下班的小王自从公司上云以后每天都比他早下班一个小时，大家手头上的活都差不多，讲道理不应该呀，经过多番试探、跟踪、调查，终于让老刘发现了秘密的所在。

作为一个开发，每天总少不了要出N个测试版本停止调试，容器化以后每次出版本都需求打成镜像，老刘发现每次他做一个镜像都要20分钟，而小王只需10分钟，比照来比照去只要这个东西不一样!

Storage-Dirver究竟是何方神圣?为什么可以招致构建时间上的差异?如今让我们来一窥终究。

在回答这个成绩之前我们需求先回答三个成绩——什么是镜像?什么是镜像构建?什么是storage-driver?

什么是镜像?

说到镜像就绕不开容器，我们先看一张来自官方对镜像和容器解释的图片：

看完以后是不是更疑惑了，我们可以这样复杂粗犷的去了解，镜像就是一堆只读层的堆叠。那只读层里究竟是什么呢，另外一个复杂粗犷的解释：里边就是放了一堆被改动的文件。这个解释在不同的storage-driver下不一定准确但是我们可以先这样复杂去了解。

那不对呀，执行容器的时清楚明是可以去修正删除容器里的文件的，都是只读的话怎样去修正呢?实践上我们运转容器的时分是在那一堆只读层的顶上再添加了一个读写层，一切的操作都是在这个读写层里停止的，当需求修正一个文件的时分我们会将需求修正的文件从底层拷贝到读写层再停止修正。那假设是删除呢，我们不是没有办法删除底层的文件么?没错，确实没有办法删除，但只需求在下层把这个文件隐藏起来，就可以到达删除的效果。按照官方说法，这就是Docker的写时复制策略。

为了加深大家对镜像层的了解我们来举个栗子，用下面的Dockerfile构建一个etcd镜像：

构建完成以后生成了如下的层文件：

每次进入容器的时分都觉得似乎进入了一台虚机，外面包含linux的各个系统目录。那是不是有一层目录里包含了一切的linux系统目录呢?

bingo答对!在最底层的层目录确实包含了linux的一切的系统目录文件。

上述Dockerfile中有这样一步操作

ADD . /go/src/github.com/coreos/etcd 

将外面目录的文件拷到了镜像中，那这一层镜像里终究保存了什么呢?

翻开发现外面就只要

/go/src/github.com/coreos/etcd这个目录，目录下寄存了拷贝出去的文件。 

到这里是不是有种管中窥豹的觉得，接上去我们再来了解什么是镜像构建，这样基本上可以窥其全貌了。

什么是镜像构建?

经过第一节的内容我们知道了镜像是由一堆层目录组成的，每个层目录里放着这一层修正的文件，镜像构建复杂的说就是制造和生成镜像层的进程，那这一进程是如何完成的呢?以下图流程为例：

Docker Daemon首先应用基础镜像ubuntu:14.04创立了一个容器环境，经过第一节的内容我们知道容器的最下层是一个读写层，在这一层我们是可以写入修正的，Docker Daemon首先执行了RUN apt-update get命令，执行完成以后，经过Docker的commit操作将这个读写层的内容保存成一个只读的镜像层文件。接上去再在这一层的基础上继续执行 ADD run.sh命令，执行完成后继续commit成一个镜像层文件，如此重复直到将一切的Dockerfile都命令都被提交后，镜像也就做好了。

这里我们就能解释为什么etcd的某个层目录里只要一个go目录了，由于构建的进程是逐层提交的，每一层里只会保存这一层操作所触及改动的文件。

这样看来镜像构建就是一个重复按照Dockerfile启动容器执行命令并保存成只读文件的进程，那为什么速度会不一样呢?接上去就得说到storage-driver了。

什么是storage-driver?

再来回忆一下这张图：

之前我们曾经知道了，镜像是由一个个的层目录叠加起来的，容器运转时只是在下面再添加一个读写层，同时还有写时复制策略保证在最顶层可以修正底层的文件内容，那这些原理是怎样完成的呢?就是靠storage-driver!

复杂引见三种常用的storage-driver：

AUFS

(责任编辑：admin)