Skip to content
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

Open
mikepurvis opened this issue Mar 23, 2023 · 3 comments
Open

Including a usable 'nix' in the container? #1

mikepurvis opened this issue Mar 23, 2023 · 3 comments

Comments

@mikepurvis
Copy link

mikepurvis commented Mar 23, 2023

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?

@elohmeier
Copy link
Owner

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).

@adrian-gierakowski
Copy link

This repo includes docker images with nix installed and ready to use (built with dockerTools)

@mikepurvis
Copy link
Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants