Puppet Blog - Page 50

Stronger DevOps Culture with Puppet and Vagrant

DevOps is a lot more than configuration management. DevOps is all about developers working more closely with operations to address business needs quickly, while keeping everything stable and running. Formalizing configuration management with a tool like Puppet is a big step towards this collaboration between developers and operations, because the process is formalized, can be version controlled, and offers a single point of truth for the configuration of environments.

Vagrant is another tool to help your organization transition to a DevOps culture. Vagrant also helps improve your entire workflow of using Puppet, improving development and process for both developers and operations.

In this blog post, I’m going to talk about using Vagrant effectively with Puppet, and how it helps your organization work more efficiently in the process. I gave a talk at PuppetConf on advanced Vagrant usage with Puppet, and I’ve written an article for InfoQ on transitioning to a DevOps culture. This blog post will be a mix of both of those topics.

Say Hello to Puppet 3

Hi, I’m Eric Sorenson (eric0 on #puppet IRC), and in June 2012 I moved from being a community member and Puppet administrator in the field, to working at Puppet Labs as the Product Owner for our open source projects. At the time, my first goal was to help get a great release of the next major version of Puppet (code-named “Telly”) shipped to the world, which launched late last month. Now with the release of Puppet 3.0.1 — which addressed and fixed the biggest issues that our awesome community of early-adopters found in the 3.0.0 release — it seemed like a good time to blog from the rooftops.

I’m new to Puppet Labs, but I have been running Puppet in large-scale production operations since 2009 and, somewhat naïvely, felt like I had a good idea of what Puppet 3 was supposed to look like. There had been, after all, a few dozen bugs in Redmine over the past couple of years in which the “Target Release” field I’d seen James or Nigel set to “Telly” … it was going to fix all the bad behavior we’d all reported over the years, right? Well, not exactly.

The tough thing about major releases of popular products is that the burden of expectations becomes so great, there’s no way reality can measure up. In some cases (The Phantom Menace, Guns n’ Roses “Chinese Democracy”) when the release does come, it’s universally panned on its own merits; other times, the release might have been fantastic if it had come when it was promised, but the timing was such that it had already gone stale (Duke Nukem Forever).

Mapping the Puppet Forge

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.

Building Application Stacks with Puppet

Managing Google Compute Engine Instances with Puppet

Puppet is an IT automation language that has traditionally been used to configure individual nodes. Puppet’s declarative language and dependency model is also suitable for describing entire application stacks on top of public cloud offerings.

This post will explain how Puppet can be used to model resources through Google Compute Engine’s API in order to describe application stacks as reusable and composable configuration files.

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.

Module of the Week: maestrodev/maven – Maven repository artifact downloads

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

Purpose Manage Apache Maven installation and download artifacts from Maven repositories
Module maestrodev/maven
Puppet Version 2.7+
Platforms RHEL5, RHEL6

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.