Toolkit Docker Tips

Internal Element AI Image Registries

There are two (2) internal registries with distinct purposes.

volatile-registry.console.elementai.com: This registry is meant to store images that do not live for long. 24 hours after having been created (or last updated) a tag will be deleted. Once a week, garbage collection is performed on the registry. This is to ensure that images that are only temporarily used are not kept forever. This will typically be used for automated tests.

Note

It is also possible to extend the storage duration by appending -<number>days or -<number>months (like -3months) to the tag used when pushing the image. The maximum duration is 90 days or 3 months.

registry.console.elementai.com: This registry is meant to store images that are susceptible to live for longer. Images meant to be deployed or reused later fall into this category. Housekeeping is not done automatically in this registry.

Pushing an Image to an Internal Registry

Consult the tutorial section Docker Images.

Image Tags

Pragmatic versioning practices help users make the best use of images. The goal of an effective versioning scheme is to communicate clearly and provide adoption flexibility. [DIA01]

There are basically 2 categories of tags: The latest tag and versions tags.

In Summary

1. When tagging: avoid reusing a version tag.

2. When launching a job: try to use a version tag.

In Details

latest tag

This tag is meant to represent the latest version of an image.

• writing: You can tag your image with this tag all the time. It is expected to be changing.

• reading: When you launch a job, you should avoid using that tag. Since it is expected to change, if you launch multiple jobs with it it will be hard to tell if they are running on the same or different versions of the image. Classic issues are: (1) a new version was pushed when the jobs were launched. (2) Some nodes cached an older version and are using it. On top of that you may launch on a new version that is incompatible with what you are trying to do.

Partial semantic version tags

Tip

You don’t know what semantic versioning is? Head over here.

These tags are similar to the latest tag in the sense that the image they are associated with can change over time. By using semantic versioning, the give some guarantee towards the set of change that can be part of them. Eg.:

• x.y: Images tagged with this should be the latest version of x.y.z where z changes over time.

• x: Images tagged with this should be the latest version of x.y.z where y and z change over time.

As for their usage:

• writing: Be careful to follow semantic versionning principles. Is it a patch, minor or major release? Tag accordingly.

• reading: It’s similar to reading over a latest tag. It can be risky and inconsistent.

Version tags

Of course, it always depends on who publishes the images, but by convention all other tags should be expected to be write once. In other words, they represent a static version and should never change.

• writing: This category of tags fall in the write once mindset. Although it is possible to retag with the same version, doing so breaks the conventions on which most system (and humans!) rely.

• reading: When you launch a job, you should use these tags. Since they represent static versions, all your jobs should use the same exact image, making it easier to reproduce all issues you may encoutner.

Conventions

The difference between the tag types comes from a convention. Based on it, some system will always try to repull an image using the “latest” tag while, on the contrary, never try to repull an image with a version tag since it should never change. As an example, this is the default behaviour of kubernetes. [KIA01]

[DIA01]

Jeff Nickoloff. “Docker in Action” book, section 7.4.

[KIA01]

Marko Lukša. “Kubernetes in Action MEAP V10” book, section 9.2 under Updating images without changing the image tag