docker
/
docs
mirror of https://github.com/docker/docs.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

vendor: github.com/docker/buildx v0.12.0 

Signed-off-by: David Karlsson <35727626+dvdksn@users.noreply.github.com>
This commit is contained in:
David Karlsson 2023-11-17 09:55:57 +01:00
parent bf958ab99e
commit 320f719d57
15 changed files with 352 additions and 245 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

137
_vendor/github.com/docker/buildx/docs/bake-reference.md generated
View File

@ -12,18 +12,118 @@ You can define your Bake file in the following file formats:
By default, Bake uses the following lookup order to find the configuration file:
1. `docker-bake.override.hcl`
2. `docker-bake.hcl`
3. `docker-bake.override.json`
4. `docker-bake.json`
5. `docker-compose.yaml`
6. `docker-compose.yml`
1. `compose.yaml`
2. `compose.yml`
3. `docker-compose.yml`
4. `docker-compose.yaml`
5. `docker-bake.json`
6. `docker-bake.override.json`
7. `docker-bake.hcl`
8. `docker-bake.override.hcl`
Bake searches for the file in the current working directory.
You can specify the file location explicitly using the `--file` flag:
```console
$ docker buildx bake --file=../docker/bake.hcl --print
$ docker buildx bake --file ../docker/bake.hcl --print
```
If you don't specify a file explicitly, Bake searches for the file in the
current working directory. If more than one Bake file is found, all files are
merged into a single definition. Files are merged according to the lookup
order. That means that if your project contains both a `compose.yaml` file and
a `docker-bake.hcl` file, Bake loads the `compose.yaml` file first, and then
the `docker-bake.hcl` file.
If merged files contain duplicate attribute definitions, those definitions are
either merged or overridden by the last occurrence, depending on the attribute.
The following attributes are overridden by the last occurrence:
- `target.cache-to`
- `target.dockerfile-inline`
- `target.dockerfile`
- `target.outputs`
- `target.platforms`
- `target.pull`
- `target.tags`
- `target.target`
For example, if `compose.yaml` and `docker-bake.hcl` both define the `tags`
attribute, the `docker-bake.hcl` is used.
```console
$ cat compose.yaml
services:
webapp:
build:
context: .
tags:
- bar
$ cat docker-bake.hcl
target "webapp" {
tags = ["foo"]
}
$ docker buildx bake --print webapp
{
"group": {
"default": {
"targets": [
"webapp"
]
}
},
"target": {
"webapp": {
"context": ".",
"dockerfile": "Dockerfile",
"tags": [
"foo"
]
}
}
}
```
All other attributes are merged. For example, if `compose.yaml` and
`docker-bake.hcl` both define unique entries for the `labels` attribute, all
entries are included. Duplicate entries for the same label are overridden.
```console
$ cat compose.yaml
services:
webapp:
build:
context: .
labels:
com.example.foo: "foo"
com.example.name: "Alice"
$ cat docker-bake.hcl
target "webapp" {
labels = {
"com.example.bar" = "bar"
"com.example.name" = "Bob"
}
}
$ docker buildx bake --print webapp
{
"group": {
"default": {
"targets": [
"webapp"
]
}
},
"target": {
"webapp": {
"context": ".",
"dockerfile": "Dockerfile",
"labels": {
"com.example.foo": "foo",
"com.example.bar": "bar",
"com.example.name": "Bob"
}
}
}
}
```
## Syntax
@ -115,6 +215,7 @@ The following table shows the complete list of attributes that you can assign to
| Name | Type | Description |
| ----------------------------------------------- | ------- | -------------------------------------------------------------------- |
| [`args`](#targetargs) | Map | Build arguments |
| [`annotations`](#targetannotations) | List | Exporter annotations |
| [`attest`](#targetattest) | List | Build attestations |
| [`cache-from`](#targetcache-from) | List | External cache sources |
| [`cache-to`](#targetcache-to) | List | External cache destinations |
@ -171,6 +272,26 @@ target "db" {
}
```
### `target.annotations`
The `annotations` attribute is a shortcut to allow you to easily set a list of
annotations on the target.
```hcl
target "default" {
output = ["type=image,name=foo"]
annotations = ["key=value"]
}
```
is the same as
```hcl
target "default" {
output = ["type=image,name=foo,annotation.key=value"]
}
```
### `target.attest`
The `attest` attribute lets you apply [build attestations][attestations] to the target.

2
_vendor/modules.txt
View File

@ -1,6 +1,6 @@
# github.com/moby/moby v24.0.5+incompatible
# github.com/moby/buildkit v0.13.0-beta1.0.20231113205014-1efcd30d9dd6
# github.com/docker/buildx v0.11.2
# github.com/docker/buildx v0.12.0
# github.com/docker/scout-cli v1.0.9
# github.com/docker/cli v24.0.8-0.20231106123152-48ec4f339e2b+incompatible
# github.com/docker/compose-cli v1.0.35

4
data/buildx/docker_buildx.yaml
View File

@ -7,7 +7,7 @@ cname:
- docker buildx bake
- docker buildx build
- docker buildx create
- docker buildx debug-shell
- docker buildx debug
- docker buildx du
- docker buildx imagetools
- docker buildx inspect
@ -21,7 +21,7 @@ clink:
- docker_buildx_bake.yaml
- docker_buildx_build.yaml
- docker_buildx_create.yaml
- docker_buildx_debug-shell.yaml
- docker_buildx_debug.yaml
- docker_buildx_du.yaml
- docker_buildx_imagetools.yaml
- docker_buildx_inspect.yaml

12
data/buildx/docker_buildx_bake.yaml
View File

@ -2,7 +2,7 @@ command: docker buildx bake
aliases: docker buildx bake, docker buildx f
short: Build from a file
long: |-
Bake is a high-level build command. Each specified target will run in parallel
Bake is a high-level build command. Each specified target runs in parallel
as part of the build.
Read [High-level build options with Bake](/build/bake/)
@ -153,8 +153,8 @@ examples: |-
### Specify a build definition file (-f, --file) {#file}
Use the `-f` / `--file` option to specify the build definition file to use.
The file can be an HCL, JSON or Compose file. If multiple files are specified
they are all read and configurations are combined.
The file can be an HCL, JSON or Compose file. If multiple files are specified,
all are read and the build configurations are combined.
You can pass the names of the targets to build, to build only specific target(s).
The following example builds the `db` and `webapp-release` targets that are
@ -189,9 +189,9 @@ examples: |-
See the [Bake file reference](/build/bake/reference/)
for more details.
### Do not use cache when building the image (--no-cache) {#no-cache}
### Don't use cache when building the image (--no-cache) {#no-cache}
Same as `build --no-cache`. Do not use cache when building the image.
Same as `build --no-cache`. Don't use cache when building the image.
### Print the options without building (--print) {#print}
@ -253,7 +253,7 @@ examples: |-
$ docker buildx bake --set foo*.no-cache # bypass caching only for targets starting with 'foo'
```
Complete list of overridable fields:
You can override the following fields:
* `args`
* `cache-from`

145
data/buildx/docker_buildx_build.yaml
View File

@ -6,8 +6,8 @@ long: |-
to the UI of `docker build` command and takes the same flags and arguments.
For documentation on most of these flags, refer to the [`docker build`
documentation](/engine/reference/commandline/build/). In
here we'll document a subset of the new flags.
documentation](/engine/reference/commandline/build/).
This page describes a subset of the new flags.
usage: docker buildx build [OPTIONS] PATH | URL | -
pname: docker buildx
plink: docker_buildx.yaml
@ -35,6 +35,16 @@ options:
experimentalcli: false
kubernetes: false
swarm: false
- option: annotation
value_type: stringArray
default_value: '[]'
description: Add annotation to the image
deprecated: false
hidden: false
experimental: false
experimentalcli: false
kubernetes: false
swarm: false
- option: attest
value_type: stringArray
default_value: '[]'
@ -94,7 +104,7 @@ options:
swarm: false
- option: cgroup-parent
value_type: string
description: Optional parent cgroup for the container
description: Set the parent cgroup for the `RUN` instructions during build
details_url: /engine/reference/commandline/build/#cgroup-parent
deprecated: false
hidden: false
@ -201,15 +211,6 @@ options:
experimentalcli: false
kubernetes: false
swarm: false
- option: invoke
value_type: string
description: Invoke a command after the build
deprecated: false
hidden: false
experimental: false
experimentalcli: true
kubernetes: false
swarm: false
- option: isolation
value_type: string
description: Container isolation technology
@ -527,7 +528,7 @@ inherited_options:
examples: |-
### Create attestations (--attest) {#attest}
```
```text
--attest=type=sbom,...
--attest=type=provenance,...
```
@ -554,7 +555,7 @@ examples: |-
### Allow extra privileged entitlement (--allow) {#allow}
```
```text
--allow=ENTITLEMENT
```
@ -565,9 +566,7 @@ examples: |-
[related Dockerfile extensions](/engine/reference/builder/#run---securitysandbox).
For entitlements to be enabled, the `buildkitd` daemon also needs to allow them
with `--allow-insecure-entitlement` (see [`create --buildkitd-flags`](buildx_create.md#buildkitd-flags))
**Examples**
with `--allow-insecure-entitlement` (see [`create --buildkitd-flags`](buildx_create.md#buildkitd-flags)).
```console
$ docker buildx create --use --name insecure-builder --buildkitd-flags '--allow-insecure-entitlement security.insecure'
@ -578,24 +577,21 @@ examples: |-
Same as [`docker build` command](/engine/reference/commandline/build/#build-arg).
There are also useful built-in build args like:
There are also useful built-in build arguments, such as:
* `BUILDKIT_CONTEXT_KEEP_GIT_DIR=<bool>` trigger git context to keep the `.git` directory
* `BUILDKIT_INLINE_BUILDINFO_ATTRS=<bool>` inline build info attributes in image config or not
* `BUILDKIT_INLINE_CACHE=<bool>` inline cache metadata to image config or not
* `BUILDKIT_MULTI_PLATFORM=<bool>` opt into deterministic output regardless of multi-platform output or not
* `BUILDKIT_CONTEXT_KEEP_GIT_DIR=<bool>`: trigger git context to keep the `.git` directory
* `BUILDKIT_INLINE_CACHE=<bool>`: inline cache metadata to image config or not
* `BUILDKIT_MULTI_PLATFORM=<bool>`: opt into deterministic output regardless of multi-platform output or not
```console
$ docker buildx build --build-arg BUILDKIT_MULTI_PLATFORM=1 .
```
> **Note**
>
> More built-in build args can be found in [Dockerfile reference docs](/engine/reference/builder/#buildkit-built-in-build-args).
Learn more about the built-in build arguments in the [Dockerfile reference docs](/engine/reference/builder/#buildkit-built-in-build-args).
### Additional build contexts (--build-context) {#build-context}
```
```text
--build-context=name=VALUE
```
@ -623,7 +619,7 @@ examples: |-
COPY --from=project myfile /
```
#### Source image from OCI layout directory {#source-oci-layout}
#### Use an OCI layout directory as build context {#source-oci-layout}
Source an image from a local [OCI layout compliant directory](https://github.com/opencontainers/image-spec/blob/main/image-layout.md),
either by tag, or by digest:
@ -651,7 +647,7 @@ examples: |-
### Use an external cache source for a build (--cache-from) {#cache-from}
```
```text
--cache-from=[NAME|type=TYPE[,KEY=VALUE]]
```
@ -687,7 +683,7 @@ examples: |-
### Export build cache to an external cache destination (--cache-to) {#cache-to}
```
```text
--cache-to=[NAME|type=TYPE[,KEY=VALUE]]
```
@ -704,9 +700,8 @@ examples: |-
- [`s3` type](https://github.com/moby/buildkit#s3-cache-experimental) exports
cache to a S3 bucket.
`docker` driver currently only supports exporting inline cache metadata to image
configuration. Alternatively, `--build-arg BUILDKIT_INLINE_CACHE=1` can be used
to trigger inline cache exporter.
The `docker` driver only supports cache exports using the `inline` and `local`
cache backends.
Attribute key:
@ -740,28 +735,9 @@ examples: |-
$ docker buildx build --load --metadata-file metadata.json .
$ cat metadata.json
```
```json
{
"containerimage.buildinfo": {
"frontend": "dockerfile.v0",
"attrs": {
"context": "https://github.com/crazy-max/buildkit-buildsources-test.git#master",
"filename": "Dockerfile",
"source": "docker/dockerfile:master"
},
"sources": [
{
"type": "docker-image",
"ref": "docker.io/docker/buildx-bin:0.6.1@sha256:a652ced4a4141977c7daaed0a074dcd9844a78d7d2615465b12f433ae6dd29f0",
"pin": "sha256:a652ced4a4141977c7daaed0a074dcd9844a78d7d2615465b12f433ae6dd29f0"
},
{
"type": "docker-image",
"ref": "docker.io/library/alpine:3.13",
"pin": "sha256:026f721af4cf2843e07bba648e158fb35ecc876d822130633cc49f707f0fc88c"
}
]
},
"containerimage.config.digest": "sha256:2937f66a9722f7f4a2df583de2f8cb97fc9196059a410e7f00072fc918930e66",
"containerimage.descriptor": {
"annotations": {
@ -778,14 +754,14 @@ examples: |-
### Set the export action for the build result (-o, --output) {#output}
```
```text
-o, --output=[PATH,-,type=TYPE[,KEY=VALUE]
```
Sets the export action for the build result. In `docker build` all builds finish
by creating a container image and exporting it to `docker images`. `buildx` makes
this step configurable allowing results to be exported directly to the client,
oci image tarballs, registry etc.
OCI image tarballs, registry etc.
Buildx with `docker` driver currently only supports local, tarball exporter and
image exporter. `docker-container` driver supports all the exporters.
@ -840,15 +816,15 @@ examples: |-
specification](https://github.com/docker/docker/blob/v20.10.2/image/spec/v1.2.md)
tarball on the client. Tarballs created by this exporter are also OCI compatible.
Currently, multi-platform images cannot be exported with the `docker` export type.
The most common usecase for multi-platform images is to directly push to a registry
(see [`registry`](#registry)).
The default image store in Docker Engine doesn't support loading multi-platform
images. You can enable the containerd image store, or push multi-platform images
is to directly push to a registry, see [`registry`](#registry).
Attribute keys:
- `dest` - destination path where tarball will be written. If not specified the
tar will be loaded automatically to the current docker instance.
- `context` - name for the docker context where to import the result
- `dest` - destination path where tarball will be written. If not specified,
the tar will be loaded automatically to the local image store.
- `context` - name for the Docker context where to import the result
#### `image`
@ -859,7 +835,7 @@ examples: |-
Attribute keys:
- `name` - name (references) for the new image.
- `push` - boolean to automatically push the image.
- `push` - Boolean to automatically push the image.
#### `registry`
@ -867,7 +843,7 @@ examples: |-
### Set the target platforms for the build (--platform) {#platform}
```
```text
--platform=value[,value]
```
@ -896,12 +872,12 @@ examples: |-
instance supports by running `docker buildx inspect --bootstrap`.
Inside a `Dockerfile`, you can access the current platform value through
`TARGETPLATFORM` build argument. Please refer to the [`docker build`
`TARGETPLATFORM` build argument. Refer to the [`docker build`
documentation](/engine/reference/builder/#automatic-platform-args-in-the-global-scope)
for the full description of automatic platform argument variants .
The formatting for the platform specifier is defined in the [containerd source
code](https://github.com/containerd/containerd/blob/v1.4.3/platforms/platforms.go#L63).
You can find the formatting definition for the platform specifier in the
[containerd source code](https://github.com/containerd/containerd/blob/v1.4.3/platforms/platforms.go#L63).
```console
$ docker buildx build --platform=linux/arm64 .
@ -911,11 +887,11 @@ examples: |-
### Set type of progress output (--progress) {#progress}
```
```text
--progress=VALUE
```
Set type of progress output (auto, plain, tty). Use plain to show container
Set type of progress output (`auto`, `plain`, `tty`). Use plain to show container
output (default "auto").
> **Note**
@ -949,15 +925,18 @@ examples: |-
`--provenance=mode=max` can be used as an abbreviation for
`--attest=type=provenance,mode=max`.
Additionally, `--provenance` can be used with boolean values to broadly enable
or disable provenance attestations. For example, `--provenance=false` can be
used to disable all provenance attestations, while `--provenance=true` can be
used to enable all provenance attestations.
Additionally, `--provenance` can be used with Boolean values to enable or disable
provenance attestations. For example, `--provenance=false` disables all provenance attestations,
while `--provenance=true` enables all provenance attestations.
By default, a minimal provenance attestation will be created for the build
result, which will only be attached for images pushed to registries.
result. Note that the default image store in Docker Engine doesn't support
attestations. Provenance attestations only persist for images pushed directly
to a registry if you use the default image store. Alternatively, you can switch
to using the containerd image store.
For more information, see [here](/build/attestations/slsa-provenance/).
For more information about provenance attestations, see
[here](/build/attestations/slsa-provenance/).
### Push the build result to a registry (--push) {#push}
@ -971,15 +950,19 @@ examples: |-
`--sbom=generator=<user>/<generator-image>` can be used as an abbreviation for
`--attest=type=sbom,generator=<user>/<generator-image>`.
Additionally, `--sbom` can be used with boolean values to broadly enable or
disable SBOM attestations. For example, `--sbom=false` can be used to disable
all SBOM attestations.
Additionally, `--sbom` can be used with Boolean values to enable or disable
SBOM attestations. For example, `--sbom=false` disables all SBOM attestations.
Note that the default image store in Docker Engine doesn't support
attestations. Provenance attestations only persist for images pushed directly
to a registry if you use the default image store. Alternatively, you can switch
to using the containerd image store.
For more information, see [here](/build/attestations/sbom/).
### Secret to expose to the build (--secret) {#secret}
```
```text
--secret=[type=TYPE[,KEY=VALUE]
```
@ -992,7 +975,7 @@ examples: |-
Attribute keys:
- `id` - ID of the secret. Defaults to basename of the `src` path.
- `id` - ID of the secret. Defaults to base name of the `src` path.
- `src`, `source` - Secret filename. `id` used if unset.
```dockerfile
@ -1034,7 +1017,7 @@ examples: |-
### SSH agent socket or keys to expose to the build (--ssh) {#ssh}
```
```text
--ssh=default|<id>[=<socket>|<key>[,<key>]]
```
@ -1074,8 +1057,8 @@ examples: |-
> **Note**
>
> If you do not provide a `hard limit`, the `soft limit` is used
> for both values. If no `ulimits` are set, they are inherited from
> If you don't provide a `hard limit`, the `soft limit` is used
> for both values. If no `ulimits` are set, they're inherited from
> the default `ulimits` set on the daemon.
deprecated: false
hidden: false

88
data/buildx/docker_buildx_create.yaml
View File

@ -1,9 +1,9 @@
command: docker buildx create
short: Create a new builder instance
long: |-
Create makes a new builder instance pointing to a docker context or endpoint,
Create makes a new builder instance pointing to a Docker context or endpoint,
where context is the name of a context from `docker context ls` and endpoint is
the address for docker socket (eg. `DOCKER_HOST` value).
the address for Docker socket (eg. `DOCKER_HOST` value).
By default, the current Docker configuration is used for determining the
context/endpoint value.
@ -155,7 +155,7 @@ examples: |-
### Specify options for the buildkitd daemon (--buildkitd-flags) {#buildkitd-flags}
```
```text
--buildkitd-flags FLAGS
```
@ -163,13 +163,13 @@ examples: |-
configuration file specified by [`--config`](#config). See `buildkitd --help`
for the available flags.
```
```text
--buildkitd-flags '--debug --debugaddr 0.0.0.0:6666'
```
### Specify a configuration file for the buildkitd daemon (--config) {#config}
```
```text
--config FILE
```
@ -177,7 +177,8 @@ examples: |-
can be overridden by [`--buildkitd-flags`](#buildkitd-flags).
See an [example buildkitd configuration file](https://github.com/moby/buildkit/blob/master/docs/buildkitd.toml.md).
If the configuration file is not specified, will look for one by default in:
If you don't specify a configuration file, Buildx looks for one by default in:
* `$BUILDX_CONFIG/buildkitd.default.toml`
* `$DOCKER_CONFIG/buildx/buildkitd.default.toml`
* `~/.docker/buildx/buildkitd.default.toml`
@ -189,23 +190,30 @@ examples: |-
### Set the builder driver to use (--driver) {#driver}
```
```text
--driver DRIVER
```
Sets the builder driver to be used. There are two available drivers, each have
their own specificities.
Sets the builder driver to be used. A driver is a configuration of a BuildKit
backend. Buildx supports the following drivers:
* `docker` (default)
* `docker-container`
* `kubernetes`
* `remote`
For more information about build drivers, see [here](/build/drivers/).
#### `docker` driver
Uses the builder that is built into the docker daemon. With this driver,
Uses the builder that is built into the Docker daemon. With this driver,
the [`--load`](buildx_build.md#load) flag is implied by default on
`buildx build`. However, building multi-platform images or exporting cache is
not currently supported.
#### `docker-container` driver
Uses a BuildKit container that will be spawned via docker. With this driver,
Uses a BuildKit container that will be spawned via Docker. With this driver,
both building multi-platform images and exporting cache are supported.
Unlike `docker` driver, built images will not automatically appear in
@ -214,7 +222,7 @@ examples: |-
#### `kubernetes` driver
Uses a kubernetes pods. With this driver, you can spin up pods with defined
Uses Kubernetes pods. With this driver, you can spin up pods with defined
BuildKit container image to build your images.
Unlike `docker` driver, built images will not automatically appear in
@ -233,48 +241,18 @@ examples: |-
### Set additional driver-specific options (--driver-opt) {#driver-opt}
```
```text
--driver-opt OPTIONS
```
Passes additional driver-specific options.
For information about available driver options, refer to the detailed
documentation for the specific driver:
Note: When using quoted values for example for the `nodeselector` or
`tolerations` options, ensure that quotes are escaped correctly for your shell.
#### `docker` driver
No driver options.
#### `docker-container` driver
- `image=IMAGE` - Sets the container image to be used for running buildkit.
- `network=NETMODE` - Sets the network mode for running the buildkit container.
- `cgroup-parent=CGROUP` - Sets the cgroup parent of the buildkit container if docker is using the "cgroupfs" driver. Defaults to `/docker/buildx`.
#### `kubernetes` driver
- `image=IMAGE` - Sets the container image to be used for running buildkit.
- `namespace=NS` - Sets the Kubernetes namespace. Defaults to the current namespace.
- `replicas=N` - Sets the number of `Pod` replicas. Defaults to 1.
- `requests.cpu` - Sets the request CPU value specified in units of Kubernetes CPU. Example `requests.cpu=100m`, `requests.cpu=2`
- `requests.memory` - Sets the request memory value specified in bytes or with a valid suffix. Example `requests.memory=500Mi`, `requests.memory=4G`
- `limits.cpu` - Sets the limit CPU value specified in units of Kubernetes CPU. Example `limits.cpu=100m`, `limits.cpu=2`
- `limits.memory` - Sets the limit memory value specified in bytes or with a valid suffix. Example `limits.memory=500Mi`, `limits.memory=4G`
- `serviceaccount` - Sets the created pod's service account. Example `serviceaccount=example-sa`
- `"nodeselector=label1=value1,label2=value2"` - Sets the kv of `Pod` nodeSelector. No Defaults. Example `nodeselector=kubernetes.io/arch=arm64`
- `"tolerations=key=foo,value=bar;key=foo2,operator=exists;key=foo3,effect=NoSchedule"` - Sets the `Pod` tolerations. Accepts the same values as the kube manifest tolera>tions. Key-value pairs are separated by `,`, tolerations are separated by `;`. No Defaults. Example `tolerations=operator=exists`
- `rootless=(true|false)` - Run the container as a non-root user without `securityContext.privileged`. Needs Kubernetes 1.19 or later. [Using Ubuntu host kernel is recommended](https://github.com/moby/buildkit/blob/master/docs/rootless.md). Defaults to false.
- `loadbalance=(sticky|random)` - Load-balancing strategy. If set to "sticky", the pod is chosen using the hash of the context path. Defaults to "sticky"
- `qemu.install=(true|false)` - Install QEMU emulation for multi platforms support.
- `qemu.image=IMAGE` - Sets the QEMU emulation image. Defaults to `tonistiigi/binfmt:latest`
#### `remote` driver
- `key=KEY` - Sets the TLS client key.
- `cert=CERT` - Sets the TLS client certificate to present to buildkitd.
- `cacert=CACERT` - Sets the TLS certificate authority used for validation.
- `servername=SERVER` - Sets the TLS server name to be used in requests (defaults to the endpoint hostname).
* [`docker` driver](/build/drivers/docker/)
* [`docker-container` driver](/build/drivers/docker-container/)
* [`kubernetes` driver](/build/drivers/kubernetes/)
* [`remote` driver](/build/drivers/remote/)
### Remove a node from a builder (--leave) {#leave}
@ -288,7 +266,7 @@ examples: |-
### Specify the name of the builder (--name) {#name}
```
```text
--name NAME
```
@ -297,17 +275,17 @@ examples: |-
### Specify the name of the node (--node) {#node}
```
```text
--node NODE
```
The `--node` flag specifies the name of the node to be created or modified. If
none is specified, it is the name of the builder it belongs to, with an index
number suffix.
you don't specify a name, the node name defaults to the name of the builder it
belongs to, with an index number suffix.
### Set the platforms supported by the node (--platform) {#platform}
```
```text
--platform PLATFORMS
```
@ -319,7 +297,7 @@ examples: |-
```console
$ docker buildx create --platform linux/amd64
$ docker buildx create --platform linux/arm64,linux/arm/v8
$ docker buildx create --platform linux/arm64,linux/arm/v7
```
### Automatically switch to the newly created builder (--use) {#use}

5
data/buildx/docker_buildx_imagetools.yaml
View File

@ -1,8 +1,9 @@
command: docker buildx imagetools
short: Commands to work on images in registry
long: |-
Imagetools contains commands for working with manifest lists in the registry.
These commands are useful for inspecting multi-platform build results.
The `imagetools` commands contains subcommands for working with manifest lists
in container registries. These commands are useful for inspecting manifests
to check multi-platform configuration and attestations.
pname: docker buildx
plink: docker_buildx.yaml
cname:

10
data/buildx/docker_buildx_imagetools_create.yaml
View File

@ -9,6 +9,16 @@ usage: docker buildx imagetools create [OPTIONS] [SOURCE] [SOURCE...]
pname: docker buildx imagetools
plink: docker_buildx_imagetools.yaml
options:
- option: annotation
value_type: stringArray
default_value: '[]'
description: Add annotation to the image
deprecated: false
hidden: false
experimental: false
experimentalcli: false
kubernetes: false
swarm: false
- option: append
value_type: bool
default_value: "false"

171
data/buildx/docker_buildx_imagetools_inspect.yaml
View File

@ -139,23 +139,93 @@ examples: |-
#### JSON output
A `json` go template func is also available if you want to render fields as
JSON bytes:
A `json` template function is also available if you want to render fields in
JSON format:
```console
$ docker buildx imagetools inspect crazymax/loop --format "{{json .Manifest}}"
$ docker buildx imagetools inspect crazymax/buildkit:attest --format "{{json .Manifest}}"
```
```json
{
"mediaType": "application/vnd.docker.distribution.manifest.v2+json",
"digest": "sha256:a9ca35b798e0b198f9be7f3b8b53982e9a6cf96814cb10d78083f40ad8c127f1",
"size": 949
"schemaVersion": 2,
"mediaType": "application/vnd.oci.image.index.v1+json",
"digest": "sha256:7007b387ccd52bd42a050f2e8020e56e64622c9269bf7bbe257b326fe99daf19",
"size": 855,
"manifests": [
{
"mediaType": "application/vnd.oci.image.manifest.v1+json",
"digest": "sha256:fbd10fe50b4b174bb9ea273e2eb9827fa8bf5c88edd8635a93dc83e0d1aecb55",
"size": 673,
"platform": {
"architecture": "amd64",
"os": "linux"
}
},
{
"mediaType": "application/vnd.oci.image.manifest.v1+json",
"digest": "sha256:a9de632c16998489fd63fbca42a03431df00639cfb2ecb8982bf9984b83c5b2b",
"size": 839,
"annotations": {
"vnd.docker.reference.digest": "sha256:fbd10fe50b4b174bb9ea273e2eb9827fa8bf5c88edd8635a93dc83e0d1aecb55",
"vnd.docker.reference.type": "attestation-manifest"
},
"platform": {
"architecture": "unknown",
"os": "unknown"
}
}
]
}
```
```console
$ docker buildx imagetools inspect crazymax/buildkit:attest --format "{{json .Image}}"
```
```json
{
"created": "2022-12-01T11:46:47.713777178Z",
"architecture": "amd64",
"os": "linux",
"config": {
"Env": [
"PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
],
"Cmd": [
"/bin/sh"
]
},
"rootfs": {
"type": "layers",
"diff_ids": [
"sha256:ded7a220bb058e28ee3254fbba04ca90b679070424424761a53a043b93b612bf",
"sha256:d85d09ab4b4e921666ccc2db8532e857bf3476b7588e52c9c17741d7af14204f"
]
},
"history": [
{
"created": "2022-11-22T22:19:28.870801855Z",
"created_by": "/bin/sh -c #(nop) ADD file:587cae71969871d3c6456d844a8795df9b64b12c710c275295a1182b46f630e7 in / "
},
{
"created": "2022-11-22T22:19:29.008562326Z",
"created_by": "/bin/sh -c #(nop) CMD [\"/bin/sh\"]",
"empty_layer": true
},
{
"created": "2022-12-01T11:46:47.713777178Z",
"created_by": "RUN /bin/sh -c apk add curl # buildkit",
"comment": "buildkit.dockerfile.v0"
}
]
}
```
```console
$ docker buildx imagetools inspect moby/buildkit:master --format "{{json .Manifest}}"
```
```json
{
"schemaVersion": 2,
@ -300,11 +370,13 @@ examples: |-
}
```
Following command provides [SLSA](https://github.com/moby/buildkit/blob/master/docs/attestations/slsa-provenance.md) JSON output:
The following command provides [SLSA](https://github.com/moby/buildkit/blob/master/docs/attestations/slsa-provenance.md)
JSON output:
```console
$ docker buildx imagetools inspect crazymax/buildkit:attest --format "{{json .Provenance}}"
```
```json
{
"SLSA": {
@ -359,11 +431,13 @@ examples: |-
}
```
Following command provides [SBOM](https://github.com/moby/buildkit/blob/master/docs/attestations/sbom.md) JSON output:
The following command provides [SBOM](https://github.com/moby/buildkit/blob/master/docs/attestations/sbom.md)
JSON output:
```console
$ docker buildx imagetools inspect crazymax/buildkit:attest --format "{{json .SBOM}}"
```
```json
{
"SPDX": {
@ -388,6 +462,7 @@ examples: |-
```console
$ docker buildx imagetools inspect crazymax/buildkit:attest --format "{{json .}}"
```
```json
{
"name": "crazymax/buildkit:attest",
@ -456,75 +531,6 @@ examples: |-
"comment": "buildkit.dockerfile.v0"
}
]
},
"Provenance": {
"SLSA": {
"builder": {
"id": ""
},
"buildType": "https://mobyproject.org/buildkit@v1",
"materials": [
{
"uri": "pkg:docker/docker/buildkit-syft-scanner@stable-1",
"digest": {
"sha256": "b45f1d207e16c3a3a5a10b254ad8ad358d01f7ea090d382b95c6b2ee2b3ef765"
}
},
{
"uri": "pkg:docker/alpine@latest?platform=linux%2Famd64",
"digest": {
"sha256": "8914eb54f968791faf6a8638949e480fef81e697984fba772b3976835194c6d4"
}
}
],
"invocation": {
"configSource": {},
"parameters": {
"frontend": "dockerfile.v0",
"locals": [
{
"name": "context"
},
{
"name": "dockerfile"
}
]
},
"environment": {
"platform": "linux/amd64"
}
},
"metadata": {
"buildInvocationID": "02tdha2xkbxvin87mz9drhag4",
"buildStartedOn": "2022-12-01T11:50:07.264704131Z",
"buildFinishedOn": "2022-12-01T11:50:08.243788739Z",
"reproducible": false,
"completeness": {
"parameters": true,
"environment": true,
"materials": false
},
"https://mobyproject.org/buildkit@v1#metadata": {}
}
}
},
"SBOM": {
"SPDX": {
"SPDXID": "SPDXRef-DOCUMENT",
"creationInfo": {
"created": "2022-12-01T11:46:48.063400162Z",
"creators": [
"Tool: syft-v0.60.3",
"Tool: buildkit-1ace2bb",
"Organization: Anchore, Inc"
],
"licenseListVersion": "3.18"
},
"dataLicense": "CC0-1.0",
"documentNamespace": "https://anchore.com/syft/dir/run/src/core-0a4ccc6d-1a72-4c3a-a40e-3df1a2ffca94",
"files": [...],
"spdxVersion": "SPDX-2.2"
}
}
}
```
@ -538,6 +544,7 @@ examples: |-
```console
$ docker buildx imagetools inspect --format '{{json (index .Image "linux/s390x")}}' moby/buildkit:master
```
```json
{
"created": "2022-11-30T17:42:26.414957336Z",
@ -604,15 +611,14 @@ examples: |-
}
```
### Show original, unformatted JSON manifest (--raw) {#raw}
### Show original JSON manifest (--raw) {#raw}
Use the `--raw` option to print the unformatted JSON manifest bytes.
> `jq` is used here to get a better rendering of the output result.
Use the `--raw` option to print the raw JSON manifest.
```console
$ docker buildx imagetools inspect --raw crazymax/loop | jq
$ docker buildx imagetools inspect --raw crazymax/loop
```
```json
{
"mediaType": "application/vnd.docker.distribution.manifest.v2+json",
@ -645,6 +651,7 @@ examples: |-
```console
$ docker buildx imagetools inspect --raw moby/buildkit:master | jq
```
```json
{
"mediaType": "application/vnd.docker.distribution.manifest.list.v2+json",

6
data/buildx/docker_buildx_inspect.yaml
View File

@ -32,7 +32,7 @@ examples: |-
Use the `--bootstrap` option to ensure that the builder is running before
inspecting it. If the driver is `docker-container`, then `--bootstrap` starts
the buildkit container and waits until it is operational. Bootstrapping is
the BuildKit container and waits until it's operational. Bootstrapping is
automatically done during build, and therefore not necessary. The same BuildKit
container is used during the lifetime of the associated builder node (as
displayed in `buildx ls`).
@ -50,7 +50,9 @@ examples: |-
> **Note**
>
> Asterisk `*` next to node build platform(s) indicate they had been set manually during `buildx create`. Otherwise, it had been autodetected.
> The asterisk (`*`) next to node build platform(s) indicate they have been
> manually set during `buildx create`. Otherwise the platforms were
> automatically detected.
```console
$ docker buildx inspect elated_tesla

9
data/buildx/docker_buildx_rm.yaml
View File

@ -87,13 +87,16 @@ examples: |-
### Keep the buildkitd daemon running (--keep-daemon) {#keep-daemon}
Keep the buildkitd daemon running after the buildx context is removed. This is useful when you manage buildkitd daemons and buildx contexts independently.
Currently, only supported by the [`docker-container` and `kubernetes` drivers](buildx_create.md#driver).
Keep the BuildKit daemon running after the buildx context is removed. This is
useful when you manage buildkitd daemons and buildx contexts independently.
Only supported by the
[`docker-container`](/build/drivers/docker-container/)
and [`kubernetes`](/build/drivers/kubernetes/) drivers.
### Keep BuildKit state (--keep-state) {#keep-state}
Keep BuildKit state, so it can be reused by a new builder with the same name.
Currently, only supported by the [`docker-container` driver](buildx_create.md#driver).
Currently, only supported by the [`docker-container` driver](/build/drivers/docker-container/).
deprecated: false
hidden: false
experimental: false

2
data/buildx/docker_buildx_stop.yaml
View File

@ -1,7 +1,7 @@
command: docker buildx stop
short: Stop builder instance
long: |-
Stops the specified or current builder. This will not prevent buildx build to
Stops the specified or current builder. This does not prevent buildx build to
restart the builder. The implementation of stop depends on the driver.
usage: docker buildx stop [NAME]
pname: docker buildx

2
data/buildx/docker_buildx_version.yaml
View File

@ -5,7 +5,7 @@ long: |-
```console
$ docker buildx version
github.com/docker/buildx v0.5.1-docker 11057da37336192bfc57d81e02359ba7ba848e4a
github.com/docker/buildx v0.11.2 9872040b6626fb7d87ef7296fd5b832e8cc2ad17
```
usage: docker buildx version
pname: docker buildx

2
go.mod
View File

@ -6,7 +6,7 @@ toolchain go1.21.1
require (
github.com/compose-spec/compose-spec v0.0.0-20230927132538-f223c5150d5d // indirect
github.com/docker/buildx v0.11.2 // indirect
github.com/docker/buildx v0.12.0 // indirect
github.com/docker/cli v24.0.8-0.20231106123152-48ec4f339e2b+incompatible // indirect
github.com/docker/compose-cli v1.0.35 // indirect
github.com/docker/compose/v2 v2.23.1 // indirect

2
go.sum
View File

@ -48,6 +48,8 @@ github.com/docker/buildx v0.11.1 h1:xfmrAkOJrN+NLRcwhZn1iBgJVAK1dEBEv8lWu1Wxg14=
github.com/docker/buildx v0.11.1/go.mod h1:qAxs3bsJEfVo7DOc9riES/f9Z187CeGM5nLPmadk8AA=
github.com/docker/buildx v0.11.2 h1:R3p9F0gnI4FwvQ0p40UwdX1T4ugap4UWxY3TFHoP4Ws=
github.com/docker/buildx v0.11.2/go.mod h1:CWAABt10iIuGpleypA3103mplDfcGu0A2AvT03xfpTc=
github.com/docker/buildx v0.12.0 h1:pI4jr4SeH9oHa0SmMvH/lz+Rdqkg+dRa9H/1VXbYgws=
github.com/docker/buildx v0.12.0/go.mod h1:SBLnQH9q+77aVvpvS5LLIly9+nHVlwscl5GEegGMD5g=
github.com/docker/cli v24.0.2+incompatible h1:QdqR7znue1mtkXIJ+ruQMGQhpw2JzMJLRXp6zpzF6tM=
github.com/docker/cli v24.0.2+incompatible/go.mod h1:JLrzqnKDaYBop7H2jaqPtU4hHvMKP+vjCwu2uszcLI8=
github.com/docker/cli v24.0.4+incompatible h1:Y3bYF9ekNTm2VFz5U/0BlMdJy73D+Y1iAAZ8l63Ydzw=