Book Review: Puppet 3 Beginner's Guide

sagecreek writes "If you are in charge of a small network with just a few servers, you may still be doing configuration management primarily by hand. And you may take particular pride in maintaining that 'artisan' role. After all, it's mostly up to you to set up new users and their machines, fix current problems, manage the servers and their software, create databases and their user accounts, and try to keep the network and user configurations as uniform as possible despite running several different brands--and vintages--of hardware and software. However, warns infrastructure consultant John Arundel, '[b]eyond 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.' In his new book, Puppet 3 Beginner's Guide, Arundel emphasizes: 'Manual configuration management is tedious and repetitive, it's error-prone, and it doesn't scale well. Puppet is a tool for automating this process.'" Read below for the rest of sagecreek's review. Puppet 3 Beginner's Guide author John Arundel pages 184 publisher Packt Publishing rating 8 out of 10 reviewer sagecreek ISBN 978-1-78216-124-0 summary Learn how to fully utilize Puppet through simple, practical examples Actually, among "UNIX-like systems," there are at least three major configuration management (CM) packages — Puppet, Chef, and CFEngine — plus some other competitors, Arundel notes. He calls them "all great solutions to the CM problem...it's not very important which one you choose as long as you choose one." But he hopes, of course, you will check out Puppet and his new, well-written how-to book.

Puppet 3 Beginner's Guide is structured to help system administrators "start from scratch...and learn how to fully utilize Puppet through simple, practical examples."

Arundel's book places important emphasis on the rapidly closing "divide between 'devs,' who wrangle code, and 'ops,' who wrangle configurations. Traditionally, the skills sets of the two groups haven't overlapped much," he notes. "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."

Today, he points out, system admins are "facing the challenge of scaling systems to enormous size for the web, [and] have had to get smart about programming and automation." Meanwhile, "[d]evelopers, 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."

Therefore, "[t]he term 'devops' has begun to be used to describe the growing overlap between these skill sets," Arundel emphasizes. "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."

Arundel's 184-page Puppet 3 Beginner's Guide has 10 chapters that are smoothly structured with numerous headings, subheadings, short paragraphs, code examples, and other illustrations. He has generated his code examples using the Ubuntu 12.04 LTS "Precise" distribution of Linux. But he explains how to load the software using "Red Hat Linux, CentOS, or another Linux distribution that uses the Yum package system," as well.

Chapter 1, "Introduction to Puppet," explains the software's basic architecture and shows how Puppet deals with large-scale configuration management problems.

In Chapter 2, "First Steps with Puppet," the author details how to install Puppet, create a simple manifest, and apply it to a machine. He also offers some basic Puppet language examples.

Chapter 3, "Packages, Files, and Services," focuses on "how to use these key resource types...and how they work together" and presents "a complete and useful example based on the Nginx web server."

In Chapter 4, "Managing Puppet with Git," Arundel shows "a simple and powerful way to connect machines together using Puppet, and to distribute your manifests and work on them together collaboratively using the version control system Git."

The emphasis in Chapter 5, "Managing Users," is on "good practices for user administration" and implementing them with Puppet. The chapter also covers "how to control access using SSH and manage user privileges using sudo."

The topics covered in Chapter 6, "Tasks and Templates," include using "Puppet's resource types to run commands, schedule regular tasks, and distribute large trees of files." Also covered: "how to insert values dynamically into files using templates."

In Chapter 7, "Definitions and Classes," Arundel explains "how to organize Puppet code into reusable modules and objects. We'll see how to create definitions and classes, and how to pass parameters to them."

Chapter 8, "Expressions and Logic," dives deeper into Puppet code. It "shows how to control flow using conditional statements and logical expressions, and how to build arithmetic and string expressions. It also covers operators, arrays, and hashes."

Chapter 9, "Reporting and Troubleshooting," deals with what the author terms "the practical side of working with Puppet," including diagnosing and solving common problems, debugging the software's operations, and understanding Puppet's error messages.

The final section, Chapter 10, "Moving on Up," wraps up with a range of topics, including how to make Puppet code "more elegant, more readable, and more maintainable." Arundel also offers "links and suggestions for further reading." And he describes nine projects to help you "improve your skills and your infrastructure at the same time." The projects, he says, "provide a series of stepping-stones from your first use of Puppet to a completely automated environment."

Puppet's maker, Puppet Labs, offers some virtual-machine options for learning the software. The choices are: (1) a VXM version recommended for VMware Fusion and VMware Workstation; and (2) an OVF version recommended for VirtualBox "and all other non-VMware virtualization software." Puppet Labs also offers a Puppet Enterprise version of its software that supports up to 10 nodes free.

Along with Linux, Puppet will run on other several platforms, including Windows and Macs,, but you will find little help for those in Arundel's book. You will need to use Puppet Lab's online Mac or Windows documentation. And Windows may not be the greatest of choices. As the documentation notes: "Windows nodes can't act as puppet masters or certificate authorities, and most of the ancillary Puppet subcommands aren't supported on Windows."

It can take a bit of work to get Puppet installed and configured. But once you have it running in a Linux environment, John Arundel's new book can be a solid guide to helping you become both a proficient Puppet user and a more efficient, knowledgeable, and versatile system administrator.

You can purchase Puppet 3 Beginner's Guide from amazon.com. Slashdot welcomes readers' book reviews (sci-fi included) -- to see your own review here, read the book review guidelines, then visit the submission page.

Comments

Poor review

[Score Whore]

That was a pretty poor review. Giving a summary of the table of contents isn't a review. Additionally it doesn't seem like they recognize that devops and duplicative administration don't fit with a lot of data processing models. There are many organizations that have servers that have a distinct purpose and it doesn't make sense to envision them as just another clone system in "the cloud".

Re:Poor review

[Karzz1]

Judging from account activity, I believe the submitter is a paid slashvertiser.

Re:Poor review

[steveb3210]

There is pretty much nothing you can do by hand that puppet can't also do - and often it takes just as much time to update a single puppet config file and run the puppet update process as it would be to ssh into the server and make the manual change.

Another advantage is what might go into traditional documentation is now just a puppet configuration.. Oh, fuck, this server crashed? Just roll another in 5 minutes... Who cares about the old one..

And this is the flaw in your argument. There seems to be some assumption that if it's not under control of Puppet or Chef then it's manual. This is completely untrue. Any competent admin automates their administration. I've been doing it for more than a decade.

Second it's not the host OS and host configuration that makes the servers distinct. It's the data. You can't automate ten years worth of data entry and workflow modules. I suppose it would be unfair of me to hold against you the fact that you don't know anything about my operations, but we're not an internet based company. We're doing stuff other than serving up a bunch of vanity gopro videos. We have several large data centers but we also have hundreds of offices around the world and those offices have their own IT infrastructure. Anyone can stand up a server in 10 minutes in their data center. How long will it take you to stand one up Chengdu given that your primary data centers are in the US and Europe and your network line to the remote facility is 512Kb/s?

The absurdity of the proponents of CFengine, Puppet, Chef, et. al. is that they assume no one has ever solved these problems before. What problems that I have are these products going to solve for me? The emphasis is on "problems that I have". It's not sufficient to tell me what a product does, it's whether it solves my problems.

You are right, there is nothing you can do with puppet that you can't do with SSH, and 10 years ago things like puppet didn't even exist so it makes total sense for you to be in the situation you're in and it wouldn't make alot of sense for you to switch just for the sake of using puppet.

But it's 2013, if you're starting off new - why would you roll your own when many solutions already exist that have been thoroughly tested and extended to have a rich feature set that you probally wouldn't have time to develop as a day-to-day dev op. Furthermore, Puppet allows for this idea of modules that people can write generic versions of "apache" or whatever and often times you don't even have to write configuration systems yourself but instead you can just clone it off github and customize it to your liking..

Your question about standing up servers is silly - why would a more manual solution be impacted differently than a puppet solution based on in-bound bandwidth? Puppet allows for client/server architecture and if bandwidth was your big concern, you could set up a local puppet machine in Chengdu and build servers in that data center based on that...

I worked in a largeish datacenter in 2002 and wrote alot of SSH scripts to manage those servers - it works but its tedious. The benefits of using something like puppet is enormous.. The company I work for now used to employ a full time sysadmin - now the devs just update puppet as we need and it hardly impacts our workloads given how easy it is for us to maintain...

This isn't a book review...

[Midnight_Falcon]

This is a slashvertisement..first tells you why you want to learn Puppet and what it's used for, and then gets you to read a book to time invest in learning Puppet which will become your "goto" for all DevOps stuff going forward. The hope being that -- some point, you end up looking into Puppet Enterprise and get out of open source..or you get to the level where you need enterprise and not the open source version, yadda yadda, more people on puppet, the better for their business model, as eventually some will have to go with enterprise for some type of requirement (additional functionality and/or enterprisey support)

As Always

[Bigbutt]

It requires some agent to be installed on a target server which communicates back to the Puppet Master. It's the same problem I have with other such tools that have agents. Infosec doesn't permit such holes in the various firewalls (I have servers in many locations). So I fall back to what I always do. I write scripts that run on the host gathering data, retrieve the data nightly, and can push changes out on the fly or with a nightly scheduled action.

It's a hell of a way to manage around 1,000 unix servers, but it's the easiest way to get the info I need to manage not just production but lab systems as well.

I'll finish downloading the docs and reading up on it out of curiosity but I don't see this going anywhere for us.

[John]

Re:As Always

[Anonymous Coward]

SSH in, run puppet apply, done.

Re:As Always

[kcbnac]

For situations where the agents can't talk back to the Puppet Master, you can push out the manifests (config files) to each host and apply them directly, locally. (As if it were a single, standalone machine)

Not sure if there is a way to push the results back to a Puppet Master for aggregation, but there may be a way to tackle that. (Or just back to a central logging server for parsing)

Re:As Always

[Anonymous Coward]

Check out Ansible. Ansible does it all through SSH, and doesn't require an agent. It's also much easier to learn and use than the mess called Puppet.

Re:As Always

[xaoslaad]

reports can be sent via http. Use foreman if you want a pretty interface, run passenger, choose any port you want.

For that matter do the same with puppet. You can run it on port 80 or 443 using passenger. You'll just have to customize your client config to use the same... so I don't really know why this is any sort of big deal for you.

Anyway, with foreman you can easily see if systems are out of sync, if they're erroring, etc. Might be a little unusual to do it running the way described in the previous post, but should be manageable if you really really really can't get it to work through the existing firewall configs. I've heard of people doing it when they've hit walls scaling as well. And foreman can do a lot more, though it doesn't have to. We started out using it just for the reports portion and facts searching...

Re:As Always

[silas_moeckel]

Puppet has no agents on ports either the agent grabs the config file every x amount of time and uses pre shared crypto keys to cross validate. If your sending data up from your servers for centralized processing that's probably not something puppet or any other config management bit does.

Cheaper Direct from the Publisher, and no DRM

[kcbnac]

http://www.packtpub.com/puppet-3-beginners-guide/book

(Currently) $23 USD for the eBook, and $45 USD for the Print + eBook access, and no Amazon-Kindle-DRM. (But you can still get it in a .mobi format for your Kindle, in addition to ePub and PDF)

The run masterlessly

[FreeUser]

It requires some agent to be installed on a target server which communicates back to the Puppet Master.

You can run puppet in masterless mode, against a local copy of the manifests, either managed locally or checked out from a version control repository.

Likewise with salt (my preferred choice over puppet, but both work), you can run either with a master host, or masterlessly. With salt the nice thing is, you can use the same config for both, just invoke the command differently (salt-call --local vs salt).

Infosec is no reason not to automate, just don't automate with a master server if your policies don't permit it.

Re: Balderdash

[turbidostato]

It is overkill for you but, if your boss has any professional acumen (I know, most don't) it wouldn't be overkill for him. A commonly understated value of automated configuration management is that it allows the company to own the knowledge it paid to acquire instead of letting it live only in some employee's memories.