InterSystems Official
· Jun 30, 2023

Upcoming InterSystems Container Changes

When IRIS 2023.2 reaches general availability, we’ll be making some improvements to how we tag and distribute IRIS & IRIS for Health containers.

IRIS containers have been tagged using the full build number format, for example 2023.1.0.235.1.  Customers have been asking for more stable tags, so they don’t need to change their dockerfiles/Kubernetes files every time a new release is made.  With that in mind, we’re making the following changes to how we tag container images.

Major.Minor Tags:  Containers will be tagged with the year and release, but not the rest of the full build number.   For example, where an image is accessed currently as

containers.intersystems.com/intersystems/iris:2023.2.0.606.0

Will now be accessed as 

containers.intersystems.com/intersystems/iris:2023.2

latest-em and latest-cd Tags:  The most recent extended-maintenance and continuous-delivery releases will be tagged with latest-em and latest-cd, respectively.  This provides a shorthand notation that can be used in documentation, examples, and development environments.  We do not advise using these tags for production environments.

Preview:  Developer preview releases will all be clearly tagged with -preview so you can easily separate out pre-release containers from production-ready containers.  The most recent preview release will helpfully be tagged with latest-preview.

If you’re looking for the full build number for an InterSystems container, that’s available as a label, which you can view with the docker inspect command.  For example:

    docker inspect --format '{{ index .Config.Labels "com.intersystems.platform-version"}}'  containers.intersystems.com/intersystems/iris:2023.1.0.235.1

 

Containers will no longer be distributed via the WRC download site.  If you’re one of the few customers downloading containers from the WRC download site, now’s the time to switch to the InterSystems Container Registry (docs).

While we’re here, as a reminder that we have been publishing multi-architecture manifests for IRIS containersThis means that pulling the IRIS container tagged 2022.3 will download the right container for your machine’s CPU architecture (Intel/AMD or ARM).

If you need to pull a container for a specific CPU architecture, tags are available for architecture-specific containers.  For example, 2022.3-linux-amd64 will pull the Intel/AMD container and 2022.3-linux-arm64v8 will pull the ARM container.

We’ll stop posting to the iris-arm64 repositories soon since multi-architecture streamlines the process of getting the right containers on the right machines.

If you have questions or concerns, please reach out to the WRC.

Discussion (12)5
Log in or sign up to continue

Hi Bob,

That's good news and I like new names much more than old ones. I hope old tags for old releases will still be available?

A couple of entries from my container tagging wishlist (one can dream, you know)

- provide :latest tag for all containers, but especially for community ones, which will just pull the latest working release without having to rebuild dockerfiles every year when license expires

- provide 2023.1.x tag which will follow the latest minor version

- provide 2023.1.x tag which will follow the latest minor version

It's not clear to me whether or not this is already the plan for the new Major.Minor tags. For instance, when IRIS 2024.1.1 is released, will it be at containers.intersystems.com/intersystems/iris:2024.1 (where IRIS 2024.1.0 images would likely have existed previously) or containers.intersystems.com/intersystems/iris:2024.1.1? @Bob Kuszewski can you please clarify?

The plan for new IRIS containers is to use YYYY.R format only.  Let's walk through an example of a few releases for a hypothetical IRIS 2024.1 release.
 

Release Old Tag New Tag
Initial GA 2024.1.0.123.0 2024.1
First maintenance 2024.1.1.234.0 2024.1
Security Fix 2024.1.1.234.1 2024.1

This new scheme greatly simplifies your work to keep up with whatever mix of maintenance and security releases we provide.  All you need to do is reference iris:2024.1 and you'll pick up the latest bug and security fixes without making any changes to your code.

As for the latest tag, we like the idea so much that we're giving you two.  One that lets you get the latest release (iris:latest-cd) and one that lets you get the latest long-term-support release (iris:latest-em).  

Already some time since the last post...
I appreciate the way of dealing with the tags although I'm used to the way this is done i.E. in docker hub where every provided image is listed with its actual build-number so you can see, which image exactly is "latest" or which version is delivered when you only ask for a mayor-release-tag.

If there is a bug in a certain minor-version I cannot see easily if there is a never minor version provided with a docker image. Therefore I have to search through the release notes to see if / when an image of the new version is released or I have to pull the last image of the mayor-version (some GB!) and inspect it.
Perhaps this scenario seems a little "constructed"? We just had to deal with it .

In short: With only mayor-version-tags we have to rely in Intersystems that

1. there is always the latest release of an application provided as docker image as well and

2. that there are no new bugs in a newer version (because we can't stick to a certain build).

For production environments with high availability I recommend to use a private registry for Iris etc. and tag the images so we can determine when to upgrade.

How do other deal with this (or am I just paranoid?)

Hi,

Pulling the irishealth:latest-em fails with dangling manifests (looks like).

docker pull containers.intersystems.com/intersystems/irishealth:latest-em
latest-em: Pulling from intersystems/irishealth
a271f97708e3: Pull complete
6d17179b85a7: Downloading [==================================================>]  272.8MB/272.8MB
0a3eeb0be045: Waiting
ae9eda793928: Waiting
cda3cca218dc: Waiting
7858487e277f: Waiting
unexpected EOF
 

Did any get this error?

Thanks,

JB