Image-Tags - warum latest keine Versionierung ist

Image-Tags - warum latest keine Versionierung ist

nginx:latest klingt nach dem aktuellen, stabilen Stand. In Wirklichkeit ist latest nur ein Label — und ein gefährliches dazu.

Was Tags wirklich sind

Tags sind einfache Zeiger auf einen bestimmten Image-Digest. Sie sind veränderlich: Wer docker push myimage:latest ausführt, verschiebt den latest-Tag auf das neue Image. Was gestern hinter latest war, kann heute ein anderes Image sein.

# Diese drei Befehle können auf verschiedene Images zeigen — je nach Zeitpunkt
docker pull nginx:latest   # heute
docker pull nginx:latest   # in 3 Monaten (nach Release)
docker pull nginx:latest   # nach Breaking Change

Das Problem mit latest in der Praxis

Ein docker-compose.yml mit image: nginx:latest funktioniert auf dem Entwicklungsrechner — aber nach einem docker pull auf dem Produktionsserver kommt eine neue Version, die Breaking Changes enthält. Der Build ist nicht reproduzierbar.

# Schlecht — nicht reproduzierbar
services:
  web:
    image: nginx:latest

# Gut — exakt definiert
services:
  web:
    image: nginx:1.25.3

Semver-Tags verstehen

Die meisten Images bieten mehrere Tag-Varianten:

nginx:1.25.3        ← exakte Version (unveränderlich)
nginx:1.25          ← minor-stable (patch-Updates automatisch)
nginx:1             ← major-stable (minor-Updates automatisch)
nginx:latest        ← letzter Push (komplett variabel)

Für Produktionsumgebungen: immer die exakte Version (1.25.3) pinnen.

Wie man Updates im Griff behält

Versionspinning bedeutet nicht, Sicherheitsupdates zu ignorieren. Tools wie Renovate oder Dependabot können docker-compose.yml und Dockerfiles automatisch auf neue Versionen prüfen und Pull Requests erstellen:

# Renovate erkennt das und erstellt PR bei neuer Version
image: nginx:1.25.3

So hat man Kontrolle und bekommt Updates — ohne Überraschungen in Produktion.

Eigene Images taggen

Für eigene Images gilt dieselbe Empfehlung:

# Beim Build mehrere Tags vergeben
docker build -t myapp:2.1.4 -t myapp:2.1 -t myapp:latest .

# latest nur als Convenience-Tag, nicht als Versionierung nutzen

latest als zusätzlicher Tag auf dem letzten Release ist akzeptabel. Als einziger Tag — problematisch.

Zusammenfassung

  • latest ist ein bewegliches Ziel, kein Versionsbezeichner
  • Für reproduzierbare Deployments: exakte Tags pinnen
  • Update-Automatisierung via Renovate oder Dependabot einrichten
  • Eigene Images nach Semver taggen