编写新Buildpack时如何指定构建与运行镜像及相关疑问

1. Stack弃用后的替代方案及自定义镜像的使用方式 #

Stack确实已被弃用，现在官方推荐直接通过Builder配置或Buildpack元数据关联构建与运行镜像，无需再创建Stack。

如果你已经有了自定义的基础构建/运行镜像，可通过两种方式使用：

• 方式一：创建自定义Builder
  编写builder.toml配置文件，直接指定你的镜像，示例如下：

  [[buildpacks]]
    id = "your-buildpack-id"
    version = "0.0.1"
    path = "./path-to-your-buildpack"
  
  [[order]]
    group = [{ id = "your-buildpack-id", version = "0.0.1" }]
  
  [stack]
    build-image = "your-custom-build-image:tag"
    run-image = "your-custom-run-image:tag"
  

  执行pack create-builder my-custom-builder --config builder.toml生成自定义Builder，之后用该Builder构建应用即可。
• 方式二：构建时直接指定镜像
  无需创建Builder，直接在pack build命令中通过参数指定你的镜像，同时确保Buildpack兼容这些镜像（可在Buildpack的buildpack.toml里将[[stacks]]的id设为"*"，或匹配镜像标签）：

  pack build my-app --build-image your-custom-build-image:tag --run-image your-custom-run-image:tag --buildpack ./path-to-your-buildpack
  

2. Builder的作用及对构建可重复性的影响 #

为何定义Stack后仍能用默认Builder？ #

默认Builder本身已内置了某一Stack对应的构建/运行镜像，文档用默认Builder是为了简化演示——只要默认Builder的Stack与你定义的兼容，就能正常执行构建。

Builder的核心作用 #

Builder是一个封装体，它把以下核心内容打包在一起：

• 构建环境（build-image）：包含构建应用所需的系统依赖、工具链
• 运行环境（run-image）：应用最终运行的基础镜像
• 一组Buildpacks：实现应用构建逻辑的具体集合
  简单来说，Builder给Buildpack提供了标准化的执行环境，避免每次构建都手动指定大量参数。

不同Builder对可重复性的影响 #

肯定会影响。不同Builder的差异体现在：

• 构建镜像中的系统库、工具版本不同（比如不同版本的Ubuntu、GCC等）
• 内置的Buildpack版本不同
• 运行镜像的基础环境不同
  这些差异会直接导致构建出的应用镜像内容不一致，破坏构建可重复性。因此要保证可重复构建，必须固定使用同一个Builder（含具体版本）。

内容的提问来源于stack exchange，提问作者Rashad Sirajudeen