精通 DevOps 工具与最佳实践 - DevOps 知识中心 精通 DevOps 工具与最佳实践 - DevOps 知识中心

掌握Dockerfile层缓存，实现闪电般的容器构建速度

通过掌握Dockerfile层缓存，加速您的Docker构建并优化开发工作流程。本全面指南揭示了优化指令顺序、利用多阶段构建以及理解缓存机制的最佳实践，从而显著缩短构建时间。学习如何让您的Docker构建变得极快，并提升CI/CD效率。

掌握Dockerfile层缓存，实现闪电般的容器构建速度

Dockerfile层缓存决定了构建是在您思考变更时完成，还是让每次提交都显得代价高昂。缓存并不复杂，但它是无情的：过早复制错误的文件，Docker别无选择，只能重新运行缓慢的步骤。

主要习惯很简单。将稳定的工作放在前面，将频繁变化的工作放在后面，并保持构建上下文干净。一旦理解了这一点，大多数Dockerfile性能问题在构建输出中就会变得显而易见。

理解Docker层缓存

Docker以层的形式构建容器镜像。Dockerfile中的每条指令（如RUN、COPY、ADD）都会创建一个新层。当您构建镜像时，Docker会检查它是否已经在之前的构建中执行过具有相同上下文（例如，COPY的相同文件）的特定指令。如果发生缓存命中，Docker会重用缓存中的现有层，而不是重新执行指令。这可以节省大量时间，特别是对于计算密集型操作或复制大文件时。

关键概念：

  • 层： 由Dockerfile指令创建的不可变文件系统快照。
  • 缓存命中： 当Docker在缓存中找到给定指令的相同层时。
  • 缓存未命中： 当Docker找不到匹配的层，必须执行指令时，会使所有后续指令的缓存失效。

Docker缓存的工作原理：机制

Docker根据指令本身和涉及的文件来确定缓存命中。对于像RUN echo 'hello'这样的指令，指令字符串是主要的缓存键。对于COPY或ADD等指令，Docker不仅考虑指令，还会计算正在复制的文件的校验和。如果指令或文件的校验和发生变化，就会导致缓存未命中。

这意味着Dockerfile指令或相关文件的任何更改都会使该指令以及所有后续指令的缓存失效。这是优化的关键点。

优化Dockerfile以最大化缓存利用

利用Docker构建缓存的艺术在于构建Dockerfile以最小化缓存失效，特别是对于频繁更改的指令。一般原则是将不太可能更改的指令放在Dockerfile的前面，而将更频繁更改的指令放在后面。

1. 策略性地安排指令顺序

黄金法则： 将稳定的指令放在前面。

考虑一个典型的Web应用程序Dockerfile。您可能有安装依赖项、复制应用程序代码，然后运行构建或启动服务器的步骤。

低效示例（缓存失效）：

FROM ubuntu:latest

# 安装系统包（很少更改）
RUN apt-get update && apt-get install -y --no-install-recommends \
    python3 \
    python3-pip \
    && rm -rf /var/lib/apt/lists/*

# 复制应用程序代码（非常频繁更改）
COPY . .

# 安装Python依赖项（经常更改）
RUN pip install --no-cache-dir -r requirements.txt

# ... 其他指令

在此示例中，每次更改一行应用程序代码（因为执行了COPY . .），COPY . .和所有后续指令（RUN pip install ...）的缓存都将失效。这意味着即使requirements.txt没有更改，pip install也会重新运行，导致构建时间更长。

优化示例（最大化缓存）：

FROM ubuntu:latest

# 安装系统包（很少更改）
RUN apt-get update && apt-get install -y --no-install-recommends \
    python3 \
    python3-pip \
    && rm -rf /var/lib/apt/lists/*

# 首先仅复制依赖文件（更改频率较低）
COPY requirements.txt .

# 安装Python依赖项（如果requirements.txt未更改，则缓存）
RUN pip install --no-cache-dir -r requirements.txt

# 复制其余的应用程序代码（非常频繁更改）
COPY . .

# ... 其他指令

通过首先复制requirements.txt并立即运行pip install，Docker可以缓存依赖项安装层。如果只有应用程序代码更改（而requirements.txt保持不变），则pip install步骤将被缓存，从而显著加快构建速度。

2. 利用多阶段构建

多阶段构建是减少镜像大小的强大技术，但它们也通过保持中间构建环境分离而间接有益于构建时间。每个阶段都可以有自己的缓存层。

# 阶段1：构建器
FROM golang:1.20 AS builder
WORKDIR /app
COPY go.mod ./ 
COPY go.sum ./
RUN go mod download
COPY . .
RUN CGO_ENABLED=0 go build -o myapp

# 阶段2：最终镜像
FROM alpine:latest
WORKDIR /root/
COPY --from=builder /app/myapp .
CMD ["./myapp"]

在此场景中，如果只有应用程序源代码更改（但go.mod和go.sum未更改），则构建器阶段中的go mod download步骤将被缓存。即使构建器阶段需要重新运行编译，最终阶段仍将基于alpine:latest镜像，该镜像很可能已被缓存，并且仅当工件myapp发生更改时，COPY --from=builder指令才会重新执行。

3. 明智地使用ADD和COPY

  • COPY 通常更受欢迎，用于将本地文件复制到镜像中。它简单且可预测。
  • ADD 具有更多功能，例如解压tar包和获取远程URL的能力。然而，这些额外功能有时可能导致意外行为，并可能以不同方式影响缓存失效。除非您明确需要ADD的高级功能，否则坚持使用COPY。

使用COPY时，要精细。不要使用COPY . .，而是考虑复制以不同速率更改的特定目录或文件，如上面的优化示例所示。

4. 在同一RUN指令中清理

为避免缓存膨胀并减少镜像大小，始终在创建工件的同一RUN指令中清理工件（如包管理器缓存）。

不良实践：

RUN apt-get update && apt-get install -y some-package
RUN rm -rf /var/lib/apt/lists/*

在这里，rm命令是一个单独的RUN指令。如果some-package已更新（导致第一个RUN缓存未命中），则第二个RUN仍将执行，即使清理对于新层并非严格必要。更重要的是，第一个RUN创建的中间缓存层可能仍包含在第二个RUN清理之前下载的包列表。

良好实践：

RUN apt-get update && apt-get install -y some-package && rm -rf /var/lib/apt/lists/*

这确保了在包安装期间创建的任何临时文件都会立即被删除，并且创建的缓存层代表更干净的文件系统状态。

5. 避免每次都安装依赖项

如前所述，在复制应用程序源代码之前复制依赖定义文件（requirements.txt、package.json、Gemfile等）并安装依赖项是一项基本的缓存优化。

6. 缓存破坏（必要时）

虽然目标是最大化缓存，但有时您想要强制重建缓存。这称为缓存破坏。常见技术包括：

  • 更改注释： Dockerfile注释（#）被忽略，因此这不起作用。
  • 添加虚拟参数： 您可以使用ARG引入一个变量，通过更改它来破坏缓存。
    ARG CACHEBUST=1
RUN echo "Cache bust: ${CACHEBUST}" # 如果CACHEBUST更改，此指令将重新运行
    然后您将使用docker build --build-arg CACHEBUST=$(date +%s) .进行构建。
  • 修改较早的RUN命令： 如果您更改Dockerfile中较早的命令，它将破坏所有后续指令的缓存。

缓存破坏应谨慎使用，通常是在需要确保外部资源的新鲜下载或对标准缓存机制处理不佳的内容进行干净构建时。

Docker BuildKit和增强缓存

最新版本的Docker已将BuildKit引入为默认构建器引擎。BuildKit在缓存方面提供了显著改进，包括：

  • 远程缓存： 能够在不同机器和CI/CD运行器之间共享构建缓存。
  • 更细粒度的缓存： 更好地识别哪些内容已更改。
  • 并行构建执行： 即使没有缓存命中，也能加速构建。

BuildKit通常默认启用，并且通常提供更好的开箱即用缓存。然而，理解上述原则仍将允许您为BuildKit优化Dockerfile。

有效Dockerfile缓存的技巧

  • 保持Dockerfile干净有序： 可读性有助于识别优化机会。
  • 测试您的缓存： 进行更改后，观察您的Docker构建输出。查找[internal]或CACHED标签以确认缓存命中。
  • 使用.dockerignore： 防止不必要的文件（如node_modules、.git、构建工件）被复制到构建上下文中，这可以加速COPY指令并减少意外缓存失效的机会。
  • 定期清理Docker缓存： 随着时间的推移，您的缓存可能会变得很大。使用docker builder prune删除未使用的构建缓存层。

一个真实的Node.js示例

缓存问题在Node.js项目中最容易看到。这个Dockerfile可以工作，但浪费时间：

FROM node:22-slim
WORKDIR /app
COPY . .
RUN npm ci
RUN npm run build
CMD ["npm", "start"]

每次源代码更改都会使COPY . .失效，这意味着npm ci会再次运行。一个更好的版本将依赖元数据与应用程序代码分开：

FROM node:22-slim
WORKDIR /app

COPY package.json package-lock.json ./
RUN npm ci

COPY . .
RUN npm run build

CMD ["npm", "start"]

现在，对src/routes/account.ts的更改不会使依赖安装层失效。对package-lock.json的更改仍然会使其失效，这正是您想要的。

对于生产镜像，将其与多阶段构建结合：

FROM node:22-slim AS deps
WORKDIR /app
COPY package.json package-lock.json ./
RUN npm ci

FROM node:22-slim AS build
WORKDIR /app
COPY --from=deps /app/node_modules ./node_modules
COPY . .
RUN npm run build

FROM node:22-slim AS runtime
WORKDIR /app
ENV NODE_ENV=production
COPY package.json package-lock.json ./
RUN npm ci --omit=dev
COPY --from=build /app/dist ./dist
CMD ["node", "dist/server.js"]

这更长，但它分离了三个关注点：依赖下载、应用程序构建和运行时内容。CI运行器可以缓存昂贵的部分，最终镜像不需要整个源代码树或开发依赖项。

将.dockerignore作为缓存策略的一部分

层缓存不仅关乎Dockerfile指令顺序。构建上下文也很重要。如果您将.git、本地测试输出、截图、覆盖率报告或node_modules发送到构建上下文中，Docker将有更多文件需要校验和，并且有更多机会使COPY失效。

一个典型的应用程序.dockerignore可能包括：

.git
node_modules
dist
coverage
.env
*.log
tmp
.DS_Store

小心.env。出于安全和可重复性原因，您通常希望将其排除在镜像之外。运行时配置应在容器启动时传递，而不是烘焙到构建中，除非它确实是构建时非敏感配置。

知道何时缓存对您撒谎

缓存可能隐藏错误。常见的例子是依赖于外部存储库的包管理器命令。如果您编写：

RUN apt-get update
RUN apt-get install -y curl

缓存的apt-get update层可能会变得过时，而后面的安装步骤期望最新的包元数据。将更新和安装放在一起：

RUN apt-get update \
  && apt-get install -y --no-install-recommends curl \
  && rm -rf /var/lib/apt/lists/*

同样的想法适用于语言依赖项。锁定文件使构建更可重复，并帮助缓存行为可预测。使用package-lock.json、pnpm-lock.yaml、poetry.lock、Gemfile.lock、go.sum或您技术栈的等效文件。如果您的Dockerfile从网络安装浮动依赖版本，缓存命中可能很快，但重建可能会在以后让您感到惊讶。

用于包管理器的BuildKit缓存挂载

BuildKit支持缓存挂载，可以加速包管理器，而无需将其缓存放入最终镜像层。例如，npm：

# syntax=docker/dockerfile:1.7
FROM node:22-slim
WORKDIR /app
COPY package.json package-lock.json ./
RUN --mount=type=cache,target=/root/.npm npm ci
COPY . .
RUN npm run build

对于Python：

# syntax=docker/dockerfile:1.7
FROM python:3.12-slim
WORKDIR /app
COPY requirements.txt .
RUN --mount=type=cache,target=/root/.cache/pip \
  pip install --no-cache-dir -r requirements.txt
COPY . .

这是否有帮助取决于您的CI设置。没有远程缓存的短期运行器仍将冷启动。在作业之间保留BuildKit缓存的运行器可以节省大量时间。

CI中的远程缓存

本地缓存很容易；CI缓存需要精心设置。使用docker buildx，您可以从注册表推送和拉取缓存元数据：

docker buildx build \
  --cache-from=type=registry,ref=registry.example.com/myapp:buildcache \
  --cache-to=type=registry,ref=registry.example.com/myapp:buildcache,mode=max \
  -t registry.example.com/myapp:${GIT_SHA} \
  --push .

这允许新的运行器重用早期运行器构建的层。这对于依赖安装和大型编译步骤特别有用。请注意访问控制：构建缓存可能包含来自中间阶段的文件系统快照，因此将私有注册表缓存视为构建基础设施的一部分，而不是公共暂存空间。

调试缓慢的Docker构建

当构建意外缓慢时，读取输出而不是猜测。BuildKit会打印哪些步骤被缓存以及哪些被执行。如果依赖安装步骤未被缓存，请查看之前的COPY或RUN行。它之前的某些内容发生了变化。

有用的检查：

docker build --progress=plain .
docker buildx du
docker builder prune --filter until=24h

如果其他作业依赖于缓存，不要在共享构建主机上盲目清理。当磁盘使用率高时，清理是有帮助的，但它可能使下一次构建变慢。

实用审查清单

在审查Dockerfile以加快构建速度时，从上到下浏览并询问：

  • 稳定的基础设置步骤是否在频繁更改的源文件之前？
  • 依赖清单是否在完整应用程序之前复制？
  • .dockerignore是否排除了本地噪音和秘密？
  • 包管理器缓存是否在同一层中处理，或者使用BuildKit缓存挂载？
  • 最终镜像是否只包含运行所需的内容？
  • 如果运行器是可丢弃的，CI是否使用远程缓存？

快速的Docker构建通常是许多小的、乏味的选择的结果。将缓慢、稳定的工作放在前面。将频繁更改的工作放在后面。保持构建上下文干净。然后通过构建输出验证，而不是假设正在使用缓存。