Online course for setting up your Manageable Puppet Infrastructure

Written by Ger Apeldoorn. Posted in Manageable Puppet Infrastructure

I’ve released a new course on Udemy, with this course you can set up your Manageable Puppet Infrastructure and learn how it works.

This is the first part of a series I will be developing over the next few months.

In this course we will build a fully functioning Manageable Puppet Infrastructure, fully deployed from puppet code.

This infrastructure has been deployed at many companies, and works very well in both very large and small environments.

It is updated with the latest best practices and works with Roles and Profiles, r10k deployments, Hiera eyaml et cetera. Puppetboard is used as the GUI.

With this coupon code, you will will get a nice discount.

Check usage of classes in your Puppet-infra

Written by Ger Apeldoorn. Posted in Manageable Puppet Infrastructure, Sysadmin

It’s always good to know what the impact is of your change. With these scripts, we can easily see which hosts use a specific class.

Example usage

$ Random
DTA Server
Count Modulename
4 Profile::Random
4 Profile::Random::Accounts
4 Profile::Random::Filesystems
4 Profile::Random::Initd
4 Profile::Random::Ulimit
2 Role::Random

Count Modulename
7 Profile::Random
7 Profile::Random::Accounts
7 Profile::Random::Filesystems
7 Profile::Random::Initd
7 Profile::Random::Ulimit
3 Role::Random

Continue reading for info on how to set this up!

MPI – Managing multiple customers within a single environment

Written by Ger Apeldoorn. Posted in Manageable Puppet Infrastructure


This is set in the Manageable Puppet Infrastructure, but should be quite useable if you’re not using it.

You want to manage multiple clients within a single environment. (You probably don’t want to create seperate environments or puppetmasters, because that creates quite a bit of overhead in the long run).

But how do we keep things flexible? It’s quite simple, use Hiera and classes in a smart way and you’re there!

One note; this simple setup only works if you do not have any naming conflicts in the modules. e.g. customer1 needs puppetlabs/apache and another needs another module named apache. In that case, you do need seperate environments.

Get that $customer variable filled

You’ll need a way to let Puppet know what customer a node belongs to. There are several ways:

Facter variables can be overridden quite easily. Use the ENC or Hiera!

  • Getting the info from Hiera, see below.
  • Set it from the ENC.

Adding a global $customer variable

In my site.pp:

$customer = hiera('customer')

node default {

Example: hieradata/hosts/

customer: mycustomer1

That’s an easy way to get the $customer (global) variable filled!

Putting it to use!


With the MPI, you’ve created a baserole that applies to all hosts.

We can still use that, just be aware that those resources/includes apply to ALL customers.

Also, we’d like a baseclass for each customer. Within the roles-module, that’s a piece of cake.

└── manifests
    ├── base.pp   # class role::base { (applies to all nodes)
    ├── mycustomer1
    │   ├── app.pp       # class role::mycustomer1::app {
    │   ├── base.pp      # class role::mycustomer1::base { (applies to all nodes of mycustomer1)
    │   ├── db.pp        # class role::mycustomer1::db {
    │   └── smarthost.pp # class role::mycustomer1::smarthost {
    └── mycustomer2
        ├── app.pp       # class role::mycustomer2::app {
        ├── base.pp      # class role::mycustomer2::base {
        ├── db.pp        # class role::mycustomer2::db {
        └── lamp.pp      # class role::mycustomer2::lamp {


You can add a level for customer-specific settings.

  - "hosts/%{clientcert}"        # Host-specific settings
  - "customer/%{customer}"       # Customer specific settings
  - "osfamily/%{osfamily}"       # Settings based on OS
  - "environment/%{environment}" # Environment specific settings
  - common                       # Common settings for all nodes.

Now, we can add a yaml file for each customer and assign the role::customer::base there.

Example: hieradata/customer/mycustomer1.yaml

  - role::mycustomer1::base

Of course, you can add other customer-specific settings as well here!

Feedback is welcome, leave a message!