Live data from Hacker News

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

tuananh.net

11–20 of 80 posts

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

#11

I don't use buildkit for artifacts, but I do like to output images to an OCI Layout so that I can finish some local checks and updates before pushing the image to a registry. But the real hidden power of buildkit is the ability to swap out the Dockerfile parser. If you want to see that in action, look at this Dockerfile (yes, that's yaml) used for one of their hardened images: https://github.com/docker-hardened-image…

i did include a repo example on how to create custom frontend as well https://github.com/tuananh/apkbuild

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

#12

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…

Along similar lines, when I was reading the article I was thinking "this just sounds like a slightly worse version of nix". Nix has the whole content addressed build DAG with caching, the intermediate language, and the ability to produce arbitrary outputs, but it is functional (100% of the inputs must be accounted for in the hashes/lockfile, as opposed to Docker where you can run commands like `apk add firefox` which…

> so two docker builds can end up with the same hash but different output

The cache key includes the state of the filesystem so I don’t think that would ever be true.

Regardless, the purpose of the tool is to generate [layer] images to be reused, exactly to avoid the pitfalls of reproducible builds, isn’t it? In the context of the article, what makes builds reproducible is the shared cache.

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

#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 this in the linear Dockerfile

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

#15

Earlier quoted context omitted.

Along similar lines, when I was reading the article I was thinking "this just sounds like a slightly worse version of nix". Nix has the whole content addressed build DAG with caching, the intermediate language, and the ability to produce arbitrary outputs, but it is functional (100% of the inputs must be accounted for in the hashes/lockfile, as opposed to Docker where you can run commands like `apk add firefox` which…

> so two docker builds can end up with the same hash but different output The cache key includes the state of the filesystem so I don’t think that would ever be true. Regardless, the purpose of the tool is to generate [layer] images to be reused, exactly to avoid the pitfalls of reproducible builds, isn’t it? In the context of the article, what makes builds reproducible is the shared cache.

It's not reproducible then, it's simply cached. It's a valid approach but there's tradeoffs of course.

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

#16

Earlier quoted context omitted.

Are you on a phone? I loaded the article with both my phone and laptop. The ascii diagram was thoroughly distorted on my phone but it looked fine on my laptop.

Firefox on a 27" display. Could be the font being used to render.

The only ASCII image I see on that page is actually a PNG:

https://tuananh.net/img/buildkit-llb.png

Maybe the page was changed? If you're just talking about the gaps between lines, that's just the line height in whatever source was used to render the image, which doesn't say much about AI either way.

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

#17
post #13

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

I found it more jarring that they chose to use both Excalidraw and ascii art. What a strange choice.

the hugo theme requires an image thumbnail. i just find one and use it :D

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

#18
post #16

Earlier quoted context omitted.

Firefox on a 27" display. Could be the font being used to render.

The only ASCII image I see on that page is actually a PNG: https://tuananh.net/img/buildkit-llb.png Maybe the page was changed? If you're just talking about the gaps between lines, that's just the line height in whatever source was used to render the image, which doesn't say much about AI either way.

looks fine to me but since it messed up for some so i replace it with png

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

#19

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

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

#20

Earlier quoted context omitted.

Along similar lines, when I was reading the article I was thinking "this just sounds like a slightly worse version of nix". Nix has the whole content addressed build DAG with caching, the intermediate language, and the ability to produce arbitrary outputs, but it is functional (100% of the inputs must be accounted for in the hashes/lockfile, as opposed to Docker where you can run commands like `apk add firefox` which…

> so two docker builds can end up with the same hash but different output The cache key includes the state of the filesystem so I don’t think that would ever be true. Regardless, the purpose of the tool is to generate [layer] images to be reused, exactly to avoid the pitfalls of reproducible builds, isn’t it? In the context of the article, what makes builds reproducible is the shared cache.

Ah you're right, the hash wouldn't be the same but a Dockerfile could produce different outputs on different machines whereas nix will produce identical output on different machines.
Post reply on HN