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

Merge pull request #20592 from dvdksn/restructure-build-manuals 

build: restructure manuals section
This commit is contained in:
David Karlsson 2024-08-19 13:12:53 +02:00 committed by GitHub
parent 52b3d97da7 127bf48d12
commit 9e90b8cfd0
No known key found for this signature in database
GPG Key ID: B5690EEEBB952194
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
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
build context. Files caught by the glob patterns you specify in your
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
in the cloud.'
icon: inventory_2
link: /build/building/packaging
link: /build/concepts/overview/
- title: Multi-stage builds
description: Keep your images small and secure with minimal dependencies.
icon: stairs
link: /build/building/multi-stage
link: /build/building/multi-stage/
- title: Multi-platform images
description: Build, push, pull, and run images seamlessly on different computer
architectures.
icon: content_copy
link: /build/building/multi-platform/
- title: Architecture
- title: BuildKit
description: Explore BuildKit, the open source build engine.
icon: construction
link: /build/buildkit/
- title: Build drivers
description: Configure where and how you run your builds.
icon: engineering
link: /build/drivers/
link: /build/builders/drivers/
- title: Exporters
description: Export any artifact you like, not just Docker images.
icon: output
link: /build/exporters
link: /build/exporters/
- title: Build caching
description: Avoid unnecessary repetitions of costly operations, such as package
installs.
icon: cycle
link: /build/cache
link: /build/cache/
- title: Bake
description: Orchestrate your builds with Bake.
icon: cake
link: /build/bake
link: /build/bake/
aliases:
- /buildx/working-with-buildx/
- /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
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
uses the [`docker` driver](../drivers/docker.md).
uses the [`docker` driver](drivers/docker.md).
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,
see [Manage builders](./manage.md)
- To learn about different types of builders,
see [Build drivers](../drivers/index.md)
see [Build drivers](drivers/index.md)

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

@ -6,6 +6,7 @@ aliases:
- /build/buildx/drivers/
- /build/building/drivers/
- /build/buildx/multiple-builders/
- /build/drivers/
---
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 |
\* _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
@ -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.
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
$ docker buildx build --load -t <image> --builder=container .
...
=> exporting to oci image format 7.7s
=> => exporting layers 4.9s
=> => exporting manifest sha256:4e4ca161fa338be2c303445411900ebbc5fc086153a0b846ac12996960b479d3 0.0s
=> => exporting config sha256:adf3eec768a14b6e183a1010cb96d91155a82fd722a1091440c88f3747f1f53f 0.0s
=> => sending tarball 2.8s
=> importing to docker
```
```console
$ docker buildx build --load -t <image> --builder=container .
...
=> exporting to oci image format 7.7s
=> => exporting layers 4.9s
=> => exporting manifest sha256:4e4ca161fa338be2c303445411900ebbc5fc086153a0b846ac12996960b479d3 0.0s
=> => exporting config sha256:adf3eec768a14b6e183a1010cb96d91155a82fd722a1091440c88f3747f1f53f 0.0s
=> => sending tarball 2.8s
=> 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
$ docker image ls
REPOSITORY TAG IMAGE ID CREATED SIZE
<image> latest adf3eec768a1 2 minutes ago 197MB
```
```console
$ docker image ls
REPOSITORY TAG IMAGE ID CREATED SIZE
<image> latest adf3eec768a1 2 minutes ago 197MB
```
### Load by default
@ -84,7 +85,7 @@ flag.
Read about each driver:
- [Docker driver](./docker.md)
- [Docker container driver](./docker-container.md)
- [Kubernetes driver](./kubernetes.md)
- [Docker driver](./docker.md)
- [Docker container driver](./docker-container.md)
- [Kubernetes driver](./kubernetes.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:
- /build/buildx/drivers/docker-container/
- /build/building/drivers/docker-container/
- /build/drivers/docker-container/
---
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.
- 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
@ -132,14 +133,14 @@ $ docker buildx build \
You can customize the network that the builder container uses. This is useful
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`:
```console
$ 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:
```console
@ -149,13 +150,13 @@ $ docker buildx create --use \
--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
$ 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:
```console
@ -166,4 +167,4 @@ map[foonet:0xc00018c0c0]
## Further reading
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:
- /build/buildx/drivers/docker/
- /build/building/drivers/docker/
- /build/drivers/docker/
---
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.
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
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
[Docker container driver](./docker-container.md).
@ -36,4 +37,4 @@ If you need additional configuration and flexibility, consider using the
## Further reading
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:
- /build/buildx/drivers/kubernetes/
- /build/building/drivers/kubernetes/
- /build/drivers/kubernetes/
---
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.
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
@ -143,7 +144,7 @@ $ docker buildx create \
## Multi-platform builds
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.
### QEMU
@ -343,9 +344,9 @@ Prerequisites:
--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
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:
- /build/buildx/drivers/remote/
- /build/building/drivers/remote/
- /build/drivers/remote/
---
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
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
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.
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`
flag. For more information about available drivers, see
[Build drivers](../drivers/index.md).
[Build drivers](drivers/_index.md).
## List available builders
@ -42,7 +42,7 @@ my_builder docker-container
```
The asterisk (`*`) next to the builder name indicates the
[selected builder](index.md#selected-builder).
[selected builder](_index.md#selected-builder).
## Inspect a builder

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

@ -62,7 +62,7 @@ ADD 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:
```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
[Dockerignore file](../../build/building/context.md#dockerignore-files).
[Dockerignore file](/build/concepts/context.md#dockerignore-files).
## Create ephemeral containers
@ -578,8 +578,8 @@ For more information about `ENV`, see [Dockerfile reference for the ENV instruct
### ADD or COPY
`ADD` and `COPY` are functionally similar. `COPY` supports basic copying of
files into the container, from the [build context](../../build/building/context.md)
or from a stage in a [multi-stage build](../../build/building/multi-stage.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).
`ADD` supports features for fetching files from remote HTTPS and Git URLs, and
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**:
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
@ -191,9 +191,9 @@ default * docker
```
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
and the more advanced cache exporters, which are currently unsupported in the
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_HOST](#buildkit_host) | String | Specify host to use for remote builders. |
| [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_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. |
@ -380,7 +380,7 @@ $ export BUILDKIT_PROGRESS=plain
### 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`).
```console
@ -519,7 +519,7 @@ $ export BUILDX_EXPERIMENTAL=1
{{< introduced buildx 0.10.4 "../release-notes.md#0104" >}}
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:
@ -532,7 +532,7 @@ $ export BUILDX_GIT_CHECK_DIRTY=1
{{< introduced buildx 0.10.0 "../release-notes.md#0100" >}}
When set to false, removes source control information from
[provenance attestations](../attestations/slsa-provenance.md).
[provenance attestations](/build/metadata/attestations/slsa-provenance.md).
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" >}}
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
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
- Parallelize building independent build stages
- 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
[build context](../building/context.md)
- Use [Dockerfile frontend](../dockerfile/frontend.md) implementations with many
[build context](../concepts/context.md)
- Use [Dockerfile frontend](frontend.md) implementations with many
new features
- Avoid side effects with rest of the API (intermediate images and containers)
- 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
BuildKit, you would
[use an external Dockerfile frontend](../dockerfile/frontend.md).
[use an external Dockerfile frontend](frontend.md).
## Getting started
@ -88,7 +88,7 @@ $ DOCKER_BUILDKIT=1 docker build .
> [!NOTE]
>
> [Buildx](../architecture.md#buildx) always uses BuildKit.
> Buildx always uses BuildKit.
To use Docker BuildKit by default, edit the Docker daemon configuration in
`/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
```
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.
```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
tags: [Release notes]
toc_max: 2
aliases:
- /build/dockerfile/release-notes/
---
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
aliases:
- /build/buildkit/dockerfile-frontend/
- /build/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.
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
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
@ -134,7 +134,7 @@ COPY . /src
```
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
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
`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]
>

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.
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

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.
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

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.
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

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.
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

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

@ -18,10 +18,10 @@ parameters by defining garbage collection policies.
## 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.
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).
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,
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.

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

@ -105,7 +105,7 @@ jobs:
## Configure annotation level
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
`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

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
[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.
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
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:
### Registry mirror
@ -145,7 +145,7 @@ fields:
| `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. |
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):
```yaml
@ -187,7 +187,7 @@ using SSH or TLS.
### 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:
```yaml
@ -215,7 +215,7 @@ jobs:
### 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
an environment variables that sets up authentication using the BuildKit client
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
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).
```yaml

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

@ -89,7 +89,7 @@ jobs:
## Using with a container builder
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
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:

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

@ -2,6 +2,8 @@
title: Build context
description: Learn how to use the build context to access files from your Dockerfile
keywords: build, buildx, buildkit, context, git, tarball, stdin
aliases:
- /build/building/context/
---
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
keywords: build, buildx, buildkit, getting started, dockerfile
aliases:
- /build/hellobuild/
- /build/building/packaging/
---
## 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).
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)
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)
must appear before any other comment, whitespace, or Dockerfile instruction in
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
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
description: Analyze telemetry data for builds
keywords: build, buildx buildkit, opentelemetry
aliases:
- /build/building/opentelemetry/
---
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
```
Then [create a `docker-container` builder](../drivers/docker-container.md)
that will use the Jaeger instance via the `JAEGER_TRACE` env var:
Then [create a `docker-container` builder](/build/builders/drivers/docker-container.md)
that will use the Jaeger instance via the `JAEGER_TRACE` environment variable:
```console
$ docker buildx create --use \
@ -27,7 +29,7 @@ $ docker buildx create --use \
--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
$ 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
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
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
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
- [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
- [Exporters](../exporters/index.md): save your build results to different
- [Exporters](../exporters/_index.md): save your build results to different
output formats
- [Bake](../bake/index.md): orchestrate your build workflows
- [Attestations](../attestations/index.md): annotate your build artifacts with
- [Bake](../bake/_index.md): orchestrate your build workflows
- [Attestations](../metadata/attestations/_index.md): annotate your build artifacts with
metadata
- [Continuous integration](../ci/index.md): run Docker builds in CI
- [GitHub Actions](../ci/github-actions/_index.md): run Docker builds in CI
## 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
description: Annotations specify additional metadata about OCI images
keywords: build, buildkit, annotations, metadata
aliases:
- /build/building/annotations/
---
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
> annotations. To build with annotations, make sure to push the image directly
> 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
`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" .
```
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:
```hcl
@ -61,12 +63,12 @@ target "default" {
```
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
imagetools create`. This command only supports adding annotations to an index
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
@ -195,19 +197,19 @@ $ docker build --tag <IMAGE> --push --annotation "manifest[linux/amd64]:foo=bar"
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]
Reference information:
- [`docker buildx build --annotation`](../../reference/cli/docker/buildx/build.md#annotation)
- [Bake file reference: `annotations`](../bake/reference.md#targetannotations)
- [`docker buildx imagetools create --annotation`](../../reference/cli/docker/buildx/imagetools/create.md#annotation)
- [`docker buildx build --annotation`](/reference/cli/docker/buildx/build.md#annotation)
- [Bake file reference: `annotations`](/build/bake/reference.md#targetannotations)
- [`docker buildx imagetools create --annotation`](/reference/cli/docker/buildx/imagetools/create.md#annotation)
<!-- links -->
[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
[descriptors]: https://github.com/opencontainers/image-spec/blob/main/descriptor.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: |
Introduction to SBOM and provenance attestations with Docker Build,
what they are, and why they exist
aliases:
- /build/attestations/
---
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
> a registry directly.
> - Enable the [containerd image store](../../desktop/containerd.md).
> - Enable the [containerd image store](/desktop/containerd.md).
> [!NOTE]
>
> Provenance attestations are enabled by default, with the `mode=min` option.
> 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`
> 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: |
SBOM build attestations describe the contents of your image,
and the packages used to build it.
aliases:
- /build/attestations/sbom/
---
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`.
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
@ -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
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.
```dockerfile
@ -173,7 +175,7 @@ sbom.spdx.json
## Inspecting SBOMs
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
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
description: >
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
@ -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`.
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
@ -141,17 +143,17 @@ detailed information for analysis.
> [!WARNING]
>
> 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
> 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.
## Inspecting Provenance
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
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.
- 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/)
- 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/)
@ -127,7 +127,7 @@ The full release note for this release is available
[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.
[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#2415](https://github.com/docker/buildx/pull/2415)
- 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
current build. [docker/buildx#1412](https://github.com/docker/buildx/issues/1412)
[docker/buildx#1475](https://github.com/docker/buildx/issues/1475)
- `--attest type=sbom` or `--sbom=true` adds [SBOM attestations](attestations/sbom.md).
- `--attest type=provenance` or `--provenance=true` adds [SLSA provenance attestation](attestations/slsa-provenance.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](/build/metadata/attestations/slsa-provenance.md).
- When creating OCI images, a minimal provenance attestation is included
with the image by default.
- 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#1455](https://github.com/docker/buildx/issues/1455),
[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)
- [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)
@ -575,7 +575,7 @@ For more details, see the complete release notes in the [Buildx GitHub repositor
### 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.
[docker/buildx#1078](https://github.com/docker/buildx/issues/1078),
[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)
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.
### Build timing
@ -93,7 +93,7 @@ operations are defined as follows:
| HTTP | Remote artifact downloads using `ADD`. |
| Git | Same as **HTTP** but for Git URLs. |
| 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). |
### Build dependencies
@ -123,7 +123,7 @@ including image manifest details, attestations, and build traces.
Attestations are metadata records attached to a container image.
The metadata describes something about the image,
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
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
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.
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 .
```
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.
@ -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:
* [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 image tag reference](/engine/reference/commandline/image_tag/)
* [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
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
aliases:
- /build/guides/multi-stage/
---
{{< 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
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.
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.
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)
## 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.
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)
## 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!
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).
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.
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)
## 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.
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)
## 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.
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)
## 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.
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)
## 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.
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)
## 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.
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)
## 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.
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)
## 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.
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)
## 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
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.
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
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:
- 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
[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.
> [!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).
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
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}
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.
You can configure BuildKit to use the Docker Scout SBOM generator
using the `--attest` flag for the `docker build` command.

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

@ -18,7 +18,7 @@ them in the database.
When you push a new image to a repository, Docker Scout evaluates the results
of the SonarQube analysis record corresponding to the image. Docker Scout uses
Git provenance metadata on the images, from provenance attestations or an OCI
Git provenance metadata on the images, from provenance attestations or an OCI
annotations, to link image repositories with SonarQube analysis results.
> [!NOTE]
@ -32,7 +32,7 @@ annotations, to link image repositories with SonarQube analysis results.
To integrate Docker Scout with SonarQube, ensure that:
- 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,
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.
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
found, and you've enabled the GitHub app, Docker Scout parses the Dockerfile
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
The **Supply chain attestations** policy requires that your artifacts have
[SBOM](../../build/attestations/sbom.md) and
[provenance](../../build/attestations/slsa-provenance.md) attestations.
[SBOM](../../build/metadata/attestations/sbom.md) and
[provenance](../../build/metadata/attestations/slsa-provenance.md) attestations.
This policy is violated if an artifact lacks either an SBOM attestation or a
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
building with attestations, see
[Attestations](../../build/attestations/_index.md).
[Attestations](../../build/metadata/attestations/_index.md).
### 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
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
SonarQube analysis results with container images. In addition to enabling 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
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
image version.

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

@ -72,7 +72,7 @@ information available about the image.
### No provenance attestations
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.
<!--
@ -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
has a provenance attestation, but the attestation doesn't contain enough
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).
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,
and Linux).

2
data/buildx/docker_buildx_bake.yaml
View File

@ -304,7 +304,7 @@ examples: |-
> **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_METADATA_PROVENANCE` environment variable to customize this behavior:
> * `min` sets minimal provenance (default).

26
data/buildx/docker_buildx_build.yaml
View File

@ -623,7 +623,7 @@ examples: |-
--attest=type=provenance,...
```
Create [image attestations](/build/attestations/).
Create [image attestations](/build/metadata/attestations/).
BuildKit currently supports:
- `sbom` - Software Bill of Materials.
@ -631,7 +631,7 @@ examples: |-
Use `--attest=type=sbom` to generate an SBOM for an image at build-time.
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
@ -641,7 +641,7 @@ examples: |-
By default, a minimal provenance attestation will be created for the build
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}
@ -1062,7 +1062,7 @@ examples: |-
> **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_METADATA_PROVENANCE` environment variable to customize this behavior:
>
@ -1070,6 +1070,12 @@ examples: |-
> - `max` sets full 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}
Available options for the networking mode are:
@ -1080,12 +1086,6 @@ examples: |-
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}
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
`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
configurable allows export of results directly to the client's filesystem, an
OCI image tarball, a registry, and more.
@ -1356,7 +1356,7 @@ examples: |-
to using the containerd image store.
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}
@ -1378,7 +1378,7 @@ examples: |-
to a registry if you use the default image store. Alternatively, you can switch
to using the containerd image store.
For more information, see [here](/build/attestations/sbom/).
For more information, see [here](/build/metadata/attestations/sbom/).
### Secret to expose to the build (--secret) {#secret}

10
data/buildx/docker_buildx_create.yaml
View File

@ -227,7 +227,7 @@ examples: |-
* `kubernetes`
* `remote`
For more information about build drivers, see [here](/build/drivers/).
For more information about build drivers, see [here](/build/builders/drivers/).
#### `docker` driver
@ -274,10 +274,10 @@ examples: |-
For information about available driver options, refer to the detailed
documentation for the specific driver:
* [`docker` driver](/build/drivers/docker/)
* [`docker-container` driver](/build/drivers/docker-container/)
* [`kubernetes` driver](/build/drivers/kubernetes/)
* [`remote` driver](/build/drivers/remote/)
* [`docker` driver](/build/builders/drivers/docker/)
* [`docker-container` driver](/build/builders/drivers/docker-container/)
* [`kubernetes` driver](/build/builders/drivers/kubernetes/)
* [`remote` driver](/build/builders/drivers/remote/)
### 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
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
being sent as part of the build context.

2
data/redirects.yml
View File

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

226
data/toc.yaml
View File

@ -1880,28 +1880,26 @@ Manuals:
section:
- path: /build/
title: Overview
- path: /build/architecture/
title: Architecture
- sectiontitle: Building images
- sectiontitle: Core concepts
section:
- path: /build/concepts/overview/
title: Build overview
- path: /build/concepts/dockerfile/
title: Dockerfile
- path: /build/concepts/context/
title: Build context
- sectiontitle: Building
section:
- path: /build/building/packaging/
title: Packaging your software
- path: /build/building/context/
title: Context
- path: /build/building/multi-stage/
title: Multi-stage builds
- path: /build/building/variables/
title: Variables
- path: /build/building/best-practices/
title: Best practices
- path: /build/building/multi-platform/
title: Multi-platform images
- path: /build/building/secrets/
title: Build secrets
- path: /build/building/annotations/
title: Annotations
- path: /build/building/opentelemetry/
title: OpenTelemetry support
- path: /build/building/best-practices/
title: Best practices
- path: /build/building/base-images/
title: Base images
- path: /build/checks/
@ -1912,52 +1910,18 @@ Manuals:
title: Builders overview
- path: /build/builders/manage/
title: Manage builders
- sectiontitle: Drivers
section:
- path: /build/drivers/
title: Drivers overview
- path: /build/drivers/docker/
title: Docker driver
- path: /build/drivers/docker-container/
title: Docker container driver
- path: /build/drivers/kubernetes/
title: Kubernetes driver
- path: /build/drivers/remote/
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
- sectiontitle: Build drivers
section:
- path: /build/cache/backends/
- path: /build/builders/drivers/
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
- path: /build/builders/drivers/docker/
title: Docker driver
- path: /build/builders/drivers/docker-container/
title: Docker container driver
- path: /build/builders/drivers/kubernetes/
title: Kubernetes driver
- path: /build/builders/drivers/remote/
title: Remote driver
- sectiontitle: Bake
section:
- path: /build/bake/
@ -1986,24 +1950,94 @@ Manuals:
title: Building from Compose file
- path: /build/bake/remote-definition/
title: Remote Bake file definition
- sectiontitle: Attestations
- sectiontitle: Cache
section:
- path: /build/attestations/
- path: /build/cache/
title: Overview
- path: /build/attestations/sbom/
title: SBOM
- path: /build/attestations/slsa-provenance/
title: Provenance
- path: /build/attestations/slsa-definitions/
title: SLSA definitions
- path: /build/attestations/attestation-storage/
title: Attestation storage
- sectiontitle: Dockerfile
- 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: GitHub Actions
section:
- path: /build/dockerfile/frontend/
title: Custom Dockerfile syntax
- path: /build/dockerfile/release-notes/
title: Release notes
- path: /build/ci/github-actions/
title: Introduction
- path: /build/ci/github-actions/build-summary/
title: Build summary {{< badge color=blue text=Beta >}}
- path: /build/ci/github-actions/configure-builder/
title: Configuring your builder
- path: /build/ci/github-actions/multi-platform/
title: Multi-platform image
- path: /build/ci/github-actions/secrets/
title: Secrets
- path: /build/ci/github-actions/push-multi-registries/
title: Push to multiple registries
- path: /build/ci/github-actions/manage-tags-labels/
title: Manage tags and labels
- path: /build/ci/github-actions/cache/
title: Cache management
- path: /build/ci/github-actions/export-docker/
title: Export to Docker
- path: /build/ci/github-actions/test-before-push/
title: Test before push
- path: /build/ci/github-actions/local-registry/
title: Local registry
- path: /build/ci/github-actions/share-image-jobs/
title: Share built image between jobs
- path: /build/ci/github-actions/named-contexts/
title: Named contexts
- path: /build/ci/github-actions/copy-image-registries/
title: Copy image between registries
- path: /build/ci/github-actions/update-dockerhub-desc/
title: Update Docker Hub repo description
- path: /build/ci/github-actions/attestations/
title: SBOM and provenance attestations
- path: /build/ci/github-actions/annotations/
title: Annotations
- path: /build/ci/github-actions/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/
@ -2012,48 +2046,14 @@ Manuals:
title: Configure
- path: /build/buildkit/toml-configuration/
title: TOML configuration
- sectiontitle: Continuous integration
- path: /build/buildkit/frontend/
title: Custom Dockerfile syntax
- path: /build/buildkit/dockerfile-release-notes/
title: Dockerfile release notes
- sectiontitle: Debugging
section:
- path: /build/ci/
title: CI with Docker
- sectiontitle: GitHub Actions
section:
- path: /build/ci/github-actions/
title: Introduction
- path: /build/ci/github-actions/build-summary/
title: Build summary {{< badge color=blue text=Beta >}}
- path: /build/ci/github-actions/configure-builder/
title: Configuring your builder
- path: /build/ci/github-actions/multi-platform/
title: Multi-platform image
- path: /build/ci/github-actions/secrets/
title: Secrets
- path: /build/ci/github-actions/push-multi-registries/
title: Push to multiple registries
- path: /build/ci/github-actions/manage-tags-labels/
title: Manage tags and labels
- path: /build/ci/github-actions/cache/
title: Cache management
- path: /build/ci/github-actions/export-docker/
title: Export to Docker
- path: /build/ci/github-actions/test-before-push/
title: Test before push
- path: /build/ci/github-actions/local-registry/
title: Local registry
- path: /build/ci/github-actions/share-image-jobs/
title: Share built image between jobs
- path: /build/ci/github-actions/named-contexts/
title: Named contexts
- path: /build/ci/github-actions/copy-image-registries/
title: Copy image between registries
- path: /build/ci/github-actions/update-dockerhub-desc/
title: Update Docker Hub repo description
- path: /build/ci/github-actions/attestations/
title: SBOM and provenance attestations
- path: /build/ci/github-actions/annotations/
title: Annotations
- path: /build/ci/github-actions/reproducible-builds/
title: Reproducible builds
- path: /build/debug/opentelemetry/
title: OpenTelemetry support
- path: /build/release-notes/
title: Release notes
- sectiontitle: Docker Build Cloud

4
hugo.yaml
View File

@ -263,9 +263,9 @@ module:
- source: docs/buildkitd.toml.md
target: content/build/buildkit/toml-configuration.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
target: content/build/attestations/attestation-storage.md
target: content/build/metadata/attestations/attestation-storage.md
- path: github.com/docker/buildx
mounts: