Getting started with Puppet in Skytap

This article describes how to configure a template in Skytap so that each time you create an environment, your VMs connect to a primary Puppet master to receive their configuration.

Contents

Before you begin

This example requires the following:

  • The Skytap environment has network access to your Puppet master.

    (If your Puppet master is secured behind a firewall, you must set up a VPN connection between your corporate network and Skytap. See Creating a VPN connection.)

  • Puppet Enterprise 2015.2
  • The Puppet master is configured as follows:
    • Certificate Authority Master
    • Uses DNS names to sign certificates.
    • Naïve auto signing is enabled.
  • Ubuntu 14.04 is the guest OS on the VMs.

NOTE: If you’re using a different version of Puppet or a different guest OS, some of the commands and configuration settings may differ.

To access Skytap VMs, click credentials to enter the stored credentials. For more information, see Storing VM credentials.

Configuring Skytap templates

This section provides a high-level overview of the configuration process. Each step is described in greater detail below.

VM setup

Use these steps to configure each VM in the environment:

  1. Install curl and jq.

    The agent configuration script in this tutorial makes a call to the Skytap VM metadata service using curl. It then parses the JSON response using jq. You can use other tools; just make the appropriate changes to the script. For example, in Windows, you can do everything with PowerShell.

  2. Install the Puppet agent

    To reduce VM startup time, pre-install the Puppet agent and dynamically configure it at startup time.

  3. Set up the startup script

    The startup script searches for configuration metadata you provide on the environment and uses it to configure the Puppet agent.

Environment setup

After you set up the VMs, save the environment as a template. Every time you create an environment from the template, the VMs connect to the Puppet master and get their required configuration.

  1. Enter environment metadata for the Puppet configuration.
  2. Enable NAT (optional).
  3. Save the environment as a template.

VM setup

Prerequisite applications

Repeat these steps for each VM in the environment:

  1. Install curl and jq with the following commands:

     apt-get install curl
    
     apt-get install jq
    
  2. Install the Puppet agent:

     curl –k https://<MyPuppetMaster>:8140/packages/current/install.bash | sudo bash
    

Alternately, you can move the install package to the VM using the Assets page in Skytap.

  1. Add the following script to /etc/init.d. Make sure the script is owned by root. (chown root:root <ScriptName>) and that it can be executed (chmod 755 <ScriptName>).

    (see Startup script)

    If you add the script to a different directory, you’ll need to run a command similar to this:

    ln –s <ScriptPath>/<ScriptName> /etc/init.d

  2. Set the script to run at startup:

    update-rc.d puppetConfig.sh start 20 2 3 4 5 .

Environment setup

  1. On the environment details page, click Metadata in the environment settings. metadata

    The environment User Data page loads. user data

  2. Add the following information to the user data field

    Name Description Example
    PuppetMaster FQDN of the Puppet master PuppetMaster=pe-master.puppet.example
    PuppetCertname Prefix for the node names PuppetCertname=skytap-vm
    PuppetHost IP address, FQDN, and Aliases for the Puppet master PuppetHost=10.0.4.1 pe-master.puppet.example pe-master

    For example:

     #Puppet Agent Configuration
     PuppetMaster=pe-master.puppet.example
     PuppetCertname=skytap-vmPuppetHost=10.0.4.1 pe-master.puppet.example pe-master
    

    The script is currently limited to only this configuration data and applies the same configuration to all VMs in the environment. You could extend the script it to pull additional configuration data. Also, if you want to override the environment metadata at the individual VM level, you can. Each VM also has metadata. You could extend the script to look at the VM metadata first and then the environment data if it didn’t find the required configuration information.

  3. If the environment needs to communicate with devices outside of the environment, you may need to enable NAT. For more information, see Using Network Address Translation (NAT) to avoid IP address conflicts
  4. Create a copy of the environment and test it.
  5. If everything is working properly, save the original environment as a template.

Creating environments from the configured template

When you create an environment from the template, each VM starts, configures itself, and connects to the Puppet master. Depending on the node facts and which node group classifiers you use, the corresponding modules are pushed down to the nodes, configured as expected, and ready for use.

The following script configures a Puppet master with a few nodes from different environments.

Each node name follows the convention: skytap-vm-<VM ID>.

Startup script

#!/bin/sh
#
### BEGIN INIT INFO
# Provides: puppetConfig.sh
# Required-Start: $all
# Required-Stop: $all
# Default-Start: 2 3 4 5
# Default-Stop:
# Short-Description: Configures Puppet Agent running on a VM in Skytap
# Description: Configures Puppet Agent running on a VM in Skytap
### END INIT INFO
#
# This script configures the Puppet Agent on the VM.
# It reads data from the environment metadata section, including
# the FQDN and hosts file entry of the Puppet Master
# and the certname prefix to use for the agent.
# The script appends the VM ID to the certname prefix to
# ensure uniqueness.
#
rm -f /tmp/ConfigData_*
#
# Issue a call to the Skytap API to get the configuration
# metadata for this VM and save it in in an intermediate file
#
curl -s -X GET "http://gw/skytap" -H "Content-Type: application/json" -H "Accept: application/json" &gt; /tmp/ConfigData_$$
#
# use the jq command line JSON parser along with some sed pattern
# matching and text substitution to extract the VM ID from the
# metadata retrieved from the Skytap API
#
vmID=`cat /tmp/ConfigData_$$ | /usr/bin/jq .id | sed s/\"//g`
#
# remove any previous intermediate UserData file that might be left
# from a previous run of this script
#
rm -f /tmp/EnvironmentUserData_*
#
# use the jq command line JSON parser along with some sed pattern
# matching and text substitution to extract the UserData field
# from the VM Metadata
#
cat /tmp/ConfigData_* | /usr/bin/jq .configuration_user_data | sed s/\\\\n/\"\\n\"/g &gt; /tmp/EnvironmentUserData_$$
#
# Now use some grep, awk and sed pattern matching and text parsing
# to extract the PuppetMaster and Certname designations from the
# Environment metadata
#
puppetMaster=`grep PuppetMaster /tmp/EnvironmentUserData_$$ | awk -F= '{print $2}' | sed s/\"//g`
puppetCertname=`grep PuppetCertname /tmp/EnvironmentUserData_$$ | awk -F= '{print $2}' | sed s/\"//g`
puppetCertname=${puppetCertname}-${vmID}
puppetHost=`grep PuppetHost /tmp/EnvironmentUserData_$$ | awk -F= '{print $2}' | sed s/\"//g`
#
# echo what we found to the boot log
#
echo "Installed Certname:" ${puppetCertname}
echo "PuppetMaster:" ${puppetMaster}
echo "PuppetMasterHosts:" ${puppetHost}
#
# Now update the hosts file and set the server, and certname on
# the Agent and issue a pull
#
if (grep ${puppetMaster} /etc/hosts &gt; /dev/null 2&gt;&amp;1) ; then
echo "Hosts file already up to date"
else
echo ${puppetHost} &gt;&gt; /etc/hosts
fi
sudo puppet config set server ${puppetMaster} --section agent
sudo puppet config set certname ${puppetCertname} --section agent
sudo puppet agent -t
exit 0

Other considerations

There are a few additional items beyond the scope of this article that are worth mentioning.

Node classification

Classifying nodes or setting node environments should be the same for nodes running in Skytap as for nodes running anywhere else in the Puppet environment. You can set up tags and the agent’s Puppet environment as part of the installation step. Alternatively, you can extend the startup script to pull these configuration parameters from the environment or VM user data.

Cleaning up the Puppet master

Skytap environments are ephemeral by design. It’s trivial to create a new Skytap environment from a template, delete it, and create it again. Within Skytap, this has very few consequences. This isn’t the case with Puppet; when you delete the Skytap environment, it orphans the node on the Puppet master. Puppet doesn’t have an automatic method to identify and clean up orphaned nodes; you have to deactivate them manually. Puppet provides different ways for handling orphaned nodes. You can read more about node deactivation to determine what’s right for your situation: https://docs.puppetlabs.com/pe/latest/node_deactivation.html.

Facter data

In a future article, we will show how to extend the Puppet agent’s Facter data with data specific to Skytap. This may be useful when classifying nodes and identifying orphaned nodes that need to be cleaned up.