About the speaker Senior Consultant @ VMware justin7jones
Integration and Automation Team
Lockheed Martin Accenture Consulting Projects I’ve worked on: 2
Why Self Service Provisioning? • Properly implemented Self Service Provisioning promises al 3 of the Delivery Triangle Traditional VM Delivery Triangle
• To achieve al 3, configuration management is a Pick 2 necessity Fast Delivery • Organizations try al the time to script customization and configuration. They mostly fail- the overhead in maintaining and managing an application instal ation and configuration script base across product versions and operating systems is too high. • There is an answer…
Puppet + Self Service Provisioning Benefits Admins, too • 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 chal enges standardized enterprise configuration which can be a huge headache for system administrators 4
Using Puppet with a Self Service Provisioning Solution There are 2 main types of Self Provisioning puppet implementations we frequently see in the field: Infrastructure Configuration Infrastructure Customization
• Shared between (most) VMs in the • Unique depending on the purpose of environment the VM • Configures global OS settings like • Instal s and configures non logging, admin security accounts, NTP infrastructure applications settings, etc. • Subdivided into 2 additional models • Definition extends to instal ing and • ‘a la carte’ Design Pattern configuring infra apps like monitoring • Roles and Profiles Design Pattern agents, backup, etc. 5
Infrastructure Customization Design Patterns “Design Patterns” is the term typical y 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 al ’ and what is ‘Best Practices’ for one organization may not be such for another.
Roles Profiles Design Pattern: Essential y 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 8
‘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 al owed- 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 9
Roles and Profiles Design Pattern (with Self Service Provisioning)
Roles and Profiles Design Pattern 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. VMware vRealize Automation 6.01 screenshot, simple Role Selection list. 11
Roles and Profiles Design Pattern Properties of the Roles and Profiles design pattern:
• Nodes can be members of ONLY 1 GROUP. This Group is cal ed 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- 12
Which Design Pattern Should I use? ‘a la carte’ Attributes Roles and Profiles Attributes
• Provides users with the greatest flexibility • High level of consistency between servers • Can al ow ‘hybrid’ systems (web + db), etc. • Easier to enforce compliance • Prevents ‘role sprawl’ • Less choices for user (depends on your user base if this is good or not) • If systems frequently end up with invalid • If ‘role sprawl’ occurs, you have probably chosen class combinations, you may want to the wrong design pattern. consider Roles and Profiles 13
Self Service Provisioning Task Flow Designs
Self Service Provisioning Task Flow: Autosign Method Prestage VM in Node checks in to Node is autosigned User Orders VM Puppet Node Builds in Node boots and Puppet Enterprise (Policy Based, (RAKE API) Hypervisor runs Puppet Agent Console whitelist, ,or Naïve) Node is assigned group(s) by RAKE Agent Runs and API cal VM is complete For more information on autosigning, see:
Self Service Provisioning Task Flow: REST API Signing Method Prestage VM in Node checks in to User Orders VM Puppet Node Builds in Node boots and Puppet Enterprise HTTP REST API cal (RAKE API) Hypervisor runs Puppet Agent Console to sign CERT Node is assigned group(s) by RAKE Agent Runs and API cal VM is complete For more information on the HTTP REST API and cert signing, see:
Sample RAKE API Commands (Prestage ‘a la carte’) Automation engine wil 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
Sample RAKE API Commands (Prestage ‘Roles and Profiles’) Automation engine wil 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
For more information on RAKE API, see the fol owing:
Machine Lifecycle: Determine how to integrate with SSP Platform VM is ordered Before Machine is After Machine When Machine When machine is From Catalog Cloned/built/ Deployed Is booted Is Edited deleted Prestage Node In Puppet Invoke Agent Clean Up Node And/or Change Node (Delete from (Create and classify/ HTTP REST Sign Groups Puppet) apply groups) INTERNAL OR VMWARE AUTHORIZED USE ONLY 24
Machine Lifecycle: How VMware does it (Before Machine is Built) User Orders VM from catalog During Each State, a vCenter Orchestrator Workflow is cal ed by vCloud Automation Center 25
Key Points • 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 typical y requires an orchestration engine that can be cal ed from the SSP Platform 26