There is a similar question on the site which must not be named.
My question still has a little different spin:
It seems to me that one of the biggest selling points of Nix is basically infrastructure as code. (Of course being immutable etc. is nice by itself.)
I wonder now, how big the delta is for people like me: All my desktops/servers are based on Debian stable with heavy customization, but 100% automated via Ansible. It seems to me, that a lot of the vocal Nix user (fans) switched from a pet desktop and discover IaC via Nix, and that they are in the end raving about IaC (which Nix might or might not be a good vehicle for).
When I gave Silverblue a try, I totally loved it, but then to configure it for my needs, I basically would have needed to configure the host system, some containers and overlays to replicate my Debian setup, so for me it seemed like too much effort to arrive nearly at where I started. (And of course I can use distrobox/podman and have containerized environments on Debian w/o trouble.)
Am I missing something?
In this comparison, the devil is in the detail.
With Ansible, you have an initial condition onto which you add additional state through automatically executed steps dictated by you until you (hopefully) arrive at a target state. This all happens through modification of one set of state; each step receives the state of the previous step, modifies it and passes the entire state onto the next step. The end result is not only dependant on your declared steps but also the initial state. A failure in any step means you're left in an inconsistent state which is especially critical for the case of updating an existing state which is the most common thing to do to a Linux system.
In NixOS, you describe the desired target state and the NixOS modules then turn that description into compartmentalised bits of independent state. These are then cheaply and generically combined into a "bundle"; wrapping them into one big "generation" that contains your entire target state.
Your running system state is not modified at any point in this process. It is fully independent, no matter what the desired system is supposed to be. It is so independent in fact that you could do this "realisation" of the NixOS system on any other system of the same platform that has Nix installed without any information about the state of the system it's intended to be deployed on.
This "bundle" then contains a generic script which applies the pre-generated state to your actual system in a step that is as close to atomic as possible.
A good example for this are packages in your PATH. Rather than sequentially placing the binaries into the/usr/bin/directory as a package manager would when instructed by ansible to install a set of packages, NixOS merely replaces thebinsymlink with one that points at an entirely new pre-generated directory which contains the desired packages' binaries (well, symlinks to them for efficiency). There cannot possibly be an in-between state where only some of the binaries exist; it's all or nothing. (This concept applies to all parts that make up a Linux system of course, not just binaries in the PATH. I just chose that as an easy to understand example.)
By this property, your root filesystem no longer contains any operating system configuration state. You could wipe it and NixOS would not care. In fact, many NixOS users do that on every boot or even use atmpfsfor/.(Immutability is a property that NixOS gains almost by accident; that's not its primary goal.)
Nice, thank you very much for this great summary!
In my own words, you describe the difference between declarative vs. imperative configuration and the joy of atomic updates. :-)
I just want to add one point: Theoretically I totally agree, that one might have a bad state in Ansible and the updated state is spoiled, and of course configuration drift is a theoretical problem via Ansible. In practice I never run into this problems in 10+ years of using Ansible. (Of course I treat servers/desktop as cattle, so every major revision of Debian means a complete/clean new installation.)
If it works for you, that's great.
I find it a lot more convenient to treat every change about my system as a nearly complete/clean new installation though and NixOS allows you to do so. An upgrade between major versions becomes a walk in the park due to this; it's the M.O. The last one didn't require any modification of the config on my NAS. I remotely rebuilt the system from my MacBook Pro with the new channel, rebooted to get the newer kernel and everything worked just like before.
I use Fedora Silverblue and in my experience the updates are very stable. But with Debian and Ansible automation I think you are not missing a much, maybe nothing at all.
Would you mind sharing how you automated your setup with Ansible or generally how to use Ansible in that way? I use some bash scripts for my automation and it is a bit hacky, so if I could improve that, it would be nice.
Yes, I really love the Silverblue download in the background, reboot and you are up to date updates. So much better than watching the package manager do its thing. :-)
I don't know about your knowledge about Ansible, and when you are already running Silverblue and are happy with it, it might be more worthwhile for you to explore how to automate Silverblue and the containers you are using... and write a blog post for people like me, how you did it, so I can learn. :-P
Ansible... basically it allows you to install software with the package managers (apt, dnf, ...), configure/restart etc. services, clone git repositories, run arbitrary commands, configure stuff with dconf.
Example for my workflow:
When Debian 12 got into the alpha stage, I simply set up a virtual machine, install git, ansible and vim, and then I start from a known starting place (like Gnome Desktop for desktops, minimal for servers). First, I clone my git repository with my dotfiles, and link all the relevant dotfiles. After that I simply use Ansible to install all packages I will use from that distribution, run dconf to configure Gnome for my needs, configure/download software from 3rd party package repositories or just download tarballs and install them to /opt or ~/opt. Of course also flatpaks can be configured/downloaded via Ansible.
Once, everything works great in the virtual machine I will work in the VM for a few days or even weeks. If everything works stable I'll just make a clean install of the operating system, add some hardware specific tweaks (change grub config, tweak WIFI drivers power mode) and then I am up and running. Thanks to Debian, my Ansible configs are mostly stable with minor tweaks for around 2 years, and when time is due for Debian 13, I'll repeat the cycle.
The way I do things with Ansible have grown for a long time and are tailored to my private/professional use cases. I simply like having the same setup on every desktop/server I deploy, because I never have to wonder, if my software is configured in the way I like it, if a hotkey works or if something I use is installed or not. (And if my hardware dies or I do an SSD upgrade, I am up and running within minutes, same is true if I get new hardware.)
Still, it is a tradeoff. I really like Fedora, but one year of updates is too short for me and my initial investment to setup a new version of Debian. Further, I only use dconf based desktops like Mate or Gnome, because I can simply configure them painless 100% via Ansible. OTOH I have MY Debian desktop setup running on multiple AMD64 and AARCH64 physical and virtual machines. If I want to experiment with software, I just create a VM, start Ansible, get a cup of tea and I have a disposable machine to play around. Further I have my setup 100% documented, if I wonder, what strange power settings tweak I needed in which file to make Debian 11 work on my netbook, I know were to find the 100% correct answer..
Excuse the wall of text, hope that gave you an idea, don't hesitate to reach out if any questions are left. Obviously, you have to decide for yourself if such a setup is worthwhile for you. In case you use only one Desktop, this would be total overkill. :-P
Thank you for this in depth answer. It makes me want to explore Ansible and setup automation. Sounds really great!
and write a blog post for people like me, how you did it, so I can learn.
I am thinking about that ... 🤔
Really, Ansible doesn't matter, the IaC part is the killer.
Just start to put your config into code and learn, over time it will grow!
I cannot go back to setting desktops/servers up by hand, IaC just solves too many problems and gives me peace of mind.
I switched from a big custom Ansible deployment to NixOS.
The system includes 8 managed machines, multiple VPNs and a custom certificate authority.
Downsides:
- rethinking of how to manage Certificates and VPN configs outside of Nix
- getting secrets to work took a bit until I found agenix
- deployments can take a while with deploy-rs
Still, I can only tell you how much more at ease I feel with the NixOS based system. Its just much easier to refactor, not having to take care of legacy cleanup and polluting the machines over time.
Once you wrap your head around it all more complex system architectures start to become manageable/maintainable.
IaC
You still need sth like Terraform on the side for your actual infrastructure provisioning.
Solutions to bridge this with the Nix ecosystem are evolving in the nix-community repos on Github, but I found it easier to manage that separately for the time being.
All in all I would recommend NixOS based systems for the heavy lifters in your setup. If you want to deploy a fleet of machines you are entering new territory. Exciting, but maybe too much of a time commitment for some.
