Like many things at Puppet Labs, the idea for a Deployment Guide for Puppet Enterprise came from our users. By the time I joined the Puppet Labs docs team, most of the heavy lifting of documenting the features and functions of Puppet Enterprise had already been done by documentation wunderkind, Nick Fagerlund. But we were still hearing from users that they needed something to help them start the job of incorporating Puppet Enterprise into their IT ecosystems. A manual is all fine and good when you have a task you’re trying to complete, they told us, but what if you don’t know what tasks you need to do and when you should do them?

It’s a little bit like when you rent a beach house and the kids immediately find a 1,000 piece puzzle in the closet, but there’s no box to show you what the puzzle looks like when it’s done. With a puzzle, you know what to do next: you dump out all the pieces on the coffee table and start looking for the edges and the corners. To a new user, Puppet Enterprise can be a bit of a puzzle without a box. The manual can tell you the procedures and show you the shape of the pieces, but the Deployment Guide is there to show you what it looks like when it’s all put together by helping you find the edges and the corners.

To create the Guide, I started by brainstorming a rough outline, dividing the project of deployment into logical chunks. But to get that outline filled in, I had to turn to the brain-trust that is our Professional Services and Support departments. I was lucky to have folks with collective decades of experience deploying Puppet Enterprise in all sorts of different enterprises right there in the northern half of our offices. With the assistance of Nigel Kersten, our CTO, I identified subject-matter experts in various aspects of a Puppet Enterprise deployment. And then I started in on the task that defines much of a tech writer’s day: hounding people until they give up their knowledge. After 12 years or so in this game, my nagging skills are — dare I say — fairly advanced since I understand the stick and I understand the carrot. Especially the carrot (in Portland, this is usually beer or coffee, but sometimes an actual carrot; there are lots of vegetarians here). In fairly short order, I had amassed a very large pile of information, tips, tricks and advice.

This led to a new problem: our Professional Service Engineers and Support staff are opinionated people, and now I had a big pile of opinions, not all of which necessarily agreed with one another. How would I choose what to put in the Guide as the best practice? Admittedly, I flailed about on this question for some time. Like any good piece of software, Puppet Enterprise gives you a number of different ways to complete a given task. Add to that the varying skills and knowledge of Puppet Enterprise users, and the incredible variety of enterprises where it gets deployed, and I found myself neck-deep in some pretty murky water.

Read the rest of this entry »

The “User Growth Team,” while not an entirely new concept, has been recently popularized by some articles on Facebook. This team works somewhat out-of-band of traditional marketing, product, and business cycles to do whatever it takes to grow the member base. More details of this can be found in these threads on Quora.

I’ve always thought of DevOps as having a similar mandate, but being more of the “Internal User Growth Team,” where users are employees and growth means performance, not volume. The team does what it takes to make the company and its employees work better, typically achieving these goals with code. The current DevOps focus of merging software development and operations places an emphasis on automation and transparency, two characteristics that certainly work towards these improvement goals. But unless your company is in a hyper-growth phase (where you are always behind), the DevOps team is going to hit diminishing returns in traditional operations work. Can we apply the lessons learned to the other areas of the organization? By following the data, we find many opportunities for DevOps to expand its mandate.

Read the rest of this entry »

Here at Puppet Labs, we’re proud to make software that helps free people from mindless, repetitive fire-fighting work so that they can focus on the important and interesting aspects of their job. But the same attributes of Puppet Enterprise that make it such a powerful tool—its ability to handle diverse environments, the number of components and the complexity of their interactions—can make it incredibly difficult to develop for. Add to this the fact that Puppet Enterprise’s power as a system tool can make even minor bugs potentially very destructive, and it’s easy to see why our team needs a robust environment for developing and testing.

For all the progress that has been made in software development, the unpleasant truth is that a great deal of software development and testing is done in fragile, unrealistic environments, often directly on developer machines. For many reasons, this approach (or lack of one) would never have worked for developing Puppet Enterprise. Apart from the fact that this would have cluttered (and potentially clobbered) developer machines, Puppet Enterprise is a complex and system-critical application, and lack of a sufficient development environment could allow bugs to lurk unnoticed.

What, then, were the specific requirements for a Puppet Enterprise development environment?

Read the rest of this entry »

In the wake of recent events on the East Coast of the United States, disaster recovery (DR) planning has reared its head again. Of course, it’s a bad time to think about disaster recovery right after an event with such a large impact. However, it’s even worse to never think about it.

Prior to working at Puppet Labs, I spent a lot of time on disaster recovery. For nearly two years, I led a team designing multi-site replication, creating reference architectures for availability and recovery, and selling our business partners on disaster recovery investments. This was for one of the top performing business units at a Fortune 100 company with seven and eight figure budgets for DR.

Disaster recovery is a huge proposition. It’s costly, time consuming, difficult to test correctly and often the first thing cut when doing budget reviews. DR planning is also never complete. You evolve. You change. Your plans need to as well.

The starting points for DR planning can be difficult to find. Infrastructure engineers often jump to technical solutions. Before you figure out the newest wizbang in storage replication technologies and failover, take a step back.

Read the rest of this entry »

For our final PuppetConf Preview, we’ve got Jesse Newland from GitHub talking about his upcoming presentation. If you can’t make it to PuppetConf, be sure to sign up for live video streaming of two of the large rooms. If you are out in San Francisco for the conference, GitHub is sponsoring a drink-up on Friday evening.

Jesse Newland from GitHub

Puppet Labs: Tell me a little about yourself and your technical background.

Jesse: I started doing sysadmin work on the student newspaper at the University of Georgia, where I learned all the good and bad things about system administration. I learned how to take down production sites on accident, and how to break and fix people’s desktops. I figured out a lot of anti-patterns for how to manage large infrastructure, and that’s where I started the search for utilities and tools to manage large infrastructure. I started more as an administrator than a developer, and as I came across more complex problems I started trying to work them out in Perl and C.

After that I started working at LexBlog, a company that does blogs for lawyers. So at that point I started really owning my skills in terms of web infrastructure. I worked at a company called Rails Machine, which is a Ruby on Rails web host. And at that job I honed my Ruby skills, and at that job I wrote some code and started actually using Puppet in production at the job. We had a very specific need for configuration management, and it pushed me into writing a Ruby DSL for Puppet before there was an official Ruby DSL for Puppet. It was a project called Moonshine, and it’s largely infamous in the Puppet community. It did a lot of of things very differently from how Puppet’s Ruby DSL did things, and a lot of things differently from how it might make sense for a lot of people who use Puppet as their primary tool. Moonshine was written for people that didn’t understand Puppet, for people that understood Ruby on Rails, so they could make subtle changes from a standardized set of configuration that would be easy for them to understand and easy for them to apply and work with.

And from there, I moved to GitHub, and continue to use Puppet as my primary tool.

Puppet Labs: Could you elaborate on how you use Puppet as your primary tool?

Read the rest of this entry »

Ever wish you could just tweak a single setting in an existing INI-style configuration file without having to manage the whole file—without mastering the intricacies of Augeas? Now you can, thanks to the new inifile module.

Read the rest of this entry »

PuppetConf 2012 is 3 days away! While we wish everyone could make it, we know it’s not always possible to get the time off work. In an effort to provide VIP access, we’ll be streaming live video of the two main rooms, thanks to our streaming sponsor and provider Ooyala.

Sign up for live video streaming

Read the rest of this entry »

One of the new projects that we at Puppet Labs are excited about right now is PuppetDB, our new “data warehouse” for managing storage and retrieval of all platform-generated data. (Version 1.0 of PuppetDB was just released! If you haven’t checked it out yet, have a look at Nick Lewis’ blog post or the PuppetDB documentation.) Currently, it offers a huge performance improvement for exported and collected resources, as well as several other great features.

Read the rest of this entry »

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.

Read the rest of this entry »

Google Compute Engine (GCE) was announced at Google I/O 2012. Google Compute offers high performance Ubuntu and CentOS systems backed by KVM at Google scale. As part of the announcement we extended Puppet Cloud Provisioner to provide support for deploying compute resource into GCE. This module delivers those Puppet Face extensions as a plugin to Cloud Provisioner.

Installing the module

On a machine where you have Puppet and Puppet Cloud Provisioner installed use the Puppet module tool to install the node_gce module from the Puppet Forge. The Learning Puppet VM is a great environment start using the node_gce module. You will also need to sign up for a Preview account to for Google Compute Engine.

From the command line issue the following command to install the module:

puppet module install puppetlabs-node_gce

This will download and install the module and the dependencies from the Puppet Forge to the appropriate module path.

Preparing to install into /etc/puppet/modules ...
Downloading from http://forge.puppetlabs.com ...
Installing -- do not interrupt ...
/etc/puppet/modules
└─┬ puppetlabs-node_gce (v0.0.1)
  ├── puppetlabs-lib_puppet (v0.0.1)
  └── puppetlabs-pe_gem (v0.0.1)

The Google Compute Engine module includes a Puppet manifest that install the Puppet Face in the proper place, and generates a script for building a credentials file. We will use Puppet to apply to the manifest locally.

puppet apply /etc/puppet/modules/node_gce/tests/init.pp

By default, init.pp manifests only install the minimal components. The optional manifest below resolves the following warning messages, but it has additional build dependencies to compile JSON.

Faraday: you may want to install system_timer for reliable timeouts
[WARNING] MultiJson is using the default adapter (ok_json). We recommend loading a different JSON library to improve performance.
 
puppet apply /etc/puppet/modules/node_gce/tests/optional.pp

Next we need to setup our GCE credentials. Once you have received confirmation of your GCE preview account you will need to enable Google Compute Engine under Google API Services. Once you have enabled GCE and created a project, go to API access menu and create a new Client ID for installed applications:

Next, execute the generated credentials script:

/tmp/build_gce_credentials

Copy the generated link into your browser and use the authorization code to complete the credentials file. The script will ask for a file to store your credentials. The node_gce Face expects to find those credentials in ~/.fog.

Enter file for storing OAuth2 credentials [/tmp/oauth2_credentials.yml]: ~/.fog
Storing credentials information in [~/.fog]...

Example ~/.fog:

:gce:
  :client_id: "52313212-idasf921.apps.googleusercontent.com"
  :client_secret: "ida8214kdasfsd93"
  :authorization_code: "sfas1/daf9123123kjfasfojdjsfk213213"
  :refresh_token: "dsfas9123kdsfaj892sadkfa"

Using the node_gce Face

Before creating any Google Compute Nodes, we need to upload SSH keys in order to have access to any new systems created by cloud provisioner. SSH keys can be added to the project via add_metadata action, along with the project id, username, and path to the SSH public key file.

$ puppet node_gce add_metadata --project=puppetlabs.com:gce --user='paul' --sshkey=~/.ssh/paul.rsa.pub

This process can be repeated for multiple users to grant them SSH access to systems under multiple projects. New keys will also distribute to existing systems in the same project, but the process will take time to propagate through the environment (about 60 seconds). In Google Compute, SSH keys are associated with a non-root user account with sudo access, and they are stored in per project metadata ‘sshKeys’ value. The SSH key for each user is separated by newlines, and can be listed by executing metadata action and providing the appropriate project:

$ puppet node_gce metadata --project=puppetlabs.com:gce
{
 "kind": "compute#project",
…
 "commonInstanceMetadata": {
  "kind": "compute#metadata",
  "items": [
   {
    "key": "sshKeys",
    "value": "paul:ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAg...",
   }
  ]
 },

At this point, we can create new compute instances via the create action. Google compute allows users to specify unique hostnames as long they are unique per project. The machine-type indicates the size of system which defaults to n1-standard-1. (For the public preview, Google only made *-d type system available, so specify n1-standard-1d). Zone indicates the preference for the region where the system should be created, which defaults to us-central1-a. See the Google Compute documentation for more information about machine-type and zone.

$ puppet node_gce create --name=demo1 --project=puppetlabs.com:gce --machine-type=n1-standard-2 --zone=us-east1-a
{
 "kind": "compute#instance",
 "id": "12920446812432197392",
 "selfLink": "https://www.googleapis.com/compute/v1beta12/projects/puppetlabs.com:gce/instances/demo1",
 "image": "https://www.googleapis.com/compute/v1beta12/projects/google/images/ubuntu-12-04-v20120621",
 "machineType": "https://www.googleapis.com/compute/v1beta12/projects/puppetlabs.com:gce/machine-types/n1-standard-2",
 "status": "PROVISIONING",
 "zone": "https://www.googleapis.com/compute/v1beta12/projects/puppetlabs.com:gce/zones/us-east1-a",
 "networkInterfaces": [
  {
   "kind": "compute#networkInterface",
   "name": "nic0",
   "network": "https://www.googleapis.com/compute/v1beta12/projects/puppetlabs.com:gce/networks/default",
   "networkIP": "10.240.20.171",
   "accessConfigs": [
    {
     "kind": "compute#accessConfig",
     "name": "External NAT",
     "type": "ONE_TO_ONE_NAT",
     "natIP": "173.255.112.192"
    }
   ]
…

The new node status will be “provisioning” initially, and we can use the list action to check when the system transitions to “running”:

$ puppet node_gce list --project=puppetlabs.com:gce

Once the new node is in the running state, we can connect to the system via ssh to its external NAT IP.

$ ssh -i ~/.ssh/private.rsa paul@173.255.112.192

When we are done with the instance simply destroy it via the terminate action:

$ puppet node_gce terminate --project=puppetlabs.com:raiden --name=demo1   
{
 "kind": "compute#operation",
 "id": "12920446812432197392",
 "selfLink": "https://www.googleapis.com/compute/v1beta12/projects/puppetlabs.com:gce/operations/operation-1341328670190-4c3ee6ae99b90-444a5700",
 "name": "operation-1341328670190-4c3ee6ae99b90-444a5700",
 "targetLink": "https://www.googleapis.com/compute/v1beta12/projects/puppetlabs.com:gce/instances/demo1",
 "targetId": "12920446812432197392",
 "status": "DONE",
 "user": "paul@puppetlabs.com",
 "progress": 100,
 "insertTime": "2012-07-03T15:17:50.190",
 "startTime": "2012-07-03T15:17:50.356",
 "endTime": "2012-07-03T15:17:58.248",
 "operationType": "delete"
}

Conclusion

Our initial Cloud Provisioner enables you to quickly get started deploying workloads into Google Compute Engine Environments. Next up, we’ll demonstrate bootstrapping a QA environment in Google Compute Engine using Puppet Enterprise.

Learn More

• puppetlabs/node_gce
• Attend the Puppet/GCE webinar – Tuesday at 11 am PT
• Google Compute Engine Solutions Page
• Previous Modules of the Week