The Importance of a Good Docker Image Naming Strategy

Today I needed to debug why an application was misbehaving in a none development environment. The first thing to do for sanity sake is ensure that the code you are debugging is the code you expect has been deployed.

Luckily in my case we use a very good naming strategy so we can easily inspect running containers in an environment and tie it back to the code. For example in our Kubernetes environment for the pod I am investigating I would run:

kubectl describe pod my-apps-pod-3213sdasa

which would output something like the below:

ame:           my-apps-pod-3213sdasa
Namespace:      default
Node:           k8s-agentpool1-83254052-6/10.240.0.11
Start Time:     Sat, 10 Mar 2018 04:22:11 +0200
...
Containers:
  my-app:
    Container ID:   docker://04bad116fda85f46cdc5aa4d77088020629e63c65c118c0254a681f94150c53f
    Image:          my.companies.docker.registry.io/foundery/my-app:f5699e1
    ...

The line I am looking for in this case is this one:

Image:          my.companies.docker.registry.io/foundery/my-app:f5699e1

In the above I can see what docker image is being run in the pod. The hash at the end of the registry URL matches with a hash of the code that is running in the container. This makes it trivial to easily link this back to the exact code being run making debugging just that little bit easier.