1. 从一次镜像拉取卡顿说起：为什么需要搞懂加载原理很多人用 Docker 的第一课就是docker pull，然后docker run，容器跑起来了，任务就算完成。直到某天你发现：同一个镜像，在测试机上拉取只要十几秒，在生产环境却卡了五分钟；或者你明明只改了一行代码重新构建，推送的层却有好几百 MB；又或者磁盘空间莫名其妙被吃满，docker images一看，一堆<none>标签的悬空镜像堆在那里。这些问题表面上看是"网络慢""磁盘小"，但根子上都指向同一件事——你没有真正理解 Docker 镜像是怎么被加载和组织的。我自己刚开始接触容器的时候，也走过一段弯路。当时以为镜像就是一个打包好的压缩文件，拉下来解压就能用。后来在一个离线部署的场景里，需要把镜像从一台机器搬到另一台机器，我天真地直接拷贝了/var/lib/docker目录，结果目标机器上镜像列表是有了，但一运行就报错，层校验对不上。那次折腾了整整一个下午，才把镜像分层和加载机制彻底搞清楚。这篇文章就是把我踩过的这些坑、以及后来总结出来的原理和实操经验，系统地梳理一遍。核心围绕Docker 镜像加载原理展开，会讲到镜像的分层结构、内容寻址机制、联合文件系统怎么把一堆只读层"拼"成一个可用的根文件系统、docker pull和docker load背后的完整链路，以及在实际工作中怎么利用这些原理去排查问题、优化构建、清理空间。适合谁看？如果你已经会用 Docker 基本命令，但对"镜像为什么这么大""层是怎么复用的""加载时到底发生了什么"这些问题还模棱两可，那这篇内容就是为你准备的。如果你是完全的新手，也没关系，我会尽量用生活化的类比把底层机制讲清楚，保证你能看懂、能上手验证。需要提前说明的是，本文涉及的原理和操作，都是基于常见的 Linux 环境下的容器运行时实践总结而来，不同版本、不同存储驱动在细节上会有差异，但核心思路是一致的。下面我们正式进入正题。2. 镜像不是"一个文件"：分层结构与内容寻址的本质2.1 用"千层饼"理解镜像的分层很多人对镜像的第一个误解，就是把它当成一个整体。实际上，一个 Docker 镜像是由**一系列只读层（layer）叠加而成的。你可以把它想象成一张千层饼：最底下是基础层，比如一个精简的操作系统根文件系统；往上一层是运行时环境，比如某种语言的解释器；再往上是依赖库；最上面是你自己的应用代码。每一层都是只读的，层与层之间通过一种叫联合文件系统（Union File System）**的机制叠加在一起，对外呈现为一个完整的文件系统视图。这里有个关键点：每一层只记录相对于上一层的差异。也就是说，如果你在第一层装了一个包，第二层又删掉了它，第二层记录的并不是"删除"这个动作本身，而是记录了一个"白障文件"（whiteout），用来在联合挂载时屏蔽掉下层的那个文件。这个设计非常巧妙，它保证了层一旦生成就永远不可变，从而可以被安全地共享和复用。为什么这么设计？因为不可变意味着可以缓存、可以复用、可以并行分发。你想想，如果每一层都能被随意修改，那多个镜像共享同一层的时候就乱套了。正是因为层不可变，Docker 才能做到：十个镜像如果都基于同一个基础镜像，那这个基础层在磁盘上只存一份，在网络上传输时也只传一次。2.2 内容寻址：层的"身份证"是怎么算出来的每一层都有一个唯一的标识，叫DiffID和ChainID，最终对外暴露的是我们熟悉的镜像层摘要（digest）。这个摘要是怎么来的？简单说，就是对层的内容做一次哈希计算（通常是 SHA256），内容一样，哈希就一样；内容变一个字节，哈希就完全不同。这就是所谓的内容寻址（Content Addressable Storage）。它的好处是：你不需要给层起名字，也不需要维护一个中心化的命名表，只要拿到哈希值，就能唯一确定这一层的内容。这也解释了为什么镜像摘要（比如sha256:abc123...）可以用来做完整性校验——拉取下来的层，重新算一遍哈希，和清单里记录的对不上，就说明传输过程中出了问题。我在离线搬运镜像的时候就吃过这个亏。当时直接拷贝目录，绕过了校验环节，结果某个层在拷贝过程中损坏了，运行时才报错。后来改用docker save导出成 tar 包，再docker load导入，这个过程会做完整性校验，问题就暴露在加载阶段，而不是等到运行时才炸。2.3 镜像清单：层的"目录索引"光有层还不够，还需要一个东西来记录"这个镜像由哪些层组成、顺序是什么、每一层对应哪个哈希"。这个角色由**镜像清单（manifest）和配置对象（config）**来承担。配置对象里记录了镜像的元数据：环境变量、启动命令、工作目录、暴露端口等等。清单则记录了配置对象的摘要，以及所有层的摘要列表。当你执行docker pull时，实际上是先拉取清单，再根据清单里的摘要去拉取每一层。这个顺序很重要，因为它决定了拉取是可以并行的——清单拿到后，所有层的下载任务可以同时发起。理解了这一层，你就能明白为什么有时候docker pull会显示多个进度条同时跑，也能明白为什么"拉取清单失败"和"拉取某一层失败"是两个不同性质的错误。3. 联合文件系统如何把只读层"拼"成可写容器3.1 从只读层到可写层：容器启动时的关键一步镜像本身全是只读层，但容器运行时需要能写文件。这个矛盾怎么解决？答案是：在只读层的最上面，再叠加一个可写层（容器层）。所有对容器的写操作，都发生在这一层里。这就是所谓的**写时复制（Copy-on-Write，CoW）**机制。具体来说，当容器里的进程要修改一个位于只读层的文件时，联合文件系统会先把那个文件复制到可写层，然后在可写层里做修改。原来的只读层纹丝不动。这样做的好处是：镜像层可以被无数个容器共享，每个容器只额外占用自己可写层的空间。我经常用一个类比来解释这件事：镜像层就像图书馆里的参考书，谁都不能在上面涂改；容器层就像你借书时附带的笔记本，你想怎么记就怎么记，但笔记本上只记录你写的内容，不会把整本书抄一遍。所以一个基于大镜像启动的容器，如果只改了几个小文件，它实际占用的额外空间可能只有几 MB。3.2 不同存储驱动的差异：overlay2 为什么成为主流联合文件系统的具体实现，在 Linux 上有多种，Docker 把它们抽象成存储驱动（storage driver）。常见的有 overlay2、aufs、btrfs、zfs、devicemapper 等。目前绝大多数 Linux 发行版上，默认和推荐的都是overlay2。overlay2 的工作原理是：用lowerdir表示所有只读层，用upperdir表示可写层，再用一个merged目录把两者合并挂载，对外呈现统一视图。当你读一个文件时，如果 upperdir 里有就用 upperdir 的，没有就往下层找；当你写一个文件时，如果文件在下层，就先复制到 upperdir 再写。为什么 overlay2 能成为主流？主要是它在性能和稳定性之间取得了比较好的平衡，而且已经进入 Linux 主线内核，不需要额外打补丁。相比之下，早期的 aufs 需要单独的内核补丁，devicemapper 在空间管理上比较笨重。不过 overlay2 也有它的限制，比如对多层嵌套的支持不如某些驱动灵活，早期版本对 inode 数量也比较敏感。这里给一个实操建议：如果你在排查容器文件系统相关的诡异问题，第一件事就是确认当前用的存储驱动。docker info | grep "Storage Driver"不同驱动的行为差异，往往就是问题根源。3.3 层数过多的代价：为什么构建时要合并指令理解了分层机制，就能明白一个常见的构建优化原则：尽量减少层数。因为每一层都有元数据开销，层数太多会导致联合挂载时的查找变慢，镜像清单也变长。更重要的是，某些存储驱动对层数有上限限制。这就是为什么在写 Dockerfile 时，我们习惯把多个RUN指令用&&合并成一条。比如：RUN apt-get update && \ apt-get install -y curl git && \ rm -rf /var/lib/apt/lists/*这条指令只产生一层。如果拆成三条RUN，就会产生三层，而且中间层里还残留着包管理器的缓存，白白增大镜像体积。合并之后，清理动作和安装动作在同一层完成，缓存根本不会进入最终镜像。不过这里要提醒一句：合并指令不是越多越好。过度合并会让单层变得巨大，构建时的缓存粒度也变粗——改一个小地方，整层都要重建。所以实际项目中要权衡：变化频率相近的操作放一层，变化频率差异大的分开。比如系统依赖安装放一层（很少变），应用代码拷贝放另一层（经常变），这样改代码时不会触发依赖重装。4. docker pull 背后的完整链路拆解4.1 从仓库到本地：一次拉取经历了什么docker pull看起来只是一条命令，背后其实是一套完整的协商和传输流程。我把它拆成几个阶段：第一阶段是认证与协商。客户端先和镜像仓库建立连接，确认自己有没有权限拉取这个镜像。如果是公开镜像，这一步基本透明；如果是私有仓库，就需要凭据。协商阶段还会确认客户端支持的清单格式，比如是传统的 schema2 还是更新的 OCI 格式。第二阶段是拉取清单。客户端拿到镜像的清单文件，里面列出了配置对象和所有层的摘要。这一步很快，因为清单本身很小。第三阶段是并行拉取层。根据清单里的摘要列表，客户端检查本地是否已经存在这些层。已经存在的直接跳过，不存在的才发起下载。这就是为什么第二次拉取同一个基础镜像时几乎瞬间完成——层已经在本地了。第四阶段是校验与落盘。每一层下载完成后，客户端会重新计算哈希，和清单里的摘要比对。校验通过后，层被解压并写入本地存储目录。注意，这里有个容易忽略的点：传输时层是压缩的，落盘时是解压的。所以你会看到下载进度显示的大小，和最终磁盘占用不完全一致。4.2 层复用：为什么拉取能"跳过"大部分内容层复用是 Docker 镜像机制最实用的特性之一。假设你有三个镜像，都基于同一个基础镜像，那么这三个镜像在本地共享同一个基础层。拉取第三个镜像时，如果它的基础层和依赖层都已经存在，实际需要下载的可能只有最上面那几层应用代码。这个机制在 CI/CD 场景里价值巨大。构建流水线里，如果每次都从零拉取所有层，时间和带宽成本会非常高。而有了层复用，只要基础镜像没变，大部分层都能命中本地缓存。但层复用也有它的边界。只要层内容变了一个字节，哈希就变了，复用就失效。这就是为什么在 Dockerfile 里，把经常变化的指令放在后面很重要。如果你把应用代码拷贝放在最前面，那每次改代码都会导致后面所有层重建，缓存全部失效。正确的顺序是：先装依赖（很少变），再拷代码（经常变）。4.3 拉取失败的常见原因与排查思路拉取失败的原因五花八门，但按发生阶段可以归类。我整理了一个排查表，方便对照：失败阶段典型现象常见原因排查方向认证阶段提示未授权凭据过期或权限不足检查登录状态和仓库权限拉取清单提示清单不存在标签写错或镜像被删确认镜像名和标签拼写拉取层某个层卡住或超时网络不稳定或层较大重试、检查网络、分时段拉取校验阶段提示摘要不匹配传输损坏或本地存储异常清理本地缓存后重试落盘阶段提示磁盘空间不足存储目录空间不够清理悬空镜像和停止的容器这里分享一个我自己的经验：遇到拉取卡在某一层不动，先别急着重试，可以看看是不是本地磁盘快满了。因为落盘阶段需要空间解压，空间不足时表现出的现象可能就是"卡住"。另外，docker system df可以快速查看镜像、容器、卷各自占用的空间，比手动du方便得多。5. docker load 与离线搬运：镜像在机器之间怎么"搬家"5.1 save 和 load 的配对使用在没有外网或者网络受限的环境里，镜像搬运靠的是docker save和docker load这一对命令。docker save把一个或多个镜像导出成一个 tar 归档，docker load则把这个归档导入本地。# 导出镜像到文件 docker save -o myapp.tar myapp:1.0 # 在目标机器上导入 docker load -i myapp.tar这里有个细节值得注意：docker save导出的 tar 包里，包含了镜像的所有层和清单信息。导入时，docker load会逐层校验哈希，确保内容完整。这就是它比直接拷贝存储目录可靠的原因——拷贝目录绕过了校验，而 save/load 把校验内建在流程里。5.2 导出体积为什么比镜像显示的大很多人第一次用docker save会惊讶：docker images显示镜像 500MB，导出的 tar 包却有 1GB 多。这是正常的，原因有两个。第一，docker images显示的是压缩后的层大小之和，而docker save导出的是解压后的内容。压缩比通常在 2:1 到 3:1 之间，所以导出文件偏大是正常的。第二，如果导出多个镜像，它们共享的层在 tar 包里只会存一份，但每个镜像的清单都会引用它。所以导出多个镜像时，总体积并不是简单相加。如果你需要控制导出体积，可以在导出后再用通用压缩工具压一遍：docker save myapp:1.0 | gzip > myapp.tar.gz docker load -i myapp.tar.gzdocker load能自动识别 gzip 压缩的输入，不需要先解压。5.3 离线搬运的完整操作清单把镜像从一台机器搬到另一台，我总结了一套固定流程，照着做基本不会出问题：在源机器上确认镜像名称和标签，用docker images核对。执行docker save导出，建议同时用 gzip 压缩。计算导出文件的校验和，比如sha256sum，记录下来。传输文件到目标机器。在目标机器上重新计算校验和，和源端比对，确认传输无损。执行docker load导入。用docker images确认镜像已存在，并核对镜像 ID。启动一个测试容器，验证镜像可正常运行。第 3 步和第 5 步的校验和比对，是我强烈建议加上的。传输大文件时，静默损坏的概率虽然不高，但一旦发生，排查起来非常痛苦。提前比对校验和，能把问题挡在加载之前。6. 镜像加载原理在实际工作中的几个应用场景6.1 排查"镜像明明在，运行却报错"有一种情况很让人困惑：docker images里明明能看到镜像，docker run却报错说找不到或者层损坏。这通常和悬空镜像或层引用断裂有关。悬空镜像（dangling image）是指那些没有标签、也没有被任何镜像引用的层。它们通常是被新构建覆盖掉的旧版本。正常情况下它们不影响使用，但如果存储驱动在垃圾回收时出了问题，可能导致某些层被误删，进而让引用它的镜像无法运行。排查思路是：先用docker images -a看看有没有大量<none>标签的镜像，再用docker image inspect检查目标镜像的层是否完整。如果确认是层损坏，最稳妥的办法是删掉镜像重新拉取或重新加载。# 查看悬空镜像 docker images -f "dangling=true" # 清理悬空镜像 docker image prune注意：docker image prune默认只清理悬空镜像，加-a会清理所有未被容器使用的镜像，操作前务必确认没有正在依赖的镜像。6.2 优化构建：让层缓存尽可能命中理解了层复用机制，优化构建就有了明确方向。核心原则是：把变化频率低的操作放在前面，变化频率高的放在后面。一个典型的优化前后对比：优化前，先拷贝代码再装依赖，每次改代码都要重装依赖，构建时间几分钟。优化后，先拷贝依赖描述文件（比如某种语言的依赖清单），装完依赖再拷贝代码。这样只要依赖清单没变，依赖层就一直命中缓存，改代码只重建最上面一层，构建时间降到几秒。这个技巧在依赖安装耗时的项目里效果尤其明显。我见过一个项目，优化前每次构建要八分钟，调整 Dockerfile 指令顺序后降到四十秒，团队里所有人都松了口气。6.3 磁盘空间治理：从原理出发的清理策略磁盘被镜像吃满，是运维常见问题。理解了分层和引用机制，清理就有章法了。首先要区分三类占用：镜像层、容器可写层、数据卷。docker system df能给出总览。清理时按优先级来：先清理停止的容器，它们各自占着可写层。再清理悬空镜像，它们没有标签，通常可以安全删除。然后清理未被使用的镜像，这一步要谨慎，确认没有项目依赖。最后考虑数据卷，但数据卷里可能有重要数据，删之前一定要确认。# 查看空间占用总览 docker system df # 清理停止的容器、悬空镜像、未使用的网络 docker system prune # 更彻底的清理，包括未使用的镜像 docker system prune -a提示：docker system prune -a会删除所有未被运行中容器使用的镜像，包括你手动拉取但暂时没用的。执行前最好先docker images看一眼，避免误删。我自己的习惯是，定期跑一次docker system df，心里有个数。如果发现悬空镜像占比很高，说明构建频繁且没有及时清理，可以考虑在 CI 流程里加一步自动清理。7. 几个容易混淆的概念澄清7.1 镜像 ID 和层摘要不是一回事新手容易把镜像 ID 和层摘要搞混。镜像 ID 是配置对象的摘要，它代表的是"这个镜像的元数据"，而不是某一层的内容。层摘要是每一层内容的哈希。一个镜像 ID 对应一个配置对象，配置对象里引用了多个层摘要。所以当你看到docker images里的 IMAGE ID 时，那是配置对象的摘要。而docker pull时显示的sha256:...进度条，那些是层摘要。两者格式相似，但含义不同。7.2 容器层和镜像层的关系容器启动时，会在镜像的只读层之上加一个可写层。这个可写层的生命周期和容器绑定：容器删除，可写层也就没了。所以容器里的数据默认不持久，需要持久化的数据必须挂载数据卷或者绑定宿主机目录。这一点在原理上很好理解：可写层是临时的，它不属于任何镜像，也不该被其他容器共享。如果你把重要数据放在容器可写层里，容器一删，数据就没了。我见过不止一个团队因为这个问题丢过数据，教训很深刻。7.3 镜像摘要和标签的区别标签（tag）是给人看的，比如myapp:1.0；摘要是给机器校验用的，比如sha256:abc...。标签可以被重新指向别的镜像，摘要则永远对应同一份内容。这就是为什么在生产环境里，推荐用摘要而不是标签来引用镜像。标签可能被覆盖，今天latest指向 A，明天可能就指向 B；而摘要一旦确定，拉取到的永远是同一份内容。这个习惯在需要严格版本控制的场景里非常重要。8. 我踩过的坑和总结出的几条经验聊了这么多原理，最后分享几条从实际踩坑中总结出来的经验，都是真金白银换来的。第一条，永远不要手动去改 Docker 的存储目录。我早期为了省事，直接删过/var/lib/docker下的某些目录，结果导致镜像数据库和实际层文件不一致，Docker 服务起不来。正确的做法是用官方命令清理，让 Docker 自己维护一致性。第二条，离线搬运一定要做校验。前面提过，直接拷贝目录绕过了校验，问题会延迟到运行时才暴露。用docker save加校验和比对，虽然多两步，但能省下大量排查时间。第三条，构建缓存失效不一定是坏事，但要能解释。有时候你发现某个层突然不命中缓存了，先别急着骂 Docker，去看看是不是依赖清单变了、基础镜像更新了，或者构建上下文里混进了不该有的文件。理解原理之后，缓存行为都是可解释的。第四条，定期清理，但别过度清理。清理能释放空间，但频繁清理会让每次构建都重新拉取基础层，反而拖慢速度。找到一个平衡点，比如保留最近常用的基础镜像，清理掉明显过时的悬空层。第五条，遇到诡异问题，先看存储驱动和磁盘空间。这两个因素能解释相当一部分"莫名其妙"的故障。docker info和docker system df是我排查问题时最先敲的两条命令。镜像加载原理看起来是底层细节，但它直接决定了你构建快不快、拉取稳不稳、磁盘够不够用。把这些机制搞清楚，很多以前觉得"玄学"的问题，都会变得有迹可循。后续如果大家感兴趣，我还可以聊聊镜像构建缓存的更细粒度控制，以及多阶段构建是怎么利用分层机制来瘦身镜像的。
1. 从一次镜像拉取卡顿说起：为什么需要搞懂加载原理很多人用 Docker 的第一课就是docker pull，然后docker run，容器跑起来了，任务就算完成。直到某天你发现：同一个镜像，在测试机上拉取只要十几秒，在生产环境却卡了五分钟；或者你明明只改了一行代码重新构建，推送的层却有好几百 MB；又或者磁盘空间莫名其妙被吃满，docker images一看，一堆<none>标签的悬空镜像堆在那里。这些问题表面上看是"网络慢""磁盘小"，但根子上都指向同一件事——你没有真正理解 Docker 镜像是怎么被加载和组织的。我自己刚开始接触容器的时候，也走过一段弯路。当时以为镜像就是一个打包好的压缩文件，拉下来解压就能用。后来在一个离线部署的场景里，需要把镜像从一台机器搬到另一台机器，我天真地直接拷贝了/var/lib/docker目录，结果目标机器上镜像列表是有了，但一运行就报错，层校验对不上。那次折腾了整整一个下午，才把镜像分层和加载机制彻底搞清楚。这篇文章就是把我踩过的这些坑、以及后来总结出来的原理和实操经验，系统地梳理一遍。核心围绕Docker 镜像加载原理展开，会讲到镜像的分层结构、内容寻址机制、联合文件系统怎么把一堆只读层"拼"成一个可用的根文件系统、docker pull和docker load背后的完整链路，以及在实际工作中怎么利用这些原理去排查问题、优化构建、清理空间。适合谁看？如果你已经会用 Docker 基本命令，但对"镜像为什么这么大""层是怎么复用的""加载时到底发生了什么"这些问题还模棱两可，那这篇内容就是为你准备的。如果你是完全的新手，也没关系，我会尽量用生活化的类比把底层机制讲清楚，保证你能看懂、能上手验证。需要提前说明的是，本文涉及的原理和操作，都是基于常见的 Linux 环境下的容器运行时实践总结而来，不同版本、不同存储驱动在细节上会有差异，但核心思路是一致的。下面我们正式进入正题。2. 镜像不是"一个文件"：分层结构与内容寻址的本质2.1 用"千层饼"理解镜像的分层很多人对镜像的第一个误解，就是把它当成一个整体。实际上，一个 Docker 镜像是由**一系列只读层（layer）叠加而成的。你可以把它想象成一张千层饼：最底下是基础层，比如一个精简的操作系统根文件系统；往上一层是运行时环境，比如某种语言的解释器；再往上是依赖库；最上面是你自己的应用代码。每一层都是只读的，层与层之间通过一种叫联合文件系统（Union File System）**的机制叠加在一起，对外呈现为一个完整的文件系统视图。这里有个关键点：每一层只记录相对于上一层的差异。也就是说，如果你在第一层装了一个包，第二层又删掉了它，第二层记录的并不是"删除"这个动作本身，而是记录了一个"白障文件"（whiteout），用来在联合挂载时屏蔽掉下层的那个文件。这个设计非常巧妙，它保证了层一旦生成就永远不可变，从而可以被安全地共享和复用。为什么这么设计？因为不可变意味着可以缓存、可以复用、可以并行分发。你想想，如果每一层都能被随意修改，那多个镜像共享同一层的时候就乱套了。正是因为层不可变，Docker 才能做到：十个镜像如果都基于同一个基础镜像，那这个基础层在磁盘上只存一份，在网络上传输时也只传一次。2.2 内容寻址：层的"身份证"是怎么算出来的每一层都有一个唯一的标识，叫DiffID和ChainID，最终对外暴露的是我们熟悉的镜像层摘要（digest）。这个摘要是怎么来的？简单说，就是对层的内容做一次哈希计算（通常是 SHA256），内容一样，哈希就一样；内容变一个字节，哈希就完全不同。这就是所谓的内容寻址（Content Addressable Storage）。它的好处是：你不需要给层起名字，也不需要维护一个中心化的命名表，只要拿到哈希值，就能唯一确定这一层的内容。这也解释了为什么镜像摘要（比如sha256:abc123...）可以用来做完整性校验——拉取下来的层，重新算一遍哈希，和清单里记录的对不上，就说明传输过程中出了问题。我在离线搬运镜像的时候就吃过这个亏。当时直接拷贝目录，绕过了校验环节，结果某个层在拷贝过程中损坏了，运行时才报错。后来改用docker save导出成 tar 包，再docker load导入，这个过程会做完整性校验，问题就暴露在加载阶段，而不是等到运行时才炸。2.3 镜像清单：层的"目录索引"光有层还不够，还需要一个东西来记录"这个镜像由哪些层组成、顺序是什么、每一层对应哪个哈希"。这个角色由**镜像清单（manifest）和配置对象（config）**来承担。配置对象里记录了镜像的元数据：环境变量、启动命令、工作目录、暴露端口等等。清单则记录了配置对象的摘要，以及所有层的摘要列表。当你执行docker pull时，实际上是先拉取清单，再根据清单里的摘要去拉取每一层。这个顺序很重要，因为它决定了拉取是可以并行的——清单拿到后，所有层的下载任务可以同时发起。理解了这一层，你就能明白为什么有时候docker pull会显示多个进度条同时跑，也能明白为什么"拉取清单失败"和"拉取某一层失败"是两个不同性质的错误。3. 联合文件系统如何把只读层"拼"成可写容器3.1 从只读层到可写层：容器启动时的关键一步镜像本身全是只读层，但容器运行时需要能写文件。这个矛盾怎么解决？答案是：在只读层的最上面，再叠加一个可写层（容器层）。所有对容器的写操作，都发生在这一层里。这就是所谓的**写时复制（Copy-on-Write，CoW）**机制。具体来说，当容器里的进程要修改一个位于只读层的文件时，联合文件系统会先把那个文件复制到可写层，然后在可写层里做修改。原来的只读层纹丝不动。这样做的好处是：镜像层可以被无数个容器共享，每个容器只额外占用自己可写层的空间。我经常用一个类比来解释这件事：镜像层就像图书馆里的参考书，谁都不能在上面涂改；容器层就像你借书时附带的笔记本，你想怎么记就怎么记，但笔记本上只记录你写的内容，不会把整本书抄一遍。所以一个基于大镜像启动的容器，如果只改了几个小文件，它实际占用的额外空间可能只有几 MB。3.2 不同存储驱动的差异：overlay2 为什么成为主流联合文件系统的具体实现，在 Linux 上有多种，Docker 把它们抽象成存储驱动（storage driver）。常见的有 overlay2、aufs、btrfs、zfs、devicemapper 等。目前绝大多数 Linux 发行版上，默认和推荐的都是overlay2。overlay2 的工作原理是：用lowerdir表示所有只读层，用upperdir表示可写层，再用一个merged目录把两者合并挂载，对外呈现统一视图。当你读一个文件时，如果 upperdir 里有就用 upperdir 的，没有就往下层找；当你写一个文件时，如果文件在下层，就先复制到 upperdir 再写。为什么 overlay2 能成为主流？主要是它在性能和稳定性之间取得了比较好的平衡，而且已经进入 Linux 主线内核，不需要额外打补丁。相比之下，早期的 aufs 需要单独的内核补丁，devicemapper 在空间管理上比较笨重。不过 overlay2 也有它的限制，比如对多层嵌套的支持不如某些驱动灵活，早期版本对 inode 数量也比较敏感。这里给一个实操建议：如果你在排查容器文件系统相关的诡异问题，第一件事就是确认当前用的存储驱动。docker info | grep "Storage Driver"不同驱动的行为差异，往往就是问题根源。3.3 层数过多的代价：为什么构建时要合并指令理解了分层机制，就能明白一个常见的构建优化原则：尽量减少层数。因为每一层都有元数据开销，层数太多会导致联合挂载时的查找变慢，镜像清单也变长。更重要的是，某些存储驱动对层数有上限限制。这就是为什么在写 Dockerfile 时，我们习惯把多个RUN指令用&&合并成一条。比如：RUN apt-get update && \ apt-get install -y curl git && \ rm -rf /var/lib/apt/lists/*这条指令只产生一层。如果拆成三条RUN，就会产生三层，而且中间层里还残留着包管理器的缓存，白白增大镜像体积。合并之后，清理动作和安装动作在同一层完成，缓存根本不会进入最终镜像。不过这里要提醒一句：合并指令不是越多越好。过度合并会让单层变得巨大，构建时的缓存粒度也变粗——改一个小地方，整层都要重建。所以实际项目中要权衡：变化频率相近的操作放一层，变化频率差异大的分开。比如系统依赖安装放一层（很少变），应用代码拷贝放另一层（经常变），这样改代码时不会触发依赖重装。4. docker pull 背后的完整链路拆解4.1 从仓库到本地：一次拉取经历了什么docker pull看起来只是一条命令，背后其实是一套完整的协商和传输流程。我把它拆成几个阶段：第一阶段是认证与协商。客户端先和镜像仓库建立连接，确认自己有没有权限拉取这个镜像。如果是公开镜像，这一步基本透明；如果是私有仓库，就需要凭据。协商阶段还会确认客户端支持的清单格式，比如是传统的 schema2 还是更新的 OCI 格式。第二阶段是拉取清单。客户端拿到镜像的清单文件，里面列出了配置对象和所有层的摘要。这一步很快，因为清单本身很小。第三阶段是并行拉取层。根据清单里的摘要列表，客户端检查本地是否已经存在这些层。已经存在的直接跳过，不存在的才发起下载。这就是为什么第二次拉取同一个基础镜像时几乎瞬间完成——层已经在本地了。第四阶段是校验与落盘。每一层下载完成后，客户端会重新计算哈希，和清单里的摘要比对。校验通过后，层被解压并写入本地存储目录。注意，这里有个容易忽略的点：传输时层是压缩的，落盘时是解压的。所以你会看到下载进度显示的大小，和最终磁盘占用不完全一致。4.2 层复用：为什么拉取能"跳过"大部分内容层复用是 Docker 镜像机制最实用的特性之一。假设你有三个镜像，都基于同一个基础镜像，那么这三个镜像在本地共享同一个基础层。拉取第三个镜像时，如果它的基础层和依赖层都已经存在，实际需要下载的可能只有最上面那几层应用代码。这个机制在 CI/CD 场景里价值巨大。构建流水线里，如果每次都从零拉取所有层，时间和带宽成本会非常高。而有了层复用，只要基础镜像没变，大部分层都能命中本地缓存。但层复用也有它的边界。只要层内容变了一个字节，哈希就变了，复用就失效。这就是为什么在 Dockerfile 里，把经常变化的指令放在后面很重要。如果你把应用代码拷贝放在最前面，那每次改代码都会导致后面所有层重建，缓存全部失效。正确的顺序是：先装依赖（很少变），再拷代码（经常变）。4.3 拉取失败的常见原因与排查思路拉取失败的原因五花八门，但按发生阶段可以归类。我整理了一个排查表，方便对照：失败阶段典型现象常见原因排查方向认证阶段提示未授权凭据过期或权限不足检查登录状态和仓库权限拉取清单提示清单不存在标签写错或镜像被删确认镜像名和标签拼写拉取层某个层卡住或超时网络不稳定或层较大重试、检查网络、分时段拉取校验阶段提示摘要不匹配传输损坏或本地存储异常清理本地缓存后重试落盘阶段提示磁盘空间不足存储目录空间不够清理悬空镜像和停止的容器这里分享一个我自己的经验：遇到拉取卡在某一层不动，先别急着重试，可以看看是不是本地磁盘快满了。因为落盘阶段需要空间解压，空间不足时表现出的现象可能就是"卡住"。另外，docker system df可以快速查看镜像、容器、卷各自占用的空间，比手动du方便得多。5. docker load 与离线搬运：镜像在机器之间怎么"搬家"5.1 save 和 load 的配对使用在没有外网或者网络受限的环境里，镜像搬运靠的是docker save和docker load这一对命令。docker save把一个或多个镜像导出成一个 tar 归档，docker load则把这个归档导入本地。# 导出镜像到文件 docker save -o myapp.tar myapp:1.0 # 在目标机器上导入 docker load -i myapp.tar这里有个细节值得注意：docker save导出的 tar 包里，包含了镜像的所有层和清单信息。导入时，docker load会逐层校验哈希，确保内容完整。这就是它比直接拷贝存储目录可靠的原因——拷贝目录绕过了校验，而 save/load 把校验内建在流程里。5.2 导出体积为什么比镜像显示的大很多人第一次用docker save会惊讶：docker images显示镜像 500MB，导出的 tar 包却有 1GB 多。这是正常的，原因有两个。第一，docker images显示的是压缩后的层大小之和，而docker save导出的是解压后的内容。压缩比通常在 2:1 到 3:1 之间，所以导出文件偏大是正常的。第二，如果导出多个镜像，它们共享的层在 tar 包里只会存一份，但每个镜像的清单都会引用它。所以导出多个镜像时，总体积并不是简单相加。如果你需要控制导出体积，可以在导出后再用通用压缩工具压一遍：docker save myapp:1.0 | gzip > myapp.tar.gz docker load -i myapp.tar.gzdocker load能自动识别 gzip 压缩的输入，不需要先解压。5.3 离线搬运的完整操作清单把镜像从一台机器搬到另一台，我总结了一套固定流程，照着做基本不会出问题：在源机器上确认镜像名称和标签，用docker images核对。执行docker save导出，建议同时用 gzip 压缩。计算导出文件的校验和，比如sha256sum，记录下来。传输文件到目标机器。在目标机器上重新计算校验和，和源端比对，确认传输无损。执行docker load导入。用docker images确认镜像已存在，并核对镜像 ID。启动一个测试容器，验证镜像可正常运行。第 3 步和第 5 步的校验和比对，是我强烈建议加上的。传输大文件时，静默损坏的概率虽然不高，但一旦发生，排查起来非常痛苦。提前比对校验和，能把问题挡在加载之前。6. 镜像加载原理在实际工作中的几个应用场景6.1 排查"镜像明明在，运行却报错"有一种情况很让人困惑：docker images里明明能看到镜像，docker run却报错说找不到或者层损坏。这通常和悬空镜像或层引用断裂有关。悬空镜像（dangling image）是指那些没有标签、也没有被任何镜像引用的层。它们通常是被新构建覆盖掉的旧版本。正常情况下它们不影响使用，但如果存储驱动在垃圾回收时出了问题，可能导致某些层被误删，进而让引用它的镜像无法运行。排查思路是：先用docker images -a看看有没有大量<none>标签的镜像，再用docker image inspect检查目标镜像的层是否完整。如果确认是层损坏，最稳妥的办法是删掉镜像重新拉取或重新加载。# 查看悬空镜像 docker images -f "dangling=true" # 清理悬空镜像 docker image prune注意：docker image prune默认只清理悬空镜像，加-a会清理所有未被容器使用的镜像，操作前务必确认没有正在依赖的镜像。6.2 优化构建：让层缓存尽可能命中理解了层复用机制，优化构建就有了明确方向。核心原则是：把变化频率低的操作放在前面，变化频率高的放在后面。一个典型的优化前后对比：优化前，先拷贝代码再装依赖，每次改代码都要重装依赖，构建时间几分钟。优化后，先拷贝依赖描述文件（比如某种语言的依赖清单），装完依赖再拷贝代码。这样只要依赖清单没变，依赖层就一直命中缓存，改代码只重建最上面一层，构建时间降到几秒。这个技巧在依赖安装耗时的项目里效果尤其明显。我见过一个项目，优化前每次构建要八分钟，调整 Dockerfile 指令顺序后降到四十秒，团队里所有人都松了口气。6.3 磁盘空间治理：从原理出发的清理策略磁盘被镜像吃满，是运维常见问题。理解了分层和引用机制，清理就有章法了。首先要区分三类占用：镜像层、容器可写层、数据卷。docker system df能给出总览。清理时按优先级来：先清理停止的容器，它们各自占着可写层。再清理悬空镜像，它们没有标签，通常可以安全删除。然后清理未被使用的镜像，这一步要谨慎，确认没有项目依赖。最后考虑数据卷，但数据卷里可能有重要数据，删之前一定要确认。# 查看空间占用总览 docker system df # 清理停止的容器、悬空镜像、未使用的网络 docker system prune # 更彻底的清理，包括未使用的镜像 docker system prune -a提示：docker system prune -a会删除所有未被运行中容器使用的镜像，包括你手动拉取但暂时没用的。执行前最好先docker images看一眼，避免误删。我自己的习惯是，定期跑一次docker system df，心里有个数。如果发现悬空镜像占比很高，说明构建频繁且没有及时清理，可以考虑在 CI 流程里加一步自动清理。7. 几个容易混淆的概念澄清7.1 镜像 ID 和层摘要不是一回事新手容易把镜像 ID 和层摘要搞混。镜像 ID 是配置对象的摘要，它代表的是"这个镜像的元数据"，而不是某一层的内容。层摘要是每一层内容的哈希。一个镜像 ID 对应一个配置对象，配置对象里引用了多个层摘要。所以当你看到docker images里的 IMAGE ID 时，那是配置对象的摘要。而docker pull时显示的sha256:...进度条，那些是层摘要。两者格式相似，但含义不同。7.2 容器层和镜像层的关系容器启动时，会在镜像的只读层之上加一个可写层。这个可写层的生命周期和容器绑定：容器删除，可写层也就没了。所以容器里的数据默认不持久，需要持久化的数据必须挂载数据卷或者绑定宿主机目录。这一点在原理上很好理解：可写层是临时的，它不属于任何镜像，也不该被其他容器共享。如果你把重要数据放在容器可写层里，容器一删，数据就没了。我见过不止一个团队因为这个问题丢过数据，教训很深刻。7.3 镜像摘要和标签的区别标签（tag）是给人看的，比如myapp:1.0；摘要是给机器校验用的，比如sha256:abc...。标签可以被重新指向别的镜像，摘要则永远对应同一份内容。这就是为什么在生产环境里，推荐用摘要而不是标签来引用镜像。标签可能被覆盖，今天latest指向 A，明天可能就指向 B；而摘要一旦确定，拉取到的永远是同一份内容。这个习惯在需要严格版本控制的场景里非常重要。8. 我踩过的坑和总结出的几条经验聊了这么多原理，最后分享几条从实际踩坑中总结出来的经验，都是真金白银换来的。第一条，永远不要手动去改 Docker 的存储目录。我早期为了省事，直接删过/var/lib/docker下的某些目录，结果导致镜像数据库和实际层文件不一致，Docker 服务起不来。正确的做法是用官方命令清理，让 Docker 自己维护一致性。第二条，离线搬运一定要做校验。前面提过，直接拷贝目录绕过了校验，问题会延迟到运行时才暴露。用docker save加校验和比对，虽然多两步，但能省下大量排查时间。第三条，构建缓存失效不一定是坏事，但要能解释。有时候你发现某个层突然不命中缓存了，先别急着骂 Docker，去看看是不是依赖清单变了、基础镜像更新了，或者构建上下文里混进了不该有的文件。理解原理之后，缓存行为都是可解释的。第四条，定期清理，但别过度清理。清理能释放空间，但频繁清理会让每次构建都重新拉取基础层，反而拖慢速度。找到一个平衡点，比如保留最近常用的基础镜像，清理掉明显过时的悬空层。第五条，遇到诡异问题，先看存储驱动和磁盘空间。这两个因素能解释相当一部分"莫名其妙"的故障。docker info和docker system df是我排查问题时最先敲的两条命令。镜像加载原理看起来是底层细节，但它直接决定了你构建快不快、拉取稳不稳、磁盘够不够用。把这些机制搞清楚，很多以前觉得"玄学"的问题，都会变得有迹可循。后续如果大家感兴趣，我还可以聊聊镜像构建缓存的更细粒度控制，以及多阶段构建是怎么利用分层机制来瘦身镜像的。