How to find availability of newer versions of docker images in docker-compose

Question

How to find availability of newer versions of docker images in a docker-compose file containing multiple services, if you don't happen to use the latest version of a docker image (similar to npm outdated, gradlew dependencyUpdates gem outdated)

Answer 1

Docker images don't have a concept of versions like a package manager does. Docker images have tags. Those tags can be anything that the image author chooses them to be. Some image authors may publish tags that indicate the version of the software that is in the image, and other image authors may simply push newer images over top of the same tag over time.

For example, if you use the nginx:mainline tag when specifying the image, it will grab whatever the current nginx mainline version is at the time you pull the image. This is due to the policy that the nginx official image publishers have in the way they tag images. They also have specific version tags such as nginx:1.21.1 which happens to point to the same blobs as nginx:mainline at the time this answer is written.

Given this particular image tagging policy, you can set docker-compose.yml to point to nginx:mainline and regularly run docker-compose up --pull -d. This will cause compose to try to pull the nginx:mainline image again, and then cycle any containers that need to be cycled. In the case of a newer nginx:mainline image being present on the registry, compose would pull that new image and then recreate the container using the new image.

docker-compose itself does not have the ability to compare what is on a registry to what is present on a local docker engine.

You can query the registry via the API to see the sha256 digest that a given tag returns, or use the reg CLI tool to interact with a registry: https://github.com/genuinetools/reg

Continuing with the nginx:mainline example, say I deployed my compose file with nginx:mainline when the corresponding version was 1.20.0, but 1.21.1 is out now. I would do the following to make a comparison:

docker inspect nginx:mainline --format '{{.Id}}'

This would return the long sha256 image id for nginx:mainline

I can then query the repository with the following:

reg manifest nginx:mainline

This returns a json document describing the image and its layers. In the config key, there is a digest key. If this key matches, you know it is the same image. If it is different, you know that the remote copy is different.

You can use jq in conjunction with this command to get the correct value:

reg manifest nginx:mainline | jq -r .config.digest

This means that if I rerun docker-compose up --pull -d, the remote image will be pulled and my container recreated to use it.

--

If you use the specific version tag instead of the mainline tag, then you could script out available tags and try to programmatically determine if there's a new version that way.

In the case of the nginx repository, the version specific tags (excluding variants like -alpine) always only contain numbers and dots. Because that's this image's specific strategy for versioning in its tags, I can get a list of those like this and sort them by version:

reg tags nginx | grep '^[0-9,\.]*$' | sort -V

I'd have to determine some way to compare that list of versions with the current version, and that's covered in this stack overflow question: How to compare two strings in dot separated version format in Bash?

Of course, this is only an example based on the image tagging strategy of a docker official image that specifically tags versions of the software in this particular pattern. Other image authors may have their own pattern that you would need to implement logic for.