Das zugrunde liegende Problem war im App-Modell von ZimaOS 2024–2025 real: Beim Installieren einer App mit latest konnte dieses Tag zum Installationszeitpunkt aufgelöst werden. Anschließend behielt ZimaOS jedoch die aufgelöste Version bei, statt automatisch zukünftigen Änderungen in der Registry hinter demselben Tag zu folgen. Zima-Giorgio erklärte, dass dieses Verhalten aus Stabilitätsgründen beabsichtigt war, und warnte wiederholt davor, dass ein erzwungenes App-Upgrade die App beschädigen könnte.
Seitdem haben sich zwei Dinge geändert. Erstens führte ZimaOS 1.7 den App Store 2.0 mit einer eigenen Verwaltungsseite für installierte Apps und einem Update-Status ein. Zweitens sind die Docker-Grundprinzipien weiterhin relevant: Ein laufender Container wird niemals automatisch zum neuen Image, nur weil sich das latest-Tag der Registry geändert hat. Für ein Update muss immer ein geändertes Image erkannt bzw. abgerufen und der Container oder Stack neu erstellt werden.
Das frühere ZimaOS-Design löste das Tag auf und fixierte anschließend die Version
Giorgio erklärte, dass latest bei der Installation der App wirksam war und ZimaOS danach die Version stabil hielt. Dadurch sollten überraschende Fehler vermieden werden, die entstehen können, wenn sich Upstream-Images unbemerkt unter den Nutzern ändern.
Dasselbe Problem aus der Community trat später auch bei develop und wahrscheinlich bei jedem veränderlichen benannten Tag auf – nicht nur bei latest.
Docker latest bedeutet niemals „meinen laufenden Container automatisch aktualisieren“
Ein veränderliches Tag ist lediglich ein Zeiger in der Registry. Wenn example/app:latest morgen auf ein neues Image zeigt, verwendet ein bereits erstellter Container weiterhin sein bisheriges Image, bis ein Aktualisierungsprozess das neue Image abruft und den Container neu erstellt.
Daher sind „latest“ und „automatische Aktualisierung“ auch außerhalb von ZimaOS zwei getrennte Konzepte.
Die Quelle verwendete als Workaround explizite Versions-Tags
CogZog berichtete, das Immich-Tag manuell auf die veröffentlichte Versionsnummer geändert und die App dadurch auf v1.132.3 gebracht zu haben. Giorgio erklärte später, dass Nutzer, die eine bestimmte Version benötigten, das App-Versionsfeld bearbeiten und speichern konnten.
Dies war ein Workaround auf Community- bzw. Nutzerebene und kein Beleg dafür, dass es sicher ist, jede App blind auf das neueste Upstream-Image zu aktualisieren.
Multi-Container-Apps können beschädigt werden, wenn nur ein Image aktualisiert wird
Immich ist ein gutes Beispiel: Für die Komponenten Server, maschinelles Lernen, Datenbank und Cache können abgestimmte Migrationen erforderlich sein. Wenn nur ein Tag bearbeitet wird, ohne die Upstream-Anweisungen für Veröffentlichung und Migration der App zu befolgen, kann dadurch ein inkompatibler gemischter Stack entstehen.
ZimaOS 1.7 führte eine ausdrückliche Verwaltung von Updates installierter Apps ein
Der aktuelle ZimaOS App Store zeigt installierte Apps auf einer gemeinsamen Verwaltungsseite an, einschließlich ihres Status und der Verfügbarkeit von Updates. Pakete des App Store 2.0 enthalten außerdem Versionsmetadaten und Inhalts-Hashes, anhand derer Paketänderungen erkannt werden.
Siehe das aktuelle Update-Erlebnis im App Store.
Store-Apps und benutzerdefinierte Compose-Stacks haben unterschiedliche Verantwortliche für Updates
Bei einem App-Store-Paket entscheidet der Maintainer des Stores, wann ein getestetes Paket-Update veröffentlicht wird. Bei einem benutzerdefinierten Compose-Stack sind Sie der Maintainer: Sie entscheiden über Image-Tag bzw. Digest, lesen die Upstream-Versionshinweise, rufen das neue Image ab und erstellen den Stack neu.
Erwarten Sie nicht, dass der Store eine benutzerdefinierte Compose-Datei umschreibt oder eine benutzerdefinierte Datenbank automatisch migriert.
Das explizite Fixieren von Versionen ist bei wichtigen Diensten oft sicherer
Bei Datenbanken, Fotomanagern, Automatisierungssystemen und anderen zustandsbehafteten Apps bieten ein getestetes Versions-Tag oder ein Digest zusammen mit einem bewusst geplanten Upgrade-Zeitfenster die Möglichkeit, ein Rollback zu planen und Zeit zum Lesen von Änderungen mit potenziellen Inkompatibilitäten zu gewinnen.
Bei kurzlebigen bzw. zustandslosen Tools kann das Folgen eines veränderlichen Tags akzeptabel sein, sofern Sie weiterhin kontrollieren, wann der Abruf und die Neuerstellung erfolgen.
FAQ zu Docker-Tag-Updates
Hat der Nutzer der Quelle Docker latest grundlegend missverstanden?
Nein. ZimaOS fixierte im früheren Design tatsächlich die aufgelöste App-Version. Docker selbst erfordert jedoch ebenfalls das Abrufen eines Images und die Neuerstellung des Containers, um einen laufenden Container zu aktualisieren.
Verfügt das aktuelle ZimaOS über eine Verwaltungsseite für App-Updates?
Ja. Der App Store 2.0 führte den Update-Status und die Verwaltung installierter Apps ein.
Sollte jede App immer automatisch latest folgen?
Nein. Updates über veränderliche Tags können inkompatible Änderungen einführen, insbesondere bei zustandsbehafteten oder aus mehreren Containern bestehenden Anwendungen.
