CODEWITHSUNDEEP
dockerdockerhubcontinuous-delivery
Russell
Russell

Reputation: 2076

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

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?

Upvotes: 16

Views: 10229

Answers (2)

Adrian Mouat
Adrian Mouat

Reputation: 46480

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.

Upvotes: 10

Henrik Sachse
Henrik Sachse

Reputation: 54212

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.

Upvotes: 5

Related Questions