Docker images versioning for Continuous Integration / Continuous Deployment

Question

We're implementing our Continuous Integration and Continuous Delivery processes with the use of two well-known concepts: Linux binary packages and Docker images.

The most part of the work is already done: we take the code from GitLab repo, compile it and put into the deb packages stored in Aptly, then we create Docker images for the every service we have and push the images into the private Docker Registry server. Afterwards these images are rolled to the testing environment. Finally we start the services and perform the acceptance testing. This is a continuous process and it starts every time when someone pushes commits to origin/master.

What's still not clear is how to distinguish stable images stored in the Docker Registry?

We have to track the state of every image because we need to perform the periodical updates of stable sever. Obviously some releases (i.e. versions of images) will not pass the acceptance tests and must be marked as unusable and filtered out at the every next iteration of Continuous Delivery.

Seems like there's no default implementation of this feature:

1. Default image repo/tag is a trivial plain string that cannot hold both version number, build date and QA marks.
2. Labels (introduced in 1.6) could be a good starting point for a workaround, but we were not able to find the opportunity of relabeling the existing images (note that we need to update the image "metadata" taking into account the results of QA). There is no usable method of querying the image by the label values, but we probably can wrap the Docker API.

So what is the proper way of assigning the versions to the Docker Images? How the QA-related information can be stored? How can we "highlight" the stable image builds? What features of Jenkins CI could be used for reaching these purposes? Please share your experience.

UPD: after a while I had to start the discussion in Docker issue tracker. Probably someone will find it useful too.

Answer 1

Looks like your question is already answered in that discussion link however I would just note that at Bleacher Report we never pushed images to a docker hub (private or hosted) that didn't pass CI first.

• Code pushed
• CircleCI creates a tagged build
• Tests run inside tagged container
• If tests passed CircleCI pushes tagged container to a hub

Detailed explanation