4 ms·

> unless you've done something very clever like 1 package per layer I struggle to think that 50 is really useful? 1 package per layer can actually be quite nic

> unless you've done something very clever like 1 package per layer I struggle to think that 50 is really useful? 1 package per layer can actually be quite nice, since it means that any package updates will only affect that layer, meaning that downloading container updates will use much less network bandwidth. This is nice for things like bootc [0] that are deployed on the "edge", but less useful for things deployed in a well-connected server farm. [0]: https://bootc-dev.github.io/bootc/ https://bootc-dev.github.io/bootc/

seabrookmx 8mo ago
It doesn't work this way really? It's called a layer because each layer on top depends on the layers below. If you change the package defined in the bottom most layer, all 49 above it are invalid and need re-pulled or re-built.
- gucci-on-fleek 8mo ago
  > If you change the package defined in the bottom most layer, all 49 above it are invalid and need re-pulled or re-built. I also initially thought that that was the case, but some tools are able to work around that [0] [1] [2]. I have no idea how it works, but it works pretty well in my experience. [0]: https://github.com/hhd-dev/rechunk/ https://github.com/hhd-dev/rechunk/ [1]: https://coreos.github.io/rpm-ostree/container/#creating-chunked-images https://coreos.github.io/rpm-ostree/container/#creating-chun... [2]: https://coreos.github.io/rpm-ostree/build-chunked-oci/ https://coreos.github.io/rpm-ostree/build-chunked-oci/
- minitech 8mo ago
  That’s mostly a Dockerism (and even Docker has `COPY --link` these days). The underlying tech supports independent layers.
- SR2Z 8mo ago
  Layering in the container spec is achieved by overlaying each layer's filesystem (a tarball, I think) over each layer below it. If file "a" is modified in layers 3 and 5, the resulting container will have data for both versions but reading "a" in the container will return version 5. Docker exploits this to figure out when it can cache a layer, but building a container is different than running one because changing the underlying file system can change what a command outputs. If you're running a container, changing one deeply buried layer doesn't change the layers above it because they're already saved.
- eliaspro 8mo ago
  grahamc wrote down how to optimize this (within the constraints of max 128 layers supported by OCI) to categorize/prioritize packages by popularity/dependencies which lead to dramatic speed-ups for pulling updates or related images. https://grahamc.com/blog/nix-and-layered-docker-images/ https://grahamc.com/blog/nix-and-layered-docker-images/
yjftsjthsd-h 8mo ago
Yes, my intended meaning was that if you're doing that or something similar then I totally get having lots of layers because it's useful. Mostly I've only seen it come up with nix, but I can see how bootc would have a similar deal. That said, most container images I've ever seen aren't doing anything that clever and probably should be like... 2-3 layers? (One base layer, one with all your dependencies shoved in, and maybe one on top for the actual application.)

seabrookmx 8mo ago

It doesn't work this way really? It's called a layer because each layer on top depends on the layers below. If you change the package defined in the bottom most layer, all 49 above it are invalid and need re-pulled or re-built.

gucci-on-fleek 8mo ago
> If you change the package defined in the bottom most layer, all 49 above it are invalid and need re-pulled or re-built. I also initially thought that that was the case, but some tools are able to work around that [0] [1] [2]. I have no idea how it works, but it works pretty well in my experience. [0]: https://github.com/hhd-dev/rechunk/ https://github.com/hhd-dev/rechunk/ [1]: https://coreos.github.io/rpm-ostree/container/#creating-chunked-images https://coreos.github.io/rpm-ostree/container/#creating-chun... [2]: https://coreos.github.io/rpm-ostree/build-chunked-oci/ https://coreos.github.io/rpm-ostree/build-chunked-oci/
minitech 8mo ago
That’s mostly a Dockerism (and even Docker has `COPY --link` these days). The underlying tech supports independent layers.
SR2Z 8mo ago
Layering in the container spec is achieved by overlaying each layer's filesystem (a tarball, I think) over each layer below it. If file "a" is modified in layers 3 and 5, the resulting container will have data for both versions but reading "a" in the container will return version 5. Docker exploits this to figure out when it can cache a layer, but building a container is different than running one because changing the underlying file system can change what a command outputs. If you're running a container, changing one deeply buried layer doesn't change the layers above it because they're already saved.
eliaspro 8mo ago
grahamc wrote down how to optimize this (within the constraints of max 128 layers supported by OCI) to categorize/prioritize packages by popularity/dependencies which lead to dramatic speed-ups for pulling updates or related images. https://grahamc.com/blog/nix-and-layered-docker-images/ https://grahamc.com/blog/nix-and-layered-docker-images/

yjftsjthsd-h 8mo ago

Yes, my intended meaning was that if you're doing that or something similar then I totally get having lots of layers because it's useful. Mostly I've only seen it come up with nix, but I can see how bootc would have a similar deal. That said, most container images I've ever seen aren't doing anything that clever and probably should be like... 2-3 layers? (One base layer, one with all your dependencies shoved in, and maybe one on top for the actual application.)