Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

BuildKit: Docker's Hidden Gem That Can Build Almost Anything

tuananh.net

Post reply on HN
Print view View original

21–30 of 80 posts

Re: BuildKit: Docker's Hidden Gem That Can Build Almost Anything

#21

Post by stackskipton »

moochmooch wrote: post #3

unfortunately, make is more well written software. I think ultimately Dockerfile was a failed iteration of Makefile. YAML & Dockerfile are poor interfaces for these types of applications. The code first options are quite good these days, but you can get so far with make & other legacy tooling. Docker feels like a company looking to sell enterprise software first and foremost, not move the industry standard forward gr…

SRE here, I feel like both are just instructions how to get source code -> executable with docker/containers providing "deployable package" even if language does not compile into self-contained binary (Python, Ruby, JS, Java, .Net)

Also, there is nothing stopping you from creating a container that has make + tools required to compile your source code, writing a dockerfile that uses those tools to produce the output and leave it on the file system. Why that approach? Less friction for compiling since I find most make users have more pet build servers then cattle or making modifications can have a lot of friction due to conflicts.

Re: BuildKit: Docker's Hidden Gem That Can Build Almost Anything

#22

Post by slekker »

scuff3d wrote: post #19
whalesalad wrote: post #2

Folks, please fix your AI generated ascii artwork that is way out of alignment. This is becoming so prevalent - instant AI tell.

The "This is the key insight -" or "x is where it gets practical -", are dead give aways too. If I wanted an LLMs explanation of how it works, I can ask an LLM. When I see articles like this I'm expecting an actual human expert

This one too: "It’s a proven pattern."

Re: BuildKit: Docker's Hidden Gem That Can Build Almost Anything

#25

Post by cyberax »

Buildkit...

It sounds great in theory, but it JustDoesn'tWork(tm).

Its caching is plain broken, and the overhead of transmitting the entire build state to the remote computer every time is just busywork for most cases. I switched to Podman+buildah as a result, because it uses the previous dead simple Docker layered build system.

If you don't believe me, try to make caching work on Github with multi-stage images. Just have a base image and a couple of other images produced from it and try to use the GHA cache to minimize the amount of pulled data.

Re: BuildKit: Docker's Hidden Gem That Can Build Almost Anything

#26

Post by mid-kid »

cyberax wrote: post #25

Buildkit... It sounds great in theory, but it JustDoesn'tWork(tm). Its caching is plain broken, and the overhead of transmitting the entire build state to the remote computer every time is just busywork for most cases. I switched to Podman+buildah as a result, because it uses the previous dead simple Docker layered build system. If you don't believe me, try to make caching work on Github with multi-stage images. Just…

How do you use buildah? with dockerfiles?

I find that buildah is sort of unbearably slow when using dockerfiles...

Re: BuildKit: Docker's Hidden Gem That Can Build Almost Anything

#27

Post by croes »

scuff3d wrote: post #19
whalesalad wrote: post #2

Folks, please fix your AI generated ascii artwork that is way out of alignment. This is becoming so prevalent - instant AI tell.

The "This is the key insight -" or "x is where it gets practical -", are dead give aways too. If I wanted an LLMs explanation of how it works, I can ask an LLM. When I see articles like this I'm expecting an actual human expert

And waste time and energy again to get a similar result?

Re: BuildKit: Docker's Hidden Gem That Can Build Almost Anything

#28

Post by kylegalbraith »

After building Depot [0] for the past three years, I can say I have a ton of scar tissue from running BuildKit to power our remote container builders for thousands of organizations.

It looks and sounds incredibly powerful on paper. But the reality is drastically different. It's a big glob of homegrown thoughts and ideas. Some of them are really slick, like build deduplication. Others are clever and hard to reason about, or in the worst case, terrifying to touch.

We had to fork BuildKit very early in our Depot journey. We've fixed a ton of things in it that we hit for our use case. Some of them we tried to upstream early on, but only for it to die on the vine for one reason or another.

Today, our container builders are our own version of BuildKit, so we maintain 100% compatibility with the ecosystem. But our implementation is greatly simplified. I hope someday we can open-source that implementation to give back and show what is possible with these ideas applied at scale.

[0] https://depot.dev/products/container-builds

Re: BuildKit: Docker's Hidden Gem That Can Build Almost Anything

#29

Post by kodama-lens »

verdverm wrote: post #14

BuildKit also comes with a lot of pain. Dagger (a set of great interfaces to BuildKit in many languages) is working to remove it. Even their BuildKit maintainers think it's a good idea. BuildKit is very cool tech, but painful to run at volume Fun gotchya in BuildKit direct versus Dockerfiles, is the map iteration you loaded those ENV vars into consistent? No, that's why your cache keeps getting busted. You can't do t…

I switched our entire container build setup to buildkit. No kaniko, no buildah, no dind. The great part is that you can split buildkitd and the buildctl.

Everything runs in its own docker runner. New buildkitd service for every job. Caching only via buildkit native cache export. Output format oci image compressed with zstd. Works pretty great so far, same or faster builds and we now create multi arch images. All on rootless runners by the way

Re: BuildKit: Docker's Hidden Gem That Can Build Almost Anything

#30

Post by hanikesn »

cyberax wrote: post #25

Buildkit... It sounds great in theory, but it JustDoesn'tWork(tm). Its caching is plain broken, and the overhead of transmitting the entire build state to the remote computer every time is just busywork for most cases. I switched to Podman+buildah as a result, because it uses the previous dead simple Docker layered build system. If you don't believe me, try to make caching work on Github with multi-stage images. Just…

Why would you use the horrible GHA cache and not a much more efficient registry based cache?
Post reply on HN