Docker用户指南(3) – 理解镜像,容器和存储驱动

为了更有效地使用存储驱动，你必须理解Docker是如何构建和存储镜像的。然后，你需要对镜像是如何被容器使用作个了解。最后，你需要一段关于镜像和容器共同使用的技术的简洁的介绍。

镜像和数据层

每个Docker镜像引用一个或多个代表文件系统差异的只读数据层。数据层彼此堆叠来组成容器的根文件系统。下面的图表表示Ubuntu 15.04镜像由4个堆叠的数据层组成。

Docker存储驱动负责堆叠这些数据层和提供一个单独的统一视图。
当你创建一个容器，同时也在底层堆栈顶部创建了一个新的，薄的，可写的数据层。这个数据层也称为”容器数据层(container layer)“。所有对运行容器的更改 – 如写新文件，更新文件和删除文件 – 都是写到这个数据层。下面的图表显示基于Ubuntu 15.04镜像的容器。

内容寻址存储

Docker 1.10引入了一个新的内容寻址存储模型。这是一个全新的方法来定位硬盘上的镜像和数据层数据。之前的版本，镜像和数据层通过使用随机生成的UUID来引用。在这个新的模型使用了安全哈希（secure content hash）来代替。
新的模式提高了安全性，提供了一个内置的方式来避免ID冲突，并且在pull,push,load,save后保证数据完整性。同时也通过允许镜像(即使它们不是由相同的Dockerfile构建)自由地共享它们的数据层来获取更好的使用体验。
在使用新模式前需要注意的是：

1.迁移现有的镜像

2.镜像和数据层文件系统结构

那些使用早期Docker版本创建和拉取的镜像，在与新模式一起使用前需要进行迁移。迁移操作涉及计算新的安全checksum，这个操作是在你首次启动新的Docker版本时自动完成的。迁移完成后，所有的镜像都会具有全新的安全ID。
虽然迁移是自动和透明的，但是要使用比较多的计算资源。意味着当你有许多镜像需要计算时要花费比较长的时间。在这期间Docker daemon不会响应其它请求。
Docker为此把迁移工具单独出来，允许你在升级Docker之前先把镜像迁移好。这样可以避免长时间的停机时间。
迁移工具以容器方式运行，可以到这里下载https://github.com/docker/v1.10-migrator/releases。
如果你使用的是默认的docker数据路径，手动迁移命令如下：

如果你用的是devicemapper存储驱动，你需要添加–privileged参数来让容器可以访问存储设备。

迁移示例

下面是在Docker 1.9.1，AUFS存储驱动的环境下使用迁移工具的示例.Docker主机运行在配置为1 vCPU, 1GB RAM以及单独的8G SSD的t2.micro AWS EC2实例。Docker数据目录(/var/lib/docker)占用2GB空间。

Unix time命令放在docker run命令前面来统计其运行时间。正如你所看到了，迁移大小为2GB的7个镜像总体时间将近1分钟。不过这个时间包括了拉取镜像/docker/v1.10-migrator镜像的时间(大约为3.5秒)。同样的操作在一个配置为40 vCPUs, 160GB RAM和一个8GB SSD的m4.10xlarge EC2 instance实例花费的时间少得多：

这个示例表明了迁移操作耗费的时间受机器硬件配置的影响。

容器和数据层

容器和镜像的主要区别是顶部的可写数据层。所有对容器进行文件添加或文件更新的操作都会存储到这个可写数据层。当容器被删除后，这个可写数据层也被删除了。而底层的镜像仍然不变。
由于每个容器有自己的可写容器数据层，并且所有的更改都储存到这个数据层，意味着多个容器可以共享访问同一个底层镜像且有它们自己的数据状态。下面的图表显示多个容器共享一个相同的Ubuntu 15.04镜像。

Docker存储驱动负责激活和管理镜像数据层和可写容器数据层。不同的存储驱动处理这两个数据层的方式有所不同。Docker镜像和容器管理背后两个关键技术是可堆叠镜像数据层和写时拷贝(copy-on-write)。

写时拷贝策略

写时拷贝策略与共享和复制类似。需要相同数据的系统进程共享该数据，而不是各自拥有自己的副本。在某些时候，如果一个进程需要更新或写入数据，操作系统就为该进程拷贝一份数据使用。只有需要写入数据的系统有权限访问数据副本。所有其它进程继续使用原始的数据。
Docker对镜像和容器都使用了写时拷贝技术。写时拷贝策略优化了镜像硬盘占用和容器启动时间的性能。接下来我们来看看写时拷贝技术是如何通过共享和复制影响镜像和容器的。

共享使镜像更小

现在我们来了解镜像数据层和写入拷贝技术。所有的镜像和容器数据层存储在由存储驱动管理的Docker主机本地存储区域内。在基于Linux的Docker主机这个目录是/var/lib/docker/。
当使用docker pull和docker push拉取和推送镜像时,docker客户端将输出镜像数据层报告。下面的命令是从Docker Hub拉取ubuntu:15.04镜像。

从输出中我们看到命令实际上拉取了4个镜像数据层。上面的每一行列出了一个镜像数据层和它的UUID或加密散列。这4个数据层混合组成了ubuntu:15.04 Docker镜像。
每一个数据层都存储在Docker主机本地存储区域内的它们自己的目录。
Docker 1.10之前的版本把数据层存储在与它们ID相同名称的目录中。不过对于使用docker 1.10和之后的版本拉取镜像的情况并非如此。例如，下面的命令显示从Docker Hub拉取一个镜像，并列出Docker 1.9.1的一个目录文件列表。

注意看四个目录是如何与下载的镜像的数据层ID匹配的。现在比较下由docker 1.10完成同样的操作的表现。

我们看到四个目录与镜像数据层ID并不匹配。尽管docker 1.10之前与之后的版本镜像管理有不同之处，不过所有的docker版本仍然能在镜像之间共享数据层。例如，如果你拉取一个与已经拉取下来的镜像拥有一些共同的数据层的镜像，Docker会检查到这个并只拉取本地没有的数据层。在这之后，两个镜像共享一些相同的数据层。
你可以自己做试验来说明。对你刚拉取下来的ubuntu:15.04镜像做一个更改，然后基于这个更改构建一个新的镜像。做这个操作的其中一个方法是使用Dockerfile和docker build命令。
1.在一个空目录创建一个以ubuntu:15.04镜像开始的Dockerfile。

2.添加一个内容为”hello world”在/tmp目录的”newfile”文件。Dockerfile类似如下：

3.保存Dockerfile并关闭文件。
4.在Dockerfile相同目录的终端，执行如下命令：

上面显示新镜像的ID为94e6b7d2c720。
5.执行docker images来检查新的changed-ubuntu镜像是否在Docker主机本地存储区域。

6.执行docker history命令来查看哪些数据层用来创建这个新的changed-ubuntu镜像。
$ docker history changed-ubuntu

docker history命令输出显示新的94e6b7d2c720镜像数据层在顶部。你知道这个数据层是由于Dockerfile中的echo “Hello world” > /tmp/newfile命令添加的。下面的4个镜像数据层与组成ubuntu:15.04的数据层是一样的。
注意到新的changed-ubuntu镜像没有它自己每个数据层的拷贝。从如下图表看到，新的镜像与ubuntu:15.04镜像4个底层数据层共享。

docker history命令也显示了每个镜像数据层的大小。如你所见，94e6b7d2c720数据层只消耗了12字节的空间。意味着我们刚才创建的changed-ubuntu镜像只占用了docker主机12字节的空间 – 94e6b7d2c720数据层以下的所有数据层都以存在docker主机上并与其它镜像共享。
镜像数据层的共享使得docker镜像和容器如此的节省空间。

复制使容器高效

你早先学到了一个容器与镜像的区别是容器多了一个可写数据层。下面的图表显示了基于ubuntu:15.04的容器的数据层：

所有对容器的更改都会存储到这个薄的可写容器数据层。其它的数据层是不能修改的只读的镜像数据层。意味着多个容器能安全地共享一个底层镜像。下面的图表显示多个容器镜像一个ubuntu:15.04镜像。每一个容器有它自己的可写数据层。

当容器内的一个存在的文件被修改时，docker使用存储驱动来完成写时拷贝操作。操作的细节取决于存储驱动程序。对于AUFS和OverlayFS存储驱动，写时拷贝的操作类似如下：

在镜像数据层中搜索要更新的文件。从顶部，每次一个数据层开始搜索。

在找到的第一个文件副本执行复制(copy-up)操作。”copy up“复制文件到容器自己的可写数据层。

在容器的可写数据层修改刚才复制上来的文件。

Btrfs, ZFS和其它驱动处理写时拷贝有所不同。你可以之后阅读这些驱动的详细说明。
一个copy-up操作可能导致明显的性能开销。开销的不同取决于使用的存储驱动。不过，大文件，大量数据层和尝试目录树会影响更显着。幸运的是，操作只发生在第一次修改任何特定文件时。随后对同一个文件的修改不会引起一个copy-up操作，而是对存在于容器数据层的这个文件直接修改。
让我们看看如果我们根据我们之前创建的更改的ubuntu映像启动5个容器会发生什么：
1.从Docker主机上的终端，运行以下docker run命令5次。

这将根据更改的ubuntu映像启动5个容器。 随着每个容器的创建，Docker添加一个可写层，并为其分配一个随机UUID。 这是从docker run命令返回的值。
2.运行docker ps命令以验证5个容器是否正在运行。

上面的输出显示了5个正在运行的容器，它们都共享更改的ubuntu映像。 每个CONTAINER ID在创建每个容器时从UUID派生。
3.列出本地存储区的内容。

Docker的写时拷贝策略不仅减少了容器所消耗的空间量，而且还减少了启动容器所需的时间。 在开始时，Docker只需为每个容器创建可写层。 下图显示了这5个容器共享更改的ubuntu映像的一个只读（RO）副本。

如果Docker在每次启动一个新容器时都必须创建底层映像堆栈的整个副本，那么容器启动时间和磁盘空间将大大增加。

数据卷和存储驱动

当容器被删除时，写入到容器中的未存储在数据卷中的任何数据与容器一起被删除。
数据卷是Docker主机文件系统中直接挂载到容器中的目录或文件。 数据卷不受存储驱动程序控制。 对数据卷的读取和写入绕过存储驱动程序，并以本机主机速度运行。 你可以将任意数量的数据卷装载到容器中。 多个容器还可以共享一个或多个数据卷。
下图显示了运行两个容器的单个Docker主机。 每个容器存在于Docker主机本地存储区（/var/lib/docker/ …）内的自己的地址空间内。 Docker主机上的/data还有一个共享数据卷。 它直接安装在两个容器中。

数据卷驻留在Docker主机上的本地存储区域之外，进一步增强了它们与存储驱动程序控制的独立性。 当容器被删除时，存储在数据卷中的任何数据都会保留在Docker主机上。