幂等 Dockerfiles：理想的追求还是误导的目标？

发布: 2天前 (2025年12月4日 GMT+8 06:41)

8 min read

Source: Dev.to

TL;DR

幂等或完全可复现的 Dockerfile 常被宣传为最佳实践，但在大多数真实工程环境中，这并不是正确的目标。团队真正需要的是：（1）存放在镜像仓库中的不可变、可追溯的制品；（2）能够定期在 CI 中重新构建，以持续获取安全补丁和更新的依赖。只要原始镜像制品被保留并可通过 digest 访问，幂等重建几乎没有运维价值。可复现性在特定领域（受监管、科研、高保证）仍有用处，但对主流应用开发而言，它会在没有相应收益的情况下增加成本和复杂度。

1. “幂等 Dockerfile” 实际指的是什么

该术语融合了几个相关概念：

幂等构建： 多次运行 docker build 会得到“相同”的镜像。
可复现构建： 任何人在任何机器上都能重新构建出位相同的镜像。
功能等价： 即使位不同（元数据、时间戳），运行时行为基本相同。

实际使用中的 Dockerfile 往往只能达到功能等价层级，而不是严格的幂等，更别说完整的可复现性了。

示例非幂等 Dockerfile

FROM debian:stable-slim

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

COPY app /usr/local/bin/app
ENTRYPOINT ["/usr/local/bin/app"]

几周后重新构建可能会因为基础镜像的补丁级别或软件包版本变化而产生不同的镜像哈希。这种情况很常见，也往往是可以接受的。

2. 支持幂等或可复现构建的论点

2.1. 消除 CI 漂移和 “在我机器上能跑” 现象

相关指南强调固定版本、避免网络非确定性、阻止副作用，以确保同一 Dockerfile 产生同一镜像。这有助于调试并保证协作者看到一致的结果。

2.2. 支持科学可复现性

科研工作流有时需要多年后能够重新构建完全相同的环境。已有专门针对可复现科研 Dockerfile 的指导。

2.3. 与某些供应链安全叙事保持一致

可复现构建有助于验证镜像是否精准对应给定源码，并检测篡改。BuildKit 与 SBOM/证明（attestation）功能正是为此类场景设计的。

3. 为什么幂等 Dockerfile 在实践中很少见

3.1. 常见的 Dockerfile 模式本质上是非确定性的

一段 BuildKit 讨论对该问题的概括如下：

“使用 Dockerfile 构建 Docker 镜像并不可复现…大多数真实场景都涉及行为非确定性的包管理器。”

漂移的来源包括

浮动的基础标签
随时间变化的包仓库
未固定摘要的下载
层中嵌入的时间戳和元数据

3.2. Docker 官方指南强调频繁重建

Docker 建议频繁重建，以获取安全补丁和更好的依赖。真正的幂等性需要冻结版本，而持续的安全性则要求允许版本变化。

3.3. 完全可复现性带来巨大的运维开销

要实现位相同的镜像通常需要私有镜像源、完整的版本固定、快照仓库、时间戳归一化以及受控的构建环境。这会增加维护成本，却在主流场景中收益有限。

4. 反向观点：幂等性不应是首要目标

关键洞见是：容器工作流围绕不可变制品，而不是可重建性。

4.1. 镜像仓库已经保留了重要的东西

容器生态默认不可变的镜像：

通过 digest 存储并可检索
可追溯到构建元数据、CI 提交和 SBOM
在构建时已完成版本化，而不是以后再重建

既然仓库已经保存了制品，运营上几乎不需要通过重新构建来再现它。

4.2. 现代 CI 流水线依赖时间变化的构建

flowchart LR
  A[git commit] --> B[CI build]
  B --> C[docker build -> digest]
  C --> D[push to registry]
  D --> E[deploy by digest]

正确的不变量是

每一次提交都会生成自己的镜像。
每个镜像以 digest 形式不可变存储。
部署和回滚都引用已存储的 digest。

只要原始 digest 被保留，docker build 是否还能产生相同的 digest 并不重要。

4.3. 定期的非幂等重建是一种安全优势

频繁重建可以确保操作系统包已打补丁、基础镜像已更新、依赖已刷新。严格的幂等性直接与安全最佳实践冲突。

示例以镜像仓库为中心的工作流

Dockerfile（时间变化但在运营上是合理的）

FROM python:3.12-slim

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

WORKDIR /app
COPY pyproject.toml poetry.lock ./
RUN pip install --no-cache-dir poetry && \
    poetry install --no-interaction --no-ansi

COPY . .
CMD ["poetry", "run", "myapp"]

CI 构建

COMMIT_SHA=$(git rev-parse --short HEAD)

docker build \
  -t registry.example.com/myapp:${COMMIT_SHA} \
  -t registry.example.com/myapp:main \
  .

docker push registry.example.com/myapp:${COMMIT_SHA}
docker push registry.example.com/myapp:main

DIGEST=$(docker inspect --format='{{index .RepoDigests 0}}' \
  registry.example.com/myapp:${COMMIT_SHA})

echo "Built image: ${DIGEST}"

运营正确性由以下保证：

记录并通过 digest 部署
保留每一次生成的制品
定期重建以保持持续新鲜

幂等重建在此并非必要。

5. 何时需要可复现性

幂等性和可复现性在以下场景下重要：

受监管或高保证的供应链
需要精确可重现环境的科研工作流
空气隔离（air‑gapped）环境中只能通过重建获取镜像

针对这些情况，可采用专门的方法：

BuildKit 的可复现构建设置、SOURCE_DATE_EPOCH、确定性时间戳
功能性构建系统（Nix、Bazel）实现确定性的依赖图
固定版本的仓库或快照镜像

这些是例外而非常态。

6. 实用的分层模型

可以将容器构建的正确性划分为三层：

运行时行为： 容器在运行时表现可预测。
制品不可变性： 镜像仓库存储不可变的 digest 并附带来源信息。
构建可复现性： 重新构建 Dockerfile 能产生相同的输出。

第 1 层和第 2 层对所有情况都至关重要。第 3 层仅在上文所述的特化场景中才有价值。