When I want to get something done quickly and easily though, it's the first thing I reach for.
When I want to get something done quickly and easily though, it's the first thing I reach for.
Ansible is imperative. You give it a list of things to do, and it will do each one, in order, whatever you say.
Puppet is declarative. It runs through your entire script to build a model of how things should be, compares the target system to see how things are different, then uses a combination of implicit and explicit dependencies to order changes and apply them to the machine. Because it is building a model, it is able to detect defects like two different modules trying to configure the same thing two different ways.
The declarative models make it so that doing the right thing is easier then doing the wrong thing (ie, making idempotent configuration is easier then exec'ing out). But the imperative model makes doing everything easier (ie, it doesn't guide me to make idempotent scripts, but makes it super easy to automate any old task list).
That is what makes Ansible easier to adopt, the very low level of mental overhead to understand what it is doing. Conversely, it probably also makes it harder to scale, both because performance is basically single-threaded and synchronous and harder to enforce good standards.
PS I work for Red Hat, but have used both Puppet and Ansible extensively.
One of the things i struggle with most in regards to Ansible is that things that are semi-interesting like loops, conditionals, data munging, etc are quite complicated and cumbersome. I agree that things like Puppet and Chef make these tasks _much_ easier and i end up writing more understandable code that works just like any other scripting language.
I also _very_ much appreciate the fact that i can unit test my code in Puppet and Chef. As part of a good DevOps practice, unit testing along with integration/acceptance testing is crucial!
On top of that i believe that the roles in Ansible Galaxy are very much sub-par when compared to modules in Puppet Forge. Most of the modules in Ansible Galaxy are simply "install package, start the service". In general, Puppet Forge modules are much more in-depth and allow for configuration and customization to many aspects of the application you're configuring.
Also, check out Bolt from Puppet: https://puppet.com/docs/bolt/latest/bolt.html
Bolt is an "ad-hoc task runner" very much like Ansible. One of the cool things you can do with Bolt though is apply Puppet code as part of the run, so you can reuse all of the Puppet Forge modules that already exist.
Once I eventually figured out which of their indistinct products is actually the basic tool I then tried to follow their tutorials, which want me to install hundreds of megabytes of who knows what, set up heavyweight servers, watch video tutorials (!), and who knows what.
When I eventually slogged through all that to get to a minimally working setup trying to convert a few fairly trivial ansible plays for what I would have thought of as fairly standard stuff rapidly turned into "time to write some ruby"!
I gave up.
This is also part of Ansible's philosophy: to be agentless and as thin as possible.
Puppet and chef are significantly more complex, and historically required remote agents on the hosts they managed.
On the threads about Progress buying chef and VMware buying Saltstack, it was pretty clear that the sentiment of the community was that things have moved passed chef and puppet to Ansible and Terraform.
You can unit test your configuration (which in ansible isn't really practical due to its dynamic nature). You can get completion in your editor...
In practice, though, you write a lot more code and have to comprehend more. Also have a look at community cookbooks, most stuff is very old.
I think chef have totally killed their community by doing that stupid EULA move. https://docs.chef.io/versions/
A lot of the functionality offered by community cookbooks made it way into the core DSL. Most community cookbooks for installing applications were abandoned for other approaches though.
>I think chef have totally killed their community by doing that stupid EULA move.
I agree. Seems like they tried to move to the "redhat model" without having a centos style OSS version. CINC has come along and filled that gap: https://cinc.sh/