docker buildx build

描述开始构建
用法docker buildx build [OPTIONS] PATH | URL | -
别名
docker build docker builder build docker image build docker buildx b

描述

docker buildx build 命令使用 BuildKit 开始构建。

选项

选项默认值描述
--add-host添加自定义主机到 IP 映射(格式:host:ip
--allow允许额外的特权授权(例如,network.hostsecurity.insecure
--annotation为镜像添加注解
--attest证明参数(格式:type=sbom,generator=image
--build-arg设置构建时变量
--build-context附加构建上下文(例如,name=path)
--cache-from外部缓存源(例如,user/app:cachetype=local,src=path/to/dir
--cache-to缓存导出目标(例如,user/app:cachetype=local,dest=path/to/dir
--callbuild设置评估构建的方法(check, outline, targets
--cgroup-parent设置构建期间 RUN 指令的父 cgroup
--check--call=check 的简写
--detach实验性 (CLI) 分离 buildx 服务器(仅在 linux 上支持)
-f, --fileDockerfile 的名称(默认值:PATH/Dockerfile
--iidfile将镜像 ID 写入文件
--label设置镜像的元数据
--load--output=type=docker 的简写
--metadata-file将构建结果元数据写入文件
--network设置构建期间 RUN 指令的网络模式
--no-cache构建镜像时不使用缓存
--no-cache-filter不缓存指定阶段
-o, --output输出目标(格式:type=local,dest=path
--platform设置构建的目标平台
--progressauto设置进度输出类型(auto, quiet, plain, tty, rawjson)。使用 plain 显示容器输出
--provenance--attest=type=provenance 的简写
--pull始终尝试拉取所有引用的镜像
--push--output=type=registry 的简写
-q, --quiet抑制构建输出并在成功时打印镜像 ID
--root实验性 (CLI) 指定要连接的服务器根目录
--sbom--attest=type=sbom 的简写
--secret暴露给构建的 Secret(格式:id=mysecret[,src=/local/secret]
--server-config实验性 (CLI) 指定 buildx 服务器配置文件(仅在启动新服务器时使用)
--shm-size构建容器的共享内存大小
--ssh暴露给构建的 SSH 代理 socket 或密钥(格式:default|<id>[=<socket>|<key>[,<key>]]
-t, --tag名称和可选的标签(格式:name:tag
--target设置要构建的目标构建阶段
--ulimitUlimit 选项

示例

向容器的 hosts 文件添加条目 (--add-host)

您可以使用一个或多个 --add-host 标志将其他主机添加到构建容器的 /etc/hosts 文件中。此示例为名为 my-hostnamemy_hostname_v6 的主机添加了静态地址

$ docker buildx build --add-host my_hostname=8.8.8.8 --add-host my_hostname_v6=2001:4860:4860::8888 .

如果您的构建需要连接到主机上运行的服务,您可以使用 --add-host 的特殊值 host-gateway。在以下示例中,构建容器将 host.docker.internal 解析为主机的网关 IP。

$ docker buildx build --add-host host.docker.internal=host-gateway .

您可以将 IPv6 地址用方括号括起来。=: 都是有效的分隔符。以下示例中的两种格式都有效

$ docker buildx build --add-host my-hostname:10.180.0.1 --add-host my-hostname_v6=[2001:4860:4860::8888] .

创建注解 (--annotation)

--annotation="key=value"
--annotation="[type:]key=value"

向镜像索引、清单或描述符添加 OCI 注解。以下示例向镜像清单添加了 foo=bar 注解

$ docker buildx build -t TAG --annotation "foo=bar" --push .

您可以选择添加类型前缀来指定注解的级别。默认情况下,会对镜像清单进行注解。以下示例向镜像索引而不是清单添加了 foo=bar 注解

$ docker buildx build -t TAG --annotation "index:foo=bar" --push .

您可以指定多个类型,用逗号 (,) 分隔,以便将注解添加到多个镜像组件。以下示例向镜像索引、描述符、清单添加了 foo=bar 注解

$ docker buildx build -t TAG --annotation "index,manifest,manifest-descriptor:foo=bar" --push .

您还可以在类型前缀的方括号 ([os/arch]) 中指定平台限定符,以便将注解应用于匹配平台的清单子集。以下示例仅向平台为 linux/amd64 的清单添加了 foo=bar 注解

$ docker buildx build -t TAG --annotation "manifest[linux/amd64]:foo=bar" --push .

平台限定符中不支持通配符;您不能指定诸如 manifest[linux/*] 的类型前缀来仅向操作系统平台为 linux 的清单添加注解。

有关注解的更多信息,请参阅注解

创建证明 (--attest)

--attest=type=sbom,...
--attest=type=provenance,...

创建镜像证明。BuildKit 当前支持

  • sbom - 软件物料清单。

    使用 --attest=type=sbom 在构建时为镜像生成 SBOM。或者,您可以使用--sbom 简写

    有关更多信息,请参阅此处

  • provenance - SLSA 来源证明

    使用 --attest=type=provenance 在构建时为镜像生成来源证明。或者,您可以使用--provenance 简写

    默认情况下,将为构建结果创建一个最小的来源证明,该证明仅附加到推送至仓库的镜像。

    有关更多信息,请参阅此处

允许额外的特权授权 (--allow)

--allow=ENTITLEMENT

允许额外的特权授权。授权列表:

  • network.host - 允许使用主机网络执行。
  • security.insecure - 允许在没有沙箱的情况下执行。请参阅相关的 Dockerfile 扩展

为了启用这些授权,BuildKit daemon 也需要使用 --allow-insecure-entitlement 来允许它们(参阅create --buildkitd-flags)。

$ docker buildx create --use --name insecure-builder --buildkitd-flags '--allow-insecure-entitlement security.insecure'
$ docker buildx build --allow security.insecure .

设置构建时变量 (--build-arg)

您可以使用 Dockerfile 中的 ENV 指令来定义变量值。这些值会保留在构建的镜像中。但通常您不希望它们持久存在。用户可能希望根据构建镜像的主机不同而指定不同的变量。

一个很好的例子是 http_proxy 或用于拉取中间文件的源版本。ARG 指令允许 Dockerfile 作者定义用户可以在构建时使用 --build-arg 标志设置的值

$ docker buildx build --build-arg HTTP_PROXY=http://10.20.30.2:1234 --build-arg FTP_PROXY=http://40.50.60.5:4567 .

此标志允许您传递构建时变量,这些变量在 Dockerfile 的 RUN 指令中像常规环境变量一样访问。这些值不像 ENV 值那样保留在中间或最终镜像中。您必须为每个构建参数添加 --build-arg

使用此标志不会改变构建过程回显 Dockerfile 中的 ARG 行时您看到的输出。

有关使用 ARGENV 指令的详细信息,请参阅Dockerfile 参考

您也可以在不指定值的情况下使用 --build-arg 标志,在这种情况下,daemon 会将本地环境中的值传播到它正在构建的 Docker 容器中

$ export HTTP_PROXY=http://10.20.30.2:1234
$ docker buildx build --build-arg HTTP_PROXY .

此示例类似于 docker run -e 的工作方式。有关更多信息,请参阅docker run 文档

还有一些有用的内置构建参数,例如:

  • BUILDKIT_CONTEXT_KEEP_GIT_DIR=<bool>: 触发 git 上下文保留 .git 目录
  • BUILDKIT_INLINE_CACHE=<bool>: 是否将内联缓存元数据到镜像配置
  • BUILDKIT_MULTI_PLATFORM=<bool>: 选择确定性输出,无论是否进行多平台输出
$ docker buildx build --build-arg BUILDKIT_MULTI_PLATFORM=1 .

有关内置构建参数的更多信息,请参阅Dockerfile 参考文档

附加构建上下文 (--build-context)

--build-context=name=VALUE

定义具有指定内容的附加构建上下文。在 Dockerfile 中,使用 FROM name--from=name 时可以访问此上下文。如果 Dockerfile 定义了同名阶段,则该阶段会被覆盖。

该值可以是本地源目录、符合本地 OCI 布局规范的目录、容器镜像(带有 docker-image:// 前缀)、Git 或 HTTP URL。

用固定的镜像替换 alpine:latest

$ docker buildx build --build-context alpine=docker-image://alpine@sha256:0123456789 .

暴露第二个本地源目录

$ docker buildx build --build-context project=path/to/project/source .
# docker buildx build --build-context project=https://github.com/myuser/project.git .
# syntax=docker/dockerfile:1
FROM alpine
COPY --from=project myfile /

使用 OCI 布局目录作为构建上下文

从本地符合 OCI 布局规范的目录中获取镜像,可以通过标签或摘要

$ docker buildx build --build-context foo=oci-layout:///path/to/local/layout:<tag>
$ docker buildx build --build-context foo=oci-layout:///path/to/local/layout@sha256:<digest>
# syntax=docker/dockerfile:1
FROM alpine
RUN apk add git
COPY --from=foo myfile /

FROM foo

OCI 布局目录必须符合OCI 布局规范。您可以使用标签或精确摘要来引用布局中的镜像。

覆盖配置的构建器实例 (--builder)

buildx --builder 相同。

为构建使用外部缓存源 (--cache-from)

--cache-from=[NAME|type=TYPE[,KEY=VALUE]]

为构建使用外部缓存源。支持的类型有 registrylocalghas3

  • registry 可以从仓库上的缓存清单或(特殊)镜像配置导入缓存。
  • local 可以从之前使用 --cache-to 导出的本地文件导入缓存。
  • gha 可以从之前在您的 GitHub 仓库中使用 --cache-to 导出的缓存导入缓存
  • s3 可以从之前在您的 S3 存储桶中使用 --cache-to 导出的缓存导入缓存

如果未指定类型,则使用带有指定引用的 registry 导出器。

docker 驱动程序目前仅支持从仓库导入构建缓存。

$ docker buildx build --cache-from=user/app:cache .
$ docker buildx build --cache-from=user/app .
$ docker buildx build --cache-from=type=registry,ref=user/app .
$ docker buildx build --cache-from=type=local,src=path/to/cache .
$ docker buildx build --cache-from=type=gha .
$ docker buildx build --cache-from=type=s3,region=eu-west-1,bucket=mybucket .

有关缓存导出器和可用属性的更多信息:https://github.com/moby/buildkit#export-cache

调用前端方法 (--call)

--call=[build|check|outline|targets]

BuildKit 前端可以使用前端方法支持替代的构建执行模式。前端方法是一种改变或扩展构建调用行为的方式,它允许您例如检查、验证或从构建生成替代输出。

docker buildx build--call 标志允许您指定要执行的前端方法。如果未指定此标志,则默认为执行构建并评估构建检查

对于 Dockerfile,可用的方法有:

命令描述
build(默认)执行构建并评估当前构建目标的构建检查。
check评估整个 Dockerfile 或选定目标的构建检查,而不执行构建。
outline显示您可以为目标设置的构建参数及其默认值。
targets列出 Dockerfile 中的所有构建目标。
subrequests.describe列出当前前端支持的所有前端方法。

请注意,其他前端可能实现了这些或其它的方法。要查看您正在使用的前端可用的方法列表,请使用 --call=subrequests.describe

$ docker buildx build -q --call=subrequests.describe .

NAME                 VERSION DESCRIPTION
outline              1.0.0   List all parameters current build target supports
targets              1.0.0   List all targets current build supports
subrequests.describe 1.0.0   List available subrequest types

描述

--call=targets--call=outline 方法(如果可用)包含构建目标和参数的描述。描述是从 Dockerfile 中的注释生成的。位于 FROM 指令前一行的注释会成为构建目标的描述,而位于 ARG 指令前的注释会成为构建参数的描述。注释必须以阶段或参数的名称开头,例如

# syntax=docker/dockerfile:1

# GO_VERSION sets the Go version for the build
ARG GO_VERSION=1.22

# base-builder is the base stage for building the project
FROM golang:${GO_VERSION} AS base-builder

当您运行 docker buildx build --call=outline 时,输出将包含描述,如下所示

$ docker buildx build -q --call=outline .

TARGET:      base-builder
DESCRIPTION: is the base stage for building the project

BUILD ARG    VALUE   DESCRIPTION
GO_VERSION   1.22    sets the Go version for the build

有关如何编写 Dockerfile docstrings 的更多示例,请查看 Docker 文档的 Dockerfile

调用:check (--check)

check 方法会在不执行构建的情况下评估构建检查。--check 标志是 --call=check 的便捷简写形式。在开始构建之前使用 check 方法验证构建配置。

$ docker buildx build -q --check https://github.com/docker/docs.git

WARNING: InvalidBaseImagePlatform
Base image wjdp/htmltest:v0.17.0 was pulled with platform "linux/amd64", expected "linux/arm64" for current build
Dockerfile:43
--------------------
  41 |         "#content/desktop/previous-versions/*.md"
  42 |
  43 | >>> FROM wjdp/htmltest:v${HTMLTEST_VERSION} AS test
  44 |     WORKDIR /test
  45 |     COPY --from=build /out ./public
--------------------

不指定目标而使用 --check 会评估整个 Dockerfile。如果您想评估特定目标,请使用 --target 标志。

调用:outline

outline 方法会打印指定目标的名称(如果未指定 --target,则为默认目标),以及该目标使用的构建参数,如果设置了默认值,还会打印其默认值。

以下示例显示了默认目标 release 及其构建参数

$ docker buildx build -q --call=outline https://github.com/docker/docs.git

TARGET:      release
DESCRIPTION: is an empty scratch image with only compiled assets

BUILD ARG          VALUE     DESCRIPTION
GO_VERSION         1.22      sets the Go version for the base stage
HUGO_VERSION       0.127.0
HUGO_ENV                     sets the hugo.Environment (production, development, preview)
DOCS_URL                     sets the base URL for the site
PAGEFIND_VERSION   1.1.0

这意味着可以使用这些构建参数配置 release 目标

$ docker buildx build \
  --build-arg GO_VERSION=1.22 \
  --build-arg HUGO_VERSION=0.127.0 \
  --build-arg HUGO_ENV=production \
  --build-arg DOCS_URL=https://example.com \
  --build-arg PAGEFIND_VERSION=1.1.0 \
  --target release https://github.com/docker/docs.git

调用:targets

targets 方法列出了 Dockerfile 中的所有构建目标。这些是您可以使用 --target 标志构建的阶段。它还指示了默认目标,即当您未指定目标时将构建的目标。

$ docker buildx build -q --call=targets https://github.com/docker/docs.git

TARGET            DESCRIPTION
base              is the base stage with build dependencies
node              installs Node.js dependencies
hugo              downloads and extracts the Hugo binary
build-base        is the base stage for building the site
dev               is for local development with Docker Compose
build             creates production builds with Hugo
lint              lints markdown files
test              validates HTML output and checks for broken links
update-modules    downloads and vendors Hugo modules
vendor            is an empty stage with only vendored Hugo modules
build-upstream    builds an upstream project with a replacement module
validate-upstream validates HTML output for upstream builds
unused-media      checks for unused graphics and other media
pagefind          installs the Pagefind runtime
index             generates a Pagefind index
test-go-redirects checks that the /go/ redirects are valid
release (default) is an empty scratch image with only compiled assets

将构建缓存导出到外部缓存目的地 (--cache-to)

--cache-to=[NAME|type=TYPE[,KEY=VALUE]]

将构建缓存导出到外部缓存目的地。支持的类型有 registrylocalinlineghas3

docker 驱动程序仅支持使用 inlinelocal 缓存后端导出缓存。

属性键

  • mode - 指定随缓存导出的层数。min 仅导出最终构建阶段中已有的层,max 导出所有阶段的层。元数据始终导出整个构建的。
$ docker buildx build --cache-to=user/app:cache .
$ docker buildx build --cache-to=type=inline .
$ docker buildx build --cache-to=type=registry,ref=user/app .
$ docker buildx build --cache-to=type=local,dest=path/to/cache .
$ docker buildx build --cache-to=type=gha .
$ docker buildx build --cache-to=type=s3,region=eu-west-1,bucket=mybucket .

有关缓存导出器和可用属性的更多信息:https://github.com/moby/buildkit#export-cache

使用自定义父 cgroup (--cgroup-parent)

当您使用 --cgroup-parent 选项运行 docker buildx build 时,守护程序将使用 相应的 docker run 标志运行构建中使用的容器。

指定 Dockerfile (-f, --file)

$ docker buildx build -f <filepath> .

指定要使用的 Dockerfile 的文件路径。如果未指定,默认使用构建上下文根目录下的名为 Dockerfile 的文件。

要从 stdin 读取 Dockerfile,您可以将 - 作为 --file 的参数。

$ cat Dockerfile | docker buildx build -f - .

将单平台构建结果加载到 docker images (--load)

--output=type=docker 的简写形式。将自动把单平台构建结果加载到 docker images

将构建结果元数据写入文件 (--metadata-file)

要输出构建元数据(例如镜像摘要),请传递 --metadata-file 标志。元数据将以 JSON 对象的形式写入指定文件。指定文件的目录必须已存在且可写。

$ docker buildx build --load --metadata-file metadata.json .
$ cat metadata.json
{
  "buildx.build.provenance": {},
  "buildx.build.ref": "mybuilder/mybuilder0/0fjb6ubs52xx3vygf6fgdl611",
  "buildx.build.warnings": {},
  "containerimage.config.digest": "sha256:2937f66a9722f7f4a2df583de2f8cb97fc9196059a410e7f00072fc918930e66",
  "containerimage.descriptor": {
    "annotations": {
      "config.digest": "sha256:2937f66a9722f7f4a2df583de2f8cb97fc9196059a410e7f00072fc918930e66",
      "org.opencontainers.image.created": "2022-02-08T21:28:03Z"
    },
    "digest": "sha256:19ffeab6f8bc9293ac2c3fdf94ebe28396254c993aea0b5a542cfb02e0883fa3",
    "mediaType": "application/vnd.oci.image.manifest.v1+json",
    "size": 506
  },
  "containerimage.digest": "sha256:19ffeab6f8bc9293ac2c3fdf94ebe28396254c993aea0b5a542cfb02e0883fa3"
}

注意

构建记录 来源证明 (buildx.build.provenance) 默认包含最小来源证明。设置 BUILDX_METADATA_PROVENANCE 环境变量可自定义此行为

  • min 设置最小来源证明(默认)。
  • max 设置完整来源证明。
  • disabledfalse0 不设置任何来源证明。

注意

构建警告 (buildx.build.warnings) 默认不包含。设置 BUILDX_METADATA_WARNINGS 环境变量为 1true 可包含它们。

构建期间为 RUN 指令设置网络模式 (--network)

网络模式的可用选项有

  • default (默认):在默认网络中运行。
  • none:在没有网络访问权限的情况下运行。
  • host:在宿主机的网络环境中运行。

更多详情请参见 Dockerfile 参考

忽略特定阶段的构建缓存 (--no-cache-filter)

--no-cache-filter 允许您指定多阶段 Dockerfile 中的一个或多个阶段,这些阶段的构建缓存应被忽略。要指定多个阶段,请使用逗号分隔的语法

$ docker buildx build --no-cache-filter stage1,stage2,stage3 .

例如,以下 Dockerfile 包含四个阶段

  • base
  • install
  • test
  • release
# syntax=docker/dockerfile:1

FROM oven/bun:1 AS base
WORKDIR /app

FROM base AS install
WORKDIR /temp/dev
RUN --mount=type=bind,source=package.json,target=package.json \
    --mount=type=bind,source=bun.lockb,target=bun.lockb \
    bun install --frozen-lockfile

FROM base AS test
COPY --from=install /temp/dev/node_modules node_modules
COPY . .
RUN bun test

FROM base AS release
ENV NODE_ENV=production
COPY --from=install /temp/dev/node_modules node_modules
COPY . .
ENTRYPOINT ["bun", "run", "index.js"]

要忽略 install 阶段的缓存

$ docker buildx build --no-cache-filter install .

要忽略 installrelease 阶段的缓存

$ docker buildx build --no-cache-filter install,release .

--no-cache-filter 标志的参数必须是阶段的名称。

设置构建结果的导出操作 (-o, --output)

-o, --output=[PATH,-,type=TYPE[,KEY=VALUE]

设置构建结果的导出操作。使用 docker 构建驱动程序时的默认输出是将容器镜像导出到本地镜像存储。--output 标志使此步骤可配置,允许将结果直接导出到客户端的文件系统、OCI 镜像 tarball、registry 等。

Buildx 使用 docker 驱动程序时仅支持 local、tarball 和 image 导出器docker-container 驱动程序支持所有导出器。

如果您仅指定文件路径作为 --output 的参数,Buildx 将使用 local 导出器。如果值为 -,Buildx 将使用 tar 导出器并将输出写入 stdout。

$ docker buildx build -o . .
$ docker buildx build -o outdir .
$ docker buildx build -o - . > out.tar
$ docker buildx build -o type=docker .
$ docker buildx build -o type=docker,dest=- . > myimage.tar
$ docker buildx build -t tonistiigi/foo -o type=registry

您可以通过重复该标志来导出多个输出。

支持的导出类型有

local

local 导出类型将所有结果文件写入客户端上的目录。新文件将由当前用户拥有。在多平台构建中,所有结果将按其平台放入子目录中。

属性键

  • dest - 文件将被写入的目标目录

更多信息,请参见 Local 和 tar 导出器

tar

tar 导出类型将所有结果文件写入客户端上的单个 tarball。在多平台构建中,所有结果将按其平台放入子目录中。

属性键

  • dest - tarball 将被写入的目标路径。“-” 写入 stdout。

更多信息,请参见 Local 和 tar 导出器

oci

oci 导出类型将结果镜像或清单列表写入客户端上的 OCI 镜像布局 tarball。

属性键

  • dest - tarball 将被写入的目标路径。“-” 写入 stdout。

更多信息,请参见 OCI 和 Docker 导出器

docker

docker 导出类型将单平台结果镜像写入客户端上的 Docker 镜像规范 tarball。此导出器创建的 tarball 也与 OCI 兼容。

Docker Engine 中的默认镜像存储不支持加载多平台镜像。您可以启用 containerd 镜像存储,或者将多平台镜像直接推送到 registry,参见 registry

属性键

  • dest - tarball 将被写入的目标路径。如果未指定,tar 将自动加载到本地镜像存储。
  • context - 导入结果的 Docker 上下文名称

更多信息,请参见 OCI 和 Docker 导出器

image

image 导出器将构建结果写入为镜像或清单列表。使用 docker 驱动程序时,镜像将显示在 docker images 中。或者,可以通过指定属性将镜像自动推送到 registry。

属性键

  • name - 新镜像的名称(引用)。
  • push - 用于自动推送镜像的布尔值。

更多信息,请参见 Image 和 registry 导出器

registry

registry 导出器是 type=image,push=true 的快捷方式。

更多信息,请参见 Image 和 registry 导出器

设置构建的目标平台 (--platform)

--platform=value[,value]

设置构建的目标平台。Dockerfile 中所有没有自己的 --platform 标志的 FROM 命令都将为此平台拉取基础镜像,此值也将是结果镜像的平台。

默认值是运行构建的 BuildKit 守护程序的平台。该值采用 os/archos/arch/variant 的形式。例如,linux/amd64linux/arm/v7。此外,--platform 标志还支持一个特殊的 local 值,该值告诉 BuildKit 使用调用构建的 BuildKit 客户端的平台。

docker-container 驱动程序与 buildx 一起使用时,此标志可以接受逗号分隔的多个值作为输入。使用多个值时,将为所有指定的平台构建结果,并将其合并到一个清单列表中。

如果 Dockerfile 需要调用 RUN 命令,构建器需要对指定平台提供运行时支持。在干净的设置中,您只能执行针对您系统架构的 RUN 命令。如果您的内核支持用于二级架构的 binfmt_misc 启动器,buildx 将自动识别它们。Docker Desktop 版本自动配置了适用于 arm64arm 架构的 binfmt_misc。您可以通过运行 docker buildx inspect --bootstrap 来查看当前构建器实例支持的运行时平台。

Dockerfile 内部,您可以通过 TARGETPLATFORM 构建参数访问当前平台值。有关自动平台参数变体的完整说明,请参阅 Dockerfile 参考

您可以在 containerd 源代码 中找到平台规范的格式定义。

$ docker buildx build --platform=linux/arm64 .
$ docker buildx build --platform=linux/amd64,linux/arm64,linux/arm/v7 .
$ docker buildx build --platform=darwin .

设置进度输出类型 (--progress)

--progress=VALUE

设置进度输出类型。支持的值有

  • auto (默认):如果客户端是 TTY,则使用 tty 模式,否则使用 plain 模式
  • tty:具有颜色和重绘的交互式输出流
  • plain:以纯文本格式打印原始构建进度
  • quiet:抑制构建输出并在成功时打印镜像 ID(与 --quiet 相同)
  • rawjson:将原始构建进度打印为 JSON 行

注意

您也可以使用 BUILDKIT_PROGRESS 环境变量来设置其值。

以下示例在构建期间使用 plain 输出

$ docker buildx build --load --progress=plain .

#1 [internal] load build definition from Dockerfile
#1 transferring dockerfile: 227B 0.0s done
#1 DONE 0.1s

#2 [internal] load .dockerignore
#2 transferring context: 129B 0.0s done
#2 DONE 0.0s
...

注意

还可以查看 BUILDKIT_COLORS 环境变量,用于修改终端输出的颜色。

rawjson 输出将 BuildKit 的求解状态事件序列化为 JSON 行。此模式旨在供外部程序读取。

创建来源证明 (--provenance)

--attest=type=provenance 的简写形式,用于配置构建结果的来源证明。例如,--provenance=mode=max 可以作为 --attest=type=provenance,mode=max 的缩写形式使用。

此外,--provenance 可以与布尔值一起使用,以启用或禁用来源证明。例如,--provenance=false 禁用所有来源证明,而 --provenance=true 启用所有来源证明。

默认情况下,将为构建结果创建最小来源证明。请注意,Docker Engine 中的默认镜像存储不支持证明。如果您使用默认镜像存储,来源证明仅对直接推送到 registry 的镜像持久化。或者,您可以切换到使用 containerd 镜像存储。

有关来源证明的更多信息,请参见此处

将构建结果推送到 registry (--push)

--output=type=registry 的简写形式。将自动将构建结果推送到 registry。

创建 SBOM 证明 (--sbom)

--attest=type=sbom 的简写形式,用于配置构建结果的 SBOM 证明。例如,--sbom=generator=<user>/<generator-image> 可以作为 --attest=type=sbom,generator=<user>/<generator-image> 的缩写形式使用。

此外,--sbom 可以与布尔值一起使用,以启用或禁用 SBOM 证明。例如,--sbom=false 禁用所有 SBOM 证明。

请注意,Docker Engine 中的默认镜像存储不支持证明。如果您使用默认镜像存储,来源证明仅对直接推送到 registry 的镜像持久化。或者,您可以切换到使用 containerd 镜像存储。

有关更多信息,请参阅此处

暴露给构建的秘密 (--secret)

--secret=[type=TYPE[,KEY=VALUE]

将秘密(认证凭据、令牌)暴露给构建。可以在 Dockerfile 中使用 RUN --mount=type=secret 挂载将秘密挂载到构建中。有关如何使用构建秘密的更多信息,请参见 构建秘密

支持的类型有

如果未设置 type,Buildx 会尝试自动检测。如果设置了与 id 具有相同键的环境变量,则 Buildx 使用 type=env,并且变量值成为秘密。如果未设置此类环境变量且未设置 type,则 Buildx 回退到 type=file

type=file

从文件获取构建秘密。

type=file 概要
$ docker buildx build --secret [type=file,]id=<ID>[,src=<FILEPATH>] .
type=file 属性
描述默认值
id秘密的 ID。N/A(此键必需)
src, source包含秘密值的文件路径(绝对路径或相对于当前工作目录的路径)。如果未设置,则为 id
type=file 用法

在以下示例中,由于未设置与 aws(ID)匹配的环境变量,因此自动检测到 type=file

$ docker buildx build --secret id=aws,src=$HOME/.aws/credentials .
# syntax=docker/dockerfile:1
FROM python:3
RUN pip install awscli
RUN --mount=type=secret,id=aws,target=/root/.aws/credentials \
  aws s3 cp s3://... ...

type=env

从环境变量获取构建秘密。

type=env 概要
$ docker buildx build --secret [type=env,]id=<ID>[,env=<VARIABLE>] .
type=env 属性
描述默认值
id秘密的 ID。N/A(此键必需)
env, src, source用作秘密来源的环境变量。如果未设置,则为 id
type=env 用法

在以下示例中,由于设置了与 id 匹配的环境变量,因此自动检测到 type=env

$ SECRET_TOKEN=token docker buildx build --secret id=SECRET_TOKEN .
# syntax=docker/dockerfile:1
FROM node:alpine
RUN --mount=type=bind,target=. \
  --mount=type=secret,id=SECRET_TOKEN,env=SECRET_TOKEN \
  yarn run test

在以下示例中,构建参数 SECRET_TOKEN 被设置为包含环境变量 API_KEY 的值。

$ API_KEY=token docker buildx build --secret id=SECRET_TOKEN,env=API_KEY .

您也可以使用 srcsource 指定环境变量的名称

$ API_KEY=token docker buildx build --secret type=env,id=SECRET_TOKEN,src=API_KEY .

注意

使用 srcsource 指定环境变量名称时,您需要显式设置 type=env,否则 Buildx 会假定秘密是 type=file,并查找名称为 srcsource 的文件(在本例中,是相对于执行 docker buildx build 命令的位置,名为 API_KEY 的文件)。

构建容器的共享内存大小 (--shm-size)

使用 RUN 指令时,设置分配给构建容器的共享内存大小。

格式为 <number><unit>number 必须大于 0。单位是可选的,可以是 b(字节)、k(千字节)、m(兆字节)或 g(千兆字节)。如果省略单位,系统默认使用字节。

注意

在大多数情况下,建议让构建器自动确定适当的配置。仅当复杂的构建场景需要特定的性能调优时,才应考虑手动调整。

暴露给构建的 SSH agent socket 或密钥 (--ssh)

--ssh=default|<id>[=<socket>|<key>[,<key>]]

当 Dockerfile 中的某些命令需要特定的 SSH 认证(例如,克隆私有仓库)时,这会很有用。

--ssh 将 SSH agent socket 或密钥暴露给构建,并可以与 RUN --mount=type=ssh 挂载一起使用。

使用 SSH agent socket 访问 Gitlab 的示例

# syntax=docker/dockerfile:1
FROM alpine
RUN apk add --no-cache openssh-client
RUN mkdir -p -m 0700 ~/.ssh && ssh-keyscan gitlab.com >> ~/.ssh/known_hosts
RUN --mount=type=ssh ssh -q -T git@gitlab.com 2>&1 | tee /hello
# "Welcome to GitLab, @GITLAB_USERNAME_ASSOCIATED_WITH_SSHKEY" should be printed here
# with the type of build progress is defined as `plain`.
$ eval $(ssh-agent)
$ ssh-add ~/.ssh/id_rsa
(Input your passphrase here)
$ docker buildx build --ssh default=$SSH_AUTH_SOCK .

标记镜像 (-t, --tag)

$ docker buildx build -t docker/apache:2.0 .

此示例的构建方式与上一个示例相同,但它会标记结果镜像。仓库名称将是 docker/apache,标签为 2.0

了解更多关于有效标签的信息.

您可以为一个镜像应用多个标签。例如,您可以将 latest 标签应用于新构建的镜像,并添加另一个引用特定版本的标签。

例如,要将一个镜像同时标记为 docker/fedora-jboss:latestdocker/fedora-jboss:v2.1,请使用以下命令

$ docker buildx build -t docker/fedora-jboss:latest -t docker/fedora-jboss:v2.1 .

指定目标构建阶段 (--target)

构建包含多个构建阶段的 Dockerfile 时,使用 --target 选项按名称指定中间构建阶段作为结果镜像的最终阶段。构建器会跳过目标阶段之后的命令。

FROM debian AS build-env
# ...

FROM alpine AS production-env
# ...
$ docker buildx build -t mybuildimage --target build-env .

设置 ulimits (--ulimit)

--ulimit 会在使用 RUN 指令时覆盖构建容器的默认 ulimits,并按如下方式指定软限制和硬限制:<type>=<soft limit>[:<hard limit>],例如

$ docker buildx build --ulimit nofile=1024:1024 .

注意

如果您未提供 hard limit,则 soft limit 将用于这两个值。如果没有设置 ulimits,它们将继承自守护程序上设置的默认 ulimits

注意

在大多数情况下,建议让构建器自动确定适当的配置。仅当复杂的构建场景需要特定的性能调优时,才应考虑手动调整。