Puppet: Make It So

Jean-Luc Picard

SVDevOps, June 12, 2012

Robert Harker

Sr. Service Engineer, Yahoo! Sports, harker@harker.com

This talk is extracted from "The Puppet Show, Managing Servers with Puppet"


(Up arrow, down arrow to move between slides)

This is a talk about Puppet


Robert Harker

Currently a Sr. Service Engineer at Yahoo! Sports

On a team of 4 SEs managing ~3,000 hosts

Heavily involved with Yahoo! Sports move to a DevOps team
and continuous integration with Jenkins
Working on migrating Yahoo! Sports to new hardware
into two consolidated data centers

Active in the OpenStack and cloud computing community


What Is Puppet

Puppet is a configuration management tool Written by Luke Kanies Supported by Puppet Labs (formerly Reductive Labs) Written in Ruby but Ruby skills not needed

Client/Server model: puppetmasterd is the central management daemon puppetd runs on each managed system (node)


Make It So

The goal of Puppet is to define the end state of the managed system (node)

This end state is defined by a set of related class data that build up a node specific manifest

Puppetd running on each node inspects itself with factor which defines:
OS, network interfaces, IP addresses, file systems, architecture, hostname

The node uploads this information to the puppetmaster


Make It So

The puppetmaster then uses the factor information to:
Define which resources (classes) need to be applied to the node Evaluate the resources to make it specific to a node Build up a node specific manifest and download it to the client

This may include files and templates that are available on the puppetmaster

The node then uses this manifest to compare its current configuration to the configuration defined in the manifest


Make It So

Any differences are logged and corrected:
Download a file Change owner or permissions Install or deinstall an application Enable or start a service
Because puppet strives to make the current state of the client be the same as the state defined in the manifest, puppetd can be run multiple times without corruption
Puppet is idempotent

Puppet Security Infrastructure

Puppetmasterd listens to port 8140 Puppet uses SSL for security The puppetmaster includes a SSL certificate server


Puppet Architecture

Puppet Language

Puppet decouples the syntax of the configuration management tool from the syntax of the underlying OS and applications
This is done with Puppets Resource Abstraction Layer (RAL)

The decoupling allows Puppet to define a high level idea like user, application, or service

The Puppet RAL will translate that in to the commands required by the client OS

Resources describe some aspect of a system Each resource has a type, a title, and a list of attributes


Puppet Is A Declarative Language

Resource Types - Each resource is modeled as a type Resources include services, packages, files, users, permissions, run state Resource Types are independent of the underlying OS semantics

Providers how to implement a resource Providers hide the underlying differences between OSes Providers for the type package include apt, yum, pkgadd

Resource providers actually perform the management functions


Puppet Language Structure

Puppet creates a graph based structure to define the relationships between resources: What resources depend on another What order the resources should be evaluated Whether a change in one resource requires an action by another resource I.e. restarting a service if a config file changes

Puppet has a tool to print out these dependency graphs


Pros and Cons of Puppet

Pros: Buzz in the Linux systems management community OpenSource Active development community New features and modules added weekly

Cons: Scalability Factor running on the client is expensive Manifest generation on the puppetmaster is expensive Many desirable features missing Dashboard is a commercial product Many systems administration tasks missing (still true?)


Some topics to think about are:


Differences in approaches between configuration management systems?

How much configuration management?

OS apps only, host configuration, custom applications, bare metal restores?

Integration with Continuous Integration (CI) systems?

Production only or the whole tool chain?

Devel integration -> QA -> staging -> production

Automatically pull the changes or manual push of changes?

Integration with other systems?

Tips or techniques which have lead to success.

Problems you have encountered.