Environment isolation prevents resource types from leaking between your various environments.
If you use multiple environments with Puppet, you might encounter issues with multiple versions of the same resource type leaking between your various environments on the primary server. This doesn’t happen with built-in resource types, but it can happen with any other resource types.
This problem occurs because Ruby resource type bindings are global in the Ruby runtime. The first loaded version of a Ruby resource type takes priority, and then subsequent requests to compile in other environments get that first-loaded version. Environment isolation solves this issue by generating and using metadata that describes the resource type implementation, instead of using the Ruby resource type implementation, when compiling catalogs.
Enable environment isolation with Puppet
To use environment isolation, generate metadata files that Puppet can use instead of the default Ruby resource type implementations.
On the command line, run
puppet generate types --environment <ENV_NAME>for each of your environments. For example, to generate metadata for your production environment, run:
puppet generate types --environment production
Whenever you deploy a new version of Puppet,
overwrite previously generated metadata by running
puppet generate types --environment <ENV_NAME> --force
Enable environment isolation with r10k
To use environment isolation with r10k, generate types for each environment every time r10k deploys new code.
To generate types with r10k, use one of the following methods:
Modify your existing r10k hook to run the
generate typescommand after code deployment.
Create and use a script that first runs r10k for an environment, and then runs
generate typesas a post run command.
If you have enabled environment-level purging in r10k, allow the
resource_typesfolder so that r10k does not purge it.
Troubleshoot environment isolation
types command cannot generate certain types, if the type generated has missing
or inaccurate information, or if the generation itself has errors or fails, you get a
catalog compilation error of “type not found”
or “attribute not found.”
To fix catalog compilation errors:
- Ensure that your Puppet resource types are correctly implemented. In addition to implementation errors, check for types with title patterns that contain a proc or a lambda, as these types cannot be generated. Refactor any problem resource types.
Regenerate the metadata by removing the
.resource_typesdirectory and running the
generate typescommand again.
- If you continue to get catalog compilation errors, disable environment isolation to help you isolate the error.
To disable environment isolation in open source
generate typescommand from any r10k hooks.
- Remove the
To disable environment isolation in Puppet Enterprise (PE):
/etc/puppetlabs/puppetserver/conf.d/pe-puppet-server.conf, remove the
In Hiera, set
On the command line, run
service pe-puppetserver reload
.resource_typesdirectories from your staging code directory,
- Deploy the environments.
When you run the
generate types command, it scans the entire environment for resource type
implementations, excluding core Puppet resource
generate types command accepts the
--environment <ENV_NAME>: The environment for which to generate metadata. If you do not specify this argument, the metadata is generated for the default environment (
--force: Use this flag to overwrite all previously generated metadata.
For each resource type implementation it finds, the command
generates a corresponding metadata file, named after the resource type, in the
It also syncs the files in the
.resource_types directory so that:
Types that have been removed in modules are removed from
Types that have been added are added to
Types that have not changed (based on timestamp) are kept as is.
Types that have changed (based on timestamp) are overwritten with freshly generated metadata.
The generated metadata files, which have a
.pp extension, exist in the code
directory. If you are using Puppet Enterprise with Code Manager and file sync, these files appear in both the
staging and live code directories. The generated files are read-only. Do not delete
them, modify them, or use expressions from them in manifests.