Home / server / Questions / 110354
Accepted
cclark
Asked: 2010-02-07 21:31:43 +0800 CST

What methods are there to configure puppet to serve resources for multiple environments?

  • 772

I seem to come across two ways for using puppet in multiple environments:

1) Install a puppetmaster in each environment and only update the recipes from source control for that environment when ready to deploy the recipes in that environment.

2) Use one puppetmaster and use a variable in the puppet.conf of each client to specify the environment and then in the puppetmaster specify a different modulepath for each environment and each of those paths is updated to the branch of the recipe repository intended for that environment (e.g. dev, staging, production).

Only running one puppetmaster seems like it is one less piece of infrastructure to keep running but there is some additional complexity in the configuration.

Are there additional pros or cons to one of these methods or something which I'm missing entirely?

puppet

4 Answers

  1. Best Answer

    Option #1 won't scale. It'll be a pain to manage. Puppet supports environments for this very reason :)

    Let a single puppetmaster serve multiple environments, each with their own manifest and modulepath directives. It's a really common approach that a lot of people use. Also remember that:

    • Puppet can manage your puppetmasterd.conf and puppet.conf config files.
    • Depending on how you call puppetd you can also use the --environment argument.
    • 2

  2. You can call puppetd from the command line with --environtment. But that can be a pain to manage if you want to move many servers from one Env to another.

    The foreman project acts an "external nodes" interface and lets you assign environments to hosts/hostgroups from a web front end. You can then have different modulepaths for different hosts. You can even change Environments for nodes from the interface, letting you move modulepaths from Dev->Prod, or however you want.

    • 1

  3. I think you should take a look at puppet tags

    • 0

  4. Using puppet environments has a couple of drawbacks:

    • you can reliably set puppet environment only from agent — this might create some vulnerabilities if you store your passwords etc cleartext in your modules/templates.
    • custom functions are loaded only from a single environment which is used as default on puppetmaster — this means you'll be unable to keep different version of custom functions (if you use them) on different environments.

    In a company I'm working for we are going to use 2 puppetmaster servers — one for production, and one for the rest of environments.

    To ease managing puppet modules on several puppetmasters you can keep your modules in VCS like git and deploy new versions of them to puppetmasters through capistrano etc.

    If you need several environments not to do versioning of your puppet modules but for providing different data to different nodes based on the environment (different variables, node classes etc) there are some more options: * inherit nodes of different environments from basic "environment" nodes * provide a per-environment set of parameters and classes for each node through ENC (Puppet Dashboard, Foreman) in which you create a group for each environment with needed params set and add your nodes to those. * create a custom fact or a custom function returning your environment (based on local file/ AWS tag/DB query/whatever) and use that fact to serve different data in your manifests using conditionals/extlookup/hiera.

    • 0