云原生正在吞并软件世界，容器改变了传统的应用开发模式，如今研发人员不仅要构建应用，还要使用 Dockerfile 来完成应用的容器化，将应用及其依赖关系打包，从而获得更可靠的产品，提高研发效率。
随着项目的迭代，达到一定的规模后，就需要运维团队和研发团队之间相互协作。运维团队的视角与研发团队不同，他们对镜像的需求是安全和标准化。比如：
不同的应用应该选择哪种基础镜像？
应用的依赖有哪些版本？
应用需要暴露的端口有哪些？
为了优化运维效率，提高应用安全性，研发人员需要不断更新 Dockerfile 来实现上述目标。同时运维团队也会干预镜像的构建，如果基础镜像中有 CVE 被修复了，运维团队就需要更新 Dockerfile，使用较新版本的基础镜像。总之，运维与研发都需要干预 Dockerfile，无法实现解耦。
为了解决这一系列的问题，涌现出了更加优秀的产品来构建镜像，其中就包括 Cloud Native Buildpacks (СNB)。CNB 基于模块化提供了一种更加快速、安全、可靠的方式来构建符合 OCI 规范的镜像，实现了研发与运维团队之间的解耦。
Buildpacks是一款对标Docker的镜像打包工具，虽然在CNCF中作为核心项目，但在目前的主流开发场景中用到的并不多。
什么是Buildpacks
Buildpacks简介
Buildpack位于CNCF全景图的应用定义和镜像构建这一层，可以看出这个东西是用来构建镜像的
Buildpacks 是一个项目，最早由 Heroku 在 2011 年发起，被以 Cloud Foundry 为代表的 PaaS 平台广泛采用。Buildpacks 的目标是实现统一的应用打包生态系统，支持广泛的编程语言，支持各种 CI/CD 工具，支持各种扩展插件。
在 2018 年 1 月，Pivotal 和 Heroku 发起了一个项目 Cloud Native Buildpacks (简称 CNB)，并在同年十月份加入 CNCF。CNB 提供了一种更加快速、安全、可靠的方式来构建符合 OCI 规范的镜像，实现了研发与运维团队之间的解耦。
总的来说，Buildpacks 提供了一种高级别的抽象，使得开发者可以专注于代码逻辑，而不需要关心应用的构建和部署的细节。这使得 Buildpacks 成为了构建和部署应用的强大工具。
举个栗子：当我们构建docker镜像时，往往需要编写一个dockerfile，指定使用的基础镜像和一些参数。如果是构建springboot的镜像时，有时候还需要配置jvm参数，这样还是太麻烦了。如果使用buildpacks的话，以上的步骤就可以减免，buildpacks会自动帮你选择最适合的基础镜像和参数给你构建最佳的镜像，同时还可以自动修复镜像中存在的安全问题，并且不需要dockerfile。
更多就不说了，可以自行去官网学习：https://buildpacks.io/
Buildpacks的优点
- 不需要写 Dockerfile
- 打包成镜像只需要一行命令
- 支持多语言
- 可以把注意力集中在代码逻辑上
- 容器镜像的安全性由 builder 处理
- 通过rebase可以快速增量更新镜像
Buildpacks适合哪些人
Cloud Native Buildpacks 非常适合需要频繁打包应用的场景, 而且应用的种类比较多。
aPaaS 平台
aPaaS 是提供运行时的平台, 经常需要部署各类应用。使用 Cloud Native Buildpacks 能规范打包流程, 快速将源码转换为镜像。
FaaS 平台
FaaS 平台提供函数的运行环境。在以容器为核心的基础设施上, FaaS 将用户代码打包为镜像, 再创建容器运行。而 Cloud Native Buildpacks 既能探测用户代码的编程语言、框架, 还能快速编译成 OCI 镜像, 正是 FaaS 之所需。Google Cloud Platform 的 FaaS 采用的就是 Buildpacks。
开发者
并不是每个开发者都适合使用 Cloud Native Buildpacks, 学习和维护也需要成本。如果你有很多应用需要维护和发布, 那么 Cloud Native Buildpacks 将拯救你, 起码可以少写很多 Dockerfile。
有哪些开源的buildpacks
其实现在有很多开源的 buildpack 可以用，没有特定定制的情况下无需自己手动编写。比如下面的几个大厂开源并维护的 Buildpacks。
-
Heroku Buildpacks[https://devcenter.heroku.com/articles/buildpacks#using-a-third-party-buildpack]
-
Google Buildpacks[https://cloud.google.com/docs/buildpacks?hl=zh-cn]
-
Paketo[https://paketo.io/]（一般常用这个厂商的，听说是spring的亲儿子）
和其他工具对比如下：
Buildpacks的使用
安装
前提：你的电脑需要有docker，不支持其他容器
docker安装不罗嗦，看官网：https://docker.p2hp.com/get-started/index.html
windows
winget install buildpacks.pack
Linux/Mac OS
我没有苹果电脑，安装清看这里：https://buildpacks.io/docs/tools/pack/
使用方法（入门）
pack-cli
以我的cloud-events-demo为例，这个应用是基于springboot3.2.1和java21来开发的
1-显示建议的builders
pack suggest-builders
2-构建镜像
pack cli会自动帮我们构建镜像，不需要dockerfile
pack build images.midea.com/cloud-enents-demo:latest --builder paketobuildpacks/builder-jammy-base
有趣的事情发生了，cloud-events-demo是使用java21的，但是它自动给我推荐的java是17的版本，显然还不够智能
不出意外的话，应该是出了意外，使用java 17无法构建java21的项目
指定java 21镜像，可以看到上图是通过变量BP_JVM_VERSION来指定JDK版本的
pack build images.midea.com/cloud-enents-demo:latest --builder paketobuildpacks/builder-jammy-base --env BP_JVM_VERSION=21
可以看到真的使用java21来进行镜像构建了，我们先等待它构建完成看看
镜像构建完成了，awesome,先看看打出来的镜像大小以及里面有什么东西
让我们进入容器内看看buildpacks帮我们配置的jvm参数
spring boot的maven插件
<plugin>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-maven-plugin</artifactId>
<executions>
<execution>
<goals>
<goal>build-image-no-fork</goal>
</goals>
</execution>
</executions>
</plugin>
参考
Modern Build Systems for Containers: https://fosdem.org/2024/events/attachments/fosdem-2024-3398-modern-build-systems-for-containers/slides/22454/Modern_Build_Systems_for_Containers_gR4dSaa.pdf
Safer Image Builds with Cloud Native Buildpacks and Wolfi: https://thenewstack.io/safer-image-builds-with-cloud-native-buildpacks-and-wolfi/