©
This document uses PHP Chinese website manual Release
要有效地使用存储驱动程序，您必须了解Docker如何构建和存储图像。然后，您需要了解容器如何使用这些图像。最后，您需要简单介绍启用图像和容器操作的技术。
了解Docker如何管理图像和容器中的数据将帮助您理解设计容器和Dockerize应用程序的最佳方式，并避免之后的性能问题。
图像和图层
Docker镜像是由一系列图层构建而成的。每个图层代表图像的Dockerfile中的指令。除最后一层以外的每个图层都是只读的。考虑以下Dockerfile：
FROM ubuntu:15.04COPY . /app RUN make /app CMD python /app/app.py
这个Dockerfile包含四个命令，每个命令创建一个图层。 FROM语句从ubuntu：15.04映像创建一个图层开始。 COPY命令添加Docker客户端当前目录中的一些文件。 RUN命令使用make命令构建您的应用程序。 最后，最后一层指定在容器内运行的命令。
每个图层只是与之前图层的一组差异。这些图层堆叠在一起。当你创建一个新的容器时，你在底层上添加一个新的可写层。这个层通常被称为“容器层”。对正在运行的容器所做的所有更改（如写入新文件，修改现有文件和删除文件）都会写入此可写容器层。下图显示了一个基于Ubuntu 15.04映像的容器。
一个存储驱动程序处理这些层相互交互的方式的细节。不同的存储驱动程序是可用的，这在不同的情况下具有优点和缺点。
容器和图层
容器和图像之间的主要区别是最高的可写层。所有写入容器的添加新的或修改现有数据的内容都存储在该可写层中。当容器被删除时，可写层也被删除。底层图片保持不变。
由于每个容器都有自己的可写容器层，并且所有更改都存储在此容器层中，因此多个容器可以共享对相同基础映像的访问权限，并且拥有自己的数据状态。下图显示了共享相同Ubuntu 15.04映像的多个容器。
注意：如果您需要多个映像才能共享访问完全相同的数据，请将这些数据存储在Docker卷中并将其挂载到容器中。
Docker使用存储驱动程序来管理图像层和可写容器层的内容。每个存储驱动程序都以不同方式处理实现，但所有驱动程序都使用可堆叠的图像层和写入时复制（CoW）策略。
磁盘上的容器大小
要查看正在运行的容器的大小，可以使用该docker ps -s命令。两个不同的列与大小有关。
size：用于每个容器的可写层的数据量（在磁盘上）virtual size：用于容器使用的只读图像数据的数据量。多个容器可能共享部分或全部只读图像数据。从同一图像开始的两个容器共享只读数据的100％，而具有不同图像的两个容器共享这些共同层。因此，你不能只总计虚拟尺寸。这会通过一个可能不重要的数量来高估整个磁盘使用量。
磁盘上所有正在运行的容器使用的总磁盘空间是每个容器大小和虚拟大小值的组合。 如果多个容器具有完全相同的虚拟大小，则它们可能从相同的精确图像开始。
这也不会计算容器占用磁盘空间的以下其他方式：
如果使用
json-file日志记录驱动程序，则用于日志文件的磁盘空间。如果您的容器生成大量日志数据并且未配置日志轮转，这可能不平凡。容器使用的卷和绑定挂载。
用于容器配置文件的磁盘空间，通常很小。
写入磁盘的内存（如果启用了交换）。
检查点，如果您使用的是实验性检查点/恢复功能。
写时复制（CoW）策略
写入时复制是一种共享和复制文件以实现最高效率的策略。如果文件或目录存在于映像的较低层中，而另一层（包括可写层）需要对其进行读取访问，则它只使用现有文件。第一次需要修改文件时（构建图像或运行容器时），该文件将被复制到该图层并进行修改。这最大限度地减少了每个后续层的I / O和大小。下面将更深入地解释这些优点。
共享促进了较小的图像
当您使用docker pull从存储库中下拉图像时，或者当您从本地还不存在的图像创建容器时，每个图层都单独下拉，并存储在Docker的本地存储区域中，该区域通常/var/lib/docker/位于Linux主机上。在这个例子中你可以看到这些图层被拉出来了：
$ docker pull ubuntu:15.0415.04: Pulling from library/ubuntu 1ba8ac955b97: Pull complete f157c4e5ede7: Pull complete 0b7e98f84c4c: Pull complete a3ed95caeb02: Pull complete Digest: sha256:5e279a9df07990286cce22e1b0f5b0490629ca6d187698746ae5e28e604a640e Status: Downloaded newer image for ubuntu:15.04
每个层都存储在Docker主机本地存储区内的自己的目录中。要检查文件系统上的图层，请列出内容/var/lib/docker/<storage-driver>/layers/。以下示例使用aufs默认存储驱动程序：
$ ls /var/lib/docker/aufs/layers 1d6674ff835b10f76e354806e16b950f91a191d3b471236609ab13a930275e24 5dbb0cbe0148cf447b9464a358c1587be586058d9a4c9ce079320265e2bb94e7 bef7199f2ed8e86fa4ada1309cfad3089e0542fec8894690529e4c04a7ca2d73 ebf814eccfe98f2704660ca1d844e4348db3b5ccc637eb905d4818fbfb00a06a
目录名称不对应于层ID（自从Docker 1.10以来，都为true）。
现在想象你有两个不同的Docker文件。您使用第一个来创建一个名为acme/my-base-image:1.0的图像
FROM ubuntu:16.10COPY . /app
第二个是基于acme/my-base-image:1.0的，但有一些额外的层次：
FROM acme/my-base-image:1.0CMD /app/hello.sh
第二个图像包含第一个图像的所有图层，以及一个带有CMD指令的新图层和一个读写容器图层。Docker已经拥有了第一张图片中的所有图层，因此不需要再次拖动它们。这两个图像将共享他们共有的任何图层。
如果您从两个Dockerfiles构建图像，则可以使用docker images和docker history命令来验证共享图层的加密ID是否相同。
建立一个新的目录
cow-test/并改变它。其中
cow-test/，创建一个包含以下内容的新文件：＃！/ bin / sh echo“Hello world”保存文件并使其可执行：chmod + x hello.sh将上面第一个Dockerfile的内容复制到一个名为
Dockerfile.base的新文件中。将上面第二个Dockerfile的内容复制到一个名为
Dockerfile的新文件中。在
cow-test/目录中，建立第一张图片。$ docker build -t acme/my-base-image:1.0 -f Dockerfile.base . Sending build context to Docker daemon 4.096kB Step 1/2 : FROM ubuntu:16.10 ---> 31005225a745 Step 2/2 : COPY . /app ---> Using cache ---> bd09118bcef6 Successfully built bd09118bcef6 Successfully tagged acme/my-base-image:1.0建立第二个图像。$ docker build -t acme/my-final-image:1.0 -f Dockerfile . Sending build context to Docker daemon 4.096kB Step 1/2 : FROM acme/my-base-image:1.0 ---> bd09118bcef6 Step 2/2 : CMD /app/hello.sh ---> Running in a07b694759ba ---> dbf995fc07ff Removing intermediate container a07b694759ba Successfully built dbf995fc07ff Successfully tagged acme/my-final-image:1.0
检查图像的大小：$ docker images REPOSITORY TAG IMAGE ID CREATED SIZE acme/my-final-image 1.0 dbf995fc07ff 58 seconds ago 103MB acme/my-base-image 1.0 bd09118bcef6 3 minutes ago 103MB
查看构成每个图像的图层：$ docker history bd09118bcef6 IMAGE CREATED CREATED BY SIZE COMMENT bd09118bcef6 4 minutes ago /bin/sh -c #(nop) COPY dir:35a7eb158c1504e... 100B 31005225a745 3 months ago /bin/sh -c #(nop) CMD "/bin/bash" 0B <missing> 3 months ago /bin/sh -c mkdir -p /run/systemd && echo '... 7B <missing> 3 months ago /bin/sh -c sed -i 's/^#\s*(deb.*universe... 2.78kB <missing> 3 months ago /bin/sh -c rm -rf /var/lib/apt/lists/* 0B <missing> 3 months ago /bin/sh -c set -xe && echo '#!/bin/sh' >... 745B <missing> 3 months ago /bin/sh -c #(nop) ADD file:eef57983bd66e3a... 103MB$ docker history dbf995fc07ff IMAGE CREATED CREATED BY SIZE COMMENT dbf995fc07ff 3 minutes ago /bin/sh -c #(nop) CMD ["/bin/sh" "-c" "/a... 0B bd09118bcef6 5 minutes ago /bin/sh -c #(nop) COPY dir:35a7eb158c1504e... 100B 31005225a745 3 months ago /bin/sh -c #(nop) CMD "/bin/bash" 0B <missing> 3 months ago /bin/sh -c mkdir -p /run/systemd && echo '... 7B <missing> 3 months ago /bin/sh -c sed -i 's/^#\s*(deb.*universe... 2.78kB <missing> 3 months ago /bin/sh -c rm -rf /var/lib/apt/lists/* 0B <missing> 3 months ago /bin/sh -c set -xe && echo '#!/bin/sh' >... 745B <missing> 3 months ago /bin/sh -c #(nop) ADD file:eef57983bd66e3a... 103MB
请注意，除第二个图像的顶层外，所有图层都相同。 所有其他图层都在两个图像之间共享，并且只在/ var / lib / docker /中存储一次。 新层实际上并不占用任何空间，因为它不会更改任何文件，而只是运行一个命令。
注意：docker历史输出中的<missing>行表明这些图层是在另一个系统上构建的，并且在本地不可用。 这可以被忽略。
复制使容器高效
当你启动一个容器时，一个薄的可写容器层被添加到其他层的顶部。容器对文件系统所做的任何更改都存储在此处。容器不会更改的任何文件都不会被复制到此可写层中。这意味着可写层尽可能小。
当容器中的现有文件被修改时，存储驱动程序执行写入时复制操作。涉及的具体步骤取决于具体的存储驱动程序。对于默认的aufs驱动程序和overlay和overlay2驱动程序时，写入时复制操作遵循以下顺序粗糙：
通过图像层搜索要更新的文件。该过程从最新层开始，一次处理一层基础层。找到结果后，它们将被添加到缓存中以加速未来的操作。
copy_up对找到的文件的第一个副本执行操作，将文件复制到容器的可写层。对该文件的副本进行任何修改，并且该容器不能看到存在于较低层中的文件的只读副本。
Btrfs，ZFS和其他驱动程序以不同方式处理写入时复制。稍后您可以在详细说明中阅读有关这些驱动程序方法的更多信息。
写入大量数据的容器会比不容器的容器消耗更多的空间。这是因为大多数写入操作会在容器的可写顶层中占用新空间。
注意：对于大量写入的应用程序，您不应将数据存储在容器中。相反，请使用Docker卷，这些卷独立于正在运行的容器，并且设计为对I / O有效。另外，卷可以在容器间共享，不会增加容器可写层的大小。
一个copy_up操作可能导致性能显着的开销。这个开销根据使用的存储驱动程序而不同。大文件，大量图层和深层目录树可以使影响更加明显。这可以通过每个copy_up操作只在第一次修改给定文件时发生。
为了验证写入时复制的工作方式，下面的过程根据acme/my-final-image:1.0我们之前构建的映像加速了5个容器，并检查它们占用的空间。
注意：此过程在Docker for Mac或Docker for Windows上不起作用。
从Docker主机的终端上运行以下
docker run命令。最后的字符串是每个容器的ID。 $ docker run -dit --name my_container_1 acme/my-final-image:1.0 bash \ && docker run -dit --name my_container_2 acme/my-final-image:1.0 bash \ && docker run -dit --name my_container_3 acme/my-final-image:1.0 bash \ && docker run -dit --name my_container_4 acme/my-final-image:1.0 bash \ && docker run -dit --name my_container_5 acme/my-final-image:1.0 bash c36785c423ec7e0422b2af7364a7ba4da6146cbba7981a0951fcc3fa0430c409 dcad7101795e4206e637d9358a818e5c32e13b349e62b00bf05cd5a4343ea513 1e7264576d78a3134fbaf7829bc24b1d96017cf2bc046b7cd8b08b5775c33d0c 38fa94212a419a082e6a6b87a8e2ec4a44dd327d7069b85892a707e3fc818544 1a174fc216cccf18ec7d4fe14e008e30130b11ede0f0f94a87982e310cf2e765运行docker ps命令以验证5个容器正在运行。 CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES 1a174fc216cc acme/my-final-image:1.0 "bash" About a minute ago Up About a minute my_container_5 38fa94212a41 acme/my-final-image:1.0 "bash" About a minute ago Up About a minute my_container_4 1e7264576d78 acme/my-final-image:1.0 "bash" About a minute ago Up About a minute my_container_3 dcad7101795e acme/my-final-image:1.0 "bash" About a minute ago Up About a minute my_container_2 c36785c423ec acme/my-final-image:1.0 "bash" About a minute ago Up About a minute my_container_1
列出本地存储区的内容。 $ sudo ls /var/lib/docker/containers 1a174fc216cccf18ec7d4fe14e008e30130b11ede0f0f94a87982e310cf2e765 1e7264576d78a3134fbaf7829bc24b1d96017cf2bc046b7cd8b08b5775c33d0c 38fa94212a419a082e6a6b87a8e2ec4a44dd327d7069b85892a707e3fc818544 c36785c423ec7e0422b2af7364a7ba4da6146cbba7981a0951fcc3fa0430c409 dcad7101795e4206e637d9358a818e5c32e13b349e62b00bf05cd5a4343ea513
现在检查大小： $ sudo du -sh /var/lib/docker/containers/* 32K /var/lib/docker/containers/1a174fc216cccf18ec7d4fe14e008e30130b11ede0f0f94a87982e310cf2e765 32K /var/lib/docker/containers/1e7264576d78a3134fbaf7829bc24b1d96017cf2bc046b7cd8b08b5775c33d0c 32K /var/lib/docker/containers/38fa94212a419a082e6a6b87a8e2ec4a44dd327d7069b85892a707e3fc818544 32K /var/lib/docker/containers/c36785c423ec7e0422b2af7364a7ba4da6146cbba7981a0951fcc3fa0430c409 32K /var/lib/docker/containers/dcad7101795e4206e637d9358a818e5c32e13b349e62b00bf05cd5a4343ea513 这些容器中的每一个只占用文件系统上的32k空间。
不仅写入时复制节省空间，而且还缩短了启动时间。当你启动一个容器（或者来自同一个图像的多个容器）时，Docker只需要创建可写的容器层。
如果Docker在每次启动一个新容器时都必须制作底层映像堆栈的整个副本，则容器启动时间和使用的磁盘空间将显着增加。这与虚拟机的工作方式类似，每个虚拟机具有一个或多个虚拟磁盘。
数据体积和存储驱动程序
当容器被删除时，写入容器的任何未存储在数据卷中的数据将与容器一起被删除。
数据体积是直接安装到容器中的Docker主机文件系统中的目录或文件。数据卷不受存储驱动程序的控制。读取和写入数据卷绕过存储驱动程序并以本地主机速度运行。您可以将任意数量的数据卷装入容器。多个容器也可以共享一个或多个数据卷。
下图显示了一个运行两个容器的Docker主机。每个容器都存在于Docker主机本地存储区（/var/lib/docker/...）内自己的地址空间内。/dataDocker主机上还有一个共享数据卷。这被直接安装到两个容器中。
数据积位于Docker主机本地存储区域之外，进一步增强了它们与存储驱动程序控制的独立性。当容器被删除时，存储在数据卷中的任何数据都会保留在Docker主机上。
有关数据积的详细信息，请参阅管理容器中的数据。
相关信息
选择存储驱动程序
AUFS存储驱动程序在实践中
Btrfs存储驱动程序在实践中
Device Mapper存储驱动程序在实践中