Docker Bake is now generally available | Hacker News Reader

Docker Bake is now generally available

docker.com

34 pointstodsacerdoti20 comments

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

From: https://docs.docker.com/build/bake/

About time. https://github.com/containers/ramalama also working on this

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].

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...

Is there a way to specify an image’s build dependencies without manually grouping targets for parallelization?

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...

Have you figured it out?

I've been playing with it for the past hour this morning. It looks like it does everything I want it to do and more.

It all "just works". No "depends_on", you just specify your "FROM" as usual and it just figures it all out for you.

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.

Kind of, you use contexts.

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! I hope this is part of the OSS interface so eg podman can implement something similar.

I can’t remember the last time I ran docker locally. All my docker builds now happen on remote clusters.

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.

Earthly is a very similar idea too.

Why is this flagged?

Good question. HN flagging either needs more transparency or an overhaul.

Flagged an actual major technology release and it hasn't been fixed in a week. What a joke of a "tech forum".

I'm not sure I understand the use case. What problems does this solve that a nice Docker Compose file doesn't?

Compose is orchestrating the containers

Bake builds the containers from source

Make Docker chat so that we don't need to learn it again.

Why was this post flagged?

Reply on news.ycombinator.com