Buildpacks 将容器控制点从 Dockerfile 中移出

关于 Dockerfile 与 Buildpacks 的长期争论已经演变为一场安全之争。 Dockerfile 将基础镜像的选择和补丁发布频率交由各个应用团队来决定，而 Cloud Native Buildpacks 则将这些决策权移交给了平台工程团队，由其决定如何在由数百个服务组成的集群中快速修复关键 CVE 漏洞。 两者的区别在于基础镜像的声明位置。在 Dockerfile 中，每个存储库都包含一条 FROM 语句，因此，要推广打过补丁的基础镜像，就意味着需要修改每个服务。虽然 Renovate 和 Dependabot 能自动处理这类机械性操作，但还是需要重新构建：更新 FROM 语句仍然会触发一次完整构建、占用一个 CI 队列槽位、执行一次测试并进行重新部署，而这些操作还要乘以服务数量。 Buildpacks 则颠覆了这一模式。其 构建器 "（builder）是一个 OCI 镜像，其中打包了一组按顺序排列的 Buildpacks、生命周期以及构建时基础镜像，同时还在元数据中关联了一个独立的运行时基础镜像（即“运行镜像”）。后续构建时会选择一个新的运行镜像，而现有的兼容应用镜像无需重建其应用程序层即可进行 Rebase 操作。不过，更新生产环境仍然需进行测试、升级和部署。 Cloud Native Buildpacks 项目 "于 2026 年 7 月 17 日从 CNCF 正式毕业 "。该项目对其构建方式的表述是，“将关于容器构建最佳实践的知识集中于专业团队，而非让组织内的应用程序开发人员各自维护自己的 Dockerfile”。其实现机制是 rebase " 命令。它会检测更新的运行时基础镜像，并据此重写 OCI 清单和配置。 将操作系统层的摘要值（digest）替换为新运行镜像的摘要值，可以完全绕过重建周期。Joe Kutner 在 2023 年 12 月为 CNCF TAG 环境可持续性小组撰文时指出， 这本质上只是对一个 JSON 文件的编辑 "，仅需几毫秒就可以完成，而且计算资源消耗极低，无需重建、访问源代码或进入 CI 队列。Rebase 仅替换兼容的运行镜像层；但如果应用程序依赖项中存在漏洞，则仍然需重新构建。 这种极高的运行效率正是如今各 Buildpack 供应商竞相提升构建器安全性的原因之一。BellSoft 于 2026 年 7 月 21 日正式推出了一款 基于其 Alpaquita Linux 加固镜像 "构建的 加强版 Paketo 构建器 "。该构建器将同时取代构建栈和运行栈：内置精简的软件包集、默认非 root 权限、签名及 SBOM 数据。不过，对于生成的应用程序镜像，平台团队仍然需要进行签名、认证、测试和发布。 根据 BellSoft 自己的描述，补丁是通过“下个构建版本”而非通过 rebase 方式推送至应用程序的。因此，“毫秒级”的响应速度是该模型的固有特性，而非供应商的宣传口号。该公司表示，补丁镜像通常会在漏洞披露后“24小时内”发布；根据合同约定，其标准版（Standard tier）承诺高危漏洞 7 天内完成修复，其余漏洞的修复 SLA 为 14 天，而免费社区版（Community tier）则未列明相关条款。 包括 Chainguard "、 Docker "、 Wiz " 和 Minimus " 在内的其他供应商，则通过提供低 CVE 或零 CVE 镜像目录展开竞争，而且该市场正趋于商品化： Docker 已于 2025 年 12 月将其全部加固镜像目录在 Apache 2.0 许可证下免费开放 "，仅保留具有 SLA 保障的付费修复服务。Docker 的 Select 版承诺在七天内修复高危 CVE，这与 BellSoft 的 Standard 版标准一致。如果镜像免费且服务水平协议趋同，那么差异化竞争的焦点将转向交付能力和责任追溯机制，这也正是将构建器而非镜像视为控制点的理由。 关于 Dockerfile 漂移 "的研究表明，构建定义很容易与所支持的代码脱节；而在 Spring I/O 2026 大会上， BellSoft 在 对 250 名 Spring 开发者、技术负责人和架构师进行的调查 "中发现，64% 的受访者并未意识到他们的 Dockerfile 存在安全风险。更广泛地讲，补丁管理的规范性偏弱： 一项针对 6292 个 Docker 镜像的跨标签研究 "（ICSME 2025）发现，在被检查的每个标签中，近 61% 的存储库都包含存在漏洞的应用程序依赖项。这属于应用层的问题，rebase 无法解决，但它们反映的习惯与导致基础镜像未打补丁的习惯是一样的。 Buildpacks 并非一个万能的解决方案。它牺牲了手动编写 Dockerfile 时那种按步骤控制的优势，对于需要自定义操作系统软件包，或者需要使用 Buildpacks 未涵盖的语言生态系统的工作负载来说，这会带来一些不便之处。在很大程度上， 镜像扩展 "弥补了这一差距。它允许平台团队在原本的标准构建过程中生成 build.Dockerfile 和 run.Dockerfile 步骤，但扩展运行镜像可能会损害 rebase 能力。因此，虽然团队重新获得了 Dockerfile 式的控制权，却牺牲了该模型之所以吸引人的快速打补丁路径。 Buildpacks 还可能导致冷构建速度变慢、镜像体积增大，并且将信任高度集中于平台的构建器上。本质上，这是在控制权与风险影响范围之间做出的抉择：治理权转移到了负责维护、签名和发布构建器的一方，而随着《 欧盟网络弹性法案 "》等法规的出台，这种压力只会与日俱增。 原文链接： https://www.infoq.com/news/2026/08/buildpacks-dockerfile-patching/ "