Docker Images richtig taggen: Anleitung und Best Practices
Mit Tags in Docker lassen sich Container-Images statt über kryptische IDs über verständliche Bezeichnungen identifizieren. Entwickler können dadurch Images klar nach Version, Umgebung oder Feature strukturieren. Diese Anleitung zeigt, wie du Images beim oder nach dem Build taggst, mehrere Tags effizient vergibst und bewährte Tagging-Strategien im CI/CD-Workflow etablierst.
Kurzübersicht der wichtigsten Docker-Tags
# Beim Build taggen
$ docker build -t repository_name:tag .
# Nach dem Build taggen
$ docker image tag SOURCE_IMAGE[:TAG] TARGET_IMAGE[:TAG]
# Mehrere Tags gleichzeitig setzen
$ docker build -t repository_name:tag1 -t repository_name:tag2 .
Docker Image beim Erstellen taggen
Mit dem Flag -t kannst du einem Image beim Buildvorgang direkt einen Tag zuweisen. So ist das Image sofort für Staging, Produktion oder andere Einsatzzwecke gekennzeichnet – ein späteres Nach-Taggen ist nicht notwendig.
Befehlsstruktur
docker build -t repository_name:tag .
docker build: Erstellt ein Image aus dem Dockerfile im aktuellen Verzeichnis.-t: Fügt dem Image einen lesbaren Namen im Format repository:tag hinzu..: Gibt den aktuellen Build-Kontext an.
Mehrere Tags gleichzeitig angeben:
docker build -t repository_name:tag1 -t repository_name:tag2 .
-t repository_name:tag1: Erster Tag.-t repository_name:tag2: Zusätzlicher Tag.
Beispielhafte Anwendung
Image ohne Tag erstellen:
$ docker build .
Image mit staging-Tag bauen:
$ docker build -t myapp:staging .
Image für die Produktion taggen:
$ docker build -t myapp:production .
Alle Images auflisten:
$ docker image ls
Beispielausgabe:
REPOSITORY TAG IMAGE ID CREATED SIZE
myapp production 459263adb890 vor 19 Minuten 206MB
6410385feccb vor 19 Minuten 206MB
myapp staging 38da9244f5f0 vor 19 Minuten 206MB
Durch direktes Tagging beim Build wird verhindert, dass unbenannte (<none>) Images entstehen.
Image nach dem Build taggen
Nachdem ein Image erstellt wurde, kannst du es mit weiteren Tags versehen, ohne es erneut zu bauen. Das ist ideal für Versionierungen oder um Umgebungskennzeichnungen nachträglich zu ergänzen.
Befehlsstruktur
docker image tag SOURCE_IMAGE[:TAG] TARGET_IMAGE[:TAG]
docker image tag: Weist einem vorhandenen Image einen neuen Namen zu.SOURCE_IMAGE[:TAG]: Aktueller Name oder Image-ID.TARGET_IMAGE[:TAG]: Neuer Tag, der hinzugefügt werden soll.
Beispiel
Untagged Image mithilfe seiner ID taggen:
$ docker image tag 6410385feccb myapp:dev
Ein bestehendes Image zusätzlich als Version v1.0 taggen:
$ docker image tag myapp:production myapp:v1.0
Verifizieren, dass beide Tags auf das gleiche Image zeigen:
$ docker image ls
Beispielausgabe:
REPOSITORY TAG IMAGE ID CREATED SIZE
myapp dev 6410385feccb vor etwa einer Stunde 206MB
myapp staging 38da9244f5f0 vor etwa einer Stunde 206MB
myapp production 459263adb890 vor etwa einer Stunde 206MB
myapp v1.0 459263adb890 vor etwa einer Stunde 206MB
Ein Docker-Tag ist lediglich ein Verweis – es wird kein Speicher verdoppelt. Du kannst ein und dasselbe Image unter verschiedenen Namen nutzen, ohne es mehrfach zu speichern.
Mehrere Tags beim Build zuweisen
Um Workflows zu optimieren, kannst du beim Build-Vorgang mehrere Tags gleichzeitig vergeben, indem du mehrere -t-Flags nutzt. Dadurch entfällt das nachträgliche Tagging und alle Varianten sind sofort verfügbar.
Befehlsstruktur
docker build -t repository_name:tag1 -t repository_name:tag2 [OPTIONS] PATH
-t repository_name:tag1: Erster Tag.-t repository_name:tag2: Weitere Tags.PATH: Pfad zum Build-Kontext, meist..
Beispielhafte Anwendung
Vorhandene Images anzeigen:
$ docker image ls
Alte Versionen entfernen:
$ docker image rm myapp:staging myapp:production myapp:dev myapp:v1.0
Ausgabe:
Untagged: myapp:staging
Untagged: myapp:production
Untagged: myapp:dev
Untagged: myapp:v1.0
Deleted: sha256:<image_id>
Image mit allen benötigten Tags neu erstellen:
$ docker build -t myapp:staging -t myapp:production -t myapp:dev -t myapp:v1.0 .
Tags und zugehöriges Image überprüfen:
$ docker image ls
Beispielausgabe:
REPOSITORY TAG IMAGE ID CREATED SIZE
myapp dev 83782771e2ab gerade eben 206MB
myapp production 83782771e2ab gerade eben 206MB
myapp staging 83782771e2ab gerade eben 206MB
myapp v1.0 83782771e2ab gerade eben 206MB
Alle Tags verweisen auf dieselbe Image-ID – das zeigt, dass das Image nur einmal gebaut wurde und mehrfach referenziert wird. Das ist ideal für automatisierte Deployments und klare Release-Zyklen.
Best Practices für das Tagging von Docker-Images
Ein durchdachtes Tagging-Konzept macht Docker-Images besser nachvollziehbar, vereinfacht automatisierte Deployments und verbessert die Zusammenarbeit im Team. Im Folgenden findest du bewährte Strategien und ein flexibles Tagging-System, das sich problemlos in CI/CD-Pipelines und Versionskontrollen integrieren lässt.
Empfohlene Tag-Arten
Setze auf ein variables System, das verschiedene Release-Modelle unterstützt:
- Semantische Tags: Mit
repository:1.2.3kennzeichnest du klar Haupt-, Neben- und Fehlerbehebungs-Releases. - Basis-/Major-Tags: Tags wie
repository:1oderrepository:2markieren stabile Versionslinien oder LTS-Releases. - Feature-Tags: Varianten wie
repository:lightwoododerrepository:huggingfacebeschreiben funktionale Unterschiede. - Kombinierte Tags: Kombiniere Version und Zweck – z. B.
repository:2.1-redisfür präzise Zuordnung. - Build-/Commit-Tags: Nutze IDs aus der CI/CD-Pipeline wie
repository:74667932oderrepository:sha-abc123.
Vermeide :latest in Produktionsumgebungen
Das Verwenden des Tags :latest in der Produktion ist riskant, da es zu unvorhersehbarem Verhalten führt – z. B. wenn verschiedene Nutzer unabsichtlich unterschiedliche Versionen ziehen.
$ docker build -t app:2.1.0 .
Nutze stattdessen klar definierte Versionsnummern. :latest sollte nur für lokale Tests oder interne Entwicklung reserviert sein.
Einzigartige Tags für jedes Deployment nutzen
Stelle sicher, dass jeder Build ein eindeutiges Tag erhält – das erleichtert Rückverfolgung, Audits, Rollbacks und die Verwaltung von Artefakten.
Beispiele für eindeutige Tags:
app:build-92875462app:20240521-1530app:feature-payment
Stabile Tags für Sicherheitsupdates beibehalten
Verwende stabile Tags wie app:2.0 für langfristig unterstützte Versionen. Passe :latest bei kleineren Updates an, um die aktuell stabile Version anzuzeigen.
Erster Build mit Tag 2.0 und latest:
$ docker build -t app:2.0 -t app:latest .
Späteres Update auf Version 2.1 mit gleichem :latest-Tag:
$ docker build -t app:2.1 -t app:latest .
Automatisiertes Tagging in CI/CD-Pipelines
Richte deine CI/CD-Tools wie GitHub Actions oder Jenkins so ein, dass sie bei jedem Build automatisch eindeutige, konsistente Tags erzeugen. Das gewährleistet Transparenz und Nachvollziehbarkeit über alle Deployments hinweg.
- name: Build and Tag Docker Image
run: |
docker build -t myapp:${{ github.sha }} .
docker tag myapp:${{ github.sha }} myapp:latest
Verwende Commit-Hashes, Branch-Namen oder Build-IDs, um jede Version eindeutig identifizierbar zu machen – ein zentrales Element für automatisierte Releases.
Tagging-Regeln dokumentieren und standardisieren
Erstelle eine klare Tagging-Richtlinie in deinem Projektrepository. Definiere darin, wie Versionen, Umgebungen und Feature-Stände benannt werden sollen.
# Tagging-Strategie
Semantische Tags:
- app:1.2.3 → Fehlerbehebung (Patch)
- app:1.2 → Aktuellster Patch der Minor-Version
- app:1 → Aktuellster Patch der Major-Version
Feature-Tags:
- app:redis
- app:v2-graphql
Build-Tags:
- app:dev-login
- app:build-74667932
Platziere diese Vorgaben z. B. im README.md oder in den Beitragshinweisen deines Projekts, um einheitliche Konventionen im Team sicherzustellen.
Fazit
In diesem Beitrag hast du gelernt, wie Docker-Images während oder nach dem Build-Vorgang getaggt werden können. Außerdem hast du erfahren, wie man mehrere Tags gleichzeitig vergibt und welche Best Practices für ein konsistentes Tagging sinnvoll sind.
Durch diese Techniken lassen sich Workflows vereinfachen, Deployments zuverlässiger gestalten und automatisierte CI/CD-Prozesse nahtlos umsetzen.
