Tagging scheme

594 views
Skip to first unread message

Don McCasland

unread,
Oct 31, 2019, 5:04:44 PM10/31/19
to Distroless Users
Now that we're delivering a whole bunch more variants, with more to come, I'd like to discuss tagging and registry organization.  

We are currently delivering into folders:
base, base-debian9, base-debian10, cc, cc-debian9, cc-debian10, static, static-debian9, static-debian10, python2.7, python-debian9, python2.7-debian10, java, java/jetty, nodejs, python3, python3-debian9, python3-debian10, dotnet

And we deliver several variants of these images in each of the folders, tagging them things like:
latest, nonroot, debug, debug-nonroot, 8, 8-debug, 11, 11-debug, java8, java8-debug, java11, java11-debug

What's wrong with that you might ask?

1) When we deliver a new version of the images, the tags move to point to the new variants, and we lose any idea of which of the old versions were vanilla, nonroot, debug, java8, or java11.  
2) Subsequently there is no way to find the last X versions of 'nonroot' if you're trying to debug your runtime environment
3) Variant labeling is inconsistent from folder to folder.  We have python2.7 and python3 folders, but java8 and java11 tags
4) We have to combine variant information into one namespace, leading to things like debug-nonroot, or java8-debug-nonroot-milkshake-frenchfries or something
5) We can't use 'staging' tags to deliver and then test new sets of images

Proposal:
I'm going to recommend using registry folders to contain all information regarding baseOS, language, version, and variant.  The only tags that will be used are 'latest' and 'staging.'  The primary variant will be delivered in the base directory, every other variant or variant combination will have another folder.

e.g.
will become

will become
becomes

becomes

becomes

becomes


Any thoughts before I start on the PR?

Appu Goundan

unread,
Oct 31, 2019, 5:22:51 PM10/31/19
to Distroless Users
Curious if we should group by "debian" instead of runtime ("java", etc):

gcr.io/distroless/debian10/java...

Ray Tsang

unread,
Oct 31, 2019, 5:24:52 PM10/31/19
to Distroless Users
most of the current practices already exists, e.g.


It'd be nice to use the same convention, as oppose to something completely different.

For Java, for example, I'd prefer gcr.io/distroless/java:11-debug

Don McCasland

unread,
Oct 31, 2019, 5:26:01 PM10/31/19
to Appu Goundan, Distroless Users
I think this is a valid idea.  Group by a baseOS.  

Unfortunately, we haven't yet introduced debian10 into all the images, and I assume we won't for dotnet (what's that based on anyhow?).  

And all of the documents refer to the primary kinds of images as: base, cc, static, java, python, nodejs, dotnet right now.

--
You received this message because you are subscribed to the Google Groups "Distroless Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to distroless-use...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/distroless-users/8d2a946f-9829-4c56-b6ac-016f9eb0f287%40googlegroups.com.

Les Vogel

unread,
Oct 31, 2019, 5:27:01 PM10/31/19
to Distroless Users
It seems like a different kind of scheme than is used on hub.docker.com, for example, https://hub.docker.com/_/golang seems to use names that always mean :latest for those names.  ie :1.13.3-buster, 1.13-buster, 1-buster, and buster are all the same.  We also have 1.13.3-stretch, 1.13-stretch, 1-stretch, and stretch; and lastly 1.13.3-alpine3.10, 1.13-alpine3.10, 1-alpine3.10, alpine3.10, 1.13.3-alpine, 1.13-alpine, and 1-alpine, alpine

Don McCasland

unread,
Oct 31, 2019, 5:32:09 PM10/31/19
to Ray Tsang, Distroless Users
Thanks for that.  I'm seeing that 'node' and 'openjdk' are tracked in different folders.  We're already doing that in the distroless registry.  

I'm also seeing something I like which is tagging with extra information about a baseOS variant: 8.16.2-jessie, 8.16-jessie, 8-jessie, carbon-jessie.  I like that because it gives automation the best chances of getting the right images and makes it easy to guess as well.

What about the 'version+variant' tag do you prefer?  


--
You received this message because you are subscribed to the Google Groups "Distroless Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to distroless-use...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/distroless-users/b558ec77-ca94-480e-88be-f73e7ad9f90b%40googlegroups.com.

Les Vogel

unread,
Oct 31, 2019, 5:33:36 PM10/31/19
to Distroless Users
Argh - hit send, I saw Ray's comment and was going to revise -- we should follow a similar standard to hub.docker.com .   I'd add https://hub.docker.com/r/alpine/git to the mix of examples.


With tags that represent the versions of each.  

:10, latest .  debian 10, latest
:10-nonroot
:10-debug
:10-debug-nonroot

etc.

Chanseok Oh

unread,
Oct 31, 2019, 5:36:40 PM10/31/19
to Distroless Users
I am opposed to having different repositories for major Java versions. Almost all JDK images on Docker Hub have major versions as tags.

I once asked to someone (can't remember) why the Python Distroless repositories have 2.7 and 3 separately, and the answer was that they are just totally different that warrants separate repositories. I don't know much about Python 2 vs 3, but I remember in a totally unrelated context that it is like the biggest flop in the CS history or something along that line.

Don McCasland

unread,
Oct 31, 2019, 5:45:05 PM10/31/19
to Chanseok Oh, Distroless Users
Yeah, I want to follow the standards of the primary languages wherever possible.

But the idea of tagging multiple variants in a single repository makes it really difficult to debug problems that might arise due to different versions of the container.

--
You received this message because you are subscribed to the Google Groups "Distroless Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to distroless-use...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/distroless-users/03ff5a4d-4145-4689-8f40-04a7ef91177f%40googlegroups.com.

Ray Tsang

unread,
Oct 31, 2019, 6:09:51 PM10/31/19
to Distroless Users
I'd like to learn more about the difficulties. It's better to be readable and idiomatic - and there are many idiomatic examples. I haven't seen any concrete problem that arises such that can only be solved by not following these standards.

I don't feel `alpine/git` is not representative of an idiomatic language base runtime.  There are lots of stuff under https://hub.docker.com/u/alpine - but not for the reason of what we are doing.
There is alpine/node too. But overwhelmingly, 

To unsubscribe from this group and stop receiving emails from it, send an email to distrole...@googlegroups.com.

Evan Jones

unread,
Nov 1, 2019, 9:37:52 AM11/1/19
to Don McCasland, Chanseok Oh, Distroless Users
On Thu, Oct 31, 2019 at 5:45 PM 'Don McCasland' via Distroless Users <distrole...@googlegroups.com> wrote:
Yeah, I want to follow the standards of the primary languages wherever possible.

I second this! Which seems like we probably want distroless/runtime:version-os-tags ?

I hate to point it out, but most of the images on the "official" docker hub use the Debian release "code names" in their tags. I personally hate this convention: I can never remember which of the names is the newest one, and I have to look it up nearly every time. I'd personally prefer to say "debian10" because that is clearly newer than "debian9". However, I'm also willing to follow external conventions, if we think that is better. In particular: to use the distroless images, you may need to look up the code name anyway. For example, you need to build a Go program that uses CGO libraries with golang:1.13-buster, then use it with distroless/base:debian10 .

That said: this all ranks in my bucket of "I don't care much". I'll back up anyone who decides something sensible. :)

(I'm also happy to continue doing the work to make all the runtime images available on Debian10, with the caveat that I can't really test any that are not Python and Go, beyond what bazel test does).

Evan
 

Brian de Alwis

unread,
Nov 1, 2019, 9:47:24 AM11/1/19
to Ray Tsang, Distroless Users
The idiomatic label schemes used on Docker Hub are caused because Docker Hub supports a maximum two-level naming hierarchy (and single-level for “official images”).  GCR doesn’t have this restriction.

But part of the issue that Don brings up — being able to tell the variants apart — indicates that we should be recording this information inside the image as labels/annotations.

Brian.

To unsubscribe from this group and stop receiving emails from it, send an email to distroless-use...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/distroless-users/db94bc22-8f63-4a3d-b0ed-0f4ea8787bc5%40googlegroups.com.

Don McCasland

unread,
Nov 1, 2019, 9:51:09 AM11/1/19
to distrole...@googlegroups.com, Ray Tsang
Yeah, as I was thinking about this last night.  We can't both follow the standards in other registries AND get what I want.  If we added variant and version knowledge into labels that aren't moved, then we can.  Filtering on the labels then gets you a version history that you can use with container-diff etc

To view this discussion on the web visit https://groups.google.com/d/msgid/distroless-users/AEB2BBE1-7D9E-47DE-B215-EF199F93AD1D%40gmail.com.

Ray Tsang

unread,
Nov 5, 2019, 6:15:28 PM11/5/19
to donmcc...@google.com, distrole...@googlegroups.com
If I were to look for a Java base image, and it's like:

Which one should I choose? Now I have to consider the base image of the OS first. I feel that's usually the last thing to consider.  If I go to gcr.io/distroless/, then the OS base image becomes the first choice I have to make.

On the other hand, the first thing I look for may be the language, so Java (or, openjdk)

Then a specific Java version - because my app can only run on Java 8

Then, a specific update/minor version - because version below 8u192 is not container friendly, I need to know which version is being used in case there is an JDK issue. OpenJDK 11.0.3+ has an issue w/ producing Zip streams. Without this information, I would never know up front nor be able to pin.

Then, maybe the OS - I trust distroless to make a good default choice for me, but if I really cared, then I need to see the choices:
gcr.io/distroless/java:8u222-debian (defaults to most recent stable release)

Then, maybe a specific version of that OS base image.



Don McCasland

unread,
Nov 5, 2019, 6:23:47 PM11/5/19
to Ray Tsang, Distroless Users
I agree on the ordering of the choices.  I would actually also suggest that variants like 'nonroot' 'debug' come before platform.

Also, we can address one of my nitpicks by adding dated labels in addition to the standard labels.  

Let me explain the problem:
If we label an image with latest, 8, 8u222, nonroot, debian, buster, 8-nonroot-debian-buster
And then we deliver another image of the same type, we move all of those tags to the new image.
The old image then loses all the identifying information.  We have no idea whether it was nonroot, debug, debian or ubuntu, etc.

But if we add one last tag to the list that doesn't get moved '8u222-nonroot-debian-buster-201910130013' then all the identifying information lasts.
Reply all
Reply to author
Forward
0 new messages