OmbuLabs Blog

As a consultancy specializing in upgrades, dealing with legacy code is our bread and butter. Incompatible versions of Ruby, different version managers, C errors while running bundle install - there are many ways that setting up projects is not always straightforward. Add to this several projects and your development machine becomes a mess of hard to diagnose issues due to mismatched system dependencies. Virtualization to the rescue!

Here at OmbuLabs, we do a lot of work with older versions of Ruby and Rails. Recently, I’ve been taking a look at Docker, the virtual container platform, to see how it might help us manage the often idiosyncratic setup that applications we work with might require.

The last time we looked at Docker, we looked at the most basic and easy version of using it - building an image from a base image, a parent, and then layering additions and changes on top of it. With a carefully chosen base image, this can be an extremely flexible and relatively straightforward way of getting an image up and running in a container.

In my last article, I gave a brief tour of what Docker is, and basic usage. Once you’ve got your feet under you with basic usage, you’ll reach the point where you want to start making your own containers. You’ll certainly need to know how to roll your own if you want to use Docker in your own infrastructure.

If you’re like I was not too long ago, the DevOps world gives you a chance to experience what most non-developers probably feel like when they read about what we do on a day to day basis - confused, and maybe a little bored and frustrated, with an utter lack of even basic knowledge. It doesn’t help that DevOps is rapidly becoming a field of expertise unto itself, or that most of the relevant players seem determined to hide behind vague descriptions like “enterprise platform” and “containerization solution.” As a day to day working developer, adding an entire new skillset can be a daunting and intimidating prospect.