What does HackerNews think of buildkit?

concurrent, cache-efficient, and Dockerfile-agnostic builder toolkit

Language: Go

#20 in Docker
#20 in Go
#11 in Go
LXD containers on macOS at near-native speeds | Nov 2022
Expand Context ↕
https://github.com/moby/buildkit it looks like it is not, kind of?
Show HN: Depot – fast, remote Docker container builds | Sep 2022
Expand Context ↕
Not currently - Depot runs BuildKit (https://github.com/moby/buildkit) on our builders, and it does not support Windows containers to my knowledge.
Podman 4.2.0 | Aug 2022
Expand Context ↕
You can use podman with buildkit, it's just kind of a pain because you have to do it manually. It is missing some nice to have feature integrations with buildkit. The instructions are fairly clear: https://github.com/moby/buildkit
Dagger: a new way to build CI/CD pipelines | Mar 2022
Expand Context ↕
Yes :) We rely entirely on buildkit (https://github.com/moby/buildkit) to run the pipelines (`dagger` itself acts as a "compiler" and buildkit client). So anything you can do with buildkit, works out of the box with Dagger. That includes clustering.

There is a lot of ongoing work in that area in the buildkit ecosystem. For example Netflix has a distributed buildkit farm, which I believe relies on containerd storage backends to share cache data. There are also integrations to run buildkit nodes on a kubernetes cluster.

Dagger itself is obviously quite new, but buildkit itself is very mature, thanks to its integration with 'docker build'.
`COPY –chmod` reduced the size of my container image by 35% | Mar 2022
Expand Context ↕
https://github.com/moby/buildkit
Gokrazy – A Native Go Userland | Jan 2022
Expand Context ↕
Relatedly, there's also buildkit[1] and that entire ecosystem. I've been meaning to check out the experience of building containers using Nix, but either way it seems very interesting.

[1]: https://github.com/moby/buildkit
HashiCorp Waypoint | Oct 2020
Expand Context ↕
I believe BuildKit solves the dependency graph problem. Docker has shipped with it since 18.09. It is opt-in for now so you have to use e.g. `DOCKER_BUILDKIT=1 docker build ...`.

https://github.com/moby/buildkit
HashiCorp Waypoint | Oct 2020
Broadly, I agree, and I've written a lot about it in the past[0].

OCI images are not quite as bad as they used to be. Linear caching is no longer baked directly into the image format, instead it's an assumption that has been carried forward by Dockerfiles and docker build.

Docker folks are working on at least the docker build part in buildkit[1]. In the meantime though I prefer Cloud Native Buildpacks, which are able to perform layer rebasing as an update operation.

Disclosure: I have previously worked on buildpacks technology for Pivotal, now VMware.

[0] https://docs.google.com/document/d/1M2PJ_h6GzviUNHMPt7x-5POU...

[1] https://github.com/moby/buildkit

Alpine makes Python Docker builds slower, and images larger | Jan 2020
Expand Context ↕
Docker's build system has been given a huge overhaul and does create a dependency tree. It is highly efficient and even does things like support mounts for caching package downloads, build artifacts, etc.

See https://github.com/moby/buildkit. You can enable it today with `DOCKER_BUILDKIT=1 docker build ...`

There is also buildx which is an experimental tool to replace `docker build` with a new CLI: https://github.com/docker/buildx
Defence Against the Docker Arts | Apr 2019
Here’s a little known fact: “docker build” can trivially be extended to build buildpacks or CNB. Now that the buildkit refactoring is complete, Dockerfiles are just the default frontend. There’s already a buildpack frontend in the community repo, and it works great. Writing your own frontend is real straightforward.

Honestly after years of stagnation, the most exciting work on container building is now coming out of Docker. Buildkit is amazing, a real hidden gem.

See https://github.com/moby/buildkit

Goodbye Docker and Thanks for all the Fish | Mar 2019
Expand Context ↕
I would say check out buildkit, which is the tech behind "docker build"'s new builder.

I don't know if the Dockerfile format is really suitable for this, but you can now build your own format and Docker can just build it.

Basically buldkit breaks things down into a frontend format (like Dockerfile) and a frontend parser which gets specified as an image at the top of your file (`#syntax=`), the parser converts the frontend format into an intermediary language (called llb), buildkit takes the llb and passes it to a backend worker.

This all happens behind the scenes with `DOCKER_BUILDKIT=1 docker build -t myImage .`

Docker actually ships new Dockerfile features that aren't tied to a docker version this way.

Actually there are a number of new Dockerfile features that might get you what you need, even if the format isn't all that great, at least it's relatively natural to reason about. Things like cache mounts, secrets, mounting (not copying) images into a build stage's "RUN" directive, lots of great stuff.

This is all officially supported stuff.

Here's a demo of "docker build" building from a buildpack spec instead of Dockerfile: https://github.com/tonistiigi/buildkit-pack

- buildkit - https://github.com/moby/buildkit - official Docker docs - https://docs.docker.com/develop/develop-images/build_enhance... - buildkit Dockerfile docs - https://github.com/moby/buildkit/blob/master/frontend/docker...
Kaniko: Build container images in Kubernetes | Apr 2018
Does this (or could this) use Buildkit? It seems that Docker themselves are encouraging the development of an ecosystem of third-party container build tools, with buildkit as an interoperability layer. I heard good things about buildkit but haven't tried it yet.

If Kaniko authors are reading this: have you considered buildkit and, if not, would you be open to contributions based on it?

My understanding is that the official 'docker build' itself is based on Buildkit.

https://github.com/moby/buildkit