How to prevent docker images on docker hub from being overwritten?

Question

Is there any way to prevent images being uploaded to docker hub with the same tags as existing images? Our use case is as follows.

We deploy to production with a docker-compose file with the tags of images as version numbers. In order to support roll-back to previous environments and idempotent deployment it is necessary that a certain tagged docker image always refer to the same image.

However, docker hub allows images to be uploaded with the same tags as existing images (they override the old image). This completely breaks the idea of versioning your images.

We currently have work-arounds which involve our build scripts pulling all versions of an image and looking through the tags to check that an overwrite will not happen etc. but it feels like there has to be a better way.

If docker hub does not support this, is there a way to do docker deployment without docker hub?

Ambassadoratlarge

Having re-read this, I don't really understand. What do you mean "tags of images as version numbers"? Do you mean you use version numbers as your image tags? That makes sense. But to check if a tag is going to be overwritten, why can't you just do docker pull image:tag and see if there is anything there? – Peroxidize

Hmmm hadn't thought of trying to pull the specific image as a way of inspecting whether a tag exists, we were just pulling all the images / tags for that and it was cumbersome, good idea. – Ambassadoratlarge

This is one more reason why tags should have been made immutable. I have similar issue where i can't guarantee that my local version of some image (with certain tag) is the same as on all other nodes. Other than this, DOCKER ROCKS! – Polyphemus

devops.stackexchange.com/q/1549/210 – Atiptoe

Answer 1

Assuming you have a local build system to build your Docker images: you could include the build number from your local build job in your tag. With that you assure your requirement:

... it is necessary that a certain tagged docker image always refer to the same image.

When your local build automatically pushes to docker hub it is assured that each push pushes an image with a unique tag.

Junker

Thanks, I'm accepting this answer because it is the approach we have now used (and it works), However, I'm sure that @adrian-mouat 's approach also works. – Ambassadoratlarge

Out of curiosity, what are you guys using as this build system for Docker builds? Is it some automated system like CI, where builds are triggered by a push to a Git repo? – Saltarello

We use Jenkins on which our maven style projects are build. For maven there are good Docker plugins available. Those builds are triggered by a push to our Atlassian Stash git repos. – Junker

Note that this, in many cases, is no guarantee of immutability. The image itself could be based onto something that changed (i.e. FROM whatever:latest is now something else) and a different image could then have been rebuilt with the same rev. number (or git commit hash) but different contents if rebuilt. – Rodriguez

Answer 2

The tag system has no way of preventing images been overwritten; you have to come up with your own processes to handle this (and h3nrik's answer is an example of this).

However, you could use the digest instead. In the new v2 of the registry, all images are given a checksum, known as a digest. If an image or any of its base layers change, the digest will change. So if you pull by digest, you can be absolutely certain that the contents of that image haven't changed over time and that the image hasn't been tampered with.

Pulling by digest looks like:

docker pull debian@sha256:f43366bc755696485050ce14e1429c481b6f0ca04505c4a3093dfdb4fafb899e

You should get the digest when you do a docker push.

Now, I agree that pulling by digest is a bit unwieldy, so you may want to set up a system that simply tracks digest and tag and can verify that the image hasn't changed.

In the future, this situation is likely to improve, with tools like Notary for signing images. Also, you may want to look at using labels to store metadata such as git hash or build number.

Peroxidize

Unfortunately this doesn't work well with multiple architectures, in which case a tag can map to multiple digests. This becomes relevant when your development machine has a different architecture than the CI agent or target instance. – Brownson

My mistake, it does work, when used with a manifest digest instead of a platform-specific digest. – Brownson