Managed Services with Puppet

Because I work with a lot a of Windows guys, I tend to describe Puppet as Group Policy for Linux. The basic idea is to centralize your host and service configurations, so that you don’t have to waste time configuring the same things over and over again. Once you have a set of standard templates, you can simply apply them to the desired hosts and let Puppet do all the configuring for you. This article is not meant to be an in-depth Puppet tutorial (you can find that elsewhere), but more of a high-level overview of how to design a flexible Puppet infrastructure.

Zones and Roles

The first thing we did was organize our hosts and services into “zones” and “roles” (similar to the Example (42) Infrastructure Design Guidelines). A “zone” says something about where a particular host lives (e.g., which network it’s on or which customer it belongs to), while a “role” says something about what the host does (e.g., serves web pages, routes email messages, etc.). Note that Puppet has no built-in concept of zones and roles. This is just a method of organization that worked well for us.

Modules

Once our zones and roles were defined, we needed to create the “modules” that make up our various roles. A “module” is simply a way to group related configuration options together. For example, we have modules with names like “apache,” “bind,” “mysql,” and “postfix.” Each module contains the scripts and files needed to apply the appropriate configuration for a given service.

Module Example

Here is an example of a module that we use to manage the SSH service on some of our servers:

class openssh::server {
    package { "openssh":
        name   => "openssh-server",
        ensure => installed,
    }
    file { "sshd_config":
        path    => "/etc/ssh/sshd_config",
        owner   => "root",
        group   => "root",
        mode    => "600",
        source  => "puppet:///openssh/sshd_config",
        require => Package["openssh"],
    }
    service { "openssh":
        name      => "sshd",
        enable    => true,
        ensure    => running,
        hasstatus => true,
        require   => Package["openssh"],
        subscribe => File["sshd_config"],
    }
}

I don’t want to go into a lot of detail here, but you should notice three distinct sections in this module—”package,” “file,” and “service.” In Puppet lingo, these are called “resources,” and are the basic building blocks of every Puppet configuration. Puppet resources allow you to focus on what you want to do, and let Puppet handle the platform-specific details of how it gets done. In this example, we tell Puppet to do the following:

1. Use the package resource to ensure that the “openssh-server” package is installed.
2. Use the file resource to overwrite the sshd_config file with our modified version (making sure to set the proper permissions on the file).
3. Use the service resource to ensure that the “sshd” service is running.
   • If any changes are made to the sshd_config file, then restart the sshd service so that the new configuration takes effect.

Role Example

Now that you know what a module looks like, let’s look at how roles are built up from modules:

class role_default {
    include openssh::server
}
class role_lamp {
    include role_default
    include apache::ssl
    include apache::php
    include mysql::server
}

There are two roles here; role_default (the role we apply to all hosts) and role_lamp (for Linux/Apache/MySQL/PHP servers). Notice that our example openssh::server module is assigned to role_default, and role_lamp includes role_default, as well as three other modules. This demonstrates how complex roles can be built up from smaller roles.

Zone Example

At Fandotech, we typically use zones to set variables that override the default behavior of certain modules. In other words, a given module may configure things differently depending on what zone the target host is in. In this example, we set a variable to allow the “LinuxAdmins” group to log on to hosts that live in the zone_fandotech zone:

node zone_fandotech {
    $accessconf_rules = ["+ : LinuxAdmins : ALL"]
}

Node Example – Tying it all Together

Nodes are the individual hosts managed by Puppet, and are what tie everything together. Let’s look at one final example:

node default {
    include role_default
}
node 'example.fandotech.com' inherits zone_fandotech {
    include role_lamp
}

In this example, we have a special “default” node, which refers to any puppet-managed host that does not have explicit node configuration. We also have a node called “example.fandotech.com” which lives in the zone_fandotech zone and gets all the configuration options from the role_lamp role.

Conclusion

Puppet promotes efficiency by making it possible for a single administrator to configure hundreds (or possibly even thousands) of Linux machines without having to log on to a single one. It also helps ensure standards compliance, and if your Puppet configuration is stored in a source code repository (which it should be), then you have a built-in audit history of every change made to your systems.

The bottom line is that if you’re still trying to manage Linux machines without a configuration management system (like Puppet), then you’re doing it wrong.

Michael Conigliaro