Set buildx as default builder

[crazy-max]

This is a first part to the effort to migrate users to buildx as the default builder.

tldr;

The default experience will be the same as the current DOCKER_BUILDKIT=1 experience. This was the default experience for Docker Desktop and we are unifying the experience to be the same for Linux distributions as well.

All Docker packages will contain buildx by default. The user does not need to install anything else. If a third-party package distributes CLI today without buildx, it may be necessary to update its release pipeline.

Context

There are currently four different ways that one can build locally with Docker:

• The legacy builder in Docker Engine: DOCKER_BUILDKIT=0 docker build .
• BuildKit in Docker Engine: DOCKER_BUILDKIT=1 docker build .
• Buildx CLI plugin with the Docker driver: docker buildx build .
• Buildx CLI plugin with the Container driver: docker buildx create && docker buildx build .

The current state not only confuses users who do not understand the differences between our build experiences, it also contradicts with where we are investing our build engineering effort: in Buildx and BuildKit.

What is buildx?

Buildx is a CLI tool that, combined with the server-side component BuildKit, provides Docker's next generation container build system. Buildx is architected so that it can work with different container runtimes through drivers. Some of the drivers (container and kubernetes) use a containerized version of BuildKit which means that the build tool chain can be updated independently of other container tooling.

Key features of buildx include:

• Multi-platform builds using QEMU binary emulation or native builders
• Parallel builds across multiple builder nodes
• Support for different container runtimes (Docker, Kubernetes)
• Standalone architecture (for container and kubernetes drivers)
• (Experimental) high-level build tooling with bake

What I did

Forward CLI build command

Docker branded build commands will by default be invoked by buildx client and go to a BuildKit based backend:

• docker build forwarded to docker buildx build
• docker image build forwarded to docker buildx build
• docker builder forwarded to docker buildx

Remove BuildKit implementation

• Remove BuildKit implementation code and linked build flags (now forwarded to buildx).

DOCKER_BUILDKIT=0 fallback

• The legacy builder invocation code will remain in CLI for now in a frozen state. If the environment variable is set, it will be used instead.
• Build triggered this way issue a warning for an unoptimized build (will be replaced with a deprecation message at some point in the future).

Default behavior for WCOW

• WCOW build command should point to the legacy builder by default. Note that this does not mean Windows clients that should default to buildx but windows containers reported from server-side.

Missing plugin

• If Buildx plugin is missing or broken, the following message will be displayed and fall back to the legacy builder:

$ docker build .
DEPRECATED: The legacy builder is deprecated and will be removed in a future release.
            Install the buildx component to build images with BuildKit:
            https://docs.docker.com/go/buildx/

Sending build context to Docker daemon ...
...

• But if builder is enforced with DOCKER_BUILDKIT=1 and plugin is missing or broken, cmd will fail:

$ DOCKER_BUILDKIT=1 docker build .
ERROR: BuildKit is enabled but the buildx component is missing or broken.
       Install the buildx component to build images with BuildKit:
       https://docs.docker.com/go/buildx/

• Add deprecation note entry about legacy builder fallback

Documentation

Update documentation:

• Here
• docker.github.io

How to verify it

$ docker buildx bake binary
$ ./build/docker build .

cc @tonistiigi @thaJeztah @justincormack @mikeparker @chris-crone

closes #3237

Signed-off-by: CrazyMax crazy-max@users.noreply.github.com