Discuss: a meta-package for buildpacks?
jonjohnsonjr opened this issue · 5 comments
Dropping a rough sketch of what I had in mind so we can collect thoughts here.
Buildpacks don't currently have a way for users to specify which OS packages they require for their image. There is a related RFC, but I had an idea for how we could "solve" this with nixery in the short term. In the long term, we'll probably want to maintain a NixOS "stack", which would probably also involve nixery in some way :)
I'm not familiar with the implementation of the shell meta-package, but if the mechanism is reasonably extensible, I'd like to propose a buildpacks meta-package that sets sufficient config metadata to use nixery for a buildpacks run image.
tl;dr at a minimum:
- Add a label with a globally unique Stack ID representing nixery.
- Set the UID/GID to a specific value (let's pick something arbitrary, say 1000) that matches the build image.
One thing to consider is how this affects rebasing of the produced images. It's unclear if there are ABI compatibility guarantees for updated nix packages, but my overall impression is that it's probably a non-issue?
if the mechanism is reasonably extensible, I'd like to propose a buildpacks meta-package that sets sufficient config metadata to use nixery for a buildpacks run image
This is reasonably easy to do. The mechanism is extensible (not yet in an ideal way, but this would be the third meta-package so it's not too bad). I'll need to understand how the stack IDs work etc. before making a concrete complexity judgement.
It's unclear if there are ABI compatibility guarantees for updated nix packages, but my overall impression is that it's probably a non-issue
It's a non-issue for packages built by Nix, because those are linking absolute dependency paths in the Nix store. Users running arbitrary other software on top might face more of an issue with this.
One way to work around this would potentially be the introduction of FHS-compatible symlink layers (see #58). I suspect that the requirement for ABI compatibility here stems from legacy build systems which make it difficult to separate build & runtime dependencies, but need to read a bit more about the Buildpack setup!
The ABI compatibility is mostly about upgrading packages within a stack, which is why defining a stack ID is required. As part of post-deployment image lifecycle, buildpacks can "rebase" images on top of a new run image (e.g. when vulnerabilities are detected). It doesn't actually do a complete rebuild of the image, just swap out the layers in-registry, so doing this safely requires that anything depending on the original layers isn't broken by the newly rebased layers.
The whole talk is worth watching, but here's a good timestamp from a kubecon talk: https://youtu.be/j9Ak5YLrihU?t=1333
Thanks, I'll take a look!
I've started looking into this and it seems like I need to switch Nixery over to using the OCI image specification, as I can't find any references to the label fields in the spec for the vnc.docker.container.* types.
This might be the point where Nixery should switch to using ggcr for the image types instead of maintaining this stuff separately.
Labels are defined here, but I won't stop you from switching over to using ggcr :)