3 ms·

A couple of reasons spring to mind as to why Ansible is an improvement on the eminently workable approach you outline here. One is idemopotency - The fact that

A couple of reasons spring to mind as to why Ansible is an improvement on the eminently workable approach you outline here. One is idemopotency - The fact that it is not easy to run the above script on a bunch of host just to 'fix up' a config that was somehow broken or to add or amend a directive in httpd.conf type of thing. With Ansible, you could re-reun the playbook and it would only change what needed to be changed to bring everything in line with the playbook, i.e. just the directives in httpd.conf and then do the reconfigure on httpd to bring in the changed config. The other is inventory, so such a change as I outlined could be, with a one liner playbook command, be run against all Dev hosts only, or Dev and UAT hosts only, or Red Hat hosts only etc, when you're managing a lot of hosts this is invaluable. Even for just checking some config or other easily by running a shell command against some set of hosts.

kosma 10y ago
Ansible's idempotency is an illusion. Removing an item from a playbook will practically cause it to be "forgotten" by Ansible, but left on machines where it was deployed previously. While there are mechanisms to remove stale items (state=absent), in practice it takes Spock-level discipline to do this properly. Playbooks are also not tied to a particular Ansible version, meaning just upgrading Ansible can cause changes even though your definitions are still the same. In my experience Ansible promises consistent environments, but consistently fails to deliver.
vog 10y ago
> One is idemopotency - The fact that it is not easy to run the above script on a bunch of host just to 'fix up' a config that was somehow broken or to add or amend a directive in httpd.conf type of thing In my case, I simply overwrite all config files and restart all services. This is not "efficient" (but still sub-second), but I believe this is idempotent by all means.

kosma 10y ago

Ansible's idempotency is an illusion. Removing an item from a playbook will practically cause it to be "forgotten" by Ansible, but left on machines where it was deployed previously. While there are mechanisms to remove stale items (state=absent), in practice it takes Spock-level discipline to do this properly. Playbooks are also not tied to a particular Ansible version, meaning just upgrading Ansible can cause changes even though your definitions are still the same. In my experience Ansible promises consistent environments, but consistently fails to deliver.

vog 10y ago

> One is idemopotency - The fact that it is not easy to run the above script on a bunch of host just to 'fix up' a config that was somehow broken or to add or amend a directive in httpd.conf type of thing In my case, I simply overwrite all config files and restart all services. This is not "efficient" (but still sub-second), but I believe this is idempotent by all means.