The learning curve to Ansible is low, and it doesn't depend on any additional software running on the server.

I dislike yaml, but I like Ansible. I think it hits the sweet spot for small and medium size enterprises, who are looking for a middle point between manually provisioning servers and containerisation.

>bash and python

Neither of those of idempotent.

It seems likely you are coming at this from the perspective of "when I find an ansible playbook on github its hard to follow whats going on".

There is a certain truth to that, but much of its complexity is probably related to said playbook developers trying to abstract away specifics and create a playbook that works on a variety of distributions / configuration options.

Ansible can be as simple as a single file that proceeds sequentially like a bash script.

Most of the ansible roles I come across written by my team are not idempotent either, its a huge lie that Ansible is idempotent. Its idempotent if you put the effort into make it be but if I see tons of shell or command module invocations without prerequisite checks to see if the work should be done. Most devs I see using Ansible treat it like a shell script written in YAML and to that purpose it sucks.

I can appreciate that I learned the term idompotency from working with Ansible, but I think they failed to really make it a feature of the language- it could have been a stronger default, explicit, like Unsafe in Rust. As it stands, writing idempotent Ansible takes as much discipline and intentionality as any other language, and can prevent integrating roles that other's have written without such discipline. There is value in it, but not in respect to idempotentcy as any sort of inherent principal (at least outside of the std lib, which is ofc pretty great abt it).

This. The built in tasks only get you so far. If you have anything custom you have to create the task for it yourself, with idempotency in mind, at which point you might as well have the exact same logic in a ./install.py file.

Even with the standard library of predefined task, most devs don't put in the effort to learn them since "ifconfig | grep" and other commands are baked into their muscle memory, they would rather make a quick and dirty bash-step than figure out what is the best practice ansible-equivalent. In the end the result is a sequential shell script written in yaml with no guard rails keeping it idempotent, plus riddled with jinja template-substitutions making it a nightmare to follow.

A truly declarative system would be designed more like makefiles, really enforcing idempotence. With steps in playbooks being executed in sequence it's too easy to fall back to script-thinking and side-effects. Sadly i'm not aware of any.

> >bash and python

> Neither of those of idempotent.

There is nothing magical about Ansible that makes it idempotent by default either.

The simple stuff like having specific versions of a package installed that you might be thinking of is just using Python under the hood. If you get into more complicated stuff, especially around custom infrastructure abstractions you use internally, guess what, you will have to write a bunch of Python and effectively call it from Ansible. And you will have to put in extra effort to make sure it's idempotent.

At which point you start thinking...why not just write a Python script instead? At least that gives you all of the flexibility.

> It seems likely you are coming at this from the perspective of "when I find an ansible playbook on github its hard to follow whats going on".

No, I've worked with ansible over 3 jobs, for the past 4 years. It hasn't been hard to convince colleagues to move away from Ansible once I show the competition. Sadly the migration process is rarely easy.

If you don't mind me asking, what's the competition? Do you mean you have a bespoke bash stack or you're using chef, capistrano, etc.?

I, too, am wondering what you recommend be used instead.

Yes, it can get hairy but I just have a hard time seeing an adhoc mess of python and bash doing the equivalent amount of lifting without becoming an even bigger hairball. And the thing is, you can also just run those same bash and python scripts using Ansible if you really want to, just to keep them orchestrated properly.

> you can also just run those same bash and python scripts using Ansible if you really want to, just to keep them orchestrated properly

Most of the time (i.e. if your Bash script generates a known file), Ansible also gives you idempotency for free, thanks to the ’creates’ parameter.

Wait, Ansible is sold as being idempotent? Really?

What about it isn't idempotent for you? Are you falling into the anti-pattern of using shell/command all over the place instead of real modules?

We have playbooks installing and managing our databases, web servers, VoIP PBX, DNS servers, backend services, and on and on. All completely idempotent and safe to run at any time against any host. No special effort whatsoever was required to make that safe to do.

Perhaps I'm not using it for its intended use case, but I've run into many issues where built-ins simply don't do the job. I'm using it for setting up my local personal machines, including a remarkable tablet.

If Ansible is a pain, what's your view on Chef? :)

I've found Ansible good for quick one-liners across multiple nodes :)

Having used Puppet, Chef, Ansible, custom shell and Python scripts, and Terraform provisioners, I'll say there aren't really any "good" automation tools.

They each have their pros and a long list of cons.

The good thing is that a lot of garbage that I used to do with those tools has been replaced with K8s. Some Terraform and Ansible still survive for self-managed VMs, but that's about it.

Many of the automation tools aren't great, but some are better than others. I'd take terraform and puppet or chef over ansible any day. I'd much rather have something that is declarative and easy to make idempotent over something that by design is procedural and much harder to make idempotent. Even bash easier to make idempotent. Don't forget yaml hell that ansible loves to put you in. If there was a tool that had a planning and apply phase for server management like terraform, I'd take that (for pets only). Ansible's dry run barely works since it requires additional effort to get working properly, often impossible without faking data. It's been a while since I've used chef or puppet and I can't remember if their dry run or the like is useful.

Having said that, in an ideal scenario, you use auto scaling combined with cloud init to avoid having to manage live servers. Cattle, not pets. That way you can provision images using chef/puppet, and then have them deploy and be automatically deployed. It gives also gives you the opportunity to create self healing architecture that requires less baby sitting.

K8s certainly forces you to think closer to that architecture and that is good.

What is your take on cfengine? Just curious...

Do you have any suggestions on good set of sdk or library for writing those automations in python? The main reason for using ansible for me was always because of their rich built in tasks. I tried writing in python my automations but even very simple tasks were needed too much effort compare to ansible so I had to return back.

I wouldn't. I said that as a point the ansible is bad. It is procedural and hard to follow. Bash and python don't have any host management features (I.e. inventories) so you'd have implement that yourself, which won't be easy.

I suggest looking into the alternative, such as chef, puppet, saltstack etc. They allow for declarative configurations and make it a lot easier to make your configurations idempotent. On top of that, do the infrastructure itself (aws, gcp etc) in terraform (or pulumi if you want it in a programming language). Terraform has its issues, but it is certainly a lot better at managing infrastructure than ansible.

Ansible and Puppet are tools that do very different things. I mostly agree with you, but Ansible does work decently as an orchestrator.

You want to use tools like Puppet and Terraform to define the state of your systems, and Ansible to run operations on those systems, because not everything is stateless; trying to upgrade a database with Puppet or Terraform will be painful, but Ansible won't have trouble.

I do wish it had static typing (Puppet took 4 major releases to finally get it and its type system is its best feature over alternatives) and less YAML, but it is what it is...

Nowhere near as complete as Ansible or even in the same space, but helps to write remote SSH automations:

https://www.fabfile.org/

Saltstack. It is super easy to write your own python modules and everything else, such as a transport, module distribution, delivery from git and management, is already there for you.

Give pyinfra a try

https://github.com/Fizzadar/pyinfra

Having used all of the configuration management tools available, and I do mean all of them, I have found Ansible to be the most flexible, the easiest to execute arbitrarily, and the easiest to understand and package alongside applications. I would love to know what you're using that's better than Ansible and doesn't rhyme with poohbernetes.

I wholeheartedly agree. I've used CFEngine, BladeLogic, Chef, Puppet, Ansible, Salt in various infrastructure management tasks in the UNIX/Linux space. They're all shitty tools, don't get me wrong; they all have giant gaps in functionality especially when it comes to physical storage management. However, Ansible is maybe the least shitty. The cleanest and easiest environment to manage by far, was NIS/NIS+ with properly managed and groomed tables, and bash/ksh over automounter/NFS. I watched this work idempotently, and easily, across arch platforms and various versions of operating systems (some around since before i was born) without anyone on our small team breaking a sweat). Unfortunately, this architecture requires vigilance and a level of control that seems to have slipped away from the operations groups in recent years.

Github.com/Triplea-game, I wrote bash scripts to do deployments as a way to avoid ansible. The bash scripts were not well received (who likes bash scripts) They were coverted to andibke and became simpler. There was then an uptick of people engaging with the deployment code. IMO it's tough to do ansible well and keep it simple. In part restricting how it is used, where to find what, I think goes a long way

> It's a mess of yaml and what feels like a million yaml files that is always extremely hard to follow.

Don't look at kubernetes then...

I somewhat agree. That's why I chose Bash in teaching people deployment. It's better to go back to basics, and then if you know how things work, can choose (or write?) a higher level tool you like.