3 ms·

This kind of feeling is a large reason why I created http://ansible.cc/ http://ansible.cc/ The feeling that I want to write something quick or easy shouldn't

This kind of feeling is a large reason why I created http://ansible.cc/ http://ansible.cc/ The feeling that I want to write something quick or easy shouldn't depend on the size of my infrastructure, it should be easy either way -- 500 servers, 50, 1, doesn't matter. That being said, our modules do need some patch-love for things like launchd and OS X groups, we've been a lot more Linux/Unix focused to date. (Patches are welcome of course!)

contingencies 14y ago
Thanks for your reply Michael. I had a look at Ansible and your personal website and you definitely have been doing work with a fair bunch of serious systems in this space, so I really value your perspective. However, looking at the ansible news and documentation - "playbooks, configuration management, deployment, and orchestration" - I really couldn't see how it differs significantly in paradigm to puppet. Is it just the ability to converge on some defined configuration automatically? It's unclear to me. Would you be so kind as to summarise the differences in brief? Thanks.
- mpdehaan2 14y ago
  Sure, multi-tier has been a focus from day 1, so a common example is a workflow where you want to hop between tiers of a 3-tier application, touch load balancers and monitoring along the way, and so on... that's all trivially possible primarily because it's push, not pull, based. Ansible can both code up and execute those kinds of workflows very quickly. A major core other aspect is not requiring any agents on the remote nodes, not even having a server, and not needing an additional PKI. Because it's using SSH, it's using your OS credentials, so if your boxes are, for example, using Kerberized SSH, that just works out of the box. The resource model is still very puppet-like (state=absent/present, idempotence, etc), in that we have states and convergence, but I have tried in many places to not make this a programming language, and keep the amount of syntax down. A key focus was making the content readable, so you didn't have to think about dependency ordering and could tell by skimming the playbooks top to bottom exactly what they will do.

contingencies 14y ago

Thanks for your reply Michael. I had a look at Ansible and your personal website and you definitely have been doing work with a fair bunch of serious systems in this space, so I really value your perspective. However, looking at the ansible news and documentation - "playbooks, configuration management, deployment, and orchestration" - I really couldn't see how it differs significantly in paradigm to puppet. Is it just the ability to converge on some defined configuration automatically? It's unclear to me. Would you be so kind as to summarise the differences in brief? Thanks.

mpdehaan2 14y ago
Sure, multi-tier has been a focus from day 1, so a common example is a workflow where you want to hop between tiers of a 3-tier application, touch load balancers and monitoring along the way, and so on... that's all trivially possible primarily because it's push, not pull, based. Ansible can both code up and execute those kinds of workflows very quickly. A major core other aspect is not requiring any agents on the remote nodes, not even having a server, and not needing an additional PKI. Because it's using SSH, it's using your OS credentials, so if your boxes are, for example, using Kerberized SSH, that just works out of the box. The resource model is still very puppet-like (state=absent/present, idempotence, etc), in that we have states and convergence, but I have tried in many places to not make this a programming language, and keep the amount of syntax down. A key focus was making the content readable, so you didn't have to think about dependency ordering and could tell by skimming the playbooks top to bottom exactly what they will do.