FYI: Bake is a feature of Docker Buildx that lets you define your build configuration using a declarative file, as opposed to specifying a complex CLI expression. It also lets you run multiple builds concurrently with a single invocation.
A Bake file can be written in HCL, JSON, or YAML formats, where the YAML format is an extension of a Docker Compose file
Hm, that’s interesting. Are you saying just specifying the FROM in the Dockerfile is enough? I’ve seen a trick floating around specifying from in the bake config in addition to Dockerfile.
You can create contexts that point to other targets. So in your Dockerfile you can use `FROM project-base` where `project-base` is whatever you specified in the context.
The targets documentation makes this seem like Bazel but everything is a container, so you don't have to learn the ins and outs of a build system versus using whatever tooling is most familiar + a thin Docker config layer. https://docs.docker.com/build/bake/targets/
Neat idea, I like it. Interested to see if it gets adopted more widely.
A quote from that page claims that Bake saves complexity by removing "all the flags and environment variables" from a build command, but as far as I can tell, all those flags and environment variables are still there, they're just now defined even more verbosely in an HCL file...
It's cool to see bake go GA. We've been supporting bake at Depot [0] for a while now and it is a unsung hero when it comes to building multiple images in parallel.
We help many folks adopt it for their monorepo setups in particular. With Depot, folks can get the highly parallelized builds right out of the box, but bake takes it to another level by allowing you to define all your image builds in one place like an HCL, Compose, or JSON file. We've added some extra spice to fan out builds across multiple BuildKit instances [1].
22 comments
[ 2.8 ms ] story [ 49.6 ms ] threadI can’t remember the last time I ran docker locally. All my docker builds now happen on remote clusters.
Bake builds the containers from source
A Bake file can be written in HCL, JSON, or YAML formats, where the YAML format is an extension of a Docker Compose file
From: https://docs.docker.com/build/bake/
For example, if image D depends on both B and C to be built first and images B and C depended on A.
The build order would be:
0) A builds by itself.
1) B and C builds in parallel.
2) D builds by itself.
I built a tool to do this years ago and I’d really like to retire it.
Compose ignores “depends_on” for builds: https://github.com/docker/compose/issues/6332#issuecomment-4...
You can create contexts that point to other targets. So in your Dockerfile you can use `FROM project-base` where `project-base` is whatever you specified in the context.
See "Pinning an Alpine image" here: https://docs.docker.com/build/bake/contexts/#pinning-alpine-...
Neat idea, I like it. Interested to see if it gets adopted more widely.
We help many folks adopt it for their monorepo setups in particular. With Depot, folks can get the highly parallelized builds right out of the box, but bake takes it to another level by allowing you to define all your image builds in one place like an HCL, Compose, or JSON file. We've added some extra spice to fan out builds across multiple BuildKit instances [1].
If you're interested in bake and want a go-to guide, we wrote this blog post a while back: https://depot.dev/blog/buildx-bake-deep-dive.
[0] https://depot.dev
[1] https://depot.dev/changelog/2024-06-07-depot-cli-bake-multip...