Le problème décrit était bien réel dans le modèle d’applications de ZimaOS en 2024–2025 : installer une application avec latest pouvait résoudre cette balise au moment de l’installation, mais ZimaOS conservait ensuite la version résolue au lieu de suivre automatiquement les futures modifications du registre derrière cette même balise. Zima-Giorgio a expliqué que ce comportement était intentionnel pour garantir la stabilité et a averti à plusieurs reprises que forcer la mise à niveau d’une application pouvait la rendre défaillante.
Deux éléments ont changé depuis. Premièrement, ZimaOS 1.7 a introduit l’App Store 2.0, avec une page dédiée à la gestion des applications installées et à l’état de leurs mises à jour. Deuxièmement, la sémantique de Docker reste importante : un conteneur en cours d’exécution ne devient jamais automatiquement la nouvelle image simplement parce que la balise latest du registre a changé. Une mise à jour nécessite toujours de détecter ou de télécharger une image modifiée, puis de recréer le conteneur ou la pile.
La conception historique de ZimaOS résolvait la balise, puis verrouillait la version
Giorgio a expliqué que latest était pris en compte lors de l’installation de l’application, après quoi ZimaOS conservait la version fixe. L’objectif était de limiter les risques de panne imprévue causée par des images en amont qui changeraient sans que l’utilisateur le sache.
Le même problème est ensuite apparu dans la communauté avec develop, et probablement avec toute balise nommée mutable, pas uniquement latest.
La balise latest de Docker ne signifie jamais « mettre automatiquement à jour mon conteneur en cours d’exécution »
Une balise mutable n’est qu’un pointeur vers une image du registre. Si example/app:latest pointe demain vers une nouvelle image, un conteneur déjà créé continue d’utiliser son image existante jusqu’à ce qu’un processus de mise à jour télécharge la nouvelle image et recrée le conteneur.
Par conséquent, « latest » et « mise à jour automatique » sont deux notions distinctes, même en dehors de ZimaOS.
La source utilisait des balises de version explicites comme solution de contournement
CogZog a indiqué avoir remplacé manuellement la balise d’Immich par le numéro de version publié, ce qui a permis de faire passer l’application à la version v1.132.3. Giorgio a ensuite précisé que les utilisateurs ayant besoin d’une version précise pouvaient modifier le champ de version de l’application et l’enregistrer.
Il s’agissait d’une solution de contournement appliquée au niveau de la communauté ou de l’utilisateur, et non d’une preuve qu’il est sans risque de mettre aveuglément chaque application à jour vers la dernière image publiée en amont.
Les applications à plusieurs conteneurs peuvent tomber en panne si une seule image est mise à jour
Immich en est un bon exemple : le serveur, le composant d’apprentissage automatique, la base de données et le cache peuvent nécessiter des migrations coordonnées. Modifier une seule balise sans suivre les instructions de publication et de migration du projet peut créer une pile incohérente.
ZimaOS 1.7 a ajouté une gestion explicite des mises à jour des applications installées
L’App Store actuel de ZimaOS présente les applications installées sur une seule page de gestion, avec notamment leur état et la disponibilité des mises à jour. Les paquets de l’App Store 2.0 incluent également des métadonnées de version et des hachages du contenu, utilisés pour détecter les modifications des paquets.
Consultez l’expérience actuelle de mise à jour de l’App Store.
Les applications de la boutique et les piles Compose personnalisées ont des responsables différents pour les mises à jour
Pour un paquet de l’App Store, le responsable de la boutique décide quand publier une mise à jour testée. Pour une pile Compose personnalisée, c’est vous qui en êtes responsable : vous choisissez la balise ou le condensat de l’image, consultez les notes de version en amont, téléchargez la nouvelle image et recréez la pile.
Ne vous attendez pas à ce que la boutique réécrive un fichier Compose personnalisé ou effectue automatiquement la migration d’une base de données personnalisée.
Le verrouillage explicite d’une version est souvent plus sûr pour les services importants
Pour les bases de données, les gestionnaires de photos, les systèmes d’automatisation et autres applications conservant des données, une balise de version testée ou un condensat, associé à une fenêtre de mise à niveau planifiée, facilite la préparation d’un retour en arrière et laisse le temps de lire les changements incompatibles.
Pour les outils jetables ou sans état, suivre une balise mutable peut être acceptable, à condition de garder le contrôle sur le moment où le téléchargement et la recréation sont effectués.
FAQ sur la mise à jour des balises Docker
L’utilisateur de la source avait-il complètement mal compris latest dans Docker ?
Non. Dans sa conception historique, ZimaOS verrouillait bien la version résolue de l’application, mais Docker exige également de télécharger l’image et de recréer le conteneur pour mettre à jour un conteneur en cours d’exécution.
La version actuelle de ZimaOS dispose-t-elle d’une page de gestion des mises à jour des applications ?
Oui. L’App Store 2.0 a ajouté l’état et la gestion des mises à jour des applications installées.
Chaque application devrait-elle toujours suivre automatiquement latest ?
Non. Les mises à jour basées sur des balises mutables peuvent introduire des changements incompatibles, en particulier pour les applications avec état ou composées de plusieurs conteneurs.
