Announcing rules_img: a faster path to container images in Bazel
11 points by typesanitizer
11 points by typesanitizer
Strongly recommend watching the BazelCon 2025 talk on rules_img: https://youtu.be/biYXmAv4Ppk to easily understand how it differs from previous rulesets.
interesting, I actually already love the container story for Bazel.
It was Bazel that made my mindset shift from “docker is a series of layers on top of each other” to: “Docker containers are a collection of layers that can be in any order or swapped out”.
This was a mindblowing distinction, even though I’m aware that the docker format is just tarballs and metadata, because it mean that creating a “debug” container was just having my debug tools in a layer and then assembling two builds of my images.
idk, I can’t explain it, it was a really lovely feeling.. it felt composable instead of instructive.
collection of layers that can be in any order or swapped out
Hm that could be useful, but it can also be wrong. Does Bazel have any notion of say this situation
In this case, layer A+B+C+D is a valid image, but layer A+D is not. It won't run anything.
A+C might be valid ... it depends on whether unzip and openssl share any deps
Personally I want to have a different concept to address this situation. Right now I call them "wedges" - packages that can be bind mounted or copied in and out of containers ...
i.e. "wedges" compose differently than layers. It seems like layers do inherently depend the layer below, because in general arbitrary Unix command in a RUN may spray files all over the file system!
Would your wedges relate as a directed acyclic graph?
I'd also appreciate if each layer was a set of images that mustn't collide (otherwise the layer would be invalid) instead of a single image. This would really benefit the encoding Nix store outputs as OCI containers.
OCI containers built by Nix already have their layers related as a DAG, because they are just store paths, which represent derivations which in turn are represented by a DAG
Right now I think any DAG relation would be in a different tool / layer, like a build system.
I imagine layers and wedges more like dumb tarballs. You can build them with anything -- either a shell script, or something like make/Bazel with a DAG.
(But wedges have some constraint on the directory structure, so you can bind mount them independently. Sort of like /nix/store/$HASH )
Concretely, I want to move the Oils CI off of podman / OCI ... and probably use crun and OverlayFS directly. No more "registry", and no more docker/podman push/pull
In a simple cloud, everything should just be processes, files, and users! You don't need special storage for executables
We just moved from Docker to podman: https://oils.pub/blog/2025/12/release-0.37.0.html#appendix-docker-podman-migration . So we are slowly moving away from the OCI ecosystem