Live data from Hacker News

A faster path to container images in Bazel

tweag.io

11–20 of 60 posts

Re: A faster path to container images in Bazel

#11
post #9
post #7

I'm struggling with the caching right now. I'm trying to switch from the Github actions to just running stuff in containers, and it works. Except for caching. Buildkit from Docker is just a pure bullshit design. Instead of the elegant layer-based system, there's now two daemons that fling around TAR files. And for no real reason that I can discern. But the worst thing is that the caching is just plain broken.

The layers are tar files, I’m confused what behavior you actually want that isn’t supported.

The original Docker (and the current Podman) created each layer as an overlay filesystem. So each layer was essentially an ephemeral container. If a build failed, you could actually just run the last successful layer with a shell and see what's wrong.

More importantly, the layers were represented as directories on the host system. So when you wanted to run something in the final container, Docker just needed to reassemble it.

Buildkit has broken all of it. Now building is done, essentially, in a separate system, the "docker buildx" command talks with it over a socket. It transmits the context, and gets the result back as an OCI image that it then needs to unpack.

This is an entirely useless step. It also breaks caching all the time. If you build two images that differ only slightly, the host still gets two full OCI artifacts, even if two containers share most of the layers.

It looks like their Bazel infrastructure optimized it by moving caching down to the file level.

Re: A faster path to container images in Bazel

#12
post #3
post #2

Awful AI images everywhere. Can we not help ourselves?

Is my adblocker blocking them? I only saw the stack of tars in a coat. Didn't break the article's flow for me.

I also only saw that, but the text feels a bit fluffed out by AI as well, if I’m not mistaken.

Re: A faster path to container images in Bazel

#13

Earlier quoted context omitted.

> The article is about producing container images for deployment Fair. Docker does trigger my predator drive. I’m pretty shocked that the Bazel workflow involves downloading Docker base images from external URLs. That seems very unbazel like! That belongs in the monorepo for sure. > What specifically is very very wrong with Linux packaging and dependency resolution? Linux userspace for the most part is built on a poo…

> I’m pretty shocked that the Bazel workflow involves downloading Docker base images from external URLs. That seems very unbazel like! That belongs in the monorepo for sure. Not every dependency in Bazel requires you to "first invent the universe" locally. Lots of examples of this like toolchains, git_repository, http_archive rules and on and on. As long as they are checksum'ed (as they are in this case) so that you…

Everything belongs in version control imho. You should be able to clone the repo, yank the network cable, and build.

I suppose a URL with checksum is kinda sorta equivalent. But the article adds a bunch of new layers and complexity to avoid “downloading Cuda for the 4th time this week”. A whole lot of problems don’t exist if they binary blobs exist directly in the monorepo and local blob store.

It’s hard to describe the magic of a version control system that actually controls the version of all your dependencies.

Webdev is notorious for old projects being hard to compile. It should be trivial to build and run a 10+ year old project.

Re: A faster path to container images in Bazel

#14
post #12
post #3

Earlier quoted context omitted.

Is my adblocker blocking them? I only saw the stack of tars in a coat. Didn't break the article's flow for me.

I also only saw that, but the text feels a bit fluffed out by AI as well, if I’m not mistaken.

It’s not. It’s been through several editing rounds. (I was one of the editors.) In theory, we don’t have a problem with AI generated content if it meets our high editorial requirements, but all Tweag technical blogs go through a rigorous, manual review and editing process to keep standards high.

Re: A faster path to container images in Bazel

#15

Earlier quoted context omitted.

> I’m pretty shocked that the Bazel workflow involves downloading Docker base images from external URLs. That seems very unbazel like! That belongs in the monorepo for sure. Not every dependency in Bazel requires you to "first invent the universe" locally. Lots of examples of this like toolchains, git_repository, http_archive rules and on and on. As long as they are checksum'ed (as they are in this case) so that you…

Everything belongs in version control imho. You should be able to clone the repo, yank the network cable, and build. I suppose a URL with checksum is kinda sorta equivalent. But the article adds a bunch of new layers and complexity to avoid “downloading Cuda for the 4th time this week”. A whole lot of problems don’t exist if they binary blobs exist directly in the monorepo and local blob store. It’s hard to describe…

Making heavy use of mostly remote caches and execution was one of the original design goals of Blaze (Google's internal version) iirc in an effort to reduce build time first and foremost. So kind of the opposite of what you're suggesting. That said, fully air-gapped builds can still be achieved if you just host all those cache blobs locally.

Re: A faster path to container images in Bazel

#16
post #4

Funny that the article only obliquely references the compression issues. The OCI users that I have seen are using gzip due to inertia, while zstd layers have been supported for a while and are radically faster.

I looked into switching to zstd recently however at least crane the utility that rules_oci uses to upload containers does not yet support uploading zstd layers.

https://github.com/google/go-containerregistry/pull/1827

Re: A faster path to container images in Bazel

#17

Earlier quoted context omitted.

Everything belongs in version control imho. You should be able to clone the repo, yank the network cable, and build. I suppose a URL with checksum is kinda sorta equivalent. But the article adds a bunch of new layers and complexity to avoid “downloading Cuda for the 4th time this week”. A whole lot of problems don’t exist if they binary blobs exist directly in the monorepo and local blob store. It’s hard to describe…

Making heavy use of mostly remote caches and execution was one of the original design goals of Blaze (Google's internal version) iirc in an effort to reduce build time first and foremost. So kind of the opposite of what you're suggesting. That said, fully air-gapped builds can still be achieved if you just host all those cache blobs locally.

> So kind of the opposite of what you're suggesting.

I don’t think they’re opposites. It seems orthogonal to me.

If you have a bunch of remote execution workers then ideally they sit idle on a full (shallow) clone of the repo. There should be no reason to reset between jobs. And definitely no reason to constantly refetch content.

Re: A faster path to container images in Bazel

#18
post #12

Earlier quoted context omitted.

I also only saw that, but the text feels a bit fluffed out by AI as well, if I’m not mistaken.

It’s not. It’s been through several editing rounds. (I was one of the editors.) In theory, we don’t have a problem with AI generated content if it meets our high editorial requirements, but all Tweag technical blogs go through a rigorous, manual review and editing process to keep standards high.

As I've read through the post, seeing phrases like "Why this matters for performance", usage of em-dashes and lists/bullet points, screams AI written to me. I appreciate you saying it wasn't, but such is the fate of who wrote this to write like LLMs do nowadays. I also liked to use em-dashes and bullet lists but am consciously avoiding them now.

Re: A faster path to container images in Bazel

#19
My experience is that anything involving Bazel is slow, bloated, and complicated, hammers your disk, copies your files ten times over, and balloons your disk usage without ever collecting the garbage. A lot of essential features are missing so you realistically have to build a lot of custom rules if not outright additional tooling on top.

I'm not too surprised that out of the box docker images exhibit more of this. While it's good they're fixing it, it feels like maybe some of the core concepts cause pretty systematic issues anytime you try to do anything beyond the basic feature set...

Re: A faster path to container images in Bazel

#20

Earlier quoted context omitted.

> The article is about producing container images for deployment Fair. Docker does trigger my predator drive. I’m pretty shocked that the Bazel workflow involves downloading Docker base images from external URLs. That seems very unbazel like! That belongs in the monorepo for sure. > What specifically is very very wrong with Linux packaging and dependency resolution? Linux userspace for the most part is built on a poo…

> I’m pretty shocked that the Bazel workflow involves downloading Docker base images from external URLs. That seems very unbazel like! That belongs in the monorepo for sure. Not every dependency in Bazel requires you to "first invent the universe" locally. Lots of examples of this like toolchains, git_repository, http_archive rules and on and on. As long as they are checksum'ed (as they are in this case) so that you…

Also it is possible to air gap bazel and provide files as long as they have the same checksum offline.
Post reply on HN