A domain-specific language makes a big difference in the amount of code you write. For example, you could argue that there’s not much difference between:

chmod 640 /my/file

and

file { "/my/file":
    mode => 640,
}

but there’s a great deal of difference between these:

FILE=/my/file
chmod 640 $FILE
chown foo $FILE
chgrp bar $FILE
wget -O $FILE "http://my.puppet.server/dist/$FILE"
     # where the URL contains "Hello world"

and

file { "/my/file":
    mode => 640,
    owner => foo,
    group => bar,
    content => "Hello world",
}

What happens if the wget fails? How will your script handle that? And what happens if there’s something after that in your script that requires $FILE to be there with the correct contents?

You might argue that one could just put echo "Hello world" > $FILE in the script, except that in the first example the script must be run on the client, whereas puppet compiles all of this on the server. So if you change the content, you only have to change it on the server and it changes it for as many systems as you want to put it on. And puppet handles dependencies and transfer problems for you automatically.

There’s just no comparison – proper configuration management tools save you time and complexity. The more you try to do, the more shell scripts seem inadequate, and the more effort you will save by doing it with puppet.

Paul Gear

You’ve answered your own question…

Automation is becoming more scalable and formalized. Puppet and Chef are considered standards these days (check the job ads).

Cobbled-together shell scripts have their place, but they’re not scalable in the context of the DevOps movement. Readability is part of that.

ewwhite

This will be an unpopular opinion, but configuration management systems are not necessarily better. Sometimes simple really is best.

There is a definite learning curve and administrative overhead associated with the configuration system you choose. You are after all introducing a dependency. As with any automation you must also be careful that security is maintained in deployed configurations.

I’ve only had a couple of instances where we deployed configuration management and it stuck. It was always when there were a large number of systems with repetitive configuration and a need to perform configurable cookie-cutter deployments.

radium

If servers are disposable to you, or you have cause to stand up more than a couple at a time, a full-blown CM system will much better meet your needs than a series of shell scripts.

If your build needs are modest, (or like to artisanally hand-craft organic free-range fair-trade servers), then keep it simple.

Personally, having used Chef extensively at a past gig, I attempted to ‘keep it simple’ at this gig, but I really missed the primitives, abstractions, and power that Chef provided. Even if you get to a situation where you could get what you need from a couple shell commands, you can simply run those with a ‘command’ block, entering your shell commands exactly as you would write them in shell.

With that said, you can run Chef without a server (chef-solo), and I’m pretty sure that Puppet has an analogue, where you can still leverage others’ cookbooks and recipes without running a central server.

Another benefit is the community: there are a lot of people (many of which will be smarter and/or more experienced than you). Personally I love it when someone else has done my work for me, often more extensively than I would have.

gWaldo

Modern configuration management tools such as Puppet and Chef allow you to define the state of a system instead of worrying about activities necessary to achieve a configured server.

For example, your chmod command assumes that the file exists, the user owning the file exists, that the directories have been created, and so on. Your script therefore must consider all of these prerequisites.

State-based configuration management tools are simpler: you just care that the file has the correct permissions. How that is achieved is the tool’s problem.

Jon Jaroker

Chef makes it a lot easier to manage and version the setup of a complex infrastructure, especially in any type of cloud environment vs. having to manually ftp or scp a bunch of shell scripts organized in a unstandardized fashion. Depending on how many dependencies you need to manage, the size of this win can vary greatly, making the decision to move to a CM solution a non-obvious one for a lot of people.

The real (often unsung) benefit of Chef is idempotence. Being able to be certain of a resource’s state regardless of the combination of recipes run with overlapping interests is a huge benefit over shell script configuration. If you have shell scripts for configuration now, ask yourself how many of them can be run multiple times without unintended/undesirable consequences?

A proper CM solution helps to ensure success at scale by simplifying cross-platform automation and team collaboration. While it is possible to accomplish all this with a well organized, properly maintained, versioned group of shell scripts; you’ve got to ask yourself “why”. Chef/Puppet and similar technologies came about because a group of talented SysOps were tired of having to solve these same problems over and over again and set out to give us a better option.

Key pieces:

• Idempotence
• Ease of Dependency Management (versioning)
• Standardized Organization (accepted at an industry level)
• Abstraction to separate server configuration tasks from system level details
• Ability to leverage community knowledge (that is guaranteed to embrace all the above principles)

Matt Surabian