The blog Quick Start Guide: Application Director and Puppet Enterprise Integration has details about getting started on using the integration between Puppet Master and VMware vCloud Application Director server. That's what you should see if you are just looking at functional details and how to use this feature. This blog post goes into some of the technical details (behind-the-scenes) on how AppDir server and Puppet Master work together towards a common goal of provisioning any complex multi-machine (multi-tier) workload.
Disclaimer
Details presented in this blog are subject to change without notice. This post confers to no rights and provided 'as is'. This is not an official post from VMware - this is my personal blog with no warranties whatsoever!
Content
In Puppet, the content is puppet modules mainly containing the puppet classes and user defined resources. From now, I'll just use 'puppet class' to refer to both puppet classes and user defined resources. In AppDir, the relevant type of content (aka catalog in AppDir terms) is the 'service version'. Within AppDir, each unit of puppet content (class or user defined resource) is modeled as 'service version'. The version part of the service is same as the version of the puppet module owning the corresponding puppet class. For example if you import 'mysql::client' puppet class from mysql module version 1.2, it will create a service version named 'Puppet mysql client' with version '1.2'. If you import the same class again, (as of AppDir 6.0) the import command will ignore this puppet class stating the service version already exists. If you import the same class but of a different mysql module version, say 1.3, it will create a new service version with same name but with version '1.3'.
The service versions representing puppet content have few unique characteristics worth calling out
- They don't have actions (aka scripts) because AppDir will delegate their handling to 'puppet master' and it doesn't make sense to have actions at the level of each service version
- Some restrictions exist on what can be modified. For instance, you cannot add/remove properties or change name of existing property. You could however change description and change property metadata like overridable, binding info, secured etc. You can also change service level metadata tags, supported OSes etc.
- Names all start with 'Puppet' prefix and namespace separator (::) is replaced with a space. Its recommended that you don't change the prefix - just so its easier to identify a service as representing a puppet class. However things won't break if you change the prefix!
- Inclusion of any puppet based service version in a blueprint node automatically installs, configures puppet agent on vms for that node and registers with puppet master
Puppet Master Registration
When you register Puppet Master as explained at Create a Solution Instance. Following is what happens.
Key point is AppDir server uses MCO (command-line tool) to issue a custom command (named testconnection) on the AppDir specific MC agent (named appdintegn). Following is a sample MCO client-side configuration file that's dynamically generated based on puppet master solution instance details.
plugin.activemq.pool.size = 1
plugin.activemq.pool.1.ssl.cert = /private/var/folders/z4/m40ng7hj5czfr80j6vnbmvwc0000gn/T/5_-1247675466/Puppet_Agent-REGISTER_AGENT/.mcollective/.credentials/certs/vmware-appd.pem
loglevel = debug
securityprovider = ssl
plugin.activemq.pool.1.password = GG0Eqi2LXTOAWZpAtMfo
main_collective = mcollective
plugin.ssl_serializer = yaml
plugin.activemq.pool.1.ssl.ca = /private/var/folders/z4/m40ng7hj5czfr80j6vnbmvwc0000gn/T/5_-1247675466/Puppet_Agent-REGISTER_AGENT/.mcollective/.credentials/certs/ca_cert.pem
plugin.activemq.pool.1.port = 61613
plugin.activemq.pool.1.host = 10.64.63.15
direct_addressing = 1
plugin.activemq.max_reconnect_attempts = 10
plugin.activemq.pool.1.ssl = true
collectives = mcollective
libdir = /usr/libexec/mcollective:/opt/puppet/libexec/mcollective:/private/var/folders/z4/m40ng7hj5czfr80j6vnbmvwc0000gn/T/5_-1247675466/Puppet_Agent-REGISTER_AGENT/.mcollective/plugins
plugin.activemq.pool.1.ssl.key = /private/var/folders/z4/m40ng7hj5czfr80j6vnbmvwc0000gn/T/5_-1247675466/Puppet_Agent-REGISTER_AGENT/.mcollective/.credentials/private_keys/vmware-appd.pem
plugin.ssl_client_private = /private/var/folders/z4/m40ng7hj5czfr80j6vnbmvwc0000gn/T/5_-1247675466/Puppet_Agent-REGISTER_AGENT/.mcollective/.credentials/private_keys/vmware-appd.pem
plugin.ssl_client_public = /private/var/folders/z4/m40ng7hj5czfr80j6vnbmvwc0000gn/T/5_-1247675466/Puppet_Agent-REGISTER_AGENT/.mcollective/.credentials/certs/vmware-appd.pem
plugin.ssl_server_public = /private/var/folders/z4/m40ng7hj5czfr80j6vnbmvwc0000gn/T/5_-1247675466/Puppet_Agent-REGISTER_AGENT/.mcollective/.credentials/certs/mc_servers_shared_cert.pem
connector = activemq
plugin.activemq.connect_timeout = 30
plugin.activemq.timeout = 60
logfile = /private/var/folders/z4/m40ng7hj5czfr80j6vnbmvwc0000gn/T/5_-1247675466/Puppet_Agent-REGISTER_AGENT/.mcollective/client.log
plugin.activemq.pool.1.user = mcollective
For someone who understand MCO, this should give a pretty good idea on how the MCollective needs to be configured on the puppet master for a successful integration. The good news is when you install 'Puppet Enterprise' the out-of-the-box configuration (at-least as of Puppet Enterprise 3.0.1) is exactly in-sync with above config file, so you don't need to do anything special!
Actual Provisioning
When you deploy a blueprint that's using the puppet based services, following picture depicts the high-level flow.
- AppDir server issues a request to provision all the required VMs based on application blueprint being provisioned
- The actual cloud provider creates the VMs as per the specified compute, network and storage configuration
- AppDir server installs and configures 'Puppet Agent' by running a script that's hosted by 'AppDir Agent'. This happens for each vm (but not for vms that don't have any puppet based service included in them as part of blueprint design)
- Puppet agent automatically sends a CSR (certificate signing request) to the correct puppet master
- AppDir server using MCO approves the outstanding CSR. Specifically it calls the 'registernode' command of 'appdintegn' MCollective agent
- AppDir server also configures the node manifest according to the structure of blueprint node. Again using an mco command in 'appdintegn' MC agent
- AppDir server kicks off a puppet agent by running a script hosted by 'AppDir agent'
- Puppet agent now realizes its CSR is approved, gets the configured node definition/manifest, applies all the changes and sends the status report to puppet master. AppDir agent grabs the report to send it to AppDir server
The execution plan shown in the AppDir UI reveals lot of these details and much more. The screenshot is in the blog post Quick Start Guide: Application Director and Puppet Enterprise Integration .