Version/Tag distroless images

[saturnism]

For Java image, it's gcr.io/distroless/java, but doesn't have any reference to which Java version. This is important to be tagged.

[lathama]

@saturnism can you share how you would suggest the tagging be done?

[saturnism]

similar to https://hub.docker.com/_/openjdk/

we should at least call out 8u???, and always update 8 to point to the latest of 8u...

[saturnism]

quick ping.

[lathama]

Currently it is built off of Debian Stable so only those packages would be used but you can use the cc image and drop on your JDK of choice in a multi-stage docker or update the bazel build in your own bazel setup.

[saturnism]

Hmm.. I'm not sure I'm following how this relates to tagging the container images.

The issue is that untagged images aren't stable, and relaying on latest tag is not too great.

[dlorenc]

Can you explain what you mean by stable? All images are tagged with the git commit they were built at, and are also available by their sha256 digest.

[asaikali]

As a user I would like to know exactly what version of java my code is running with. The latest tag does not tell me if it's JDK 8 update 171 or JDK 8 update 131 or some other value. It makes my build unstable since every time I run it I might end up with a different version of the java distroless image. Once you add support for Java 11 I assume latest will point at java 11 not 8 so my builds will break because I am using the wrong version of java with my app.

[saturnism]

Where is the list of git commit tags? and is there a documentation on which git commit represents which JDK build?

a tag is helpful to expose this in a readable and easily understood way.

[darkobits]

Adding my support for this.

In addition to providing a quick, easy way to determine which version of X we're getting, tags provide a way to pin to a specific version. Otherwise, you're always implicitly pulling the latest tag, which is a moving target. Without the ability to pin to a specific tag, consumers have no way of knowing what they're getting.

---

Brief addendum, root cause possibly being my docker-fu is lacking:

Because these images are not hosted on the public registry and because the Docker CLI doesn't seem to implement a command that enumerates the tags for an image, I've had a difficult time trying to determine what tags actually available.

Specific to the Node image:

It would be extremely helpful to indicate the Node version used here, especially considering that none of the source files under that directory make any reference to the Node version being used. I did finally find it here. 😕

[briandealwis]

@darkobits just visit https://gcr.io/distroless/java (or https://gcr.io/distroless/nodejs) — Google Container Registry will provide a nice UI with available images and tags.

[darkobits]

Brilliant! 😍

[briandealwis]

There have been quite a few changes since this issue was created. I'll collect the different requests here with pointers to follow-on issues.

@saturnism: we should at least call out 8u???, and always update 8 to point to the latest of 8u...
@asaikali: Once you add support for Java 11 I assume latest will point at java 11 not 8 so my builds will break because I am using the wrong version of java with my app.

We now have and maintain :8 and :11 tags, and the images are now branded with their JRE build information in the JAVA_ENVIRONMENT (below).

@asaikali: As a user I would like to know exactly what version of java my code is running with. The latest tag does not tell me if it's JDK 8 update 171 or JDK 8 update 131 or some other value.
@darkobits: It would be extremely helpful to indicate the Node version

We're now publishing a JAVA_VERSION environment variable on the java images as per #291. #301 requests similar variables for the other images.

#276 requests exposing this information on image labels too, but we need to come up with a label naming scheme.

@asaikali: It makes my build unstable since every time I run it I might end up with a different version of the java distroless image.
@darkobits: tags provide a way to pin to a specific version

Since Docker tags aren't immutable they aren't really suitable to pin to a specific version. If you want reproducibility, you really need to reference the SHA1 as the distroless base image updates fairly often, which cascades through the other images.

---

So the original request is to tag images with their JRE build.
My Bazel-fu is weak, and propagating the version information for a built image to the actual image tagging is non-trivial. I suspect that we could extract a suitable version tag from a container image annotation.

[donmccasland]

related to this conversation:
https://groups.google.com/g/distroless-users/c/Uufl6cxWgMI

[tothadam98]

How can I know which one is java 15 from '/gcr/images/distroless/global/java'?

[Guillaume-Mayer]

@tothadam98 There is no java 15 but there are java 17, java 11 and java 8.