Docker Bake 101: Ditch Bash Scripts for Declarative Builds
Dive into part one of the Docker Bake practical guide series, replacing 200-line bash scripts with HCL configuration and ready-to-run code snippets.
Stock photo for illustration only, not from the actual event
- Docker Bake is a declarative orchestration tool for managing multiple container image builds simultaneously.
- It solves OS portability issues found in bash scripts, such as macOS shipping with outdated Bash 3.2.
- The series originates from conference talks delivered across France and Morocco.
- All code examples link directly to the author's GitHub repository for hands-on execution.
Part one of this two-part series on Docker Bake covers the fundamentals: what Bake is, why it exists, and the core features that make it worth adopting. Part two will focus on CI/CD integrations including Cloud Build, GitHub Actions, GitLab CI, and Dagger. This content stems from a talk the author has delivered over the past two years at conferences across France and Morocco, including DevLille, DevFest Toulouse, DevFest Lyon, Devoxx Morocco, and Cloud Native Days France, where attendees frequently expressed surprise at Bake's capabilities compared to maintaining 200-line bash scripts.
For those who prefer visual learning, a French video recording from Cloud Native Days France is available, and an English walkthrough video will soon launch on the author's YouTube channel. If you prefer reading at your own pace with copy-pasteable snippets, this article provides the companion repository where every section links to the exact file needed to run the examples yourself.
Core command-line examples for running Docker Bake include:
- Building and publishing images locally:
docker buildx bake -f vars.hcl -f docker-bake-app-and-infra.hcl --push - Printing the interpolated configuration values:
docker buildx bake -f vars.hcl -f docker-bake-app-and-infra.hcl --print - Executing linter and tests via Compose:
docker compose -f compose_lint_and_test.yaml up
Understanding the three-layer architecture of Docker's build stack clarifies how BuildKit functions as the underlying engine handling parallel stages and caching, Buildx serves as the friendly CLI frontend, and Bake acts as the orchestration layer. Transitioning from legacy bash scripts to declarative HCL eliminates shell version discrepancies across operating systems.
Stock photo for illustration only, not from the actual event
Before diving into HCL files, it is vital to clear up the layering of three terms that are often mistakenly used interchangeably. BuildKit is the modern Docker build engine replacing the legacy builder in Docker Engine 23+, handling actual heavy-lifting like parallel stages, caching, and multi-platform support. Buildx is the CLI plugin exposing BuildKit features through commands like docker buildx build, while Bake operates as a subcommand of Buildx to orchestrate multiple builds declaratively, functioning similarly to Docker Compose but tailored for building rather than running containers.
Regarding installation requirements, anyone running Docker Desktop in recent years or Linux with Docker Engine 23+ already has Buildx, BuildKit, and Bake bundled out of the box with no extra installation steps required unless dealing with unusually outdated environments.
To appreciate the motivation behind Bake, consider the friction involved when building and pushing multi-platform application and infrastructure images with provenance attestations. Traditional bash implementations quickly resort to loops and associative arrays, which demand Bash version 4 or newer. Because macOS freezes its default shell at Bash 3.2 due to GPL v3 licensing changes, these scripts fail silently on fresh Macs unless manually upgraded via Homebrew, contributing directly to the classic "works on my machine" software dilemma.
Source: Dev.to
Found something wrong in this article? Report an issue with this article
Comments
Leave a Comment