Problem opisany w źródle rzeczywiście występował w modelu aplikacji ZimaOS z lat 2024–2025: instalacja aplikacji z użyciem tagu latest mogła rozwiązać ten tag w momencie instalacji, ale następnie ZimaOS zachowywał ustaloną wersję zamiast automatycznie śledzić przyszłe zmiany rejestru kryjące się za tym samym tagiem. Zima-Giorgio wyjaśnił, że takie zachowanie było zamierzone ze względu na stabilność, i wielokrotnie ostrzegał, że wymuszenie aktualizacji aplikacji może ją uszkodzić.
Od tamtej pory zmieniły się dwie rzeczy. Po pierwsze, ZimaOS 1.7 wprowadził App Store 2.0 z dedykowaną stroną zarządzania zainstalowanymi aplikacjami oraz informacjami o dostępnych aktualizacjach. Po drugie, nadal obowiązują zasady Dockera: uruchomiony kontener nigdy nie staje się automatycznie nowym obrazem tylko dlatego, że tag latest w rejestrze został przesunięty. Aktualizacja zawsze wymaga wykrycia lub pobrania zmienionego obrazu oraz odtworzenia kontenera albo stosu.
Historyczny projekt ZimaOS rozwiązywał tag, a następnie przypinał wersję
Giorgio wyjaśnił, że latest działał w momencie instalacji aplikacji, po czym ZimaOS utrzymywał wersję bez zmian. Miało to ograniczać ryzyko nieoczekiwanych awarii spowodowanych zmianami obrazów źródłowych dokonywanymi bez wiedzy użytkowników.
Później ten sam problem społeczność napotkała w przypadku tagu develop i prawdopodobnie dowolnego zmiennego tagu o nazwie własnej — nie tylko latest.
Dockerowy tag latest nigdy nie oznacza „automatycznie aktualizuj mój uruchomiony kontener”
Zmienny tag jest tylko wskaźnikiem w rejestrze. Jeśli jutro example/app:latest zacznie wskazywać nowy obraz, już utworzony kontener nadal będzie używać dotychczasowego obrazu, dopóki proces aktualizacji nie pobierze nowego obrazu i nie odtworzy kontenera.
Dlatego „latest” i „automatyczna aktualizacja” to dwa odrębne pojęcia, także poza ZimaOS.
Źródło wykorzystywało jawne tagi wersji jako obejście problemu
CogZog poinformował, że ręcznie zmienił tag Immich na numer opublikowanej wersji i zaktualizował aplikację do wersji v1.132.3. Giorgio później powiedział, że użytkownicy potrzebujący konkretnej wersji mogą edytować pole wersji aplikacji i zapisać zmiany.
Było to obejście na poziomie społeczności lub użytkownika, a nie dowód na to, że bezrefleksyjna aktualizacja każdej aplikacji do najnowszego obrazu źródłowego jest bezpieczna.
Aplikacje wielokontenerowe mogą ulec awarii, gdy zaktualizowany zostanie tylko jeden obraz
Immich jest dobrym przykładem: komponenty serwera, uczenia maszynowego, bazy danych i pamięci podręcznej mogą wymagać skoordynowanych migracji. Zmiana jednego tagu bez postępowania zgodnie z instrukcjami dotyczącymi wydań i migracji aplikacji źródłowej może doprowadzić do powstania niezgodnego stosu.
ZimaOS 1.7 dodał jawne zarządzanie aktualizacjami zainstalowanych aplikacji
Obecny App Store ZimaOS prezentuje zainstalowane aplikacje na jednej stronie zarządzania, wraz z ich stanem i informacjami o dostępnych aktualizacjach. Pakiety App Store 2.0 zawierają również metadane wersji i skróty zawartości używane do wykrywania zmian w pakietach.
Zobacz obecny mechanizm aktualizacji w App Store.
Aplikacje ze sklepu i niestandardowe stosy Compose mają różnych operatorów aktualizacji
W przypadku pakietu z App Store jego opiekun decyduje, kiedy opublikować przetestowaną aktualizację pakietu. W przypadku niestandardowego stosu Compose to Ty jesteś jego opiekunem: decydujesz o tagu lub skrócie obrazu, czytasz informacje o wydaniu źródłowym, pobierasz nowy obraz i odtwarzasz stos.
Nie oczekuj, że sklep zmodyfikuje niestandardowy plik Compose albo automatycznie przeprowadzi migrację niestandardowej bazy danych.
Jawne przypinanie wersji jest często bezpieczniejsze w przypadku ważnych usług
W przypadku baz danych, menedżerów zdjęć, systemów automatyzacji i innych aplikacji przechowujących dane przetestowany tag wersji lub skrót obrazu, wraz z zaplanowanym oknem aktualizacji, ułatwia przygotowanie planu wycofania zmian i daje czas na zapoznanie się z potencjalnie niekompatybilnymi zmianami.
W przypadku narzędzi jednorazowych lub bezstanowych korzystanie ze zmiennego tagu może być akceptowalne, jeśli nadal kontrolujesz moment pobrania obrazu i odtworzenia kontenera.
Najczęstsze pytania dotyczące aktualizacji tagów Dockera
Czy użytkownik cytowany w źródle całkowicie nie rozumiał działania Dockerowego latest?
Nie. W historycznym projekcie ZimaOS rzeczywiście przypinano ustaloną wersję aplikacji, ale sam Docker również wymaga pobrania obrazu i odtworzenia kontenera, aby zaktualizować działający kontener.
Czy obecny ZimaOS ma stronę zarządzania aktualizacjami aplikacji?
Tak. App Store 2.0 dodał informacje o aktualizacjach zainstalowanych aplikacji i możliwość zarządzania nimi.
Czy każda aplikacja powinna zawsze automatycznie korzystać z najnowszej wersji?
Nie. Aktualizacje oparte na zmiennych tagach mogą wprowadzać niekompatybilne zmiany, szczególnie w przypadku aplikacji przechowujących dane lub składających się z wielu kontenerów.
