Environments: Limitations of Environments
This version of Puppet is not included in Puppet Enterprise. The latest version of PE includes Puppet 4.5. A newer version is available; see the version menu above for details.
Environments solve a lot of problems in a convenient way, but they still have some limitations. Some of these are just features Puppet doesn’t have yet, and some of them are outside Puppet’s control. We want to fix all of them, but some may take a lot longer than others.
Plugins Running on the Puppet Master are Weird
Puppet modules can contain Puppet code, templates, file sources, and Ruby plugin code (in the
lib directory). Environments work perfectly with most of those, but there’s a lingering problem with plugins.
The short version is: any plugins destined for the agent node (e.g. custom facts and custom resource providers) will work fine, but plugins to be used by the puppet master (functions, resource types, report processers, indirector termini) can get mixed up, and you won’t be able to control which version the puppet master is using. So if you need to do testing while developing custom resource types or functions, you may need to spin up a second puppet master, since environments won’t be reliable.
This has to do with the way Ruby loads code, and we’re not sure if it can be fixed given Puppet’s current architecture. (Some of us think this would require separate Ruby puppet master processes for each environment, which isn’t currently practical with the way Rack manages Puppet.)
If you’re interested in the issue, it’s being tracked as PUP-731.
Hiera Configuration Can’t be Specified Per Environment
Puppet will only use a global hiera.yaml file; you can’t put per-environment configs in an environment directory.
When using the built-in YAML or JSON backends, it is possible to separate your Hiera data per environment; you will need to interpolate the
$environment variable into the
:datadir setting. (e.g.
Most Extensions Aren’t Environment-Aware
As of today, most extensions to Puppet (including PuppetDB and the Puppet Enterprise console) don’t receive, store, or control information about Puppet’s use of environments.
We’re in the process of working on this; one of the most important steps was adding the ability to query the master for environment info, as mentioned above.
Exported Resources Can Conflict or Cross Over
Nodes in one environment can accidentally collect resources that were exported from another environment, which causes problems — either a compilation error due to identically titled resources, or creation and management of unintended resources.
Right now, the only solution is to run multiple puppet masters if you heavily use exported resources. We’re working on making PuppetDB environment-aware, which will fix the problem in a more permanent way.