Technik

Warum derselbe Containername morgen andere Software starten kann

Ein Container-Tag ist ein veränderlicher Verweis. Ein Digest hält die Fassung fest, braucht aber einen eigenen Ablauf für neue Sicherheitskorrekturen.

Von Wolfgang

05. Okt. 20266 Min. Lesezeit

Zwei gleich beschriftete neutrale Versandkisten neben einem präzisen Fingerabdruck der jeweiligen Inhalte; metaphorischer Softwarevergleich, keine gedruckten Fantasie-Zahlen.

Zwei Rechner starten einen Container mit demselben Namen und bekommen unterschiedliche Software. Das kann passieren, ohne dass der Name falsch geschrieben wurde. Ein Container-Tag ist ein Verweis, den sein Herausgeber auf neue Inhalte setzen kann. Wer eine genaue Fassung festhalten möchte, braucht deshalb eine andere Kennung: den Digest, einen kryptografischen Fingerabdruck des Images. Docker

Daraus folgt eine Entscheidung für den Betrieb. Ein beweglicher Tag erleichtert den Bezug neuer Fassungen. Ein festgehaltener Digest erleichtert den Vergleich zwischen Test und Produktion. Sicherheitsupdates bleiben in beiden Fällen eine Aufgabe, nur an unterschiedlichen Stellen: Entweder kann sich der Verweis ändern, oder die verantwortliche Person muss die festgehaltene Fassung bewusst ersetzen.

Ein Name funktioniert wie eine Beschriftung im Regal

Ein Container-Image enthält die Dateien und Angaben, aus denen eine Containerumgebung gestartet wird. Die Registry stellt solche Images bereit. Ein Tag wie „latest“ oder eine Versionsbezeichnung hilft, das gewünschte Angebot lesbar zu adressieren. Docker dokumentiert, dass Tags veränderlich sind. Der Herausgeber kann unter derselben Bezeichnung später eine andere Imagefassung anbieten. DockerDocker

Das ist bei einem Versionszweig häufig erwünscht. Eine Bezeichnung kann auf die jeweils aktuelle Korrekturfassung dieses Zweigs zeigen. Die Anwender müssen dafür nicht bei jeder kleinen Änderung einen völlig anderen Namen lernen. Dieser Komfort hat jedoch eine Folge: Ein Name und die Bytes, die er heute bezeichnet, sind unterschiedliche Gegenstände.

Warum derselbe Containername morgen andere Software starten kann: Vereinfachtes Erklärungsschema, keine Messdaten.
Vereinfachtes Erklärungsschema, keine Messdaten. Grafik: TechZeitGeist.

Wenn ein Testrechner das Image gestern bezogen hat und ein Produktionsrechner es heute neu bezieht, kann derselbe Tag inzwischen auf andere Inhalte zeigen. Ob das tatsächlich geschieht, hängt vom Herausgeber, dem verwendeten Tag und dem Zeitpunkt ab. Der Name allein hält diesen Zeitpunkt nicht fest. Deshalb ist er für einen strikten Vergleich zweier Installationen eine unvollständige Angabe.

Auch „latest“ hat eine technische, begrenzte Bedeutung. Docker verwendet diesen Tag als Voreinstellung, wenn beim Pull kein Tag angegeben wird. Die Bezeichnung ist kein allgemeines Verfahren, das sämtliche angebotenen Fassungen zeitlich sortiert und die neueste herausfindet. Sie verweist auf das Image, das der Herausgeber diesem Tag zugeordnet hat. Docker

Der Fingerabdruck bindet den konkreten Inhalt

Ein Digest identifiziert eine bestimmte Fassung. Ändern sich die zugehörigen Inhalte, ergibt sich eine andere Kennung. Docker ermöglicht deshalb den Bezug über eine Referenz mit „@sha256:“ und dem vollständigen Digest. Damit wird die Imagefassung gezielt festgehalten. DockerDocker

Dieser Unterschied ähnelt dem zwischen einem Regalplatz und einer Inhaltsliste mit genauer Kennung. „Das Paket im Fach A“ bleibt verständlich, auch wenn das Lager dort morgen ein neues Paket abstellt. „Das Paket mit diesem Fingerabdruck“ bezeichnet dagegen denselben Inhalt. Für einen Vergleich zwischen zwei Umgebungen muss man wissen, welche dieser beiden Aussagen man verwendet hat.

Eine festgehaltene Referenz ist besonders hilfreich, wenn ein Fehler untersucht wird. Dann können die Beteiligten die tatsächlich verwendete Imagefassung bestimmen und erneut beziehen, solange sie verfügbar bleibt. Aus „bei mir läuft derselbe Name“ wird eine konkrete überprüfbare Übereinstimmung. Das grenzt eine mögliche Ursache ein, bevor man Einstellungen, Daten oder andere Laufzeitbedingungen untersucht.

Der Fingerabdruck beschreibt allerdings die Identität des Inhalts. Die Entscheidung, ob dieser Inhalt für die Aufgabe geeignet und vertrauenswürdig ist, gehört weiterhin zur Auswahl und Prüfung. Ein bekannter problematischer Inhalt bleibt derselbe problematische Inhalt, auch wenn seine Kennung hervorragend dokumentiert ist. Identität, Herkunft und Verhalten erfüllen im Betrieb unterschiedliche Aufgaben.

Ein Rechner kann hinter dem Namen ein anderes Image wählen

Mehrplattform-Images ergänzen die Sache um eine weitere Ebene. Ein Angebot kann Fassungen für verschiedene Prozessorarchitekturen bündeln. Docker beschreibt dafür einen Index beziehungsweise eine Manifestliste, die mehrere plattformspezifische Images referenziert. Sowohl die Gesamtliste als auch die einzelnen Varianten besitzen Digests. Docker

Das ist praktisch: Ein Tag kann auf einem passenden Rechner zur jeweiligen Architekturvariante führen. Ein PC mit einer anderen Architektur muss dadurch nicht dieselben ausführbaren Dateien bekommen. Die Zuordnung passt die angebotene Software an die Plattform an.

Für die Fehlersuche bedeutet es, dass „gleicher Digest“ genau benannt werden sollte. Ein festgehaltener Index kann mehrere feste Varianten zusammenfassen. Zwei Systeme können dann denselben Index verwenden und dennoch jeweils die für ihre Architektur bestimmte Variante beziehen. Wer die tatsächlich gestartete Fassung vergleichen will, muss zusätzlich die Plattform und die zugehörige Imagekennung erfassen.

Die Trennung hilft besonders bei einer Mischung aus Entwicklungsrechnern und Servern. Der gemeinsame Name erleichtert den Ablauf. Plattform und genaue Variante erklären, welche Dateien am Ende auf welchem System landen. Ein Fehler, der nur auf einer Architektur auftritt, wird durch eine gleiche Tagbezeichnung nicht rätselhafter, sobald diese zusätzliche Ebene sichtbar ist.

Festhalten braucht einen Weg zum nächsten Stand

Docker nennt beim Pinning ausdrücklich den Wartungsaufwand. Wer ein Basisimage über einen Digest fixiert, erhält nicht automatisch neue Fassungen samt möglicher Sicherheitskorrekturen. Der Digest muss für eine Aktualisierung gezielt geändert werden. Die Dokumentation beschreibt dafür auch Prüfungen und automatisierte Änderungsvorschläge. DockerDocker

Das ist der wichtigste Gegenpunkt zur Empfehlung, alles einfach festzuschreiben. Ein stabiler Ausgangspunkt erleichtert Tests, kann aber veralten. Eine brauchbare Betriebsregel verbindet deshalb zwei Schritte: zunächst die genaue Fassung erfassen, dann neue geeignete Fassungen erkennen, prüfen und übernehmen. Der zweite Schritt darf nicht verschwinden, nur weil der erste technisch zuverlässig ist.

Für ein Team kann das heißen, einen neuen Digest zunächst in der Testumgebung zu verwenden und erst nach den passenden Prüfungen in die Produktion zu übernehmen. So bleiben Test und Freigabe an einer konkreten Fassung gebunden. Ein beweglicher Tag kann weiterhin helfen, neue Angebote zu entdecken. Er wird dabei zum Eingang des Updateprozesses, während die geprüfte Kennung den freigegebenen Stand beschreibt.

Herunterladen und Starten sind verschiedene Zeitpunkte

Eine neue Fassung in der Registry verändert auch nicht rückwirkend jeden bereits laufenden Container. Der Betrieb umfasst mehrere Schritte: Ein Image wird bezogen, daraus wird ein Container erzeugt, und dieser wird gestartet. Welcher Stand dabei genutzt wird, hängt vom konkreten Ablauf ab. Ein neuer Bezug über einen beweglichen Tag kann andere Bytes liefern als eine schon vorhandene lokale Fassung. Docker

Für eine Störung sollte das Team deshalb nicht nur den Namen in der Konfigurationsdatei ansehen. Es braucht auch den tatsächlich bezogenen beziehungsweise gestarteten Stand. Sonst können zwei Personen korrekt berichten, dieselbe Konfiguration zu benutzen, und trotzdem über unterschiedliche Imagefassungen sprechen.

Ein dokumentierter Updateablauf macht diesen Übergang sichtbar: Was wurde angeboten, was wurde bezogen, was wurde geprüft und was läuft jetzt? Der Digest verbindet die technischen Schritte mit einer konkreten Fassung. Die Versionsbezeichnung bleibt als menschlich lesbare Orientierung nützlich. Zusammen entsteht eine verständliche und überprüfbare Beschreibung des Betriebs, die sowohl den Alltag als auch eine spätere Fehleranalyse erleichtert.

Derselbe Containername muss somit nicht jeden Tag dieselbe Software bedeuten. Wer Namen, Fingerabdruck und Plattform getrennt dokumentiert, kann diesen Unterschied beherrschen. Und wer zum festgehaltenen Stand einen regelmäßigen Updateweg hinzufügt, verbindet nachvollziehbare Installationen mit laufender Pflege.

Quellen

Für diesen Artikel wurden KI-gestützte Recherche- und Editierwerkzeuge verwendet. Der Inhalt wurde redaktionell geprüft.