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

There’s a lot of buzz about the cloud in the IT industry today. One of the biggest questions I’m often asked is what exactly is the “cloud”? The definition is much simpler than one would think; the cloud is merely the Internet.  The reality is any application or service that is delivered to you via the web is, in essence, a cloud-based service. Pretty simple and not exactly unique! The truth is we have been using the cloud since the inception of the Internet.

I would argue that websites could be considered the first cloud application since without the Internet the sites could not exist. This was soon followed by e-mail and instant messaging services that even the most technophobic people have been using for nearly a decade.

So what’s different today? The biggest thing is that bandwidth has become more readily available, reliable, and cheaper than it was as recently as three years ago. Additionally, many people become more reliant on their cell phone as their primary medium for communication and carry web-enabled devices. These factors have changed the mindset of the application developers who now focus on developing programs that can be accessed via the web from any device that’s connected to the Internet. The expectation of people today is that they can access their data and communicate with others anywhere, anytime. 

So how does this translate to business use? Companies have been leveraging the cloud for quite some time, utilizing applications like Microsoft’s Terminal Server or Citrix XenApp (formerly Presentation) server. These allow companies to leverage the web for remote access to company information, no VPN required.

Another great example of a cloud delivered application is Salesforce.com. This application provides clients with customer relationship management (CRM) services via a public web address and secure login. This application stores and makes accessible a company’s most valuable asset, their customer data, yet no part of the solution resides at the client site. Salesforce.com’s success and track record has helped gain customers confidence in embracing cloud delivered applications.

At Fandotech one service we deliver via the cloud is our Boomerang Offsite backup service. Boomerang automates the backup at our clients’ sites, secures all data for transmission to our data center, and eliminates the need for clients to take tapes offsite.

So is Fandotech a “cloud” company? The definition above allows me to safely say Fandotech has been a “cloud” company for years. We’ve been providing hosted websites, e-mail services, and data center infrastructure for nearly a decade. Newer services have been introduced over the last year (Boomerang Recovery Solutions, 360ITv) responding to customers’ needs for business continuity, disaster recovery, and outsourced infrastructure. Also, customers calling into our technical assistance center (TAC) have received support delivered via the cloud as our technician’s reach into your network environment from afar to assist.

This is an exciting time for businesses as the cloud offers potential to reduce costs for hardware, applications, and support. And you can confidently move forward knowing that Fandotech has been a long-term player in cloud delivered services and is continuing to broaden our scope of services provided via the Internet. 

Brian Doyle