Why Your Dockerfile Sucks for Production

Harpooned by a Dockerfile that sucks
Don’t get harpooned by a Dockerfile that sucks

Your Docker Compose file might suck too.

I admit it! I am guilty of making Dockerfiles that suck.

We’re all guilty of being overly general in our Dockerfiles. Just look on Docker Hub or GitHub. But in some ways it might be making things less consistent across builds.


FROM debian:latest 

Which is fine for testing something or working to build Dockerfiles for development pipelines. But let’s look at the shortfalls and headaches we can all avoid. You never really know what something like the above will get you.

The same applies to running package manager with only package name and no version. In some instances you will want to update a package for security or bug fix purposes. But for Docker in Production you want to stipulate these things.

So first let’s stipulate the right known base image using it’s SHA256:

FROM debian@sha256:52af198afd8c264f1035206ca66a5c48e602afb32dc912ebf9e9478134601ec4

To get the SHA256 you can get it when you pull the intial image you’ll be using to build projects.

$ sudo docker pull debian:8.7
8.7: Pulling from library/debian
693502eb7dfb: Pull complete
Digest: sha256:52af198afd8c264f1035206ca66a5c48e602afb32dc912ebf9e9478134601ec4
Status: Downloaded newer image for debian:8.7


Now you know the exact version you will be running. Now be sure to stipulate for other packages you need to install.

RUN apt-get update && apt-get install -y \
python=2.7.5-5 \
python-pip=1.5.4-1 \
some-package=1.1.1 \
&& rm -rf /var/lib/apt/lists/*

Now you have your Dockerfile not sucking so much for Production use!

You’ll also want to have internal Docker Registry for versioning and storing your containers once you build.