What are best practices for docker tag versioning?

Question

I've recently hooked our CI servers up to build docker images upon git commit.

We have about 8 different containers that get built, each with their own language / frameworks. Some are node and have a package.json, others are python services that contain no semantic version information.

My question is not about how to create tags, its about creating the values for the tag.

How to ensure that each tag has a unique semantic version number for the specific images? Who should be the authority on tracking / incrementing a build version?

Answer 1

I would direct you to my post Coupling docker registry and source control where dmaze answered from the official forums.docker.com. Commit hash and branch name or tags suffices.

In your Dockerfile, use a LABEL to record the source of the build. That probably includes the commit hash from distributed source control (git, Mercurial), the branch name if relevant, any release tags if present, and possibly details like the timestamp of the last commit. docker history and docker inspect should be able to show these.

When you docker push your images, push them at least twice, with the commit hash and with the branch name as the “version” part (quay.io/mycorp/imagename:123abc7, quay.io/mycorp/imagename:dmaze-test). If release tags are readily available, the CI system should push images with these tags too.

We are currently using a combination of branch name/commit hash. For us that seems to be enough. timestamps while they are useful IMO just add clutter as they don't provide anything the commit hash doesn't.

I agree with 030 regarding:

who should be the authority on tracking / incrementing a build version

100% is responsibility of the CI to maintain such things, with proper communication between other teams.

Answer 2

How to ensure that each tag has a unique semantic version number for the specific images?

One could create a tag that consists of multiple elements, e.g. a combination of a timestamp, git commit hash and semantic version. The latter has to be set manually, while the first two could be automated. Such a tag could look as follows:

20171015141729-58617f500f7efe236c7ba6a1dfdf37a478b4c878-0.1.4

This tag contains the date of build, the commit and the semantic version. If a docker image runs in production and a bug is found then one knows the version of the product, the code that is inside and when the image was built and under what circumstances.

Who should be the authority on tracking / incrementing a build version?

In my opinion this should be the responsibility of the CI as this is able to automate processes and as the creation of tags could be automated such a tool is the right tool for the job.

Answer 3

I suppose that you use one of the DevOps tools for CI/CD like Jenkins, I suggest the following approach,

If you use something like Jenkins-

• You can configure your job such a way that you can use Jenkins environment variable "BUILD_ID", which retrieves the build id of the job when triggered to tag it to your image. This way you can version control your docker images. Please check the below example.

ex:- sudo docker build -t <image_name>:<BUILD_ID>

So, if you have got tag like mechanism for your SCM, you can check the tag in the respective build ID either in job based builds or in config.xml of the build ID in JENKINS HOME_FOLDER.