|
|
|
|
|
|
by anyoneamous
1022 days ago
|
|
|
Sadly it's not that simple. For example: - Run a playbook which asserts the existence of a user - Playbook fails at a later stage - Executing an earlier version of the playbook which doesn't have the user assertion won't cause the user to be removed, just ignored. You need a different (assert not-existing) statement to actually remove the user. In general these things won't be impactful - but they do mean that if you iterate on your deployment playbooks, you will end up with orphaned files/resources scattered around unless you explicitly tidy them up. IME using Ansible for small-scale automation is no faster than just running the tasks manually, once development time is taken into account - you need tens of servers to make it worthwhile, by which point containers start to look more appealing. |
|
|
Ansible has a very low learning curve. I cringe with the thought of the time it would take documenting then typing in all the commands to setup my servers manually. That's just not feasible. Ansible provides a sweet spot between traditional "pet" servers and containerisation.
It's not only the number of servers that matters. It's also about being able to create ephemeral staging/developer environments, and easily being able to easily migrate to different VM providers.