Taming Slaves with Docker and ShutIt

At our company we had a problem.

We used Jenkins for CI, but had no clear way of setting up machines in a reliable portable and reproducible way. We had centralised VMs but provisioning was slow and complex.

So we bought a big beefy development server. Everyone was happy, for it was Big and the developers did Rejoice. This server was and is maintained by a tightly-controlled puppet script.

As Jenkins use and CI takeup increased over the years we ran out of CPU and memory (thanks, Java) and explored a few options: AWS, a VMWare Virtual Private Cloud, even buying VM server boxes and handing them to teams. All had their drawbacks.

The centralised dev server approach meant a single constraint on delivery. Requirements among the temas diverged and the (centralised and harassed) IT infrastructure cost centre are reluctant to make changes for fear of helping one team and breaking another (“Why can’t we just upgrade python pleeease? What could go wrong!?”)

The system we build is monolithic and has complex dependencies, so when Docker came along we saw the opportunity to rid ourselves of this. How complex?

ShutIt has a feature (“shutit depgraph”) whereby you can output the dependency graph. Here’s the graph of the Jenkins slave server image, suitably anonymised:

jenkins_slave_anon

The dependencies go from top to bottom. At the top is the slave module, which adds a few bits onto its dependencies (the publicly available memcache and docker modules for example – yes, we run docker-within-docker to make some build processes even simpler), and those modules in turn depend on others, many of which we’ve had to tweak or maintain for our proprietary needs. Each module can be configured for specific versions that are on different real-world deployments, and used to test upgrades/fixes and the like. Doing this with standard CM tools was far more complex and difficult to maintain.

The nature of ShutIt means that it’s easy for a developer or team to add a few tweaks to this image, and regression testing can happen in the background off git hooks (or another pet project, cheapci), as all you need to know is bash; not learn and understand some declarative framework new to you.

The nature of Docker makes these slaves easy to deploy (docker pull) and portable (run on your Core i5 laptop? A provisioned VM? A Digital Ocean instance? AWS? No problem).

In the next post I plan to explain why ShutIt and Docker is a perfect configuration management fit for developers looking to manage complex build needs.

Advertisements
This entry was posted in Uncategorized. Bookmark the permalink.

2 Responses to Taming Slaves with Docker and ShutIt

  1. Pingback: Docker in Practice – A Guide for Engineers | zwischenzugs

  2. Pingback: Docker in Practice – A Guide for Engineers | Ceiba3D Studio

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s