I know I’m late to this party, but I just have to say it: I absolutely love Ansible.

For many years, I have been a Puppet wrangler.  It was always a real struggle.  I mean, the basics are pretty straightforward, and the framework provides everything you reasonably need to achieve some exceptionally sophisticated automation.  If you embrace the “Puppet Way”, there’s really nothing you can’t do.  I’ve helped write and maintain modules that are many tens-of-thousands of lines of code that pretty well ran our application infrastructure and was the foundation of the application’s software delivery machinery.  But it was a pain.  It was never just right.  There were always caveats and mental hoops to jump through.  It made me feel inadequate as a developer.  It broke my brain.  It was such a chore.  I came to dread wading into module code for any reason. Continue reading

Bootstrapping A Simple Openstack Lab

In my last post, I waved my hands and assumed you had a deployment of Openstack to run the CoreOS cluster that was the subject of that post.  I felt a little absurd talking about autonomous, self-assembling infrastructure-in-a-box while choosing to forego a simple tutorial on setting up an all-in-one lab environment, at a minimum. So this time around, we’ll discuss a way you might bootstrap a simple Openstack deployment.  This setup will result in an RDO all-in-one Openstack system where the floating ip pool will be assigning valid IP addresses on your “public” network.  In this example, we pretend your lab subnet is  When you assign a floating IP address, any host that can route to that network will be able to talk to those floating IPs (assuming your security group allows it).

In my personal home lab, the first thing I set up was a Cobbler server.  I performed a minimal installation of CentOS 6.5 x86_64 with a netboot ISO, installed the EPEL repo, and set up Cobbler using the instructions on the Cobbler website.  I configured Cobbler to manage DHCP and DNS, and also installed cobbler-web.  I imported one distro: centos-6.5-x86_64.

Continue reading

A Simple CoreOS and Etcd Cluster

In my idle moments, I contemplate such things as self-assembling infrastructure-in-a-box.  What I mean by that is how do you go from an an empty room (conceptually) to doing useful work for the business in as few steps as possible, as quickly as possible?  What minimum complement of services do you need, and how do you bootstrap it into existence, autonomously?  The goal is to perform as few manual steps as possible to get to a state where you can easily build out the rest of your infrastructure and start deploying applications right away.  Bootstrapping.  Inception.  Whatever.

In this post, at a high level, I want to lay out a simple application platform bootstrapping exercise.  We’re going to make use of a HOT template for Openstack to bring up a three node CoreOS cluster which performs auto-discovery to assemble an etcd cluster.  This is not a tutorial on Openstack.  I am not covering the obvious question of how to get Openstack running.  The point of this exercise is only to lay the foundation for running clustered applications in Docker containers.

Continue reading

Initial Thoughts on Cloud-Init

I have a confession: I only recently discovered the awesome that is cloud-init.  I mean, I’d heard of it, but hadn’t ever really dug in to get to know it.  I most definitely fall into the early-adopter category when it comes to technology, too.  As a freshman in college, I helped build a network kickstart installer, years before tools like Cobbler came on the scene.  After college, I had the good fortune to work somewhere that understood the possibilities with VMWare, and was running a nearly 100% virtualized infrastructure in the ESX 2.0 days.  I first discovered Puppet back in the 0.23 days.  I was using Mcollective in production almost 2 years ago.  I wowed my developers with Vagrant in the pre 1.0 days.

But cloud-init.

Continue reading