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设置评估构建的方法(checkoutlinetargets
--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设置进度输出的类型(autoplainttyrawjson)。使用 plain 显示容器输出
--provenance--attest=type=provenance的简写
--pull始终尝试拉取所有引用的镜像
--push--output=type=registry的简写
-q, --quiet抑制构建输出,并在成功时打印镜像 ID
--root实验性 (CLI) 指定要连接的服务器的根目录
--sbom--attest=type=sbom的简写
--secret要公开给构建的密钥(格式:id=mysecret[,src=/local/secret]
--server-config实验性 (CLI) 指定 buildx 服务器配置文件(仅在启动新服务器时使用)
--shm-size构建容器的共享内存大小
--ssh要公开给构建的 SSH 代理套接字或密钥(格式: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]) 指定平台限定符,以将注释应用于具有匹配平台的清单子集。以下示例仅将foo=bar注释添加到具有linux/amd64平台的清单。

$ 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守护程序也需要使用--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标志,在这种情况下,守护程序会将值从本地环境传播到它正在构建的 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标志允许您指定要执行的前端方法。如果未指定此标志,则默认为执行构建并评估构建检查

对于Dockerfiles,可用的方法是

命令描述
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文档字符串的更多示例,请查看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的文件。

要从标准输入读取 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、注册表等等。

使用docker驱动的 Buildx 仅支持本地、tarball 和镜像 导出程序docker-container驱动程序支持所有导出程序。

如果只指定文件路径作为--output的参数,Buildx 将使用本地导出程序。如果值为-,Buildx 将使用tar导出程序并将输出写入标准输出。

$ 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 - 将写入文件的目标目录

有关更多信息,请参阅本地和 tar 导出程序

tar

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

属性键

  • dest - 将写入 tarball 的目标路径。“-”写入标准输出。

有关更多信息,请参阅本地和 tar 导出程序

oci

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

属性键

  • dest - 将写入 tarball 的目标路径。“-”写入标准输出。

有关更多信息,请参阅OCI 和 Docker 导出程序

docker

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

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

属性键

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

有关更多信息,请参阅OCI 和 Docker 导出程序

image

image导出程序将构建结果写入镜像或清单列表。使用docker驱动程序时,镜像将出现在docker images中。可选地,可以通过指定属性自动将镜像推送到注册表。

属性键

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

有关更多信息,请参阅镜像和注册表导出程序

registry

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

有关更多信息,请参阅镜像和注册表导出程序

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

--platform=value[,value]

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

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

当使用带有buildxdocker-container驱动程序时,此标志可以接受以逗号分隔的多个值作为输入。使用多个值时,结果将针对所有指定的平台构建,并组合成单个清单列表。

如果Dockerfile需要调用RUN命令,构建器需要指定平台的运行时支持。在干净的设置中,你只能为你的系统架构执行RUN命令。如果你的内核支持binfmt_misc启动器用于次要架构,buildx 将自动选择它们。Docker Desktop 版本会自动配置binfmt_misc以用于arm64arm架构。你可以通过运行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, plain, tty, rawjson)。使用plain显示容器输出(默认auto)。

注意

你也可以使用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 中的默认镜像存储库不支持证明。仅当使用默认镜像存储库时,来源证明才会对直接推送到注册表的镜像持久存在。或者,你可以切换到使用 containerd 镜像存储库。

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

将构建结果推送到注册表 (--push)

--output=type=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 中的默认镜像存储库不支持证明。仅当使用默认镜像存储库时,来源证明才会对直接推送到注册表的镜像持久存在。或者,你可以切换到使用 containerd 镜像存储库。

更多信息,请参见此处

公开给构建的密钥 (--secret)

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

将密钥(身份验证凭据、令牌)公开给构建。可以使用Dockerfile中的RUN --mount=type=secret挂载将密钥挂载到构建中。有关如何使用构建密钥的更多信息,请参见构建密钥

支持的类型为

如果未设置,Buildx 会尝试自动检测type。如果设置了与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的文件(在这种情况下,名为API_KEY的文件相对于执行docker buildx build命令的位置)。

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

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

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

注意

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

公开给构建的 SSH 代理套接字或密钥 (--ssh)

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

当你的 Dockerfile 中的一些命令需要特定的 SSH 身份验证(例如,克隆私有存储库)时,这将非常有用。

--ssh将 SSH 代理套接字或密钥公开给构建,并可与RUN --mount=type=ssh挂载一起使用。

使用 SSH 代理套接字访问 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 .

设置 ulimit (--ulimit)

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

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

注意

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

注意

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