Once we start writing programs to configure machines, we get some benefits right away. We can adopt the tools and techniques that regular programmers—who write code in Ruby or Java, for example—have used for years:
Powerful editing and refactoring tools
Version control
Tests
Pair programming
Code reviews
This can make us more agile and flexible as system administrators, able to deal with fast-changing requirements and deliver things quickly to the business. We can also produce higher-quality, more reliable work.
Some of the benefits are more subtle, organizational, and psychological. There is often a divide between "devs", who wrangle code, and "ops", who wrangle configuration. Traditionally, the skill sets of the two groups haven't overlapped much. It was common until recently for system administrators not to write complex programs, and for developers to have little or no experience of building and managing servers.
That's changing fast. System administrators, facing the challenge of scaling systems to enormous size for the web, have had to get smart about programming and automation. Developers, who now often build applications, services, and businesses by themselves, couldn't do what they do without knowing how to set up and fix servers.
The term "devops" has begun to be used to describe the growing overlap between these skill sets. It can mean sysadmins who happily turn their hand to writing code when needed, or developers who don't fear the command line, or it can simply mean the people for whom the distinction is no longer useful.
Devops write code, herd servers, build apps, scale systems, analyze outages, and fix bugs. With the advent of CM systems, devs and ops are now all just people who work with code.
Being a sysadmin, in the traditional sense, is not usually a very exciting job. Instead of getting to apply your experience and ingenuity to make things better, faster, and more reliable, you spend a lot of time just fixing problems, and making manual configuration changes that could really be done by a machine. The following carefully-researched diagram shows how traditional system administration compares to some other jobs in both excitement and stress levels:
We can see from this that manual sysadmin work is both more stressful and more boring than we would like. Boring, because you're not really using your brain, and stressful, because things keep going wrong despite your best efforts.
Automating at least some of the dull manual work can make sysadmin work more exciting, because it frees you for things that are more important and challenging, such as figuring out how to make your systems more resilient or more performant.
Having an automated infrastructure means your servers are consistent, up to date, and well-documented, so it can also make your job a little less stressful. Or, at any rate, it can give you the freedom to be stressed about more interesting things.
So how do you do system administration with Puppet? Well, it turns out, not too differently from the way you already do it. But because Puppet handles the low-level details of creating users, installing packages, and so on, you're now free to think about your configuration at a slightly higher level.
Let's look at an example sysadmin task and see how it's handled the traditional way and then the Puppet way.
A new developer has joined the organization. She needs a user account on all the servers. The traditional approach will be as follows:
Log in to server 1.
Run the
useradd rachelcommand to create the new user.Create Rachel's home directory.
Log in to server 2 and repeat these steps.
Log in to server 3 and repeat these steps.
Log in to server 4 and repeat these steps.
Log in to server 5 and repeat these steps.
The first three steps will be repeated for all the servers.
Here's what you might do to achieve the same result in a typical Puppet-powered infrastructure:
Add the following lines to your Puppet code:
user { 'rachel':
ensure => present,
}Puppet runs automatically a few minutes later on all your machines and picks up the change you made. It checks the list of users on the machine, and if Rachel isn't on the list, Puppet will take action. It detects what kind of operating system is present and knows what commands need to be run in that environment to add a user. After Puppet has completed its work, the list of users on the machine will match the ones in your Puppet code.
The key differences from the traditional, manual approach are as follows:
You only had to specify the steps to create a new user once, instead of doing them every time for each new user
You only had to add the user in one place, instead of on every machine in your infrastructure
You didn't have to worry about the OS-specific details of how to add users
It's not hard to see that, if you have more than a couple of servers, the Puppet way scales much better than the traditional way. Years ago, perhaps many companies would have had only one or two servers. Nowadays it's common for a single infrastructure to have tens or even hundreds of servers.
By the time you've got to, say, five servers, the Puppet advantage is obvious. Not counting the initial investment in setting up Puppet, you're getting things done five times faster. Your colleague doing things the traditional, hand-crafted way is still only on machine number 2 by the time you're heading home.
Above ten servers the traditional approach becomes almost unmanageable. You spend most of your time simply doing repetitive tasks over and over just to keep up with changes. To look at it in another, more commercial way, your firm needs ten sysadmins to get as much work done as one person with Puppet.
Beyond ten or so servers, there simply isn't a choice. You can't manage an infrastructure like this by hand. If you're using a cloud computing architecture, where servers are created and destroyed minute-by-minute in response to changing demand, the artisan approach to server crafting just won't work.