January Virtual Meetup Recap Improve Image Builds Using the Features in BuildKit

In this , I share how to improve image builds using the features in . is an alternative builder

In this , I share how to improve image builds using the features in . is an alternative builder with great features like caching, concurrency and the ability to separate your image build into multiple stages – which is useful for separating the build environment from the runtime environment.  The default builder in Docker is the legacy builder. This is recommended for use when you need support for Windows. However, in nearly every other case, using BuildKit is recommended because of the fast build time, ability to use custom BuildKit front-ends, building stages in parallel and other features. Catch the full replay below and view the to learn: I also covered a few tools that I use in my workflow, namely: And finally, answered some of your questions:   If your workflow involves building images often, then we recommend that you do set BuildKit as the default builder. Here is how to enable in the docker daemon config.    Support for BuildKit was added in docker-compose 1.25.0 which can be enabled by setting DOCKER_BUILDKIT=1 and COMPOSE_DOCKER_CLI_BUILD=1.   In addition to the features presented, in many cases. BuildKit secrets are a good way to use a secret at build time, without saving the secret in the image. Think of it as pulling a private git repo without saving your ssh key to the image. For runtime, it’s often different compose files to support compose vs swarm mode, each mounting the secret a different way, i.e. a volume vs. swarm secret.   The only reference to BuildKit I was able to find refers to .   No, the caches are separate.   The test step can be a separate stage in the build. If the test step requires a special tool to be installed, it can be a second final stage. If your multi-stage build increases in complexity, take a look at CI/CD tools. The download can be significantly faster than redoing all the work.   The legacy builder, as well as BuildKit, produces identical (or rather equivalent) images.   No. No. Anyone have any advice here?    If the question is referring to Spotify’s Dockerfile Maven plugin (which is unmaintained), the answer is no. Other plugins may be able to use BuildKit when providing the environment variable DOCKER_BUILDKIT=1. Instead of changing the way the client works, you could configure the daemon to use BuildKit by default (see first question above).   I think that containerd has gained more visibility and has been adopted by many cloud providers as the runtime in Kubernetes offerings. But I have no experience myself with CRI-O. To be notified of upcoming meetups, join the using your Docker ID or on .