存储驱动

要有效使用存储驱动程序，了解Docker如何构建和存储镜像，以及容器如何使用这些镜像非常重要。您可以使用这些信息来做出明智的选择，以最佳方式持久化应用程序的数据，并在此过程中避免性能问题。

存储驱动与Docker卷

Docker 使用存储驱动程序来存储镜像层，并在容器的可写层中存储数据。容器的可写层在容器删除后不会持久化，但适合存储运行时生成的临时数据。存储驱动程序针对空间效率进行了优化，但（取决于存储驱动程序）写入速度低于本地文件系统性能，特别是对于使用写时复制文件系统的存储驱动程序。写入密集型应用程序，如数据库存储，会受到性能开销的影响，特别是在只读层中存在预先存在的数据时。

对于写入密集型数据、必须在容器生命周期之外持久化的数据以及必须在容器之间共享的数据，请使用Docker卷。请参阅卷部分以了解如何使用卷来持久化数据并提高性能。

图像和图层

Docker 镜像由一系列层构建而成。每一层代表镜像 Dockerfile 中的一个指令。除了最后一层之外，每一层都是只读的。考虑以下 Dockerfile：

# syntax=docker/dockerfile:1

FROM ubuntu:22.04
LABEL org.opencontainers.image.authors="org@example.com"
COPY . /app
RUN make /app
RUN rm -r $HOME/.cache
CMD python /app/app.py

这个Dockerfile包含四个命令。修改文件系统的命令会创建一个新的层。FROM语句首先从ubuntu:22.04镜像创建一个层。LABEL命令只修改镜像的元数据，不会产生新的层。COPY命令从Docker客户端的当前目录添加一些文件。第一个RUN命令使用make命令构建你的应用程序，并将结果写入一个新的层。第二个RUN命令删除一个缓存目录，并将结果写入一个新的层。最后，CMD指令指定在容器内运行什么命令，它只修改镜像的元数据，不会产生镜像层。

每一层只是与前一层的差异集合。请注意，无论是添加还是删除文件都会生成一个新的层。在上面的例子中，$HOME/.cache目录被删除了，但它仍然可以在前一层中找到，并会增加镜像的总大小。请参考编写Dockerfile的最佳实践和使用多阶段构建部分，以了解如何优化您的Dockerfile以创建高效的镜像。

这些层是相互堆叠的。当你创建一个新的容器时，你会在底层之上添加一个新的可写层。这个层通常被称为“容器层”。所有对运行中的容器所做的更改，例如写入新文件、修改现有文件和删除文件，都会被写入到这个薄薄的可写容器层中。下图展示了一个基于ubuntu:15.04镜像的容器。

Layers of a container based on the Ubuntu image

存储驱动程序处理这些层之间交互方式的细节。有不同的存储驱动程序可用，它们在不同情况下各有优缺点。

容器和层

容器和镜像之间的主要区别在于顶部的可写层。所有向容器中添加新数据或修改现有数据的写入操作都存储在这个可写层中。当容器被删除时，可写层也会被删除。底层镜像保持不变。

因为每个容器都有自己的可写容器层，所有的更改都存储在这个容器层中，多个容器可以共享对同一个基础镜像的访问，同时拥有自己的数据状态。下图显示了多个容器共享同一个Ubuntu 15.04镜像。

Docker 使用存储驱动程序来管理镜像层和可写容器层的内容。每个存储驱动程序处理实现的方式不同，但所有驱动程序都使用可堆叠的镜像层和写时复制（CoW）策略。

注意
如果您需要多个容器共享访问完全相同的数据，请使用Docker卷。请参阅卷部分以了解关于卷的更多信息。

磁盘上的容器大小

要查看正在运行的容器的大致大小，您可以使用docker ps -s命令。有两个不同的列与大小相关。

size: 用于每个容器的可写层的数据量（在磁盘上）。
virtual size: 用于容器的只读镜像数据量加上容器的可写层size。多个容器可能共享部分或全部只读镜像数据。从同一镜像启动的两个容器共享100%的只读数据，而具有不同镜像但共享某些层的两个容器共享这些共同层。因此，你不能简单地将虚拟大小相加。这会高估总磁盘使用量，可能高估的量不小。

磁盘上所有运行容器使用的总磁盘空间是每个容器的size和virtual size值的某种组合。如果多个容器从完全相同的镜像启动，这些容器在磁盘上的总大小将是SUM（容器的size）加上一个镜像大小（virtual size - size）。

这还不包括容器可能占用磁盘空间的以下额外方式：

用于存储由logging-driver生成的日志文件的磁盘空间。如果您的容器生成大量日志数据且未配置日志轮换，这可能非常重要。
容器使用的卷和绑定挂载。
用于容器配置文件的磁盘空间，这些文件通常很小。
写入磁盘的内存（如果启用了交换）。
检查点，如果您正在使用实验性的检查点/恢复功能。

写时复制（CoW）策略

写时复制是一种共享和复制文件的策略，以实现最大效率。如果文件或目录存在于镜像的较低层中，而另一层（包括可写层）需要读取访问权限，它只需使用现有文件。当另一层首次需要修改文件时（在构建镜像或运行容器时），文件会被复制到该层并进行修改。这最大限度地减少了I/O和每个后续层的大小。这些优势将在下面更详细地解释。

当你使用docker pull从仓库拉取镜像时，或者当你从本地尚不存在的镜像创建容器时，每一层都会被单独拉取，并存储在Docker的本地存储区域，通常在Linux主机上是/var/lib/docker/。你可以在这个例子中看到这些层被拉取的过程：

$ docker pull ubuntu:22.04
22.04: Pulling from library/ubuntu
f476d66f5408: Pull complete
8882c27f669e: Pull complete
d9af21273955: Pull complete
f5029279ec12: Pull complete
Digest: sha256:6120be6a2b7ce665d0cbddc3ce6eae60fe94637c6a66985312d1f02f63cc0bcd
Status: Downloaded newer image for ubuntu:22.04
docker.io/library/ubuntu:22.04

每一层都存储在Docker主机本地存储区域内的各自目录中。要检查文件系统上的层，请列出/var/lib/docker/的内容。此示例使用overlay2存储驱动：

$ ls /var/lib/docker/overlay2
16802227a96c24dcbeab5b37821e2b67a9f921749cd9a2e386d5a6d5bc6fc6d3
377d73dbb466e0bc7c9ee23166771b35ebdbe02ef17753d79fd3571d4ce659d7
3f02d96212b03e3383160d31d7c6aeca750d2d8a1879965b89fe8146594c453d
ec1ec45792908e90484f7e629330666e7eee599f08729c93890a7205a6ba35f5
l

目录名称与图层ID不匹配。

现在想象一下，你有两个不同的Dockerfiles。你使用第一个来创建一个名为acme/my-base-image:1.0的镜像。

# syntax=docker/dockerfile:1
FROM alpine
RUN apk add --no-cache bash

第二个是基于 acme/my-base-image:1.0，但有一些额外的层：

# syntax=docker/dockerfile:1
FROM acme/my-base-image:1.0
COPY . /app
RUN chmod +x /app/hello.sh
CMD /app/hello.sh

第二张图片包含了第一张图片的所有层，加上由COPY和RUN指令创建的新层，以及一个读写容器层。Docker已经拥有第一张图片的所有层，因此不需要再次拉取它们。这两张图片共享它们共有的任何层。

如果你从这两个Dockerfiles构建镜像，你可以使用docker image ls和docker image history命令来验证共享层的加密ID是否相同。

创建一个新目录 cow-test/ 并切换到该目录。
在cow-test/目录中，创建一个名为hello.sh的新文件，内容如下。
#!/usr/bin/env bash echo "Hello world"
将上述第一个Dockerfile的内容复制到一个名为Dockerfile.base的新文件中。
将上述第二个Dockerfile的内容复制到一个名为Dockerfile的新文件中。

在cow-test/目录中，构建第一个镜像。不要忘记在命令中包含最后的.。这设置了PATH，告诉Docker在哪里查找需要添加到镜像中的任何文件。

$ docker build -t acme/my-base-image:1.0 -f Dockerfile.base .
[+] Building 6.0s (11/11) FINISHED
=> [internal] load build definition from Dockerfile.base                                      0.4s
=> => transferring dockerfile: 116B                                                           0.0s
=> [internal] load .dockerignore                                                              0.3s
=> => transferring context: 2B                                                                0.0s
=> resolve image config for docker.io/docker/dockerfile:1                                     1.5s
=> [auth] docker/dockerfile:pull token for registry-1.docker.io                               0.0s
=> CACHED docker-image://docker.io/docker/dockerfile:1@sha256:9e2c9eca7367393aecc68795c671... 0.0s
=> [internal] load .dockerignore                                                              0.0s
=> [internal] load build definition from Dockerfile.base                                      0.0s
=> [internal] load metadata for docker.io/library/alpine:latest                               0.0s
=> CACHED [1/2] FROM docker.io/library/alpine                                                 0.0s
=> [2/2] RUN apk add --no-cache bash                                                          3.1s
=> exporting to image                                                                         0.2s
=> => exporting layers                                                                        0.2s
=> => writing image sha256:da3cf8df55ee9777ddcd5afc40fffc3ead816bda99430bad2257de4459625eaa   0.0s
=> => naming to docker.io/acme/my-base-image:1.0                                              0.0s

构建第二张图片。

$ docker build -t acme/my-final-image:1.0 -f Dockerfile .

[+] Building 3.6s (12/12) FINISHED
=> [internal] load build definition from Dockerfile                                            0.1s
=> => transferring dockerfile: 156B                                                            0.0s
=> [internal] load .dockerignore                                                               0.1s
=> => transferring context: 2B                                                                 0.0s
=> resolve image config for docker.io/docker/dockerfile:1                                      0.5s
=> CACHED docker-image://docker.io/docker/dockerfile:1@sha256:9e2c9eca7367393aecc68795c671...  0.0s
=> [internal] load .dockerignore                                                               0.0s
=> [internal] load build definition from Dockerfile                                            0.0s
=> [internal] load metadata for docker.io/acme/my-base-image:1.0                               0.0s
=> [internal] load build context                                                               0.2s
=> => transferring context: 340B                                                               0.0s
=> [1/3] FROM docker.io/acme/my-base-image:1.0                                                 0.2s
=> [2/3] COPY . /app                                                                           0.1s
=> [3/3] RUN chmod +x /app/hello.sh                                                            0.4s
=> exporting to image                                                                          0.1s
=> => exporting layers                                                                         0.1s
=> => writing image sha256:8bd85c42fa7ff6b33902ada7dcefaaae112bf5673873a089d73583b0074313dd    0.0s
=> => naming to docker.io/acme/my-final-image:1.0                                              0.0s

查看图片的大小。

$ docker image ls

REPOSITORY             TAG     IMAGE ID         CREATED               SIZE
acme/my-final-image    1.0     8bd85c42fa7f     About a minute ago    7.75MB
acme/my-base-image     1.0     da3cf8df55ee     2 minutes ago         7.75MB

查看每张图片的历史记录。

$ docker image history acme/my-base-image:1.0

IMAGE          CREATED         CREATED BY                                      SIZE      COMMENT
da3cf8df55ee   5 minutes ago   RUN /bin/sh -c apk add --no-cache bash # bui…   2.15MB    buildkit.dockerfile.v0
<missing>      7 weeks ago     /bin/sh -c #(nop)  CMD ["/bin/sh"]              0B
<missing>      7 weeks ago     /bin/sh -c #(nop) ADD file:f278386b0cef68136…   5.6MB

有些步骤没有大小（0B），并且只是元数据的更改，这些更改不会生成镜像层，除了元数据本身外，不会占用任何大小。上面的输出显示此镜像由2个镜像层组成。

$ docker image history  acme/my-final-image:1.0

IMAGE          CREATED         CREATED BY                                      SIZE      COMMENT
8bd85c42fa7f   3 minutes ago   CMD ["/bin/sh" "-c" "/app/hello.sh"]            0B        buildkit.dockerfile.v0
<missing>      3 minutes ago   RUN /bin/sh -c chmod +x /app/hello.sh # buil…   39B       buildkit.dockerfile.v0
<missing>      3 minutes ago   COPY . /app # buildkit                          222B      buildkit.dockerfile.v0
<missing>      4 minutes ago   RUN /bin/sh -c apk add --no-cache bash # bui…   2.15MB    buildkit.dockerfile.v0
<missing>      7 weeks ago     /bin/sh -c #(nop)  CMD ["/bin/sh"]              0B
<missing>      7 weeks ago     /bin/sh -c #(nop) ADD file:f278386b0cef68136…   5.6MB

请注意，第一张图像的所有步骤也包含在最终图像中。最终图像包括第一张图像中的两个层，以及第二张图像中添加的两个层。

docker history 输出中的行表示这些步骤要么是在另一个系统上构建的，并且是来自 Docker Hub 的 alpine 镜像的一部分，要么是使用 BuildKit 作为构建器构建的。在 BuildKit 之前，“经典”构建器会为每个步骤生成一个新的“中间”镜像以用于缓存目的，而 IMAGE 列将显示该镜像的 ID。

BuildKit 使用其自己的缓存机制，不再需要中间镜像进行缓存。请参阅 BuildKit 以了解更多关于 BuildKit 的其他改进。

查看每张图像的图层
使用 docker image inspect 命令查看每个镜像中层的加密ID：
$ docker image inspect --format "{{json .RootFS.Layers}}" acme/my-base-image:1.0 [ "sha256:72e830a4dff5f0d5225cdc0a320e85ab1ce06ea5673acfe8d83a7645cbd0e9cf", "sha256:07b4a9068b6af337e8b8f1f1dae3dd14185b2c0003a9a1f0a6fd2587495b204a" ]
$ docker image inspect --format "{{json .RootFS.Layers}}" acme/my-final-image:1.0 [ "sha256:72e830a4dff5f0d5225cdc0a320e85ab1ce06ea5673acfe8d83a7645cbd0e9cf", "sha256:07b4a9068b6af337e8b8f1f1dae3dd14185b2c0003a9a1f0a6fd2587495b204a", "sha256:cc644054967e516db4689b5282ee98e4bc4b11ea2255c9630309f559ab96562e", "sha256:e84fb818852626e89a09f5143dbc31fe7f0e0a6a24cd8d2eb68062b904337af4" ]
请注意，前两层在两个图像中是相同的。第二个图像添加了两个额外的层。共享的图像层仅在/var/lib/docker/中存储一次，并且在将图像推送到图像注册表或从图像注册表拉取时也会共享。因此，共享的图像层可以减少网络带宽和存储。
提示
使用--format选项格式化Docker命令的输出。
上面的示例使用docker image inspect命令和--format选项查看层ID，格式化为JSON数组。Docker命令上的--format选项可以是一个强大的功能，允许您从输出中提取和格式化特定信息，而不需要额外的工具，如awk或sed。要了解更多关于使用--format标志格式化docker命令输出的信息，请参阅格式命令和日志输出部分。我们还使用jq实用程序来美化JSON输出以提高可读性。

复制使容器高效

当你启动一个容器时，一个薄的可写容器层会被添加到其他层的顶部。容器对文件系统所做的任何更改都会存储在这里。容器未更改的任何文件都不会被复制到这个可写层。这意味着可写层尽可能小。

当容器中的现有文件被修改时，存储驱动程序会执行写时复制操作。具体涉及的步骤取决于特定的存储驱动程序。对于overlay2驱动程序，写时复制操作大致遵循以下顺序：

搜索图像层以查找要更新的文件。该过程从最新层开始，逐层向下工作到基础层。当找到结果时，它们会被添加到缓存中以加速未来的操作。
对找到的文件的第一个副本执行copy_up操作，以将文件复制到容器的可写层。
对此文件的副本进行的任何修改，容器都无法看到存在于较低层中的只读文件副本。

Btrfs、ZFS和其他驱动程序处理写时复制的方式不同。您可以在后面的详细描述中阅读更多关于这些驱动程序的方法。

写入大量数据的容器比不写入数据的容器消耗更多的空间。这是因为大多数写操作都会在容器的薄可写顶层消耗新的空间。请注意，更改文件的元数据，例如更改文件权限或文件所有权，也可能导致copy_up操作，从而将文件复制到可写层。

提示
对于写操作频繁的应用程序使用卷。
对于写操作频繁的应用程序，不要将数据存储在容器中。例如，写密集型数据库等应用程序，在只读层中存在预先存在的数据时，尤其容易出现问题。
相反，使用Docker卷，它们独立于运行中的容器，并且设计为I/O高效。此外，卷可以在容器之间共享，并且不会增加容器可写层的大小。请参阅使用卷部分以了解卷。

一个copy_up操作可能会引起明显的性能开销。这种开销根据使用的存储驱动程序而有所不同。大文件、多层和深目录树可能会使影响更加明显。这种情况通过每个copy_up操作仅在首次修改给定文件时发生的事实得到缓解。

为了验证写时复制的工作方式，以下过程基于我们之前构建的acme/my-final-image:1.0镜像启动了5个容器，并检查它们占用了多少空间。

从您的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

40ebdd7634162eb42bdb1ba76a395095527e9c0aa40348e6c325bd0aa289423c
a5ff32e2b551168b9498870faf16c9cd0af820edf8a5c157f7b80da59d01a107
3ed3c1a10430e09f253704116965b01ca920202d52f3bf381fbb833b8ae356bc
939b3bf9e7ece24bcffec57d974c939da2bdcc6a5077b5459c897c1e2fa37a39
cddae31c314fbab3f7eabeb9b26733838187abc9a2ed53f97bd5b04cd7984a5a

运行带有--size选项的docker ps命令，以验证5个容器是否正在运行，并查看每个容器的大小。

$ docker ps --size --format "table {{.ID}}\t{{.Image}}\t{{.Names}}\t{{.Size}}"

CONTAINER ID   IMAGE                     NAMES            SIZE
cddae31c314f   acme/my-final-image:1.0   my_container_5   0B (virtual 7.75MB)
939b3bf9e7ec   acme/my-final-image:1.0   my_container_4   0B (virtual 7.75MB)
3ed3c1a10430   acme/my-final-image:1.0   my_container_3   0B (virtual 7.75MB)
a5ff32e2b551   acme/my-final-image:1.0   my_container_2   0B (virtual 7.75MB)
40ebdd763416   acme/my-final-image:1.0   my_container_1   0B (virtual 7.75MB)

上面的输出显示，所有容器共享镜像的只读层（7.75MB），但没有数据写入容器的文件系统，因此没有为容器使用额外的存储空间。

注意
此步骤需要一台Linux机器，并且不能在Docker Desktop上运行，因为它需要访问Docker守护进程的文件存储。

虽然docker ps的输出提供了有关容器可写层消耗的磁盘空间的信息，但它不包括有关为每个容器存储的元数据和日志文件的信息。

更多详细信息可以通过探索Docker守护进程的存储位置（默认为/var/lib/docker）获得。

$ sudo du -sh /var/lib/docker/containers/*

36K  /var/lib/docker/containers/3ed3c1a10430e09f253704116965b01ca920202d52f3bf381fbb833b8ae356bc
36K  /var/lib/docker/containers/40ebdd7634162eb42bdb1ba76a395095527e9c0aa40348e6c325bd0aa289423c
36K  /var/lib/docker/containers/939b3bf9e7ece24bcffec57d974c939da2bdcc6a5077b5459c897c1e2fa37a39
36K  /var/lib/docker/containers/a5ff32e2b551168b9498870faf16c9cd0af820edf8a5c157f7b80da59d01a107
36K  /var/lib/docker/containers/cddae31c314fbab3f7eabeb9b26733838187abc9a2ed53f97bd5b04cd7984a5a

这些容器中的每一个在文件系统上只占用36k的空间。

每个容器的存储

为了演示这一点，运行以下命令将单词'hello'写入容器my_container_1、my_container_2和my_container_3的可写层中的文件：

$ for i in {1..3}; do docker exec my_container_$i sh -c 'printf hello > /out.txt'; done

之后再次运行docker ps命令显示这些容器现在各自消耗5字节。这些数据对每个容器都是唯一的，不共享。容器的只读层不受影响，仍然由所有容器共享。

$ docker ps --size --format "table {{.ID}}\t{{.Image}}\t{{.Names}}\t{{.Size}}"

CONTAINER ID   IMAGE                     NAMES            SIZE
cddae31c314f   acme/my-final-image:1.0   my_container_5   0B (virtual 7.75MB)
939b3bf9e7ec   acme/my-final-image:1.0   my_container_4   0B (virtual 7.75MB)
3ed3c1a10430   acme/my-final-image:1.0   my_container_3   5B (virtual 7.75MB)
a5ff32e2b551   acme/my-final-image:1.0   my_container_2   5B (virtual 7.75MB)
40ebdd763416   acme/my-final-image:1.0   my_container_1   5B (virtual 7.75MB)

前面的例子说明了写时复制文件系统如何帮助使容器变得高效。写时复制不仅节省空间，还减少了容器的启动时间。当你创建一个容器（或从同一镜像创建多个容器）时，Docker只需要创建薄的可写容器层。

如果 Docker 每次创建新容器时都必须复制整个底层镜像堆栈，那么容器创建时间和使用的磁盘空间将显著增加。这将类似于虚拟机的工作方式，每个虚拟机有一个或多个虚拟磁盘。vfs 存储不提供写时复制（CoW）文件系统或其他优化。使用此存储驱动程序时，会为每个容器创建镜像数据的完整副本。