Sergey Nivens - Fotolia
Why -- and how -- to use Docker image tags
Version control is a critical part of software development and deployment. IT teams can use Docker tags to better manage and organize container images.
IT admins can use tags to be more intentional and specific about the types of container images they pull from a Docker repository.
Tags are simple text labels that categorize or describe a Docker container image. A tag conveys information such as the base OS version, or whether it is the most recent update of the image. In this way, tags help developers and admins differentiate between the various available images in a repository.
Docker image tags also play a key role in the development lifecycle, as developers can use them to, for example, restrict the use of development infrastructure for a development build.
Tagging basics
Tags are specified after the image name. Although it isn't specified during a pull, the latest tag will always be used, unless admins override it with a custom tag, as discussed further below. As an example, docker pull ubuntu will always pull the latest version of Ubuntu by default.
To pull all tagged versions of an Ubuntu image, use:
docker pull ubuntu -a
It's also possible to determine which versions of Ubuntu are available without the -a tag. In a browser, use the following URL, assuming you use Docker's own repository:
https://registry.hub.docker.com/v1/repositories/ubuntu/tags
This will emit a human-readable JSON file -- use Firefox to hide all the surplus entries. There are additional ways to do this on the command line as well. To explore other image types, substitute the "ubuntu" portion of the path.
Ubuntu, along with most major OS distributions, will tag each major release in a similar fashion. If your application was designed for Ubuntu 16.04 LTS (long term support), include this information in the pull to get the latest available Ubuntu 16.04 image. The "16.04" is just a simple Docker image tag:
docker pull ubuntu:16.04
Many other tags exist, and can be swapped out for other versions, such as 18.04.
If the application is built around a specific platform version or sub-version, continue to use that same version, but with the latest build image, including recent application and security fixes.
Tag a local Docker image
To tag a local image -- meaning one on your local machine -- use this command:
docker tag "image id" image/tag
With this command, we tag a known version of an image -- uniquely identified by the image ID -- for our own purposes, such as a base image for further use. Now, when we perform a pull with that tag, via docker pull image/tag, it will reference that specific image. These changes only affect your environment, not that of other users.
When there are different versions of the build Dockerfile, it is useful to tag the image builds. If a developer has several versions of an application -- such as versions for production, testing and development -- there needs to be a way to specify which image to pull. To apply a Docker image tag to a build, use the -t switch. For example, this creates a tag of "myapp_debug" on the image:
docker build -t myapp:debug -f Dockerfile.debug .
To repeat this process for the production build, use a tag of "myapp_production" from the production Dockerfile folder.
The command line can accommodate multiple tags through repeated use of the -t option. For example:
docker build -f dockerfiles/Dockerfile.debug -t myapp_debug -t appv2 .
All the command lines above are configured and consumed locally. To push the image to a remote -- on-site or cloud-based -- repository, use docker push, assuming you have a Docker account.
After completing these steps, perform a pull with the command:
docker pull ;account/repo_name:myapp_debug
This will, by default, bring down the latest image version that is tagged "myapp_debug."
