4 ms·

I really like Ansible as a quick and accessible automation tool. It is always so low overhead to get going due to being agentless and using YAML. As I've got mo

I really like Ansible as a quick and accessible automation tool. It is always so low overhead to get going due to being agentless and using YAML. As I've got more experience with config management though, I find myself enjoying other philosophies like Puppet and Chef more. I think once scale gets large, having a consistent execution environment (via an agent) and more expressive language (like Ruby or Puppet DSC over YAML) outweighs the benefits of accessibility Ansible provides. When I want to get something done quickly and easily though, it's the first thing I reach for.

mkesper 6y ago
Well, in theory, chef is great. 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/ https://docs.chef.io/versions/
- gscho 6y ago
  > Also have a look at community cookbooks, most stuff is very old. 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/ https://cinc.sh/
evgen 6y ago
This is purely a matter of opinion, but in my experience once scale gets large enough where something like Chef or Puppet looks more appealing you really should be looking at containers/pods. It seems to me that Ansible is hitting the right niche between being simple enough to massage the base image for your fleet of docker/kubernetes engines and still works well at a bit of pre and post work for building the containers themselves. It is definitely possible for a good Puppet or Chef system to scale up and handle the whole stack from top to bottom, but I sincerely think that the moment is passing both of those technologies by and the agentless nature of Ansible, its simplicity, and the fact that it leverages Python instead of Ruby is pushing Ansible forward and eclipsing tools that would have been considered competitors five years ago...
- cpitman 6y ago
  This rings true. Systems I manage have gone from using fairly complex configuration management scripts that stand up the full stack, to using really basic scripts that create systemd units to run containers.
hackbinary 6y ago
Ansible was designed to be agnostic in this regard. Most Ansible plugins in the unix world are written in sh or Python, and in the Windows world in PowerShell. But you can use anything you want. 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.
nmaludy 6y ago
I do agree that Ansible is quite easy to start with, YAML being a fairly simply syntax to understand if you've never coded before. 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 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.
- frenchtoastto 6y ago
  Not sure what does you're using in puppet forge but everyone of the modules I've used are no longer being maintained as the develops have all switched to ansible and left the puppet modules to rot. While ill agree there is a learning curve to ansible for advanced things like loops and conditionals, you have everything a scripting language does.
fnord123 6y ago
Do you use some tooling to make it work efficiently? Every time I use ansible I'm stuck in the mud for days.
cpitman 6y ago
The important difference between them is not the syntax they are written in, it is their model for how to configure systems. 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.
ldite 6y ago
I keep trying to get started with puppet/chef, but their homepages are so buried in mounds of enterprise products that it's incredibly hard to figure out how to get started. 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.
- slezyr 6y ago
  I've checked chef/puppet/salt/ansible and all of them full of "contact sales", "request information". I've never seen that much noise on other projects.

mkesper 6y ago

Well, in theory, chef is great. 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/ https://docs.chef.io/versions/

gscho 6y ago
> Also have a look at community cookbooks, most stuff is very old. 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/ https://cinc.sh/

evgen 6y ago

This is purely a matter of opinion, but in my experience once scale gets large enough where something like Chef or Puppet looks more appealing you really should be looking at containers/pods. It seems to me that Ansible is hitting the right niche between being simple enough to massage the base image for your fleet of docker/kubernetes engines and still works well at a bit of pre and post work for building the containers themselves. It is definitely possible for a good Puppet or Chef system to scale up and handle the whole stack from top to bottom, but I sincerely think that the moment is passing both of those technologies by and the agentless nature of Ansible, its simplicity, and the fact that it leverages Python instead of Ruby is pushing Ansible forward and eclipsing tools that would have been considered competitors five years ago...

cpitman 6y ago
This rings true. Systems I manage have gone from using fairly complex configuration management scripts that stand up the full stack, to using really basic scripts that create systemd units to run containers.

hackbinary 6y ago

Ansible was designed to be agnostic in this regard. Most Ansible plugins in the unix world are written in sh or Python, and in the Windows world in PowerShell. But you can use anything you want. 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.

nmaludy 6y ago

I do agree that Ansible is quite easy to start with, YAML being a fairly simply syntax to understand if you've never coded before. 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 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.

frenchtoastto 6y ago
Not sure what does you're using in puppet forge but everyone of the modules I've used are no longer being maintained as the develops have all switched to ansible and left the puppet modules to rot. While ill agree there is a learning curve to ansible for advanced things like loops and conditionals, you have everything a scripting language does.

fnord123 6y ago

Do you use some tooling to make it work efficiently? Every time I use ansible I'm stuck in the mud for days.

cpitman 6y ago

The important difference between them is not the syntax they are written in, it is their model for how to configure systems. 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.

ldite 6y ago

I keep trying to get started with puppet/chef, but their homepages are so buried in mounds of enterprise products that it's incredibly hard to figure out how to get started. 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.

slezyr 6y ago
I've checked chef/puppet/salt/ansible and all of them full of "contact sales", "request information". I've never seen that much noise on other projects.