I do a lot of programming in a lot of different languages at different times for different reasons on different machines in different places. One of the inevitable side effects of this is the dreaded "it works on [insert wherever you are not here]". I experience this effect on steroids when doing pipeline development where I can never count on the current version of the os or toolchain being used to perform any particular task. The most recent incarnation of this happened when my 12 year old son asked me to teach him how to deploy his own minecraft server and learn to code. Stop me if you've heard this one before - he has a Windows machine and I have a Mac and foobar - putting aside whether teaching a kid to program on a Windows machine is child abuse - I was faced with instant problems with pathing related to Terraform.

The problem with developing on your local machine and using the product of your development is beautifully illustrated in some images I borrowed from

The corresponding github repo is the single best resource I have found for learning about and teaching others about the container ecosystem and I highly recommend it. Take the time to learn how to build the slides and you will realize just what an invaluable resource this really is.

We can see in these four images how the problem of deploying code across multiple hardware domains creates problems and how the shipping industry is a great analogy. Ultimately we need a way to encapsulate our code with it's configuration and dependencies in a reliable way that can be executed anywhere.

Using Docker, or other container runtime environments, you can divorce the OS, executables and configuration from the local environment. This lends itself directly to making it easier to prepare your applications for Kubernetes or any of the various cloud flavors of container instances. I even use Docker when deploying to compute instances because it greatly simplifies the setup and maintenance of any given machine.

Most importantly it gives you a way to define your development environment as code so when you share it with someone else or come back to it 6 months later you don't have to try and figure out what the magic state of your machine was when you created it. Given the simplicity of doing it I am often surprised by how little I see people doing it. Just recently I needed to add some code to a cli built with Go and cobra and was struck by the extensive documentation on how to set up you local environment. One dockerfile and one docker-compose file and 5 minutes later no developer should ever have to suffer "the set up" again. Run docker-compose run --rm magicgocli and proceed with your brilliance future developer.

Tools like JetBrains GoLand are now supporting run targets where you can configure your IDE task to use Docker, or other remote hosts, to run your code.

Some examples of how I use this in my own life include:

I use github pages to serve this blog as I showed in my first post. When I want to work on a post locally I don't want to be dependent on what machine I'm on or what the configuration was the last time I used it so I use a simple docker-compose file that allows me to run docker-compose run --rm blog whenever I need to stand up my local environment. The compose file allows me to keep my run command short and looks like this:

If we decompose this file we can see a lot of super cool stuff going on. Running top to bottom we have:

Similarly for Terraform I can use their officially maintained image to execute my local code by starting an interactive container mounted to a directory

Here I use docker-compose with a Dockerfile to tweak the base image for my purposes by making directories to mount various things to that I want to use:

Then compose file looks like:

What is even cooler is that after starting my container I can exec in with multiple sessions using docker exec -it 19a9 /bin/sh to perform terraform tasks on different directories simultaneously!

In a more complex scenario when I want to run multiple API endpoints locally to test some microservices I can use docker composeto define multiple container instances and start them as a group using docker-compose up. Here I create a docker-compose.yml file that mounts the same source code (volumes) to 3 separate containers (api1, api2, api3) using the same base image (golang:1.16.2-buster) from the Go team and map the container port (1323) to different host ports (3140, 3150, 3160).

Hopefully what these examples show is how easy it is to use container technology to codify development environments for reliable and repeatable local use with the only requirement being the presence of the Docker runtime. Not using containers for local development leads to slower and more painful development as the size of your team and the number of other teams you collaborate with increases.