Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 6 Next »

This document requires familiarity with Puppet Environments and their relationship to SIMP Environments.


SIMP-3479 - Getting issue details... STATUS

Managing Multiple Puppet environments (without SIMP)

Control repositories

Outside of SIMP, Git-based control repositories have been the dominant 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, where each branch defines a complete Puppet environment (which includes a Puppetfile)
  • A tool (r10k or PE Code Manager) to deploy Puppet environments from the control repository branches
  • (Advanced, but preferred) Repository webhooks that automatically trigger environment deployments on the Puppet master(s) whenever a branch is updated.

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

Puppet environments as code

A branch contains everything required to recreate a Puppet environment, so Puppet Environments can be treated like code:

  • (Using r10k/Code Manager,) Adding or removing a git branch will add or remove that environment on the Puppet master(s)
  • Puppet environment updates can be submitted as merge/pull requests
  • User can test, diff, and review changes before promoting them into important environments
  • When branches are updated, CI pipelines can automatically trigger tests and deployments

Multiple environments using Control repositories

Since 1 control repo branch = 1 Puppet environment, managing multiple Puppet environments is as simple as using git:

Control repos + Puppet deployment tools enable advanced environment scenarios:

  • (r10k, Code Manager:) Deploy consistent Puppet environments across Puppet architectures that involve multiple masters  
  • (Bolt:) Manage remote "agentless" hosts by checking out an environment's modules (using bolt puppetfile install) before 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 (SIMP 5.0-6.3).  However, in practice this has been cumbersome, risky, and easy to get wrong.

Starting with the 6.4.0 release (SIMP 6.4), SIMP has been retooled enough to safely support single-environment Puppetfile deployments (e.g., r10k puppetfile install from a Puppet environment directory).  However, there are still two major sources of conflicts with multiple Puppet environments and  SIMP:

Conflicts with Control Repositories

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

  • SIMP 5.0-6.3 RPM scriptlets + simp_rpm_helper, some tools like simp config 
  • SIMP 6.4 The simp environment new command
    • This is much safer than earlier versions, because it only alters environment files at user direction

Conflicts with Multiple Puppet Environments

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

  • SIMP (ALL) "Secondary" data under /var/simp/environments/$environment/
  • SIMP (ALL) "Writable" data under under /opt/puppetlabs/server/data/puppetserver/simp/environments/$environment/


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.

  • Puppetfile-based deployment tools like r10k or Code Manager and now preferred to deploy SIMP's Puppet modules
    • To prevent conflicts with these tools, SIMP no longer interferes with any files under the Puppet or SIMP environment directories, unless directed to by the user.
  • SIMP module RPMs now install tagged versions into local git repositories, for use in local Puppetfiles
    • The simp puppetfile tool was introduced to automatically generate Puppetfiles based on the current module RPMs.
  • The simp environment new tool was introduced to help users ensure that corresponding SIMP and Puppet environments are created.

Improvements focused on making it simple to use Puppetfiles in a single environment, with multiple 

made it simple to deploy environments, but they didn't make them safe.  


During the development of SIMP 6.4.0 it became apparent that the simp environment workflow would have problems down the road:

  • 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+







  • No labels