The recommended puppet server directory layout

puppetpuppetmaster

I am just setting up a new puppet server and wanted to find out what the best practise directory structure is? Ive had a look around on different forums and on the puppet site and what strikes me is that everyone seems to lay it out in a different way. Isnt there a recommended way and directory structure?

So far I have:

puppet/
   + manifests/
      + site.pp  
      + nodes/
          + production/
              + nodes.pp
          + dev/
              + nodes.pp
   + modules/

Im just a little stuck after this 🙂

So I think I want to separate this down to server roles such as "webserver", which has a service such as "httpd" or "nginx"

Whats the best method to lay all of this out as its driving me nuts that there doesnt seem to be a preferred method to do this, or maybe I have just missed it in all of the other information 🙁

Is is this how you would structure the directories?

puppet/
   + manifests/
      + site.pp  
      + nodes/
          + production/
              + nodes.pp (Nodes have roles)
          + dev/
              + nodes.pp
       + roles/
           + web-server-apache.pp (Roles have modules)
   + modules/
       + web-server-apache/
           + manifests/
               + init.pp (This is where "httpd" gets defined and installs latest httpd)
           + templates/
           + files/

Best Answer

Yes, the standard directory layout looks like that - what kind of variations to this structure are you seeing?

Your different services (httpd, nginx) should each be handled by modules within the modules directory, while attaching these modules to nodes for inclusion in their configuration catalog will happen within manifests.

How are you looking to define your roles? Generally that should be done in your node definitions, whether that's a nodes.pp file in your manifests directory that gets loaded by site.pp, or instead using Hiera for your node definitions (which I'd definitely recommend if you're up for it).

Related Solutions

Puppet – Understanding Class Inheritance in Puppet

Puppet does not support this kind of configuration, but the restriction can be easily bypassed. The reason is in two basic puppet "rules":

A class can be included only once (subsequent include -statements will do nothing)
The order of execution is not strictly defined and can even be random

er-dev and er-bce-dev both include the class er. But the class cannot be included two times, so er class is executed only with the default $venvname = "er", or with overridden $venvname = "er-dev", but not both.

The solution: Change er class to a definition (see "Definitions" from Puppet Language Tutorial (http://docs.puppetlabs.com/guides/language_tutorial.html)):

modules/django-env/manifests/er.pp

# Create new er resource definition
define django-env::er($vpath="/home/django/virtualenvs", $vname="er") {
    file { "$vpath/$vname" :
        ensure => directory
    }
    # etc ...
}

We do not need the $venvname and $venvpath variables, they are specified as default values in the definition. The name django-env::er adds the definition into django-env namespace and allows automatic import (see below).

Import and Include

The difference between import and include statemens is:

import works with files, and does not execute classes
include executes classes
files must be imported before the classes can be included

Note: there is a very strong exception to the last rule: Puppet module lookup. include statement does automatic imports in many situations. Here are some of them:

include foo tries to import the file module_dir/foo/manifests/init.pp
include foo::bar imports module_dir/foo/manifests/bar.pp

With these automatic imports and the resource definition, you can define multiple virtual environments very easily. Change node 'centos-dev':

node 'centos-dev' imports default {
    include django-env
    # The er resource with default values:
    django-env::er { 'er-bce': }
    # Another er resource with different environment name:
    django-env::er { 'er-bce-dev': vname => 'bce-dev'}
}

And you can remove basically all import statements considering django-env module.

Happy Puppeting!

Linux – Puppet error when testing manifest

I posted it over at http://ask.puppetlabs.com as suggested by Sirex in chat. It was pointed out that I had renamed the file module manifest to users.pp, but it should have been init.pp as per the automatic loading of classes and subclasses that is built into Puppet.

Best Answer

Related Solutions

Puppet – Understanding Class Inheritance in Puppet

Import and Include

Linux – Puppet error when testing manifest

Related Topic