Best practices when working with Docker images

Shipshape

Containers have become the most convenient method of deploying complex applications. This convenience is shared both by developers, who can comfortably work in the same environment as the final deployment, and by the staff responsible for installing, updating, monitoring, and troubleshooting the application, whether they are traditional sys admins or DevOps.

Although several container solutions are present on the market, with varying levels of features, maturity, and flexibility, Docker is by far the most popular. In this article, I offer a couple of useful tips to make your work with Docker images and containers more efficient.

Be Careful with the "latest" Tag

Despite its name, latest doesn't mean the image tagged as such is actually its most recent version – it's just the default value assigned to images that don't have a tag assigned. Therefore, if you create an image without tagging it, it will be tagged latest – unless you specify another tag. Therefore, if you create new images with other tags, latest will not be the most recent.

Moreover, because latest is just a shortcut for the default value, it can be easily overwritten by other team members; that is, if you don't tag your images, each new image pushed to the registry will have the latest tag automatically applied, which might create confusion.

If you don't explicitly specify an image tag, Kubernetes implicitly assumes it's latest , but because tags are mutable and latest is easily overwritten, it's hard to say what image is really deployed. What is more, if you set imagePullPolicy to Always and one of your pods dies, Kubernetes will pull the latest image, possibly resulting in a different image than in the other pods. That itself is bad enough and might become worse if your latest image is broken.

What to use

... comments powered by Disqus