4.7.2. Deploying SIMP Environments

SIMP fully supports Puppet Environments, and extends the practice by providing parallel environment directories to manage data that does not belong in a control repository.

This section describes how SIMP interacts with Puppet environments, and how to integrate SIMP environments into your site’s deployment strategy.

4.7.2.1. SIMP Environments

The term “environment” is heavily overloaded when discussing SIMP, Puppet, DevOps, and IT in general.  We attempt to make the following distinctions:

SIMP Environments diagram

A full SIMP “Omni” environment is composed from three corresponding environments:

Environment Description
Puppet
  • The standard concept of “Puppet environment” when Puppet/PE is operated independently from SIMP.
  • Acts as a namespace for managing nodes―with its own code, data, and lookup hierarchy.
  • Sourced (once deployed) from a Puppet environment directory
Secondary
  • Provides SIMP with independently-maintained assets that support a specific Puppet environment
  • Useful for git-unfriendly files, such as secrets (e.g., keydist/) and large files distributed by rsync.
  • Sourced from a secondary environment directory
Writable
  • Puppet environment-specific SIMP data (e.g., simplib::passgen() data), generated by the Puppet Server
  • Data is generated automatically by Puppet functions during catalog compilation
  • Written to/sourced from the writable environment directory

Each environment has an associated directory:

Puppet environment directory

  • A single directory at $codedir/environments/<environment_name>
  • Contains the Puppet code and Hiera data needed to manage a Puppet environment:
    • site manifest(s), Puppet modules, Hiera data (Hiera 4+), and Hiera hierarchy (Hiera 5+).
  • Assets can deployed using r10k or Code Manager:
    • r10k deploy creates one Puppet environment directory per control repository branch.
    • r10k puppetfile install (using default settings) can be run at the top level of a Puppet environment directory to deploy its modules from the local Puppetfile.

Secondary environment directory

SIMP, by default, supplements each Puppet environment with a Secondary environment directory, located on the SIMP server at /var/simp/environments/<environment_name>.

This space holds all static, non-Puppet created files. It is generally used for large binary items that will be delivered via rsync, and for files that are too dangerous to add to a version control system. These include things like the SIMP rsync materials (rsync/), the Infrastructure Certificates (site_files/pki_files/files/keydist/), and the krb5 Puppet module (site_files/krb5_files/files/keytabs).

As you add new Puppet environments, you will need to replicate the appropriate Secondary directory structure here.

Note

For more information on the SIMP rsync structure, please see HOWTO Work with the SIMP Rsync Shares

Writable environment directory

SIMP also maintains Writable environment directories in parallel with each Puppet environment at /opt/puppetlabs/server/data/puppetserver/simp/environments/. This space holds all non-static, Puppet Server created files. It is used for content that can be generated during catalog compilation, such as simplib::passgen() and ssh::autokey(),

Warning

You should never need to manually adjust anything in this directory space.

Building on the environments above, it is useful to consider the following “meta” environments:

Environment Description
SIMP “Omni” environment
  • The complete combination of Puppet + SIMP Extra (Secondary + Writable) environments of the same name
SIMP “Extra” environment
  • A combined Secondary environment + Writable environment
  • (Just the SIMP environments w/o the Puppet environment)
Infrastructure Environment
  • A local site’s dedicated internal infrastructure tier
  • Exists independently from Puppet
  • Often named something along the lines of “development,” “testing, acceptance,” “staging,” “production”, etc.,
  • In Puppet circles, this is sometimes referred to an infrastructure as an “application tier” or “permanent test environment

Scaling considerations for Extra (Secondary and Writable) environment directories

Secondary and Writable environment directories pose a problem for Puppet scaling:

  • Load-balanced compile masters must keep the contents of both secondary and writable environment directories in sync across all compile masters.
  • Alternatively, disciplined use of Hiera Eyaml encryption must be used to replace all parameters that default to using Writable-environment functions like simplib::passgen().

4.7.2.2. Deployment Scenarios

4.7.2.2.1. r10k + SIMP RPM-delivered module repositories

Note

This is the initial deployment scenario immediately after Installing SIMP from an ISO.

r10k + local, SIMP RPM-delivered module repositories

Under this scenario, local Puppet admins:

  • deploy Puppet modules from an existing Puppet environment directory
  • use the command r10k puppetfile install to deploy the modules defined in the local Puppetfile
  • reference module repos from git repositories on the local filesystem via file:// urls in the Puppetfile.

4.7.2.2.2. Professional: r10k + Control Repository

r10k + Control Repository

Note

Administrators of all control repository scenarios are assumed to have enough git and r10k (or Code Manager) expertise to manage their own infrastructure. This includes arranging their own external git-hosting service, managing their own control repository, and updating their modules repositories with the contents delivered on the local filesystem by SIMP Puppet module RPMs.

Under this scenario, Puppet admins:

  • maintain a Puppet control repository from an external git service
  • deploy entire Puppet environment directories (one environment for each repository branch) using r10k deploy environment [ENVIRONMENT].
    • This might be done manually from the command line, or triggered automatically (e.g., from a webhook).

4.7.2.2.3. Enterprise: PE Code Manager + Control Repository

PE Code Manager + Control Repository

Under this scenario, Puppet admins:

  • maintain a Puppet control repository from an external git service
  • deploy entire Puppet environment directories (one environment for each repository branch) using PE Code Manager.
    • This is triggered automatically from a Code Manager webhook.