Hey all, I’m wondering about giving NixOS a try. It seems like it’s mostly marketed for development environments and CI, but I haven’t seen much of anything about it being used on production servers. Right now I manage Alma 8 servers with Salt, and bootstrap Salt with a modified version of the ISO. NixOS seems like it could help streamline how I do things. Does anyone use it and have thoughts one way or another?
Thank you for your extremely thoughtful response. One thing I need to research for myself is how user data, configuration, etc. is handled with a rollback. In MicroOS, the system itself is snapshotted by default (/etc for example) but user data (/home) is not. I would assume that a rollback would not touch the user data, so an upgrade could break that (e.g. database migration performed by a package update).
If you’re always able to roll back, is taking the time to build and run a VM really worth it except for very critical maintenance windows? Does the VM just copy the nix config or the data too? Today, I use Vagrant for testing my Salt states. It does what I need.
I don’t come from functional programming, but I’m sure I’ll figure it out. Would have been nice for it not to have its own language, but I suppose that’s most efficient instead of repurposing / abusing another language in a weird way.
NixOS doesn’t handle stateful application data at all (especially it doesn’t touch home directories at all other than creating them, though there’s home-manager if you wish to do that). But I think big incompatible updates are kept between major NixOS versions, at least for stuff like databases, and I’ve never ran into this being an issue, except for when I wrote some configuration to move some files to new locations and then wanted to roll back, but that’s on me (and it was easy to cherry-pick the parts that used the new paths). Having snapshots for /var and so on might be a good idea, though personally I just keep daily backups of those directories.
The VM is less useful for testing package upgrades and other small changes and more for configuration you don’t want to run on the actual server yet (such as when you’re writing it at the moment and it’s not complete and just want to test how much of it works), like testing software locally before pushing it to production. The VM build takes about as much time as building the normal configuration (and very short if that is already built). It produces a script which starts a QEMU VM using a blank disk file which it will reuse (of course, some services may fail due to missing keys). But I don’t think that’s a problem and it also kinda is another check that your system won’t horribly fail if you ever want to reinstall it completely before restoring a backup.
Cool! Thank you. I appreciate the detail with which you write. I’m going to give this a shot, I think!
Thank you, that means a lot to me! And of course, good luck and I hope you’ll like it.
…One of these days I’m going to write a first time users oriented guide for NixOS I can point people to that actually goes through everything I think is important to know but for now I’ll just link you to these:
And last, my own configuration. It’s gotten pretty big at this point with ~8k lines, containing configuration for various machines, shared configuration, new service definitions, new packages and so on. I honestly don’t expect it to be useful to you but it might give an idea of how one of these might look and what is possible. In the turris branch I’m currently setting up NixOS on a new machine, my router. (At some point I also need to document what is going on in that repository, especially the configuration loader.)
It’s also a Flake-based configuration which is the new “experimental” (read: not yet marked stable but unlikely to change significantly at this point and has been this way for years) way of doing things, I heavily encourage you to look into Flakes at some point because they are a big improvement in especially how inputs such as the nixpkgs version used for your system is tracked (it works similar to lock files from NPM or similar package managers), vs. the old channels.