Container-Image-Tags versus Digests: veränderliche Namen und Inhaltsadressen

Worum es geht

Eine OCI-Registry speichert Blobs (Layer und Manifeste) nach Inhaltsadresse. Die Distribution-Spezifikation (zitiert) definiert einen Digest als eindeutigen Bezeichner, der aus einem kryptografischen Hash des Inhalts eines Blobs erzeugt wird, und einen Tag als benutzerdefinierten, menschenlesbaren Zeiger auf ein Manifest; ein Manifest-Digest kann null, einen oder mehrere darauf verweisende Tags haben. Der Descriptor-Abschnitt der Image-Spezifikation (zitiert) erklärt, dass der Digest als Inhaltsbezeichner dient und dass aus einer nicht vertrauenswürdigen Quelle abgerufener Inhalt durch Neuberechnung geprüft werden kann. Eine Referenz hat daher zwei Formen: registry/repo:tag löst über einen veränderlichen Zeiger auf, während registry/repo@sha256:<hex> Bytes benennt. Die Docker-CLI-Referenz (zitiert) bezeichnet die zweite Form als Pull anhand eines unveränderlichen Bezeichners.

Warum es wichtig ist

python:3.12-slim heute und nächsten Monat sind unterschiedliche Images mit demselben Namen; myapp:latest kann auf zwei Knoten zwei verschiedene Builds sein. Ein Rollback „zum vorherigen Tag“ kann etwas Neueres abrufen als das, was zuvor lief, falls der Tag erneut gepusht wurde. Schwachstellen-Scans, Provenienz-Attestierungen und Signaturen hängen alle an Digests, sodass ein nur nach Tag beschriebenes Deployment nicht seinem Scan-Ergebnis zugeordnet werden kann. Umgekehrt hat ein Digest für einen Menschen keine Bedeutung, ohne dass festgehalten ist, woraus es gebaut wurde.

So wird es angewendet

• Einen Build einmal unter einer unveränderlichen Identität pushen (sha-<commit> oder ein Versions-Tag) und die CI den resultierenden Digest ausgeben lassen; ihn zusammen mit dem Release speichern.
• Nach Digest deployen: image: registry/app@sha256:… in Manifesten, oder den Tag zum Zeitpunkt des Deployments auf einen Digest auflösen und diesen im gerenderten Manifest festhalten.
• Basis-Images in Dockerfiles als FROM image:tag@sha256:… pinnen, sodass der Tag die Absicht dokumentiert und der Digest den Inhalt fixiert; beide über reviewte Update-Pull-Requests aktualisieren.
• Fliessende Tags (latest, 3.12) nur für interaktive Nutzung und um herauszufinden, was als Nächstes zu pinnen ist, verwenden.
• Einen Multi-Plattform-Tag mit Vorsicht behandeln: Er zeigt auf einen Image-Index, dessen Digest sich von den darin enthaltenen plattformspezifischen Manifest-Digests unterscheidet.

Stolpersteine

Registry-Auflistungen sind meist nach Tag organisiert, sodass ein untagged Manifest leicht übersehen wird, obwohl es weiterhin per Digest abrufbar ist und weiterhin Speicherplatz belegt. Die Distribution-Spezifikation erlaubt es einer Registry, das Löschen von Tags getrennt vom Löschen von Manifesten zu implementieren, sodass das Entfernen eines Tags nicht von selbst das Manifest oder dessen Layer freigibt. Das Neuverpacken eines Images (etwa das erneute Komprimieren von Layern oder ein Neubau mit anderen Metadaten) ändert den Digest, obwohl die enthaltenen Dateien identisch sind; Signaturen und Attestierungen hingegen werden neben dem Image gespeichert und ändern es nicht.