Are Docker official images rebuilt when there is a upstream change?

Question

Are Docker official images always rebuilt whenever a newer base image under the same tag, as the child image was based on, is pushed to DockerHub to adopt upstream updates?

For example, if an elasticsearch:5.0.0 image is using openjdk:8-jre as base, when a newer openjdk image with same tag (8-jre) is pushed into Docker Hub, will elasticsearch:5.0.0 be rebuilt (ending up having a different digest)?

Answer 1

No.

There is nothing that automatically rebuilds images. It's up to the image owners to build a new image and push it to Docker Hub if they want an upstream change to be included in their image.

Answer 2

No, that is not something that container registries like DockerHub offer at the moment.

You can, however, integrate a tool such as renovate in your source code repository so that you automatically get a PR when the base images used in your Dockerfile change. So if you configure your CI/CD in a certain way, you can seamlessly update your Docker images and deploy them automatically.

Documentation reference: https://docs.renovatebot.com/docker/

Answer 3

In practice, with the official images, the current patch image will be rebuilt and pushed when the base image is updated (along with the associated semver tags). If you are using something older than the latest patch, you should not depend on that to be updated. I only know this from conversations with the maintainers, this is not formally documented and is subject to change without warning.

Specifically for elasticsearch, at the time of this answer, 8.11.1 and 7.17.15 are explicitly identified as being maintained, which would imply that the elasticsearch:5.0.0 image will not be updated again, and that should be apparent since it was last pushed 7 years ago.

As another example of this, looking at the golang image:

• Alpine: pushed Nov 7th which is the same time their Dockerfile was updated.
• Debian: pushed Nov 22nd despite their Dockerfile seeing the same Nov 7th update, because the Debian image was updated Nov 21st.
• Older 1.21 patches were not updated, so 1.21.4 was updated but not 1.21.3 or 1.21.2.

This is specific to how Docker manages their official images. Images from other sources may not do this, and your own images would need to be rebuilt to take advantage of an updated upstream image. Managing your images by explicitly pinning to a digest for each tag, and regularly updating those pins, is a good way to ensure CI systems are updating as base images are changed.