I know this sound kinda click-bait, but recently tech youtuber wolfgang upload a video in where he speaks about his home server, moreover in the video they acknowledge nixos and ansible as two good options to reproducibility setups.
My question here is: From a friendly perspective (I’m still a noob) which is the advantages of running nixos over running ansible which support more linux distros (Debian based, arch, etc…) what are the advantages of each one, beyond reproducibility.
The main philosophical differences are imperative vs declarative programming.
Ansible playbooks are sequential steps taken to reach a hopefully desired end-state.
NixOS configurations are a “manifest” of the end-state you want, and then the nixos modules will contain the logic around their slice of the system configuration.
I haven’t used ansible for a few years, so I can’t comment much further. But the other notable difference I notice with Nix (in general) is that your complexity percolates up to the top and you have to deal with it immediately. I would argue that this makes it easier to iterate in the long run, but many people try nix and find it off-putting since their original and impure processes often translate poorly into nix.
the practical difference is, that nor nixos nor ansible provide true reproducibility in most cases. But nix setups are much closer to that, and usually are simpler to troubleshoot in my opinion(due to it being declarativly defined) . Where’s ansible if it failed(like the state has been altered outside of ansible’s scope) you’re mostly fucked, and will have to do some manual work, to get it to work the way you intended it.
Positive with ansible is that to troubleshoot it you only need to know how to manage linux systems, with nix you need to know how nix works and how to manage linux systems and what are the caveats with managing it with nix
From my experience, Ansible is a lot easier to use. There is not much complexity in it, which makes it really pleasant (e.g. compared to Puppet or Saltstack).
However, playbook execution is really slow, even if no state needs to change, it easily gets into minutes with just a few services configured through Ansible. Due to that, people start to tag steps and only run specific tags. In the end, that leads to the system state and the Ansible configuration to diverge.
NixOS on the other hand is really complex at first (I needed a few weeks to get my basic system running) and painful at times if you try to run software that is not yet packaged. But, with determination to live with the constant effort when getting new things to run, it ends up with a much more enjoyable system than Ansible, Salt or Puppet could ever achieve.
I agree to @jonringer that a strong point of nix is that it forces you to do things declaratively from the start.
@jonringer @Seebi @almostnobody
Thanks for you feedback, i ask because this new year i’m planning to go in deep with system administration and devops so hearing this kind of thinks it’s interesting to me, it’s true that most servers out there run linux or some derivation but, my second question is the following:
It’s actually possible to apply nix infrastructure in already existence systems? With infrastructure i mean taking the already existence system configuration from a system and translate it into nix or this is only possible when setting up a new nixos machine?
do you mean using nix only to configure a small part of the software stack on a non-Nixos system?
That’s possible, but not something i would recommend in a production environment(nix itself is not popular enough to use it in production unless you feel fluent enough in all it’s quirks.) using an unpopular way to use nix is even more likely to run into edge cases that no one has ever ran into. That will be painful.
An exception would be a home-manager to use on a gui system of the enduser(devs etc).
User services can be migrated over using home-manager, but I don’t think you can do a system translation as easily. It might be possible, but it’s probably more complexity than choosing one or the other.
so you could say, nix it’s better for small projects? and Ansible for big ones?
no, nix itself is a fundamentally superior tool capable to solve much broader set of issues.
But it’s not as popular, and it’s minimal requirement of knowledge to be sure of your capability to troubleshoot future issues is higher and not for everyone(it seems a custom functional dsl is not for everyone)
If you are ready to become a true master of nix, you are going to be much more comfortable to use nix
If you want to be vaguely familiar with the tool you use and just get by(as most do) than ansible is probably the best choice.
Anyway to know for sure you better get yourself familiar with both on not so big projects(like a homeserver).
“big” and “small” are under-defined: the size of what is meant here? configuration code line count? time frame? performance metrics of machines under management? number of users?
if you substitute “team” and “personal” for “big” and “small”, then popularity/familiarity considerations (as spelled out above) apply.
There are also some hard-to-capture variables here pertaining to what you’ll be running and any language ecosystem(s) you’ll need to work with.
If you’re mostly talking about configuring a few servers running common software there may not be a lot of difference in effort between the two.
Nix has its own logic that generally doesn’t align with the package ecosystems of individual languages, and most of the integrations are ~community projects. If you’re running one or more bespoke apps that use language packages, the experience can differ a lot from ecosystem to ecosystem.
(I’ve only used Ansible once or twice, so I’m not sure if this commentary applies there as well. I imagine that Ansible runbooks will be more-straightforwardly engaging with the underlying language package managers. I imagine it’ll take less effort, but I also imagine it’ll be as prone to reproducibility problems as the underlying language ecosystem’s package management practices are?)
So I started in with Nix when I was still using Ansible to manage the deployment for some of my development systems on a regular Linux distro. I was, like most newbies, kinda intimidated by NixOS and the whole module system at first, so I started by trying to plug Nix in as the package fetcher for my Ansible deployments because I was having issues with the specific version of some packages not playing well with configuration scripts they would run, and locking the versions with Nix seemed like a sensible solution.
I ended up giving up on that approach because of some difficulties I ran into and made an attempt to port my existing configs to a full NixOS system that I iterated on in a VM until I was comfortable enough to deploy it on bare metal.
As other’s have rightly pointed out, there is a bit of a learning curve with Nix, especially if you’ve never been exposed to a purely functional language before, but what doesn’t get mentioned quite as often sometimes is that, I feel at least, Nix is actually orders of magnitude simpler to use and manage once you get a good understanding of it.
I feel that way because it simply illiminates so many possibly impurities and discrepencancies that there is just no other way to solve quite as nicely in other systems. In short, moving from Ansible to NixOS was a revelation for me personally. There is a whole class of bugs ranging from incompatible package updates, to full on linked library hell that I simply just don’t have to deal with at all anymore. For this reason alone, it has made me far more productive, since I can spend more time focused on actually progressing on a given task, and less on debugging various system issues as they arise.
Don’t get me wrong, Ansible is a decent tool, and if you’ve never worked with it before, I’m sure there is valuable knowledge to be gained from picking it up. With that said, I really feel like either Nix itself, or some future tool inspired by its design will inevitably become the future basis for system deployments, as there is just something magical about knowing that, once my configuration is in a working state, it will always work, and really can’t break, at least at the system provisioning level.
I’ve never used Ansible, but I used Chef before starting to transition to NixOS.
I believe Ansible has a Convergent model of system configuration whereas NixOS tries to achieve and comes much closer to achieving a Congruent model (see Why Order Matters: Turing Equivalence in Automated Systems Administration for definitions of those terms).
An example of this is at a company I worked at, we had a list of users who have access to the systems. When someone leaves, we want to remove them as a user from the systems. On Chef, we have to add a line to our user configuration like remove_user :john_doe. In NixOS, we remove the nix expressions for that user. We could probably write some script that implements declarative users in Chef, but in NixOS this is already well integrated. I believe these differences permeate the ecosystems.
Well, you can probably sweat over Ansible and the rest of the word soup cf engine clones (bad ones too) for a while, and get something running. Once you go down the nix rabbit hole, you’ll find its not only teaches you things that other operating system (engineers) either do not know, or cannot be bothered teach you. Many things that nix cares deeply about, i believed were not relevant when i was first starting out, but now, i’ve come along a long road, the stuff that nix tries to enforce, promote and to guide, is a path which is different, but makes more sense in the longer term.
Nix/OS can be also be an entire CI/CD pipeline, with probably the best built in integration tests on the planet right now. If you’ve ever had the ‘pleasure’ of upgrading a ‘build server’, or doing maintenance on the machine that ‘no developer’ wants to touch, you’ll find it ‘fun’…yes…fun… 
as the new matrix film came out yesterday, i couldn’t resist this.
Unfortunately, no one can be told what Nix is. You have to see it for yourself.
This is your last chance. After this, there is no turning back.
You take the blue pill - the story ends, you wake up at your shell and believe whatever you want to believe. Continuing to run installers mutating your system in blissful ignorance. Not questioning whether - perhaps - your package dependencies are incomplete. Accepting that one version is more than any person ever needs. Never worrying how to get here all over again.
You take the Nix pill - you stay in wonderland and I show you how deep the rabbit hole of reproducibility goes.`
so, my suggestion to you , is take the the Nix Pill…if you don’t like it , you. can always ask for a refund.
To me it depends what your current knowledge level is.
If you’re somewhat familiar with something like Arch Linux you should be fine with Nix.
If you’re coming from a Debian based system, have experience and are willing to learn, just be aware that the learning curve will be rather steep one with NixOS.
If you’re completely new to the topic I would recommend that you start with Ansible first.
I’m using Ansible a lot at work and to manage my personal servers (will try to replace them with NixOS servers soon).
In addition I tried to use Ansible to manage my laptop.
Managing servers works well enough because I usually don’t need something to change immediately.
On the laptop however I often just installed packages manually and then promised myself that I would add them to the playbook later (rarely happened).
Here NixOS works much better because it forces me to add the changes to the config beforehand.
Which I then can easily replicate on my other desktop systems.
Like the others already mentioned it is very easy to add stuff with Ansible but you have to remove it explicitly as well.
Which is IMO the most annoying part with it, especially if you copy custom scripts or files to the servers.
Just a slight rename will force you to write a task to remove the old file.
And for that you have to go down the rabbit hole. There aren’t too many good ideas. (Gerald Sussman) What’s powerful about Nix is the idea to acknowledge that system state is just the result of evaluating an expression in a pure functional language. It’s another way of looking at things, so the Matrix analogy is entirely appropriate with all implied twisted irony.
This is actually not about Nix in particular, it’s just one implementation for that idea, full of accidental complexity, which people trip over for good reason.
I have used Ansible for the devops of my company, and can confirm what Ryan says:
Here’s a simpler article about the same Divergent, Convergent, Congruent system management concepts. Concretely:
In Ansible, if you declare yourself an Nginx webserver into its YAML files, and deploy, Nginx is running.
If you delete Nginx from the YAML file, and deploy, Nginx is still running.
Thus, Ansible does not actually provide proper declarative system management: There is no guarantee that what you write in your YAML files isn’t actually what’s running on your servers.
Further, even our moderately-sized Ansible playbooks took > 10 minutes to run, because Ansible is just an imperative command runner without a real understanding of what’s happening on the other system, so there is no proper incrementality. To alleviate that, you can try to use conditionals but they are almost impossible to get right, and so you often end up some change that you want deployed being skipped accidentally. We wanted something that will take only a few seconds when, say, changing nginx.conf, and restarting only those things that actually depend on nginx.conf.
In combination, those 2 issues were unacceptable for my company. I thought that there must be a better way, and found nixops, and thus NixOS.
Thus we switched all our servers from Ansible to NixOS + nixops 5 years ago, and are very happy with it. Deploys are now declarative, and small changes apply within seconds.
Correct me if I’m wrong: Nix can only be used in Nix/NixOS/Linux/macOS environments.
It does not support Windows (yet). It does not support network equipment (routers, switches, firewalls, WAPs,…) or custom equipments (embedded systems, SANs,…).
Those are supported out of the box by Ansible and Ansible Network. And if your equipment/OS/software is not supported, you can write custom modules to do so. Not always easily, but you can do so. (I did that.)
Thus, if you have to manage complex data centers from top to bottom, from application deployment, whatever the OS, to entire network configurations, you can do so with Ansible.
Moreover, as some have mentioned, the Nix, Ansible and Powershell DSC systems management models are different, probably making them hard to mix and match (using Nix for Linux systems and services/applications, using Ansible for the rest, for example).
This is not a dismissal of Nix/NixOS/NixOps: I’m currently studying those It’s just that I don’t see (yet) how the Nix model could be used for complex, cross-platform environments.
Welcome!
http://www.infrastructures.org/papers/turing/turing.html
You may find this interesting.
I know a of a few network and robot infrastructure startups that are actively looking at nix in their control planes. Many run linux already. If you can’t get Nixos directly running on them, then using nix as a build tool for them it probably a good start.
It’s a question of state. Ansible doesn’t really help you identify where state is, or if it’s needed, or how to manage it long term. Nixos cheats, by rebuilding the state of the machine from scratch via a declarative configuration rather than try to mutate state from the current system. It’s a very very nice cheat. It also has the weird side effect of making you learn about state, where it lives, and what you should be doing with it.
That’s not the fault of the Ansible it’s just how it functions. Nix is just another way of thinking about the system build and configuration task.
Nix solves a lot of these problems, but gives you some new problems, which are nicer to have.
If you are trying to ask if Ansible is better than Nix, then it’s an impossible question to answer, because they from not same school of thinking. Ansible just regurgitates what Cfengine does/did, where nix is a entirely new way of thinking.
It’s rather like comparing walking (or crawling) to traveling on Mr Musks Starship…
Both are involved in travel, one has been used for years and is the industry standard, but only one will get you to Mars.
If you want to go the Ansible route, then you won’t be without a job in a complex data center, deploying software to microsoft windows machines and cisco routers, however only time will tell if the job in the complex data center will make you happy.
ssshhhhhh…keep it quiet…Nix is pretty fun to work with… 
Interesting discussion so far…
I’m actually using both in combination, which might be considered an anti-pattern of sorts, especially if you consider that you can use nix-ops …
I have two VPS running nixos, where e.g.nginx with virtual hosts is managed declaratively, but their contents (gatsby-generated static sites) are pushed from a local gitlab CI using ansible to their respective webroots on the VPS.
Actually (even “worse” of an anti-pattern) I also push updated /etc/nixos/...nix from my local private git clone to the VPS with ansible (and do a nixos-rebuild switch after that). Obviously the latter pattern would be better replaced by something more nix-ops like.
I guess this is just to say that if you know ansible/“classic” devops but want to move to nix it is possible to mix them at first and hold-off on nix-ops if it’s “too much to handle” at first.
Indeed I’d be interested what is the recommended (nix) way to handle the former scenario, especially considering resource-constrained webservers and a process featuring static site generation in a local CI/CD instance (i.e. no dev-tools on webserver) and deployment of the webroot to a remote VPS (running nixos). This should be extensible also to e.g. web-service containers such as e.g. nodebb under podman/docker, where I suppose things like postgres would just run natively on the VPS?