Achieving smaller, easier to manage, more secure containers with Docker right now

The ideas present on Darren Rush's post are interesting. However, I think he misses the point on his three main arguments. Most of them can be attained today, with Docker.

Smaller containers

It is indeed possible to build large Docker images. You could say this is the default, if you use common base images such as Ubuntu or CentOS, both very popular on Docker Hub at the time of this writing.

This is not the only way. BusyBox provides a base image which is very often packed with more than enough tools for any container at just around 2.5MB.

In some cases, it is even possible to build images from scratch. Kelsey Hightower has a great post on this for Go: Building Docker Images for Static Go Binaries.

The lesson to learn from his post is not necessarily the use of the scratch image but the process of refinement trying to build smaller images. It is possible, right now.

Ease of managing

The immutable server idea sounds great. I'll admit I wasn't familiar with the concept until now, what I say has to be taken with a grain of salt.

Once again, this can be attained with what we already have today. Recently I've gone through the trouble of setting up a continuous integration process that would run tests on every commit of my code, build a new docker image tagged with a build number, push it to a registry and deploy it to an updated environment on Amazon BeanStalk, powered by CircleCI.

Rollbacks are brain dead, if necessary, accessible through the push of a button. 99.99% of the time, they shouldn't be, since the deploys only happen when tests are green. Each version of the container is independent, runs only one microservice, can be pulled and tested on any environment with ease.

This does not contemplate the idea of Unikernels, which may be a hole in my argument. However, it still holds true that the promise of less surface area, faster deployment and easy management can be attained today, with the tools we have right now.

More secure containers

Security in containers is still a moving target. Container breakout has been known to happen before Docker 1.0.

Docker 1.3 has done a lot of work for security. The Docker team has been very straight-forward on this subject, providing extensive documentation on docker security.

Once again, this ties into the areas explored previously. Smaller images, with less surface area, are naturally less prone to holes in security. Individual deploys of specific tagged images of containers removes doubts about variations in the underlying structure. Docker 1.3 provides new options for fine tuning SELinux and AppArmor, reducing the need for containers running in privileged mode.

It is clear that this area is still a work in progress.

Towards best practices

Docker is still a quite recent development, having hit 1.0 less than 6 months ago. Nevertheless, 1.1, 1.2 and 1.3 have been released already since then.

For most of us, including myself, working with Docker is a novelty. We, as a community, are learning, each and every day.

Smaller containers are already possible, well orchestrated deployments as well. As said in one of the Hacker News comments:

there aren't yet best practices about building minimal and secure Docker images

One of the joys of the work with Docker is the process of learning, given how new everything is. Best practices are emerging.

Those new technologies can be interesting and should not be dismissed. It is too soon, however, to believe Docker can already be left behind. This is just the beginning.