Background

...

Managing Multiple Puppet environments (without SIMP)

...

Control repositories

Outside of SIMP, Git-based control repositories have been the dominant (non-SIMP) technology to manage and deploy Puppet code since 2015.  At a high-level, this workflow involves:

• A Puppetfile that defines a collection of Puppet modules and where to get them
• A (Git) Control repository, from which  where each branch defines a complete Puppet environment (including which includes a Puppetfile)
• A tool (r10k or PE Code Manager) to deploy Puppet environments from the control repository Deployments are typically triggered by the repository—so that whenever a branch is updated, it is automatically deployed branches
• (Advanced, but preferred) Repository webhooks that automatically trigger environment deployments on the Puppet master(s) whenever a branch is updated.

The upshot of this is that a control repository branch defines everything needed to recreate a specific Puppet environment. 

This makes it simple to:

...

Managing Puppet environments as code

Since a branch contains everything required, Puppet Environments can be treated like code:

• Add Adding or remove removing a branch from the repository to will add or remove that environment on the Puppet masterTest(s) (via r10k/Code Manager)
• Environment updates can be submitted as merge requests in the git hosting service
• User can test, diff, and review changes like code
• Automate CI pipelines to automatically test and trigger deployments
Deploy before promoting them into important environments
• As branches are updated, CI pipelines can automatically trigger tests and deployments 

Managing multiple environments with control repositories

Since an SCM branch = a Puppet environment, managing multiple Puppet environments is as simple as using git:

• Creating a temporary testing (canary) environment is as simple as forking from an existing branch
  • Once the canary branch is validated, you can simply merge it back into its original branch
• Write access to important permanent environments can be controlled by protecting their git branches.
• Deploying consistent Puppet environments across Puppet architectures that involve multiple mastersDeploy a specific puppet environment to a remote "agentless" host using Puppet bolt. becomes as simple as r10k deploy environment BRANCHNAME.
• You can use Puppet bolt to manage remote "agentless" hosts by checking out an environment's modules (using bolt puppetfile install) and running bolt apply.

Managing Multiple Puppet environments (with SIMP)

It has been technically possible to manage multiple Puppet environments from a control repository since SIMP 5.0 (

Starting with the 6.4.0 release (

The are two major sources of conflicts with multiple Puppet environments in the earlier and 6.4.0 releases of SIMP:

SIMP automation can alters files under the Puppet and SIMP environment directories

• Status
  colour Grey title SIMP 5.0-6.3

   RPM scriptlets + simp_rpm_helper, some tools like simp config 

• Status
  colour Blue title SIMP 6.4

   The simp environment new command, which only alters environment files at user direction

SIMP expects a Secondary and Writable "extra" directory for each Puppet environment

• Status
  colour Red title SIMP (ALL)

   Everything under /var/simp/environments/$environment/

• Status
  colour Red title SIMP (ALL)

   Everything under /var/simp/environments/$environment/

SIMP Extra "environment" data

Earlier SIMP releases

In earlier SIMP releases (5.0–6.3), it was technically possible to deploy multiple environments from a control repository—but in practice, it was  cumbersome and risky:

• Whenever a new Puppet environment was deployed, (manual) follow-on actions were required to ensure the appropriate SIMP data was available for that environment
• RPM updates and simp_rpm_helper could modify existing files Puppet and SIMP environment directories
• It assumed an in-depth knowledge of Puppet and SIMP
• It still suffered from significant limitations and risks

SIMP 6.4.0: Deploy single environment from a Puppetfile

SIMP 6.4.0 addressed many of tool and RPM-related problems by making Puppetfile-based module deployments the preferred method to deploy modules.

...

• Making a new SIMP writable and secondary environment for ever Puppet environment was arbitrary 
  • The dependence on $environment made it necessary to adopt workarounds like `simp environment new [--copy|--link]` when environments used the same (or similar) resources
  • Linked 
• It would be too easy to permanently lose data from linked environments with the proposed simp environment rm command

Puppet Environments and SIMP Assets

SIMP 6.4 

Proposed SIMP 6.5+

Legacy 6.4 assets in SIMP 6.5+

...