Learning Puppet 4

Chapter 29. Customizing Environments

Way back at the beginning of Part II, you set up testing and production environments. Now that you’ve learned more about Puppet, Puppet servers, and deployment methodologies, it’s time to talk about how to use environments effectively.

Environments provide isolation for modules and data. They provide useful ways to organize and separate modules and configuration data for different requirements. There are numerous reasons that people divide systems into different environments, but here are just a few:

• Support multiple team environments with different needs but some shared code
• Distinguish evolutions of product development (stable, beta, staging, test, dev)
• Avoid conflicts for dependency modules that share names
• Isolate security-sensitive data
• Stage tests for bug fixes or feature changes

In this chapter, we’ll discuss how to use environments for all of these purposes.

Even if you don’t think you need separate environments, I encourage you to read through this chapter so that you can consider what environments have to offer you. Even the smallest Puppet sites use environments, and there are good reasons for that.

Understanding Environment Isolation

An environment is not a namespace—it’s a hard wall where a module or data either exists in the environment or not. Two Puppet nodes requesting data from two environments might as well be talking to two different Puppet servers. You can have the same data or the same modules in multiple environments, ...