Add Image Tags to reflect base image updates

[canon-cmi-brian-mcdonald]

Is your feature request related to a problem? Please describe

The problem I am facing is evaluating changes that have occured within nginx docker image between publications. Currently this is difficult to trace for base image updates as in that case the nginx git repo doesn't have a new commit, the image created date doesn't change, and the image tag doesn't change. For a deployment environement where changes need to be evaluated before deployed, this pattern makes it diffecult to determine what those changes are. There is a more descriptive use case in the Addional Content section below.

Describe the solution you'd like

I would like a tag that is changed on every docker image publish and documentation for how to find out the changes in that image's contents from the pervious publication.

I would suggest using a build number or publication date for each image type on docker hub. Assuming a build number of 12345, this would introduce the following tags for the 1.27.3 version:

• 1.27.3-bookworm-12345
• 1.27.3-bookworm-perl-12345
• 1.27.3-bookworm-otel-12345
• 1.27.3-apline3.20-12345
• 1.27.3-apline3.20-slim-12345
• 1.27.3-apline3.20-perl-12345
• 1.27.3-apline3.20-otel-12345

I am not familiar with the nginx docker publication build, but what I can gather from documentation the build number could be derived from https://doi-janky.infosiftr.net/job/update.sh/job/docker/. Otherwise, the epoch date at publication time would likely be enough information to track down changes.

Describe alternatives you've considered

Once an image has changed, it is possible to detect a change has occurred by comparing digest ids and image ids from dockerhub images vs deployed images. Furthermore, that image can be inspected with history command to tell how the image layers may have changed. While this is the beginning breadcrumbs needed to hunt down information, it is not a straight forward process.

One "solution" is accepting whatever image is on docker hub without inspection. Note that for my use case this does not work as changes need to be evaluated.

Other docker images have solved this issue by using git commit hashes as docker tags. This wouldn't work for nginx use case as base image updates do not require code changes.

Another alternative is embedding the base image version into the name. So instead of 1.27.3-bookworm, the tag would be 1.27.3-bookworm20241223 as that is the tag pattern in https://hub.docker.com/_/debian. Similar for 1.27.3-apline it could be 1.27.3-alpine3.20.3. This would be a lot clearer for consumers, but I haven't evaluated those repos tagging policies. It is possible they have the same issue with publishing image updates without changing tags.

Additional context

As an example use case, a deployment I maintain had nginx:1.27.3 deployed to it on Dec 5th. The base image for this tag is debain:bookworm. On Dec 23, there was a new build of debain:bookworm, which resulted in a new nginx image being deployed to docker hub. There was no indication of a change on docker hub, as all the tags remained the same. An auditing system caught that my deployed image was out of date due to the digest and image ids not matching with what was available on docker hub. After a few hours of debugging and digging around nginx code, build files, and deployment files, I determined that it was a new build of debain by running history on the image to see the change "# debian.sh --arch 'amd64' out/ 'bookworm' '@1733097600'" to "# debian.sh --arch 'amd64' out/ 'bookworm' '@1734912000'". Needless to say, this was not an straight forward process as a consumer of the docker image. For environments that require change evaluations to occur, it would be helpful for a clear indication of changes in container content.

Note this is similar to issue #863

[thresheek]

Hi @canon-cmi-brian-mcdonald!

I feel like the feasibility of adding additional tags is questionable, but I'd like to redirect that question to Docker Library infrastructure maintainers, @tianon @yosifkit, as this is more of a general question on "how the library works" rather than something specific to NGINX or its docker images on their own.

In any case, if your environment requires immutability, why don't you just use the image digests instead of tags? They are guaranteed not to change and you'll be able to control what you're deploying.

[canon-cmi-brian-mcdonald]

Thanks for the quick response @thresheek

The digest does work for making sure a certain version of an image is deployed. It also can be used to determine if the deployed image is different from the latest image on dockerhub. But what it doesn't give is an easy way to tell why there is a differences between the deployed image and dockerhub image.

For instance, if the deployed image has tag 1.27.2 and dockerhub image has tag 1.27.3, its very easy to see what changed in the nginx change logs nginx change logs. Or with the current tags, I imagine a change from alpine3.20 to alpine3.21 would also be apparent. I am hoping for the same sort of transparency for any published change, and I think a build number tag could do that.

Perhaps I'm missing something from docker / dockerhub functionality, but it seemed to take a bit of digging to uncover the root change between publications without a tag difference.