共计 9383 个字符，预计需要花费 24 分钟才能阅读完成。
作者：米开朗基杨，方阗
云原生正在吞并软件世界，容器扭转了传统的利用开发模式，现在研发人员不仅要构建利用，还要应用 Dockerfile 来实现利用的容器化，将利用及其依赖关系打包，从而取得更牢靠的产品，进步研发效率。
随着我的项目的迭代，达到肯定的规模后，就须要运维团队和研发团队之间相互协作。运维团队的视角与研发团队不同，他们对镜像的需要是 平安 和标准化。比方：
- 不同的利用应该抉择哪种根底镜像？
- 利用的依赖有哪些版本？
- 利用须要裸露的端口有哪些？
为了优化运维效率，进步利用安全性，研发人员须要不断更新 Dockerfile 来实现上述指标。同时运维团队也会干涉镜像的构建，如果根底镜像中有 CVE 被修复了，运维团队就须要更新 Dockerfile，应用较新版本的根底镜像。总之，运维与研发都须要干涉 Dockerfile，无奈实现解耦。
为了解决这一系列的问题，涌现出了更加优良的产品来构建镜像，其中就包含 Cloud Native Buildpacks (СNB)。CNB 基于模块化提供了一种更加疾速、平安、牢靠的形式来构建合乎 OCI 标准的镜像，实现了研发与运维团队之间的解耦。
在介绍 CNB 之前，咱们先来论述几个基本概念。
合乎 OCI 标准的镜像
现在，容器运行时早就不是 Docker 一家独大了。为了确保所有的容器运行时都能运行任何构建工具生成的镜像，Linux 基金会与 Google，华为，惠普，IBM，Docker，Red Hat，VMware 等公司独特发表成立凋谢容器我的项目（OCP），后更名为凋谢容器倡导（OCI）。OCI 定义了围绕容器镜像格局和运行时的行业标准，给定一个 OCI 镜像，任何实现 OCI 运行时规范的容器运行时都能够应用该镜像运行容器。
如果你要问 Docker 镜像与 OCI 镜像之间有什么区别，现在的答案是：简直没有区别。有一部分旧的 Docker 镜像在 OCI 标准之前就曾经存在了，它们被成为 Docker v1 标准，与 Docker v2 标准是不兼容的。而 Docker v2 标准捐给了 OCI，形成了 OCI 标准的根底。现在所有的容器镜像仓库、Kubernetes 平台和容器运行时都是围绕 OCI 标准建设的。
什么是 Buildpacks
Buildpacks 我的项目最早由 Heroku 在 2011 年发动, 被以 Cloud Foundry 为代表的 PaaS 平台宽泛采纳。
一个 buildpack 指的就是一个将源代码变成 PaaS 平台可运行的压缩包的程序，通常状况下，每个 buildpack 封装了繁多的语言生态系统的工具链，例如 Ruby、Go、NodeJs、Java、Python 等都有专门的 buildpack。
你能够将 buildpack 了解成一坨脚本，这坨脚本的作用是将利用的可执行文件及其依赖的环境、配置、启动脚本等打包，而后上传到 Git 等仓库中，打好的压缩包被称为 droplet。
而后 Cloud Foundry 会通过调度器抉择一个能够运行这个利用的虚拟机，而后告诉这个机器上的 Agent 下载利用压缩包，依照 buildpack 指定的启动命令，启动利用。
到了 2018 年 1 月，Pivotal 和 Heroku 联结发动了 Cloud Native Buildpakcs(CNB) 我的项目，并在同年 10 月让这个我的项目进入了 CNCF。
2020 年 11 月，CNCF 技术监督委员会（TOC）投票决定将 CNB 从沙箱我的项目晋升为孵化我的项目。是时候好好钻研一下 CNB 了。
为什么须要 Cloud Native Buildpacks
Cloud Native Buildpacks(CNB) 能够看成是 基于云原生的 Buildpacks 技术，它反对古代语言生态系统，对开发者屏蔽了利用构建、部署的细节，如选用哪种操作系统、编写适应镜像操作系统的解决脚本、优化镜像大小等等，并且会产出 OCI 容器镜像，能够运行在任何兼容 OCI 镜像规范的集群中。CNB 还拥抱了很多更加云原生的个性，例如跨镜像仓库的 blob 挂载和镜像层级 rebasing。
由此可见 CNB 的镜像构建形式更加标准化、自动化，与 Dockerfile 相比，Buildpacks 为构建利用提供了更高层次的形象，Buildpacks 对 OCI 镜像构建的形象，就相似于 Helm 对 Deployment 编排的形象。
2020 年 10 月，Google Cloud 开始发表全面反对 Buildpacks，蕴含 Cloud Run、Anthos 和 Google Kubernetes Engine (GKE)。目前 IBM Cloud、Heroku 和 Pivital 等公司皆已采纳 Buildpacks，如果不出意外，其余云供应商很快就会效仿。
Buildpacks 的长处：
- 针对同一构建目标的利用，不必反复编写构建文件（只须要应用一个 Builder）。
- 不依赖 Dockerfile。
- 能够依据丰盛的元数据信息（buildpack.toml）轻松地查看到每一层（buildpacks）的工作内容。
- 在更换了底层操作系统之后，不须要从新改写镜像构建过程。
- 保障利用构建的安全性和合规性，而无需开发者干涉。
Buildpacks 社区还给出了一个表格来比照同类利用打包工具：
能够看到 Buildpacks 与其余打包工具相比，反对的性能更多，包含：缓存、源代码检测、插件化、反对 rebase、重用、CI/CD 多种生态。
Cloud Native Buildpacks 工作原理
Cloud Native Buildpacks 次要由 3 个组件组成：Builder、Buildpack 和 Stack。
Buildpack
Buildpack 实质是一个可执行单元的汇合，个别包含检查程序源代码、构建代码、生成镜像等。一个典型的 Buildpack 须要蕴含以下三个文件：
- buildpack.toml – 提供 buildpack 的元数据信息。
- bin/detect – 检测是否应该执行这个 buildpack。
- bin/build – 执行 buildpack 的构建逻辑，最终生成镜像。
Builder
Buildpacks 会通过“检测”、“构建”、“输入”三个动作实现一个构建逻辑。通常为了实现一个利用的构建，咱们会应用到多个 Buildpacks，那么 Builder 就是一个构建逻辑的汇合，蕴含了构建所须要的所有组件和运行环境的镜像。
咱们通过一个假如的流水线来尝试了解 Builder 的工作原理：
- 最后，咱们作为利用的开发者，筹备了一份利用源代码，这里咱们将其标识为“0”。
- 而后利用“0”来到了第一道工序，咱们应用 Buildpacks1 对其进行加工。在这个工序中，Buildpacks1 会查看利用是否具备“0”标识，如果有，则进入构建过程，即为利用标识增加“1”，使利用标识变更为“01”。
- 同理，第二道、第三道工序也会依据本身的准入条件判断是否须要执行各自的构建逻辑。
在这个例子中，利用满足了三道工序的准入条件，所以最终输入的 OCI 镜像的内容为“01234”的标识。
对应到 Buildpacks 的概念中，Builders 就是 Buildpacks 的有序组合，蕴含一个根底镜像叫 build image、一个 lifecycle 和对另一个根底镜像 run image 的利用。Builders 负责将利用源代码构建成利用镜像（app image）。
build image 为 Builders 提供根底环境（例如 带有构建工具的 Ubuntu Bionic OS 镜像），而 run image 在运行时为 利用镜像（app image）提供根底环境。build image 和 run image 的组合被称为 Stack。
Stack
下面提到，build image 和 run image 的组合被称为 Stack，也就是说，它定义了 Buildpacks 的执行环境和最终利用的根底镜像。
你能够将 build image 了解为 Dockerfile 多阶段构建中第一阶段的 base 镜像，将 run image 了解为第二阶段的 base 镜像。
上述 3 个组件都是以 Docker 镜像的模式存在，并且提供了非常灵活的配置选项，还领有管制所生成镜像的每一个 layer 的能力。联合其弱小的 caching 和 rebasing 能力，定制的组件镜像能够被多个利用反复利用，并且每一个 layer 都能够依据须要独自更新。
Lifecycle 是 Builder 中最重要的概念，它将由利用源代码到镜像的构建步骤形象进去，实现了对整个过程的编排，并最终产出利用镜像。上面咱们独自用一个章节来介绍 Lifecycle。
构建生命周期（Lifecyle）
Lifecycle 将所有 Buildpacks 的探测、构建过程抽离进去，分成两个大的步骤聚合执行：Detect 和 Build。这样一来就升高了 Lifecycle 的架构复杂度，便于实现自定义的 Builder。
除了 Detect 和 Build 这两个次要步骤，Lifecycle 还蕴含了一些额定的步骤，咱们一起来解读。
Detect
咱们之前提到，在 Buildpack 中蕴含了一个用于探测的 /bin/detect 文件，那么在 Detect 过程中，Lifecycle 会领导所有 Buildpacks 中的 /bin/detect 按程序执行，并从中获取执行后果。
那么 Lifecycle 把 Detect 和 Build 离开后，又是怎么维系这两个过程中的关联关系呢？
Buildpacks 在 Detect 和 Build 阶段，通常都会告知在本人这个过程中会须要哪些前提，以及本人会提供哪些后果。
在 Lifecycle 中，提供了一个叫做 Build Plan 的构造体用于寄存每个 Buildpack 的所需物和产出物。
type BuildPlanEntry struct {
Providers `toml:“providers”`
Requires `toml:"requires"` 同时，Lifecycle 也规定，只有当所有产出物都匹配有一个对应的所需物时，这些 Buildpacks 能力组合成一个 Builder。
Analysis
Buildpacks 在运行中会创立一些目录，在 Lifecycle 中这些目录被称为 layer。那么为了这些 layer 中，有一些是能够作为缓存提供给下一个 Buildpacks 应用的，有一些则是须要在利用运行时起作用的，还有的则是须要被清理掉。怎么能力更灵便地管制这些 layer？
Lifecycle 提供了三个开关参数，用于示意每一个 layer 冀望的解决形式：
- launch 示意这个 layer 是否将在利用运行时起作用。
- build 示意这个 layer 是否将在后续的构建过程中被拜访。
- cache 则示意这个 layer 是否将作为缓存。
之后，Lifecycle 再依据一个关系矩阵来判断 layer 的最终归宿。咱们也能够简略的了解为，Analysis 阶段为构建、利用运行提供了缓存。
Build
Build 阶段会利用 Detect 阶段产出的 build plan，以及环境中的元数据信息，配合保留至本阶段的 layers，对利用源码执行 Buildpacks 中的构建逻辑。最终生成可运行的利用工件。
Export
Export 阶段比拟好了解，在实现了上述构建之后，咱们须要将最初的构建后果产出为一个 OCI 规范镜像，这样一来，这个 App 工件就能够运行在任何兼容 OCI 规范的集群中。
Rebase
在 CNB 的设计中，最初 app 工件理论是运行在 stack 的 run image 之上的。能够了解为 run image 以上的工件是一个整体，它与 run image 以 ABI(application binary interface) 的模式对接，这就使得这个工件能够灵便切换到另一个 run image 上。
这个动作其实也是 Lifecycle 的一部分，叫做 rebase。在构建镜像的过程中也有一次 rebase，产生在 app 工件由 build image 切换到 run image 上。
这种机制也是 CNB 比照 Dockerfile 最具劣势的中央。比方在一个大型的生产环境中，如果容器镜像的 OS 层呈现问题，须要更换镜像的 OS 层，那么针对不同类型的利用镜像就须要重写他们的 dockerfile 并验证新的 dockerfile 是否可行，以及新减少的层与已存在的层之间是否有抵触，等等。而应用 CNB 只须要做一次 rebase 即可，简化了大规模生产中镜像的降级工作。
以上就是对于 CNB 构建镜像的流程剖析，总结来说：
- Buildpacks 是最小构建单元，执行具体的构建操作；
- Lifecycle 是 CNB 提供的镜像构建生命周期接口；
- Builder 是若干 Buildpacks 加上 Lifecycle 以及 stack 造成的具备特定构建目标的构建器。
再精减一下：
- build image + run image = stack
- stack(build image) + buildpacks + lifecycle = builder
- stack(run image) + app artifacts = app
那么当初问题来了，这个工具怎么应用呢？
Platform
这时候就须要一个 Platform，Platform 其实是 Lifecycle 的执行者。它的作用是将 Builder 作用于给定的源代码上，实现 Lifecycle 的指令。
在这个过程中，Builder 会将源代码构建为 app，这个时候 app 是在 build image 中的。这个时候依据 Lifecycle 中的 rebase 接口，底层逻辑是是用 ABI(application binary interface) 将 app 工件从 build image 转换到 run image 上。这就是最初的 OCI 镜像。
罕用的 Platform 有 Tekton 和 CNB 的 Pack。接下来咱们将应用 Pack 来体验如何应用 Buildpacks 构建镜像。
装置 Pack CLI 工具
目前 Pack CLI 反对 Linux、MacOS 和 Windows 平台，以 Ubuntu 为例，装置命令如下：
$ sudo add-apt-repository ppa:cncf-buildpacks/pack-cli
$ sudo apt-get update
$ sudo apt-get install pack-cli查看版本：
$ pack version
0.22.0+git-26d8c5c.build-2970留神：在应用 Pack 之前，须要先装置并运行 Docker。
目前 Pack CLI 只反对 Docker，不反对其余容器运行时（比方 Containerd 等）。但 Podman 能够通过一些 hack 来变相反对，以 Ubuntu 为例，大略步骤如下：
先装置 podman。
$ . /etc/os-release
$ echo "deb https://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/xUbuntu_${VERSION_ID}/ /" | sudo tee /etc/apt/sources.list.d/devel:kubic:libcontainers:stable.list
$ curl -L "https://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/xUbuntu_${VERSION_ID}/Release.key" | sudo apt-key add -
$ sudo apt-get update
$ sudo apt-get -y upgrade
$ sudo apt-get -y install podman而后启用 Podman Socket。
$ systemctl enable --user podman.socket
$ systemctl start --user podman.socket指定 DOCKER_HOST 环境变量。
$ export DOCKER_HOST="unix://$(podman info -f"{{.Host.RemoteSocket.Path}}")"最终就能够实现在 Podman 容器运行时中应用 Pack 来构建镜像。具体配置步骤可参考 Buildpacks 官网文档。
应用 Pack 构建 OCI 镜像
装置完 Pack 之后，咱们能够通过 CNB 官网提供的 samples 加深对 Buildpacks 原理的了解。这是一个 Java 示例，构建过程中无需装置 JDK、运行 Maven 或其余构建环境，Buildpacks 会为咱们解决好这些。
首先克隆示例仓库：
$ git clone https://github.com/buildpacks/samples.git前面咱们将应用 bionic 这个 Builder 来构建镜像，先来看下该 Builder 的配置：
$ cat samples/builders/bionic/builder.toml
# Buildpacks to include in builder
[[buildpacks]]
id = "samples/java-maven"
version = "0.0.1"
uri = "../../buildpacks/java-maven"
[[buildpacks]]
id = "samples/kotlin-gradle"
version = "0.0.1"
uri = "../../buildpacks/kotlin-gradle"
[[buildpacks]]
id = "samples/ruby-bundler"
version = "0.0.1"
uri = "../../buildpacks/ruby-bundler"
[[buildpacks]]
uri = "docker://cnbs/sample-package:hello-universe"
# Order used for detection
[[order]]
[[order.group]]
id = "samples/java-maven"
version = "0.0.1"
[[order]]
[[order.group]]
id = "samples/kotlin-gradle"
version = "0.0.1"
[[order]]
[[order.group]]
id = "samples/ruby-bundler"
version = "0.0.1"
[[order]]
[[order.group]]
id = "samples/hello-universe"
version = "0.0.1"
# Stack that will be used by the builder
[stack]
id = "io.buildpacks.samples.stacks.bionic"
run-image = "cnbs/sample-stack-run:bionic"
build-image = "cnbs/sample-stack-build:bionic"builder.toml 文件中实现了对 Builder 的定义，配置构造能够划分为 3 个局部：
- [[buildpacks]] 语法标识用于定义 Builder 所蕴含的 Buildpacks。
- [[order]] 用于定义 Builder 所蕴含的 Buildpacks 的执行程序。
- [[stack]] 用于定义 Builder 将运行在哪个根底环境之上。
咱们能够应用这个 builder.toml 来构建本人的 builder 镜像：
$ cd samples/builders/bionic
$ pack builder create cnbs/sample-builder:bionic --config builder.toml
284055322776: Already exists
5b7c18d5e17c: Already exists
8a0af02bbad1: Already exists
0aa0fb9222a5: Download complete
3d56f4bc2c9a: Already exists
5b7c18d5e17c: Already exists
284055322776: Already exists
8a0af02bbad1: Already exists
a967314b5694: Already exists
a00d148009e5: Already exists
dbb2c49b44e3: Download complete
53a52c7f9926: Download complete
0cceee8a8cb0: Download complete
c238db6a02a5: Download complete
e925caa83f18: Download complete
Successfully created builder image cnbs/sample-builder:bionic
Tip: Run pack build <image-name> --builder cnbs/sample-builder:bionic to use this builder接着，进入 samples/apps 目录，应用 pack 工具和 builder 镜像，实现利用的构建。当构建胜利后，会产出一个名为 sample-app 的 OCI 镜像。
$ cd ../..
$ pack build --path apps/java-maven --builder cnbs/sample-builder:bionic sample-app最初应用 Docker 运行这个 sample-app 镜像：
$ docker run -it -p 8080:8080 sample-app拜访 http://localhost:8080，如果一切正常，你能够在浏览器中看见如下的界面：
当初咱们再来察看一下之前构建的镜像：
$ docker images
REPOSITORY TAG IMAGE ID CREATED SIZE
cnbs/sample-package hello-universe e925caa83f18 42 years ago 4.65kB
sample-app latest 7867e21a60cd 42 years ago 300MB
cnbs/sample-builder bionic 83509780fa67 42 years ago 181MB
buildpacksio/lifecycle 0.13.1 76412e6be4e1 42 years ago 16.4MB镜像的创立工夫居然都是固定的工夫戳：42 years ago。这是为什么呢？如果工夫戳不固定，每次构建镜像的 hash 值都是不同的，一旦 hash 值不一样，就不太容易判断镜像的内容是否雷同了。应用固定的工夫戳，就能够反复利用之前的构建过程中创立的 layers。
总结
Cloud Native Buildpacks 代表了古代软件开发的一个重大提高，在大部份场景下绝对于 Dockerfile 的益处是立杆见影的。尽管大型企业须要投入精力从新调整 CI/CD 流程或编写自定义 Builder，但从久远来看能够节俭大量的工夫和保护老本。
本文介绍了 Cloud Native Buildpacks(CNB) 的起源以及绝对于其余工具的劣势，并具体论述了 CNB 的工作原理，最初通过一个简略的示例来体验如何应用 CNB 构建镜像。后续的文章将会介绍如何创立自定义的 Builder、Buildpack、Stack，以及函数计算平台（例如，OpenFunction、Google Cloud Functions）如何利用 CNB 提供的 S2I 能力，实现从用户的函数代码到最终利用的转换过程。
本文由博客一文多发平台 OpenWrite 公布！