cross-build

cross-build

$ cat Makefile
cross-build:
	@docker buildx create --name mybuilder --use
	@docker buildx build --platform ${BUILDX_PLATFORMS} -t ${PROD_IMAGE} --push ./app

$ BUILDX_BINARY_URL="https://github.com/docker/buildx/releases/download/v0.4.2/buildx-v0.4.2.linux-amd64"
$ curl --output docker-buildx \
       --silent --show-error --location --fail --retry 3 \
        "$BUILDX_BINARY_URL"
$ mkdir -p ~/.docker/cli-plugins
$ mv docker-buildx ~/.docker/cli-plugins/
$ chmod a+x ~/.docker/cli-plugins/docker-buildx
$ docker buildx install
$ # Run binfmt
$ docker run --rm --privileged tonistiigi/binfmt:latest --install "$BUILDX_PLATFORMS"
$ export BUILDX_PLATFORMS="linux/amd64,linux/arm64,linux/ppc64le,linux/s390x,linux/386,linux/arm/v7,linux/arm/v6"
$ BUILDX_PLATFORMS="$BUILDX_PLATFORMS" make cross-build
  

Here, emulation means that from a specific machine (for example, say Intel machine) we can build an image targeted for a different architecture-supported machine (for example, a raspberry pi machine)

So, what we can do with buildx is, in simplest terms, we can build an image on Mac, targeted for Raspberry Pi, push it to dockerhub and then on our Raspberry Pi machine, we can pull that image and run it.

1. It is quicker to do on the emulator rather than the actual device.
2. It provides us with – building and testing on the device, in a loop, without being actually connected to the device being targeted, i.e. for which the image is being built.
3. The other advantage here is, we can build a genuine Build farm.

the docker buildx will build the manifest for me at the output of this command but using the 2 extra parameters –platform and –push :

–platform : This parameter is used for listing all of the platforms which are targeted, i.e. for which the images are to be built (for example, linux/amd64, linux/arm64, darwin/amd64, etc). And docker buildx will reach out to each of these elements in the farm and give them the right platform to build the image. And when we use this image in docker run or docker service, docker picks up the correct image based on the node’s platform.

–push : This parameter is used when the images have been built for all targeted platforms and now the images have to be pushed to the registry ( the public registry, by default : dockerhub ).

So, now we can say that we get a multi-arch image with buildx that we can use anywhere with just a single command. And docker buildx will reach out to each of these elements in the farm and give them the right platform to build.

Link: https://blog.knoldus.com/a-word-on-docker-buildx/

We can build multi-platform images using three different strategies that are supported by Buildx and Dockerfiles:

1. Using the QEMU emulation support in the kernel.In particular, this approach is considered to be the most suitable approach when one is working on a Docker Desktop ( usually Mac or Windows ).
2. Building on multiple native nodes using the same builder instance.This approach is suitable for covering all the use-cases that are not handled efficiently by QEMU approach, and as a result we achieve better performance.
3. Using a stage in Dockerfile to cross-compile to different architectures.In this case, multi-stage builds in Dockerfiles can be effectively used to build binaries for the platform specified with --platform using the native architecture of the build node. A list of build arguments like BUILDPLATFORM and TARGETPLATFORM is available automatically inside your Dockerfile.

Link: https://blog.knoldus.com/a-word-on-docker-buildx/