Thoughts on Containers for Development

The new container and Docker filled world has led to many new opportunities for developers, but is it enough to satisfy a picky nerd?

Edit: 5/3/19 Turns out VSCode is working on a solution to the problems I mention!

What are Containers and Docker?

There have been hundreds (if not more) articles introducing containers and Dockers. I’ll let others explain what a container is and why you would want to use Docker.

A quick summary of the benefits: Docker makes it easy to create reproducible sand-boxed containers with configuration files, as well as access a large repository of software for ease of getting started.

Why I care?

Like many developers I have a very strong (possibly unreasonable) preference to the tools I use to write code and the way I’ve setup my computer. It is both my digital home and workspace, and personally, I like to keep things neat and tidy. My belief, is that the text editor or IDE someone uses should be up to them. The same should go for their other tools, applications, and operating system (Linux being the best of course). Being able to stick to the tools you know also has practical benefits, like making it easier to get up and running on a project (not that having to learn new things is inherently bad, but it does take time).

Another pain point for developers is dependency management. If you work on multiple projects (or just use software tools) you might end up installing different versions of the software you need to get a project going. This can lead to headaches, broken code, headaches, weird errors, and headaches. Not to mention that just installing the stuff you need to get working on a new project can be unnecessarily difficult.

I’m not the only one who thinks this either.

Opportunity

Container technology has moved us to the point where it’s feasible to develop on different platforms and tools without running into dependency issues. For instance, in the below example, I was able to configure a Vue.js project using Node and npm with only Docker installed on my system.

Example

Let’s say you wanted to experiment with some new cool framework (Vue.js is my placeholder for this) that didn’t have a standard Docker image to download. Well you can use another Docker image that has the tools you need to setup a custom image for that framework. The results can then be saved onto your machine by using a shared volume. From there you can use a version control system and a custom Dockerfile to share that image with others on your team.

This line creates a Node container with the tools we need to download the Vue CLI to setup the project:

docker run -it -p 8080:8080 -v "$(pwd)":/app -w /app --rm --name vue-test node:10.11.0-alpine /bin/sh

Now we are in the Node container and can run the commands we need:

npm install -g @vue/cli
vue create hello-world

And then fill out the settings the CLI provides.

Now we have a Vue.js project setup! If we wanted others to be able to use it with Docker, we could add a Dockerfile that pulls in the dependencies we need.

# In Dockerfile

FROM node:9.11.1-alpine

# Make the 'app' folder the current working directory
WORKDIR /app

# Copy both 'package.json' and 'package-lock.json' (if available)
COPY package*.json ./

# Install project dependencies
RUN npm install

# Copy project files and folders to the current working directory (i.e. 'app' folder)
COPY . .

# Open up the container's port 8080
EXPOSE 8080

# Run with live reloading
CMD npm run serve

Check that Dockerfile into version control and ta-da, everyone else can now work on your new project without anything more than Docker.

Current State

A lot of developers are using Docker. Many companies, such as Microsoft, Google, and Amazon, are providing services and special support for it. You can download and run basically any popular open source software with just one line in a terminal. Even small teams, like the Open Source Club at UF, is able to effectively use it to work on and deploy projects.

However, there are still a handful of roadblocks preventing Docker from being the end-all for development.

• The technology is still new, and can be hard for people to wrap their mind around (for instance, I’ve been playing with it for a year and still feel like I’m missing things).
• At the Open Source Club, we’ve had a lot of people confused about getting Docker working on non-Hyper-V enabled versions of Windows. The workaround is to install Docker Toolbox, which has performance implication and seems to be buggier. This is of course, not ideal.
• I’ve also had some random issues, like containers not being able to connect to the internet unless I restart the docker service. These aren’t deal breakers as much as disappointing and annoying problems.
• Getting additional language specific tooling, like linters or debuggers, working is not a trivial task unless it’s like JavaScript and already supports attached debugging (where tools connect to the software over a networking port) or has special tooling like .NET and Visual Studio. This is a really big deal, as these tools help developers find and fix problems much faster than just printing stuff or re-reading code.

Examples of progress

All is not lost! Here are some examples that either make it easier to use containers for development or are interesting steps to a better container-ed future.

• Multi-stage builds let developers to create Docker images in several steps, allowing for optimized production code as well as intermediary debugging code.
• Docker Compose also supports easily changing configuration between development and production code. This and the multi-stage code does remove the reproducibility benefit of Docker a little bit, as the code you run on your machine is in a different environment than on the server, but it’s at least a very controlled environment.
• Fedora Toolbox is an attempt to easily create “pet” containers for projects, while still sharing things like your user information, between the regular OS and container.
• podman is another tool for container management. It has the capabilities of the Docker command line tool, without needing a dameon running in the background. This allows it to be less resource intensive than Docker and means it respects your user configuration more (preventing issues like this).
• Fedora Silverblue is an attempt to create an “immutable” operating system. Essentially, the OS is managed with something like a version control system (so you can easily revert to a previous state if there is a problem). All other software on the system must be added with (drum roll please) containers! So for this OS to succeed in the developer market, it will need to solve some of the issues presented above (and those fixes will probably apply to other situations as well).

Summary

Containers are the future of development, at least I hope so. As people and tooling become more used to the container paradigm, the problems I mentioned above will hopefully go away. I’m looking forward to following (and using) some of the projects mentioned, as well as containers in general as they impact the field of software development.

Till next time,
- Matthew Booe