docs: docker tags

[casperdcl]

• mention docker tag conventions & update cross-refs (fixes docs: mention Docker tags #86)
• fix broken link (related support #id_anchors link-check#10)

[0x2b3bfa0]

Great! I would even dedicate a separate section to container images, as they're useful on many other scenarios apart from self-hosted runners. Nevertheless, it might make sense to keep them along with the self-hosted runner documentation for now.

[0x2b3bfa0]

Any strong preference for "Docker images" instead of "container images"? I personally prefer the latter since they've become more standardized.

[casperdcl]

image: sequence of layers. container: a running instance of an image. Technically we provide images, not containers.

[DavidGOrtega]

When I read this automatically I can think of 0.6.2-dvc2.1.0-base1-gpu
Maybe this can be expressed in another way?

[0x2b3bfa0]

Perhaps {CML_MAJOR} and so on?

[0x2b3bfa0]

image: sequence of layers. container: a running instance of an image. Technically we provide images, not containers.

Technically, we provide container images as per the OCI specification: that is, images used to run containers, as opposed to virtual machine images, and plain old graphic... images. 😈

Docker just happens to be the brand of one of the first mass-adopted containerization solutions.

Anyhow, this is just a nitpicking exercise. 😄

[casperdcl]

well "container images" is like saying "driving cars." It's superfluous and potentially misleading. Better to just say "cars." Secondly (but minor) - it's probably a good idea to include brand-of-car (Docker) since we don't provide other brands atm.

[0x2b3bfa0]

well "container images" is like saying "driving cars"

Where "container" is "cars" and "images" is "driving". You can provide users with instructions intended to drive a motorcycle, but it doesn't enable those users to drive a six axis trailer. (Just a funny fallacious argument)

In a project that is all about containers, using "images" would probably suffice, but I believe that it makes sense to use the more verbose "container images" in a project that also deals with other kinds of images, like cml-publish (graphic) images and (virtual machine) images for internal use.

it's probably a good idea to include brand-of-car (Docker) since we don't provide other brands atm.

Yes, it seems a goot idea, at least for SEO purposes and people who intend to read the documentation... diagonally. Nevertheless, I would prefer to keep things as generic as possible beyond the mandatory mention to the most popular car brand.

Our container images can be — and are being — used with any other OCI-compatible runtimes, like CRI-O, sysbox or runc. Not to mention that we host them on both Docker Hub and the GitHub container registry.

[0x2b3bfa0]

Here you're some fun facts about container images and how people calls them in the wild:

• Docker Hub itself is being advertised as... the world’s leading service for finding and sharing container images with your team and the Docker community. And they mention the term repeadly all over the place.

• The official GitHub container registry documentation uses them nearly interchangeably, especially after renaming their Docker registry to the more generic container registry. All the documentation headings use container images.

• Google Cloud Container registry uses both Docker container images and container images interchangeably, with a penchant for the latter where SEO doesn't matter that much and they're talking about the concept.

• Incidentally, both the Docker Image Manifest V2, Schema 2 and the latest Open Container Initiative (OCI) Specifications are the same thing with the only major difference being that the latter is a recognized standard.

We may or may not follow them, but it looks like it's a generalized trend.