存储驱动程序
为了有效地使用存储驱动，了解 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 镜像的容器。
存储驱动程序处理这些层如何相互作用的细节。有不同的存储驱动程序可供选择，它们在不同情况下各有优缺点。
容器和层
容器和镜像之间的主要区别在于顶部的可写层。所有对容器的写入，无论是添加新数据还是修改现有数据，都存储在这个可写层中。当容器被删除时，这个可写层也会被删除。底层的镜像保持不变。
因为每个容器都有自己的可写容器层，并且所有更改都存储在该容器层中，所以多个容器可以共享对相同底层镜像的访问，同时拥有各自的数据状态。下图显示了多个容器共享同一个 Ubuntu 15.04 镜像。
Docker 使用存储驱动来管理镜像层和可写容器层的内容。每种存储驱动的实现方式不同，但所有驱动都使用可堆叠的镜像层和写时复制（CoW）策略。
注意如果您需要多个容器共享访问完全相同的数据，请使用 Docker 数据卷。请参阅数据卷部分以了解有关数据卷的信息。
容器在磁盘上的大小
要查看运行中容器的大致大小，您可以使用 docker ps -s 命令。有两个不同的列与大小相关。
size：每个容器的可写层所使用的数据量（在磁盘上）。virtual size：容器使用的只读镜像数据量加上容器的可写层size。多个容器可能共享部分或全部只读镜像数据。从同一个镜像启动的两个容器共享 100% 的只读数据，而具有共同层的不同镜像的两个容器则共享这些共同层。因此，您不能简单地将虚拟大小相加。这会高估总磁盘使用量，其高估的量可能相当可观。
所有正在运行的容器在磁盘上使用的总空间是每个容器的 size 和 virtual size 值的某种组合。如果多个容器从完全相同的镜像启动，这些容器在磁盘上的总大小将是 SUM (容器的 size) 加上一个镜像的大小 (virtual size - size)。
这还不包括容器可能占用磁盘空间的以下额外方式：
- 由日志驱动存储的日志文件所占用的磁盘空间。如果您的容器产生大量日志数据且未配置日志轮换，这可能不是一个小数目。
- 容器使用的卷和绑定挂载。
- 容器配置文件占用的磁盘空间，这通常很小。
- 写入磁盘的内存（如果启用了交换）。
- 如果您正在使用实验性的检查点/恢复功能，则会产生检查点。
写时复制（CoW）策略
写时复制（Copy-on-write）是一种共享和复制文件以实现最高效率的策略。如果一个文件或目录存在于镜像的下层，而另一层（包括可写层）需要对其进行读访问，它就直接使用现有的文件。当另一层第一次需要修改该文件时（在构建镜像或运行容器时），该文件会被复制到那一层并进行修改。这最大限度地减少了 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/<storage-driver> 的内容。此示例使用 overlay2 存储驱动：
$ ls /var/lib/docker/overlay2
16802227a96c24dcbeab5b37821e2b67a9f921749cd9a2e386d5a6d5bc6fc6d3
377d73dbb466e0bc7c9ee23166771b35ebdbe02ef17753d79fd3571d4ce659d7
3f02d96212b03e3383160d31d7c6aeca750d2d8a1879965b89fe8146594c453d
ec1ec45792908e90484f7e629330666e7eee599f08729c93890a7205a6ba35f5
l
目录名称与层 ID 不对应。
现在想象一下，您有两个不同的 Dockerfile。您使用第一个来创建一个名为 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 已经拥有第一个镜像的所有层，所以它不需要再次拉取它们。这两个镜像共享它们共有的任何层。
如果您从这两个 Dockerfile 构建镜像，您可以使用 `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` 操作只在给定文件第一次被修改时发生一次，这在一定程度上缓解了这个问题。
为了验证写时复制的工作方式，以下过程将启动 5 个基于我们之前构建的 `acme/my-final-image:1.0` 镜像的容器，并检查它们占用了多少空间。
在您的 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使用 `docker ps` 命令并带上 `--size` 选项，以验证 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）文件系统或其他优化。使用此存储驱动时，会为每个容器创建镜像数据的完整副本。