1. 容器镜像基础：镜像分层原理、UnionFS 与 OverlayFS、镜像层复用机制

容器镜像并非一个巨大的单体文件，而是一组只读层的堆叠集合。理解镜像的分层结构、联合文件系统（UnionFS）的工作原理以及层复用机制，是优化流水线缓存效率的理论基石。本节将拆解这三个核心概念，并揭示它们如何共同影响镜像的构建与加载速度。

1.1 镜像分层原理

每个 Dockerfile 指令（如 FROM、RUN、COPY）都会生成一个新的镜像层（Layer）。每一层仅记录与上一层的差异（diff），而非完整文件系统的快照。

核心特性：层是只读的、不可变的。当容器运行时，会在这些只读层之上叠加一个可写层（容器层），所有写入操作均发生在该层。

分层结构示例（以 Java 应用镜像为例）：

层序号 Dockerfile 指令 层内容描述 层大小（典型）
L0 FROM eclipse-temurin:17-jre 基础 JRE 运行环境（操作系统 + JDK/JRE） ~180 MB
L1 RUN apt-get update && apt-get install -y curl 安装 curl 工具及其依赖 ~15 MB
L2 COPY target/app.jar /app/app.jar 应用可执行 JAR 包 ~50 MB
L3 COPY config/ /app/config/ 应用配置文件 ~0.1 MB
L4 ENTRYPOINT ["java", "-jar", "/app/app.jar"] 元数据层（不占用磁盘空间） 0 MB
优化启示：将频繁变动的层（如 COPY app.jar）放在 Dockerfile 底部，将稳定层（如基础镜像、系统依赖安装）放在顶部。这样在流水线中，只有变动层及其后续层需要重新构建和传输，大幅提升缓存命中率。

1.2 UnionFS 与 OverlayFS

联合文件系统（UnionFS）是一种将多个目录（分支）联合挂载到同一个挂载点的文件系统技术。容器运行时使用 UnionFS 将多个只读镜像层与一个可写容器层合并，呈现为一个完整的、统一的文件系统视图。

目前主流的容器运行时（Docker、containerd）默认使用 OverlayFS（Overlay2 驱动），它是 Linux 内核原生支持的联合文件系统实现，性能优于早期的 AUFS 和 Device Mapper。

OverlayFS 核心概念对比：

概念 说明 在容器镜像中的角色
Lower Dir 只读层，可以有多层 镜像层（L0 ~ Ln）
Upper Dir 可读写层 容器可写层（容器运行时的修改）
Merged Dir 联合挂载后的统一视图 容器内看到的完整文件系统
Work Dir 用于原子操作和文件隐藏的临时目录 OverlayFS 内部使用，对用户透明
OverlayFS 联合挂载结构（容器运行时视图） Lower Dir (只读) 镜像层 Ln (最上层) 镜像层 L1 镜像层 L0 (基础层) Upper Dir (可读写) 容器可写层 （文件修改/新增/删除） 容器停止后丢弃 Merged Dir 关键行为： • 读文件：优先从 Upper Dir 读取，若不存在则从 Lower Dir 按层从上到下查找。 • 写文件：在 Upper Dir 创建副本（Copy-on-Write），后续读取均指向该副本。
性能陷阱：当容器内首次修改一个来自 Lower Dir 的大文件（如日志库）时，OverlayFS 会触发 Copy-on-Write (CoW) 操作，将整个文件复制到 Upper Dir。如果文件很大（如 1GB），会导致显著的 I/O 延迟和容器启动卡顿。在流水线中，应避免在容器运行时频繁修改镜像层中的大文件。

1.3 镜像层复用机制

镜像层复用是 Docker 缓存系统的核心。当构建新镜像时，Docker 守护进程会检查每个待构建的层是否已经存在于本地缓存中。判断依据是层的内容哈希（Content Hash），而非指令文本。

层缓存命中条件：

  1. 父层（Parent Layer）的哈希必须完全匹配。
  2. 当前指令生成的上下文（如 COPY 的文件内容、RUN 的 shell 命令字符串）的哈希必须匹配。
  3. 基础镜像的层链必须一致。

缓存失效的常见场景：

场景 原因 影响范围
COPY 源文件内容变更 文件内容哈希改变，导致该层及其后续所有层缓存失效 当前层及以下所有层
RUN apt-get update 后安装新包 命令字符串未变，但 apt 源或包版本更新导致层内容变化 当前层及以下所有层
基础镜像标签更新（如 FROM ubuntu:22.04 指向新 digest） 基础镜像层链哈希整体变化 整个镜像所有层
Dockerfile 中插入新指令 层顺序改变，后续层的父层哈希不匹配 插入位置之后的所有层
镜像层缓存命中与失效流程 缓存命中（Cache Hit） 步骤 1：检查父层哈希是否匹配 步骤 2：检查指令上下文哈希 步骤 3：复用本地缓存层（零构建） ✅ 构建时间：~0.1s（仅元数据操作） 缓存失效（Cache Miss） 步骤 1：父层哈希不匹配 步骤 2：重新执行指令（如 RUN、COPY） 步骤 3：生成新层并写入本地存储 ❌ 构建时间：取决于指令复杂度（秒~分钟） 流水线调优要点： • 将最稳定的层（基础镜像、系统依赖）放在 Dockerfile 顶部，最大化缓存命中。 • 使用 --cache-from 指定远程仓库中的镜像作为缓存源，实现跨构建机缓存共享。

1.4 小结：分层与复用对流水线的意义

  • 构建加速：利用层缓存，流水线中 80% 以上的层可以直接从本地或远程缓存中复用，避免重复下载和构建。
  • 传输优化：镜像推送和拉取时，仅传输未缓存的层（增量传输），显著降低网络带宽消耗和部署时间。
  • 存储节省：多个镜像共享相同的基础层（如 ubuntu:22.04），在宿主机上只需存储一份，磁盘占用大幅减少。
实践检查清单：在编写 Dockerfile 时，始终问自己三个问题：① 这一层的内容是否经常变化？② 能否将变化的部分独立成一层？③ 这一层是否可以被其他镜像复用？回答好这三个问题，你的流水线缓存效率将提升一个数量级。
← 上一章 📖 返回目录 下一章 →