From f7ccee34b0a4b71e4a1306d817f280e74f660516 Mon Sep 17 00:00:00 2001 From: David Karlsson <35727626+dvdksn@users.noreply.github.com> Date: Wed, 10 Apr 2024 10:24:40 +0200 Subject: [PATCH] cli: make buildx build the canonical build Signed-off-by: David Karlsson <35727626+dvdksn@users.noreply.github.com> --- content/build/building/best-practices.md | 2 +- content/build/building/packaging.md | 2 +- content/build/building/variables.md | 2 +- content/build/guide/export.md | 2 +- content/build/guide/intro.md | 2 +- content/docker-hub/builds/advanced.md | 4 +- .../use-case/nlp/language-translation.md | 2 +- .../use-case/nlp/named-entity-recognition.md | 2 +- .../guides/use-case/nlp/sentiment-analysis.md | 2 +- .../use-case/nlp/text-classification.md | 2 +- .../guides/use-case/nlp/text-summarization.md | 2 +- content/language/rust/build-images.md | 2 +- .../{image/build.md => build-legacy.md} | 9 +- content/reference/cli/docker/buildx/build.md | 7 + data/engine-cli/docker_build.yaml | 9 +- data/engine-cli/docker_builder_build.yaml | 9 +- data/engine-cli/docker_image_build.yaml | 607 ++---------------- data/toc.yaml | 2 + 18 files changed, 102 insertions(+), 567 deletions(-) rename content/reference/cli/docker/{image/build.md => build-legacy.md} (53%) diff --git a/content/build/building/best-practices.md b/content/build/building/best-practices.md index d2c6171cad7..2d8eb515761 100644 --- a/content/build/building/best-practices.md +++ b/content/build/building/best-practices.md @@ -607,7 +607,7 @@ as part of your build. `ADD` is better than manually adding files using something like `wget` and `tar`, because it ensures a more precise build cache. `ADD` also has built-in support for checksum validation of the remote resources, and a protocol for parsing branches, tags, and subdirectories from -[Git URLs](../../reference/cli/docker/image/build.md#git-repositories). +[Git URLs](../../reference/cli/docker/buildx/build.md#git-repositories). The following example uses `ADD` to download a .NET installer. Combined with multi-stage builds, only the .NET runtime remains in the final stage, no diff --git a/content/build/building/packaging.md b/content/build/building/packaging.md index 0a0e40381aa..77cad11a31b 100644 --- a/content/build/building/packaging.md +++ b/content/build/building/packaging.md @@ -39,7 +39,7 @@ Some projects may need distinct Dockerfiles for specific purposes. A common convention is to name these `.Dockerfile`. You can specify the Dockerfile filename using the `--file` flag for the `docker build` command. Refer to the -[`docker build` CLI reference](../../reference/cli/docker/image/build.md#file) +[`docker build` CLI reference](../../reference/cli/docker/buildx/build.md#file) to learn about the `--file` flag. > **Note** diff --git a/content/build/building/variables.md b/content/build/building/variables.md index ed1e705e0f8..b2241f59888 100644 --- a/content/build/building/variables.md +++ b/content/build/building/variables.md @@ -117,7 +117,7 @@ $ docker build --build-arg NODE_VERSION=current . For more information on how to use build arguments, refer to: - [`ARG` Dockerfile reference](../../reference/dockerfile.md#arg) -- [`docker build --build-arg` reference](../../reference/cli/docker/image/build.md#build-arg) +- [`docker build --build-arg` reference](../../reference/cli/docker/buildx/build.md#build-arg) ## `ENV` usage example diff --git a/content/build/guide/export.md b/content/build/guide/export.md index e695ef44c42..92f68924e63 100644 --- a/content/build/guide/export.md +++ b/content/build/guide/export.md @@ -103,7 +103,7 @@ This is explored later on in this guide. Related information: -- [`docker build --output` CLI reference](../../reference/cli/docker/image/build.md#output) +- [`docker build --output` CLI reference](../../reference/cli/docker/buildx/build.md#output) - [Build exporters](../exporters/index.md) ## Next steps diff --git a/content/build/guide/intro.md b/content/build/guide/intro.md index 32ce6f13121..10892aa0d52 100644 --- a/content/build/guide/intro.md +++ b/content/build/guide/intro.md @@ -160,7 +160,7 @@ container image and created a container from it. Related information: - [Dockerfile reference](../../reference/dockerfile.md) -- [`docker build` CLI reference](../../reference/cli/docker/image/build.md) +- [`docker build` CLI reference](../../reference/cli/docker/buildx/build.md) - [`docker run` CLI reference](../../reference/cli/docker/container/run.md) ## Next steps diff --git a/content/docker-hub/builds/advanced.md b/content/docker-hub/builds/advanced.md index 88251bd3d06..dac9395e852 100644 --- a/content/docker-hub/builds/advanced.md +++ b/content/docker-hub/builds/advanced.md @@ -115,11 +115,11 @@ $ docker build --build-arg CUSTOM=$VAR -f $DOCKERFILE_PATH -t $IMAGE_NAME . > **Important** > -> A `hooks/build` file overrides the basic [docker build](../../reference/cli/docker/image/build.md) command used by the builder, so you must include a similar build command in the hook or +> A `hooks/build` file overrides the basic `docker build` command used by the builder, so you must include a similar build command in the hook or the automated build fails. { .important } -Refer to the [docker build documentation](../../reference/cli/docker/image/build.md#build-arg) +Refer to the [docker build documentation](../../reference/cli/docker/buildx/build.md#build-arg) to learn more about Docker build-time variables. #### Push to multiple repositories diff --git a/content/guides/use-case/nlp/language-translation.md b/content/guides/use-case/nlp/language-translation.md index 02b555cf7ff..4fc8b37d92d 100644 --- a/content/guides/use-case/nlp/language-translation.md +++ b/content/guides/use-case/nlp/language-translation.md @@ -262,7 +262,7 @@ To run the application using Docker: this case) is sent to the Docker daemon to enable the build. It includes all the files and subdirectories in the specified directory. - For more details, see the [docker build CLI reference](/reference/cli/docker/image/build/). + For more details, see the [docker build CLI reference](/reference/cli/docker/buildx/build/). Docker outputs several logs to your console as it builds the image. You'll see it download and install the dependencies. Depending on your network diff --git a/content/guides/use-case/nlp/named-entity-recognition.md b/content/guides/use-case/nlp/named-entity-recognition.md index da3cf451582..f3d8722bedb 100644 --- a/content/guides/use-case/nlp/named-entity-recognition.md +++ b/content/guides/use-case/nlp/named-entity-recognition.md @@ -269,7 +269,7 @@ To run the application using Docker: this case) is sent to the Docker daemon to enable the build. It includes all the files and subdirectories in the specified directory. - For more details, see the [docker build CLI reference](/reference/cli/docker/image/build/). + For more details, see the [docker build CLI reference](/reference/cli/docker/buildx/build/). Docker outputs several logs to your console as it builds the image. You'll see it download and install the dependencies. Depending on your network diff --git a/content/guides/use-case/nlp/sentiment-analysis.md b/content/guides/use-case/nlp/sentiment-analysis.md index e982a1f770b..6f6a5ec3e5e 100644 --- a/content/guides/use-case/nlp/sentiment-analysis.md +++ b/content/guides/use-case/nlp/sentiment-analysis.md @@ -287,7 +287,7 @@ To run the application using Docker: feature, so subsequent builds can be faster. The console will return to the prompt when it's complete. - For more details, see the [docker build CLI reference](/reference/cli/docker/image/build/). + For more details, see the [docker build CLI reference](/reference/cli/docker/buildx/build/). 2. Run the image as a container. diff --git a/content/guides/use-case/nlp/text-classification.md b/content/guides/use-case/nlp/text-classification.md index d0e43ee7666..7efae0bc45b 100644 --- a/content/guides/use-case/nlp/text-classification.md +++ b/content/guides/use-case/nlp/text-classification.md @@ -341,7 +341,7 @@ To run the application using Docker: this case) is sent to the Docker daemon to enable the build. It includes all the files and subdirectories in the specified directory. - For more details, see the [docker build CLI reference](/reference/cli/docker/image/build/). + For more details, see the [docker build CLI reference](/reference/cli/docker/buildx/build/). Docker outputs several logs to your console as it builds the image. You'll see it download and install the dependencies. Depending on your network diff --git a/content/guides/use-case/nlp/text-summarization.md b/content/guides/use-case/nlp/text-summarization.md index b916a121a16..d074c48363a 100644 --- a/content/guides/use-case/nlp/text-summarization.md +++ b/content/guides/use-case/nlp/text-summarization.md @@ -276,7 +276,7 @@ To run the application using Docker: this case) is sent to the Docker daemon to enable the build. It includes all the files and subdirectories in the specified directory. - For more details, see the [docker build CLI reference](/reference/cli/docker/image/build/). + For more details, see the [docker build CLI reference](/reference/cli/docker/buildx/build/). Docker outputs several logs to your console as it builds the image. You'll see it download and install the dependencies. Depending on your network diff --git a/content/language/rust/build-images.md b/content/language/rust/build-images.md index 041f9fe2337..1a573370418 100644 --- a/content/language/rust/build-images.md +++ b/content/language/rust/build-images.md @@ -174,7 +174,7 @@ Related information: - [Dockerfile reference](../../reference/dockerfile.md) - [.dockerignore file](../../reference/dockerfile.md#dockerignore-file) - [docker init CLI reference](../../reference/cli/docker/init.md) - - [docker build CLI reference](../../reference/cli/docker/image/build.md) + - [docker build CLI reference](../../reference/cli/docker/buildx/build.md) ## Next steps diff --git a/content/reference/cli/docker/image/build.md b/content/reference/cli/docker/build-legacy.md similarity index 53% rename from content/reference/cli/docker/image/build.md rename to content/reference/cli/docker/build-legacy.md index 0bda22d2a2e..b28b5d83f8c 100644 --- a/content/reference/cli/docker/image/build.md +++ b/content/reference/cli/docker/build-legacy.md @@ -2,14 +2,7 @@ datafolder: engine-cli datafile: docker_image_build linkTitle: docker build -title: docker image build -aliases: -- /edge/engine/reference/commandline/image_build/ -- /engine/reference/commandline/image_build/ -- /engine/reference/commandline/build/ -- /engine/reference/commandline/builder_build/ -- /reference/cli/docker/build/ -- /reference/cli/docker/builder/build/ +title: docker build (legacy builder) layout: cli --- diff --git a/content/reference/cli/docker/buildx/build.md b/content/reference/cli/docker/buildx/build.md index a443bbd9e1a..b6e22f0d2fd 100644 --- a/content/reference/cli/docker/buildx/build.md +++ b/content/reference/cli/docker/buildx/build.md @@ -5,6 +5,13 @@ title: docker buildx build layout: cli aliases: - /engine/reference/commandline/buildx_build/ +- /edge/engine/reference/commandline/image_build/ +- /engine/reference/commandline/image_build/ +- /engine/reference/commandline/build/ +- /engine/reference/commandline/builder_build/ +- /reference/cli/docker/build/ +- /reference/cli/docker/builder/build/ +- /reference/cli/docker/image/build/ --- e9aa60c60128MB/2.284 MB (100%) endpoint: https://cdn-registry-1.docker.io/v1/ - Step 2/3 : RUN ls -lh / - ---> Running in 9c9e81692ae9 - total 24 - drwxr-xr-x 2 root root 4.0K Mar 12 2013 bin - drwxr-xr-x 5 root root 4.0K Oct 19 00:19 dev - drwxr-xr-x 2 root root 4.0K Oct 19 00:19 etc - drwxr-xr-x 2 root root 4.0K Nov 15 23:34 lib - lrwxrwxrwx 1 root root 3 Mar 12 2013 lib64 -> lib - dr-xr-xr-x 116 root root 0 Nov 15 23:34 proc - lrwxrwxrwx 1 root root 3 Mar 12 2013 sbin -> bin - dr-xr-xr-x 13 root root 0 Nov 15 23:34 sys - drwxr-xr-x 2 root root 4.0K Mar 12 2013 tmp - drwxr-xr-x 2 root root 4.0K Nov 15 23:34 usr - ---> b35f4035db3f - Step 3/3 : CMD echo Hello world - ---> Running in 02071fceb21b - ---> f52f38b7823e - Successfully built f52f38b7823e - Removing intermediate container 9c9e81692ae9 - Removing intermediate container 02071fceb21b - ``` - - This example specifies that the `PATH` is `.`, and so `tar`s all the files in the - local directory and sends them to the Docker daemon. The `PATH` specifies - where to find the files for the "context" of the build on the Docker daemon. - Remember that the daemon could be running on a remote machine and that no - parsing of the Dockerfile happens at the client side (where you're running - `docker build`). That means that all the files at `PATH` are sent, not just - the ones listed to [`ADD`](/reference/dockerfile/#add) - in the Dockerfile. - - The transfer of context from the local machine to the Docker daemon is what the - `docker` client means when you see the "Sending build context" message. - - If you wish to keep the intermediate containers after the build is complete, - you must use `--rm=false`. This doesn't affect the build cache. - - ### Build with URL - - ```console - $ docker build github.com/creack/docker-firefox - ``` - - This clones the GitHub repository, using the cloned repository as context, - and the Dockerfile at the root of the repository. You can - specify an arbitrary Git repository by using the `git://` or `git@` scheme. - - ```console - $ docker build -f ctx/Dockerfile http://server/ctx.tar.gz - - Downloading context: http://server/ctx.tar.gz [===================>] 240 B/240 B - Step 1/3 : FROM busybox - ---> 8c2e06607696 - Step 2/3 : ADD ctx/container.cfg / - ---> e7829950cee3 - Removing intermediate container b35224abf821 - Step 3/3 : CMD /bin/ls - ---> Running in fbc63d321d73 - ---> 3286931702ad - Removing intermediate container fbc63d321d73 - Successfully built 377c409b35e4 - ``` - - This sends the URL `http://server/ctx.tar.gz` to the Docker daemon, which - downloads and extracts the referenced tarball. The `-f ctx/Dockerfile` - parameter specifies a path inside `ctx.tar.gz` to the `Dockerfile` used - to build the image. Any `ADD` commands in that `Dockerfile` that refer to local - paths must be relative to the root of the contents inside `ctx.tar.gz`. In the - example above, the tarball contains a directory `ctx/`, so the `ADD - ctx/container.cfg /` operation works as expected. - - ### Build with `-` - - ```console - $ docker build - < Dockerfile - ``` - - This example reads a Dockerfile from `STDIN` without context. Due to the lack of a - context, the command doesn't send contents of any local directory to the Docker daemon. - Since there is no context, a Dockerfile `ADD` only works if it refers to a - remote URL. - - ```console - $ docker build - < context.tar.gz - ``` - - This example builds an image for a compressed context read from `STDIN`. - Supported formats are: `bzip2`, `gzip` and `xz`. - - ### Use a .dockerignore file - - ```console - $ docker build . - - Uploading context 18.829 MB - Uploading context - Step 1/2 : FROM busybox - ---> 769b9341d937 - Step 2/2 : CMD echo Hello world - ---> Using cache - ---> 99cc1ad10469 - Successfully built 99cc1ad10469 - $ echo ".git" > .dockerignore - $ docker build . - Uploading context 6.76 MB - Uploading context - Step 1/2 : FROM busybox - ---> 769b9341d937 - Step 2/2 : CMD echo Hello world - ---> Using cache - ---> 99cc1ad10469 - Successfully built 99cc1ad10469 - ``` - - This example shows the use of the `.dockerignore` file to exclude the `.git` - directory from the context. You can see its effect in the changed size of the - uploaded context. The builder reference contains detailed information on - [creating a .dockerignore file](/reference/dockerfile/#dockerignore-file). - - When using the [BuildKit backend](/build/buildkit/), - `docker build` searches for a `.dockerignore` file relative to the Dockerfile - name. For example, running `docker build -f myapp.Dockerfile .` first looks - for an ignore file named `myapp.Dockerfile.dockerignore`. If it can't find such a file, - if present, it uses the `.dockerignore` file. Using a Dockerfile based - `.dockerignore` is useful if a project contains multiple Dockerfiles that expect - to ignore different sets of files. - - ### Tag an image (-t, --tag) {#tag} - - ```console - $ docker build -t vieux/apache:2.0 . - ``` - - This examples builds in the same way as the previous example, but it then tags the resulting - image. The repository name will be `vieux/apache` and the tag `2.0`. - - [Read more about valid tags](/reference/cli/docker/image/tag/). - - You can apply multiple tags to an image. For example, you can apply the `latest` - tag to a newly built image and add another tag that references a specific - version. - - For example, to tag an image both as `whenry/fedora-jboss:latest` and - `whenry/fedora-jboss:v2.1`, use the following: - - ```console - $ docker build -t whenry/fedora-jboss:latest -t whenry/fedora-jboss:v2.1 . - ``` - - ### Specify a Dockerfile (-f, --file) {#file} - - ```console - $ docker build -f Dockerfile.debug . - ``` - - This uses a file called `Dockerfile.debug` for the build instructions - instead of `Dockerfile`. - - ```console - $ curl example.com/remote/Dockerfile | docker build -f - . - ``` - - The above command uses the current directory as the build context and reads - a Dockerfile from stdin. - - ```console - $ docker build -f dockerfiles/Dockerfile.debug -t myapp_debug . - $ docker build -f dockerfiles/Dockerfile.prod -t myapp_prod . - ``` - - The above commands build the current build context (as specified by the - `.`) twice. Once using a debug version of a `Dockerfile` and once using a - production version. - - ```console - $ cd /home/me/myapp/some/dir/really/deep - $ docker build -f /home/me/myapp/dockerfiles/debug /home/me/myapp - $ docker build -f ../../../../dockerfiles/debug /home/me/myapp - ``` - - These two `docker build` commands do the exact same thing. They both use the - contents of the `debug` file instead of looking for a `Dockerfile` and use - `/home/me/myapp` as the root of the build context. Note that `debug` is in the - directory structure of the build context, regardless of how you refer to it on - the command line. - - > **Note** - > - > `docker build` returns a `no such file or directory` error if the - > file or directory doesn't exist in the uploaded context. This may - > happen if there is no context, or if you specify a file that's - > elsewhere on the Host system. The context is limited to the current - > directory (and its children) for security reasons, and to ensure - > repeatable builds on remote Docker hosts. This is also the reason why - > `ADD ../file` doesn't work. - - ### Use a custom parent cgroup (--cgroup-parent) {#cgroup-parent} - - When you run `docker build` with the `--cgroup-parent` option, the daemon runs the containers - used in the build with the [corresponding `docker run` flag](/reference/cli/docker/container/run/#cgroup-parent). - - ### Set ulimits in container (--ulimit) {#ulimit} - - Using the `--ulimit` option with `docker build` causes the daemon to start each build step's - container using those [`--ulimit` flag values](/reference/cli/docker/container/run/#ulimit). - - ### Set build-time variables (--build-arg) {#build-arg} - - You can use `ENV` instructions in a Dockerfile to define variable values. These - values persist in the built image. Often persistence isn't what you want. Users - want to specify variables differently depending on which host they build an - image on. - - A good example is `http_proxy` or source versions for pulling intermediate - files. The `ARG` instruction lets Dockerfile authors define values that users - can set at build-time using the `--build-arg` flag: - - ```console - $ docker build --build-arg HTTP_PROXY=http://10.20.30.2:1234 --build-arg FTP_PROXY=http://40.50.60.5:4567 . - ``` - - This flag allows you to pass the build-time variables that are - accessed like regular environment variables in the `RUN` instruction of the - Dockerfile. These values don't persist in the intermediate or final images - like `ENV` values do. You must add `--build-arg` for each build argument. - - Using this flag doesn't alter the output you see when the build process echoes the`ARG` lines from the - Dockerfile. - - For detailed information on using `ARG` and `ENV` instructions, see the - [Dockerfile reference](/reference/dockerfile/). - - You can also use the `--build-arg` flag without a value, in which case the daemon - propagates the value from the local environment into the Docker container it's building: - - ```console - $ export HTTP_PROXY=http://10.20.30.2:1234 - $ docker build --build-arg HTTP_PROXY . - ``` - - This example is similar to how `docker run -e` works. Refer to the [`docker run` documentation](/reference/cli/docker/container/run/#env) - for more information. - - ### Optional security options (--security-opt) {#security-opt} - - This flag is only supported on a daemon running on Windows, and only supports - the `credentialspec` option. The `credentialspec` must be in the format - `file://spec.txt` or `registry://keyname`. - ### Specify isolation technology for container (--isolation) {#isolation} This option is useful in situations where you are running Docker containers on @@ -703,199 +410,11 @@ examples: |- Specifying the `--isolation` flag without a value is the same as setting `--isolation="default"`. - ### Add entries to container hosts file (--add-host) {#add-host} - - You can add other hosts into a build container's `/etc/hosts` file by using one - or more `--add-host` flags. This example adds static addresses for hosts named - `my-hostname` and `my_hostname_v6`: - - ```console - $ docker build --add-host my_hostname=8.8.8.8 --add-host my_hostname_v6=2001:4860:4860::8888 . - ``` - - If you need your build to connect to services running on the host, you can use - the special `host-gateway` value for `--add-host`. In the following example, - build containers resolve `host.docker.internal` to the host's gateway IP. - - ```console - $ docker build --add-host host.docker.internal=host-gateway . - ``` - - You can wrap an IPv6 address in square brackets. - `=` and `:` are both valid separators. - Both formats in the following example are valid: - - ```console - $ docker build --add-host my-hostname:10.180.0.1 --add-host my-hostname_v6=[2001:4860:4860::8888] . - ``` - - ### Specifying target build stage (--target) {#target} - - When building a Dockerfile with multiple build stages, you can use the `--target` - option to specify an intermediate build stage by name as a final stage for the - resulting image. The daemon skips commands after the target stage. - - ```dockerfile - FROM debian AS build-env - # ... - - FROM alpine AS production-env - # ... - ``` - - ```console - $ docker build -t mybuildimage --target build-env . - ``` - - ### Custom build outputs (--output) {#output} - - > **Note** - > - > This feature requires the BuildKit backend. You can either - > [enable BuildKit](/build/buildkit/#getting-started) or - > use the [buildx](https://github.com/docker/buildx) plugin which provides more - > output type options. - - By default, a local container image is created from the build result. The - `--output` (or `-o`) flag allows you to override this behavior, and specify a - custom exporter. Custom exporters allow you to export the build - artifacts as files on the local filesystem instead of a Docker image, which can - be useful for generating local binaries, code generation etc. - - The value for `--output` is a CSV-formatted string defining the exporter type - and options that supports `local` and `tar` exporters. - - The `local` exporter writes the resulting build files to a directory on the client side. The - `tar` exporter is similar but writes the files as a single tarball (`.tar`). - - If you specify no type, the value defaults to the output directory of the local - exporter. Use a hyphen (`-`) to write the output tarball to standard output - (`STDOUT`). - - The following example builds an image using the current directory (`.`) as a build - context, and exports the files to a directory named `out` in the current directory. - If the directory does not exist, Docker creates the directory automatically: - - ```console - $ docker build -o out . - ``` - - The example above uses the short-hand syntax, omitting the `type` options, and - thus uses the default (`local`) exporter. The example below shows the equivalent - using the long-hand CSV syntax, specifying both `type` and `dest` (destination - path): - - ```console - $ docker build --output type=local,dest=out . - ``` - - Use the `tar` type to export the files as a `.tar` archive: - - ```console - $ docker build --output type=tar,dest=out.tar . - ``` - - The example below shows the equivalent when using the short-hand syntax. In this - case, `-` is specified as destination, which automatically selects the `tar` type, - and writes the output tarball to standard output, which is then redirected to - the `out.tar` file: - - ```console - $ docker build -o - . > out.tar - ``` - - The `--output` option exports all files from the target stage. A common pattern - for exporting only specific files is to do multi-stage builds and to copy the - desired files to a new scratch stage with [`COPY --from`](/reference/dockerfile/#copy). - - The example, the `Dockerfile` below uses a separate stage to collect the - build artifacts for exporting: - - ```dockerfile - FROM golang AS build-stage - RUN go get -u github.com/LK4D4/vndr - - FROM scratch AS export-stage - COPY --from=build-stage /go/bin/vndr / - ``` - - When building the Dockerfile with the `-o` option, the command only exports the files from the final - stage to the `out` directory, in this case, the `vndr` binary: - - ```console - $ docker build -o out . - - [+] Building 2.3s (7/7) FINISHED - => [internal] load build definition from Dockerfile 0.1s - => => transferring dockerfile: 176B 0.0s - => [internal] load .dockerignore 0.0s - => => transferring context: 2B 0.0s - => [internal] load metadata for docker.io/library/golang:latest 1.6s - => [build-stage 1/2] FROM docker.io/library/golang@sha256:2df96417dca0561bf1027742dcc5b446a18957cd28eba6aa79269f23f1846d3f 0.0s - => => resolve docker.io/library/golang@sha256:2df96417dca0561bf1027742dcc5b446a18957cd28eba6aa79269f23f1846d3f 0.0s - => CACHED [build-stage 2/2] RUN go get -u github.com/LK4D4/vndr 0.0s - => [export-stage 1/1] COPY --from=build-stage /go/bin/vndr / 0.2s - => exporting to client 0.4s - => => copying files 10.30MB 0.3s - - $ ls ./out - vndr - ``` - - ### Specifying external cache sources (--cache-from) {#cache-from} - - > **Note** - > - > This feature requires the BuildKit backend. You can either - > [enable BuildKit](/build/buildkit/#getting-started) or - > use the [buildx](https://github.com/docker/buildx) plugin. The previous - > builder has limited support for reusing cache from pre-pulled images. - - In addition to local build cache, the builder can reuse the cache generated from - previous builds with the `--cache-from` flag pointing to an image in the registry. - - To use an image as a cache source, cache metadata needs to be written into the - image on creation. You can do this by setting `--build-arg BUILDKIT_INLINE_CACHE=1` - when building the image. After that, you can use the built image as a cache source - for subsequent builds. - - Upon importing the cache, the builder only pulls the JSON metadata from the - registry and determine possible cache hits based on that information. If there - is a cache hit, the builder pulls the matched layers into the local environment. - - In addition to images, the cache can also be pulled from special cache manifests - generated by [`buildx`](https://github.com/docker/buildx) or the BuildKit CLI - (`buildctl`). These manifests (when built with the `type=registry` and `mode=max` - options) allow pulling layer data for intermediate stages in multi-stage builds. - - The following example builds an image with inline-cache metadata and pushes it - to a registry, then uses the image as a cache source on another machine: - - ```console - $ docker build -t myname/myapp --build-arg BUILDKIT_INLINE_CACHE=1 . - $ docker push myname/myapp - ``` - - After pushing the image, the image is used as cache source on another machine. - BuildKit automatically pulls the image from the registry if needed. - - On another machine: - - ```console - $ docker build --cache-from myname/myapp . - ``` - - ### Set the networking mode for the RUN instructions during build (--network) {#network} - - #### Overview - - Available options for the networking mode are: - - - `default` (default): Run in the default network. - - `none`: Run with no network access. - - `host`: Run in the host’s network environment. + ### Optional security options (--security-opt) {#security-opt} - Find more details in the [Dockerfile documentation](/reference/dockerfile/#run---network). + This flag is only supported on a daemon running on Windows, and only supports + the `credentialspec` option. The `credentialspec` must be in the format + `file://spec.txt` or `registry://keyname`. ### Squash an image's layers (--squash) (experimental) {#squash} diff --git a/data/toc.yaml b/data/toc.yaml index a10873d46ae..ea2b7011086 100644 --- a/data/toc.yaml +++ b/data/toc.yaml @@ -340,6 +340,8 @@ Reference: title: docker (base command) - path: /reference/cli/docker/build/ title: docker build + - path: /reference/cli/docker/build-legacy/ + title: docker build (legacy builder) - sectiontitle: docker builder section: - path: /reference/cli/docker/builder/