Puppet Blog - Page 8 – Tools & Integrations

A few weeks ago, I had the honor of co-presenting at the Bay Area Juniper Users Group (BAJUG), which meets once a quarter in Sunnyvale, CA. Jeremy Schulman from Juniper Networks invited me to co-present with him on the Puppet for Junos OS solution, which became available in February. Haven’t heard about this networking automation solution before this blog? I’ll explain more, but first, I want to briefly summarize my experience at BAJUG.

I really loved the format of the user group. It kicked off with a one-hour keynote presentation from Jeremy on the Puppet for Junos OS solution, which was followed by a series of 10-minute lightning talks. Those talks were given by network guys from Facebook, IETF, Zygna, and more. The event ended with a free-form social. It was a sold out event, attended by about 250 people. Here’s a photograph I took right before my talk.

Disclaimer: This is a repost from Nan’s personal blog. The opinions expressed herein are Nan’s personal opinions and do not necessarily represent those of VMware.

Last week, we released a set of open source Puppet modules for managing VMware cloud environments, specifically VMware vCenter Server Appliance 5.1 and VMware vCloud Network and Security 5.1 (vCNS, previously known as vShield). They provide a framework for managing resources within vCenter and vCNS via Puppet (read Nick Weaver’s blog for more information).

In a previous MOTW, I covered what problem this module solves and addressed a very simple workflow for using the module to manage VMware Tools.

This time, I’m going to dive into how the module is structured and explore some of the more advanced things you can do with it.

A long time ago (well, June of this year) the Puppet Forge was running without a leader. In my role as community manager, I saw the Forge as having this awesome potential to be the resource for user-generated content surrounding the Puppet community. I knew it was getting more attention, but that was mostly anecdotal. My next step was to find some data that could tell a good story.

Puppet Modules are often the first way people learn and start using Puppet. We’ve had our Puppet Forge for a while, but I didn’t feel like I knew a lot about it. When we were getting ready to interview Product Owners for the Puppet Forge and Modules, I decided I wanted to know more to help me prepare for the interview, and maybe give me some insight into usage patterns that I hadn’t thought about.

Like any geek, I love data. I knew we had all sorts of data in our module download logs, but we had not ever really taken the time to transform that data into awesome information. I started with simple awk/sed/grep to find basic information, like what modules were popular. This worked for a time, but then I wanted to know modules by name, find popular authors, and do things like ignore version number changes.

Google Compute Engine (GCE) is a service offering from Google that allows users to provision virtual machine instances that run on Google’s infrastructure. The one thing that really stands out about this service compared to similar offerings is how fast it is. Machine instances generally take seconds, not minutes, to spin up.

The GCE API allows users to create all of the resources needed to dynamically model application stacks, including: virtual machine instances, networks, firewalls, and persistent disks. It also allows you to specify a lot of the characteristics of a virtual machine instance like the image that should be used, and how much memory and CPU to allocate to that instance.

What this API can’t do is tell a machine how it should be configured. There is no way to say: “Use this image as a starting place, and then configure yourself to be a mysql database.” This is where Puppet comes in. It can be used with GCE in order to configure the roles that should be assigned to created instances. Puppet can also be used to perform ongoing management of those instances.

This blog will take the concept one step further, explaining not only how Puppet can be used to assign roles to compute instances, but also how Puppet can be used to model the management of all of the compute objects in GCE that are used to create an application stack.

This week’s Module of the Week is a guest post from Carlos Sanchez from MaestroDev.

The maven module allows Puppet users to install and configure Apache Maven, the build and project management tool, as well as easily use dependencies from Maven repositories.

If you use Maven repositories to store the artifacts resulting from your development process, whether you use Maven, Ivy, Gradle or any other tool capable of pushing builds to Maven repositories, this module defines a new maven type that will let you deploy those artifacts into any Puppet managed server. For instance, you can deploy WAR files directly from your Maven repository by just using their groupId, artifactId and version, bridging development and provisioning without any extra steps or packaging like RPMs or debs.

The maven type allows you to easily provision servers during development by using SNAPSHOT versions—using the latest build for provisioning. Together with a CI tool, this enables you to always keep your development servers up to date.

I was O’Reilly’s Velocity conference back in June, giving a talk on hacking Puppet, and Puppet’s configuration language came up a lot. Most people love the language and find it the simplest way of expressing their configurations, but some are frustrated by how simple it is and wish they had a full Turing-complete language like Ruby for specification. I thought it would be worthwhile to discuss why Puppet has a custom language, and dive into some of the benefits and costs.