Buildah是一种开源的容器镜像构建工具，它最大的特点是不需要运行一个常驻后台的守护进程。使用Docker构建镜像时，客户端会把构建请求发送给dockerd，由daemon调度containerd和runc完成实际构建。Buildah则直接调用OCI运行时接口和containers/storage存储驱动，在命令行进程中完成镜像操作。这种设计不仅降低了资源消耗，也让构建过程更透明，尤其适合在CI环境中使用。
另一个需要澄清的概念是Buildah与Podman的关系。两者共享底层库，Buildah主要聚焦于镜像构建，Podman负责容器运行和管理。Buildah生成的镜像可以直接被Podman使用，也可以推送到任意兼容OCI的镜像仓库。接下来详细说明Buildah的安装、命令用法以及实际构建场景。
Buildah与Docker的架构差异
Docker采用客户端-服务器架构，构建镜像的所有操作都要经过dockerd。即使本地只执行docker build，后台也必须运行Docker daemon。Buildah则完全不同，它没有守护进程，每个buildah子命令都是一个独立的可执行文件调用，直接操作本地镜像存储。这意味着在构建过程中不会出现daemon崩溃导致任务中断的情况，也更容易限制构建过程的权限范围。
由于Buildah直接使用OCI标准和containers/storage，它生成的镜像格式与Docker镜像完全兼容。你可以在没有Docker的环境中用Buildah拉取基础镜像、安装软件、提交新镜像，然后推送到Harbor、Quay等镜像仓库。对于习惯了Dockerfile的开发者，构建命令buildah bud几乎与docker build行为一致，不用担心迁移成本。
权限模型也是Buildah的一大优势。通过user namespace和rootless模式，普通用户无需sudo即可构建镜像。底层运行的容器进程被映射到非特权用户命名空间，即使构建过程中出现安全漏洞，攻击者也无法直接获得宿主机root权限。这在多租户的CI平台中尤为关键。
安装Buildah与基础构建命令
在主流Linux发行版上安装Buildah非常简单。Ubuntu或Debian用户可以通过apt安装，Fedora、RHEL和CentOS用户则使用dnf或yum。安装完成后，执行buildah info可以查看存储驱动、OCI运行时版本等信息。下面演示几个常见发行版的安装命令。
# Ubuntu/Debian sudo apt update sudo apt install -y buildah # Fedora sudo dnf install -y buildah # RHEL/CentOS 8+ sudo dnf install -y buildah
Buildah的脚本式构建非常直观。以构建一个带有Nginx的镜像为例，先使用from指定基础镜像，这会创建一个工作容器；接着用run在容器中执行命令；修改完成后用commit提交为新镜像。整个过程不需要写Dockerfile，适合动态生成配置的场景。
# 创建一个基于Alpine的工作容器 ctr=$(buildah from alpine:latest) # 在容器内安装nginx buildah run $ctr apk add --no-cache nginx # 设置启动命令 buildah config --cmd "nginx -g 'daemon off;'" $ctr # 提交为新镜像 buildah commit $ctr my-nginx:latest # 清理工作容器 buildah rm $ctr
如果团队已经有现成的Dockerfile，无需改写任何内容。将Dockerfile放在当前目录下，执行buildah bud -t my-image:latest .即可完成构建。构建完成后使用buildah images查看本地镜像列表，buildah rmi删除不需要的镜像。这些命令与Docker CLI高度相似，降低了学习成本。
# 从Dockerfile构建镜像 buildah bud -t my-app:1.0 . # 列出本地所有镜像 buildah images # 删除指定镜像 buildah rmi my-app:1.0
使用Buildah进行多阶段构建和镜像推送
多阶段构建在编译型语言项目中非常实用。开发者可以在第一阶段使用包含编译工具的大型基础镜像，生成二进制文件或静态资源；第二阶段只复制这些产物到精简的运行时镜像，从而大幅减小最终镜像体积。Buildah完整支持Dockerfile中的多阶段语法，包括AS别名和COPY --from指令。
# 第一阶段：构建应用 FROM golang:1.21 AS builder WORKDIR /app COPY go.mod go.sum ./ RUN go mod download COPY . . RUN CGO_ENABLED=0 go build -o server . # 第二阶段：运行时镜像 FROM alpine:3.19 RUN apk add --no-cache ca-certificates WORKDIR /root/ COPY --from=builder /app/server . EXPOSE 8080 CMD ["./server"]
上述Dockerfile展示了一个典型的Go应用构建流程。使用Buildah执行buildah bud -t my-go-app:latest .时，它会自动解析多阶段指令，先构建builder阶段，再将编译好的server二进制文件复制到Alpine运行时阶段。最终镜像只包含一个静态可执行文件和必要的证书，体积可能只有几十兆。由于Buildah遵循OCI规范，这个镜像同样可以被Docker或其他容器引擎运行。
镜像构建完成后，推送至镜像仓库的步骤也很简单。首先通过buildah login命令登录目标仓库，然后使用buildah push将本地镜像推送到远程。如果仓库使用的是自签名证书，需要提前在/etc/containers/registries.conf中配置信任信息。推送时指定镜像的完整路径，例如quay.io/myuser/my-go-app:latest。
# 登录Quay.io镜像仓库 buildah login quay.io # 为本地镜像打上远程仓库标签 buildah tag my-go-app:latest quay.io/myuser/my-go-app:latest # 推送镜像 buildah push quay.io/myuser/my-go-app:latest
Buildah与Podman的配合也非常顺畅。因为二者共享同一个本地镜像存储，使用buildah构建的镜像无需额外导出或导入，直接通过podman run即可运行。你甚至可以在Podman的容器内调用Buildah来构建镜像，但需要注意挂载必要的存储卷。这种灵活性让Buildah成为Kubernetes生态中Tekton、OpenShift等平台默认的镜像构建引擎之一。