Rebuild docker image by reusing the same tag?

Question

I've gone thru multiple questions posted on the forum but didn't get a clarity regarding my requirement.

I'm building a docker image after every successful CI build, there will be hardly 1 to 2 lines of changes in Dockerfile for every successful build.

Docker Build Command:
     $(docker_registry)/$(Build.Repository.Name):azul
Docker Push Command
      $(docker_registry)/$(Build.Repository.Name):azul

I wanted to overwrite the current docker image with the latest one(from the latest CI build changes) but retain the same tag - azul . Does docker support this?

Answer 1

Yes, docker supports it. Every line you execute results in a new layer in image, that contains the changes compared to the previous layer. After modifying the Dockerfile , new layers will be created and the same preceding layers will be reused.

If you want to clean build the whole image with no cached layers, you can use the —no-cache parameter.

Answer 2

Mechanically this works. The new image will replace the old one with that name. The old image will still be physically present on the build system but if you look at the docker images output it will say <none> for its name; commands like docker system prune can clean these up.

The problems with this approach are on the consumer end. If I docker run registry.example.com/image:azul , Docker will automatically pull the image only if it's not already present . This can result in you running an older version of the image that happens to be on a consumer's system. This is especially a problem in cluster environments like Kubernetes, where you need a change in the text of the image name in a Kubernetes deployment specification to trigger an update.

In a CI system especially, I'd recommend assigning some sort of unique tag to every build. This could be based on the source control commit ID, or the branch name and bind number, or the current date, or something else. You can create a fixed tag like this as a convenience to developers (an image is allowed to have multiple tags) but I'd plan to not use this for actual deployments.