BuildKit：Docker 默认构建引擎，到底在干些什么

BuildKit 在 GitHub 上已经有 9,965 Star。很多人每天在用 Docker 构建镜像，但不知道引擎底下跑的就是 BuildKit。

从 Docker Engine 23.0 开始，docker build 默认使用 Buildx + BuildKit 这套组合。这件事本身不重要，重要的是 BuildKit 给构建流程带来了什么变化。

1、 它到底解决了什么问题

传统 Dockerfile 构建是一个线性的过程：把每一行 RUN 指令按顺序跑一遍，产生中间层，最后打包成镜像。这种方式能干活，但问题不少：缓存粒度过粗、没有并发依赖解析、多阶段构建的中间产物没法复用、跨平台构建要绕不少弯路。

BuildKit 把构建抽象成了一套依赖图。每条指令之间用有向边连接，互不依赖的步骤可以同时执行。缓存也不再是一层一层整体替换，而是基于指令内容的匹配：你改了一句注释，不需要重新下载所有依赖包。

2、 核心设计：LLB

BuildKit 的内部引擎是 LLB（Low-Level Build），一套二进制的构建中间表示。LLB 之于 Dockerfile，相当于 LLVM IR 之于 C 语言。

LLB 用 Protobuf 序列化，可以并发执行、可以按指令粒度做缓存、不绑定任何前端语言。这意味着不只是 Dockerfile，任何能输出 LLB 的构建描述语言都可以直接跑在 BuildKit 上。

目前已经有 20 多种前端语言实现了 LLB 支持，包括 Earthly、Nix、Bass、envd、Cargo Wharf 等。对有自己构建工具链的团队来说，不需要单独搞一套执行引擎。

3、 缓存能力

BuildKit 的缓存是它跟传统 docker build 拉开差距的地方。

• 内联缓存：把缓存元数据嵌进镜像配置，推送到 registry 时同步带上
• 分体缓存：镜像和缓存分开推送，可以只拉缓存而不拉完整镜像
• 本地缓存：导出到本地目录，离线环境也能复用
• GitHub Actions 缓存：对接 GHA 的缓存服务，CI 环境零配置
• S3 / Azure Blob 缓存：团队规模上去之后，用对象存储做集中式缓存管理

支持 min 和 max 两种模式：min 只缓存最终镜像的层，max 缓存所有中间步骤的层。max 模式在频繁迭代时能把构建时间从几分钟压到几十秒。

4、 输出格式与多平台

BuildKit 的输出不只有容器镜像。支持 image/registry、本地目录、Docker tarball、OCI tarball 和 containerd image store。本地目录输出意味着可以用 BuildKit 构建非容器产物，比如把编译结果直接写到宿主机目录里。

多平台构建天然支持。一条命令同时出 linux/amd64 和 linux/arm64 镜像，输出目录按平台分文件夹，也可以选择合并到一个目录。

5、 分布式架构

BuildKit 由 buildkitd 守护进程和 buildctl 客户端组成。多个 buildkitd 实例可以组成 worker 集群，通过一致性哈希做客户端负载均衡。支持 gRPC over TCP，启用 mTLS 后可以跨机器调用。

也支持无特权模式运行，不需要 root。跑在 Kubernetes 集群里、Podman 容器里、Nerdctl 容器里，以及 daemonless 模式都行。

6、 适合谁

• 团队构建时间长、CI 管道卡在镜像打包这步的 DevOps
• 已经在用 Earthly、Nix 这类替代 Dockerfile 的构建工具的团队
• 有多平台镜像构建需求的项目
• 需要构建缓存集中管理的中大型团队

BuildKit 做的事不花哨，不生成好看的报告，不给可视化看板。它就是一个把源码变成构建产物的执行引擎。这件事它做得足够专注。

5189)]](https://asciinema.org/a/gPEIEo1NzmDTUu2bEPsUboqmU)