[dsr_]

If you already have a complete config management setup, you're already getting 85% of the benefit.

If you're choosing one, Chef and Puppet work by having an agent on each client contact a server and pull down whatever's designated for that client. Then they try to make the local client conform to that state. Ansible is a push system where your server goes out to each client and tells it what to do over SSH.

In the event of a server issue, a chef-controlled system will continue trying to be in the last state it downloaded. That is, if you make a manual changeto something that chef controls, expect it to be reverted shortly. An ansible-controlled system will diverge with every manual change, up until contact with the server is regained.

The major difference between Chef and Puppet is that Chef recipes are Ruby programs with supplementary libraries, while Puppet uses a DSL written in Ruby. If you already have some Ruby experience or coworkers who write in Ruby, Chef is probably a better choice for that alone.

If you don't know any Ruby at all, ansible configuration may be faster for you to pick up.

[dcosson]

FWIW, we've had a lot of success with a super simple pull version of ansible. You can configure ansible to run against a local host instead of via ssh push, so we have a cron on all servers that pulls the latest configs from S3, runs ansible, and reports any failures to cloudwatch metrics. This is a good fit in particular for configuring stable host OSes that don't change all that often, for something like deploying application code where you want to be able to run it right away instead of in ~30 minutes the next time the cron runs. If we really needed to push out a critical patch or something, we could also parallel ssh to the necessary servers and trigger a run immediately.

I believe Ansible Tower is their enterprise tool to do a similar pull-based model. I haven't used it but I've used a Puppetmaster setup in the past, and I'm really not a fan of how much of walled garden, standalone solution these things all are. They introduce coordination that you might not really need and have their own protocols for dealing with it, they have their own patterns for bootstrapping new servers, authentication to servers, encrypting secrets, tracking which servers are up or down, etc. and a lot of that is redundant with other tools you might be using (e.g., secret management or monitoring) and other primitives that the cloud provider likely has built in (like IAM profiles to solve the bootstrapping problem).

[quicksilver03]

What you've described is essentially Puppet in masterless mode.

One of the reasons why I prefer Puppet to Ansible is the speed: Ansible in push mode is incredibly slow, even after applying all of the recommended tuning options and configuring Mitogen. I haven't yet used Ansible in pull mode on a large scale infrastructure, but I'd love to know if it's faster.

[33degrees]

I'll add that while using Ruby makes certain things easier in Chef, overall Ansible is simpler and that's I've ended up preferring it despite my familiarity with Ruby.

[kakwa_]

I've played with Puppet, Ansible and SaltStack (never with Chef however).

The fact Ansible is agentless is somewhat of a downside IMHO.

We have a fairly large deployment, and our Ansible code is basically a glorified setup shell script. I would be afraid to rerun it on a running instance.

After the initial setup we basically maintain the servers by hand, with some additional one-off Ansible tasks in case of a fleet wide change (meaning duplication of effort: one for the one-off task, one to update the "setup script" for new instances).

The result is a somewhat unwieldy infrastructure that feels like we are managing pets, not cattle (the infrastructure has several thousands nodes), and the pets looking a lot like cats.

I know it's because we are using Ansible wrong, but at the same time, I feel that Ansible, without a master, kind of encourages this behavior, and it's likely very common to fall in this trap.

I may sound weird, but I prefer the Puppet DSL. I do acknowledge it has a bit stepper learning curve compared to Ansible (on top of a more complex setup with a slave, a master and some keys). But the DSL itself is not that hard to learn (IMHO, it's a bit easier to learn than a programming language). Also, it's far easier to structure a Puppet code base compared to an Ansible code base:

* You have general purpose module, often provided by the community, (like one managing apache, or postgres, or nginx).

* You can then create your own modules combining these community modules (for example, to have a module "my app server" which is a combination of the apache and tomcat module + a few resources to configure your in-house app)

* You can then compose these into full server roles

* You also have things like hiera which provides ways to factorize and structure configuration parameters across the infrastructure (to handle for example a dev, a stage, and a prod environment).

It's not trivial to structure your code properly, but all the bricks are there to do it.

With Ansible by comparison, you have to invent things yourself, and because it's far less directive, what easily ends-up happening is hard coded roles, with duplicated code as it's the path of least resistance.

Maybe I'm feeling a bit nostalgic because when I used Puppet for the first time (circa 2011/2012) it was kind of a revelation. I set it up to have our dev environment plugged on our SVN repository using trunk directly, and for the stage and prod, I just flipped a symlink on the master to point to the proper tag, I had also deployed the Puppet dashboard to have an overall view of the changes. It enabled us to very quickly iterate (compared to previous ways such as manually sshing and viming config files, or running a shell script) with an high degree of confidence regarding the consistency of the configuration, and everything was tracked properly has you had to commit to push a change. Fun memories, and one of the nicer projects I had the chance to work on.

[simonh]

Puppet agent setups have been painful fro us so we switched to Ansible. Our Unix Ops team are separate from our App Support team and both wanted to use puppet, but we had problems with conflicting puppet agents and conflicting agent versions. There are probably workarounds, but the App team decided to go with Ansible while Unix Ops stuck with Puppet.