This post is originally published as article within SDN Magazine on October 13th, 2017.
During the past year I supported several clients in their journey toward Containerized Delivery on the Microsoft stack. In this blogseries I’d like to share eight practices I learned while practicing Containerized Delivery on the Microsoft stack using Docker, both in a Greenfield and in a Brownfield situation. In the seventh blogpost of this series I want to talk about Explicit Dependency Management.
PRACTICE 7: Explicit Dependency Management
A lot of Docker and Compose files I have seen contain a reference to images, without specifying the version of the image, or with the default “latest” tag. Not explicitly specifying the version of an image can result in unexpected behavior and this is very risky.
The reason for this is that every Docker host has its own local Docker image cache. Once an image-tag combination is found in your local cache, Docker will consume the cached blob on docker run instead of downloading the blob from the container registry. Making use of the “latest” tag could result in the fact that you get an older version of an image than the image you actually want. As shown in the figure below a docker run cornellk/test command on Host01 will run version 10.0.01 instead of the download of image version 10.0.02 from the registry.
You can test this scenario yourself by comparing the result of a docker run and docker pull command on an outdated image in the local cache. As you see in the image below, docker pull downloads newer image layers from the registry where docker run just starts a new container based on the outdated cached image.
Using the “latest” tag makes your build-and-release process non-repeatable. To avoid this, all you need to do is explicitly reference which version of an image you want.
Interested in the next practice? See PRACTICE 8: Environment-as-code pipeline and individual pipelines