Background

Managing Multiple Puppet environments (without SIMP)

Since 2015, control repositories have been the dominant (non-SIMP) technology to manage and deploy Puppet code. 

At a high level, this involves:

• A Puppetfile that defines a collection of Puppet modules and where to get them
• A (Git) Control repository, from which each branch defines a complete Puppet environment (including 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 on the Puppet master(s).

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

Image Added

This makes it simple to:

• Manage multiple Puppet Environments as code:
  • Add or remove a branch from the repository to add or remove that environment on the Puppet master
  • Test, diff, and review changes like code
  • Automate CI pipelines to automatically test and trigger deployments
• Deploy Puppet environments across Puppet architectures that involve multiple masters
• Deploy a specific puppet environment to a remote "agentless" host using Puppet bolt.

Earlier SIMP releases

In earlier SIMP releases (5.0–6.3), managing multiple Puppet environments with corresponding SIMP assets was cumbersome and risky.  SIMP 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 removed some of these barriers addressed many of tool and RPM-related problems by making Puppetfile-based workflows module deployments the preferred mechanism method to deploy Puppet modules and environments:

...

.

• Puppetfile-based deployment tools like r10k or Code Manager are  and now expected preferred to deploy SIMP's Puppet modules or Puppet environments
  • 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  tool new tool was introduced to help users maintain each Puppet environment and its corresponding SIMP "extra" environment.
• SIMP no longer modifies files under environment directories unless the user initiates the action with tools like simp environment.

...

• 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   

During the development of SIMP 6.4.0 it became apparent that the simp environment workflow was inadequate to handle the full Puppet environment lifecycle:

...

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

...