Using Puppet with Self Service Provisioning

transcript

Using Puppet with vRealize Automation Self Service Provisioning and Configuration Management

Justin Jones Senior Consultant, VMware

01/12/2015

About the speaker

Senior Consultant @ VMware Integration and Automation Team Previously: Lockheed Martin Accenture

justin7jones

Consulting Projects I’ve worked on:

Why Self Service Provisioning?

Fast Delivery

Fully Configured Customized

Traditional VM Delivery Triangle

Pick 2

•  Properly implemented Self Service Provisioning promises all 3 of the Delivery Triangle

•  To achieve all 3, configuration management is a necessity

•  Organizations try all the time to script customization and configuration. They mostly fail- the overhead in maintaining and managing an application installation and configuration script base across product versions and operating systems is too high.

•  There is an answer…

•  System Administrators are faced with managing much larger numbers of virtual machines when a self service provisioning system is deployed

•  Maintaining software package versions over large pools of systems is time consuming and difficult

•  Without centralized configuration management, configuration drift challenges standardized enterprise configuration which can be a huge headache for system administrators

Puppet + Self Service Provisioning Benefits Admins, too

There are 2 main types of Self Provisioning puppet implementations we frequently see in the field:

Using Puppet with a Self Service Provisioning Solution

Infrastructure Configuration

•  Shared between (most) VMs in the environment

•  Configures global OS settings like logging, admin security accounts, NTP settings, etc.

•  Definition extends to installing and configuring infra apps like monitoring agents, backup, etc.

Infrastructure Customization

•  Unique depending on the purpose of the VM

•  Installs and configures non infrastructure applications

•  Subdivided into 2 additional models •  ‘a la carte’ Design Pattern •  Roles and Profiles Design Pattern

“Design Patterns” is the term typically used in the Puppet community that is similar to what other organizations term ‘Best Practices’- the idea is that no one solution is ‘one size fits all’ and what is ‘Best Practices’ for one organization may not be such for another.

Infrastructure Customization Design Patterns

Roles Profiles Design Pattern: Essentially a single ‘role’ (which is a Puppet Group) is chosen that defines EVERYTHING that puppet configures on the system. Membership in multiple roles is NOT ALLOWED. ‘a la carte’ design pattern: The cloud platform is configured to present the user with a ‘menu’ of choices. The may multiselect as many choices as they would like. Invalid combinations must be prohibited in the user presentation layer (UI).

‘a la carte’ Design Pattern (with Self Service Provisioning)

‘a la carte’ Design Pattern

VMware vRealize Automation 6.01 screenshot, simple ‘a la carte’ checkbox list

‘a la carte’ Design Pattern

Properties of the ‘a la carte’ design pattern: •  Nodes can be members of any number of groups

•  Some group combinations may not be allowed- it is up to administrator to configure the UI so that invalid combinations cannot be selected

•  Each elective group corresponds to an option chosen in the UI

•  Required groups are applied regardless of user selection and are not selected in the UI

Roles and Profiles Design Pattern (with Self Service Provisioning)

Roles and Profiles Design Pattern

VMware vRealize Automation 6.01 screenshot, simple Role Selection list.

For Role Selection, no Multiselect is needed. A single Role may be chosen in the UI. Alternatively, each item ‘ordered’ in a catalog may correspond to a role.

Roles and Profiles Design Pattern

Properties of the Roles and Profiles design pattern: •  Nodes can be members of ONLY 1 GROUP. This Group

is called a Role

•  A role can have multiple classes applied to it

•  The UI must be configured so that only a SINGLE Role may be chosen-

Which Design Pattern Should I use?

‘a la carte’ Attributes •  Provides users with the greatest flexibility

•  Can allow ‘hybrid’ systems (web + db), etc.

•  Prevents ‘role sprawl’

•  If systems frequently end up with invalid class combinations, you may want to consider Roles and Profiles

Roles and Profiles Attributes •  High level of consistency between servers

•  Easier to enforce compliance

•  Less choices for user (depends on your user base if this is good or not)

•  If ‘role sprawl’ occurs, you have probably chosen the wrong design pattern.

Self Service Provisioning Task Flow Designs

Self Service Provisioning Task Flow: Autosign Method

User Orders VMPrestage VM in

Puppet(RAKE API)

Node Builds in Hypervisor

Node boots and runs Puppet Agent

Node checks in to Puppet Enterprise

Console

Node is autosigned(Policy Based,

whitelist, ,or Naïve)

Node is assigned group(s) by RAKE

API callAgent Runs and VM is complete

For more information on autosigning, see: https://docs.puppetlabs.com/puppet/latest/reference/ssl_autosign.html

Self Service Provisioning Task Flow: REST API Signing Method

For more information on the HTTP REST API and cert signing, see: https://docs.puppetlabs.com/guides/rest_api.html#certificate-status

User Orders VMPrestage VM in

Puppet(RAKE API)

Node Builds in Hypervisor

Node boots and runs Puppet Agent

Node checks in to Puppet Enterprise

Console

HTTP REST API call to sign CERT

Node is assigned group(s) by RAKE

API callAgent Runs and VM is complete

Alternative Methods to Assign Node Group Membership

Puppet Data Flow

Alternative Classification: Built in Facts (FQDN)

Alternative Classification: Custom Facts

For more information on creating custom facts, see: https://docs.puppetlabs.com/facter/2.3/custom_facts.html#adding-custom-facts-to-facter

Sample RAKE API Commands (Prestage ‘a la carte’)

For more information on RAKE API, see the following: https://docs.puppetlabs.com/pe/latest/console_rake_api.html

Automation engine will SSH into Puppet Enterprise Console and Create Node / Assign Group membership is a single command

$ sudo /opt/puppet/bin/rake -‐f /opt/puppet/share/puppet-‐dashboard/Rakefile RAILS_ENV=production node:add[my_vm_01,(VMware_Mandatory,VMware_Monitoring_Agent, VMware_Apache)]

Sample RAKE API Commands (Prestage ‘Roles and Profiles’)

For more information on RAKE API, see the following: https://docs.puppetlabs.com/pe/latest/console_rake_api.html

Automation engine will SSH into Puppet Enterprise Console and Create Node / Assign Group membership is a single command

$ sudo /opt/puppet/bin/rake -‐f /opt/puppet/share/puppet-‐dashboard/Rakefile RAILS_ENV=production node:add[my_vm_01,(ROLE::Apache_Web_Server)]

Integration with Puppet: Automation Platform Requirements

Machine Lifecycle: Determine how to integrate with SSP Platform

INTERNAL OR VMWARE AUTHORIZED USE ONLY 24

VM is orderedFrom Catalog

Before Machine isCloned/built/Deployed

After MachineIs booted

When MachineIs Edited

When machine isdeleted

Prestage NodeIn Puppet

(Create and classify/apply groups)

Invoke AgentAnd/or

HTTP REST Sign

Change Node Groups

Clean Up Node (Delete from Puppet)

Machine Lifecycle: How VMware does it (Before Machine is Built)

User Orders VM from catalog

During Each State, a vCenter Orchestrator Workflow is called by vCloud Automation Center

•  System Administrators are faced with managing much larger numbers of virtual machines when a self service provisioning system is deployed

•  Without configuration management, there is a gap in automated delivery of VMs (the ‘automatic’ process terminates with a manual final step, which defeats the purpose)

•  Without centralized configuration management, configuration drift and system standardization (are they pointed at the correct DNS server?, etc.) can be a huge headache for system administrators

•  Integration with Self Service Provisioning Platforms typically requires an orchestration engine that can be called from the SSP Platform

Key Points

Questions?

Using Puppet with Self Service Provisioning

Software