构建套件

其他源码

0.17.0

下载

构建套件

BuildKit 是一个工具包，用于以高效、富有表现力和可重复的方式将源代码转换为构建工件。

主要特点：

自动垃圾收集
可扩展的前端格式
并发依赖解析
高效的指令缓存
构建缓存导入/导出
嵌套构建作业调用
可分配的工人
多种输出格式
可插拔架构
无root权限执行

阅读 moby/moby#32925 的提案

介绍性博客文章 https://blog.mobyproject.org/introducing-buildkit-17e056cc5317

加入 Docker Community Slack 上的#buildkit频道

笔记

如果您访问此存储库以使用仅限 BuildKit 的 Dockerfile 功能，例如RUN --mount=type=(bind|cache|tmpfs|secret|ssh) ，请参阅 Dockerfile 参考。

笔记

从 Docker Engine 23.0 开始， docker build默认使用 Buildx 和 BuildKit。除非您想使用功能齐全的独立版本的 BuildKit，否则您不需要阅读本文档。

使用者
快速启动

图像/注册表
本地目录
Docker 压缩包
OCI 压缩包
容器镜像存储
使用buildctl构建 Dockerfile
使用外部前端构建 Dockerfile
Linux设置
Windows 设置
macOS 设置
从源代码构建
探索法学学士
探索 Dockerfile
输出

缓存

内联（将图像和缓存推送到一起）
注册表（分别推送镜像和缓存）
本地目录
GitHub Actions 缓存（实验）
S3 缓存（实验性）
Azure Blob 存储缓存（实验性）
垃圾收集
导出缓存
一致的散列

元数据
Systemd 套接字激活
将 BuildKit 公开为 TCP 服务

负载均衡

容器化 BuildKit

波德曼
内德特尔
库伯内斯
无守护进程

开放遥测支持
在没有 root 权限的情况下运行 BuildKit
构建多平台镜像

颜色输出控制
日志行数（对于 tty 模式下的活动步骤）
配置buildctl

贡献

使用者

BuildKit 由以下项目使用：

Moby 和 Docker ( DOCKER_BUILDKIT=1 docker build )
图像
OpenFaaS 云
容器构建接口
Tekton Pipelines（以前称为 Knative 构建模板）
Sanic 构建工具
瓦布
里约
金
袋容器
Docker 构建x
奥克特托云
地球档案
吉特波德
匕首
环境变量
仓库
命名空间
尤尼克拉夫特
开发者零
达克

快速启动

对于 Kubernetes 部署，请参阅examples/kubernetes 。

BuildKit 由buildkitd守护进程和buildctl客户端组成。虽然buildctl客户端可用于 Linux、macOS 和 Windows，但buildkitd守护程序目前仅适用于 Linux 和 *Windows。

此处提供适用于 Linux、macOS 和 Windows 的最新 BuildKit 二进制文件。

Linux设置

buildkitd守护进程需要安装以下组件：

runc 或 crun
容器（如果你想使用容器工作）

启动buildkitd守护进程：您需要在主机上以root用户身份运行buildkitd 。

 $ sudo buildkitd

要以非 root 用户身份运行buildkitd ，请参阅docs/rootless.md 。

buildkitd 守护进程支持两个工作后端：OCI (runc) 和 containerd。

默认情况下，使用 OCI (runc) 工作线程。您可以设置--oci-worker=false --containerd-worker=true以使用containerd工作人员。

我们愿意添加更多后端。

要使用 systemd 套接字激活来启动 buildkitd 守护进程，您可以安装 buildkit systemd 单元文件。请参阅 Systemd 套接字激活

默认情况下，buildkitd 守护进程侦听/run/buildkit/buildkitd.sock上的 gRPC API，但您也可以使用 TCP 套接字。请参阅将 BuildKit 公开为 TCP 服务。

Windows 设置

请参阅docs/windows.md中的说明和注释。

macOS 设置

Homebrew 公式（非官方）适用于 macOS。

 $brew安装buildkit

Homebrew 公式不包含守护程序 ( buildkitd )。

例如，Lima 可用于在 Linux VM 内启动守护进程。

 brew install limalimactl 启动模板://buildkitexport BUILDKIT_HOST="unix://$HOME/.lima/buildkit/sock/buildkitd.sock"

从源代码构建

要从源代码构建 BuildKit，请参阅.github/CONTRIBUTING.md 。

有关buildctl参考，请参阅此文档。

探索法学学士

BuildKit 构建基于称为 LLB 的二进制中间格式，用于定义运行构建部分的进程的依赖关系图。 tl;dr：LLB 之于 Dockerfile 就像 LLVM IR 之于 C。

编组为 Protobuf 消息
并发可执行
高效可缓存
供应商中立（即非 Dockerfile 语言可以轻松实现）

有关格式定义，请参阅solver/pb/ops.proto ，有关示例LLB应用程序，请参阅./examples/README.md 。

目前，LLB已实现以下高级语言：

Dockerfile（请参阅探索 Dockerfile）
构建包
莫克文件
戈克菲勒
bldr（Pkg 文件）
HLB
地球档案（地球）
货运码头（铁锈）
尼克斯
莫伊 (Python)
envd（星雀）
大声哭
低音
kraft.yaml (Unikraft)
r2d4/llb（JSON 网关）
（打开 PR 添加您自己的语言）

探索 Dockerfile

前端是在 BuildKit 内运行并将任何构建定义转换为 LLB 的组件。有一个名为 gateway ( gateway.v0 ) 的特殊前端，它允许使用任何图像作为前端。

在开发过程中，Dockerfile 前端 ( dockerfile.v0 ) 也是 BuildKit 存储库的一部分。将来，这将被移出，并且可以使用外部映像构建 Dockerfile。

使用`buildctl`构建 Dockerfile

构建ctl构建
     --frontend=dockerfile.v0
     --本地上下文=。
     --local dockerfile=.# orbuildctl 构建
     --frontend=dockerfile.v0
     --本地上下文=。
     --本地 dockerfile=.
     --opt 目标=foo
     --opt 构建参数：foo=bar

--local将本地源文件从客户端公开给构建器。 context和dockerfile是 Dockerfile 前端查找构建上下文和 Dockerfile 位置的名称。

如果 Dockerfile 有不同的文件名，可以使用--opt filename=./Dockerfile-alternative指定。

使用外部前端构建 Dockerfile

Dockerfile 前端的外部版本被推送到 https://hub.docker.com/r/docker/dockerfile-upstream 和 https://hub.docker.com/r/docker/dockerfile，并且可以与网关前端一起使用。外部前端的源当前位于./frontend/dockerfile/cmd/dockerfile-frontend中，但将来会移出此存储库 (#163)。对于从此存储库的 master 分支自动构建，可以使用docker/dockerfile-upstream:master或docker/dockerfile-upstream:master-labs镜像。

构建ctl构建
     --前端网关.v0
     --opt 源=docker/dockerfile
     --本地上下文=。
     --本地 dockerfile=.
构建ctl构建
     --前端网关.v0
     --opt 源=docker/dockerfile
     --opt context=https://github.com/moby/moby.git
     --opt build-arg:APT_MIRROR=cdn-fastly.deb.debian.org

输出

默认情况下，构建结果和中间缓存将仅保留在 BuildKit 内部。需要指定输出来检索结果。

图像/注册表

buildctl build ... --output type=image,name=docker.io/username/image,push=true

要将映像导出到多个注册表：

 buildctl build ... --output type=image,"name=docker.io/username/image,docker.io/username2/image2",push=true

要将嵌入的缓存与图像一起导出并将它们一起推送到注册表，需要输入registry来导入缓存，您应该指定--export-cache type=inline和--import-cache type=registry,ref=... 。要将缓存直接导出到本地，您应该指定--export-cache type=local 。导出缓存中的详细信息。

 buildctl 构建...
  --输出类型=图像，名称=docker.io/用户名/图像，push=true
   --导出缓存类型=内联
   --import-cache type=registry,ref=docker.io/用户名/image

图像输出支持的按键：

name= ：指定图像名称
push=true : 创建镜像后推送
push-by-digest=true : 推送未命名的图像
registry.insecure=true ：推送到不安全的 HTTP 注册表
oci-mediatypes=true ：在配置 JSON 中使用 OCI 媒体类型而不是 Docker 的媒体类型
unpack=true ：创建后解压镜像（与containerd一起使用）
dangling-name-prefix= ：使用prefix@命名图像，用于匿名图像
name-canonical=true : 添加额外的规范名称name@
compression= ：为新创建和缓存的图层选择压缩类型，gzip 为默认值。 eargz 应与oci-mediatypes=true一起使用。
compression-level= ：gzip、estargz (0-9) 和 zstd (0-22) 的压缩级别
rewrite-timestamp=true ：将文件时间戳重写为SOURCE_DATE_EPOCH值。请参阅docs/build-repro.md了解如何指定SOURCE_DATE_EPOCH值。
force-compression=true ：将compression选项强制应用到所有层（包括已经存在的层）
store=true ：将结果图像存储到工作人员（例如，containerd）图像存储中，并确保图像在内容存储中具有所有 blob（默认true ）。如果工作人员没有图像存储（例如 OCI 工作人员），则忽略。
annotation.= ：将带有相应key和value注释附加到构建的图像上

使用扩展语法， annotation-.= 、 annotation[].=以及两者与annotation-[].=组合annotation-[].= ，允许准确配置附加注释的位置。
指定要附加到的对象，可以是manifest （默认）、 manifest-descriptor 、 index和index-descriptor中的任何一个
指定要附加到哪些对象（默认情况下为所有对象），并且与传递到platform选项的密钥相同，请参阅docs/multi-platform.md 。
有关更多详细信息，请参阅docs/annotations.md 。

如果需要凭据， buildctl将尝试读取 Docker 配置文件$DOCKER_CONFIG/config.json 。 $DOCKER_CONFIG默认为~/.docker 。

本地目录

本地客户端会将文件直接复制到客户端。如果 BuildKit 用于构建容器镜像之外的其他内容，这非常有用。

 buildctl build ... --output type=local,dest=path/to/output-dir

要导出特定文件，请使用带有临时阶段的多阶段构建，并使用COPY --from将所需文件复制到该阶段。

 ...从头开始作为 testresultCOPY --from=builder /usr/src/app/testresult.xml 。
...

 buildctl build ... --opt target=testresult --output type=local,dest=path/to/output-dir

通过多平台构建，将在目标目录中创建与每个目标平台匹配的子文件夹：

 FROM busybox AS buildARG TARGETOSARG TARGETARCHRUN mkdir /out && echo foo > /out/hello-$TARGETOS-$TARGETARCHFROM scrapCOPY --from=build /out /

 $ buildctl 构建
   --前端dockerfile.v0
   --opt 平台=linux/amd64,linux/arm64
   --输出类型=本地，目标=./bin/release

$ 树 ./bin
。/垃圾桶/
└── 释放
    ├── linux_amd64
    │ └── 你好-linux-amd64
    └── linux_arm64
        └── 你好-linux-arm64

您可以设置platform-split=false将所有平台的文件合并到同一目录中：

 $ buildctl 构建
   --前端dockerfile.v0
   --opt 平台=linux/amd64,linux/arm64
   --output type=local,dest=./bin/release,platform-split=false

$ 树 ./bin
。/垃圾桶/
└── 释放
    ├── 你好-linux-amd64
    └── 你好-linux-arm64

Tar 导出器与本地导出器类似，但通过 tarball 传输文件。

 buildctl build ... --output type=tar,dest=out.tar
buildctl build ... --output type=tar > out.tar

Docker 压缩包

# 导出的 tarball 也与 OCI specbuildctl build 兼容 ... --output type=docker,name=myimage |码头工人负载

OCI 压缩包

buildctl build ... --output type=oci,dest=path/to/output.tar
buildctl build ... --output type=oci > output.tar

容器镜像存储

需要使用containerdworker

 buildctl build ... --output type=image,name=docker.io/username/image
ctr --namespace=buildkit 图像 ls

要更改containerd命名空间，您需要更改/etc/buildkit/buildkitd.toml中的worker.containerd.namespace 。

缓存

显示本地构建缓存（ /var/lib/buildkit ）：

 buildctl du -v

修剪本地构建缓存：

构建修剪

垃圾收集

请参阅./docs/buildkitd.toml.md 。

导出缓存

BuildKit 支持以下缓存导出器：

inline ：将缓存嵌入到镜像中，并一起推送到注册表
registry : 分别推送镜像和缓存
local ：导出到本地目录
gha ：导出到 GitHub Actions 缓存

在大多数情况下，您希望使用inline缓存导出器。但请注意， inline缓存导出器仅支持min缓存模式。要启用max缓存模式，请使用registry缓存导出器分别推送映像和缓存。

inline和registry导出器都将缓存存储在注册表中。对于导入缓存， type=registry就足够了，因为不需要指定缓存格式。

内联（将图像和缓存推送到一起）

 buildctl 构建...
   --输出类型=图像，名称=docker.io/用户名/图像，push=true
   --导出缓存类型=内联
   --import-cache type=registry,ref=docker.io/用户名/image

请注意，除非提供--import-cache type=registry,ref=...否则不会导入内联缓存。

内联缓存将缓存元数据嵌入到图像配置中。与没有缓存信息的图像相比，图像中的图层将保持不变。

Docker 集成的 BuildKit ( DOCKER_BUILDKIT=1 docker build ) 和docker buildx需要指定--build-arg BUILDKIT_INLINE_CACHE=1以启用inline缓存导出器。但是，独立的buildctl不需要--opt build-arg:BUILDKIT_INLINE_CACHE=1并且 build-arg 会被忽略。

注册表（分别推送镜像和缓存）

 buildctl 构建...
   --输出类型=图像，名称=本地主机：5000 / myrepo：图像，推送= true
   --export-cache type=registry,ref=localhost:5000/myrepo:buildcache
   --import-cache type=registry,ref=localhost:5000/myrepo:buildcache

--export-cache选项：

type=registry
mode= ：指定要导出的缓存层（默认值： min ）

min ：仅导出结果图像的图层
max ：导出所有中间步骤的所有层

ref= ：指定存储缓存的存储库引用，例如docker.io/user/image:tag
image-manifest= ：是否将缓存清单导出为 OCI 兼容的图像清单而不是清单列表/索引（默认值： false ，必须与oci-mediatypes=true一起使用）
oci-mediatypes= ：是否在导出的清单中使用 OCI 媒体类型（默认值： true ，自 BuildKit v0.8起）
compression= ：为新创建和缓存的图层选择压缩类型，gzip 为默认值。 eargz 和 zstd 应与oci-mediatypes=true一起使用
compression-level= ：选择 gzip、estargz (0-9) 和 zstd (0-22) 的压缩级别
force-compression=true ：强制将compression选项应用于所有层
ignore-error= ：指定在缓存导出失败时是否忽略错误（默认值： false ）

--import-cache选项：

type=registry
ref= ：指定从中检索缓存的存储库引用，例如docker.io/user/image:tag

本地目录

buildctl build ... --export-cache type=local,dest=path/to/output-dir
buildctl build ... --import-cache type=local,src=path/to/input-dir

目录布局符合 OCI Image Spec v1.0。

--export-cache选项：

type=local
mode= ：指定要导出的缓存层（默认值： min ）

min ：仅导出结果图像的图层
max ：导出所有中间步骤的所有层

dest= ：缓存导出器的目标目录
tag= ：指定要写入本地索引的图像的自定义标签（默认： latest ）
image-manifest= ：是否将缓存清单导出为 OCI 兼容的图像清单而不是清单列表/索引（默认值： false ，必须与oci-mediatypes=true一起使用）
oci-mediatypes= ：是否在导出的清单中使用 OCI 媒体类型（默认true ，自 BuildKit v0.8起）
compression= ：为新创建和缓存的图层选择压缩类型，gzip 为默认值。 eargz 和 zstd 应与oci-mediatypes=true一起使用。
compression-level= ：gzip、estargz (0-9) 和 zstd (0-22) 的压缩级别
force-compression=true ：强制将compression选项应用于所有层
ignore-error= ：指定在缓存导出失败时是否忽略错误（默认值： false ）

--import-cache选项：

type=local
src= ：缓存导入器的源目录
tag= ：指定要从本地索引读取的图像的自定义标签（默认： latest ）
digest=sha256: ：指定要导入的清单列表的显式摘要

GitHub Actions 缓存（实验）

 buildctl 构建...
   --输出类型=图像，名称=docker.io/用户名/图像，push=true
   --导出缓存类型=gha
   --导入缓存类型=gha

GitHub Actions 缓存将缓存元数据和图层保存到 GitHub 的缓存服务。该缓存目前的大小限制为 10GB，可在存储库中的不同缓存之间共享。如果超过此限制，GitHub 将保存您的缓存，但会开始逐出缓存，直到总大小小于 10 GB。过于频繁地回收缓存可能会导致整体运行时间变慢。

与使用 actions/cache 类似，缓存按分支划分范围，每个分支都可以使用默认分支和目标分支。

针对 GitHub Actions Cache 服务 API 进行身份验证需要以下属性：

url : 缓存服务器 URL (默认$ACTIONS_CACHE_URL )
token ：访问令牌（默认$ACTIONS_RUNTIME_TOKEN ）

这种类型的缓存可以与 Docker Build Push Action 一起使用，其中url和token将自动设置。要在内联run步骤中使用此后端，您必须在工作流程中包含 mad-max/ghaction-github-runtime 以公开运行时。

--export-cache选项：

type=gha
mode= ：指定要导出的缓存层（默认值： min ）

min ：仅导出结果图像的图层
max ：导出所有中间步骤的所有层

scope= ：缓存对象属于哪个范围（默认buildkit ）
ignore-error= ：指定在缓存导出失败时是否忽略错误（默认值： false ）
timeout= ：设置缓存导出的超时时长（默认： 10m ）

--import-cache选项：

type=gha
scope= ：缓存对象属于哪个范围（默认buildkit ）
timeout= ：设置缓存导入的超时时长（默认： 10m ）

S3 缓存（实验性）

 buildctl 构建...
   --输出类型=图像，名称=docker.io/用户名/图像，push=true
   --export-cache type=s3，region=eu-west-1，bucket=my_bucket，name=my_image
   --导入缓存类型=s3，区域=eu-west-1，存储桶=my_bucket，名称=my_image

需要以下属性：

bucket ：AWS S3 存储桶（默认值： $AWS_BUCKET ）
region : AWS 区域（默认值： $AWS_REGION ）

储存地点：

blob： s3://// ，默认值： s3:///blobs/
清单： s3://// ，默认值： s3:///manifests/

S3配置：

blobs_prefix ：在 s3 上存储/读取 blob 的全局前缀（默认值： blobs/ ）
manifests_prefix ：在 s3 上存储/读取清单的全局前缀（默认： manifests/ ）
endpoint_url ：指定特定的 S3 端点（默认值：空）
use_path_style ：如果设置为true ，则将存储桶名称放在 URL 中而不是主机名中（默认值： false ）

AWS 身份验证：

最简单的方法是使用 IAM 实例配置文件。其他选项有：

使用 AWS Go SDK 支持的环境变量/配置文件的任何系统。该配置必须可用于 buildkit 守护进程，而不是客户端。
使用以下属性：

access_key_id ：访问密钥 ID
secret_access_key ：秘密访问密钥
session_token ：会话令牌

--export-cache选项：

type=s3
mode= ：指定要导出的缓存层（默认值： min ）

min ：仅导出结果图像的图层
max ：导出所有中间步骤的所有层

prefix= ：设置全局前缀以在 s3 上存储/读取文件（默认值：空）
name= ：指定要使用的清单的名称（默认buildkit ）

可以同时指定多个清单名称，用 ; 分隔; 。标准用例是使用 git sha1 作为名称，使用分支名称作为重复名称，并使用 2 个import-cache命令加载两者。

ignore-error= ：指定在缓存导出失败时是否忽略错误（默认值： false ）
touch_refresh=24h ：每次touch_refresh都会在 s3 上“触摸”blob 文件，而不是在未更改时再次上传，默认值为 24h。因此，可以在S3存储桶上设置过期策略，自动清理无用文件。清单文件被系统地重写，无需修改它们。
upload_parallelism=4 ：此参数更改并行上传到 s3 的层数。每个单独的层都使用 AWS 开发工具包提供的上传管理器通过 5 个线程进行上传。

--import-cache选项：

type=s3
prefix= ：设置全局前缀以在 s3 上存储/读取文件（默认值：空）
blobs_prefix= ：设置全局前缀以在 s3 上存储/读取 blob（默认值： blobs/ ）
manifests_prefix= ：设置全局前缀以在 s3 上存储/读取清单（默认值： manifests/ ）
name= ：要使用的清单的名称（默认buildkit ）

Azure Blob 存储缓存（实验性）

 buildctl 构建...
   --输出类型=图像，名称=docker.io/用户名/图像，push=true
   --export-cache type=azblob,account_url=https://myaccount.blob.core.windows.net,name=my_image
   --import-cache type=azblob,account_url=https://myaccount.blob.core.windows.net,name=my_image

需要以下属性：

account_url ：Azure Blob 存储帐户 URL（默认值： $BUILDKIT_AZURE_STORAGE_ACCOUNT_URL ）

储存地点：

blob： /// ，默认值： //blobs/
清单： /// ，默认值： //manifests/

Azure Blob 存储配置：

container ：Azure Blob 存储容器名称（默认值： buildkit-cache或$BUILDKIT_AZURE_STORAGE_CONTAINER如果设置）
blobs_prefix ：在 Azure Blob 存储容器 ( ) 上存储/读取 blob 的全局前缀（默认值： blobs/ ）
manifests_prefix ：在 Azure Blob 存储容器 ( ) 上存储/读取 Blob 的全局前缀（默认值： manifests/ ）

Azure Blob 存储身份验证：

Azure Blob 存储身份验证支持 2 个选项：

使用 Azure SDK for Go 支持的环境变量的任何系统。该配置必须可用于 buildkit 守护进程，而不是客户端。
秘密访问密钥，使用secret_access_key属性指定 Azure Blob 存储帐户的主要或辅助帐户密钥。 Azure Blob 存储帐户密钥

笔记

如果帐户名称不是帐户 URL 主机的一部分，也可以使用account_name属性（或$BUILDKIT_AZURE_STORAGE_ACCOUNT_NAME ）指定帐户名称。

--export-cache选项：

type=azblob
mode= ：指定要导出的缓存层（默认值： min ）

min ：仅导出结果图像的图层
max ：导出所有中间步骤的所有层

prefix= ：设置全局前缀以在 Azure Blob 存储容器 ( ) 上存储/读取文件（默认值：空）
name= ：指定要使用的清单的名称（默认值： buildkit ）

可以同时指定多个清单名称，用 ; 分隔; 。标准用例是使用 git sha1 作为名称，使用分支名称作为重复名称，并使用 2 个import-cache命令加载两者。

ignore-error= ：指定在缓存导出失败时是否忽略错误（默认值： false ）

--import-cache选项：

type=azblob
prefix= ：设置全局前缀以在 Azure Blob 存储容器 ( ) 上存储/读取文件（默认值：空）
blobs_prefix= ：设置全局前缀以在 Azure Blob 存储容器 ( ) 上存储/读取 blob（默认值： blobs/ ）
manifests_prefix= ：设置全局前缀以在 Azure Blob 存储容器 ( ) 上存储/读取清单（默认值： manifests/ ）
name= ：要使用的清单的名称（默认值： buildkit ）

一致的散列

如果您有多个 BuildKit 守护程序实例，但不想使用注册表在集群中共享缓存，请考虑使用一致哈希进行客户端负载平衡。

请参阅./examples/kubernetes/consistenthash 。

元数据

要输出构建元数据（例如图像摘要），请传递--metadata-file标志。元数据将作为 JSON 对象写入指定文件。指定文件的目录必须已存在且可写。

 buildctl build ... --元数据文件metadata.json

 jq '.'元数据.json

 {“containerimage.config.digest”：“sha256：2937f66a9722f7f4a2df583de2f8cb97fc9196059a410e7f00072fc918930e66”，“containerimage.descriptor”：{“注释”：{“config.digest”：“sha256：2937f66 a9722f7f4a2df583de2f8cb97fc9196059a410e7f00072fc918930e66", "org.opencontainers.image.created": " 2022-02-08T21:28:03Z"}，"摘要"："sha256：19ffeab6f8bc9293ac2c3fdf94ebe28396254c993aea0b5a542cfb02e0883fa3"，"mediaType"："application/vnd.oci.image.manifest.v1+json"，"大小"： 506
  }, "containerimage.digest": "sha256:19ffeab6f8bc9293ac2c3fdf94ebe28396254c993aea0b5a542cfb02e0883fa3"}

Systemd 套接字激活

在基于 Systemd 的系统上，您可以通过 Systemd 套接字激活与守护进程通信，使用buildkitd --addr fd:// 。您可以在./examples/systemd中找到通过 BuildKit 和 Systemd 使用 Systemd 套接字激活的示例。

将 BuildKit 公开为 TCP 服务

buildkitd守护进程可以侦听 TCP 套接字上的 gRPC API。

强烈建议为守护程序和客户端 (mTLS) 创建 TLS 证书。在没有 mTLS 的情况下启用 TCP 是危险的，因为执行器容器（也称为 Dockerfile RUN容器）也可以调用 BuildKit API。

构建套件
   --地址 tcp://0.0.0.0:1234
   --tlscacert /path/to/ca.pem
   --tlscert /path/to/cert.pem
   --tlskey /path/to/key.pem

构建控制
   --addr tcp://example.com:1234
   --tlscacert /path/to/ca.pem
   --tlscert /path/to/clientcert.pem
   --tlskey /path/to/clientkey.pem
   建造 ...

负载均衡

可以针对随机负载平衡的buildkitd守护进程调用buildctl build 。

另请参阅客户端负载平衡的一致性哈希。

容器化 BuildKit

还可以通过在 Docker 容器内运行buildkitd守护进程并远程访问它来使用 BuildKit。

我们提供容器镜像作为moby/buildkit ：

moby/buildkit:latest ：从最新的常规版本构建
moby/buildkit:rootless ：与latest相同，但以非特权用户身份运行，请参阅docs/rootless.md
moby/buildkit:master ：从 master 分支构建
moby/buildkit:master-rootless ：与 master 相同，但以非特权用户身份运行，请参阅docs/rootless.md

要在容器中运行守护进程：

 docker run -d --name buildkitd --privileged moby/buildkit:latestexport BUILDKIT_HOST=docker-container://buildkitd
buildctl构建--帮助

波德曼

要连接到 Podman 容器中运行的 BuildKit 守护程序，请使用podman-container://而不是docker-container:// 。

 podman run -d --name buildkitd --privileged moby/buildkit:latest
buildctl --addr=podman-container://buildkitd build --frontend dockerfile.v0 --local context=. --本地 dockerfile=. --输出类型=oci | podman 加载 foo

不需要sudo 。

内德特尔

要连接到在 Nerdctl 容器中运行的 BuildKit 守护进程，请使用nerdctl-container://而不是docker-container:// 。

 nerdctl run -d --name buildkitd --privileged moby/buildkit:latest
buildctl --addr=nerdctl-container://buildkitd build --frontend dockerfile.v0 --local context=. --本地 dockerfile=. --输出类型=oci |书呆子负载

不需要sudo 。

库伯内斯

对于 Kubernetes 部署，请参阅examples/kubernetes 。

无守护进程

要在单个容器中运行客户端和临时守护进程（“无守护进程模式”）：

码头运行
     -它
     --rm
      - 特权
     -v /路径/到/目录:/tmp/工作
     --entrypoint buildctl-daemonless.sh
     莫比/buildkit：大师
         建造
         --前端dockerfile.v0
         --本地上下文=/tmp/工作
         --本地 dockerfile=/tmp/work

或者

码头运行
     -它
     --rm
     --security-opt seccomp=无限制
     --security-opt apparmor=无限制
     -e BUILDKITD_FLAGS=--oci-worker-no-process-sandbox
     -v /路径/到/目录:/tmp/工作
     --entrypoint buildctl-daemonless.sh
     moby/buildkit:master-rootless
         建造
          - 前端
         dockerfile.v0
         --本地上下文=/tmp/工作
         --本地 dockerfile=/tmp/work

开放遥测支持

BuildKit 支持 buildkitd gRPC API 和 buildctl 命令的 OpenTelemetry。要捕获 Jaeger 的跟踪，请将JAEGER_TRACE环境变量设置为收集地址。

 docker run -d -p6831:6831/udp -p16686:16686 jaegertracing/all-in-one:latestexport JAEGER_TRACE=0.0.0.0:6831# 重新启动 buildkitd 和 buildctl，以便它们知道 JAEGER_TRACE# 任何 buildctl 命令都应跟踪到 http:// /127.0.0.1:16686/

在 Windows 上，如果您在容器jaeger-all-in-one.exe之外运行 Jaeger，请设置环境变量setx -m JAEGER_TRACE "0.0.0.0:6831" ，在新终端中重新启动buildkitd ，跟踪信息将显示为自动收集。

在没有 root 权限的情况下运行 BuildKit

请参阅docs/rootless.md 。

构建多平台镜像

请参阅docs/multi-platform.md 。

配置`buildctl`

颜色输出控制

buildctl支持修改用于向终端输出信息的颜色。您可以将环境变量BUILDKIT_COLORS设置为run=green:warning=yellow:error=red:cancel=255,165,0之类的值来设置您想要使用的颜色。按照 no-color.org 的建议，将NO_COLOR设置为任何值都会禁用任何彩色输出。

解析错误将被报告但被忽略。这将导致在需要时使用默认颜色值。

预定义颜色列表。

日志行数（对于 tty 模式下的活动步骤）

您可以通过将BUILDKIT_TTY_LOG_LINES设置为数字（默认值：6）来更改 tty 模式下活动步骤可见的日志行数。

贡献

想为 BuildKit 做出贡献吗？惊人的！您可以在 CONTRIBUTING.md 中找到有关对该项目做出贡献的信息

展开

附加信息

版本 0.17.0
类型其他源码
更新时间 2024-11-05
大小
语言简体中文

构建套件

构建套件

使用者

快速启动

Linux设置

Windows 设置

macOS 设置

从源代码构建

探索法学学士

探索 Dockerfile

使用buildctl构建 Dockerfile

使用外部前端构建 Dockerfile

输出

图像/注册表

本地目录

Docker 压缩包

OCI 压缩包

容器镜像存储

缓存

垃圾收集

导出缓存

内联（将图像和缓存推送到一起）

注册表（分别推送镜像和缓存）

本地目录

GitHub Actions 缓存（实验）

S3 缓存（实验性）

Azure Blob 存储缓存（实验性）

一致的散列

元数据

Systemd 套接字激活

将 BuildKit 公开为 TCP 服务

负载均衡

容器化 BuildKit

波德曼

内德特尔

库伯内斯

无守护进程

开放遥测支持

在没有 root 权限的情况下运行 BuildKit

构建多平台镜像

配置buildctl

颜色输出控制

日志行数（对于 tty 模式下的活动步骤）

贡献

使用`buildctl`构建 Dockerfile

配置`buildctl`