Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

This question already has an answer here:

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?

share|improve this question

marked as duplicate by voretaq7 Mar 14 at 19:24

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

There are many well documented benefits. Have you done some research on the reasons why configuration management exists? –  Drew Khoury Mar 13 at 7: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 at 7: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 at 7:51
@David: Not very long at all. Fork a bunch of ssh -t and collect exit codes. Done. –  davidk01 Mar 13 at 7:55
@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. –  yoonix Mar 13 at 8:38

1 Answer 1

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.


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.

share|improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.