- If you have SSH access, you can use it. No matter what environment or company you work for, there’s no agent to install and no need to get approval to use the tool. It’s easy to build up a reproducible library of your shell habits that works locally or remotely, where each step can avoid being repeated in case there’s a need to rerun things.
- If you get into an environment where performance across many machines is more important you can switch to pull based execution. Because of that, I see very little advantage to any of the other tools that outweighs the advantages of Ansible.
Try Puppet Bolt. Workflow is similar to Ansible. No pesky master or certificate setup, no preparation needed, just an inventory file and SSH to the remote server. You get the entire ecosystem of Puppet modules and the Puppet language scales well when your configuration becomes larger.
> If you have SSH access, you can use it. No matter what environment or company you work for, there’s no agent to install
I don't get why is this always brought up as a major advantage when discussing CM. Ansible actually installs its Python runtime to target systems. Once I had a server that had full disk root and Ansible failed to work because there was no space left to copy tons of its Python code.
Ansible doesn't install a runtime on the target machine, it temporarily copies over the scripts that do the work and removes them after the run is complete. These are a few kilobytes typically.
No configuration system is likely to work with a full root partition, though.
Agree. Although I personally prefer Ansible to the alternatives, the one thing I don't like is that it does require python to be installed on the target hosts for most modules. That's not a problem usually, but every now and then it is. Also, sometimes additional python package requirements are needed, managing those in an automated manner is usually a hassle....
I've had this idea for a config management system that compiles all provisioning code to posit shell. One of those years I'll finish it... :-)
However, while I know you meant "all the provided modules," it seems they are headed toward a less "batteries included" style and more (pypi|maven|npm|rubygems) style of "the community will sort it out" mechanism of distribution: https://docs.ansible.com/ansible/2.9/user_guide/collections_...
Which I welcome wholeheartedly because landing even the simplest fixes to ansible modules is currently a very laborious and time intensive operation
> Ansible doesn't install a runtime on the target machine
> it temporarily copies over the scripts that do the work
So yeah, it does copy its "runtime". It cannot work purely by running commands over SSH. It needs to copy "its agent" to target, and worse, it does this every time you run it.
- If you have SSH access, you can use it. No matter what environment or company you work for, there’s no agent to install and no need to get approval to use the tool. It’s easy to build up a reproducible library of your shell habits that works locally or remotely, where each step can avoid being repeated in case there’s a need to rerun things.
- If you get into an environment where performance across many machines is more important you can switch to pull based execution. Because of that, I see very little advantage to any of the other tools that outweighs the advantages of Ansible.