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

build: restructure manuals section 

Signed-off-by: David Karlsson <35727626+dvdksn@users.noreply.github.com>
This commit is contained in:
David Karlsson 2024-08-13 12:10:56 +02:00
parent 3d5b40fc20
commit 127bf48d12
77 changed files with 402 additions and 392 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
content/build-cloud/optimization.md
View File

@ -34,7 +34,7 @@ For more information on how to optimize your builds, see
### Dockerignore files ### Dockerignore files
Using a [`.dockerignore` file](/build/building/context/#dockerignore-files), Using a [`.dockerignore` file](/build/concepts/context.md#dockerignore-files),
you can be explicit about which local files you don’t want to include in the you can be explicit about which local files you don’t want to include in the
build context. Files caught by the glob patterns you specify in your build context. Files caught by the glob patterns you specify in your
ignore-file aren't transferred to the remote builder. ignore-file aren't transferred to the remote builder.

14
content/build/_index.md
View File

@ -7,37 +7,37 @@ grid:
description: 'Build and package your application to run it anywhere: locally or description: 'Build and package your application to run it anywhere: locally or
in the cloud.' in the cloud.'
icon: inventory_2 icon: inventory_2
link: /build/building/packaging link: /build/concepts/overview/
- title: Multi-stage builds - title: Multi-stage builds
description: Keep your images small and secure with minimal dependencies. description: Keep your images small and secure with minimal dependencies.
icon: stairs icon: stairs
link: /build/building/multi-stage link: /build/building/multi-stage/
- title: Multi-platform images - title: Multi-platform images
description: Build, push, pull, and run images seamlessly on different computer description: Build, push, pull, and run images seamlessly on different computer
architectures. architectures.
icon: content_copy icon: content_copy
link: /build/building/multi-platform/ link: /build/building/multi-platform/
- title: Architecture - title: BuildKit
description: Explore BuildKit, the open source build engine. description: Explore BuildKit, the open source build engine.
icon: construction icon: construction
link: /build/buildkit/ link: /build/buildkit/
- title: Build drivers - title: Build drivers
description: Configure where and how you run your builds. description: Configure where and how you run your builds.
icon: engineering icon: engineering
link: /build/drivers/ link: /build/builders/drivers/
- title: Exporters - title: Exporters
description: Export any artifact you like, not just Docker images. description: Export any artifact you like, not just Docker images.
icon: output icon: output
link: /build/exporters link: /build/exporters/
- title: Build caching - title: Build caching
description: Avoid unnecessary repetitions of costly operations, such as package description: Avoid unnecessary repetitions of costly operations, such as package
installs. installs.
icon: cycle icon: cycle
link: /build/cache link: /build/cache/
- title: Bake - title: Bake
description: Orchestrate your builds with Bake. description: Orchestrate your builds with Bake.
icon: cake icon: cake
link: /build/bake link: /build/bake/
aliases: aliases:
- /buildx/working-with-buildx/ - /buildx/working-with-buildx/
- /develop/develop-images/build_enhancements/ - /develop/develop-images/build_enhancements/

93
content/build/architecture.md
View File

@ -1,93 +0,0 @@
---
title: Docker Build architecture
description: Learn about Docker Build and its components.
keywords: build, buildkit, buildx, architecture
aliases:
- /build/install-buildx/
---
Docker Build implements a client-server architecture, where:
- Buildx is the client and the user interface for running and managing builds
- BuildKit is the server, or builder, that handles the build execution.
![Build high-level architecture](./images/build-high-level-arch.png)
As of Docker Engine 23.0 and Docker Desktop 4.19, Buildx is the default build
client.
## Buildx
Buildx is a CLI tool that provides a user interface for working with builds.
Buildx is a drop-in replacement for the legacy build client used in earlier
versions of Docker Engine and Docker Desktop. In newer versions of Docker
Desktop and Docker Engine, you're using Buildx by default when you invoke the
`docker build` command. In earlier versions, to build using Buildx you would
use the `docker buildx build` command.
Buildx is more than just an updated `build` command. It also contains utilities
for creating and managing [builders](#builders).
### Install Buildx
Docker Buildx is installed by default with Docker Desktop. Docker Engine
version 23.0 and later requires that you install Buildx from a separate
package. Buildx is included in the Docker Engine installation instructions, see
[Install Docker Engine](../engine/install/index.md).
You can also build the CLI plugin from source, or grab a binary from the GitHub
repository and install it manually. See
[docker/buildx README](https://github.com/docker/buildx#manual-download)
for more information
## Builders
"Builder" is a term used to describe an instance of a BuildKit backend.
A builder may run on the same system as the Buildx client, or it may run
remotely, on a different system. You can run it as a single node, or as a cluster
of nodes. Builder nodes may be containers, virtual machines, or physical machines.
For more information, see [Builders](./builders/index.md).
## BuildKit
BuildKit, or `buildkitd`, is the daemon process that executes the build
workloads.
A build execution starts with the invocation of a `docker build` command.
Buildx interprets your build command and sends a build request to the BuildKit
backend. The build request includes:
- The Dockerfile
- Build arguments
- Export options
- Caching options
BuildKit resolves the build instruction and executes the build steps.
For the duration of the build, Buildx monitors the build status and prints
the progress to the terminal.
If the build requires resources from the client, such as local files or build
secrets, BuildKit requests the resources that it needs from Buildx.
This is one way in which BuildKit is more efficient compared to the legacy
builder it replaces. BuildKit only requests the resources that the build needs,
when they're needed. The legacy builder, in comparison, always takes a copy of
the local filesystem.
Examples of resources that BuildKit can request from Buildx include:
- Local filesystem build contexts
- Build secrets
- SSH sockets
- Registry authentication tokens
For more information about BuildKit, see [BuildKit](buildkit/index.md).
## Example build sequence
The following diagram shows an example build sequence involving Buildx and
BuildKit.
![Buildx and BuildKit sequence diagram](./images/build-execution.png)

6
content/build/builders/_index.md
View File

@ -23,9 +23,9 @@ Docker context, your `default` builder refers to the new Docker context.
## Build drivers ## Build drivers
Buildx implements a concept of [build drivers](../drivers/index.md) to refer to Buildx implements a concept of [build drivers](drivers/_index.md) to refer to
different builder configurations. The default builder created by the daemon different builder configurations. The default builder created by the daemon
uses the [`docker` driver](../drivers/docker.md). uses the [`docker` driver](drivers/docker.md).
Buildx supports the following build drivers: Buildx supports the following build drivers:
@ -69,4 +69,4 @@ selected when you invoke builds.
- For information about how to interact with and manage builders, - For information about how to interact with and manage builders,
see [Manage builders](./manage.md) see [Manage builders](./manage.md)
- To learn about different types of builders, - To learn about different types of builders,
see [Build drivers](../drivers/index.md) see [Build drivers](drivers/index.md)

31
content/build/drivers/_index.md → content/build/builders/drivers/_index.md
View File

@ -6,6 +6,7 @@ aliases:
- /build/buildx/drivers/ - /build/buildx/drivers/
- /build/building/drivers/ - /build/building/drivers/
- /build/buildx/multiple-builders/ - /build/buildx/multiple-builders/
- /build/drivers/
--- ---
Build drivers are configurations for how and where the BuildKit backend runs. Build drivers are configurations for how and where the BuildKit backend runs.
@ -33,7 +34,7 @@ The following table outlines some differences between drivers.
| **BuildKit configuration** | | ✅ | ✅ | Managed externally | | **BuildKit configuration** | | ✅ | ✅ | Managed externally |
\* _The `docker` driver doesn't support all cache export options. \* _The `docker` driver doesn't support all cache export options.
See [Cache storage backends](../cache/backends/_index.md) for more information._ See [Cache storage backends](/build/cache/backends/_index.md) for more information._
## Loading to local image store ## Loading to local image store
@ -42,26 +43,26 @@ aren't automatically loaded into the local image store. If you don't specify an
output, the build result is exported to the build cache only. output, the build result is exported to the build cache only.
To build an image using a non-default driver and load it to the image store, To build an image using a non-default driver and load it to the image store,
use the `--load` flag with the build command: use the `--load` flag with the build command:
```console ```console
$ docker buildx build --load -t <image> --builder=container . $ docker buildx build --load -t <image> --builder=container .
... ...
=> exporting to oci image format 7.7s => exporting to oci image format 7.7s
=> => exporting layers 4.9s => => exporting layers 4.9s
=> => exporting manifest sha256:4e4ca161fa338be2c303445411900ebbc5fc086153a0b846ac12996960b479d3 0.0s => => exporting manifest sha256:4e4ca161fa338be2c303445411900ebbc5fc086153a0b846ac12996960b479d3 0.0s
=> => exporting config sha256:adf3eec768a14b6e183a1010cb96d91155a82fd722a1091440c88f3747f1f53f 0.0s => => exporting config sha256:adf3eec768a14b6e183a1010cb96d91155a82fd722a1091440c88f3747f1f53f 0.0s
=> => sending tarball 2.8s => => sending tarball 2.8s
=> importing to docker => importing to docker
``` ```
With this option, the image is available in the image store after the build finishes: With this option, the image is available in the image store after the build finishes:
```console ```console
$ docker image ls $ docker image ls
REPOSITORY TAG IMAGE ID CREATED SIZE REPOSITORY TAG IMAGE ID CREATED SIZE
<image> latest adf3eec768a1 2 minutes ago 197MB <image> latest adf3eec768a1 2 minutes ago 197MB
``` ```
### Load by default ### Load by default
@ -84,7 +85,7 @@ flag.
Read about each driver: Read about each driver:
- [Docker driver](./docker.md) - [Docker driver](./docker.md)
- [Docker container driver](./docker-container.md) - [Docker container driver](./docker-container.md)
- [Kubernetes driver](./kubernetes.md) - [Kubernetes driver](./kubernetes.md)
- [Remote driver](./remote.md) - [Remote driver](./remote.md)

13
content/build/drivers/docker-container.md → content/build/builders/drivers/docker-container.md
View File

@ -5,6 +5,7 @@ keywords: build, buildx, driver, builder, docker-container
aliases: aliases:
- /build/buildx/drivers/docker-container/ - /build/buildx/drivers/docker-container/
- /build/building/drivers/docker-container/ - /build/building/drivers/docker-container/
- /build/drivers/docker-container/
--- ---
The Docker container driver allows creation of a managed and customizable The Docker container driver allows creation of a managed and customizable
@ -15,7 +16,7 @@ Docker driver. For example:
- Specify custom BuildKit versions to use. - Specify custom BuildKit versions to use.
- Build multi-arch images, see [QEMU](#qemu) - Build multi-arch images, see [QEMU](#qemu)
- Advanced options for [cache import and export](../cache/backends/index.md) - Advanced options for [cache import and export](/build/cache/backends/_index.md)
## Synopsis ## Synopsis
@ -132,14 +133,14 @@ $ docker buildx build \
You can customize the network that the builder container uses. This is useful You can customize the network that the builder container uses. This is useful
if you need to use a specific network for your builds. if you need to use a specific network for your builds.
For example, let's [create a network](../../reference/cli/docker/network/create.md) For example, let's [create a network](/reference/cli/docker/network/create.md)
named `foonet`: named `foonet`:
```console ```console
$ docker network create foonet $ docker network create foonet
``` ```
Now create a [`docker-container` builder](../../reference/cli/docker/buildx/create.md) Now create a [`docker-container` builder](/reference/cli/docker/buildx/create.md)
that will use this network: that will use this network:
```console ```console
@ -149,13 +150,13 @@ $ docker buildx create --use \
--driver-opt "network=foonet" --driver-opt "network=foonet"
``` ```
Boot and [inspect `mybuilder`](../../reference/cli/docker/buildx/inspect.md): Boot and [inspect `mybuilder`](/reference/cli/docker/buildx/inspect.md):
```console ```console
$ docker buildx inspect --bootstrap $ docker buildx inspect --bootstrap
``` ```
[Inspect the builder container](../../reference/cli/docker/inspect.md) [Inspect the builder container](/reference/cli/docker/inspect.md)
and see what network is being used: and see what network is being used:
```console ```console
@ -166,4 +167,4 @@ map[foonet:0xc00018c0c0]
## Further reading ## Further reading
For more information on the Docker container driver, see the For more information on the Docker container driver, see the
[buildx reference](../../reference/cli/docker/buildx/create.md#driver). [buildx reference](/reference/cli/docker/buildx/create.md#driver).

7
content/build/drivers/docker.md → content/build/builders/drivers/docker.md
View File

@ -7,10 +7,11 @@ keywords: build, buildx, driver, builder, docker
aliases: aliases:
- /build/buildx/drivers/docker/ - /build/buildx/drivers/docker/
- /build/building/drivers/docker/ - /build/building/drivers/docker/
- /build/drivers/docker/
--- ---
The Buildx Docker driver is the default driver. It uses the BuildKit server The Buildx Docker driver is the default driver. It uses the BuildKit server
components built directly into the Docker engine. The Docker driver requires no components built directly into the Docker Engine. The Docker driver requires no
configuration. configuration.
Unlike the other drivers, builders using the Docker driver can't be manually Unlike the other drivers, builders using the Docker driver can't be manually
@ -28,7 +29,7 @@ docker buildx build .
It's not possible to configure which BuildKit version to use, or to pass any It's not possible to configure which BuildKit version to use, or to pass any
additional BuildKit parameters to a builder using the Docker driver. The additional BuildKit parameters to a builder using the Docker driver. The
BuildKit version and parameters are preset by the Docker engine internally. BuildKit version and parameters are preset by the Docker Engine internally.
If you need additional configuration and flexibility, consider using the If you need additional configuration and flexibility, consider using the
[Docker container driver](./docker-container.md). [Docker container driver](./docker-container.md).
@ -36,4 +37,4 @@ If you need additional configuration and flexibility, consider using the
## Further reading ## Further reading
For more information on the Docker driver, see the For more information on the Docker driver, see the
[buildx reference](../../reference/cli/docker/buildx/create.md#driver). [buildx reference](/reference/cli/docker/buildx/create.md#driver).

9
content/build/drivers/kubernetes.md → content/build/builders/drivers/kubernetes.md
View File

@ -7,6 +7,7 @@ keywords: build, buildx, driver, builder, kubernetes
aliases: aliases:
- /build/buildx/drivers/kubernetes/ - /build/buildx/drivers/kubernetes/
- /build/building/drivers/kubernetes/ - /build/building/drivers/kubernetes/
- /build/drivers/kubernetes/
--- ---
The Kubernetes driver lets you connect your local development or CI The Kubernetes driver lets you connect your local development or CI
@ -108,7 +109,7 @@ replicas. `sticky` (the default) attempts to connect the same build performed
multiple times to the same node each time, ensuring better use of local cache. multiple times to the same node each time, ensuring better use of local cache.
For more information on scalability, see the options for For more information on scalability, see the options for
[`docker buildx create`](../../reference/cli/docker/buildx/create.md#driver-opt). [`docker buildx create`](/reference/cli/docker/buildx/create.md#driver-opt).
## Node assignment ## Node assignment
@ -143,7 +144,7 @@ $ docker buildx create \
## Multi-platform builds ## Multi-platform builds
The Kubernetes driver has support for creating The Kubernetes driver has support for creating
[multi-platform images](../building/multi-platform.md), [multi-platform images](/build/building/multi-platform.md),
either using QEMU or by leveraging the native architecture of nodes. either using QEMU or by leveraging the native architecture of nodes.
### QEMU ### QEMU
@ -343,9 +344,9 @@ Prerequisites:
--push . --push .
``` ```
That's it! You've now built an image from a Kubernetes pod, using Buildx! That's it: you've now built an image from a Kubernetes pod, using Buildx.
## Further reading ## Further reading
For more information on the Kubernetes driver, see the For more information on the Kubernetes driver, see the
[buildx reference](../../reference/cli/docker/buildx/create.md#driver). [buildx reference](/reference/cli/docker/buildx/create.md#driver).

1
content/build/drivers/remote.md → content/build/builders/drivers/remote.md
View File

@ -7,6 +7,7 @@ keywords: build, buildx, driver, builder, remote
aliases: aliases:
- /build/buildx/drivers/remote/ - /build/buildx/drivers/remote/
- /build/building/drivers/remote/ - /build/building/drivers/remote/
- /build/drivers/remote/
--- ---
The Buildx remote driver allows for more complex custom build workloads, The Buildx remote driver allows for more complex custom build workloads,

8
content/build/builders/manage.md
View File

@ -9,10 +9,10 @@ or [using Docker Desktop](#manage-builders-with-docker-desktop).
## Create a new builder ## Create a new builder
The default builder uses the [`docker` driver](../drivers/docker.md). The default builder uses the [`docker` driver](drivers/docker.md).
You can't manually create new `docker` builders, but you can create builders You can't manually create new `docker` builders, but you can create builders
that use other drivers, such as the that use other drivers, such as the
[`docker-container` driver](../drivers/docker-container.md), [`docker-container` driver](drivers/docker-container.md),
which runs the BuildKit daemon in a container. which runs the BuildKit daemon in a container.
Use the Use the
@ -25,7 +25,7 @@ $ docker buildx create --name=<builder-name>
Buildx uses the `docker-container` driver by default if you omit the `--driver` Buildx uses the `docker-container` driver by default if you omit the `--driver`
flag. For more information about available drivers, see flag. For more information about available drivers, see
[Build drivers](../drivers/index.md). [Build drivers](drivers/_index.md).
## List available builders ## List available builders
@ -42,7 +42,7 @@ my_builder docker-container
``` ```
The asterisk (`*`) next to the builder name indicates the The asterisk (`*`) next to the builder name indicates the
[selected builder](index.md#selected-builder). [selected builder](_index.md#selected-builder).
## Inspect a builder ## Inspect a builder

2
content/build/building/base-images.md
View File

@ -62,7 +62,7 @@ ADD hello /
CMD ["/hello"] CMD ["/hello"]
``` ```
Assuming an executable binary named `hello` exists at the root of the [build context](../../build/building/context.md). Assuming an executable binary named `hello` exists at the root of the [build context](/build/concepts/context.md).
You can build this Docker image using the following `docker build` command: You can build this Docker image using the following `docker build` command:
```console ```console

6
content/build/building/best-practices.md
View File

@ -114,7 +114,7 @@ For example, to exclude all files with the `.md` extension:
``` ```
For information on creating one, see For information on creating one, see
[Dockerignore file](../../build/building/context.md#dockerignore-files). [Dockerignore file](/build/concepts/context.md#dockerignore-files).
## Create ephemeral containers ## Create ephemeral containers
@ -578,8 +578,8 @@ For more information about `ENV`, see [Dockerfile reference for the ENV instruct
### ADD or COPY ### ADD or COPY
`ADD` and `COPY` are functionally similar. `COPY` supports basic copying of `ADD` and `COPY` are functionally similar. `COPY` supports basic copying of
files into the container, from the [build context](../../build/building/context.md) files into the container, from the [build context](/build/concepts/context.md)
or from a stage in a [multi-stage build](../../build/building/multi-stage.md). or from a stage in a [multi-stage build](/build/building/multi-stage.md).
`ADD` supports features for fetching files from remote HTTPS and Git URLs, and `ADD` supports features for fetching files from remote HTTPS and Git URLs, and
extracting tar files automatically when adding files from the build context. extracting tar files automatically when adding files from the build context.

6
content/build/building/multi-platform.md
View File

@ -50,7 +50,7 @@ To build for multiple platforms concurrently, you can:
- **Create a custom builder**: - **Create a custom builder**:
Initialize a [builder](../builders/_index.md) that uses the `docker-container` driver, which supports multi-platform builds. Initialize a [builder](../builders/_index.md) that uses the `docker-container` driver, which supports multi-platform builds.
For more details, see the [`docker-container` driver documentation](../drivers/docker-container.md). For more details, see the [`docker-container` driver documentation](/build/builders/drivers/docker-container.md).
## Strategies ## Strategies
@ -191,9 +191,9 @@ default * docker
``` ```
This displays the default builtin driver, that uses the BuildKit server This displays the default builtin driver, that uses the BuildKit server
components built directly into the Docker Engine, also known as the [`docker` driver](../drivers/docker.md). components built directly into the Docker Engine, also known as the [`docker` driver](/build/builders/drivers/docker.md).
Create a new builder using the [`docker-container` driver](../drivers/docker-container.md) Create a new builder using the [`docker-container` driver](/build/builders/drivers/docker-container.md)
which gives you access to more complex features like multi-platform builds which gives you access to more complex features like multi-platform builds
and the more advanced cache exporters, which are currently unsupported in the and the more advanced cache exporters, which are currently unsupported in the
default `docker` driver: default `docker` driver:

10
content/build/building/variables.md
View File

@ -306,7 +306,7 @@ They're used to configure the Buildx client, or the BuildKit daemon.
| [BUILDKIT_COLORS](#buildkit_colors) | String | Configure text color for the terminal output. | | [BUILDKIT_COLORS](#buildkit_colors) | String | Configure text color for the terminal output. |
| [BUILDKIT_HOST](#buildkit_host) | String | Specify host to use for remote builders. | | [BUILDKIT_HOST](#buildkit_host) | String | Specify host to use for remote builders. |
| [BUILDKIT_PROGRESS](#buildkit_progress) | String | Configure type of progress output. | | [BUILDKIT_PROGRESS](#buildkit_progress) | String | Configure type of progress output. |
| [BUILDKIT_TTY_LOG_LINES](#buildkit_tty_log_lines) | String | Number of log lines (for active steps in tty mode). | | [BUILDKIT_TTY_LOG_LINES](#buildkit_tty_log_lines) | String | Number of log lines (for active steps in TTY mode). |
| [BUILDX_BAKE_GIT_AUTH_HEADER](#buildx_bake_git_auth_header) | String | HTTP authentication scheme for remote Bake files. | | [BUILDX_BAKE_GIT_AUTH_HEADER](#buildx_bake_git_auth_header) | String | HTTP authentication scheme for remote Bake files. |
| [BUILDX_BAKE_GIT_AUTH_TOKEN](#buildx_bake_git_auth_token) | String | HTTP authentication token for remote Bake files. | | [BUILDX_BAKE_GIT_AUTH_TOKEN](#buildx_bake_git_auth_token) | String | HTTP authentication token for remote Bake files. |
| [BUILDX_BAKE_GIT_SSH](#buildx_bake_git_ssh) | String | SSH authentication for remote Bake files. | | [BUILDX_BAKE_GIT_SSH](#buildx_bake_git_ssh) | String | SSH authentication for remote Bake files. |
@ -380,7 +380,7 @@ $ export BUILDKIT_PROGRESS=plain
### BUILDKIT_TTY_LOG_LINES ### BUILDKIT_TTY_LOG_LINES
You can change how many log lines are visible for active steps in tty mode by You can change how many log lines are visible for active steps in TTY mode by
setting `BUILDKIT_TTY_LOG_LINES` to a number (default to `6`). setting `BUILDKIT_TTY_LOG_LINES` to a number (default to `6`).
```console ```console
@ -519,7 +519,7 @@ $ export BUILDX_EXPERIMENTAL=1
{{< introduced buildx 0.10.4 "../release-notes.md#0104" >}} {{< introduced buildx 0.10.4 "../release-notes.md#0104" >}}
When set to true, checks for dirty state in source control information for When set to true, checks for dirty state in source control information for
[provenance attestations](../attestations/slsa-provenance.md). [provenance attestations](/build/metadata/attestations/slsa-provenance.md).
Usage: Usage:
@ -532,7 +532,7 @@ $ export BUILDX_GIT_CHECK_DIRTY=1
{{< introduced buildx 0.10.0 "../release-notes.md#0100" >}} {{< introduced buildx 0.10.0 "../release-notes.md#0100" >}}
When set to false, removes source control information from When set to false, removes source control information from
[provenance attestations](../attestations/slsa-provenance.md). [provenance attestations](/build/metadata/attestations/slsa-provenance.md).
Usage: Usage:
@ -574,7 +574,7 @@ If the repository is in a dirty state, the `revision` gets a `-dirty` suffix.
{{< introduced buildx 0.10.4 "../release-notes.md#0104" >}} {{< introduced buildx 0.10.4 "../release-notes.md#0104" >}}
By default, BuildKit v0.11 and later adds By default, BuildKit v0.11 and later adds
[provenance attestations](../attestations/slsa-provenance.md) to images you [provenance attestations](/build/metadata/attestations/slsa-provenance.md) to images you
build. Set `BUILDX_NO_DEFAULT_ATTESTATIONS=1` to disable the default provenance build. Set `BUILDX_NO_DEFAULT_ATTESTATIONS=1` to disable the default provenance
attestations. attestations.

10
content/build/buildkit/_index.md
View File

@ -16,10 +16,10 @@ It also introduces support for handling more complex scenarios:
- Detect and skip executing unused build stages - Detect and skip executing unused build stages
- Parallelize building independent build stages - Parallelize building independent build stages
- Incrementally transfer only the changed files in your - Incrementally transfer only the changed files in your
[build context](../building/context.md) between builds [build context](../concepts/context.md) between builds
- Detect and skip transferring unused files in your - Detect and skip transferring unused files in your
[build context](../building/context.md) [build context](../concepts/context.md)
- Use [Dockerfile frontend](../dockerfile/frontend.md) implementations with many - Use [Dockerfile frontend](frontend.md) implementations with many
new features new features
- Avoid side effects with rest of the API (intermediate images and containers) - Avoid side effects with rest of the API (intermediate images and containers)
- Prioritize your build cache for automatic pruning - Prioritize your build cache for automatic pruning
@ -67,7 +67,7 @@ work for the features used by their definition.
For example, to build a [Dockerfile](../../reference/dockerfile.md) with For example, to build a [Dockerfile](../../reference/dockerfile.md) with
BuildKit, you would BuildKit, you would
[use an external Dockerfile frontend](../dockerfile/frontend.md). [use an external Dockerfile frontend](frontend.md).
## Getting started ## Getting started
@ -88,7 +88,7 @@ $ DOCKER_BUILDKIT=1 docker build .
> [!NOTE] > [!NOTE]
> >
> [Buildx](../architecture.md#buildx) always uses BuildKit. > Buildx always uses BuildKit.
To use Docker BuildKit by default, edit the Docker daemon configuration in To use Docker BuildKit by default, edit the Docker daemon configuration in
`/etc/docker/daemon.json` as follows, and restart the daemon. `/etc/docker/daemon.json` as follows, and restart the daemon.

2
content/build/buildkit/configure.md
View File

@ -191,7 +191,7 @@ while creating a builder with the [`--config` flags](../../reference/cli/docker/
max-parallelism = 4 max-parallelism = 4
``` ```
Now you can [create a `docker-container` builder](../drivers/docker-container.md) Now you can [create a `docker-container` builder](/build/builders/drivers/docker-container.md)
that will use this BuildKit configuration to limit parallelism. that will use this BuildKit configuration to limit parallelism.
```console ```console

2
content/build/dockerfile/release-notes.md → content/build/buildkit/dockerfile-release-notes.md
View File

@ -4,6 +4,8 @@ description: Release notes for Dockerfile frontend
keywords: build, dockerfile, frontend, release notes keywords: build, dockerfile, frontend, release notes
tags: [Release notes] tags: [Release notes]
toc_max: 2 toc_max: 2
aliases:
- /build/dockerfile/release-notes/
--- ---
This page contains information about the new features, improvements, known This page contains information about the new features, improvements, known

1
content/build/dockerfile/frontend.md → content/build/buildkit/frontend.md
View File

@ -4,6 +4,7 @@ description: Dive deep into the Dockerfile frontend, and learn about custom fron
keywords: build, buildkit, dockerfile, frontend keywords: build, buildkit, dockerfile, frontend
aliases: aliases:
- /build/buildkit/dockerfile-frontend/ - /build/buildkit/dockerfile-frontend/
- /build/dockerfile/frontend/
--- ---
## Dockerfile frontend ## Dockerfile frontend

4
content/build/cache/_index.md vendored
View File

@ -112,7 +112,7 @@ To get started, here are a few tips and tricks:
Be considerate of what files you add to the image. Be considerate of what files you add to the image.
Running a command like `COPY . /src` will copy your entire [build context](../building/context.md) Running a command like `COPY . /src` will copy your entire [build context](../concepts/context.md)
into the image. If you've got logs, package manager artifacts, or even previous into the image. If you've got logs, package manager artifacts, or even previous
build results in your current directory, those will also be copied over. This build results in your current directory, those will also be copied over. This
could make your image larger than it needs to be, especially as those files are could make your image larger than it needs to be, especially as those files are
@ -134,7 +134,7 @@ COPY . /src
``` ```
You can also create a You can also create a
[`.dockerignore` file](../../build/building/context.md#dockerignore-files), [`.dockerignore` file](../concepts/context.md#dockerignore-files),
and use that to specify which files and directories to exclude from the build and use that to specify which files and directories to exclude from the build
context. context.

2
content/build/cache/backends/_index.md vendored
View File

@ -19,7 +19,7 @@ important to keep the runtime of image builds as low as possible.
The default `docker` driver supports the `inline`, `local`, `registry`, and The default `docker` driver supports the `inline`, `local`, `registry`, and
`gha` cache backends, but only if you have enabled the [containerd image store](/desktop/containerd.md). `gha` cache backends, but only if you have enabled the [containerd image store](/desktop/containerd.md).
Other cache backends require you to select a different [driver](../../drivers/_index.md). Other cache backends require you to select a different [driver](/build/builders/drivers/_index.md).
> [!WARNING] > [!WARNING]
> >

2
content/build/cache/backends/azblob.md vendored
View File

@ -16,7 +16,7 @@ The `azblob` cache store uploads your resulting build cache to
This cache storage backend is not supported with the default `docker` driver. This cache storage backend is not supported with the default `docker` driver.
To use this feature, create a new builder using a different driver. See To use this feature, create a new builder using a different driver. See
[Build drivers](../../drivers/_index.md) for more information. [Build drivers](/build/builders/drivers/_index.md) for more information.
## Synopsis ## Synopsis

2
content/build/cache/backends/gha.md vendored
View File

@ -20,7 +20,7 @@ use case falls within the
This cache storage backend is not supported with the default `docker` driver. This cache storage backend is not supported with the default `docker` driver.
To use this feature, create a new builder using a different driver. See To use this feature, create a new builder using a different driver. See
[Build drivers](../../drivers/_index.md) for more information. [Build drivers](/build/builders/drivers/_index.md) for more information.
## Synopsis ## Synopsis

2
content/build/cache/backends/registry.md vendored
View File

@ -20,7 +20,7 @@ everything that the inline cache can do, and more:
This cache storage backend is not supported with the default `docker` driver. This cache storage backend is not supported with the default `docker` driver.
To use this feature, create a new builder using a different driver. See To use this feature, create a new builder using a different driver. See
[Build drivers](../../drivers/_index.md) for more information. [Build drivers](/build/builders/drivers/_index.md) for more information.
## Synopsis ## Synopsis

2
content/build/cache/backends/s3.md vendored
View File

@ -17,7 +17,7 @@ or other S3-compatible services, such as [MinIO](https://min.io/).
This cache storage backend is not supported with the default `docker` driver. This cache storage backend is not supported with the default `docker` driver.
To use this feature, create a new builder using a different driver. See To use this feature, create a new builder using a different driver. See
[Build drivers](../../drivers/_index.md) for more information. [Build drivers](/build/builders/drivers/_index.md) for more information.
## Synopsis ## Synopsis

4
content/build/cache/garbage-collection.md vendored
View File

@ -18,10 +18,10 @@ parameters by defining garbage collection policies.
## Configuration ## Configuration
Depending on the [driver](../drivers/index.md) used by your builder instance, Depending on the [driver](../builders/drivers/_index.md) used by your builder instance,
the garbage collection will use a different configuration file. the garbage collection will use a different configuration file.
If you're using the [`docker` driver](../drivers/docker.md), garbage collection If you're using the [`docker` driver](../builders/drivers/docker.md), garbage collection
can be configured in the [Docker Daemon configuration](../../reference/cli/dockerd.md#daemon-configuration-file). can be configured in the [Docker Daemon configuration](../../reference/cli/dockerd.md#daemon-configuration-file).
file: file:

2
content/build/ci/_index.md
View File

@ -54,5 +54,5 @@ that you can use for this purpose.
Docker maintains a set of official GitHub Actions that you can use to build, Docker maintains a set of official GitHub Actions that you can use to build,
annotate, and push container images on the GitHub Actions platform. See annotate, and push container images on the GitHub Actions platform. See
[Introduction to GitHub Actions](./github-actions/index.md) to learn more and [Introduction to GitHub Actions](github-actions/_index.md) to learn more and
get started. get started.

2
content/build/ci/github-actions/annotations.md
View File

@ -105,7 +105,7 @@ jobs:
## Configure annotation level ## Configure annotation level
By default, annotations are placed on image manifests. To configure the By default, annotations are placed on image manifests. To configure the
[annotation level](../../building/annotations.md#specify-annotation-level), set [annotation level](../../metadata/annotations.md#specify-annotation-level), set
the `DOCKER_METADATA_ANNOTATIONS_LEVELS` environment variable on the the `DOCKER_METADATA_ANNOTATIONS_LEVELS` environment variable on the
`metadata-action` step to a comma-separated list of all the levels that you `metadata-action` step to a comma-separated list of all the levels that you
want to annotate. For example, setting `DOCKER_METADATA_ANNOTATIONS_LEVELS` to want to annotate. For example, setting `DOCKER_METADATA_ANNOTATIONS_LEVELS` to

2
content/build/ci/github-actions/attestations.md
View File

@ -5,7 +5,7 @@ keywords: ci, github actions, gha, buildkit, buildx, attestations, sbom, provena
--- ---
Software Bill of Material (SBOM) and provenance Software Bill of Material (SBOM) and provenance
[attestations](../../attestations/_index.md) add metadata about the contents of [attestations](../../metadata/attestations/_index.md) add metadata about the contents of
your image, and how it was built. your image, and how it was built.
Attestations are supported with version 4 and later of the Attestations are supported with version 4 and later of the

10
content/build/ci/github-actions/configure-builder.md
View File

@ -65,7 +65,7 @@ Logs will be available at the end of a job:
## BuildKit Daemon configuration ## BuildKit Daemon configuration
You can provide a [BuildKit configuration](../../buildkit/toml-configuration.md) You can provide a [BuildKit configuration](../../buildkit/toml-configuration.md)
to your builder if you're using the [`docker-container` driver](../../drivers/docker-container.md) to your builder if you're using the [`docker-container` driver](/build/builders/drivers/docker-container.md)
(default) with the `config` or `config-inline` inputs: (default) with the `config` or `config-inline` inputs:
### Registry mirror ### Registry mirror
@ -145,7 +145,7 @@ fields:
| `buildkitd-flags` | String | [Flags for buildkitd](../../../reference/cli/docker/buildx/create.md#buildkitd-flags) daemon | | `buildkitd-flags` | String | [Flags for buildkitd](../../../reference/cli/docker/buildx/create.md#buildkitd-flags) daemon |
| `platforms` | String | Fixed [platforms](../../../reference/cli/docker/buildx/create.md#platform) for the node. If not empty, values take priority over the detected ones. | | `platforms` | String | Fixed [platforms](../../../reference/cli/docker/buildx/create.md#platform) for the node. If not empty, values take priority over the detected ones. |
Here is an example using remote nodes with the [`remote` driver](../../drivers/remote.md) Here is an example using remote nodes with the [`remote` driver](/build/builders/drivers/remote.md)
and [TLS authentication](#tls-authentication): and [TLS authentication](#tls-authentication):
```yaml ```yaml
@ -187,7 +187,7 @@ using SSH or TLS.
### SSH authentication ### SSH authentication
To be able to connect to an SSH endpoint using the [`docker-container` driver](../../drivers/docker-container.md), To be able to connect to an SSH endpoint using the [`docker-container` driver](/build/builders/drivers/docker-container.md),
you have to set up the SSH private key and configuration on the GitHub Runner: you have to set up the SSH private key and configuration on the GitHub Runner:
```yaml ```yaml
@ -215,7 +215,7 @@ jobs:
### TLS authentication ### TLS authentication
You can also [set up a remote BuildKit instance](../../drivers/remote.md#example-remote-buildkit-in-docker-container) You can also [set up a remote BuildKit instance](/build/builders/drivers/remote.md#example-remote-buildkit-in-docker-container)
using the remote driver. To ease the integration in your workflow, you can use using the remote driver. To ease the integration in your workflow, you can use
an environment variables that sets up authentication using the BuildKit client an environment variables that sets up authentication using the BuildKit client
certificates for the `tcp://`: certificates for the `tcp://`:
@ -288,7 +288,7 @@ some packages may be particularly resource-intensive to build and require more
compute. Or they require a builder equipped with a particular capability or compute. Or they require a builder equipped with a particular capability or
hardware. hardware.
For more information about remote builder, see [`remote` driver](../../drivers/remote.md) For more information about remote builder, see [`remote` driver](/build/builders/drivers/remote.md)
and the [append builder nodes example](#append-additional-nodes-to-the-builder). and the [append builder nodes example](#append-additional-nodes-to-the-builder).
```yaml ```yaml

2
content/build/ci/github-actions/named-contexts.md
View File

@ -89,7 +89,7 @@ jobs:
## Using with a container builder ## Using with a container builder
As shown in the previous section we are not using the default As shown in the previous section we are not using the default
[`docker-container` driver](../../drivers/docker-container.md) for building with [`docker-container` driver](../../builders/drivers/docker-container.md) for building with
named contexts. That's because this driver can't load an image from the Docker named contexts. That's because this driver can't load an image from the Docker
store as it's isolated. To solve this problem you can use a [local registry](local-registry.md) store as it's isolated. To solve this problem you can use a [local registry](local-registry.md)
to push your base image in your workflow: to push your base image in your workflow:

2
content/build/building/context.md → content/build/concepts/context.md
View File

@ -2,6 +2,8 @@
title: Build context title: Build context
description: Learn how to use the build context to access files from your Dockerfile description: Learn how to use the build context to access files from your Dockerfile
keywords: build, buildx, buildkit, context, git, tarball, stdin keywords: build, buildx, buildkit, context, git, tarball, stdin
aliases:
- /build/building/context/
--- ---
The `docker build` and `docker buildx build` commands build Docker images from The `docker build` and `docker buildx build` commands build Docker images from

13
content/build/building/packaging.md → content/build/concepts/dockerfile.md
View File

@ -1,9 +1,10 @@
--- ---
title: Packaging your software title: Dockerfile overview
description: Learn about Dockerfiles and how to use them with Docker Images to build and package your software description: Learn about Dockerfiles and how to use them with Docker Images to build and package your software
keywords: build, buildx, buildkit, getting started, dockerfile keywords: build, buildx, buildkit, getting started, dockerfile
aliases: aliases:
- /build/hellobuild/ - /build/hellobuild/
- /build/building/packaging/
--- ---
## Dockerfile ## Dockerfile
@ -113,7 +114,7 @@ Here's a breakdown of what this Dockerfile does:
The first line to add to a Dockerfile is a [`# syntax` parser directive](../../reference/dockerfile.md#syntax). The first line to add to a Dockerfile is a [`# syntax` parser directive](../../reference/dockerfile.md#syntax).
While optional, this directive instructs the Docker builder what syntax to use While optional, this directive instructs the Docker builder what syntax to use
when parsing the Dockerfile, and allows older Docker versions with [BuildKit enabled](../buildkit/index.md#getting-started) when parsing the Dockerfile, and allows older Docker versions with [BuildKit enabled](../buildkit/index.md#getting-started)
to use a specific [Dockerfile frontend](../dockerfile/frontend.md) before to use a specific [Dockerfile frontend](../buildkit/frontend.md) before
starting the build. [Parser directives](../../reference/dockerfile.md#parser-directives) starting the build. [Parser directives](../../reference/dockerfile.md#parser-directives)
must appear before any other comment, whitespace, or Dockerfile instruction in must appear before any other comment, whitespace, or Dockerfile instruction in
your Dockerfile, and should be the first line in Dockerfiles. your Dockerfile, and should be the first line in Dockerfiles.
@ -276,11 +277,3 @@ $ docker run -p 127.0.0.1:8000:8000 test:latest
This publishes the container's port 8000 to `http://localhost:8000` on the This publishes the container's port 8000 to `http://localhost:8000` on the
Docker host. Docker host.
## Other resources
If you are interested in examples in other languages, such as Go, check out
our [language-specific guides](../../language/index.md) in the Guides section.
For more information about building, including advanced use cases and patterns,
refer to the [Build with Docker](../guide/index.md) guide.

72
content/build/concepts/overview.md Normal file
View File

@ -0,0 +1,72 @@
---
title: Docker Build Overview
description: Learn about Docker Build and its components.
keywords: build, buildkit, buildx, architecture
aliases:
- /build/install-buildx/
- /build/architecture/
---
Docker Build implements a client-server architecture, where:
- Client: Buildx is the client and the user interface for running and managing builds.
- Server: BuildKit is the server, or builder, that handles the build execution.
When you invoke a build, the Buildx client sends a build request to the
BuildKit backend. BuildKit resolves the build instructions and executes the
build steps. The build output is either sent back to the client or uploaded to
a registry, such as Docker Hub.
Buildx and BuildKit are both installed with Docker Desktop and Docker Engine
out-of-the-box. When you invoke the `docker build` command, you're using Buildx
to run a build using the default BuildKit bundled with Docker.
## Buildx
Buildx is the CLI tool that you use to run builds. The `docker build` command
is a wrapper around Buildx. When you invoke `docker build`, Buildx interprets
the build options and sends a build request to the BuildKit backend.
The Buildx client can do more than just run builds. You can also use Buildx to
create and manage BuildKit backends, referred to as builders. It also supports
features for managing images in registries, and for running multiple builds
concurrently.
Docker Buildx is installed by default with Docker Desktop. You can also build
the CLI plugin from source, or grab a binary from the GitHub repository and
install it manually. See [Buildx README](https://github.com/docker/buildx#manual-download)
on GitHub for more information.
## BuildKit
BuildKit is the daemon process that executes the build workloads.
A build execution starts with the invocation of a `docker build` command.
Buildx interprets your build command and sends a build request to the BuildKit
backend. The build request includes:
- The Dockerfile
- Build arguments
- Export options
- Caching options
BuildKit resolves the build instructions and executes the build steps. While
BuildKit is executing the build, Buildx monitors the build status and prints
the progress to the terminal.
If the build requires resources from the client, such as local files or build
secrets, BuildKit requests the resources that it needs from Buildx.
This is one way in which BuildKit is more efficient compared to the legacy
builder used in earlier versions of Docker. BuildKit only requests the
resources that the build needs when they're needed. The legacy builder, in
comparison, always takes a copy of the local filesystem.
Examples of resources that BuildKit can request from Buildx include:
- Local filesystem build contexts
- Build secrets
- SSH sockets
- Registry authentication tokens
For more information about BuildKit, see [BuildKit](/build/buildkit/_index.md).

8
content/build/building/opentelemetry.md → content/build/debug/opentelemetry.md
View File

@ -2,6 +2,8 @@
title: OpenTelemetry support title: OpenTelemetry support
description: Analyze telemetry data for builds description: Analyze telemetry data for builds
keywords: build, buildx buildkit, opentelemetry keywords: build, buildx buildkit, opentelemetry
aliases:
- /build/building/opentelemetry/
--- ---
Both Buildx and BuildKit support [OpenTelemetry](https://opentelemetry.io/). Both Buildx and BuildKit support [OpenTelemetry](https://opentelemetry.io/).
@ -16,8 +18,8 @@ First create a Jaeger container:
$ docker run -d --name jaeger -p "6831:6831/udp" -p "16686:16686" --restart unless-stopped jaegertracing/all-in-one $ docker run -d --name jaeger -p "6831:6831/udp" -p "16686:16686" --restart unless-stopped jaegertracing/all-in-one
``` ```
Then [create a `docker-container` builder](../drivers/docker-container.md) Then [create a `docker-container` builder](/build/builders/drivers/docker-container.md)
that will use the Jaeger instance via the `JAEGER_TRACE` env var: that will use the Jaeger instance via the `JAEGER_TRACE` environment variable:
```console ```console
$ docker buildx create --use \ $ docker buildx create --use \
@ -27,7 +29,7 @@ $ docker buildx create --use \
--driver-opt "env.JAEGER_TRACE=localhost:6831" --driver-opt "env.JAEGER_TRACE=localhost:6831"
``` ```
Boot and [inspect `mybuilder`](../../reference/cli/docker/buildx/inspect.md): Boot and [inspect `mybuilder`](/reference/cli/docker/buildx/inspect.md):
```console ```console
$ docker buildx inspect --bootstrap $ docker buildx inspect --bootstrap

2
content/build/exporters/oci-docker.md
View File

@ -12,7 +12,7 @@ The `oci` exporter outputs the build result into an
tarball. The `docker` exporter behaves the same way, except it exports a Docker tarball. The `docker` exporter behaves the same way, except it exports a Docker
image layout instead. image layout instead.
The [`docker` driver](../drivers/docker.md) doesn't support these exporters. You The [`docker` driver](/build/builders/drivers/docker.md) doesn't support these exporters. You
must use `docker-container` or some other driver if you want to generate these must use `docker-container` or some other driver if you want to generate these
outputs. outputs.

12
content/build/guide/next-steps.md
View File

@ -10,16 +10,16 @@ that Docker provides.
If you would like to continue learning about Docker build, consider exploring If you would like to continue learning about Docker build, consider exploring
the following resources: the following resources:
- [BuildKit](../buildkit/index.md): deep-dive into the open source build engine - [BuildKit](../buildkit/_index.md): deep-dive into the open source build engine
that powers your Docker builds that powers your Docker builds
- [Drivers](../drivers/index.md): configure for how and where your Docker builds - [Drivers](../builders/drivers/_index.md): configure for how and where your Docker builds
run run
- [Exporters](../exporters/index.md): save your build results to different - [Exporters](../exporters/_index.md): save your build results to different
output formats output formats
- [Bake](../bake/index.md): orchestrate your build workflows - [Bake](../bake/_index.md): orchestrate your build workflows
- [Attestations](../attestations/index.md): annotate your build artifacts with - [Attestations](../metadata/attestations/_index.md): annotate your build artifacts with
metadata metadata
- [Continuous integration](../ci/index.md): run Docker builds in CI - [GitHub Actions](../ci/github-actions/_index.md): run Docker builds in CI
## Feedback ## Feedback

BIN
content/build/images/build-execution.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 374 KiB

BIN
content/build/images/build-high-level-arch.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 88 KiB

BIN
content/build/images/build_summary_error.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 7.8 KiB

16
content/build/images/continuous-integration.svg Normal file
View File

File diff suppressed because one or more lines are too long
Side by Side

After

Width:  |  Height:  |  Size: 13 KiB

BIN
content/build/images/gha_build_summary.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 124 KiB

20
content/build/building/annotations.md → content/build/metadata/annotations.md
View File

@ -2,6 +2,8 @@
title: Annotations title: Annotations
description: Annotations specify additional metadata about OCI images description: Annotations specify additional metadata about OCI images
keywords: build, buildkit, annotations, metadata keywords: build, buildkit, annotations, metadata
aliases:
- /build/building/annotations/
--- ---
Annotations provide descriptive metadata for images. Use annotations to record Annotations provide descriptive metadata for images. Use annotations to record
@ -41,7 +43,7 @@ manifest or index.
> The Docker Engine image store doesn't support loading images with > The Docker Engine image store doesn't support loading images with
> annotations. To build with annotations, make sure to push the image directly > annotations. To build with annotations, make sure to push the image directly
> to a registry, using the `--push` CLI flag or the > to a registry, using the `--push` CLI flag or the
> [registry exporter](../exporters/image-registry.md). > [registry exporter](/build/exporters/image-registry.md).
To specify annotations on the command line, use the `--annotation` flag for the To specify annotations on the command line, use the `--annotation` flag for the
`docker build` command: `docker build` command:
@ -50,7 +52,7 @@ To specify annotations on the command line, use the `--annotation` flag for the
$ docker build --push --annotation "foo=bar" . $ docker build --push --annotation "foo=bar" .
``` ```
If you're using [Bake](../bake/_index.md), you can use the `annotations` If you're using [Bake](/build/bake/_index.md), you can use the `annotations`
attribute to specify annotations for a given target: attribute to specify annotations for a given target:
```hcl ```hcl
@ -61,12 +63,12 @@ target "default" {
``` ```
For examples on how to add annotations to images built with GitHub Actions, see For examples on how to add annotations to images built with GitHub Actions, see
[Add image annotations with GitHub Actions](../ci/github-actions/annotations.md) [Add image annotations with GitHub Actions](/build/ci/github-actions/annotations.md)
You can also add annotations to an image created using `docker buildx You can also add annotations to an image created using `docker buildx
imagetools create`. This command only supports adding annotations to an index imagetools create`. This command only supports adding annotations to an index
or manifest descriptors, see or manifest descriptors, see
[CLI reference](../../reference/cli/docker/buildx/imagetools/create.md#annotations). [CLI reference](/reference/cli/docker/buildx/imagetools/create.md#annotations).
## Inspect annotations ## Inspect annotations
@ -195,19 +197,19 @@ $ docker build --tag <IMAGE> --push --annotation "manifest[linux/amd64]:foo=bar"
Related articles: Related articles:
- [Add image annotations with GitHub Actions](../ci/github-actions/annotations.md) - [Add image annotations with GitHub Actions](/build/ci/github-actions/annotations.md)
- [Annotations OCI specification][specification] - [Annotations OCI specification][specification]
Reference information: Reference information:
- [`docker buildx build --annotation`](../../reference/cli/docker/buildx/build.md#annotation) - [`docker buildx build --annotation`](/reference/cli/docker/buildx/build.md#annotation)
- [Bake file reference: `annotations`](../bake/reference.md#targetannotations) - [Bake file reference: `annotations`](/build/bake/reference.md#targetannotations)
- [`docker buildx imagetools create --annotation`](../../reference/cli/docker/buildx/imagetools/create.md#annotation) - [`docker buildx imagetools create --annotation`](/reference/cli/docker/buildx/imagetools/create.md#annotation)
<!-- links --> <!-- links -->
[specification]: https://github.com/opencontainers/image-spec/blob/main/annotations.md [specification]: https://github.com/opencontainers/image-spec/blob/main/annotations.md
[attestations]: ../attestations/_index.md [attestations]: /build/metadata/attestations/_index.md
[config]: https://github.com/opencontainers/image-spec/blob/main/config.md [config]: https://github.com/opencontainers/image-spec/blob/main/config.md
[descriptors]: https://github.com/opencontainers/image-spec/blob/main/descriptor.md [descriptors]: https://github.com/opencontainers/image-spec/blob/main/descriptor.md
[indexes]: https://github.com/opencontainers/image-spec/blob/main/image-index.md [indexes]: https://github.com/opencontainers/image-spec/blob/main/image-index.md

6
content/build/attestations/_index.md → content/build/metadata/attestations/_index.md
View File

@ -4,6 +4,8 @@ keywords: build, attestations, sbom, provenance, metadata
description: | description: |
Introduction to SBOM and provenance attestations with Docker Build, Introduction to SBOM and provenance attestations with Docker Build,
what they are, and why they exist what they are, and why they exist
aliases:
- /build/attestations/
--- ---
Build attestations describe how an image was built, and what it contains. The Build attestations describe how an image was built, and what it contains. The
@ -58,13 +60,13 @@ $ docker buildx build --sbom=true --provenance=true .
> >
> - Use a `docker-container` driver with the `--push` flag to push the image to > - Use a `docker-container` driver with the `--push` flag to push the image to
> a registry directly. > a registry directly.
> - Enable the [containerd image store](../../desktop/containerd.md). > - Enable the [containerd image store](/desktop/containerd.md).
> [!NOTE] > [!NOTE]
> >
> Provenance attestations are enabled by default, with the `mode=min` option. > Provenance attestations are enabled by default, with the `mode=min` option.
> You can disable provenance attestations using the `--provenance=false` flag, > You can disable provenance attestations using the `--provenance=false` flag,
> or by setting the [`BUILDX_NO_DEFAULT_ATTESTATIONS`](../building/variables.md#buildx_no_default_attestations) environment variable. > or by setting the [`BUILDX_NO_DEFAULT_ATTESTATIONS`](/build/building/variables.md#buildx_no_default_attestations) environment variable.
> >
> Using the `--provenance=true` flag attaches provenance attestations with `mode=max` > Using the `--provenance=true` flag attaches provenance attestations with `mode=max`
> by default. See [Provenance attestation](./slsa-provenance.md) for more details. > by default. See [Provenance attestation](./slsa-provenance.md) for more details.

8
content/build/attestations/sbom.md → content/build/metadata/attestations/sbom.md
View File

@ -4,6 +4,8 @@ keywords: build, attestations, sbom, spdx, metadata, packages
description: | description: |
SBOM build attestations describe the contents of your image, SBOM build attestations describe the contents of your image,
and the packages used to build it. and the packages used to build it.
aliases:
- /build/attestations/sbom/
--- ---
Software Bill of Materials (SBOM) attestations describe what software artifacts Software Bill of Materials (SBOM) attestations describe what software artifacts
@ -38,7 +40,7 @@ $ docker buildx build --tag <namespace>/<image>:<version> \
Alternatively, you can use the shorthand `--sbom=true` option instead of `--attest type=sbom`. Alternatively, you can use the shorthand `--sbom=true` option instead of `--attest type=sbom`.
For an example on how to add SBOM attestations with GitHub Actions, see For an example on how to add SBOM attestations with GitHub Actions, see
[Add attestations with GitHub Actions](../ci/github-actions/attestations.md). [Add attestations with GitHub Actions](/build/ci/github-actions/attestations.md).
## Verify SBOM attestations ## Verify SBOM attestations
@ -69,7 +71,7 @@ exist in the build context. This may cause you to overlook vulnerabilities in
those dependencies, which could impact the security of your final build those dependencies, which could impact the security of your final build
artifacts. artifacts.
For instance, you might use [multi-stage builds](../building/multi-stage.md), For instance, you might use [multi-stage builds](/build/building/multi-stage.md),
with a `FROM scratch` stanza for your final stage to achieve a smaller image size. with a `FROM scratch` stanza for your final stage to achieve a smaller image size.
```dockerfile ```dockerfile
@ -173,7 +175,7 @@ sbom.spdx.json
## Inspecting SBOMs ## Inspecting SBOMs
To explore created SBOMs exported through the `image` exporter, you can use To explore created SBOMs exported through the `image` exporter, you can use
[`imagetools inspect`](../../reference/cli/docker/buildx/imagetools/inspect.md). [`imagetools inspect`](/reference/cli/docker/buildx/imagetools/inspect.md).
Using the `--format` option, you can specify a template for the output. All Using the `--format` option, you can specify a template for the output. All
SBOM-related data is available under the `.SBOM` attribute. For example, to get SBOM-related data is available under the `.SBOM` attribute. For example, to get

10
content/build/attestations/slsa-provenance.md → content/build/metadata/attestations/slsa-provenance.md
View File

@ -3,6 +3,8 @@ title: Provenance attestations
keywords: build, attestations, provenance, slsa, git, metadata keywords: build, attestations, provenance, slsa, git, metadata
description: > description: >
Provenance build attestations describe how and where your image was built. Provenance build attestations describe how and where your image was built.
aliases:
- /build/attestations/slsa-provenance/
--- ---
The provenance attestations include facts about the build process, including The provenance attestations include facts about the build process, including
@ -34,7 +36,7 @@ Alternatively, you can use the shorthand `--provenance=true` option instead of `
To specify the `mode` parameter using the shorthand option, use: `--provenance=mode=max`. To specify the `mode` parameter using the shorthand option, use: `--provenance=mode=max`.
For an example on how to add provenance attestations with GitHub Actions, see For an example on how to add provenance attestations with GitHub Actions, see
[Add attestations with GitHub Actions](../ci/github-actions/attestations.md). [Add attestations with GitHub Actions](/build/ci/github-actions/attestations.md).
## Mode ## Mode
@ -141,17 +143,17 @@ detailed information for analysis.
> [!WARNING] > [!WARNING]
> >
> Note that `mode=max` exposes the values of > Note that `mode=max` exposes the values of
> [build arguments](../../reference/cli/docker/buildx/build.md#build-arg). > [build arguments](/reference/cli/docker/buildx/build.md#build-arg).
> >
> If you're misusing build arguments to pass credentials, authentication > If you're misusing build arguments to pass credentials, authentication
> tokens, or other secrets, you should refactor your build to pass the secrets using > tokens, or other secrets, you should refactor your build to pass the secrets using
> [secret mounts](../../reference/cli/docker/buildx/build.md#secret) instead. > [secret mounts](/reference/cli/docker/buildx/build.md#secret) instead.
> Secret mounts don't leak outside of the build and are never included in provenance attestations. > Secret mounts don't leak outside of the build and are never included in provenance attestations.
## Inspecting Provenance ## Inspecting Provenance
To explore created Provenance exported through the `image` exporter, you can To explore created Provenance exported through the `image` exporter, you can
use [`imagetools inspect`](../../reference/cli/docker/buildx/imagetools/inspect.md). use [`imagetools inspect`](/reference/cli/docker/buildx/imagetools/inspect.md).
Using the `--format` option, you can specify a template for the output. All Using the `--format` option, you can specify a template for the output. All
provenance-related data is available under the `.Provenance` attribute. For provenance-related data is available under the `.Provenance` attribute. For

12
content/build/release-notes.md
View File

@ -96,7 +96,7 @@ The full release note for this release is available
- [`--call=targets`](/reference/cli/docker/buildx/build.md#call-targets): Show all available targets and their descriptions. - [`--call=targets`](/reference/cli/docker/buildx/build.md#call-targets): Show all available targets and their descriptions.
- New `--prefer-index` flag has been added to the `docker buildx imagetools create` command to control the behavior of creating image out of one single-platform image manifest. [docker/buildx#2482](https://github.com/docker/buildx/pull/2482/) - New `--prefer-index` flag has been added to the `docker buildx imagetools create` command to control the behavior of creating image out of one single-platform image manifest. [docker/buildx#2482](https://github.com/docker/buildx/pull/2482/)
- The [`kubernetes` driver](/build/drivers/kubernetes.md) now supports a `timeout` option for configuring deployment timeout. [docker/buildx#2492](https://github.com/docker/buildx/pull/2492/) - The [`kubernetes` driver](/build/builders/drivers/kubernetes.md) now supports a `timeout` option for configuring deployment timeout. [docker/buildx#2492](https://github.com/docker/buildx/pull/2492/)
- New metrics definitions have been added for build warning types. [docker/buildx#2482](https://github.com/docker/buildx/pull/2482/), [docker/buildx#2507](https://github.com/docker/buildx/pull/2507/) - New metrics definitions have been added for build warning types. [docker/buildx#2482](https://github.com/docker/buildx/pull/2482/), [docker/buildx#2507](https://github.com/docker/buildx/pull/2507/)
- The [`buildx prune`](/reference/cli/docker/buildx/prune.md) and [`buildx du`](/reference/cli/docker/buildx/du.md) commands now support negative and prefix filters. [docker/buildx#2473](https://github.com/docker/buildx/pull/2473/) - The [`buildx prune`](/reference/cli/docker/buildx/prune.md) and [`buildx du`](/reference/cli/docker/buildx/du.md) commands now support negative and prefix filters. [docker/buildx#2473](https://github.com/docker/buildx/pull/2473/)
- Building Compose files with Bake now supports passing SSH forwarding configuration. [docker/buildx#2445](https://github.com/docker/buildx/pull/2445/) - Building Compose files with Bake now supports passing SSH forwarding configuration. [docker/buildx#2445](https://github.com/docker/buildx/pull/2445/)
@ -127,7 +127,7 @@ The full release note for this release is available
[docker/buildx#2363](https://github.com/docker/buildx/pull/2363) [docker/buildx#2363](https://github.com/docker/buildx/pull/2363)
- New `default-load` driver option for the `docker-container`, `remote`, and `kubernetes` drivers to load build results to the Docker Engine image store by default. - New `default-load` driver option for the `docker-container`, `remote`, and `kubernetes` drivers to load build results to the Docker Engine image store by default.
[docker/buildx#2259](https://github.com/docker/buildx/pull/2259) [docker/buildx#2259](https://github.com/docker/buildx/pull/2259)
- Add `requests.ephemeral-storage`, `limits.ephemeral-storage` and `schedulername` options to the [`kubernetes` driver](./drivers/kubernetes.md). - Add `requests.ephemeral-storage`, `limits.ephemeral-storage` and `schedulername` options to the [`kubernetes` driver](/build/builders/drivers/kubernetes.md).
[docker/buildx#2370](https://github.com/docker/buildx/pull/2370), [docker/buildx#2370](https://github.com/docker/buildx/pull/2370),
[docker/buildx#2415](https://github.com/docker/buildx/pull/2415) [docker/buildx#2415](https://github.com/docker/buildx/pull/2415)
- Add `indexof` function for `docker-bake.hcl` files. - Add `indexof` function for `docker-bake.hcl` files.
@ -494,8 +494,8 @@ The full release note for this release is available
shorthands `--sbom` and `--provenance`, for adding attestations for your shorthands `--sbom` and `--provenance`, for adding attestations for your
current build. [docker/buildx#1412](https://github.com/docker/buildx/issues/1412) current build. [docker/buildx#1412](https://github.com/docker/buildx/issues/1412)
[docker/buildx#1475](https://github.com/docker/buildx/issues/1475) [docker/buildx#1475](https://github.com/docker/buildx/issues/1475)
- `--attest type=sbom` or `--sbom=true` adds [SBOM attestations](attestations/sbom.md). - `--attest type=sbom` or `--sbom=true` adds [SBOM attestations](/build/metadata/attestations/sbom.md).
- `--attest type=provenance` or `--provenance=true` adds [SLSA provenance attestation](attestations/slsa-provenance.md). - `--attest type=provenance` or `--provenance=true` adds [SLSA provenance attestation](/build/metadata/attestations/slsa-provenance.md).
- When creating OCI images, a minimal provenance attestation is included - When creating OCI images, a minimal provenance attestation is included
with the image by default. with the image by default.
- When building with BuildKit that supports provenance attestations Buildx will - When building with BuildKit that supports provenance attestations Buildx will
@ -533,7 +533,7 @@ The full release note for this release is available
[docker/buildx#1454](https://github.com/docker/buildx/issues/1454), [docker/buildx#1454](https://github.com/docker/buildx/issues/1454),
[docker/buildx#1455](https://github.com/docker/buildx/issues/1455), [docker/buildx#1455](https://github.com/docker/buildx/issues/1455),
[docker/buildx#1345](https://github.com/docker/buildx/issues/1345) [docker/buildx#1345](https://github.com/docker/buildx/issues/1345)
- Adding extra hosts with [Docker driver](drivers/docker.md) now supports - Adding extra hosts with [Docker driver](/build/builders/drivers/docker.md) now supports
Docker-specific `host-gateway` special value. [docker/buildx#1446](https://github.com/docker/buildx/issues/1446) Docker-specific `host-gateway` special value. [docker/buildx#1446](https://github.com/docker/buildx/issues/1446)
- [OCI exporter](exporters/oci-docker.md) now supports `tar=false` option for - [OCI exporter](exporters/oci-docker.md) now supports `tar=false` option for
exporting OCI format directly in a directory. [docker/buildx#1420](https://github.com/docker/buildx/issues/1420) exporting OCI format directly in a directory. [docker/buildx#1420](https://github.com/docker/buildx/issues/1420)
@ -575,7 +575,7 @@ For more details, see the complete release notes in the [Buildx GitHub repositor
### New ### New
- Support for a new [`remote` driver](drivers/remote.md) that you can use - Support for a new [`remote` driver](/build/builders/drivers/remote.md) that you can use
to connect to any already running BuildKit instance. to connect to any already running BuildKit instance.
[docker/buildx#1078](https://github.com/docker/buildx/issues/1078), [docker/buildx#1078](https://github.com/docker/buildx/issues/1078),
[docker/buildx#1093](https://github.com/docker/buildx/issues/1093), [docker/buildx#1093](https://github.com/docker/buildx/issues/1093),

8
content/desktop/use-desktop/builds.md
View File

@ -66,7 +66,7 @@ platform:
![Platform filter](../images/build-ui-platform-menu.webp?w=400) ![Platform filter](../images/build-ui-platform-menu.webp?w=400)
The **Source details** section shows information about the frontend The **Source details** section shows information about the frontend
[frontend](../../build/dockerfile/frontend.md) and, if available, [frontend](../../build/buildkit/frontend.md) and, if available,
the source code repository used for the build. the source code repository used for the build.
### Build timing ### Build timing
@ -93,7 +93,7 @@ operations are defined as follows:
| HTTP | Remote artifact downloads using `ADD`. | | HTTP | Remote artifact downloads using `ADD`. |
| Git | Same as **HTTP** but for Git URLs. | | Git | Same as **HTTP** but for Git URLs. |
| Result exports | Time spent exporting the build results. | | Result exports | Time spent exporting the build results. |
| SBOM | Time spent generating the [SBOM attestation](../../build/attestations/sbom.md). | | SBOM | Time spent generating the [SBOM attestation](../../build/metadata/attestations/sbom.md). |
| Idle | Idle time for build workers, which can happen if you have configured a [max parallelism limit](../../build/buildkit/configure.md#max-parallelism). | | Idle | Idle time for build workers, which can happen if you have configured a [max parallelism limit](../../build/buildkit/configure.md#max-parallelism). |
### Build dependencies ### Build dependencies
@ -123,7 +123,7 @@ including image manifest details, attestations, and build traces.
Attestations are metadata records attached to a container image. Attestations are metadata records attached to a container image.
The metadata describes something about the image, The metadata describes something about the image,
for example how it was built or what packages it contains. for example how it was built or what packages it contains.
For more information about attestations, see [Build attestations](../../build/attestations/_index.md). For more information about attestations, see [Build attestations](../../build/metadata/attestations/_index.md).
Build traces capture information about the build execution steps in Buildx and Build traces capture information about the build execution steps in Buildx and
BuildKit. The traces are available in two formats: OTLP and Jaeger. You can BuildKit. The traces are available in two formats: OTLP and Jaeger. You can
@ -161,7 +161,7 @@ Now you can analyze the build trace using the Jaeger UI:
### Dockerfile source and errors ### Dockerfile source and errors
When inspecting a successful completed build or an ongoing active build, When inspecting a successful completed build or an ongoing active build,
the **Source** tab shows the [frontend](../../build/dockerfile/frontend.md) the **Source** tab shows the [frontend](../../build/buildkit/frontend.md)
used to create the build. used to create the build.
If the build failed, an **Error** tab displays instead of the **Source** tab. If the build failed, an **Error** tab displays instead of the **Source** tab.

4
content/guides/docker-concepts/building-images/build-tag-and-publish-an-image.md
View File

@ -22,7 +22,7 @@ Most often, images are built using a Dockerfile. The most basic `docker build` c
docker build . docker build .
``` ```
The final `.` in the command provides the path or URL to the [build context](https://docs.docker.com/build/building/context/#what-is-a-build-context). At this location, the builder will find the `Dockerfile` and other referenced files. The final `.` in the command provides the path or URL to the [build context](https://docs.docker.com/build/concepts/context/#what-is-a-build-context). At this location, the builder will find the `Dockerfile` and other referenced files.
When you run a build, the builder pulls the base image, if needed, and then runs the instructions specified in the Dockerfile. When you run a build, the builder pulls the base image, if needed, and then runs the instructions specified in the Dockerfile.
@ -212,7 +212,7 @@ Now that you have an image built, it's time to push the image to a registry.
To learn more about building, tagging, and publishing images, visit the following resources: To learn more about building, tagging, and publishing images, visit the following resources:
* [What is a build context?](/build/building/context/#what-is-a-build-context) * [What is a build context?](/build/concepts/context/#what-is-a-build-context)
* [docker build reference](/engine/reference/commandline/image_build/) * [docker build reference](/engine/reference/commandline/image_build/)
* [docker image tag reference](/engine/reference/commandline/image_tag/) * [docker image tag reference](/engine/reference/commandline/image_tag/)
* [docker push reference](/engine/reference/commandline/image_push/) * [docker push reference](/engine/reference/commandline/image_push/)

2
content/guides/docker-concepts/building-images/multi-stage-builds.md
View File

@ -2,6 +2,8 @@
title: Multi-stage builds title: Multi-stage builds
keywords: concepts, build, images, container, docker desktop keywords: concepts, build, images, container, docker desktop
description: This concept page will teach you about the purpose of the multi-stage build and its benefits description: This concept page will teach you about the purpose of the multi-stage build and its benefits
aliases:
- /build/guides/multi-stage/
--- ---
{{< youtube-embed vR185cjwxZ8 >}} {{< youtube-embed vR185cjwxZ8 >}}

2
content/includes/desktop-builders-setting.md
View File

@ -54,7 +54,7 @@ the build cache is also removed, along with the builder.
### Stop and start a builder ### Stop and start a builder
Builders that use the Builders that use the
[`docker-container` driver](/build/drivers/docker-container/) [`docker-container` driver](/build/builders/drivers/docker-container/)
run the BuildKit daemon in a container. run the BuildKit daemon in a container.
You can start and stop the BuildKit container using the drop-down menu. You can start and stop the BuildKit container using the drop-down menu.

2
content/language/cpp/configure-ci-cd.md
View File

@ -119,7 +119,7 @@ Save the workflow file and run the job.
In this section, you learned how to set up a GitHub Actions workflow for your C++ application. In this section, you learned how to set up a GitHub Actions workflow for your C++ application.
Related information: Related information:
- [Introduction to GitHub Actions](../../build/ci/github-actions/index.md) - [Introduction to GitHub Actions](../../build/ci/github-actions/_index.md)
- [Workflow syntax for GitHub Actions](https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions) - [Workflow syntax for GitHub Actions](https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions)
## Next steps ## Next steps

2
content/language/dotnet/configure-ci-cd.md
View File

@ -134,7 +134,7 @@ Save the workflow file and run the job.
In this section, you learned how to set up a GitHub Actions workflow for your application. In this section, you learned how to set up a GitHub Actions workflow for your application.
Related information: Related information:
- [Introduction to GitHub Actions](../../build/ci/github-actions/index.md) - [Introduction to GitHub Actions](../../build/ci/github-actions/_index.md)
- [Workflow syntax for GitHub Actions](https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions) - [Workflow syntax for GitHub Actions](https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions)
## Next steps ## Next steps

2
content/language/golang/_index.md
View File

@ -30,7 +30,7 @@ the [Go website](https://golang.org/) is a great place to explore,
so *go* (pun intended) check it out! so *go* (pun intended) check it out!
You also must know some basic [Docker concepts](../../guides/docker-concepts/the-basics/what-is-a-container.md) as well as to You also must know some basic [Docker concepts](../../guides/docker-concepts/the-basics/what-is-a-container.md) as well as to
be at least vaguely familiar with the [Dockerfile format](../../build/building/packaging.md#dockerfile). be at least vaguely familiar with the [Dockerfile format](../../build/concepts/dockerfile.md).
Your Docker set-up must have BuildKit enabled. BuildKit is enabled by default for all users on [Docker Desktop](../../desktop/index.md). Your Docker set-up must have BuildKit enabled. BuildKit is enabled by default for all users on [Docker Desktop](../../desktop/index.md).
If you have installed Docker Desktop, you don’t have to manually enable BuildKit. If you are running Docker on Linux, If you have installed Docker Desktop, you don’t have to manually enable BuildKit. If you are running Docker on Linux,

2
content/language/golang/configure-ci-cd.md
View File

@ -119,7 +119,7 @@ Save the workflow file and run the job.
In this section, you learned how to set up a GitHub Actions workflow for your application. In this section, you learned how to set up a GitHub Actions workflow for your application.
Related information: Related information:
- [Introduction to GitHub Actions](../../build/ci/github-actions/index.md) - [Introduction to GitHub Actions](../../build/ci/github-actions/_index.md)
- [Workflow syntax for GitHub Actions](https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions) - [Workflow syntax for GitHub Actions](https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions)
## Next steps ## Next steps

2
content/language/java/configure-ci-cd.md
View File

@ -129,7 +129,7 @@ Save the workflow file and run the job.
In this section, you learned how to set up a GitHub Actions workflow for your application. In this section, you learned how to set up a GitHub Actions workflow for your application.
Related information: Related information:
- [Introduction to GitHub Actions](../../build/ci/github-actions/index.md) - [Introduction to GitHub Actions](../../build/ci/github-actions/_index.md)
- [Workflow syntax for GitHub Actions](https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions) - [Workflow syntax for GitHub Actions](https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions)
## Next steps ## Next steps

2
content/language/nodejs/configure-ci-cd.md
View File

@ -126,7 +126,7 @@ Save the workflow file and run the job.
In this section, you learned how to set up a GitHub Actions workflow for your Node.js application. In this section, you learned how to set up a GitHub Actions workflow for your Node.js application.
Related information: Related information:
- [Introduction to GitHub Actions](../../build/ci/github-actions/index.md) - [Introduction to GitHub Actions](../../build/ci/github-actions/_index.md)
- [Workflow syntax for GitHub Actions](https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions) - [Workflow syntax for GitHub Actions](https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions)
## Next steps ## Next steps

2
content/language/php/configure-ci-cd.md
View File

@ -134,7 +134,7 @@ Save the workflow file and run the job.
In this section, you learned how to set up a GitHub Actions workflow for your application. In this section, you learned how to set up a GitHub Actions workflow for your application.
Related information: Related information:
- [Introduction to GitHub Actions](../../build/ci/github-actions/index.md) - [Introduction to GitHub Actions](../../build/ci/github-actions/_index.md)
- [Workflow syntax for GitHub Actions](https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions) - [Workflow syntax for GitHub Actions](https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions)
## Next steps ## Next steps

2
content/language/python/configure-ci-cd.md
View File

@ -119,7 +119,7 @@ Save the workflow file and run the job.
In this section, you learned how to set up a GitHub Actions workflow for your Python application. In this section, you learned how to set up a GitHub Actions workflow for your Python application.
Related information: Related information:
- [Introduction to GitHub Actions](../../build/ci/github-actions/index.md) - [Introduction to GitHub Actions](../../build/ci/github-actions/_index.md)
- [Workflow syntax for GitHub Actions](https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions) - [Workflow syntax for GitHub Actions](https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions)
## Next steps ## Next steps

2
content/language/r/configure-ci-cd.md
View File

@ -119,7 +119,7 @@ Save the workflow file and run the job.
In this section, you learned how to set up a GitHub Actions workflow for your R application. In this section, you learned how to set up a GitHub Actions workflow for your R application.
Related information: Related information:
- [Introduction to GitHub Actions](../../build/ci/github-actions/index.md) - [Introduction to GitHub Actions](../../build/ci/github-actions/_index.md)
- [Workflow syntax for GitHub Actions](https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions) - [Workflow syntax for GitHub Actions](https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions)
## Next steps ## Next steps

2
content/language/ruby/configure-ci-cd.md
View File

@ -119,7 +119,7 @@ Save the workflow file and run the job.
In this section, you learned how to set up a GitHub Actions workflow for your Ruby on Rails application. In this section, you learned how to set up a GitHub Actions workflow for your Ruby on Rails application.
Related information: Related information:
- [Introduction to GitHub Actions](../../build/ci/github-actions/index.md) - [Introduction to GitHub Actions](../../build/ci/github-actions/_index.md)
- [Workflow syntax for GitHub Actions](https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions) - [Workflow syntax for GitHub Actions](https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions)
## Next steps ## Next steps

2
content/language/rust/configure-ci-cd.md
View File

@ -118,7 +118,7 @@ Save the workflow file and run the job.
In this section, you learned how to set up a GitHub Actions workflow for your Rust application. In this section, you learned how to set up a GitHub Actions workflow for your Rust application.
Related information: Related information:
- [Introduction to GitHub Actions](../../build/ci/github-actions/index.md) - [Introduction to GitHub Actions](../../build/ci/github-actions/_index.md)
- [Workflow syntax for GitHub Actions](https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions) - [Workflow syntax for GitHub Actions](https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions)
## Next steps ## Next steps

2
content/scout/concepts/sbom.md
View File

@ -35,7 +35,7 @@ An SBOM typically includes the following information:
Docker Scout uses SBOMs to determine the components that are used in a Docker Docker Scout uses SBOMs to determine the components that are used in a Docker
image. When you analyze an image, Docker Scout will either use the SBOM that is image. When you analyze an image, Docker Scout will either use the SBOM that is
attached to the image (using [attestations](/build/attestations/_index.md)), or attached to the image (using [attestations](/build/metadata/attestations/_index.md)), or
it will generate an SBOM on the fly by analyzing the contents of the image. it will generate an SBOM on the fly by analyzing the contents of the image.
The SBOM is cross-referenced with the [advisory database](/scout/deep-dive/advisory-db-sources.md) The SBOM is cross-referenced with the [advisory database](/scout/deep-dive/advisory-db-sources.md)

2
content/scout/deep-dive/data-handling.md
View File

@ -85,7 +85,7 @@ Docker Scout platform; it's only used to run the analysis.
### Provenance ### Provenance
For images with [provenance attestations](/build/attestations/slsa-provenance.md), For images with [provenance attestations](/build/metadata/attestations/slsa-provenance.md),
Docker Scout stores the following data in addition to the SBOM: Docker Scout stores the following data in addition to the SBOM:
- Materials - Materials

4
content/scout/explore/analysis.md
View File

@ -75,7 +75,7 @@ analysis is activated.
``` ```
Building with the `--provenance=true` and `--sbom=true` flags attaches Building with the `--provenance=true` and `--sbom=true` flags attaches
[build attestations](/build/attestations/_index.md) to the image. Docker [build attestations](/build/metadata/attestations/_index.md) to the image. Docker
Scout uses attestations to provide more fine-grained analysis results. Scout uses attestations to provide more fine-grained analysis results.
> [!NOTE] > [!NOTE]
@ -231,7 +231,7 @@ Image analysis on the Docker Scout platform, and analysis triggered by backgroun
indexing in Docker Desktop, has an image file size limit of 10 GB (uncompressed). indexing in Docker Desktop, has an image file size limit of 10 GB (uncompressed).
To analyze images larger than that, you can either: To analyze images larger than that, you can either:
- Attach [SBOM attestations](/build/attestations/sbom.md) at build-time - Attach [SBOM attestations](/build/metadata/attestations/sbom.md) at build-time
- Use the [CLI](#cli) to analyze the image locally - Use the [CLI](#cli) to analyze the image locally
Images analyzed locally with the CLI and images with SBOM attestations Images analyzed locally with the CLI and images with SBOM attestations

2
content/scout/how-tos/view-create-sboms.md
View File

@ -62,7 +62,7 @@ reference](/reference/cli/docker/scout/sbom.md).
## Attach as build attestation {#attest} ## Attach as build attestation {#attest}
You can generate the SBOM and attach it to the image at build-time as an You can generate the SBOM and attach it to the image at build-time as an
[attestation](/build/attestations/_index.md). BuildKit provides a default [attestation](/build/metadata/attestations/_index.md). BuildKit provides a default
SBOM generator which is different from what Docker Scout uses. SBOM generator which is different from what Docker Scout uses.
You can configure BuildKit to use the Docker Scout SBOM generator You can configure BuildKit to use the Docker Scout SBOM generator
using the `--attest` flag for the `docker build` command. using the `--attest` flag for the `docker build` command.

2
content/scout/integrations/code-quality/sonarqube.md
View File

@ -32,7 +32,7 @@ annotations, to link image repositories with SonarQube analysis results.
To integrate Docker Scout with SonarQube, ensure that: To integrate Docker Scout with SonarQube, ensure that:
- Your image repository is [integrated with Docker Scout](../_index.md#container-registries). - Your image repository is [integrated with Docker Scout](../_index.md#container-registries).
- Your images are built with [provenance attestations](../../../build/attestations/slsa-provenance.md), - Your images are built with [provenance attestations](../../../build/metadata/attestations/slsa-provenance.md),
or the `org.opencontainers.image.revision` annotation, or the `org.opencontainers.image.revision` annotation,
containing information about the Git repository. containing information about the Git repository.

2
content/scout/integrations/source-code-management/github.md
View File

@ -19,7 +19,7 @@ When you enable the GitHub integration, Docker Scout can make a direct link
between the image analysis results and the source. between the image analysis results and the source.
When analyzing your image, Docker Scout checks for [provenance When analyzing your image, Docker Scout checks for [provenance
attestations](../../../build/attestations/slsa-provenance.md) to detect the attestations](../../../build/metadata/attestations/slsa-provenance.md) to detect the
location of the source code repository for the image. If the source location is location of the source code repository for the image. If the source location is
found, and you've enabled the GitHub app, Docker Scout parses the Dockerfile found, and you've enabled the GitHub app, Docker Scout parses the Dockerfile
used to create the image. used to create the image.

10
content/scout/policy/_index.md
View File

@ -158,8 +158,8 @@ For more information on policy configuration, see [Configure policies](./configu
### Supply chain attestations ### Supply chain attestations
The **Supply chain attestations** policy requires that your artifacts have The **Supply chain attestations** policy requires that your artifacts have
[SBOM](../../build/attestations/sbom.md) and [SBOM](../../build/metadata/attestations/sbom.md) and
[provenance](../../build/attestations/slsa-provenance.md) attestations. [provenance](../../build/metadata/attestations/slsa-provenance.md) attestations.
This policy is violated if an artifact lacks either an SBOM attestation or a This policy is violated if an artifact lacks either an SBOM attestation or a
provenance attestation with max mode. To ensure compliance, provenance attestation with max mode. To ensure compliance,
@ -171,7 +171,7 @@ $ docker buildx build --provenance=true --sbom=true -t <IMAGE> --push .
For more information about For more information about
building with attestations, see building with attestations, see
[Attestations](../../build/attestations/_index.md). [Attestations](../../build/metadata/attestations/_index.md).
### Default non-root user ### Default non-root user
@ -329,7 +329,7 @@ SonarQube evaluates your source code against the quality gates you've defined
in SonarQube. Docker Scout surfaces the SonarQube assessment as a Docker Scout in SonarQube. Docker Scout surfaces the SonarQube assessment as a Docker Scout
policy. policy.
Docker Scout uses [provenance](../../build/attestations/slsa-provenance.md) Docker Scout uses [provenance](../../build/metadata/attestations/slsa-provenance.md)
attestations or the `org.opencontainers.image.revision` OCI annotation to link attestations or the `org.opencontainers.image.revision` OCI annotation to link
SonarQube analysis results with container images. In addition to enabling the SonarQube analysis results with container images. In addition to enabling the
SonarQube integration, you must also make sure that your images have either the SonarQube integration, you must also make sure that your images have either the
@ -361,6 +361,6 @@ This "no data" state occurs when:
of date of date
To make sure that Docker Scout always knows about your base image, you can To make sure that Docker Scout always knows about your base image, you can
attach [provenance attestations](../../build/attestations/slsa-provenance.md) attach [provenance attestations](../../build/metadata/attestations/slsa-provenance.md)
at build-time. Docker Scout uses provenance attestations to find out the base at build-time. Docker Scout uses provenance attestations to find out the base
image version. image version.

4
content/scout/policy/remediation.md
View File

@ -72,7 +72,7 @@ information available about the image.
### No provenance attestations ### No provenance attestations
For Docker Scout to be able to evaluate this policy, you must add [provenance For Docker Scout to be able to evaluate this policy, you must add [provenance
attestations](../../build/attestations/slsa-provenance.md) to your image. If attestations](../../build/metadata/attestations/slsa-provenance.md) to your image. If
your image doesn't have provenance attestations, compliance is undeterminable. your image doesn't have provenance attestations, compliance is undeterminable.
<!-- <!--
@ -143,4 +143,4 @@ The recommendations available in the remediation side panel helps guide you to
what action you need to take to address the issues. For example, if your image what action you need to take to address the issues. For example, if your image
has a provenance attestation, but the attestation doesn't contain enough has a provenance attestation, but the attestation doesn't contain enough
information, you're recommended to re-build your image with information, you're recommended to re-build your image with
[`mode=max`](../../build/attestations/slsa-provenance.md#max) provenance. [`mode=max`](../../build/metadata/attestations/slsa-provenance.md#max) provenance.

2
content/security/for-admins/hardened-desktop/enhanced-container-isolation/faq.md
View File

@ -73,7 +73,7 @@ with Docker Desktop 4.30, it protects such containers, except for Docker Desktop
on WSL 2 (Windows hosts). on WSL 2 (Windows hosts).
Note that ECI always protects containers used by `docker build`, when using the Note that ECI always protects containers used by `docker build`, when using the
[docker-container build driver](/build/drivers/_index.md), since Docker [docker-container build driver](/build/builders/drivers/_index.md), since Docker
Desktop 4.19 and on all supported platforms (Windows with WSL 2 or Hyper-V, Mac, Desktop 4.19 and on all supported platforms (Windows with WSL 2 or Hyper-V, Mac,
and Linux). and Linux).

2
data/buildx/docker_buildx_bake.yaml
View File

@ -304,7 +304,7 @@ examples: |-
> **Note** > **Note**
> >
> Build record [provenance](/build/attestations/slsa-provenance/#provenance-attestation-example) > Build record [provenance](/build/metadata/attestations/slsa-provenance/#provenance-attestation-example)
> (`buildx.build.provenance`) includes minimal provenance by default. Set the > (`buildx.build.provenance`) includes minimal provenance by default. Set the
> `BUILDX_METADATA_PROVENANCE` environment variable to customize this behavior: > `BUILDX_METADATA_PROVENANCE` environment variable to customize this behavior:
> * `min` sets minimal provenance (default). > * `min` sets minimal provenance (default).

26
data/buildx/docker_buildx_build.yaml
View File

@ -623,7 +623,7 @@ examples: |-
--attest=type=provenance,... --attest=type=provenance,...
``` ```
Create [image attestations](/build/attestations/). Create [image attestations](/build/metadata/attestations/).
BuildKit currently supports: BuildKit currently supports:
- `sbom` - Software Bill of Materials. - `sbom` - Software Bill of Materials.
@ -631,7 +631,7 @@ examples: |-
Use `--attest=type=sbom` to generate an SBOM for an image at build-time. Use `--attest=type=sbom` to generate an SBOM for an image at build-time.
Alternatively, you can use the [`--sbom` shorthand](#sbom). Alternatively, you can use the [`--sbom` shorthand](#sbom).
For more information, see [here](/build/attestations/sbom/). For more information, see [here](/build/metadata/attestations/sbom/).
- `provenance` - SLSA Provenance - `provenance` - SLSA Provenance
@ -641,7 +641,7 @@ examples: |-
By default, a minimal provenance attestation will be created for the build By default, a minimal provenance attestation will be created for the build
result, which will only be attached for images pushed to registries. result, which will only be attached for images pushed to registries.
For more information, see [here](/build/attestations/slsa-provenance/). For more information, see [here](/build/metadata/attestations/slsa-provenance/).
### Allow extra privileged entitlement (--allow) {#allow} ### Allow extra privileged entitlement (--allow) {#allow}
@ -1062,7 +1062,7 @@ examples: |-
> **Note** > **Note**
> >
> Build record [provenance](/build/attestations/slsa-provenance/#provenance-attestation-example) > Build record [provenance](/build/metadata/attestations/slsa-provenance/#provenance-attestation-example)
> (`buildx.build.provenance`) includes minimal provenance by default. Set the > (`buildx.build.provenance`) includes minimal provenance by default. Set the
> `BUILDX_METADATA_PROVENANCE` environment variable to customize this behavior: > `BUILDX_METADATA_PROVENANCE` environment variable to customize this behavior:
> >
@ -1070,6 +1070,12 @@ examples: |-
> - `max` sets full provenance. > - `max` sets full provenance.
> - `disabled`, `false` or `0` doesn't set any provenance. > - `disabled`, `false` or `0` doesn't set any provenance.
> **Note**
>
> Build warnings (`buildx.build.warnings`) are not included by default. Set the
> `BUILDX_METADATA_WARNINGS` environment variable to `1` or `true` to
> include them.
### Set the networking mode for the RUN instructions during build (--network) {#network} ### Set the networking mode for the RUN instructions during build (--network) {#network}
Available options for the networking mode are: Available options for the networking mode are:
@ -1080,12 +1086,6 @@ examples: |-
Find more details in the [Dockerfile reference](/reference/dockerfile/#run---network). Find more details in the [Dockerfile reference](/reference/dockerfile/#run---network).
> **Note**
>
> Build warnings (`buildx.build.warnings`) are not included by default. Set the
> `BUILDX_METADATA_WARNINGS` environment variable to `1` or `true` to
> include them.
### Ignore build cache for specific stages (--no-cache-filter) {#no-cache-filter} ### Ignore build cache for specific stages (--no-cache-filter) {#no-cache-filter}
The `--no-cache-filter` lets you specify one or more stages of a multi-stage The `--no-cache-filter` lets you specify one or more stages of a multi-stage
@ -1148,7 +1148,7 @@ examples: |-
``` ```
Sets the export action for the build result. The default output, when using the Sets the export action for the build result. The default output, when using the
`docker` [build driver](/build/drivers/), is a container `docker` [build driver](/build/builders/drivers/), is a container
image exported to the local image store. The `--output` flag makes this step image exported to the local image store. The `--output` flag makes this step
configurable allows export of results directly to the client's filesystem, an configurable allows export of results directly to the client's filesystem, an
OCI image tarball, a registry, and more. OCI image tarball, a registry, and more.
@ -1356,7 +1356,7 @@ examples: |-
to using the containerd image store. to using the containerd image store.
For more information about provenance attestations, see For more information about provenance attestations, see
[here](/build/attestations/slsa-provenance/). [here](/build/metadata/attestations/slsa-provenance/).
### Push the build result to a registry (--push) {#push} ### Push the build result to a registry (--push) {#push}
@ -1378,7 +1378,7 @@ examples: |-
to a registry if you use the default image store. Alternatively, you can switch to a registry if you use the default image store. Alternatively, you can switch
to using the containerd image store. to using the containerd image store.
For more information, see [here](/build/attestations/sbom/). For more information, see [here](/build/metadata/attestations/sbom/).
### Secret to expose to the build (--secret) {#secret} ### Secret to expose to the build (--secret) {#secret}

10
data/buildx/docker_buildx_create.yaml
View File

@ -227,7 +227,7 @@ examples: |-
* `kubernetes` * `kubernetes`
* `remote` * `remote`
For more information about build drivers, see [here](/build/drivers/). For more information about build drivers, see [here](/build/builders/drivers/).
#### `docker` driver #### `docker` driver
@ -274,10 +274,10 @@ examples: |-
For information about available driver options, refer to the detailed For information about available driver options, refer to the detailed
documentation for the specific driver: documentation for the specific driver:
* [`docker` driver](/build/drivers/docker/) * [`docker` driver](/build/builders/drivers/docker/)
* [`docker-container` driver](/build/drivers/docker-container/) * [`docker-container` driver](/build/builders/drivers/docker-container/)
* [`kubernetes` driver](/build/drivers/kubernetes/) * [`kubernetes` driver](/build/builders/drivers/kubernetes/)
* [`remote` driver](/build/drivers/remote/) * [`remote` driver](/build/builders/drivers/remote/)
### Remove a node from a builder (--leave) {#leave} ### Remove a node from a builder (--leave) {#leave}

2
data/engine-cli/docker_image_build.yaml
View File

@ -48,7 +48,7 @@ long: |-
When using the legacy builder, it's therefore extra important that you When using the legacy builder, it's therefore extra important that you
carefully consider what files you include in the context you specify. Use a carefully consider what files you include in the context you specify. Use a
[`.dockerignore`](/build/building/context/#dockerignore-files) [`.dockerignore`](/build/concepts/context/#dockerignore-files)
file to exclude files and directories that you don't require in your build from file to exclude files and directories that you don't require in your build from
being sent as part of the build context. being sent as part of the build context.

2
data/redirects.yml
View File

@ -243,7 +243,7 @@
- /go/dockerfile-user-best-practices/ - /go/dockerfile-user-best-practices/
"/build/building/best-practices/#apt-get": "/build/building/best-practices/#apt-get":
- /go/dockerfile-aptget-best-practices/ - /go/dockerfile-aptget-best-practices/
"/build/building/context/#dockerignore-files": "/build/concepts/context/#dockerignore-files":
- /go/build-context-dockerignore/ - /go/build-context-dockerignore/
"/compose/compose-file": "/compose/compose-file":
- /go/compose-spec-reference/ - /go/compose-spec-reference/

160
data/toc.yaml
View File

@ -1880,28 +1880,26 @@ Manuals:
section: section:
- path: /build/ - path: /build/
title: Overview title: Overview
- path: /build/architecture/ - sectiontitle: Core concepts
title: Architecture section:
- sectiontitle: Building images - path: /build/concepts/overview/
title: Build overview
- path: /build/concepts/dockerfile/
title: Dockerfile
- path: /build/concepts/context/
title: Build context
- sectiontitle: Building
section: section:
- path: /build/building/packaging/
title: Packaging your software
- path: /build/building/context/
title: Context
- path: /build/building/multi-stage/ - path: /build/building/multi-stage/
title: Multi-stage builds title: Multi-stage builds
- path: /build/building/variables/ - path: /build/building/variables/
title: Variables title: Variables
- path: /build/building/best-practices/
title: Best practices
- path: /build/building/multi-platform/ - path: /build/building/multi-platform/
title: Multi-platform images title: Multi-platform images
- path: /build/building/secrets/ - path: /build/building/secrets/
title: Build secrets title: Build secrets
- path: /build/building/annotations/ - path: /build/building/best-practices/
title: Annotations title: Best practices
- path: /build/building/opentelemetry/
title: OpenTelemetry support
- path: /build/building/base-images/ - path: /build/building/base-images/
title: Base images title: Base images
- path: /build/checks/ - path: /build/checks/
@ -1912,52 +1910,18 @@ Manuals:
title: Builders overview title: Builders overview
- path: /build/builders/manage/ - path: /build/builders/manage/
title: Manage builders title: Manage builders
- sectiontitle: Drivers - sectiontitle: Build drivers
section: section:
- path: /build/drivers/ - path: /build/builders/drivers/
title: Drivers overview title: Overview
- path: /build/drivers/docker/ - path: /build/builders/drivers/docker/
title: Docker driver title: Docker driver
- path: /build/drivers/docker-container/ - path: /build/builders/drivers/docker-container/
title: Docker container driver title: Docker container driver
- path: /build/drivers/kubernetes/ - path: /build/builders/drivers/kubernetes/
title: Kubernetes driver title: Kubernetes driver
- path: /build/drivers/remote/ - path: /build/builders/drivers/remote/
title: Remote driver title: Remote driver
- sectiontitle: Exporters
section:
- path: /build/exporters/
title: Overview
- path: /build/exporters/image-registry/
title: Image and registry exporters
- path: /build/exporters/local-tar/
title: Local and tar exporters
- path: /build/exporters/oci-docker/
title: OCI and Docker exporters
- sectiontitle: Cache
section:
- path: /build/cache/
title: Overview
- path: /build/cache/invalidation/
title: Cache invalidation
- path: /build/cache/garbage-collection/
title: Garbage collection
- sectiontitle: Cache backends
section:
- path: /build/cache/backends/
title: Overview
- path: /build/cache/backends/inline/
title: Inline
- path: /build/cache/backends/local/
title: Local
- path: /build/cache/backends/registry/
title: Registry
- path: /build/cache/backends/gha/
title: GitHub Actions
- path: /build/cache/backends/azblob/
title: Azure Blob Storage
- path: /build/cache/backends/s3/
title: Amazon S3
- sectiontitle: Bake - sectiontitle: Bake
section: section:
- path: /build/bake/ - path: /build/bake/
@ -1986,36 +1950,30 @@ Manuals:
title: Building from Compose file title: Building from Compose file
- path: /build/bake/remote-definition/ - path: /build/bake/remote-definition/
title: Remote Bake file definition title: Remote Bake file definition
- sectiontitle: Attestations - sectiontitle: Cache
section: section:
- path: /build/attestations/ - path: /build/cache/
title: Overview title: Overview
- path: /build/attestations/sbom/ - path: /build/cache/invalidation/
title: SBOM title: Cache invalidation
- path: /build/attestations/slsa-provenance/ - path: /build/cache/garbage-collection/
title: Provenance title: Garbage collection
- path: /build/attestations/slsa-definitions/ - sectiontitle: Cache backends
title: SLSA definitions
- path: /build/attestations/attestation-storage/
title: Attestation storage
- sectiontitle: Dockerfile
section: section:
- path: /build/dockerfile/frontend/ - path: /build/cache/backends/
title: Custom Dockerfile syntax
- path: /build/dockerfile/release-notes/
title: Release notes
- sectiontitle: BuildKit
section:
- path: /build/buildkit/
title: Overview title: Overview
- path: /build/buildkit/configure/ - path: /build/cache/backends/inline/
title: Configure title: Inline
- path: /build/buildkit/toml-configuration/ - path: /build/cache/backends/local/
title: TOML configuration title: Local
- sectiontitle: Continuous integration - path: /build/cache/backends/registry/
section: title: Registry
- path: /build/ci/ - path: /build/cache/backends/gha/
title: CI with Docker title: GitHub Actions
- path: /build/cache/backends/azblob/
title: Azure Blob Storage
- path: /build/cache/backends/s3/
title: Amazon S3
- sectiontitle: GitHub Actions - sectiontitle: GitHub Actions
section: section:
- path: /build/ci/github-actions/ - path: /build/ci/github-actions/
@ -2054,6 +2012,48 @@ Manuals:
title: Annotations title: Annotations
- path: /build/ci/github-actions/reproducible-builds/ - path: /build/ci/github-actions/reproducible-builds/
title: Reproducible builds title: Reproducible builds
- sectiontitle: Metadata
section:
- path: /build/metadata/annotations/
title: Annotations
- sectiontitle: Attestations
section:
- path: /build/metadata/attestations/
title: Overview
- path: /build/metadata/attestations/sbom/
title: SBOM
- path: /build/metadata/attestations/slsa-provenance/
title: Provenance
- path: /build/metadata/attestations/slsa-definitions/
title: SLSA definitions
- path: /build/metadata/attestations/attestation-storage/
title: Attestation storage
- sectiontitle: Exporters
section:
- path: /build/exporters/
title: Overview
- path: /build/exporters/image-registry/
title: Image and registry exporters
- path: /build/exporters/local-tar/
title: Local and tar exporters
- path: /build/exporters/oci-docker/
title: OCI and Docker exporters
- sectiontitle: BuildKit
section:
- path: /build/buildkit/
title: Overview
- path: /build/buildkit/configure/
title: Configure
- path: /build/buildkit/toml-configuration/
title: TOML configuration
- path: /build/buildkit/frontend/
title: Custom Dockerfile syntax
- path: /build/buildkit/dockerfile-release-notes/
title: Dockerfile release notes
- sectiontitle: Debugging
section:
- path: /build/debug/opentelemetry/
title: OpenTelemetry support
- path: /build/release-notes/ - path: /build/release-notes/
title: Release notes title: Release notes
- sectiontitle: Docker Build Cloud - sectiontitle: Docker Build Cloud

4
hugo.yaml
View File

@ -263,9 +263,9 @@ module:
- source: docs/buildkitd.toml.md - source: docs/buildkitd.toml.md
target: content/build/buildkit/toml-configuration.md target: content/build/buildkit/toml-configuration.md
- source: docs/attestations/slsa-definitions.md - source: docs/attestations/slsa-definitions.md
target: content/build/attestations/slsa-definitions.md target: content/build/metadata/attestations/slsa-definitions.md
- source: docs/attestations/attestation-storage.md - source: docs/attestations/attestation-storage.md
target: content/build/attestations/attestation-storage.md target: content/build/metadata/attestations/attestation-storage.md
- path: github.com/docker/buildx - path: github.com/docker/buildx
mounts: mounts: