nix2container
nix2container copied to clipboard
nlewo
OCI `nix`-variant of the image spec
https://github.com/opencontainers/image-spec/blob/main/manifest.md
Notably, we could gather to submit proposal for a different mediaType:
-
application/vnd.nix.image.layer.v1.nar -
application/vnd.oci.image.layer.nondistributable.v1.tar+gzip
/cc @manveru
I don't know exactly what you have in mind, but having a layer per nar is not possible since the number of layer is generally limited to 128 (kernel limitation i guess).
OCI layers are self contained while the JSON layer as used by nix2container relies on files which are in the Nix store (outside of the layer itself). So, i'm not sure it could fit the OCI layer model...
The idea would be that really a layer is a nix store path and that OCI compliant runtimes would know how to fetch layers from nix stores.
But you are absolutely right with the 128 layer limitation. I haven't thought about this.
Maybe this can serve nevertheless as an inspiration on how we can better integrate the nix distribution story with OCI distribution story.
Technically the 128 limit would require some synthetic predictably less-volatile base-layer of the kind that nix2container is precisely trying to avoid.
Connecting the breadcrumbs: https://github.com/opencontainers/image-spec/issues/922
@blaggacao would it be possible to add an option for a OCI layer that said it was non-colliding, and then the runtime could bind mount it instead of using overlayfs? It seems that would make the change to OCI a bit more general and potentially get around the 128 layers issue
Another option I'm wondering about is zstd:chunked https://www.redhat.com/sysadmin/faster-container-image-pulls