Why chef, puppet, ansible, salt, etc.?

Question

The devops tools ecosystem is puzzling to me. Instead of shell scripts that work everywhere everyone in the server orchestration/management space is bolting on their own proprietary formats. Ansible has their YAML playbooks, Puppet has its class/graph language, salt like ansible has some kind of YAML format, chef is an embedded Ruby DSL. Out of all of these approaches I like chef the best because it does the simplest possible thing. So I guess one benefit is better visibility into the fleet when you use one of these tools but that's orthogonal to the actual configuration and provisioning component.

I don't quite get why everyone is trying to re-invent shell scripts with YAML because more often than not ssh -t is all I need to get things done along with a library of some shell scripts. These scripts are usually packaged as self-contained tar files and are small and simple enough to be mixed and matched as necessary. They have zero dependencies other than bash and will pretty much just work anywhere. So why is it then that a simple solution like that is not good enough for ansible, puppet, chef, etc.? What do all these solutions gain by replacing bash scripts with some other format?

There are many well documented benefits. Have you done some research on the reasons why configuration management exists? — Drew Khoury, Mar 13 '14 at 07:31
If you indeed live in a world where you have `shell scripts that work everywhere` then surely you don't need configuration management. The rest of the world doesn't live in that paradise, though. — Sven, Mar 13 '14 at 07:33
Scripts are not configuration? Configuration defines what the world should look like, scripts define some change to the world. How long would it take you to use your scripts to update a config file on 1000 servers? How do you make sure every server got the change properly? (What if it was down for maintenance when you ran your scripts?) — David, Mar 13 '14 at 07:51
@David: Not very long at all. Fork a bunch of `ssh -t` and collect exit codes. Done. — , Mar 13 '14 at 07:55
@DrewKhoury: The same benefits apply to well-written shell scripts and then some because you don't introduce another dependency in your infrastructure. — , Mar 13 '14 at 07:56
@David: So a YAML playbook does not describe state changes? Then why do you have it if it is not going to change the state of the server? Well written shell scripts can be just as idempotent and declarative as playbooks, recipes, modules, etc. — , Mar 13 '14 at 07:58
@davidk01: they describe the *final* desired state. A modern configuration manager requires very few lines to say 'sudo make me a sandwich'. Writing your own shell script you typically need to say 'sudo take slice of bread and put meat on top. Sudo add lettuce, sudo add mayo..' only to find out you need to come up with a new sandwich recipe because the next release no longer carries the toppings you've always had. They simply allow you to spend more time on whatever else you'd rather be doing. For most operations there is underlying code that accounts for variations in distros, oses, etc. — , Mar 13 '14 at 08:38

score 7 · Answer 1 · answered Mar 13 '14 at 10:14

There are plenty of good reasons to use configuration management software. While there are many different tools, I'll focus on a few of the features of Puppet (the main concepts are largely the same).

Note: While you could argue that writing your own scripts could achieve the same results, presumably you'd have to write and maintain a large codebase to achieve the same tasks.

Declarative

As a declarative, model-based approach to IT automation, it lets you define the desired state - or the “what” - of your infrastructure using the Puppet configuration language.

Enforcing desired state

Once these configurations are deployed, Puppet automatically installs the necessary packages and starts the related services, and then regularly enforces the desired state.

A framework for automating the mundane

In automating the mundane, Puppet frees you to work on more challenging projects with higher business impact.

An example, installing a package

You can do all sorts of interesting things like install packages (on a large variety of operating systems), or ensure only particular versions of a package are installed.

package { "screen":
    ensure => "installed"
}

The above code ensures that the package 'screen' is installed, and this will work on Debian (which uses apt) or Redhat (which uses yum). You don't need to maintain your own scripts or logic for each package management system, Puppet does that for you.

And there's more

There are plenty of other benefits around templating, facts, mcollective, roles, GUIs, event inspectors, dry-runs, support, & puppetforge.