I’ve been a big theoretical fan of Honeycomb.io for a long time now. The technology seems both timely and needed. The employees are prominent in our field and the people that start using it seem to very quickly become convinced of its worth. What’s made it theoretical for me is that I’ve just not had a reason to actually delve into it and have a play around. Or I hadn’t until I saw Observability in the SSC: Seeing Into Your Build System. Read on →

I’m not a massive fan of Mind Mapping, a “hierarchical way to diagram and visually organise information that shows relationships among pieces of the whole”, but before Christmas I found myself blocked and unable to gain traction on a small research based side project. After idling for an uncomfortable duration I tried a few alternative approaches and Mind Mapping appeared to be a decent fit so I decided to install a tool and break my block with it. Read on →

Next in my unhurried investigation of hosted build systems for my small collection of Free Software are GitHub Actions. A fully hosted task runner that can Build, test, and deploy your code right from GitHub. As someone not exclusively using GitHub to manage all their source code the idea of being completely tied into a single provider isn’t a great one but the technology looks interesting enough to justify running a few simple experiments. Read on →


I recently enabled Dependabot to help track updates to my dependencies and keep them current. The user experience has been a pleasant one with simple configuration and timely pull requests but I’ve quickly come to dread one specific thing - the Updating Of The Rubocop. I have quite a lot of ruby bases repositories and I like to use rubocop as a basic safety net and second set of eyes so it’s in heavy use, which is great until the version changes. Read on →

I have a small pile of old Ruby based Puppet modules and extensions that I don’t use anymore but have had some adoption and so thanks to an over abundance of guilt I make the occasional attempt to ensure they are still working and kept vaguely up to date. With the GitHub acquisition of Dependabot, an automated dependency update service, I decided to enable it for a few repos and see how it fits my work flow. Read on →

Travis CI has long been my hosted continuous integration service of choice for my open source repos but there have been some recent [changes](https://hub.packtpub.com/idera-acquires-travis-ci-the-open- source-continuous-integration-solution/) and departures that inspired me to look around and see what else the modern world has to offer. I run a local Jenkins for my own personal use but it’s not hardened to a degree where I’d trust it to run random pull requests from the wild internet so a hosted, free, solution would be an ideal place to start from. Read on →


I’m the only infrastructure person on a number of my projects and it’s sometimes difficult to find someone to review pull requests. So, in self-defence, I’ve adopted git precommit hooks as a way to ensure I don’t make certain tedious mistakes before burning through peoples time and goodwill. In this post we’ll look at how pre-commit and terraform can be combined. pre-commit is “A framework for managing and maintaining multi-language pre-commit hooks” that has a comprehensive selection of community written extensions. Read on →


As your terraform code grows in both size and complexity you should invest in tests and other ways to ensure everything is doing exactly what you intended. Although there are existing ways to exercise parts of your code I think Terraform is currently missing an important part of testing functionality, and I hope by the end of this post you’ll agree. <tl;dr>I want puppet catalog compile testing in terraform</tl;dr> Our current terraform testing process looks a lot like this: Read on →

While trying to add additional performance annotations to one of my side projects I recently stumbled over the exceptionally promising Server-Timing HTTP header and specification. It’s a simple way to add semi-structured values describing aspects of the response generation and how long they each took. These can then be processed and displayed in your normal web development tools. In this post I’ll show a simplified example, using Flask, to add timings to a single page response and display them using Google Chrome developer tools. Read on →

I’ve been a fan of Yelps pre-commit git hook manager ever since I started using it to Prevent AWS credential leaks. After a recent near miss involving a push to master I decided to take another look and see if it could provide a safety net that would only allow commits on non-master branches. It turns out it can, and it’s actually quite simple to enable if you follow the instructions below. Read on →

While migrating and upgrading an old install of Jenkins over to version 2 the topic of adding some new views came up in conversation and the quite shiny Jenkins CI Build Monitor Plugin came up as a pretty, and quick to deploy, option. Using some canned test jobs we did a manual deploy of the plugin, configured a view on our testing machine, and I have to say it looks as good, and as easily readable from a few desks away, as we’d hoped. Read on →


As you add more jobs to Jenkins you’ll often want to start breaking them out in to smaller, more logically grouped, views. While the UI itself makes this simple it’s a manual task, and as automation loving admins we can do better than clicking around. In this post we’ll take a brief look at the jenkins-view-builder and see if it can make our lives any easier. My test case will be a simple Jenkins view that should include any jobs whose names match the test-puppet-. Read on →

While there are many ways to test your code under Docker, for example puppet modules with dockunit, discussions about how to run acceptance checks against docker image and container creation are less common. In this post we’ll present one approach using the docker api and serverspec to test the creation and execution of a dockerised Redis. As our first step we’ll create the directory we’ll be testing under and a basic Dockerfile. Read on →

Continuing my journey through infrastructure testing tools we next visit testinfra, a serverspec equivalent written in python. For continuity purposes we’ll redo the Redis tests from the previous blog post. First we’ll configure a testinfra virtualenv we can use for our experiments. $ virtualenv testinfra-py-redis New python executable in testinfra-py-redis/bin/python2 $ cd testinfra-py-redis $ source bin/activate (testinfra-py-redis)[dwilson@home testinfra-py-redis]$ $ pip install testinfra # prove it works $ testinfra --version Now we have a working install of testinfra we’ll write some tests for redis. Read on →

I’m a big fan of serverspec but there are times the ruby tool chain behind it can be an annoyance and result in lots of baggage being installed. This isn’t a major problem on development machines, where many of the gems will already exist, but on production hosts the runtime dependencies can be comparatively heavy. To avoid this I’ve started looking at possible alternatives and one young, but promising, project is Goss Read on →


Constructing a large, multiple application, virtual datacenter with CloudFormation can quickly lead to a sprawl of different stacks. The desire to split things sensibly, delegate control of separate tiers and loosely couple as many components as possible can lead to a large number of stacks, lots of which need values from stacks created earlier in the run order. While it’s possible to do this with the native AWS CloudFormation command line tools, or even some clever bash Read on →

Working with multiple, related CloudFormation stacks can become quite taxing if you only use the native AWS command line tools. Commands start off gently - cfn-create-stack dwilson-megavpc-sns-emails --parameters "AutoScaleSNSTopic=testy@example.org" \ --template-file location/sns-email-topic.json but they quickly become painful. The two commands below each create stacks that depend on values from resources that have been defined in a previous stack. You can spot these values by their unfriendly appearance, such as ‘rtb-9n0tr34lac55’ and ‘subnet-e4n0tr34la’. Read on →

Once we started extracting applications into different logical CloudFormation stacks and physical templates, we began to notice quite a lot of duplication in our json when it came to declaring IAM rules. Some of our projects store their puppet, hiera and rpm files in restricted S3 buckets so allowing stacks access to them based upon environment, region, stack name and other criteria quickly becomes quite long-winded. After looking at a couple of dozen application templates and finding that over 30% of the json was IAM based it was time to find a different approach. Read on →

One of the nice little conveniences I’ve started to use in my daily work with Amazon Webservices CloudFormation is the Guard::CloudFormation ruby gem. The Guard gem "is a command line tool to easily handle events on file system modifications" which, simply put, means “run a command when a file changes”. While I’ve used a number of different little tools to do this in the past, Guard presents a promising base to build more specific test executors on so I’ve started to integrate it in to more aspects of my work flow. Read on →

One of the biggest surprises of Config Management Camp 2014 for me was how interesting Canonicals orchestration management tool, Juju has become. Although I much preferred the name ‘Ensemble’. I attended the Juju session in an attempt to keep myself out of the Puppet room and was pleasantly surprised at how much Juju had progressed since I last looked at it. Rather than being another config management solution it allows you to model your systems using “charms”, which can be implemented using anything from a bash script to a set of chef/puppet cookbooks/modules, and instead focuses on ensuring that they run across your fleet in a predictable way while enforcing dependencies, even over multiple tiers, no matter how many tools you choose to use underneath. Read on →


A while ago @ripienaar and I had a chat in a pub about monitoring, event systems and lots of related subjects. As we all know he’s way more productive than is fair and so while he’s been doing a BUNDLE of work with on subjects like monitoring frameworks and event correlation I’ve been doing some thinking (and no actual coding) about event auditing, continuous compliance and security event management. Now I’ve finished the $TIMESINK_PROJECT I’m soon going to actually need some of this stuff so I’ve started putting together a prototype framework that I’m calling DSAC - Dump Send and Correlate. Read on →

I’ve been doing a little tinkering with pre/post release checklists and compliance reporting using cucumber and some Nagios wrapping (among other things) in my test lab and recently needed to do some higher level entire environment checks before moving on to the next step. While it’s possible to wrap something like nmaps ping check and then Nagios each target it does feel like stepping back a few years in the tool chain. Read on →


Cronjobs are one of those necessary evils of any decent sized Unix setup, they provide often essential pieces of a sites data flows but are often treated as second class citizens. While I’ve already mentioned my Cron commandments I’m always looking for improvements in the rest of my cron tool set and, with Vladimir Vuksan’s cronologger, I may have found another piece of the puzzle. The concept is simple, you add a command to the front of your crontabs and it invokes your actual cron command. Read on →

The last time we interviewed for Java developers (a couple of jobs ago) it came as quite a surprise at how few of them could function without their IDE of choice. A high percentage of the candidates struggled to compile using javac, had problems navigating the docs and made a large number of very simple syntax errors that they were obviously used to their editor dealing with. At the time the more unix focused team, most of who were very long term vim and emacs users, had a number of discussions about how this should impact our rating of the candidates. Read on →