You tag images when you first build them, but you can also explicitly add tags to an image with the docker image tag command. This is very useful in versioning mature applications, so users can choose which versioning level they want to work with. If you were to run the following commands, you would build an image with five tags, with ascending levels of precision for the application version:
docker image build -t myapp .
docker image tag myapp:latest myapp:5
docker image tag myapp:latest myapp:5.1
docker image tag myapp:latest myapp:5.1.6
docker image tag myapp:latest myapp:bc90e9
The initial docker image build command doesn't specify a tag, so the new image will default to myapp:latest. Each subsequent docker image tag command adds a new tag to the same image. Tagging doesn't copy the image, so there's no data duplication – you just have one image which can be referred to with several tags. By adding all of these tags, you give consumers the choice of which image to use, or to base their own image on.
This example application uses semantic versioning. The final tag could be the ID of the source code commit that triggered the build; this might be used internally but not made public. 5.1.6 is the patch version, 5.1 is the minor version number, and 5 is the major version number.
Users can explicitly use myapp:5.1.6, which is the most specific version number, knowing that the tag won't change at that level and the image will always be the same. The next release will have the tag 5.1.7, but that will be a different image with a different application version.
myapp:5.1 will change with each patch release – the next build, 5.1 will be a tagged alias of 5.1.7 – but users can be confident there won't be any breaking changes. myapp:5 will change with each minor release – next month, it could be an alias of myapp:5.2. Users can choose the major version if they always want the latest release for version 5, or they could use the latest if they always want the latest version, and can accept the possibility of breaking changes.
As the producer of images, you can decide how to support versioning in your image tags. As the consumer, you should favor being more specific – especially with images you use as the FROM image for your own builds. If you're packaging a .NET Core application, you will have problems if you start your Dockerfile like this:
FROM microsoft/dotnet:sdk
At the time of writing, this image has version 2.2.103 of the .NET Core SDK installed. If your application targets version 2.2, then that's fine; the image will build and your application will run correctly in a container. But when .NET Core 2.3 or 3.0 is released, the generic :sdk tag will be applied to the new image, which may not support targeting 2.2 applications. When you use the exact same Dockerfile after that release, it will use a different base image – your image build could fail, or it could complete only for the application to fail at runtime if there are breaking changes in the .NET Core update.
Instead, you should consider using a tag for the minor version of the application framework you're using, and explicitly stating the operating system and CPU architecture if it's a multi-arch image:
FROM microsoft/dotnet:2.2-sdk-nanoserver-1809
This way, you'll benefit from any patch releases to the image, but you'll always be using the 2.2 release of .NET Core, so your application will always have a matching host platform in the base image.
You can tag any image you have in your local cache – not just images you build yourself. This is useful if you want to re-tag a public image and add it to an approved set of base images in your local, private registry.