Steer the Sphere

Using Templates with Puppet

Templates let you manage your virtual machines. Working with dedicated virtualization systems differs from desktop virtualization in that parameterization of the individual VMs relies on templates. Creating your own templates for VMware is a science in itself, which is beyond the scope of this article. To make the task a little easier for newcomers, I will touch briefly on possible approaches. Option 1, and the easiest way, is to create and configure a new VM in ESXi. You can then convert the VM into a template in vCenter. Conversion destroys the original VM; whereas it is kept if you clone. Option 2 is to use a virtual machine created in VMware workstation. A converter [6] can be used, but its use is a little quirky. Option 3, which I employ here, is to use a prebuilt appliance.

VMware offers various prebuilt virtual machines [7] on the Solution Exchange website. The comparatively small Ubuntu JeOS [8] (80MB) is fine for this example. To begin, extract the archive to a folder of your choice, and in the vSphere web client, go to the VMs and Templates section.

Then click Actions | Deploy OVF Template to start the wizard for uploading the OVF container. Select the OVF file and click your way through the settings. As when creating a vSphere appliance, also make sure here that the disk uses the thin provision format.

The deployment then occurs in the task list, and the vSphere web client installed in your browser automatically uses the disk image from your computer. Unfortunately, the collection created from the OVF file is still a classic virtual machine at the moment, so you need to fix this in the properties by selecting Actions | Template | Convert to Template .

After completing this step, check that the template was updated successfully. You can do this directly in Puppet – Listing 2 shows sample output that lists the vCenter VM, as well as the newly created template. Templates are lifeless blueprints of virtual machines that need to deployed for use, which the following Puppet command does:

puppet node_VMware create --template \
  /Datacenters/Datacenter/vm/ub1404lts --vmname NewVM --wait-for-boot

puppet node_VMware list
Warning: Cloud Provisioner is deprecated in PE 3.8.
         For more information and recommendations,
         see the release notes documentation here:
         https://docs.puppetlabs.com/pe/3.8/release_notes.html
Notice: Connecting ...
Notice: Connected to 192.168.121.136 as administrator@vsphere.local (API version 4.1)
Notice: Finding all Virtual Machines ... (Started at 09:52:09 AM)
Notice: Control will be returned to you in 10 minutes
        at 10:02 AM if locating is unfinished.
Locating: 100%     |oooooooooooooooooooooooooooooooooooooo|    Time: 00:00:00
Notice: Complete
/Datacenters/Datacenter/vm/MyVCenter
    powerstate: poweredOn
    name: MyVCenter
    hostname: localhost
    InstanceID: 527fb2f6-5877-6ea8-d04b-054660d97131
    ipaddress: 192.168.121.136
    template: false
/Datacenters/Datacenter/vm/ub1404lts
    powerstate: poweredOff
    name: ub1404lts
    hostname: --------
    InstanceID: 503c08ca-e63e-60de-f04f-5fe543d07e0a
    ipaddress: ---.---.---.---
    template: true

Keep in mind that the progress bar displayed while processing the command is pure guesswork. Puppet does not receive any feedback from ESXi and thus assumes a worst case running time. Puppet does not detect the boot process of the extremely lean Ubuntu because the VM does not advertise its presence adequately over the network. However, it is irrelevant in this case; if the boot attempt fails, you can us the puppet node_VMware list command again to make sure the new VM has appeared. Alternatively, you can log in to the new VM in the vSphere web console as root /root .

Virtual machines can be started, switched off, and terminated using Puppet. The commands for this are as follows:

puppet node_VMware start
puppet node_VMware stop
puppet node_VMware terminate

Note that terminate kills the virtual machine and wipes its image from the ESXi instance's non-volatile memory. This operation is – obviously – irreversible.

Final Adjustments

At this point, your work is done: The virtual machine created by Puppet is a normal Linux system, which is waiting for Puppet clients to be installed and configuration options to be assigned.

Smart administrators rely on shell scripts or management applications written in high-level languages from here on out. The new VM is easiest to identify if you assign a randomly generated name to it. Based on the IP address output by list, you can then copy Puppet to the VM.

For reasons of completeness, note that there is a risk of overcommitments here. If you run ESXi on a machine with 10GB of RAM, you cannot offer your flock of VMs 12GB or even 16GB of RAM total without expecting problems. In practical applications, this will tend not to work well because the VMs will force the host to start swapping, resulting in loss of performance.

Conclusions

The ESX solution presented here has its appeal; unfortunately, an ESX installation is typically limited to the resources available on the ESX host. For eCommerce and similar applications, this behavior is risky, because sudden traffic spikes could lead to huge order increases, which could cause major damage to your reputation if not handled prudently. Fortunately, Puppet can link up to classical cloud providers that provide their customers with almost unlimited computer resources – if you are willing and able to pay the price. Managing Puppet in operations with Google Compute Engine (GCE) or AWS is, on the whole, very similar to VMware, but be sure to set an upper cost threshold: A Puppet script that goes wild can cause immense financial damage in operations that rely on Amazon, GCE, or similar services, because you pay for resources per minute.

Attempting to cover the basic load with virtual machines is an economic mistake: Cloud providers can never compete with local hardware, because the lease rates for instances need to consider the costs of providing a reserve. Amazon EC2 and GCE are, however, perfectly suited to cover a short-term load peak. VMware is certainly not cheap, and it only plays to its strengths if a company needs to support multiple clients at the same time. Coverage of peak loads is achieved in this case without incurring costs simply by assigning additional resources of the in-house server.