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.
2 Likes
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).
7 Likes
“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.
1 Like
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.
9 Likes
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.
16 Likes
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.
5 Likes
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.
3 Likes
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.
2 Likes
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.
16 Likes
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.
2 Likes
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… 
4 Likes
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?
3 Likes
interesting points, it takes a bit of time to ween yourself off the ‘standard’ devops tools, Hercules CI effects might be exactly what your looking for.
If you can build up enough momentum to escape the docker black hole gravity well and avoid the oncoming dockerpocalpyse , then you enter devops rehab… I actually regard docker as operating system in it’s own right, the same as emacs ;-). I’ve got one operating system, i don’t need to run another OS within and OS…unix is already good enough, without these esoteric middle ware wrappers around cgroups (name spaces). My view changed when i saw https://www.youtube.com/watch?v=8fi7uSYlOdc . Liz is truly brilliant and smart and hat off to them…, but you get to learn how shonky these container abstractions can be , especially with tangle of virtual network stacks they employ…
But going from traditional tools to full nix, can be a steep (inverse parabolic) learning curve, so , what ever works now…, then do it… even its an anti pattern, you’ll find new nix patterns to move more systems to a fully declarative nix configuration. You will get more funky with the nix language, you’ll find you need a lot less moving parts to the job.
I find GitHub - purpleidea/mgmt: Next generation distributed, event-driven, parallel config management! a really interesting project, which is a basically a DSL for configuration management, using etcd for shared state. Their talk https://www.youtube.com/watch?v=Kd7FAORFtsc is cool. There are some interesting things about how these cfengine clones can be greatly improved. I feel that these is a connection between mgmt and nix somehow , but i don’t have time to research further at the moment.
What ever you do, keep doing it, the future is nix (maybe) and the future starts with you.
https://www.reddit.com/r/NixOS/comments/ohpi2z/nix_is_the_future_and_the_future_starts_with_you/
3 Likes
I’ve had great success in pushing websites with Hercules CI + Effects. There’s also docs for deploying machines Deploy a NixOS Machine :: Hercules CI Documentation
I wrote this effect to deploy the Plutonomicon website, and it is really simple. Let me know if you don’t understand it, and I’ll do my best to explain it.
2 Likes
Thanks, looks interesting. I did a first quick check, and noticed currently there’s only github support (I also saw this issue). But that got me thinking, I’m already using gitlab-runner on local nixos hosts, they’re currently executing “normal” container builds submitted by a lan-local gitlab instance, shouldn’t that the a good base to get hercules-ci also working on them somehow?
integration of herc-ci and gitlab is on the cards… so that would be a great help for those that want to jump from the microsoft ship to the gitlab ship (im not sure who own’s gitlab) , just watch out you don’t get attacked by the Crimson Permanent Assurance vessel
1 Like
GitLab owns GitLab They’re independent, funded by corporate buyers of the enterprise version of their software. It’s the open-core business model, so you get slightly earlier access to new features and better enterprise-targeted integration for SSO and such if you pay. Also GitLab states they prefer organizations who can afford it pay for the enterprise license, so you go on santa’s “bad” list if you don’t.
gitlab.com is their generous public offering, probably used as a test bed and marketing platform.
I don’t see them selling to Microsoft anytime soon; even if they do, the project is likely to just be maintained as a FOSS fork down the line. Anyway, my point is, go support open core organizations! 
2 Likes
No, definitely not. We are using Ansible in medium sized project and from my perspective it´s pain. Even though you are supplied with some extra modules from Ansible Galaxy it feels like every time things are getting serious you are doing bash. This plus the strange lexical design and the mixture of describing a desired state and having a sequential stepwise process makes this concept as a language compared to terraform or nixos just painful.
2 Likes