Puppet environments are a great way to promote Puppet code to your production environment in a safe way. Each environment is configured with its own manifest and module path. Using environments lets you use different versions of the same module for different groups of nodes. This is useful for testing changes to your code before implementing them on production machines.
From our perspective, all code that manages nodes is considered to be production Puppet code, regardless of which environment it’s in. Many people think that it’s best to have Puppet environments that match the application path to production environments, but that can be devastating to the performance of your Puppet infrastructure.
Everything that you add to your growing Puppet infrastructure (data, roles, profiles, and modules) has a performance impact. In addition, the primary server (formerly called a master) loads a copy of all modules and data for each Puppet environment that has a single node checking in. The performance impact is multiplied by the number of environments, so it’s important to keep your Puppet environments to a minimum. Use cases for environments fall into three categories: permanent test environments, temporary test environments, and divided infrastructure. Learn more about use cases for environments from our documentation.