Jason Hancock

I’ve always been fascinated by photo mosaics. I suppose it goes back to the first time I saw one on a family vacation to Disneyland. They had photo mosaics throughout the park of the Disney characters that were made from the images that the cast members would take of families on vacation. Fast forward a few years (okay…maybe a decade and a half or thereabouts). I’ve dabbled a bit with photography and had built up a library of images about 40 or 50k deep.

I saw the post from the guys over at Metricfire about Building the Big Red Button. I thought I’d build something similar as a proof of concept. Here’s what I ended up with: I used the same red dome button from SparkFun. Inside the case is an Arduino Uno that I repurposed from an earlier project. My dome button came equipped with an LED instead of an incandescent bulb, so I was able to power everything directly from the USB cable.

I host a couple of instances with Rackspace and generally go back and forth between them and AWS when I need an instance to do some testing. I was getting pestered by their emails every couple of weeks to check out their CloudU Certification program. I decided to check it out, but it’s unfortunate that I won’t get that 30 minutes of my life back. The program is set up as 10 lessons, each with a 10 question quiz at the end, followed by a 50 question final exam.

Puppetlabs released PuppetDB last Friday. It’s a drop-in replacement for the existing stored configurations backends and the inventory service. Stored configurations have always been a performance bottleneck in my puppet installations, so I was eager to try it out. I had it up and running, completely puppetized within a couple of hours. This was mainly due to my unfamiliarity with Postgres and having to repurpose some of the existing postgres modules on the forge to suit my needs.

Puppet Camp LA 2012 is being held on May 19th and hosted by Media Temple in Culver City. I’m excited to be a speaker this year. I’ll be talking about running Puppet on CloudStack instances and automating other parts of your infrastructure. Although the details will be focused on what it takes to run Puppet specifically on CloudStack instances, the methodology I will be presenting translates to other clouds and bare-metal infrastructure.

I wanted a subversion pre-commit hook script that did the following: Ensures all *.pp files in the transaction can be validated by the parser Ensures all *.pp files pass a puppet-lint check Ensures all *.erb files pass a syntax check I poked around a bit, but it looks like most of the existing pre-commit hook scripts were a bit out of date (wouldn’t work on puppet >= 2.7). Also, I didn’t see a script that also ran puppet-lint.

We have a couple of extra monitors lying around at work as well as some mac minis and other assorted hardware that isn’t being used. We wanted to mount the monitors to the wall and have the typical performance graphs, red/green monitors, etc. displayed on them. After attending SCALE 10X and seeing @lolcatstevens’ talk on haproxy where he used impress.js as the presntation software, I knew I wanted to use impress.

When we were building our CloudStack environment we wanted newly created instances to check into the puppetmaster and receive their configurations automatically. The goals for accomplishing this were: No human intervention Do not have to update a separate asset database/spreadsheet/text file/etc. Do NOT use Puppet’s auto-signing feature Instances receive all config via Puppet, thus minimizing the number of CloudStack templates we have to maintain by only having to keep base/minimal images for each OS that we are supporting (One el5 image, one el6 image, etc.

If you’re using Puppet, and using Puppet to automatically generate configurations for other parts of your infrastructure by using stored configurations, then one thing you have to do is clean up the stored configurations database once you have destroyed a node, otherwise whatever stored config you created will continue to persist despite you removing that node. Luckily for us, the folks at PuppetLabs ship a script that we can use to clean up after a node.

After spinning up CloudStack and playing with it for a bit, I decided it was time to add some monitors. We’re currently using Nagios, although I may start looking at Zenoss. Anyhow, I built a couple of plugins to mimic some of the functionality of the Zenoss ZenPack for CloudStack. For example, I can graph how many instances are in my cloud in addition to memory/cpu/storage/IP allocations: You can find all of the code at in my nagios-cloudstack project at GitHub.