Lesson 09/8 minutes/2 graded
Image tags and versions
Why latest promises nothing, how to tag your own builds, and what docker tag does that docker build does not.
We have been writing tags since lesson five without slowing down to look at
them. nginx:1.30.4-alpine, node:24-alpine, node-app:1.0. The part after
the colon is the tag, and it is how images do versions.
Tags on other people's images
Software gets new releases, so images get new versions, and each version is a
new tag in the same repository. Open the nginx page on Docker Hub and you get a
long list: 1.30.4, 1.30.4-alpine, 1.29-alpine, and so on. Pick the tag
that matches what your app needs.
There is one tag every repository has, and it is the one to be careful with.
latest is what you get when you do not write a tag at all, so docker pull nginx and docker pull nginx:latest are the same command.
latest sounds like a promise and is not one. It is a label pointing at
whichever image was published as latest, and that pointer moves. I proved this
to myself in one minute: I pointed a tag at the nginx image, then pointed the
same tag at the Postgres image, and the tag happily followed. The name stayed
identical while the thing underneath changed completely.
So docker pull nginx in March and docker pull nginx in August can give you
two different images. On your laptop that is a shrug. On a server, it means a
deploy you did not ask for. Name the version you want.
Tags on your own images
You already tagged your own image when you built it:
docker build -t node-app:1.0 .
Change the code, build again, and bump it:
docker build -t node-app:1.1 .
Both images now sit in docker images, side by side, and you can run either
one. That is how you go back to yesterday's version when today's is broken,
which is a better afternoon than debugging under pressure.
You can also add a second name to an image you already have. That matters when you push to a registry, because the name has to include your account or your company's registry:
docker tag node-app:1.0 mohsin/node-app:1.0
No new image is built. The same image now answers to both names, and the second one is ready to push.
What a version number should say
Whatever your team agrees on, as long as it goes up and it is written down.
Release numbers like 1.4.2 are the common choice. Some teams use the git
commit id so an image points straight back at the code that made it.
The one thing to avoid is shipping only latest and hoping. You cannot roll
back to a version you never named.