> Doing this with Chef would probably mean chasing down a knife plugin for adding Linode support, and would simply require a full Chef stack (say hello to RabbitMQ, Solr, CouchDB and a gazillion smaller dependencies)

It is throwaway lines line that where you really need to be careful since, no, you don't need to RabbitMQ, solr, couchdb etc. You can just use chef-solo which can also be installed with a one liner (albeit running a remote bash script)

When comparing two products (especially in an obviously biased manner) you need to make sure you are 100% correct. Otherwise you weaken your case and comments like this one turn up.

Another Ansible convert here. Our entire team uses it, we love it. We have a semi-unique situation where we have to do a lot of finagling to access some machines, don't always have control over what sits in front of them, and frequently have to comply with outside regulations. I won't go into too much detail, but Ansible is flexible enough and expandable enough to fit our needs. We were able to have Ansible reading from our custom inventory system in under a day, have expanded it to tie in with tons of internals, and all with very minimal effort. What would've taken weeks setting up with Puppet or Chef just falls into place. It's a beautiful thing. Highly recommend giving it a try, even if just to have a quick way of setting up your own dev machines.

The only weak point Ansible has is that its documentation doesn't show enough real-life scenarios. Fortunately, it's really easy to grok and extend when you see a script, so I wrote this to help:

http://www.stavros.io/posts/example-provisioning-and-deploym...

This is definitely cool but the real hard problem isn't in these simple easily scripted cases. The real hard to solve problem is managing all the complexity of similar-but-different hosts.

This article could just as easily have taken the complete opposite view of Ansible by saying things like "parallel ssh sessions don't scale, strong encryption costs too much CPU time; push can never work reliably therefore pull is the only viable model; etc. etc."

I feel one of Ansible's strongest points to champion is the low barrier to entry. It takes minimal understanding to get going, compare that with at least 1 month hands on with cfengine or perhaps 2 weeks puppet before you would consider yourself proficient enough. With Ansible it's 20 mins or so.

Used Chef before. In current gig, it's just me managing stuff. I picked Ansible over Chef and Puppet cause it's low(no) barrier to entry and simplicity. Also ability to ad-hoc commands means I didn't have to use another tool for that.

In the 1year since, Ansible has exploded in capability. It isn't quite as low barrier anymore (more to config language) but still gobs lower than others. While adding much sophistication.

I wouldn't even consider Puppet or Chef anymore. Salt or Ansible. Although, Python guy, so biased more than a little.

Unfortunately, we were forced to toss out Ansible immediately in our tool selection process because it did not support Windows OS clients without Cygwin.

Also, none of the "VM lifecycle management" tools we needed like Foreman or its commercial equivalents had any integrations with Ansible.

These concerns left Ansible dead on arrival for us. It sounds like a decent tool if it matches your needs.

I think you can think of these tools on a spectrum from pull-based to push-based. I say spectrum, because many of them are in reality hybrid. Tools running agents are naturally pull-based, where as with push you don't necessarily need an agent (consider sand blasting ssh commands).

CFEngine is by far the most pull-based tool as it is underpinned by a theory mandating this behavior. Puppet is pull-based but with more push, Chef is even more push based, and Ansible and Salt are (I guess) mostly push.

In the end it depends on what is more practical for your situation. If you have a few machines, then more push will be practical, but the more machines you have, pull-based solutions scale better.

The main thing that irks me (last I tried it) is that the pkg repo functionality uses add-apt-repo. This makes it not work on Debian (6 was stable at the time) or with any repo that doesn't have a matching src repo.

edit: docs indicate it's still a problem http://www.ansibleworks.com/docs/modules.html/#apt-repositor...

I'm sorry, but even as fairly smart tech guy this page was not helpful to me. It didn't tell me anything useful about Ansible. I was left wondering ".... how the hell does it work? how do I use it?" and basically had to investigate their homepage to figure out why I should care. If it was a sales pitch to get me interested, it worked, but what the hell are sales pitches doing on HN?

I love ansible. Very straightforward to use--only problem is it's moving so fast I can't keep up. :) Good problem to have though.

It's also the first open source project I've committed code to. Huge fan. I use it to run a small 8 node openstack system, as well as deploy Apache VCL.

I agree ... Ansible is awesome.

I'm using a single set of playbooks for my infrastructure with Jenkins to check out changes and push them to production machines. The same infrastructure definitions are used with Vagrant to give each developer an exact copy of the production system.

anyone with both ansible and saltstack experience to compare ?

One unanswered question for me is how to manager packages on different systems. Apache for example has a different name on RPM vs apt based systems, or you might have a different command to go the install (arch vs ubuntu for example).

Can ansible do this? Can I easily migrate a playbook from using say apt-get to pacman?

I found Ansible quite tricky to use.

I was trying to set up https://github.com/pas256/ansible-ec2 to manage some EC2 instances and it seems like I needed to replace a static config file with a script? Wouldn't that prevent me doing anything that wasn't EC2 with that instance of Ansible?

Debian also moved the inventory files around in their package so that made things confusing.

I've been using Ansible in an EC2 environment and it's been fantastic. It's powerful enough, but its requirements are slight and you don't end up fussing with bootstrapping it into being. A server with Python (and a few little things that can be installed via Ansible/Python) will get you to a place where your instances are being populated.

I'm very curious about the breakdown of developers versus operations people who are in the middle of this love affair with Ansible.

> means minimal dependency on install (Python is shipped by default with Linux).

I love how the Ansible "Getting Started" guide [0] first says you need to install Puppet 2.6, as 2.4 on CentOS / RHEL is not supported :)

[0] http://ansibleworks.com/docs/gettingstarted.html

We really wanted to use Ansible but couldn't get it to work with virtualenvwrapper. Has anyone done this (easily)?

Is there any automated or semi-automated way to create an /etc/ansible/hosts file from a ssh config file? Not fully supporting the ssh config file is a real drag for me, I currently have several dozen hosts configured and I just don't want to retype everything for ansible to work.

We use this over at useartisan.com and though I'm not one of the Dev ops oriented people here everyone who is using it seems to be really psyched on it. Glad people are contributing and it's gaining steam!

undefined

Not ruby therefore instant awesome. Man! I really don't like ruby.

My run-in with Ansible was that it was incredibly slow. What took puppet 1 minute to do took Ansible 7 minutes. Not great for pushing changes. Sure, it could probably use some tuning, but then we're out of the realm of 'just works' and into 'chasing down -foo-'. It certainly looks like it has its use-cases though.