Environments are isolated groups of Puppet agent nodes.
A Puppet master serves each environment with its own main manifest and module path.
This lets you use different versions of the same modules for different groups of nodes, which is useful for testing changes to your Puppet code before implementing them on production machines.
Access environment name in manifests
If you want to share code across environments, use the $environment variable in your manifests.
To get the name of the current environment:
-
Use the $environment variable, which is set by the master.
Environment scenarios
The main uses for environments fall into three categories: permanent test environments, temporary test environments, and divided infrastructure.
In a permanent test environment, there is a stable group of test nodes where all changes must succeed before they can be merged into the production code.
The test nodes are a smaller version of the whole production infrastructure. They are either short-lived cloud instances or longer-lived virtual machines (VMs) in a private cloud. These nodes stay in the test environment for their whole lifespan.
In a temporary test environment, you can test a single change or group of changes by checking the changes out of version control into the $codedir/environments directory, where it is detected as a new environment.
A temporary test environment can either have a descriptive name or use the commit ID from the version that it is based on. Temporary environments are good for testing individual changes, especially if you need to iterate quickly while developing them. When you’re done with a temporary environment, you can delete it. The nodes in a temporary environment are short-lived cloud instances or VMs, which are destroyed when the environment ends.
If parts of your infrastructure are managed by different teams that do not need to coordinate their code, you can split them into environments.
