diff --git a/content/build-cloud/optimization.md b/content/build-cloud/optimization.md index d7089901ef..cc5c15e91d 100644 --- a/content/build-cloud/optimization.md +++ b/content/build-cloud/optimization.md @@ -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. diff --git a/content/build/_index.md b/content/build/_index.md index 1ccd3846bb..e552e5886a 100644 --- a/content/build/_index.md +++ b/content/build/_index.md @@ -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/ diff --git a/content/build/architecture.md b/content/build/architecture.md deleted file mode 100644 index a0c81efbea..0000000000 --- a/content/build/architecture.md +++ /dev/null @@ -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) diff --git a/content/build/builders/_index.md b/content/build/builders/_index.md index 12b5a8ca78..53ff751cf4 100644 --- a/content/build/builders/_index.md +++ b/content/build/builders/_index.md @@ -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) diff --git a/content/build/drivers/_index.md b/content/build/builders/drivers/_index.md similarity index 71% rename from content/build/drivers/_index.md rename to content/build/builders/drivers/_index.md index adf30fdf24..ae88709f38 100644 --- a/content/build/drivers/_index.md +++ b/content/build/builders/drivers/_index.md @@ -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 --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 --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 - latest adf3eec768a1 2 minutes ago 197MB -``` + ```console + $ docker image ls + REPOSITORY TAG IMAGE ID CREATED SIZE + 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) diff --git a/content/build/drivers/docker-container.md b/content/build/builders/drivers/docker-container.md similarity index 93% rename from content/build/drivers/docker-container.md rename to content/build/builders/drivers/docker-container.md index b5fa5550e6..aea65c4320 100644 --- a/content/build/drivers/docker-container.md +++ b/content/build/builders/drivers/docker-container.md @@ -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). diff --git a/content/build/drivers/docker.md b/content/build/builders/drivers/docker.md similarity index 82% rename from content/build/drivers/docker.md rename to content/build/builders/drivers/docker.md index 117c1f76c3..91fe317c22 100644 --- a/content/build/drivers/docker.md +++ b/content/build/builders/drivers/docker.md @@ -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). diff --git a/content/build/drivers/kubernetes.md b/content/build/builders/drivers/kubernetes.md similarity index 98% rename from content/build/drivers/kubernetes.md rename to content/build/builders/drivers/kubernetes.md index 124ad370a3..8a973732c5 100644 --- a/content/build/drivers/kubernetes.md +++ b/content/build/builders/drivers/kubernetes.md @@ -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). diff --git a/content/build/drivers/remote.md b/content/build/builders/drivers/remote.md similarity index 99% rename from content/build/drivers/remote.md rename to content/build/builders/drivers/remote.md index c4e61d37fc..f002d49ea3 100644 --- a/content/build/drivers/remote.md +++ b/content/build/builders/drivers/remote.md @@ -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, diff --git a/content/build/builders/manage.md b/content/build/builders/manage.md index e3b3d6e203..7a1cd63c8c 100644 --- a/content/build/builders/manage.md +++ b/content/build/builders/manage.md @@ -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= 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 diff --git a/content/build/building/base-images.md b/content/build/building/base-images.md index f64e949639..8dcf38a7ff 100644 --- a/content/build/building/base-images.md +++ b/content/build/building/base-images.md @@ -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 diff --git a/content/build/building/best-practices.md b/content/build/building/best-practices.md index 7516d3ab0d..02d13dd21b 100644 --- a/content/build/building/best-practices.md +++ b/content/build/building/best-practices.md @@ -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. diff --git a/content/build/building/multi-platform.md b/content/build/building/multi-platform.md index 93f21cf1bc..8478965a36 100644 --- a/content/build/building/multi-platform.md +++ b/content/build/building/multi-platform.md @@ -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: diff --git a/content/build/building/variables.md b/content/build/building/variables.md index 5b179895ee..2521b4ae2c 100644 --- a/content/build/building/variables.md +++ b/content/build/building/variables.md @@ -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. diff --git a/content/build/buildkit/_index.md b/content/build/buildkit/_index.md index 580c25cc82..f255637284 100644 --- a/content/build/buildkit/_index.md +++ b/content/build/buildkit/_index.md @@ -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. diff --git a/content/build/buildkit/configure.md b/content/build/buildkit/configure.md index f64c01b389..cad59cd8dd 100644 --- a/content/build/buildkit/configure.md +++ b/content/build/buildkit/configure.md @@ -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 diff --git a/content/build/dockerfile/release-notes.md b/content/build/buildkit/dockerfile-release-notes.md similarity index 99% rename from content/build/dockerfile/release-notes.md rename to content/build/buildkit/dockerfile-release-notes.md index fd3135c7dd..7808eb579d 100644 --- a/content/build/dockerfile/release-notes.md +++ b/content/build/buildkit/dockerfile-release-notes.md @@ -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 diff --git a/content/build/dockerfile/frontend.md b/content/build/buildkit/frontend.md similarity index 99% rename from content/build/dockerfile/frontend.md rename to content/build/buildkit/frontend.md index d73fb8b589..941774b953 100644 --- a/content/build/dockerfile/frontend.md +++ b/content/build/buildkit/frontend.md @@ -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 diff --git a/content/build/cache/_index.md b/content/build/cache/_index.md index f61cda7aff..3ea4a944f0 100644 --- a/content/build/cache/_index.md +++ b/content/build/cache/_index.md @@ -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. diff --git a/content/build/cache/backends/_index.md b/content/build/cache/backends/_index.md index 58d28e4169..328e785542 100644 --- a/content/build/cache/backends/_index.md +++ b/content/build/cache/backends/_index.md @@ -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] > diff --git a/content/build/cache/backends/azblob.md b/content/build/cache/backends/azblob.md index 351422d6b6..df10b5f4b6 100644 --- a/content/build/cache/backends/azblob.md +++ b/content/build/cache/backends/azblob.md @@ -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 diff --git a/content/build/cache/backends/gha.md b/content/build/cache/backends/gha.md index 796398c0ad..5a7440a4b1 100644 --- a/content/build/cache/backends/gha.md +++ b/content/build/cache/backends/gha.md @@ -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 diff --git a/content/build/cache/backends/registry.md b/content/build/cache/backends/registry.md index 66c38b2eeb..1872ac0907 100644 --- a/content/build/cache/backends/registry.md +++ b/content/build/cache/backends/registry.md @@ -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 diff --git a/content/build/cache/backends/s3.md b/content/build/cache/backends/s3.md index 8d0024ca7c..c075d86a11 100644 --- a/content/build/cache/backends/s3.md +++ b/content/build/cache/backends/s3.md @@ -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 diff --git a/content/build/cache/garbage-collection.md b/content/build/cache/garbage-collection.md index 33297b22fa..d046ddbbf7 100644 --- a/content/build/cache/garbage-collection.md +++ b/content/build/cache/garbage-collection.md @@ -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: diff --git a/content/build/ci/_index.md b/content/build/ci/_index.md index 2b4291ae2e..c77e6f625d 100644 --- a/content/build/ci/_index.md +++ b/content/build/ci/_index.md @@ -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. diff --git a/content/build/ci/github-actions/annotations.md b/content/build/ci/github-actions/annotations.md index 6b3e3f995c..6b922ab9eb 100644 --- a/content/build/ci/github-actions/annotations.md +++ b/content/build/ci/github-actions/annotations.md @@ -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 diff --git a/content/build/ci/github-actions/attestations.md b/content/build/ci/github-actions/attestations.md index 190cc9832c..918fa9c752 100644 --- a/content/build/ci/github-actions/attestations.md +++ b/content/build/ci/github-actions/attestations.md @@ -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 diff --git a/content/build/ci/github-actions/configure-builder.md b/content/build/ci/github-actions/configure-builder.md index 09a99b23be..0bed4fd18d 100644 --- a/content/build/ci/github-actions/configure-builder.md +++ b/content/build/ci/github-actions/configure-builder.md @@ -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 diff --git a/content/build/ci/github-actions/named-contexts.md b/content/build/ci/github-actions/named-contexts.md index 75ea7c2f81..253548e0d9 100644 --- a/content/build/ci/github-actions/named-contexts.md +++ b/content/build/ci/github-actions/named-contexts.md @@ -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: diff --git a/content/build/building/context.md b/content/build/concepts/context.md similarity index 99% rename from content/build/building/context.md rename to content/build/concepts/context.md index bf5a8e788b..2402129c29 100644 --- a/content/build/building/context.md +++ b/content/build/concepts/context.md @@ -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 diff --git a/content/build/building/packaging.md b/content/build/concepts/dockerfile.md similarity index 96% rename from content/build/building/packaging.md rename to content/build/concepts/dockerfile.md index d6b92ef880..b4af64897a 100644 --- a/content/build/building/packaging.md +++ b/content/build/concepts/dockerfile.md @@ -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. diff --git a/content/build/concepts/overview.md b/content/build/concepts/overview.md new file mode 100644 index 0000000000..bda815578b --- /dev/null +++ b/content/build/concepts/overview.md @@ -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). diff --git a/content/build/building/opentelemetry.md b/content/build/debug/opentelemetry.md similarity index 76% rename from content/build/building/opentelemetry.md rename to content/build/debug/opentelemetry.md index 431b218471..5f891de723 100644 --- a/content/build/building/opentelemetry.md +++ b/content/build/debug/opentelemetry.md @@ -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 diff --git a/content/build/exporters/oci-docker.md b/content/build/exporters/oci-docker.md index 9e107d30ab..68707e8adc 100644 --- a/content/build/exporters/oci-docker.md +++ b/content/build/exporters/oci-docker.md @@ -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. diff --git a/content/build/guide/next-steps.md b/content/build/guide/next-steps.md index 139d7a83d5..8730f2bd08 100644 --- a/content/build/guide/next-steps.md +++ b/content/build/guide/next-steps.md @@ -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 diff --git a/content/build/images/build-execution.png b/content/build/images/build-execution.png deleted file mode 100644 index 5138441af2..0000000000 Binary files a/content/build/images/build-execution.png and /dev/null differ diff --git a/content/build/images/build-high-level-arch.png b/content/build/images/build-high-level-arch.png deleted file mode 100644 index 9c5c54f1e9..0000000000 Binary files a/content/build/images/build-high-level-arch.png and /dev/null differ diff --git a/content/build/images/build_summary_error.png b/content/build/images/build_summary_error.png new file mode 100644 index 0000000000..420bed060a Binary files /dev/null and b/content/build/images/build_summary_error.png differ diff --git a/content/build/images/continuous-integration.svg b/content/build/images/continuous-integration.svg new file mode 100644 index 0000000000..8b9f4d5a6d --- /dev/null +++ b/content/build/images/continuous-integration.svg @@ -0,0 +1,16 @@ + + + + + + + You're here! \ No newline at end of file diff --git a/content/build/images/gha_build_summary.png b/content/build/images/gha_build_summary.png new file mode 100644 index 0000000000..140e76e629 Binary files /dev/null and b/content/build/images/gha_build_summary.png differ diff --git a/content/build/building/annotations.md b/content/build/metadata/annotations.md similarity index 90% rename from content/build/building/annotations.md rename to content/build/metadata/annotations.md index 4ac9f4a45d..7a881047ad 100644 --- a/content/build/building/annotations.md +++ b/content/build/metadata/annotations.md @@ -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 --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) [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 diff --git a/content/build/attestations/_index.md b/content/build/metadata/attestations/_index.md similarity index 96% rename from content/build/attestations/_index.md rename to content/build/metadata/attestations/_index.md index 3e05424c10..e763f465ca 100644 --- a/content/build/attestations/_index.md +++ b/content/build/metadata/attestations/_index.md @@ -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. diff --git a/content/build/attestations/sbom.md b/content/build/metadata/attestations/sbom.md similarity index 97% rename from content/build/attestations/sbom.md rename to content/build/metadata/attestations/sbom.md index 243ce977e4..6d8fb860af 100644 --- a/content/build/attestations/sbom.md +++ b/content/build/metadata/attestations/sbom.md @@ -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 /: \ 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 diff --git a/content/build/attestations/slsa-provenance.md b/content/build/metadata/attestations/slsa-provenance.md similarity index 97% rename from content/build/attestations/slsa-provenance.md rename to content/build/metadata/attestations/slsa-provenance.md index e6b5fac985..761beb586b 100644 --- a/content/build/attestations/slsa-provenance.md +++ b/content/build/metadata/attestations/slsa-provenance.md @@ -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 diff --git a/content/build/release-notes.md b/content/build/release-notes.md index cbe5f852c0..932fbe7708 100644 --- a/content/build/release-notes.md +++ b/content/build/release-notes.md @@ -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), diff --git a/content/desktop/use-desktop/builds.md b/content/desktop/use-desktop/builds.md index ae23f0a3df..3997d41a0f 100644 --- a/content/desktop/use-desktop/builds.md +++ b/content/desktop/use-desktop/builds.md @@ -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. diff --git a/content/guides/docker-concepts/building-images/build-tag-and-publish-an-image.md b/content/guides/docker-concepts/building-images/build-tag-and-publish-an-image.md index 180eaa0678..8e530594fc 100644 --- a/content/guides/docker-concepts/building-images/build-tag-and-publish-an-image.md +++ b/content/guides/docker-concepts/building-images/build-tag-and-publish-an-image.md @@ -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/) diff --git a/content/guides/docker-concepts/building-images/multi-stage-builds.md b/content/guides/docker-concepts/building-images/multi-stage-builds.md index 65f3d49543..7b0bed99af 100644 --- a/content/guides/docker-concepts/building-images/multi-stage-builds.md +++ b/content/guides/docker-concepts/building-images/multi-stage-builds.md @@ -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 >}} diff --git a/content/includes/desktop-builders-setting.md b/content/includes/desktop-builders-setting.md index 1b85ef0b78..45e135be25 100644 --- a/content/includes/desktop-builders-setting.md +++ b/content/includes/desktop-builders-setting.md @@ -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. diff --git a/content/language/cpp/configure-ci-cd.md b/content/language/cpp/configure-ci-cd.md index 7c65cfbe3b..ffd08f52a0 100644 --- a/content/language/cpp/configure-ci-cd.md +++ b/content/language/cpp/configure-ci-cd.md @@ -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 diff --git a/content/language/dotnet/configure-ci-cd.md b/content/language/dotnet/configure-ci-cd.md index 41f49898cc..5f7dc1faec 100644 --- a/content/language/dotnet/configure-ci-cd.md +++ b/content/language/dotnet/configure-ci-cd.md @@ -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 diff --git a/content/language/golang/_index.md b/content/language/golang/_index.md index a4a7c1ffe0..3be7fc8708 100644 --- a/content/language/golang/_index.md +++ b/content/language/golang/_index.md @@ -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, diff --git a/content/language/golang/configure-ci-cd.md b/content/language/golang/configure-ci-cd.md index 5198b9a97b..ffc51274af 100644 --- a/content/language/golang/configure-ci-cd.md +++ b/content/language/golang/configure-ci-cd.md @@ -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 diff --git a/content/language/java/configure-ci-cd.md b/content/language/java/configure-ci-cd.md index 73572fbcb2..6f289ee932 100644 --- a/content/language/java/configure-ci-cd.md +++ b/content/language/java/configure-ci-cd.md @@ -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 diff --git a/content/language/nodejs/configure-ci-cd.md b/content/language/nodejs/configure-ci-cd.md index 5c5abcd186..ce3a2c2e7b 100644 --- a/content/language/nodejs/configure-ci-cd.md +++ b/content/language/nodejs/configure-ci-cd.md @@ -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 diff --git a/content/language/php/configure-ci-cd.md b/content/language/php/configure-ci-cd.md index fd3e97088d..db06cca6dc 100644 --- a/content/language/php/configure-ci-cd.md +++ b/content/language/php/configure-ci-cd.md @@ -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 diff --git a/content/language/python/configure-ci-cd.md b/content/language/python/configure-ci-cd.md index a8e3d93825..72c3289d48 100644 --- a/content/language/python/configure-ci-cd.md +++ b/content/language/python/configure-ci-cd.md @@ -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 diff --git a/content/language/r/configure-ci-cd.md b/content/language/r/configure-ci-cd.md index 0c3fd91910..89c02b3bb5 100644 --- a/content/language/r/configure-ci-cd.md +++ b/content/language/r/configure-ci-cd.md @@ -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 diff --git a/content/language/ruby/configure-ci-cd.md b/content/language/ruby/configure-ci-cd.md index b54d7b112e..6fbb4fb887 100644 --- a/content/language/ruby/configure-ci-cd.md +++ b/content/language/ruby/configure-ci-cd.md @@ -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 diff --git a/content/language/rust/configure-ci-cd.md b/content/language/rust/configure-ci-cd.md index f1dc557931..322ecdb1ac 100644 --- a/content/language/rust/configure-ci-cd.md +++ b/content/language/rust/configure-ci-cd.md @@ -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 diff --git a/content/scout/concepts/sbom.md b/content/scout/concepts/sbom.md index 6f7a33e9a3..8e4618f933 100644 --- a/content/scout/concepts/sbom.md +++ b/content/scout/concepts/sbom.md @@ -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) diff --git a/content/scout/deep-dive/data-handling.md b/content/scout/deep-dive/data-handling.md index 0d34c7528e..846fe16a9f 100644 --- a/content/scout/deep-dive/data-handling.md +++ b/content/scout/deep-dive/data-handling.md @@ -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 diff --git a/content/scout/explore/analysis.md b/content/scout/explore/analysis.md index 27a3ccc147..643b507239 100644 --- a/content/scout/explore/analysis.md +++ b/content/scout/explore/analysis.md @@ -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 diff --git a/content/scout/how-tos/view-create-sboms.md b/content/scout/how-tos/view-create-sboms.md index 1ac498abf0..31270c9593 100644 --- a/content/scout/how-tos/view-create-sboms.md +++ b/content/scout/how-tos/view-create-sboms.md @@ -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. diff --git a/content/scout/integrations/code-quality/sonarqube.md b/content/scout/integrations/code-quality/sonarqube.md index decc74e119..ae27b270e7 100644 --- a/content/scout/integrations/code-quality/sonarqube.md +++ b/content/scout/integrations/code-quality/sonarqube.md @@ -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. diff --git a/content/scout/integrations/source-code-management/github.md b/content/scout/integrations/source-code-management/github.md index 98be011306..dee420be02 100644 --- a/content/scout/integrations/source-code-management/github.md +++ b/content/scout/integrations/source-code-management/github.md @@ -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. diff --git a/content/scout/policy/_index.md b/content/scout/policy/_index.md index cf8c16d1ea..f910ffafd5 100644 --- a/content/scout/policy/_index.md +++ b/content/scout/policy/_index.md @@ -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 --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. diff --git a/content/scout/policy/remediation.md b/content/scout/policy/remediation.md index 2df230412c..d2d59666fd 100644 --- a/content/scout/policy/remediation.md +++ b/content/scout/policy/remediation.md @@ -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.