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-WriteCoW**机制。具体来说当容器里的进程要修改一个位于只读层的文件时联合文件系统会先把那个文件复制到可写层然后在可写层里做修改。原来的只读层纹丝不动。这样做的好处是镜像层可以被无数个容器共享每个容器只额外占用自己可写层的空间。我经常用一个类比来解释这件事镜像层就像图书馆里的参考书谁都不能在上面涂改容器层就像你借书时附带的笔记本你想怎么记就怎么记但笔记本上只记录你写的内容不会把整本书抄一遍。所以一个基于大镜像启动的容器如果只改了几个小文件它实际占用的额外空间可能只有几 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 danglingtrue # 清理悬空镜像 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是我排查问题时最先敲的两条命令。镜像加载原理看起来是底层细节但它直接决定了你构建快不快、拉取稳不稳、磁盘够不够用。把这些机制搞清楚很多以前觉得玄学的问题都会变得有迹可循。后续如果大家感兴趣我还可以聊聊镜像构建缓存的更细粒度控制以及多阶段构建是怎么利用分层机制来瘦身镜像的。 
长河君 · 2026/10/20 21:30:49 · 阅读 1.2k Docker镜像加载原理：分层、内容寻址与联合文件系统
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-WriteCoW**机制。具体来说当容器里的进程要修改一个位于只读层的文件时联合文件系统会先把那个文件复制到可写层然后在可写层里做修改。原来的只读层纹丝不动。这样做的好处是镜像层可以被无数个容器共享每个容器只额外占用自己可写层的空间。我经常用一个类比来解释这件事镜像层就像图书馆里的参考书谁都不能在上面涂改容器层就像你借书时附带的笔记本你想怎么记就怎么记但笔记本上只记录你写的内容不会把整本书抄一遍。所以一个基于大镜像启动的容器如果只改了几个小文件它实际占用的额外空间可能只有几 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 danglingtrue # 清理悬空镜像 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是我排查问题时最先敲的两条命令。镜像加载原理看起来是底层细节但它直接决定了你构建快不快、拉取稳不稳、磁盘够不够用。把这些机制搞清楚很多以前觉得玄学的问题都会变得有迹可循。后续如果大家感兴趣我还可以聊聊镜像构建缓存的更细粒度控制以及多阶段构建是怎么利用分层机制来瘦身镜像的。