Puppet Camp Atlanta is only a few weeks away! If you’re in the Atlanta area or nearby region, this event is for you! Puppet Camps are local, 1-day events that feature a mix Puppet Labs engineers, local speakers, and unconference talks generated by the audience. We’d like to thank our Sponsor MomentumSI for helping make Puppet Camp Atlanta possible!

Registration is now open and the nearly-finalized schedule is available.

We hope you’ll join us for Puppet Camp Atlanta, the first of many new Puppet Camps sprouting up worldwide.

Check out the tentative schedule below—much of the afternoon will be devoted to unconference talks (ie, you can lead the charge on a topic you care about).

*Gary is also teaching the Atlanta Puppet Master course. A ticket to this course is also good for admission to Puppet Camp Atlanta.
Hope to see you there! Register today.

Written in conjunction with Tino Vazquez from the OpenNebula Project, and cross-posted on the OpenNebula blog.

Puppet is used for managing the infrastructure for many IaaS software packages, including Eucalyptus, OpenStack, and OpenNebula. OpenNebula is an IaaS manager which can not only manage a large amount of different virtualization and public cloud platforms, it can also emulate the API’s provided by EC2 and OCCI. It’s great for creating private and public clouds, as well as hybrids of the two.

Puppet Labs (or, more specifically, Ken Barber) has developed a powerful integration between OpenNebula and Puppet. The installation and configuration of OpenNebula be managed with this solution, and a virtualized infrastructure can be provisioned starting from bare metal using only Puppet code. The module for Puppet that integrates with OpenNebula can be downloaded from the Forge here: http://forge.puppetlabs.com/puppetlabs/opennebula

Installation and Configuration

The Puppet module contains several classes, types and providers for managing OpenNebula resources and installing OpenNebula.

The class ‘opennebula::controller’ is used for managing the main controller node for OpenNebula and is a simple class. An example usage would be:

class { "opennebula::controller":
  oneadmin_password => "mypassword",
}

This will configure the necessary parts for the main controller node, applying the necessary password for the primary ‘oneadmin’ user.

The class opennebula::node can be applied to nodes that will act as hypervisors. This class configures the necessary package and SSH authorization that is used by the SSH transfer, information and virtualization driver in OpenNebula.

The class itself really needs to know the location of its master, and uses stored configurations for shipping the necessary SSH keys across:

class { "opennebula::node":
  controller => "one1.mydomain.com",
}

The Sunstone GUI can be remotely managed using the ‘opennebula::sunstone’ class. The module also can manage the EC2 gateway using ‘opennebula::econe’.

Managing OpenNebula Resources

OpenNebula has many elements that can be managed on the command line:

• Hosts
• Images
• Virtual Networks
• Virtual Machines

What’s great about OpenNebula is that the same resources can be managed using their own GUI, namely ‘Sunstone’:

We provide some resource types through the Puppet OpenNebula module that allow managing these elements via Puppet as well. The detailed documentation for each of these is provided in the README file for the module, but let’s talk about one in particular: the onevm resource.

The onevm resource allows you to actually manage a virtual machine as if it was a Puppet resource. An example usage in Puppet would be:

onevm { "db1.vms.cloud.bob.sh":
  memory => "256",
  cpu => 1,
  vcpu => 1,
  os_arch => "x86_64",
  disks => [
    { image => "debian-wheezy-amd64",
      driver => "qcow2",
      target => "vda" }
  ],
  graphics_type => "vnc",
  graphics_listen => "0.0.0.0",
  context => {
    hostname => '$NAME',
    gateway => '$NETWORK[GATEWAY]',
    dns => '$NETWORK[DNS]',
    ip => '$NIC[IP]',
    files => '/var/lib/one/context/init.sh',
    target => "vdb",
  }
}

As you can see, this mirrors all of the options made available via the template when creating virtual machines using the command line or Sunstone GUI in OpenNebula:

Using Puppet provides just another capability for managing OpenNebula. Upon creation, the VM will be created just like any other VM and now appear when running ‘onevm list’ or viewing the list of virtual machines in Sunstone:

Managing Applications End-to-End

An end-to-end example to demonstrate the capabilities of this integration is the deployment of a sample pastie/pastebin application with redundant web servers:

The sample content to build such an infrastructure is located here: http://github.com/kbarber/puppet-onedemo

In this demo content we deploy the IaaS manager OpenNebula, correctly configured and including its dependencies like libvirt. We then use the newly installed virtualization engine to start a virtualized application consisting of web servers behind a load balancer.

Combining OpenNebula and Puppet allows you to achieve a fairly complete end-to-end architecture for rapid deployment within a private cloud infrastructure. The following diagram shows some of the necessary elements in such an end-to-end architecture:

Development Progress

Currently the puppetlabs-opennebula module is OpenNebula 2.2 specific, but we are looking to add OpenNebula 3.0 support once it becomes available in the distributions (such as Debian). If you like the idea of having Puppet manage OpenNebula for installation, configuration or for management we are looking for more code contributors, testers and users.

Bugs can be raised in the Puppet Redmine project for our public modules here.

And the code is available here: https://github.com/puppetlabs/puppetlabs-opennebula

Any help or comments are much appreciated, your feedback will be used to refine the integration and make it more functional. We are confident that this integration adds value to your IaaS and Private Cloud projects, and we hope you enjoy using it as much as we did implementing it.

Additional Resources

• More information on the Puppet/OpenNebula integration, in slides and video.

The Puppet CloudFormation Face integrates Puppet Enterprise (PE) with CloudFormation so that users can reliably create entire Puppet Enterprise “stacks” in Amazon’s EC2 from their workstation.

A “stack” refers to a collection of launched Amazon Web Services (AWS) “resources” that can be specified as a “template” in CloudFormation’s declarative json modeling language. Templates support a wide range of AWS resources, including: EC2 instances, security groups, credentials, as well as a host of other resources.

EC2 meta-data and user data can be associated with AWS resources in a CloudFormation template. This meta-data allows CloudFormation to not only provision EC2 instances, but also to bootstrap those instances into a functioning application stack.

The CloudFormation Face is a command line tool that can use this meta-data to specify all of the required information to bootstrap an entire Puppet Enterprise stack, including: modules to be downloaded from the Puppet Forge, groups to be created in the Enterprise Console, Puppet Agents to be provisioned, as well as security groups and classification information to be associated with those agents.

Pre-requisites

The following things need to be setup before the Puppet CloudFormation Face can be installed:

1. AWS credentials are required. These credentials must be associated with an account that has full administrative rights. Instructions for how to sign up for Amazon Web Services (AWS) can be found here.
2. Requires that a keypair exist within the region in which resources will be launched. This keypair is used to refer to user public keys that can be injected into created EC2 instances. We recommend us-west-1. Remember what region you made a keypair for, you’ll need it later.

Installation

These tools can be easily evaluated with the Learning Puppet VM, or you can follow the manual installation instructions in the README on GitHub.

1. Download the Learning Puppet VM, follow instructions to boot the virtual machine and log-in as root. Note: You may want to ssh into your running Learning Puppet VM for easy copying and pasting.
2. Once logged in, use the following command string to download the CloudFormation Face from the Puppet Forge, unpack it to Puppet’s module path and rename it to cloudformation.

   cd /etc/puppetlabs/puppet/modules && curl http://forge.puppetlabs.com/system/releases/p/puppetlabs/puppetlabs-cloudformation-0.0.2.tar.gz | tar -xz && mv puppetlabs-cloudformation-0.0.2 cloudformation

3. Export the ec2 region you created your keypair for in the prerequisites section.

   example: export EC2_REGION=us-west-1

4. Make sure time on the virtual machine is up to date.

   ntpdate pool.ntp.org

5. CD into the cloudformation directory and edit examples/install.pp to include your AWS credentials and insert your java home. It will look something like this:

     class { 'cloudformation':
       aws_access_key => '< your key here >',
       aws_secret_key => '< your secret key here >',
       java_home => ‘/usr/lib/jvm/jre-1.6.0-openjdk’,
     }

6. Apply the modified manifest:

    	puppet apply examples/install.pp

   This will install the CloudFormation client tools and create the file: bashrc_cfn

7. Source the bashrc_cfn file to set up all of the necessary environment variables.

     	source bashrc_cfn

8. Verify that the CloudFormation client tools were successfully installed and configured by running the following:

   	cfn-describe-stacks

   A return of ‘No Stacks found’, validates that the client tools are correctly configured.

9. Verify that the CloudFormation Face is properly configured by running:

   	puppet help cloudformation deploy

   Basic usage information should be returned.

Creating a Puppet Enterprise environment from scratch

Since puppetlabs-cloudformation can reliably build out fully functional Puppet Enterprise environments, it is an ideal tool for evaluation or experimentation in EC2. Let’s build an example stack.

The ‘puppet cloudformation deploy’ action can be used to build out complete stacks of PE. The command below shows how to build out an prepared Puppet Enterprise evaluation environment. Supply your own ‘keyname’ and ‘stack-name’ to the above command.

	puppet cloudformation deploy \
		--stack-name DemoStack \
		--config config/pedemo.config \
		--disable-rollback \
		--master-type m1.small \
		--keyname

Once the stack has successfully launched, use:

cfn-describe-stacks

and

	cfn-describe-stack-events

to check the current state of this stack.

Once you see the state of CREATE_COMPLETE, you’ll also receive the public dns name of your new Puppet Master. You can open your web browser and browse to https://and log in with the user name cfn_user and cfn_password to visit the Puppet Enterprise Console. Check out the video below to see this in action.

controlling Puppet and invoking agents

With the launch of Puppet Enterprise 2.0, it’s easy to get lost in the scale of what we’ve enabled sysadmins to do. Besides shipping a world-class configuration management tool, we now make it easy to create managed servers from thin air. In addition, we’re providing command line tools that take fresh OS installs directly to production-ready application servers with no manual intervention, monitoring and reporting for when your configuration drifts, and a web interface that allows you to inspect the current state of resources across your entire population—fast.

For all the things that we’ve done with our software, there’s a much longer list of things that we just didn’t have to do thanks to the open source community at large. So, we’d like to acknowledge some of the open source software that have helped make P.E. 2.0 a great product.

Batman

We made the decision early in the development cycle for live management that we wanted to build an application that was as lively and responsive as possible. Our search for an appropriate browser-based-site framework led us to several options, but Batman (who showed up fashionably late to the investigation) impressed us immediately.

Applications written against Batman were reasonably familiar to most of the live management team (including those who had little prior Javascript experience), but the real stars are the hard-working members of the Batman development team. From day one, the core developers were engaged, gracious, and actively involved in helping make our product the best it could be, even as we took Batman down roads they never expected anyone would. Our own Pieter van de Bruggen has made many contributions to Batman’s core.

Fog

When we were building our first pass of cloud provisioning, we began with the single target of Amazon’s EC2 cloud. Fog provided an accessible way to interface with that target (in addition to a number of future targets), so the decision felt fairly obvious up front. After building our first prototype, we discovered we had also built a tool for installing Puppet Enterprise on real hardware with only an SSH connection. With a few small tweaks, it could also work on Rackspace, OpenStack, and a large number of other providers (coming soon, we promise!). Combined with the developer’s responsiveness and guidance, Fog has been an amazing asset to us. At Puppet, Jeff McCune, Kelsey Hightower, Carl Caum, and Pieter van de Bruggen have made many contributions to Fog.

Sinatra

Sinatra’s not exactly an unknown in the Ruby web development community, but it has been fundamental to us in our live management development. With all of our presentation logic hidden away in a lightweight frontend application, we wanted to build the backend against a similarly lightweight framework. Sinatra gave us just the right balance between power and simplicity on a well-known, stable platform.

LESS

Less is a CSS abstraction tool, helping us make the Puppet Enterprise console CSS much lighter and more maintainable.

CoffeeScript

A browser-side language, compiling to Javascript, used extensively throughout live management. Batman.js is written in CoffeeScript.

ActiveMQ

A message queue, used by MCollective to distribute work to your entire infrastructure.

Puppet, Dashboard, MCollective, and Facter

Puppet Enterprise wasn’t developed in a vacuum: the core tools themselves are open source software, and have for years received significant contribution from the community outside our doors.

And so many others…

We don’t have the words or the space to properly say “thank you” to every project whose open source work has helped us reach this release. So let me just say once, to every contributor on every project that’s touched our work: thank you. Your work has not gone unnoticed nor unappreciated, and I hope that our own contributions to open source software can serve to pay the kindness forward.

2011 has been an amazing year, although I always find it a bit awkward living through a prime year. In the startup world, just continuing to survive another year sometimes feels like an accomplishment, but we’ve done so much more than that. Puppet Enterprise has been the spine of 2011 for us, with a first release in February and the 2.0 release in November. We’ve managed to be both broad and deep, with PE running across the majority of server platforms and also providing a few new capabilities in 2.0 that support specific activities like compliance and reducing arbitrary infrastructure variation.

In some ways, the biggest change at Puppet Labs was the shift to being design focused. Our development process has been wrapped around a tight focus on you, our users, and we’re building our plans and stories around who we’re building products for and what problems we’re helping them with. To make sure it’s not just our designers and developers who think in design, everyone at the company was given a copy of The Design of Everyday Things.

Finally, there was the investment at the end of the year, which will be the foundation for our future in many ways. Look for interesting partnership activity with VMware, Cisco, and Google Ventures in 2012, and for our product to grow and develop with their input and customer knowledge.

As interesting and challenging as 2011 was, however, 2012 looks even better. As Greg Lemond said, it never gets easier, you just go faster. We aren’t resting on our laurels—we still wake up scared every day—but there is still far more to do than is already done. Gartner says less than 20% of companies use any kind of server automation, and someone has to help those people. This is especially the case as companies try to adopt new technologies like private clouds or bring in new culture with devops—can you imagine trying to replace traditional infrastructure with self-serve, on-demand provisioning but no server automation? Inconceivable.

Data is a major area we’ll be looking to help people in 2012. Companies have huge amounts of data trapped within their infrastructure and few ways to extract value out of it, and there is a direct relationship between the efficiency and agility of a company and its usage of this data. Companies like New Relic and Nodeable are building businesses around helping people extract meaning from their operations data, and Puppet is one of their critical data sources. It produces vast amounts of data as a natural off-shoot of the work you’re using it for anyway, and we’re working to help you get more value out of that data. We’ve got one customer whose Puppet infrastructure—that’s just Puppet, not the services maintained by Puppet — is producing 750GB of data a day. One one hand, it’s expensive to do much with that volume of data without a clear business driver, but on the other hand, it makes clear how much more you could know about what’s going on in your world.

We like to think of our efforts in this area as Big Data in the Infrastructure. Big Data projects are already a popular way for companies to start using Puppet, but here we’re talking about getting more from your Puppet data, not just managing Hadoop. Puppet already knows what you’re managing, what it’s related to, and how it’s changing, because it needs that to do its job. We’re working on giving you a clearer picture of all of this data, and some great levers and knobs on that data so you can take action based on this new-found information.

Outside of Puppet itself, I think 2012 will be an interesting year, too. We’re a bit isolated from it up here in Portland, but there’s an interesting tech/cloud bubble going on in Silicon Valley, and I’ve got a lot of friends who see a cloud winter on the way. Personally, I think we’re finally leaving the world of pure-hype clouds and 2012 is when real-world companies start figuring out how to invest practically in the cloud, and it’s also when the cloud vendors will start to separate. Hopefully we won’t see any more “Enabling the Cloud for Business!” banners, but I’m not getting my hopes up.

I think 2011 has been a critical year for devops. Almost no one I talked to had heard of it in 2010, but this year it seems to have taken over. I can think of three long-standing conferences that had a major focus on devops, and it has gained visibility up and down the organization. The only downside is there’s still a lot of disagreement on what it means and how people can take advantage of it, but great tech movements are powered by passion and vagueness, and devops looks to be the driver for innovation in operations in the next ten years or so.

Here’s looking forward to another scary, great, fast, tedious, invigorating, draining, and amazing year.

Join us for an upcoming Puppet Camp:

Atlanta, GA – Friday, February 3rd – Register

Edinburgh, Scotland – Friday March 23rd – Register

(Click on “Booking“)

Puppet Camps are one-day, regional events held 6-8 times per year. Puppet Camp features 4 to 5 talks followed by a few sessions of unconference. Registration costs, co-located events, and speakers will vary from event to event.

If you’d like to speak at or sponsor a Puppet Camp please contact us.

We are aiming to organize Puppet Camps in New York City and in Stockholm in March or early April, more information will be posted as it becomes available on the PuppetCamp Community page.

PuppetConf will persist as a multi-day user and community conference. We have a ton of changes coming to PuppetConf ’12 to look forward to, so mark your calendar for PuppetConf 2012: September 27-28 at the Mission Bay Conference Center in San Francisco, CA.

We also look forward to seeing you at SCALE 10X for Puppet Training at Scale University (use our discount code “PUP12″ for 40% off registration to SCALE and Puppet training), and at the Configuration Management Room at FOSDEM.

With the release of Puppet Enterprise 2.0, Puppet Labs has added cloud provisioning capabilities with support for some of the most popular public and private cloud offerings including Amazon EC2 and VMware. PE 2.0 allows you to quickly provision virtual machines and start managing them with Puppet right away.

Getting Started

The following set of “micro” tutorials will show you how to leverage Puppet Enterprise 2.0 cloud provisioning capabilities on a public cloud (Amazon EC2). In order to get up and running you will need access to an Amazon’s EC2 account. Please note that while this tutorials will focus on Amazon EC2, the Puppet Enterprise 2.0 provisioning capabilities are designed to support a wide range of cloud providers. Initially there is support for Amazon EC2 which is covered in this tutorial and VMware, which is covered here; with support for additional providers being added over time.

Setup EC2 for use with Cloud Provisioner

1. Download and install PE 2.0
2. Gather Amazon AWS details into the fog configuration file

Before launching instances with the Cloud Provisioner module, you’ll need to register with Amazon AWS and obtain your access credentials.

Once you have completed the registration process, follow the AWS configuration sections here.

Now that you are all set up, we are ready to create our first virtual server in the cloud.

Provisioning in the Cloud

Provisioning machines on public or private clouds offers a huge benefit over traditional methods used on bare metal machines. Gone are the delays caused by hardware procurement and network setup; new machines are just a few clicks away. But to take full advantage of these new possibilities, you’ll need the right tools for the job.

Create virtual machines on EC2

1. Gather Amazon Instance details
   • image — AMI to use when creating the instance
   • keyname — The AWS SSH key name as shown in the AWS console
   • type — Type of instance
2. Run the puppet node_aws create command

Create a Debian 6.0 micro instance on EC2:

# puppet node_aws create --image='ami-0ce41865' --keyname='kelsey_rsa' --type='t1.micro'
notice: Creating new instance ...
notice: Creating new instance ... Done
notice: Creating tags for instance ...
notice: Creating tags for instance ... Done
notice: Launching server i-2a38eb48 ...
#############
notice: Server i-2a38eb48 is now launched
notice: Server i-2a38eb48 public dns name: ec2-174-129-158-192.compute-1.amazonaws.com
ec2-174-129-158-192.compute-1.amazonaws.com

At this point you should be able to ssh into your EC2 instance:

# ssh -i .ssh/puppetlabs_id_rsa root@ec2-174-129-158-192.compute-1.amazonaws.com
Enter passphrase for key '.ssh/puppetlabs_id_rsa':
Linux ip-10-212-169-9 2.6.32-5-xen-686 #1 SMP Wed Mar 9 01:27:54 UTC 2011 i686

The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
root@ip-10-212-169-9:~#

That’s all there is too it, and doing the same for VMware is equally as easy:
http://docs.puppetlabs.com/pe/2.0/cloudprovisioner_vmware.html

Cloud Maintenance

The ability to provision an unlimited number of virtual machines has its downsides, like virtual machine sprawl, it’s easy to lose track of how many machines you have and how they are configured. In short, virtual machines require real maintenance.

PE 2.0 greatly reduces this overhead by providing tools such as the Puppet Enterprise Console—built on top of the Puppet we all know and love—which enables you to visualize and manage your entire infrastructure, virtual or physical, right out of the box. When you provision your virtual machines using the new cloud provisioning capabilities, you get access to these features immediately.

Classify, and managing machines via the PE 2.0 Console (GUI)

# export PUPPET_ENC_AUTH_PASSWD=’XXXXXXXX’
# puppet node classify ec2-174-129-158-192.compute-1.amazonaws.com \ --node-group='default' --enc-ssl --enc-server dashboard.puppetlabs.com \
--enc-port 443 --enc-auth-user console
notice: Contacting https://master.hightower.puppetlabs.com:443/ to classify ec2-174-129-158-192.compute-1.amazonaws.com
complete

At this point you should be able to access your node via the Puppet Enterprise Console:



Conclusion

Whether you have an existing cloud infrastructure or just getting started, PE 2.0 can streamline the complete life cycle of running machines in the cloud while incorporating “cloud” best practices and world class configuration management.

Look for support for additional Cloud vendors in the near future.

Related Content:

• Read the docs on cloud provisioning in Puppet Enterprise 2.0. (videos embedded)
• Learn what you can do with those classified nodes in the Puppet Enterprise 2.0 recorded webinar
• Test it out — download ten free nodes of Puppet Enterprise 2.0.

Why do we want configuration management? There are plenty of reasons, but at the core of them is that we want to streamline the configuration and deployment of systems. We want this process to be repeatable, well-understood, and predictable. We want to make it deterministic.

Determinism — the idea that a process should result in the same outcome every time it is applied — is not a new idea, but it’s also not one that system administrators apply to their daily work. Can you prove that the bash script you just wrote to deploy your new NoSQL database will work across all of your system configurations? Will it work the same way if you execute it again next week—or next year? Automating the deployment and configuration of systems is meaningless if we can’t guarantee that these systems will complete the configuration process with predictable results.

For years, organizations have tried to handle this problem using scripts to deploy and manage their environments. These scripts evolve over years as they’re passed from admin to admin, growing to contain the personal quirks of their developers and long-irrelevant legacy workarounds. It’s not until a script is needed—usually when the server fails—that sysadmins discover it’s tightly pegged to a particular version of bash or sed, or requires a specific return code from an init script that no longer exists. The script’s lack of predictability impacts organizations at the worst possible time in the development cycle.

Periodically, organizations recognize that these scripts have become unmanageable and will attempt to refactor or rebuild them from scratch, resulting in a whole new cycle of trial-and-error. This tug of war with scripts takes time from other, more valuable tasks. How many times have you fixed or updated the same process when you could have been learning or applying new information to your environment?

Your credibility as an admin is dependent on your ability to construct reliable, stable, consistent systems. It’s critical that the process you employ works in a predictable way every time.

Puppet’s View of the Server

What makes Puppet different from a library of shell scripts, and from other configuration management tools, is that it forms a model of your system configuration prior to performing any activity on the system itself.

Before a single command is executed on a host, Puppet has constructed what we refer to as a “resource graph” of that node’s existing configuration, and determined how your changes will impact that graph. Below is a very simple example of such a resource graph:

It’s a difficult leap for new users, particularly as we as sysadmins are trained to think procedurally and not deterministically. Admins tend to think of processes: managing the server as a group of activities that leave the system in a desired state when properly applied. We spend most of our careers mastering the processes (and trying to pass certification exams that prove we have).

Puppet asks you to think differently about what administration means, and to focus on what the server is supposed to look like after all processes are finished. It doesn’t ignore process, but considers it a means to an end—you tell Puppet what you want the server to look like, and Puppet works out how to get the server there.

Noop and Dry Runs

One of the big advantages of the resource graph model is Puppet’s unique and unrivaled “noop” functionality, which allows you to simulate a change before you deploy it. Other tools can run in some semblance of a dry run or do-nothing mode, but they often repeat back what your script says, without offering the impact on your system as a whole. Puppet understands what your environment currently looks like as of the last Puppet run (represented by the orange rectangle in the below example) and what the end state is supposed to look like (the green parallelogram). Puppet then tells you both what it will do when executed without noop, and how that action would change the overall configuration of your system. These steps are identical in noop mode and in regular execution mode. The only difference is whether or not Puppet performs the action in the red shape at the bottom, or merely reports to you what will happen if you run Puppet.

Where Determinism Poses a Challenge

This resource graph model can be problematic for you if you don’t know what a server is supposed to look like at the end of your administration process. Puppet insists that you understand an application’s impact will be before you begin the process of installing it. This is how it should be. Nothing should be placed on a production system without you, the administrator, being able to fully document and understand the changes that application will impose; yet we are all guilty of starting procedures on systems without fully understanding the impact.

While this deterministic core is at the heart of Puppet, there are still elements that can cause confusion. Until recently, there was an issue with resources being applied in a non-deterministic order on nodes, so that a manifest might compile and execute in one order on one node, and another on a second. This was based on the assumption that all resources are atomic, and is remedied in the Puppet 2.7 and Puppet Enterprise 2.0.

Determinism is not a panacea—you still have to validate that your Puppet manifests do what they’re supposed to, and you should put them through the same rigorous testing you expect of dev environments. But you are able to increase your confidence that something working in your test environment will work in production, and that a proposed change will not interfere with a production environment because of a surprising interaction.

Further Advantages to a Deterministic Approach with Puppet

Aside from noop mode, what do you as an administrator get out of Puppet’s deterministic nature? A few notable benefits:

• Your Puppet manifests describe what your systems look like and how to install them. While there is never a replacement for good long-form documentation, in the real world people rarely have the time to write it. Fortunately, Puppet manifests can serve as accurate documentation of a server’s entire configured environment, from unusual post-install procedures to open ports—and in fact this can be better than written documentation, since it is by definition always up-to-date.
• When you do deploy, that process is automated. Your best and most senior engineer does not have to be the guy who pushes the button—and it’s very unlikely that on deploy night that you will be writing or heavily modifying legacy bash or Perl scripts.

You can ultimately think of the choice between a deterministic and non-deterministic tool as the choice between predictability and randomness, or better, between configuration management and ad-hoc system administration. With Puppet, you think your problem through, saving you time and effort later on. Non-deterministic tools may seem to solve a short-term problem, but you’re merely accruing technical debt.

Related Content:

• How to look at your resource graph in Puppet

Last week was Usenix LISA ’11 in Boston. This was the 25th year of the conference, and the final reception included a perusal of the last 25 years of LISA, highlighting the history of the long-standing community. Old friends reuniting brought the conference center to a rolling boil of laughter and conversation. The past experiences of LISA and its participants helped make the latest conference great. If you’re feeling nostalgic, check out the LISA site archive.

If you attended LISA you were hopefully able to visit us at the DevOps, Intro to Config Management, or our Puppet Birds of a Feather Sessions. If not, we hope you caught Eric Shamow’s presentation of his paper “Getting to Elastic: Adapting a Legacy Vertical Application Environment for Scalability,” or Luke Kanies’ talk on DevOps, or got a chance to chat and watch a Puppet Enterprise demo at our booth. If you couldn’t make it to LISA, catch us at SCALE 10x in Los Angeles in January, where we’ll have a half-day training session at SCALE University and the LA Puppet User Group will host a BoF if we can find a good time (stay tuned).

We’ve also announced a Call for Papers for The Configuration Management Room at FOSDEM. Get your abstracts in by December 31, and join us in Brussels, Belgium this February for all things configuration management.