Cloud Native Buildpacks 怎样把运行时与源码构建分离

Cloud Native Buildpacks 把源码如何变成应用层、构建时需要什么环境、应用运行时依赖什么基础镜像分成不同对象。buildpack 负责识别与构建，builder 汇集构建所需组件，run image 提供最终应用镜像的运行基础。满足兼容条件时，可以通过 rebase 更新运行基础层，而不完整重建应用。

但“运行时与源码构建分离”不能理解成所有语言运行时都在 run image 中。某些 JRE、Node 或其他启动依赖可能由 buildpack 放入应用镜像的依赖层；这部分更新通常仍需重新构建，不能指望替换基础层自动修复。

官方地址：https://buildpacks.io/

Cloud Native Buildpacks 已是 CNCF 毕业项目。本文讨论其现有架构与供应链取舍，不把该状态或基础能力包装成刚发布的新消息。

从一项基础镜像修复说起

假设应用源码没变，平台团队发布了修复系统库的运行基础镜像。团队面临两个选择：从源码再构建一遍，或者在符合条件时更新已有应用镜像的基础层。前者能同时重新解析构建输入，后者则将更新范围集中在运行基础层。

这个场景最需要保护的是对象关系：原应用使用的基础镜像是什么，修复进入了哪一层，新的基础镜像是否适合这些应用层。若只看到“存在漏洞”就统一执行 rebase，可能根本没有碰到有问题的 buildpack 依赖层。

三个对象分别负责什么

builder 本身是 OCI 镜像，包含有序的 buildpacks、build image 和 lifecycle，并带有 run image 引用。build image 提供构建环境；run image 提供应用镜像运行基础，两者不是同一个角色。

buildpack 根据源码和依赖描述识别适用任务，执行相应构建，并提供应用需要的层与启动配置。最终应用镜像并不是把整个 builder 原样作为运行环境。构建时工具和运行时必要内容有了分开的组织方式，但最终包含什么，仍取决于具体 buildpack 与平台配置。

rebase 更新的是哪一层

官方文档把 rebase 描述为更新应用镜像的基础层引用，避免完整重建应用。应用相关层可以保留，但这不是任意更换发行版、体系结构或系统接口的通用许可；兼容性条件与具体工具版本应一起考虑。

如果修复位于 run image，可以评估 rebase。如果修复位于源码依赖、buildpack 提供的语言运行时或其他应用相关层，应更新对应输入并重新构建。无法确认层归属时，先查看制品元数据与组件信息，不要用更新命令是否成功来代替范围判断。

下面只展示读取 builder 信息的入口，不对任何实际镜像执行更新。使用时将变量设为团队批准的 builder 引用。

# 查看builder声明的组件与run image信息，用于确认构建输入
: "${BUILDER_REF:?请提供批准的builder引用}"
pack builder inspect "$BUILDER_REF"

这类信息能帮助确定配置来源，却不能单独保证某次应用发布的所有输入都已固定。项目配置、构建环境变量、额外 buildpack 或平台覆盖项也可能改变结果，应与最终构建记录一起保存。

自动化构建仍有需要管理的信任入口

buildpack 会处理源码并可能下载依赖，因此它本身属于有执行能力的供应链组件。减少 Dockerfile 的手工维护，不等于不再需要控制构建输入。来源未知的 builder 或临时加入的 buildpack，可能改变下载对象和构建行为。

平台可以维护批准的 builder 与 run image 清单，记录实际解析的摘要，并限制非必要构建权限。依赖版本与下载源也应受控；不应将部署凭据不加区分地作为普通构建变量传给所有组件。具体秘密传递机制需使用平台和 buildpack 明确支持的方式。

缓存有助于复用构建内容，但缓存存在不是新输入可信的证明。若某个组件版本发生变化，仍应能知道实际使用了什么。这里的关键不是把所有更新禁止掉，而是让更新由哪个维护方发起、影响哪些层、形成了哪个新制品都有明确记录。

基础层更新后，发布记录也要更新

rebase 即使保留应用层，也会形成新的应用镜像对象，其最终摘要不能继续沿用旧制品的记录。与摘要绑定的签名和来源材料应按工具链实际支持重新处理，不能把旧制品的放行结论直接改个标签后搬到新对象。

记录至少包含源码版本、builder 引用与实际摘要、buildpack 组合、原 run image 与新 run image、操作类型及最终应用摘要。若需要回滚，应保留明确的旧制品引用，并按当前发布策略处理，不应只依赖会继续变化的标签。

在进入运行环境前，团队需要确认启动行为、必要系统库与目标平台匹配。本文没有运行应用、生成性能指标或宣称更新成功；这里描述的是使用 Buildpacks 时应安排的工程职责，而不是本次文章发布的校验步骤。

更新 builder 会自动修复已部署应用吗

不会自动成立。builder 影响后续构建；已有应用需要通过相应的重建或基础层更新流程形成新制品，再由部署系统采用。

rebase 能升级所有语言依赖吗

不能。位于应用或 buildpack 依赖层的内容，不会因为更新 run image 就自动替换。

是否还需要维护运行基础镜像

需要，只是维护职责可以集中到平台侧。分离解决的是组件组织和更新边界，不是取消基础镜像的生命周期管理。

参考：Builder 的组成；基础镜像概念；Rebase 的更新范围。