On 21/07/2012, at 11:20 AM, Brian Gupta wrote: >> 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. >
Thanks for the input Brian. I have to say I definitely prefer procedural scripts with a predictable run order, but you can accomplish this with stages. I've yet to refactor my own code so that I can deploy an ecosystem of servers in one go rather than a few runs per server. I like your analogy that Ansible looks like a step above fabric & capistrano - that's the impression I got too. But I haven't used it either. Marc -- 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.
