Ansible tends to be better for jobs you do when a sysadmin wants them done, its really good for scripting repeatable installations, or for doing updates in a consistent fashion on hundreds of machines, adding new users to a bunch of different applications, etc etc.
You can use puppet for ad-hoc jobs, but its not really designed for that it tends to be overly complicated and a bit awkward (imho). You can do drift re-mediation with ansible and run it every 30 mins to fix issues and it will work but its not its real sweet spot.
Personally I would use ansible for both use cases because its simpler, I understand it, and it has a more sysadmin way of thinking, but I know places that use both and that makes sense as well.
You may find Puppet obtuse if all you want is one time provisioning of new hosts. Sometimes you do care about procedural concerns like execution order, and in Puppet you have some influence (e.g. dependency relationships) but not direct control.
You may find Ansible backs you into corners with long lived mutable infrastructure. Configurations may drift, and your ability to run a playbook may depend on the sequence of playbooks previously run on the target. Ansible doesn’t really have a notion of converging on a goal state; it’s closer to scripting. You can have a single idempotent playbook that you run every time, but it’s not opinionated about that.
Plusses: - Supported Ansible modules are usually more reliable and more clearly defined in terms of how they'll function than community cookbooks for Chef are - Upgrades between versions go smoothly - People can just go read your YAML and figure out what it's going to do
Minuses: - It's not code, so if you want to do something more programmatic, you're going to end up with something ugly compared to what you can do in Chef/Puppet's Ruby DSL - It's still a bit immature in terms of comparison to Chef's server offering (Ansible Tower is pretty useless), and the Kitchen/Vagrant/Serverspec stuff is also not as advanced.
Ansible seems to fit well as a replacement for the Chef Zero use case of fire-and-forget provisioning - works well inside Packer or inside of Terraform via a null_resource, but I don't tend to find myself wanting to use it for long-lived machines that in the Chef world benefitted from continually running the cookbooks to help keep config in sync.
Meh, I really like Tower, but maybe that depends on what you're used to.
> It's not code, so if you want to do something more programmatic, you're going to end up with something ugly
this is true, ansibles DSL has its limits and the developers are pretty clear that there are some things that are too complicated for its yaml based syntax. 99% of use cases its great for, if you want that extra 1% then you have to write your own ansible modules (which is actually reasonably straightforward). I dont know chef but puppet has become more and more complicated over the years chasing the more advanced use cases and in many ways thats moved it away from a tool for sysadmins towards a being a tool for specialists so I think Ansibles outlook makes more sense. YMMV.
Yeah, I concur. There aren't too many cases where I can't work around the lack of programmability with some creative templates or what-have-you.
(I wonder if I could render an Ansible task file from a template and then include it...)
If you need code, you're encouraged to write your own module (pure Python, typically)
> Ansible Tower is pretty useless
Why?
Ansible is more like a readable bash on steroids. It's basically a way to distribute and execute Python code into other machines. Unless you have AWX (Tower), or create a custom repeatable delivery, it won't take care of config drift.
Overall, Ansible is much easier to write and understand. It's an extremely powerful tool. Puppet doesn't have any amazing advantages or disadvantages over Ansible (except of the simplicity, which is a large benefit for Ansible).