> On 18/07/2012, at 8:54 AM, Marc Lucke wrote: > >> So I'm seeing a lot of hype around Ansible. It seems to be a compelling >> story. I've looked around and found a lot of stories about why you would >> use it over puppet, but not puppet over ansible. Can anyone relate personal >> experiences or point to some interesting reading?
On Fri, Jul 20, 2012 at 8:11 PM, Marc Lucke <m...@marcsnet.com> wrote: > … well there you have it. No advantages. Or nobody cares about this better > system. Or nobody knows :) > Well, I am guessing most of the people on this list haven't heard of Ansible (until now). (Other than any Orson Scott Card fans.) Taking a quick look the high level differences are: 1) Userbase/community - Puppet has a much larger userbase and community. My belief is this is an advantage for puppet. 2) Larger number of modules available for use with puppet. 2) Ansible uses SSH to connect to the managed hosts. Pros and cons here. Will let others argue which is "better". 3) DSL - Puppet has a Declarative DSL which largely separates the what from the how. Ansible seems to mix the two in their playbooks. (Much like Chef, but with Ansible not being Ruby specific.) I prefer a Declarative DSL, but others may prefer alternate approaches. 4) Python vs Ruby - I feel Ruby is more popular in the Devops community, and find I like the syntax better, but Python is not necessarily a bad choice. That said, largely as a puppet user, one doesn't have to deal with Ruby. (Nor does a Absible user have to deal with writing Python.) This decision would be more important if you wanted to contribute to one of the projects in question. 5) GPL vs Apache - DIfferent strokes for different folks. I actually prefer GPL licensed software, but many prefer the Apache 2 license. 6) Push vs poll. - Ansible pushes configs to hosts where puppet clients check in to a central server on regular intervals. (My understanding is that ansible is somehow serverless.) 7) External data - Puppet supports the concept of storing ones data separately from the code. It appears that ansible does not have a standard method for doing so. 8) Built in remote command execution. Puppet relies on mcollective for this feature, which is additional administrative overhead to setup and maintain. However, on the flip side, I am certain that mcollective is much more scalable than ansible. (IE: I am not using a tool that uses ssh to manage 1000s of servers.) I can't say as a blanket statement which is better.. If all you are managing is 10 nodes, I could see simplicity of setup being an advantage. If you need to scale obviously the scalable solution wins. That said, I would probably prefer to use the scalable tool in small scenarios, so I don't have to learn two toolchains. 9) Puppet manifests are historically have non-deterministic order execution, unless dependencies are specifically declared. I think this is the correct approach as implicit dependency graphs can be dangerous, and lead to incomplete understanding of one's configuration. That said, we are all used to scripts that run in order, so this is definitely a learning curve when folks are new to puppet. 10) Puppet is available in an Enterprise Edition that you can buy from a known vendor with a full support contract. This gives many companies warm and fuzzies. The majority of folks would say this is an advantage for Puppet, however if one wants to be on the FLOSS bleeding edge, and you don't have any money for software/support anyway, it might just be a wash. All in all I would say that Ansible feels more like a deployment system with some basic configuration management idioms supported. (Basically a step from capistrano or fabric towards a full-fledged cfg-management framework.) I'm also sure I didn't get this all right, and missed differences, as I have never used Ansible, and quickly skimmed the docs. Cheers, Brian -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
