Puppet deployment scenarios

Owned by Chris Tessmer
Last updated: Jan 06, 2020

SIMP 6.4+ is intended to support the Puppet deployment scenarios described in this article.


Contents:

Overview

Deployment strategies vary widely, based on a site’s infrastructure, existing policies, and administrative considerations. SIMP broadly groups these strategies into two high-level deployment scenarios, with some important variations:

Deployment ScenarioVariationr10k command

Control Repo?

Module
Repos

Autodeploy
from Git?

Local (Puppetfile-only)Local module reposr10k puppetfile install(error)Local (from RPMs)(error)


Control Repo

Manual r10kr10k deploy environment



(tick)


Remote

(Git hosting service)

(error)
Webhook + r10kr10k deploy environment(tick)
PE Code Managerpuppet code deploy(tick)




Local (Puppetfile-only) Scenarios 


Local: Deploying from Local module repos 

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

Under this scenario, a local r10k user will:

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

Notes:

  • The Puppet environment directory and Puppetfile must exist before r10k puppetfile install is run
  • The modules in the Puppetfile are defined with file:// URLs, and pull from Git repositories on the local file system

Control Repository Scenarios 


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 Puppet control repository
  • Updating their modules repositories with the contents delivered on the local filesystem by SIMP Puppet module RPMs.

Control Repo: Manual r10k deploy 

Puppet admins:

  • maintain a Puppet control repository from an external git service. 

  • An r10k user logs into the Puppet master and manually deploys entire Puppet environment directories (one per branch) from the command line:

    • r10k deploy environment [ENVIRONMENT]
    • puppet code deploy [ENVIRONMENT] (Puppet Enterprise)

Control Repo: Webhook-triggered r10k deploy 

Puppet admins:

  • Maintain a Puppet control repository (and Puppet module repositories) in an external git-hosting service
  • Deploy a Puppet environment by pushing updates to a control repository branch

When a control repository branch is updated, it automatically triggers an environment deployment on the Puppet master:

  1. The Git-hosting service uses a webhook to notify the Puppet master about the branch that was changed
  2. The webhook on the Puppet master triggers r10k to deploy the branch as an environment

Control Repo: PE Code Manager & File Sync 


Puppet admins:

  • Maintain a Puppet control repository (and Puppet module repositories) in an external git-hosting service
  • Deploy a Puppet environment by pushing updates to a control repository branch

When a control repository branch is updated, it automatically triggers an environment deployment on the Puppet master:

  1. The Git-hosting service uses a webhook to notify the PE master/MoM about the branch that was changed
  2. The webhook on the Puppet master triggers PE Code Manager to deploy the branch as a staged environment
  3. The PE File Sync service distributes the staged environment to any compile masters, and promotes the code from staging to live use.

References