5

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/
Tony
  • 311
  • 4
  • 11
  • 1
    `as its driving me nuts that there doesnt seem to be a preferred method to do this` - Yup, I think that is accurate related to what you are asking. – Zoredache Feb 07 '14 at 18:03
  • So I have update the structure to the one above. it seems to have a logical structure and layout. I still think puppet should have this sort of thing defined as a best practice. – Tony Feb 07 '14 at 20:17
  • I also spent far too long trying to work out why it didn't work when i realised that i had named the file init.php :) too much php work recently. – Tony Feb 07 '14 at 20:18

3 Answers3

2

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).

Shane Madden
  • 114,520
  • 13
  • 181
  • 251
  • Make sure to have a tests directory!! (*or does nobody actually do that?*) – ewwhite Feb 07 '14 at 17:33
  • So what i'm after is how to logically structure the roles and services directory structure. Or doesn't it really matter? As for the site and nodes that makes sense. Test directory, who tests! ;) – Tony Feb 07 '14 at 17:56
  • @ewwhite Tests? This is devops!! (I usually just see tests in individual modules, have you seen one at this level?) – Shane Madden Feb 07 '14 at 18:12
  • @Tony Ahh, gotcha. Well, the services should for the most part just be set up in modules - you can have a logical structure of roles and services, but that will not be reflected in your actual directory structure. – Shane Madden Feb 07 '14 at 18:13
2

I suggest using an IDE like Geppeto to manage your modules according to the Puppet Module Style Guide. Geppetto will create the needed files and directory structure.

рüффп
  • 620
  • 1
  • 11
  • 25
deagh
  • 2,019
  • 5
  • 19
  • 19
1

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

I think you are asking if you can organize your modules into a tree on the filesystem. For the most part, people don't do this. They just put lots of modules in the modules directory, and give things nice descriptive labels/names.

It is useful to create a little bit of structure for a particular module. For example you might have a role module, you could create a class like role::webserverwhich includes in modules that configure particular services. But ifrole::webserver` is just including classes, you could apply the same things in your node definition, your enc, or hiera.

In your example you suggest defining services under services::. You will find this very difficult to maintain if you ever want to use modules for the forge. Simply because all the forge modules basically assume they live right at the top level. You would have to masssively re-write any module you downloaded to have it fit into your structure and use it.

So my suggestion, give up on the idea of a tree, and accept that you will have a large flat directory modules directory.

Zoredache
  • 130,897
  • 41
  • 276
  • 420