As possibly the last AWS using sysadmin in London who’s not invested in Terraform I’ve decided it’s time to take my quarterly look at the tool. This time around I decided to start with a basic IAM admin user and group. For my stripped down example I’m going to create a user and group, add the user to a group and set an explicit IAM group policy. As a novice terraform user I find the code easy to read, the online documentation was short but helpful and the getting started guide did indeed guide my starting. 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 - the tool for ‘Quick and Easy server validation’. Read on →

I’ve recently begun to look at replacing as much of my custom puppet tooling as possible with third-party, open source, code. As part of this I’m planning to update my old libvirt testing infrastructure with more modern tools, and this seems to be leading me heavily down the docker path. One of the simpler, but less known, solutions in this space seems to be Dockunit, which bills itself as “Containerized unit testing across any platform and programming language” and is remarkably simple to get started with. Read on →

After a previous comment about “ templating CloudFormation JSON from a tool higher up in your stack“ I had a couple of queries about how I’m doing this. In this post I’ll show a small example that explains the work flow. We’re going to create a small CloudFormation template, with a single Jinja2 embedded directive, and call it from an example playbook. This template creates an S3 bucket resource and dynamically sets the “DeletionPolicy” attribute based on a value in the playbook. Read on →

You can create some high value resources using CloudFormation that you’d like to ensure exist even after a stack has been removed. Imagine being the admin to accidently delete the wrong stack and having to watch as your RDS master, and all your prod data, slowly vanishes in to the void of AWS reclaimed volumes. Luckily AWS provides a way to reduce this risk, the DeletionPolicy Attribute. By specifying this on a resource you can ensure that if your stack is deleted then certain resources survive and function as usual. Read on →

While AWS CloudFormation is one of the best ways to ensure your AWS environments are reproducible it can also be a bit of an awkward beast to use. Here are a couple of simple time saving tips for refining your CFN template parameters. The first one is also the simplest, always define at the least a MinLength property on your parameters and ideally an AllowedValues or AllowedPattern. This ensures that your stack will fail early if no value is provided. Read on →

Have you ever needed to access Ansible facts from inside Puppet? well, if you ever need to, you can use the basic ansible_facts custom fact. # make sure you have ansible installed $ sudo puppet resource package ansible ensure=present # clone my experimental puppet fact repo $ git clone https://github.com/deanwilson/unixdaemon-puppet_facts.git # Try running the fact $ ruby -I unixdaemon-puppet_facts/lib/ `which facter` ansible_facts -j { "ansible_facts": { "ansible_architecture": "x86_64", "ansible_bios_date": "04/25/2013", "ansible_bios_version": "RKPPT%$DSFH.86A.0457.20DF3.0425.1251", "ansible_cmdline": { ... Read on →

Puppet’s always had a couple of little inconsistencies when it comes to the file and template functions. The file function has always been able to search for multiple files and return the contents of the first file found but it required absolute paths. The template function accepts module based paths but doesn’t allow for matching on the first found file. Although this can be fixed with the Puppet Multiple Template Source Function. Read on →

In the past if you wanted to run your own puppet-lint checks there was no official, really clean way to distribute them outside of the core code. Now, with the 1.0 release of puppet-lint you can write your own, external, puppet-lint checks and make them easily distributable. I spent a little bit of time this morning reading through the existing 3rd party community plugins and after porting a private absolute template path check over to the new system I have to say that rodjek has done an excellent job with both the ease of writing your own checks and the quality of the developer tutorial. Read on →

A little while ago in a twitter conversation, many hops away a few of us discussed the Puppet Certified Professional exam and topic coverage. Specifically how much of it was focused on Puppet Enterprise (PE) and if it would either dissuade users of purely FOSS Puppet or heavily impact their chance of passing if they’d never used PE. While I stand by my views I began to worry that my knowledge of the syllabus was only based on hearsay, the practice exam questions and that I was being overly harsh and possibly spreading misinformation through my own ignorance. Read on →