Page Comparison

...

Table of Contents

Background

This article describes the workflow specific to installing a fresh SIMP 6.4.0+ server from an ISO.  It builds on the decision log SIMP 6.4.0: What r10k-friendly RPM features should it include?.

...

• Installation by ISO is intended to be an easy way to get started, and ensure that all files are present (including Puppet modules).
• SIMP supports installations in offline/network-isolated enclaves.

Relevant data

What the word "Environment" means

The term "environment" is heavily overloaded with respect to SIMP, Puppet, DevOps, and IT in general. 

This decision log uses the SIMP-specific terminology defined in the design article, SIMP Environments.

Proposed workflow

High-level workflow

For reference, the process has been broken down into stages A, B, and C:

A: (Admin) installs SIMP from ISO

Info

(Admin) installs SIMP from ISO, ala the SIMP docs procedure, "ISO Installation (preferred)." 

...

• At the end of the ISO installation:
  • All puppet modules have a local bare git repo, with a tagged commit
  • There is no simp Puppet environment yet, /etc/puppetlabs/code/environments/simp
  • There is no  /var/simp/environments/simp yet

B: Admin runs simp config

Anchor
stage_b stage_b

(Admin) logs into the newly-installed SIMP host and runs simp config.

• At an early stage (before applying with the standard action items from the questionnaire):
  • (B1) Logic determines if it needs to create the first Puppet environment directory and auto-deploy the SIMP Puppet Modules
    • This will always be "yes" after a fresh ISO install
  • (B2) (If yes:) Auto-deploy the first Puppet environment + modules
    • Details are in the "auto-deploy" section.

Key 6.4.0+ differences:

All stage B logic is new to simp config, and it replaces RPM logic in SIMP ≤ 6.3.  Specifically, it replaces the old logic between simp-environment and simp-adapter that effectively accomplished the "auto-deploy" in SIMP ≤ 6.3, but in an opinionated manner that can conflict with r10k administration. The old logic:

...

• The initial Puppet environment in SIMP ≤ 6.3 was created upon the installation of the simp-environment RPM.
  • There is only one circumstance when SIMP 6.4+ will auto-generate a Puppet environment, and that is when simp config is run on a Puppet server without any deployed Puppet environments.
  • In practice, this means that  all later environments must be created by the administrator—never automatically.
    
    
• The Puppet module auto-deploy logic in SIMP ≤ 6.3 executed immediately upon the installation of every RPM, which happened during and after the initial SIMP ISO installation.
  • There is only one circumstance when SIMP 6.4+  will auto-deploy Puppet modules, and that is when simp config is run on a Puppet server without any deployed Puppet modules.
  • In practice, this means that all later deployments must be initiated by the administrator—never automatically.
    
    

C: Remainder of SIMP installation process

After deploying the initial Puppet environment, the rest of the SIMP installation continues without any specific alterations to support the Puppetfile-based workflow.  This includes the remainder of simp config (C1), (admin-initiated) simp bootstrap, (admin-initiated) reboot, and the post-boot Puppet agent run.

Workflow details

A2: Puppet module RPMs + local bare git repositories

• After a SIMP-packaged Puppet module RPM is installed, the system's simp_rpm_helper script ensures that a local bare git repository exists for the module, and it contains a commit of the modules files (tagged with the module's version).
• This is a prerequisite for simp puppetfile generate to work.
• A prototype for this workflow was already implemented during SIMP-6083. 

B2: simp config's initial "auto-deploy"

Anchor
autodeploy autodeploy

The "auto-deploy" referenced in stage B2 must perform at least three actions:

1. Create the production Puppet environment directory $codedir/environments/production and secondary environment directory at /var/simp/environments/production.
   • There is currently no logic to do this.
   • A manual command has been proposed during architecture discussions, currently referred to as simp environment new ENVIRONMENT (see section below).
     

2. Generate the Puppetfile and Puppetfile.simp in the Puppet environment directory.
   
   (As of SIMP-6193) this can currently be accomplished manually by running:
   
   
   • simp puppetfile generate --skeleton > Puppetfile
   • simp puppetfile generate > Puppetfile.simp


3. Deploy the SIMP Puppet modules
   • This can be done by running r10k puppetfile install after the Puppetfile and Puppetfile.simp are in place.

B2: simp environment new ENVIRONMENT

Anchor
simp_environment_new simp_environment_new

During the initial planning for the ISO installation, it was noted that the initial install (and subsequent admin work) would need to create environments.

Deployment scenarios 

Anchor
deployment_scenarios deployment_scenarios

This proposed ISO+Puppetfile workflow accommodates all common Puppetfile-based deployment methods as natively as possible.

ISO-only: r10k + RPM-delivered module repositories

Local Puppet admin(s):

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

...

• The secondary environment for production was generated automatically during simp config's initial auto-deploy in Stage B2
• New environments can be generated using the proposed command, simp environment new.
• New environments can also be cloned or symlinked from an existing SIMP extra environment (associated secondary + writable environments).

Professional: r10k + Control Repository

...

• The secondary environment for production was generated automatically during simp config's initial auto-deploy in Stage B2, 
• New environments can be generated using the proposed command, simp environment new.
  • New environments can also be cloned or symlinked from an existing SIMP extra environment (associated secondary + writable environments).
• The simp environment new command can be configured to run after each deployment via the postrun setting in r10k.yaml.

Enterprise: PE Code Manager + Control Repository

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.

...

• The secondary environment for production was generated automatically during simp config's initial auto-deploy in Stage B2, 
• New environments can be generated or cloned using the proposed command, simp environment new.
  
  • can be configured to run after each environment deployment by setting postrun in Code Manager's r10k.yaml.
  • It may also be configured to run from a (not created) local webhook using Code Manager's post_environment_hooks setting.
• New environments can be generated using the proposed command, simp environment new.
  • New environments can also be cloned or symlinked from an existing SIMP extra environment (associated secondary + writable environments).
  • The simp environment new command can be configured to run after each environment deployment by setting postrun in Code Manager's r10k.yaml.
  • It may also be configured to run from a local webhook (not included) using Code Manager's post_environment_hooks setting.

Options considered

Action items

Outcome

(Working assumption for Sprint 82 as of 14 Mar 2019): Option 1

Resources

• (Source for https://draw.io diagrams: simp_iso_puppet_workflow_diagrams.xml)

...