Snorkeling around Docker Buildx
Before Diving in
This is an attempt to explain and explore how teams can use Docker Buildx for delivering Docker images.
Since we will not be covering all features around Docker Buildx, this is a wide snorkel rather than a deep dive.
This is a quick article for developers who have yet to use Docker Buildx but are curious on its use-cases.
What is Docker Buildx?
Let's take a few steps back before plunging in.
We use Docker Build to build Docker images from Dockerfiles.
Since 18.09, BuildKit was introduced as an improved version of the previous builder. As an example, we can mount secrets when building our images with BuildKit. BuildKit will also ensure that these secrets are not exposed within the built image's layers.
Buildx builds (no pun intended) on top of BuildKit. It comes with more operations besides image-building, as you can see from its available commands. Importantly, Buildx provides features for caching and cross-platform image builds.
Why should we use Docker Buildx?
For software teams shipping Docker images often, Docker Buildx can be an important tool in the box.
Caching image layers ensure a next rebuild of the image will be faster.
Before, teams would need various machines on different platforms to build images for each platform. For example, we would need a ARM64 machine to build a Docker image for ARM64 architectures.
With Docker Buildx's cross-platform feature, we can now use the same AMD64 machine to build both AMD64 and ARM64 Docker images.
Why is it relevant in CI/CD?
Many teams are building Docker images as part of their CI/CD pipelines. Hence, they can lean on the build cache and cross-platform capabilities of Docker Buildx to build various images faster and cheaper.
Let's discuss the two mentioned features a little deeper.
Caching
This pertains to the cache-from and cache-to options with the docker buildx build command.
Docker Buildx allows you to choose your caching strategy (e.g., inline, local, registry and etc), and each comes with its pros and cons.
Your choice will depend largely on your team's philosophy and the CI/CD provider.
For example, you can leverage GitHub's Cache service when running Docker Buildx on GitHub Actions.
For CircleCI users, you may find my exploratory project here useful.
Cross-platform
When building an ARM64 Docker image on a CI/CD pipeline, you would need to do so on an ARM64-based machine runner then (if not using Buildx).
Depending on your CI/CD provider, there may not be ARM64 support.
This can be worked around, if your CI/CD provider allows you to “bring you own runners” (also known as self-hosted runners). GitHub Actions and CircleCI support self-hosted runners. However, it does mean someone in your team now has to manage these runners on your infrastructure.
With Docker Buildx, we can now build cross-platform images within any arbitrary machine runner.
This can be a big win for team that prefers not owning additional infrastructures.
Resurfacing to Shore
We have explored the appeal of Docker Buildx, particularly in a CI/CD context here. As mentioned, it is ultimately a tool. For teams building Docker images in their CI/CD pipelines, I do encourage you to look into Docker Buildx if you have not!