-
Notifications
You must be signed in to change notification settings - Fork 2
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Including a usable 'nix' in the container? #1
Comments
You might take a look at example 6 & 7 from https://github.com/NixOS/nixpkgs/blob/6e5d7919b0c61ba2a4fccda5d0639d2bfb281172/pkgs/build-support/docker/examples.nix#L146 as a starting point for an image including the Nix package manager. That image could probably be served with flakehub. However, the intended use case for flakehub is mainly the creation of minimal and reproducible runtime images of applications (as you assumed). |
This repo includes docker images with nix installed and ready to use (built with dockerTools) |
Thanks for both of these links— my use case is running application test suites on Kubernetes, where the final environment is 10GB+ and contains thousands of store paths. So my primary interest is in the multi-layered image, which does seem to have some issues around nixdb-inclusion, so I'll have to investigate those and figure out if changes are needed. In any case, I'd been picturing the image-wrapping being something that had to happen at the serving layer, but maybe it's even easier than that, and the container images that I need could just be defined directly in my Nix source, making the serving part even thinner; key then is getting accurate popularity data into it, to maximize reuse. |
First, thanks for this! I've been very interested in Nixery and looking for alternative implementations/approaches. It's great to see how minimal this is able to be.
It looks like this is great for serving a container that's already going to have everything in it that's needed for runtime container use— however, the resulting configuration is fixed in the sense that there's no ability to include and run Nix itself, no nix.conf or sqlite db for the store, etc.
How much effort would be required to make the returned image include a "live" Nix environment such that it can be built upon at runtime? Is such a thing even in scope for a project like this, or is that more something for the upstream
dockerTools.streamLayeredImage
to implement?Looks like the DB part at least is non-trivial, per NixOS/nix#3091 it isn't even really possible to generate it after the fact (which wouldn't be ideal anyway, since you'd have to do it on every container start), it would be on the serving tool (flakehub) to track all the included store paths and synthesize a correct DB for them in a separate layer.
Wait... no, it looks like this actually does exist already upstream, at least in part:
https://github.com/NixOS/nixpkgs/blob/70a5ffcb63f0b557d28c320a354336ccf964bf0e/pkgs/build-support/docker/default.nix#L822-L838
So maybe it really is a matter for the serving tool (flakehub) to have a flag or something to enable it? Or maybe a way to set it to default-on or -off, with a
meta
option that can be set on individual flakes to override the global config?The text was updated successfully, but these errors were encountered: