You get a declarative config with ansible so long as you also reinstall the system every time. That's how it's meant to work professionals in an immutable setup. The power of ansible is that you can also use it as mutable on an existing infrastructure or on firewalls and stuff. It's power is it's flexibility to be do anything.
I found Ansible as a product, lacking. Granted maybe some of the issues was because it was AWX? Unsure. But everything about it was like pulling teeth.
I personally prefer Salt, if for no other reason than it's significantly faster. And frankly I found writing the respective configs much easier to ready and follow with Salt.
I feel like Red hat has pulled off a remarkable marketing feat with Ansible.
I'm my work I consult with a lot of different sysadmins and have to be conversant in whatever they are using and that includes Ansible for a big chunk of the industry.
I'd say for about 90% of people I've worked with using ansible heavily after getting the hang of it, when they are being honest they don't see what it is getting them (generally it's a lot more tedious but not better than alternatives), but are afraid to admit it because "not getting Ansible" might be seen as being inadequate in the industry. And this is only counting the folks that I consider to have gotten far enough to be competent in Ansible, reflecting experiences of people who know how to use it, but still don't understand why they should see it as "helpful". Lots of people don't make it that far (and those folks are even more shy because they think themselves "dumb" for not getting it ).
Completely agree. I haven't met a single person that has genuinely liked it. But they feel compelled to use it and speak highly of it because it's what you do in the industry. And a lot of the people that do keep pushing for it keep acting like it's going to be the single solution that fixes everything somehow magically...
And I don't know about you, but I know an excessive number of people it seem to think that if you want to idempotent then it has to be ansible... As if suggesting that it's impossible to be idempotent by any other means.
I really like Ansible and have used it for my personal dotfiles for years. I don’t think it’s a silver bullet and I’m aware of a lot of the criticism. Containerization or immutable infra solves more production problems so I don’t really use it much at work.
At least in the devops/SRE circles I work in, we know there are different tools for different jobs. While we might fight about which is the best, I haven’t seen the ossification you’re describing.
What do you like about ansible? I guess it abstracts away the need to check for OS/init system? How else does it help in place of shell scripts?
Also after using NixOS, it's amazing what NixOS does and disappointing that ansible is not so great for deterministic config [^ansible_drawback], its more or less a batch of commands executed together. The closest thing, to NixOS, I've been able to achieve is load a variables file in playbook.yml and enable/disable service or install/purge pkg based on variables declared. I might be nitpicking/wrong given I've not been using long enough but directory layout is kinda too verbose. I say that because it'll get really messy very quickly when writing modules for more services. NixOS is great, you only have to have configuration.nix or flake.nix+flake.lock too (if using flakes) and rest you can import however you like.
[^ansible_drawback]: I know that nix stores its state in /nix and ansible doesn't have any such assumption about the target host so it can't rollback to previous state
I like how simple it is. It’s made distrohopping very, very simple for me over the years. The only pet machines I have are my actual dev boxes. The rest are cattle I manage with other tools. Galaxy has also made it much simpler to consume other Ansible which used to be really annoying.
I’m on the fence about Nix. When I first saw years ago it was yet another package management system. I’ve seen enough interesting things with it now that I’ll probably try it out the next time I want to rebuild my configs from scratch.
I mean I know people who have a lot of ansible knowledge and they were always like "yeah sure it's declarative, you can ensure files are the correct version and stuff", but that's so far away that is from what NixOS does (unless I misunderstood something). I mean, the same task can be accomplished alright, but it's a bit like writing your own NixOS.
Exactly, ansible is basically imperative, where write the steps declaratively.
Whereas nixos is more like a compiler that compiles to a working linux install.
If I added the software myprogram and a config file at /etc/myprogram.conf, that’s pretty easy in both. But if I needed to to then remove those it gets different .
With nixos it’s at easy as removing the two lines that add the program and the config file; after the next “compile”, the file is gone and myprogram is no longer available in the PATH.
With ansible you need to change the relevant step to use apt remove instead of apt install and to change the config file step in a step that removes the file.
Don’t get me wrong, ansible is still better than writing a lot of bash scripts, especially if you don’t have people with a lot of shell experience.
But tools like nixos and guix are on a whole other level.
With ansible you need to change the relevant step to use apt remove instead of apt install and to change the config file step in a step that removes the file.
Wait until you have 2 services that use the same resource. Now you need:
When both are enabled the resource is set up.
When either one is enabled the resource is still set up.
When neither is configured the resource is removed.
Doing this with Ansible is a nightmare. And 99% of the time you don't even realize that you have this problem until your configs don't work for some reason.
Yeah, ansible is just full of these scenarios. Even in the best of times it demands an awful amount of verbosity.
Half the time I see people land with no more idempotency than they had before, which is supposed to be one of the big draws. A lot of the things they are frontending are inherently idempotent, and a lot of other times the modules themselves fail to be safe to run multiple times for the admins input. I've been shocked how fragile some modules have been given its regard in the industry.
