Rails Development On Docker – Part 1

On-boarding, the process of bringing a new worker into the fold, is often the hard part in starting at a company. Usually you are sat in front of a company computer and given a wiki link, GitHub repository, or maybe just an email with the steps for setting up your machine. If you’re lucky it’s been updated in the last year. We have the tools to do this better now and I want to explore them with you.

The first time I remember an on-boarding experience as a developer was at a well-to-do contracting firm. It wasn’t my first or second software position, but it was definitely the one where I discovered on-boarding as a singular concept. It was a painful experience, but not unique to that company.

This time I’m the new developer at Laurel & Wolf. I don’t think I was given a wiki or email list, but that’s probably because I didn’t give them a chance. I had one month to move and as they weren’t a remote company it was unlikely I’d be able to contribute to something the team was doing. I’ve never been one to sit on my hands however and so I talked my co-workers into letting me do a non-deadlined experiment.

I had been recently playing a lot with Docker for local development, but I hadn’t perfected it. In fact my main points of contention seemed to be things that wouldn’t be fixed for a few years. See, Docker is in a unique and precarious situation: Because it was “born” in the modern era of software, where code meets social networks, it has the dubious trait of being seen as both standard and immature. You can read at least one-hundred blog posts a week about Docker and yet the next day you’ll find something entirely new.

One good example of the edge in which Docker resides is the local development story. The idea is simple: Your application requires a certain environment to function. Not every development machine is fully equipped for that environment. You either cut out those development machines or you use virtualization. Using virtualization allows the developer to be machine agnostic which is a boon any company should recognize.

Learning Pains

Every technology has growing pains and Docker is not an exception, however there is a difference. Docker seems to have this community where things are prototyped under a non-normal name (boot2docker) and then when the community realizes the importance of a tool it consumes it under a new name (docker-machine). There are a few things I’ve learned throughout the whole process:

  1. boot2docker-cli (the thing you install from brew install boot2docker) is deprecated in favor of docker-machine.
  2. Don’t install anything from brew anymore, because now we’ve got Docker Toolbox.
  3. Grab a drink and some food you’re going to be here all night.

So knowing those pre-tips I’ll get into each of the tools and what they encompass. You can give up on learning the internals of all these tools, because there’s way too much.

docker-machine

Presumably you’ve got a computer right now and as long as it’s a Windows or Mac you’ll have access to docker-machine. The docker-machine command line is hilariously robust. Hilarious because it’s such a new tool. It will manage, mutate, and communicate with your virtual machines (locally or remotely).

The express purpose of this command in this context is to create the development intermediary. You’ll do this by running:

$ docker-machine create -d virtualbox laurelandwolf

For us this creates a specifically named virtual machine on top of virtualbox. If you look at the --help documentation for the command you’ll see a whole lot of options we’re ignoring. It creates this virtual machine with the highly acclaimed boot2docker-iso, an incredibly lightweight and efficient intermediary.

The next steps will seem very familiar to anyone who used boot2docker-cli:

$ eval "$(docker-machine env laurelandwolf)"

This exports the environment variables needed for docker, docker-compose, and other tools to talk to the right VM and containers. The main difference between boot2docker-cli and this is that it’s specific to the virtual machine intermediary. If you have multiple Docker-based development projects you’re going to need to figure out how to run that script on a per project basis. These set environment variables allow you to talk to the created machine.

This is the first post in this series and we plan on having many more so thanks for reading! If this sort of thing is something you would enjoy working on we are looking for awesome engineers to join our team.


Docker and the Docker logo are trademarks or registered trademarks of Docker, Inc. in the United States and/or other countries. Docker, Inc. and other parties may also have trademark rights in other terms used herein.