This challenge combines the chapter: build, tag, push, run, and keep a way back.
Tags in a release
| Tag | Moves? | Purpose |
|---|---|---|
1.0.0, 1.1.0 | Never, by team rule | One release each; the rollback targets |
latest | Every release | Default for people who just want the current version |
digest @sha256:… | Cannot move | Pin a deployment to exact bytes |
Registries do not enforce "never" for version tags. Some can be configured to make tags immutable; on others it is a team rule.
The release sequence
1. change the version Dockerfile: ENV APP_VERSION=1.1.0
2. build with two names -t reg/app:1.1.0 -t reg/app:latest
3. push both tags 1.1.0 first, then latest
4. deploy the version tag replace the container
5. keep the previous tag do not push or delete reg/app:1.0.0Push the version tag before latest. If the push fails halfway, latest still points at a release that works.
One build, several names
docker build accepts -t more than once. All names point at the same image ID:
docker build -t localhost:5000/status-page:1.1.0 -t localhost:5000/status-page:latest .
docker imagesPushing the second name sends only the manifest:
51d786eb4d63: Layer already exists
...
latest: digest: sha256:0a54ae410ff21f73dcac283b991695aa8a24225468b29323e9d569a221353297 size: 2087Rolling back
A rollback is a deploy of the previous tag. Nothing is rebuilt:
broken rolled back
status ← reg/app:1.1.0 ──► status ← reg/app:1.0.0Test the rollback path before you need it: start the previous tag next to the new one on another port and check its health endpoint.
Check the registry
curl -s localhost:5000/v2/status-page/tags/list
docker images --digestsCompare digests: latest should match the new version, and the old version tag should still show its original digest.