Neil Gupta
 

Taking Inventory of Docker's Black Box

690 words • 3 minutes to read

If you’re not actively using Docker, it’s pretty difficult to figure out the difference between all the tools in the docker ecosystem. When I first started using docker last year, it all felt like a black box. I could get everything running, but if something broke, I had no idea where to look. So to help anybody who’s just getting started, here’s a brief breakdown of the different components that are used in a successful docker project.

First, docker is an ecosystem of tools for containerizing your application so that it can be repeatedly installed and run in a consistent environment, even on different machines.

Currently, running Docker for Linux in a VM is more performant than running native Docker on Mac, so let’s get started with a VM to run Linux.

VMware / VirtualBox

The virtual machine runs a virtualized Linux OS host for docker. I recommend VMware for the best performance, but the latest Virtualbox has caught up a lot and it’s free. Docker recently released native Docker for Mac and Windows, but I don’t recommend using it yet because the performance is abysmal. Once it is ready for prime time use though, the VM requirement will go away.

In the meantime, we need some way to manage our new virtual machine. It wouldn’t be very repeatable if we had to manually install and configure a whole new OS every time. That brings us to…

Docker Machine / Dinghy

Machine is a tool that lets you install Docker Engine on virtual hosts, and manage the hosts.

One level up from the virtual machine is docker machine, which is a tool for creating your virtual machine and installing docker engine on it. However, if you’re on a Mac, I recommend using Dinghy instead, which is a third party wrapper around docker-machine. It behaves in almost the same way, but adds some key services, such as mounting your home directory as a shared NFS volume so that your VM can access your code on your local machine and DNS mapping http://*.docker to your docker host’s IP address. Dinghy makes development with Docker significantly more pleasant. It will also no longer be necessary once we can use native docker on Mac.

Docker Engine

Engine [is a] lightweight and powerful open source containerization technology combined with a work flow for building and containerizing your applications.

Next is docker engine, which is the core of docker. It lets you define and run an app container with a build script, known as a Dockerfile. When you build your docker image, it will run your Dockerfile so that your app always has the same environment, no matter what.

Docker Compose

Compose is a tool for defining and running multi-container Docker applications.

The next level up is docker compose, which allows you to define and manage multiple containers for a single app. This is extremely useful when working with a service-oriented architecture or many independent dependencies. For example, when developing locally, you might have a docker image for your database, your main app, your supporting service, your redis cache, and your fake_s3 server. You can link these images together with Compose, so that when you run one of the services, anything else it needs also boots up or you can boot up the whole system with one easy command. This is the tool you will be interacting with most of the time.

There are other tools in the Docker ecosystem but these are the core ones you need to get started locally.

In practice, once you’ve installed all of the above tools you can run dinghy create to setup your VM, dinghy up to boot it up, and then once you’ve written your Dockerfiles, docker-compose build and docker-compose up to run your app. To run commands within your VM, you’ll want to prefix everything with docker-compose run --rm [service name] (i.e. docker-compose run --rm web bundle install).

Hopefully that helps get you rolling with Docker!

Written on August 28, 2016 in Chicago.