ckan image tags - Githubissues

Docker tagging is a minefield of poor process -- this isn't a CKAN-specific issue, unfortunately.

The general best-practice is for users to pin to specific versions, and then for developers to overwrite tags as necessary so that the latest & greatest bugfixes can be distributed to users. However, that practice relies on an update to a tag not breaking the image, which it seems that (in this case) was violated.

I've thought about this a little bit and don't have any great solutions, but here are a few thoughts that the CKAN maintainers can think about...

My team builds a custom CKAN image FROM ckan/ckan-base:2.10.1 (it is actually a modified version of the CKAN image in ckan/ckan-docker). I am pinned to a specific minor version of the ckan-base image. My assumption as a user is that this image could be updated (in DockerHub) at any time, as long as:

The installed version of CKAN will always be 2.10.1
Any updates to this Docker image are just to fix bugs with the image itself (e.g., #24), or to update OS-level dependencies (e.g., do some apt-get updates)

I definitely agree that having "unique" identifiers would be helpful, because it would allow people to safely & quickly roll back to a known "good" version of the image, without resorting to something like fixing to a specific sha value. Unfortunately, I think that any approach to solving this problem will require modification to the current build process.

One thing I have done before that worked out well is use a "release" notation, where I add a suffix to the version tag to differentiate between various "releases" of a Docker image that embeds a tool that is locked to a specific version. In the ckan-base context, this could look like:

ckan/ckan-base:2.10.1-r1
ckan/ckan-base:2.10.1-r2
ckan/ckan-base:2.10.1-r3

And so on. Or, instead of revision numbers, you could also consider appending a short hash of the corresponding Git commit from the main branch. The advantage here is that end-users can pin to specific "sub"-versions, but the disadvantage is that you're possibly pushing more images, and I don't know what kind of quotas DockerHub enforces.

In any case, if you did adopt a revision-based numbering strategy, you could always re-tag each new revision as 2.10.1 and update that tag. This is essentially the process you're doing now, except that you aren't tracking each "old" 2.10.1 version.

All that said, I do think that the larger issue here is that there was a process failure at the CKAN dev level: changes were merged to ckan-docker-base, and a new version of the image was pushed, and that image was not compatible out of the box with the configurations in ckan-docker. Are there things the CKAN (Docker) dev team can do to improve the situation? I'm not sure -- just starting the conversation. 🙂

ckan / ckan-docker-base

ckan image tags #39