TLDR: feature and file spec. At Shipyard, we’ve found it quite useful, and wanted to share how you can get started. You can use it to save your build config: swap long Build commands with a simple call to bake.
What is Docker Bake?
Docker Bake is an experimental feature that allows users to store their Docker build config in a file format, instead of as CLI flags. Once you define your images’ options in a “Bake file” (a declarative file with a YAML, HCL, or JSON format) and run docker buildx bake, is also a great option for storing Docker container-specific configuration. So how is Bake different from a Compose file? Docker Bake is a tool for Docker ) because it supports a more feature-complete Bake spec than the others. A valid Bake file should be called docker-bake followed by your chosen file extension.
Docker Bake supports multiple Bake files within a project, and will read from all of them, using Bake’s inheritance rules for overrides.
2. Porting over your Docker config
Next, we’ll take our Docker build config options and transfer them to our Bake file. Here’s the docker build command that we want to store:
docker build \
-f frontend/Dockerfile \
-t frontend:v1.0.2 \
--no-cache \
--platform linux/amd64,linux/386, linux/arm64 \
.
Using docker-bake.hcl as our default file, we can convert these flags to a readable file format:
target "frontend" {
context = "."
dockerfile = "frontend/Dockerfile"
tags = ["frontend:v1.0.2"]
no-cache = true
platforms = ["linux/amd64", "linux/386", "linux/arm64"]
}
One of the perks of Bake is that you can define build configs for multiple images, then have them build in parallel, thanks to Buildx’s use of BuildKit. In this example, we’re taking our above config and adding another service: api :
group "default" {
targets = ["frontend", "api"]
}
target "frontend" {
context = "."
dockerfile = "frontend/Dockerfile"
tags = ["frontend:v1.0.2"]
no-cache = true
platforms = ["linux/amd64", "linux/386", "linux/arm64"]
}
target "api" {
context = "."
dockerfile = "api/Dockerfile"
args = {
NODE_ENV = "development"
}
tags = ["api:v3"]
platforms = ["linux/amd64", "linux/386", "linux/arm64"]
}
3. Invoking Docker Bake
Finally, you can build your images with Bake from your Bake file by running docker buildx bake.
What if you only want to build a certain target from the file? You can specify that. For example, in our Bake file, we’ve defined a frontend target. The syntax to build that is simply docker buildx bake frontend.
Docker Bake also allows users to define groups. Above, we have a default group. We can define as many groupings as we need, depending on how we need to mix/match build definitions. We invoke a group build for default with the syntax docker buildx bake default.
Using Bake with Compose
Docker understands that your image build config already lives in your Docker Compose definition. Bake’s file lookup order checks for a Compose file first, and uses its configuration as a base. If you also have a Bake file, it will override any conflicting flags/options. However, if your Compose already has the config you need, you won’t need a separate Bake file.
In Compose, each container is defined as a service. This translates to a Bake target. For example, if you have a Compose file with a service named proxy, you’ll be able to run docker buildx bake proxy to get just that container built.
You can use the --print flag to verify how Bake has interpreted your build configs. This will output the complete HCL that Bake uses to build, pulled together from both Bake and Compose files.
Beyond Bake
Once you’re ready to test your Dockerized application, you’ll want to deploy it to a production-like preview environment. That’s where
SOCIAL SHARE CARD GENERATOR