-
Notifications
You must be signed in to change notification settings - Fork 17
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
Comments
Yes, you can use |
Thank you for the pointers, I'll start working with that. |
@MagicRB I never got the point of decoupling from systemd, now it makes more sense |
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 |
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 settingconfig.entrypoint
to some pkg, also supporting machine configuration, just like how the native nixos containers work, soconfig
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?
The text was updated successfully, but these errors were encountered: