关于存储驱动程序
为了有效地使用存储驱动程序，了解 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值的某种组合。如果多个容器从同一个镜像启动，这些容器在磁盘上的总大小将是（size容器的）SUM 加上一个镜像大小 ( virtual size- size)。
这也不计算容器占用磁盘空间的以下其他方式：
- 用于由logging-driver存储日志文件的磁盘空间。如果您的容器生成大量日志数据并且未配置日志轮换，那么这可能很重要。
- 容器使用的卷和绑定安装。
- 用于容器配置文件的磁盘空间，通常很小。
- 内存写入磁盘（如果启用交换）。
- 检查点，如果您使用实验性检查点/恢复功能。
写时复制 (CoW) 策略
写时复制是一种共享和复制文件以实现最高效率的策略。如果文件或目录存在于图像内的较低层，并且另一层（包括可写层）需要对其进行读取访问，则它仅使用现有文件。当另一层第一次需要修改文件时（构建映像或运行容器时），文件将被复制到该层并进行修改。这最大限度地减少了 I/O 和每个后续层的大小。下面将更深入地解释这些优点。
共享促进更小的图像
当您docker pull从存储库中拉取镜像时，或者从本地尚不存在的镜像创建容器时，每一层都会单独拉取，并存储在 Docker 的本地存储区域中，该存储区域通常位于/var/lib/docker/Linux 主机上。您可以在本例中看到这些层被拉动：
$ 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请注意，第一张图像的所有步骤也包含在最终图像中。最终图像包括第一幅图像中的两个层以及第二个图像中添加的两个层。
<missing>输出中的行表明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/并且在将镜像推送和拉取到镜像注册表时也会被共享。因此，共享图像层可以减少网络带宽和存储。提示
使用选项格式化 Docker 命令的输出
--format。上面的示例使用
docker image inspect带有选项的命令--format来查看图层 ID（格式为 JSON 数组）。 Docker 命令上的选项--format是一个强大的功能，允许您从输出中提取和格式化特定信息，而不需要额外的工具，例如awk或sed。要了解有关使用标志格式化 docker 命令输出的更多信息--format，请参阅 格式命令和日志输出部分。我们还使用该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运行该
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 Daemon 的文件存储。
虽然输出为
docker ps您提供有关容器可写层消耗的磁盘空间的信息，但它不包括有关为每个容器存储的元数据和日志文件的信息。可以通过探索 Docker Daemon 的存储位置（
/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 空间。
每个容器的存储
my_container_1为了演示这一点，请运行以下命令将单词“hello”写入容器、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 文件系统或其他优化。使用此存储驱动程序时，将为每个容器创建图像数据的完整副本。