（译）Buildpacks 进入 CNCF 沙箱

今天 Pivotal、Salesforce Heroku 和 CNCF 联合宣布，云原生 Buildpacks 技术被接纳为 CNCF 沙箱项目。

多年以来 Salesforce Heroku 以及 Cloud Foundry 用户在 Buildpacks 的支持下，能够在不间断服务的情况下对应用及其依赖进行构建、打包和更新，让开发人员可以更加专注的在代码上投入精力。Buildpacks 最初由 Salesforce Heroku 开发，将应用程序的依赖一直抽象到操作系统级别。

这种抽象和分离能够在维持应用的持续运行的情况下，让基础设施针对系统缺陷和关键补丁进行升级。好点子值得向开原世界分享；Cloud Foundry 社区在项目初期就接收了 Buildpack 模型。目前数以百计的企业以及几十万开发人员都在生产环境中使用 Buildpacks 来对各种应用提供支持。

为了让更多社区从这一技术受益，最终 Pivotal 和 Salesforce Heroku 的工程师一同将该项目推向 CNCF，并命名为 Cloud Native Buildpacks（CNB）。该项目具备和 Heroku 以及 Cloud Foundry 生态系统中的 Buildpacks 同样的优秀特性。

Heroku 首席工程师 Terence Lee：Buildpacks 于 2011 年诞生于 Heroku，为多语言平台的实现铺平了道路。上百万的开发者通过这一技术的应用提高了生产力和安全性。我们自豪的为新的 Cloud Native Buildpacks 标准贡献专业知识和代码，从而更多开发者提供简化的从代码到容器的工作流。

Pivotal Cloud Foundry Buildpacks 项目负责人 Stephen Levine：Cloud Foundry Buildpacks 让 Pivotal 的企业客户能够管理大规模应用的依赖，提供更好的运维支持从而让开发人员更多的专注于商业价值的交付工作。拥抱云原生标准之后，Buildpacks 将提升到一个新的水平。

理解 Cloud Native Buildpacks

CNB 流程分为四个步骤，每个步骤都有各自的重要目标，最终产出就是 OCI 镜像。CNB 让开发和运维人员能够把创建各种软件的过程中所需的构建、补丁和重新打包的工作自动化成适合机器执行的重复任务。如果 Buildpacks 能够完成容器的构建和管理工作，还需要人工完成么？

1. 检测：对源码以及其它内容进行检测，查找与其匹配的可用 Buildpacks。假设提供一套 Java 源文件，就会检测到 Java Buildpack 适用于这一输入。
2. 分析：CNB 会在应用的生命周期中运行多次，在这一步骤里会对前一次的打包内容进行分析，分析过程会对文件的变更进行优化，从而减少构建时间和文件传输。这里会使用多个镜像层来对内容进行组织。
3. 构建：如果镜像层或者目录需要进行替换，构建过程就会生成新的层。这里会提供缓存来加速构建过程。
4. 导出：这个步骤中会生成最终镜像并推送到镜像仓库之中。传输、磁盘使用和更新时间都会用镜像层的更新操作来完成。另外 CVE 补丁也可以同时应用到多个镜像之中。

CNB 在 CNCF 生态系统中的旅途才刚刚开始，这其中包含了 Pivotal 客户、Salesforce Heroku 客户以及云原生用户的认可和贡献。很多用户在 Docker 和 Kubernetes 变得炙手可热之前就在 Buildpacks 技术上下了注，现在它们的投资已经成功的应用到了其他生态系统之中。

起步

所以还等什么？现在就去 Buildpacks.io 尝尝鲜吧。

Pivotal 理解，开源项目想要成功，很大程度上要靠开发者、合作伙伴以及客户构成的广泛、开放的社区。想要对项目做出贡献或者提出问题，可以关注项目的 Github 仓库 并关注项目账号 @buildpacks_io。