EXAMPLE 42 PUPPET INFRASTRUCTURE EXAMPLES¶ ↑

Example42 is a set of Puppet Modules that provides an integrated and coherent Puppet setup to manage many common applications.

Each module contains at least one class having its same name, which can be used by nodes.

Official site is www.example42.com

Git repositories are on GitHub: github.com/example42

Currently (02/2012) the module set is composed of 2 generation of modules:

• “Old”, 1.0 modules, that generally are supposed to work for Puppet 0.24 and later and will not be compatible with Puppet Etch/2.8

• “NextGen”, 2.0 modules, that are compatible only with Puppet versions 2.6 and later (Etch included) and feature better reusability and testing

The intention is to move the whole module set to NextGen modules by the end of 2012.

Installation of Modules¶ ↑

You can retrieve the Example42 modules Version 1.0 with:

git clone --recursive -b 1.0 git://github.com/example42/puppet-modules.git

You can get the current module set, which is in a transition phase with both 1.0 and NextGen modules with:

git clone --recursive git://github.com/example42/puppet-modules.git

Update¶ ↑

When you want to update the modules with the upstream version (don’t do this directly in a production environment!) remember that also the submodules have to be updated:

cd /etc/puppet/modules # Or the dir where you have your local git repo
git pull origin master
git submodule init
git submodule update

If you want to get the very latest version of each submodule, even the ones not tracked on the main repo:

git submodule foreach git pull origin master

The above commands (excluded the first cd and included the last) are done by the script:

Example42-tools/sync.sh

General note on Puppet nodes¶ ↑

You have at least two ways to define nodes in Puppet:

• Via Puppet manifests, using the “node” definitions and the resources declared in /etc/manifests/site.pp or in files imported from there.

• Via an External Node Classifier (ENC), such as Dashboard, Puppet Enterprise Console or Foreman or whatever custom source, where you may have a GUI that helps in setting nodes and their variables.

The general logic is that for each node you may have to set variables (eventually using different methods) and include or call classes that make use of these variables. You can eventually decide to set all your variables using and external datastore, such as Hiera or Extlookup.

If you choose the approach based on site.pp, (which is the default when you install Puppet) you can find here some sample infrastructure layouts.

Example42 sample infrastructures¶ ↑

This repository contains some sample layouts of nodes organization in Puppet ( what is placed in /etc/puppet/manifests when you don’t use an ENC ).

The samples have followed Puppet’s evolution and what we considered a good approach in the past (setting and overriding variables using nodes’ inheritance) is no longer possible in Puppet 3.0.

For this reason you might explore, in different branches, different alternative infrastructures

Branch master¶ ↑

The current branch proposes a minimal approach which does not even use nodes’ definitions.

General variables are set at top scope, and variables that are considered necessary (role and env) are defined in a switch based on regular expressions of the hostname.

Then is simply included the example42 class (which will become you own project class) where general classes are set and where different role classes are included according to the value of $role.

Note that this “nodeless” setup is something far from being common, but it’s the only approch we could conceive to set variables such as $role and $env at the top scope without using facts or an ENC.

Branch 2011¶ ↑

This is a branch useful if you don’t intend to use Puppet 3.0 soon.

Look in 10_archive/2010 and 10_archive/2011 of the 2011 branch for alternative approaches on how to define nodes using the nodes’ inheritance approach.

In the toasters/ directory you find examples of master-less setups that can be used to quickly configure an appliance.

Note that these sample layouts of /etc/puppet/manifests were done with the old Example42 modules’ set (branch 1.0 of Example42 puppet-modules) so they won’t work perfectly with NextGen modules.

The example42 module¶ ↑

In the Example42 puppet-modules set there’s a special “project” module, called example42 which contains site specific customizations of the general modules.

Here is defined the common baseline of all the nodes (example42/manifests/init.pp), “role” classes (where classes are included for different purposes) and the custom templates and files used for the “example42” project.

The example42 module is presented as just another module in the Example42 modules set but is provided are an example on how you can create a custom project module with all the customizations your site needs.

Use the script (provided by the Example42 modules git repo)

Example42-tools/project_rename.sh

to create a new project module based on the example42 sample.