[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.