Buildpack 将源代码转换为可执行文件,用于提供简单、可靠且可重复的容器创建方式。Kf 支持 V2 和 V3 Buildpack,因此您需要了解它们之间的区别。
V2 buildpack
大多数 Cloud Foundry 应用已在使用 V2 Buildpack。将 V2 Buildpack 与 Kf 搭配使用时,系统会从相应的 Git 网址下载和配置生命周期二进制文件和 Buildpack。之后,Kf 会使用 lifecycle
CLI 针对源代码执行每个 Buildpack。
优点
- 开箱即用,无需更改流水线或代码。
缺点
- 由 V3 代替的旧版 buildpack。
- 性能和可靠性略低。V2 Buildpack 的 Kf 构建流水线需要更多的 IO。
- 社区资源略少。
- Kf 仅支持 OSS Git 代码库。
V3 buildpack
V3 Buildpack 是一个 Cloud Native Computing Foundation (CNCF) 项目,它拥有一个明确定义的规范、一个 CLI (pack) 和一个不断完善的围绕不同语言和框架进行创新的社区。Google Cloud 也有自己的一组 Google Cloud 的 Buildpack。
V3 Buildpack 有两个核心 OCI 容器:
- 构建器映像
- 运行映像
构建器映像
您需要在将源代码构建到可运行的容器中时使用构建器映像。该映像包含编译源代码所需的 detect
脚本和其他实用程序。
运行映像
运行映像是用以构建容器的基础映像。这意味着,它是应用执行时将运行的基础映像。
图层
V3 Buildpack 使用层来编写最终容器。构建中包含的每个 Buildpack 都有可能会操作应用的文件系统和环境变量。这种分层方法使得 Buildpack 更轻量化且更通用。
V3 Buildpack 基于 OCI 容器构建而成。这要求将 V3 构建器映像存储在 Kf 构建流水线有权访问的 Container Registry 中。构建流水线使用构建器映像来应用底层脚本,将源代码构建到可运行的容器中。
优点
- Google 支持的构建器和运行映像。
- 可与 Cloud Build 等各种 Google Cloud 产品搭配使用。
- 不断完善的社区和 Buildpack 注册表。
缺点
- 可能需要更新代码/进程。例如,Java Buildpack 需要源代码,而 V2 Buildpack 则需要 jar 文件。
- V3 Buildpack 较新,可能需要进行额外的验证(使用社区开发的 Buildpack)。
kf 堆栈
查看堆栈
推送应用时,构建流水线会根据选定的堆栈(通过 --stack
标志或清单指定)确定 Buildpack。
如需查看空间中可用的堆栈,首先请确保定位空间:
kf target -s myspace
然后,您可以使用 kf stacks
子命令列出堆栈:
kf stacks
输出会同时显示 V2 和 V3 堆栈:
Getting stacks in Space: myspace
Version Name Build Image Run Image
V2 cflinuxfs3 cloudfoundry/cflinuxfs3@sha256:5219e9e30000e43e5da17906581127b38fa6417f297f522e332a801e737928f5 cloudfoundry/cflinuxfs3@sha256:5219e9e30000e43e5da17906581127b38fa6417f297f522e332a801e737928f5
V3 kf-v2-to-v3-shim gcr.io/kf-releases/v2-to-v3:v2.7.0 gcr.io/buildpacks/gcp/run:v1 This is a stack added by the integration tests to assert that v2->v3 shim works
V3 google gcr.io/buildpacks/builder:v1 gcr.io/buildpacks/gcp/run:v1 Google buildpacks (https://github.com/GoogleCloudPlatform/buildpacks)
V3 org.cloudfoundry.stacks.cflinuxfs3 cloudfoundry/cnb:cflinuxfs3@sha256:f96b6e3528185368dd6af1d9657527437cefdaa5fa135338462f68f9c9db3022 cloudfoundry/run:full-cnb@sha256:dbe17be507b1cc6ffae1e9edf02806fe0e28ffbbb89a6c7ef41f37b69156c3c2 A large Cloud Foundry stack based on Ubuntu 18.04
配置堆栈
您可以通过修改 kfsystem
自定义资源来更新堆栈配置:
kubectl edit kfsystem kfsystem
以下示例设置了 Google Cloud Buildpack V3 堆栈:
spec:
kf:
config:
spaceStacksV3:
- name: google
description: Google buildpacks (https://github.com/GoogleCloudPlatform/buildpacks)
buildImage: gcr.io/buildpacks/builder:v1
runImage: gcr.io/buildpacks/gcp/run:v1
您现在可以推送此新堆栈:
kf push myapp --stack google
以下示例配置 Ruby V2 buildpack 并将构建流水线默认值设置为使用 V2 堆栈:
spec:
kf:
config:
spaceDefaultToV3Stack: false
spaceBuildpacksV2:
- name: ruby_buildpack
url: https://github.com/cloudfoundry/ruby-buildpack
spaceStacksV2:
- name: cflinuxfs3
image: cloudfoundry/cflinuxfs3@sha256:5219e9e30000e43e5da17906581127b38fa6417f297f522e332a801e737928f5
V2 到 V3 Buildpack 迁移
Kf 会提供一个 V3 堆栈,用以使用名为 kf-v2-to-v3-shim
的堆栈来构建之前使用标准 V2 Buildpack 构建的应用。kf-v2-to-v3-shim
堆栈是在标准 V3 Buildpack API 的基础上创建的。系统会按照标准 Buildpack 流程随每个 Kf 版本创建一个由 Google 维护的构建器映像。该构建器映像会汇总由 kf wrap-v2-buildpack
命令所用进程创建的 V3 Buildpack 的列表。这些 V3 Buildpack 映像将使用标准 V2 Buildpack 映像进行创建。请务必注意,这些 V3 Buildpack 不包含所引用 V2 Buildpack 的二进制文件。但是,它们会引用 V2 Buildpack 映像,并会在应用构建时下载位(通过运行 kf push
)。
在应用构建时,系统会从相应的 Git 代码库下载 V2 Buildpack。当 V3 检测运行时,它会被委托给下载的 V2 检测脚本。对于通过检测的第一个 Buildpack 组,它会继续执行构建步骤,该步骤会将构建执行委托给下载的 V2 构建器脚本。
kf-v2-to-v3-shim
堆栈支持以下 V2 Buildpack:
Buildpack | Git 代码库 |
---|---|
java_buildpack | https://github.com/cloudfoundry/java-buildpack |
dotnet_core_buildpack | https://github.com/cloudfoundry/dotnet-core-buildpack |
nodejs_buildpack | https://github.com/cloudfoundry/nodejs-buildpack |
go_buildpack | https://github.com/cloudfoundry/go-buildpack |
python_buildpack | https://github.com/cloudfoundry/python-buildpack |
binary_buildpack | https://github.com/cloudfoundry/binary-buildpack |
nginx_buildpack | https://github.com/cloudfoundry/nginx-buildpack |
选项 1:迁移使用标准 V2 buildpack 构建的应用
如需使用 kf-v2-to-v3-shim
堆栈构建应用,请使用以下命令:
kf push myapp --stack kf-v2-to-v3-shim
kf-v2-to-v3-shim
堆栈将通过封装的 V2 Buildpack 自动检测运行时。生成的应用映像使用 V3 标准和构建流水线创建,但会使用等效的 V2 Buildpack 构建器。
选项 2:迁移使用自定义 V2 buildpack 构建的应用
Kf 有一个 Buildpack 迁移工具,该工具可以接受 V2 Buildpack 并使用 V3 Buildpack 将其封装。之后,您便可以在任何支持 V3 Buildpack 的位置使用该封装的 Buildpack。
kf wrap-v2-buildpack gcr.io/your-project/v2-go-buildpack https://github.com/cloudfoundry/go-buildpack --publish
这将创建一个名为 gcr.io/your-project/v2-go-buildpack
的 Buildpack 映像。之后,您便可以按照创建构建器文档中的说明使用该映像来创建构建器。
此子命令以透明方式使用以下 CLI:
go
git
pack
unzip
建议您使用 Cloud Shell Editor 来确保每条子命令在正确的路径上可用且版本正确。
已知问题
以下是无法与 Kf 搭配使用的功能。如果某项功能对您的组织来说具有较高的优先级,请与您的销售代表联系:
- V3 构建器映像的私有容器注册表。
- V3 缓存。
- 需要 Git 凭据的 V2 Buildpack。