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

Use with nixos modules, services, and machine configs #137

Open
msackman opened this issue Apr 15, 2024 · 4 comments
Open

Use with nixos modules, services, and machine configs #137

msackman opened this issue Apr 15, 2024 · 4 comments

Comments

@msackman
Copy link

It would be nice to use this to containerise not just nixos services and modules, but entire machine configs. I'm thinking both things like services.caddy, security.acme, and also, rather than setting config.entrypoint to some pkg, also supporting machine configuration, just like how the native nixos containers work, so config becomes a function: config = { config, pkgs, lib, ... }: { ...

Is there any way to do this sort of thing with nix-snapshotter? For the whole machine config, would it be "as simple" (ha!) as just figuring out what the relevant systemd entry point is and adding some flags so it knows it's in an image?

@MagicRB
Copy link

MagicRB commented Apr 15, 2024

Yes, you can use nixosSystem like normal, then use ${nicos.config.system.build.toplevel}/init and set boot.isContainer = true. And it should boot normally. Word of warning the images will be VERY heavy. And shameless plug https://github.com/nix-community/NixNG

@msackman
Copy link
Author

Thank you for the pointers, I'll start working with that.

@Lillecarl
Copy link

@MagicRB I never got the point of decoupling from systemd, now it makes more sense

@MagicRB
Copy link

MagicRB commented May 8, 2024

Putting systemd into containers is a horrible idea, outside of systemd-nspawn. Having a hard dependency on systemd is a blocker for nix built containers gaining general adoption and for anything but toy examples the tooling nixpkgs just doesn't cut it. What that tooling ends up building is a distroless container, those are generally only seen with Go/Rust programs as those generally are completely statically linked and don't depend on the operating system anyway. With for example PostreSQL you'll run into a cryptic error if /bin/sh is missing, as the devs never accounted for it missing and the error thrown by system() gets completely misinterpreted by the surrounding code.

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