# puppet directory structure (environments and profiles)

Hi, all. I'm newly managing a medium-sized (a couple dozen servers and a couple dozen Windows workstations) Puppet install, and I'm trying to come up with a directory structure that makes some sense. We're making a lot of changes right now (upgrading from 2.7 and 3.7, starting to use Forge rather than rolling our own for everything, and starting to use environments for the first time), making this a good time for a restructure. Unfortunately there are just so many things that need to be organized, and so many options that I've found online, that I'm really not sure what to go with. What would you do, and what are some best practices I could follow?

Here's what we've got now, for our company name xyz:

• puppet.conf in /etc/puppet
• nodes.pp and site.pp in /etc/puppet/manifests (the latter of which includes the former)
• All our modules in /usr/share/puppet/modules
• Our "roles" and "profiles", such as they are, in a module in /usr/share/puppet/modules/xyz

I want 3-5 environments (dev, testing, production, and maybe win7 and win7-testing).

So, a bunch of questions, then.

(1) Where do our custom and Forge modules live? Do we want our custom ones in /etc/puppet/env/$envname/modules and our Forge ones in /usr/share/puppet/modules? Or should the Forge ones go in /etc/puppet/modules, and if so, what is the /usr/share/puppet directory for? (And this might be a separate question, but what if we need different versions of a Forge module for different environments?) (2) Where do our site.pp and nodes directories go? (Do we even need a site.pp if we use a nodes directory?) And roles and profiles (though I think we really only have profiles)? Do we want paths like these: • /etc/puppet/manifests/site.pp • /etc/puppet/manifests/nodes/ • /etc/puppet/env/$envname/manifests/profiles/xyz/webserver.pp

Or am I mixing up the hierarchy order that we should be using? Or are we supposed to have site.pp and the nodes directory inside the env directory? For that matter, is anything at all supposed to go outside the env directory? And does anything go inside the env/$envname/manifests directory other than profiles? (3) How do we specify which environment we want for each node? Does the node definition in /etc/puppet/manifests/nodes/whatever.pp say "environment = dev", or does that not work? I tried to read the docs, but I got hung up when it started talking about a "node terminus". Sorry this is so long. As you can see, I'm not even totally sure I'm asking all the right questions. I hope you can help me get on the right path! Thank you! edit retag close merge delete ## 1 Answer Sort by » oldest newest most voted (Disclaimer: I'm new to Puppet too, so this is all based on googling and some playing-around research in a test puppet environment) This answer assumes some default settings from the 3.x puppet config: environmentpath=$confdir/environments, basemodulepath=\$confdir/modules:/usr/share/puppet/modules .

1. Any module that is environment-specific should go into /etc/puppet/environments/<env>/modules. Any module that is common to all environments should go into /etc/puppet/modules or /usr/share/puppet/modules; I don't know what the difference is between those two directories.

• If you need different versions of Forge modules in different environments, you can install those modules directly into the environment by using the --target option of puppet module install - for example, puppet module install --target /etc/puppet/environments/foo/modules bar-baz
2. The default for directory environments is to load all the manifests found in /etc/puppet/environment/<env>/manifests. From my understanding, it's common practice to create a 00site.pp or similar manifest in that directory that has site-wide settings, then to create a .pp file for each node or class of nodes that you are classifying.

• If you're using the "Roles and Profiles" pattern (which I highly recommend; see the Designing Puppet: Roles/Profiles Pattern for more info), then the roles and profiles should go into modules - one named roles and one named (drumroll) profiles. Within the manifests directories of those modules, you would create an almost-empty init.pp (containing just a class roles {} or class profiles {} declaration), then create a subclass file for each role or profile (e.g. for the roles::web role, you would create .../modules/roles/manifests/web.pp and declare the class roles::web {...} class).
• If you're using "profiles" as a more generic node classification term, then those would probably be the node classification files in your environment's manifests directory.
3. There are two (really two-and-a-half) ways to specify the environment for a node:

1. In the node's puppet.conf file, in the [agent] section, include the environment=<environment> setting (e.g. environment=dev).
2. An External Node Classifier can return an environment setting as part of its output. See External Node Classifiers for details, if you want to write a custom script to identify which environment each node will be in. The ENC can also assign classes to nodes (its original function), and so can take the place of having node classification scripts in your manifests.
3. (Really, 2½) The puppet master's environment=<environment> setting in the [master] section will determine the default environment for any node that does not set one.

If none of these provide an environment, then the default environment is production.

more

## Stats

Seen: 4,417 times

Last updated: Apr 27 '15