Puppet is amazing. It changed my career (thanks to Luke , and before him Mark). However, I have some itches. I have attempted to write about these before, but haven’t felt like pushing the ‘publish’ button.

I’ve been running Puppet in a atypical way for some time now.

No Puppet Master
No distribution packaging
No commit until I know something works
Only test from the outside
The only thing I feel I need to

Rump helps you run Puppet locally against a Git checkout.

Rump encourages a Puppet workflow where you quickly + iteratively develop your Puppet manifests on a single machine, then push your changes up to a repository to deploy to the rest of your infrastructure.

This workflow also complements a Capistrano or MCollective-style deployment, where you remotely instruct Rump to check out a copy of the latest manifests and run them.

Rump also has the ability to freeze Puppet in to the manifests repository, letting you quickly test different versions of Puppet without waiting for packages to appear, and reducing the dependencies on a system to run Puppet down to just Ruby and git.

This week’s module helps implement and manage Jenkins CI with Puppet. We all need to test our code when we make changes. Saying so is easy, doing so is a lot more difficult. Jenkins makes testing easier. Every time you make a change, Jenkins will test everything still works. It’s easy to get started with Jenkins by using a Puppet module written by R. Tyler Croy. This module automatically installs the Jenkins software, configures the service, and provides an simple way to add functionality by automatically installing any of the 400+ Jenkins plugins. You should give this module a spin if you’re looking for an easy way to try out Jenkins or puppetize an existing Jenkins server. Install it, classify a node with the jenkins class in the Puppet Enterprise Console and Jenkins is running and ready to do your bidding.

We deploy a lot of code. Deployinator is our creation to make that as easy and painless as possible. Deployinator is a one button web-based deployment app. Hit that button and code goes to our webservers and is serving requests in almost no time. Using Deployinator we’ve brought a typical web push from 3 developers, 1 operations engineer, everyone else on standby and over an hour (when things went smoothly) down to 1 person and under 2 minutes.

At Etsy, we’re doing what’s come to be called Continuous Deployment. However, what we’ve learned is that having a tool like Deployinator is useful for more than just enabling that. This post is about those benefits – for anyone deploying web code.

Why

Our job as engineers (and ops, dev-ops, QA, support, everyone in the company actually) is to enable the business goals. We strongly feel that in order to do that you must have the ability to deploy code quickly and safely. Even if the business goals are to deploy strongly QA’d code once a month at 3am (it’s not for us, we push all the time), having a reliable and easy deployment should be non-negotiable.

Deployinator - Deploy code like Etsy
Deployinator is a deployment framework extracted from Etsy. We've been using it since late 2009 / early 2010.

Here is a blog post explaining our rationale behind it and how it helps us out.

Since puppet and later chef took off, there was discussion in the community about code reusability (chef cookbooks or puppet modules). As far as I can see, there is hardly any progress to see and it is still a big PITA to use other people’s cookbooks or modules.

As I am mostly working with chef these days, I will present my ideas with respect to chef cookbooks. From my experience with puppet, I expect them to apply similarly.

How do you manage configuration files across a wide array of games, played by millions of users and served out of multiple data centers?

Over the years Zynga has found that the right solution to this problem varies for each unique service and product. I’d like to present one of these solutions today: Apache ZooKeeper.

Apache ZooKeeper allows Zynga to update thousands of configuration files in under a second. Game servers at Zynga need to interact with various levels of persistent and volatile storage. To provide increased performance, game nodes talk directly to these storage nodes via IP addresses and domain names stored in a local configuration file.

Over the last year I haven't only grown very fond of coffee, but also of infrastructure. Working on Scalarium has been a fun ride so far, for all kinds of reasons, one of them is dealing so much with infrastructure. Being an infrastructure platform provider, what can you do, right?

As being responsible for deployment, performance tuning, monitoring, infrastructure has always been a part of many of my job I thought it'd be about time to sprinkle some of my thoughts and daily ops thoughts on a couple of articles. The simple reason being that no matter how much you try, no matter how far away from dealing with servers you go (think Heroku), there will always be infrastructure, and it will always affect you and your application in some way.

On today's menu: monitoring. People have all kinds of different meanings for monitoring, and they're all right, because there is no one way to monitor your applications and infrastructure. I just did a recount, and there are no less than six levels of detail you can and probably should get. Note that these are my definitions, they don't necessarily have to be officially named, they're solely based on my experiences. Let's start from the top, the outside view of your application.

hubot-scripts

These are a collection of community scripts for Hubot, a chat bot for your company.

One of the features offered by Puppet is the ability to break up infrastructure configuration into environments. With environments, you can use a single Puppet master to serve multiple isolated configurations. For instance, you can adopt the development, testing and production series of environments embraced by a number of software development life cycles and by application frameworks such as Ruby on Rails, so that new functionality can be added incrementally without interfering with production systems. Environments can also be used to isolate different sets of machines. A good example of this functionality would be using one environment for web servers and another for databases, so that changes made to the web server environment don’t get applied to machines that don’t need that configuration.

RunDeck is cross-platform open source software that helps you automate ad-hoc and routine procedures in data center or cloud environments. RunDeck allows you to run tasks on any number of nodes from a web-based or command-line interface. RunDeck also includes other features that make it easy to scale up your scripting efforts including: access control, workflow building, scheduling, logging, and integration with external sources for node and option data

If you aren't yet using Puppet or Chef for managing your *nix infrastructure, you should seriously consider it. The benefits are enormous. Frankly, I don't think you __can__ manage a modern infrastructure without using Puppet, Chef, or reinventing a configuration management framework with your own custom scripts. However, you can't use both Chef and Puppet together, so which should you choose?

Apache ZooKeeper is an effort to develop and maintain an open-source server which enables highly reliable distributed coordination.

ZooKeeper is a centralized service for maintaining configuration information, naming, providing distributed synchronization, and providing group services. All of these kinds of services are used in some form or another by distributed applications. Each time they are implemented there is a lot of work that goes into fixing the bugs and race conditions that are inevitable. Because of the difficulty of implementing these kinds of services, applications initially usually skimp on them ,which make them brittle in the presence of change and difficult to manage. Even when done correctly, different implementations of these services lead to management complexity when the applications are deployed.

Getting Started With Puppet Cloud Provisioner

Learn how to install and start using Cloud Provisioner, Puppet’s extension for node bootstrapping.
Overview

Puppet Cloud Provisioner is a Puppet extension that adds new actions for creating and puppetizing new machines in Amazon’s EC2.

Cloud Provisioner gives you an easy command line interface to the following tasks:

Create a new Amazon EC2 instance
Install Puppet on a remote machine of your choice
Remotely sign a node’s certificate
Do all of the above with a single puppet node bootstrap invocation

A server infrastructure can't be considered fully operative if it's not monitored in some way.
Various tools are available in the market and they cover different facets of the common monitoring needs (alerting, trending, performance, security...) but whatever is your choice you need to configure them in some way.

Simian is an enterprise-class Mac OS X software deployment solution with Google App Engine-based hosting to scale with the needs of your growing enterprise, and a future proof client based on the Munki open-source project.

Simian provides an entire server, ready to run on App Engine, which Munki clients connect to.