There was a brief discussion on Reddit about deployment environments in Python which started with a comment asking when to use Docker containers as opposed to virtualenv. I’d like to extend the discussion, sharing my thoughts on the subject.

If you are using a docker container to deploy python applications, you probably don’t need to put a virtualenv inside the container.

Why? Think about it. If you look at the virtualenv documentation:

virtualenv is a tool to create isolated Python environments

Virtualenv creates isolated python environments for installing python applications and their dependencies, preventing things like dependency conflicts and the like.

What about docker? From the Documentation:

A container image is a lightweight, stand-alone, executable package of a piece of software that includes everything needed to run it: code, runtime, system tools, system libraries, settings.

Docker creates a complete environment for an application to run in (including its dependencies, system libraries, OS, etc), making it to be executable on any machine with a docker runtime. If you look at both solutions, from a python standpoint, docker also solves the same issue that virtualenv was built to solve.

So, why would you need both? Well, you probably don’t. If you’re already using a docker container as an environment for your python application, there’s a very high chance it’s the only environment solution you need. You can prepare your image to include everything required for the application so that when the container is executed, the application can immediately start.

What if I need to run something along with the application?

Well, is it a tool that prepares the environment for the application? If so, then it should probably be a step in building your image. If its a server application, drop it in its own container.

Will you ever need both?

Maybe. There is a possibility that both solutions may be required. Does that mean you should use both from the get-go to mitigate that possibility when it appears? Probably not. There’s no benefit to adding complexity now in case something happens, especially when the possibility of it happening is low.

The point is, I believe YAGNI extends to the DevOps/Sysadmin realm as well. Use whatever tools are required for completing the job…and only that. In production environments, it only takes something as small as a bad path to bring hell. Reducing the number of things to manage also reduces the chances of screwing up.

That is all.