Peut-on revenir à une version antérieure de l’image d’un conteneur sans perdre les données de l’application ?
Oui, vous pouvez revenir à une image de conteneur antérieure sans perdre les données de l’application lorsque l’état persistant se trouve à l’extérieur du conteneur et reste compatible avec l’ancienne version.
Sur un NAS domestique, le remplacement de l’image recrée normalement uniquement l’environnement d’exécution de l’application, tandis que les volumes nommés ou les montages bind conservent les bases de données, les paramètres et les fichiers utilisateur. Le point critique concerne les modifications de schéma : une image plus récente peut migrer la base de données ou réécrire la configuration d’une manière que l’ancienne image ne peut pas lire. Avant le retour en arrière, sauvegardez les montages actuels, l’identité de l’image, la configuration, les secrets ainsi qu’une sauvegarde cohérente des données.
Figez l’état actuel avant de modifier l’image
Désactivez les mises à jour automatiques des images et notez le tag actuel de l’image, son condensé immuable, la configuration du conteneur, les variables d’environnement, les réseaux, les ports, les montages, la politique de redémarrage et la vérification d’état. Enregistrez le fichier Compose ou la configuration exportée séparément du conteneur.
Un workflow de retour en arrière pour les conteneurs NAS recommande de conserver une image précédente connue plutôt que de dépendre d’un tag latest susceptible de changer. Le point de récupération utilisable est la version précise de l’image précédente, avec la configuration qui l’exécutait.
Effectuez une sauvegarde ou un instantané cohérent de la base de données avant d’arrêter la version la plus récente. Ne considérez pas le volume existant comme une copie de restauration, car il peut déjà contenir des modifications de schéma ou de données apportées par la mise à jour.
Vérifiez que les données de l’application se trouvent en dehors de la couche accessible en écriture
Répertoriez chaque volume nommé et chaque montage bind, puis identifiez les bases de données, fichiers téléversés, extensions, certificats, caches ou configurations encore stockés uniquement dans la couche accessible en écriture du conteneur.
Le stockage persistant ne survit au remplacement du conteneur que lorsque le nouveau conteneur se reconnecte au même emplacement de données externe. Le workflow de changement de version d’image de SynoForum vérifie explicitement que les données des volumes restent sur le stockage du NAS avant de recréer un conteneur à partir d’une autre image.
Si des données critiques existent uniquement dans la couche accessible en écriture, copiez-les ou exportez-les avant de supprimer le conteneur actuel. Considérez cette extraction comme une étape de récupération, et non comme une raison de conserver indéfiniment un conteneur sans version.
Épinglez exactement l’ancienne image au lieu de réutiliser latest
Téléchargez ou localisez le tag ou le condensé de la dernière version connue comme fonctionnelle, puis modifiez uniquement la référence de l’image. Vérifiez l’architecture, l’édition de l’application et les variables d’environnement requises avant de recréer le service.
Les utilisateurs qui reviennent à une version antérieure de services gérés par Compose reviennent généralement à une version d’image explicite précédente plutôt que de demander à Docker d’annuler directement un conteneur en cours d’exécution. Une discussion pratique sur le retour en arrière consiste à modifier le tag d’image Compose épinglé et à recréer le service.
N’utilisez pas une ancienne image mise en cache dont l’identité est inconnue. Notez le condensé après le téléchargement afin qu’une autre reconstruction ne sélectionne pas silencieusement un binaire différent sous le même tag modifiable.
Vérifiez si la version la plus récente a modifié la base de données
Lisez les notes de version de l’application et les journaux de migration pour les versions comprises entre la cible du retour en arrière et l’image actuelle. Recherchez les modifications de schéma irréversibles, les configurations réécrites, les changements de clés de chiffrement ou les mises à niveau d’extensions.
Le retour en arrière d’une base de données est plus complexe que celui d’une image, car le code de l’application et le schéma doivent rester compatibles. Octopus décrit les migrations rétrocompatibles comme une exigence lorsque d’anciennes et de nouvelles versions de l’application peuvent coexister ou être inversées, faisant de la compatibilité du schéma entre les versions le facteur déterminant du retour en arrière.
Si l’ancienne image ne peut pas lire la base de données migrée, restaurez la sauvegarde de la base de données antérieure à la mise à niveau au lieu de faire pointer l’ancien code vers le nouvel état. Conservez séparément la base de données actuelle au cas où le retour en arrière devrait lui-même être annulé.
Recréez le service avec les mêmes chemins persistants
Arrêtez et recréez le conteneur de l’application avec l’ancienne image, tout en conservant les mêmes volumes nommés ou montages bind vérifiés. N’utilisez pas de commandes ni d’options d’interface qui suppriment les volumes.
Conservez les noms de réseau, les alias de service, les ports publiés, les correspondances UID/GID, les secrets et les cibles du proxy inverse, sauf si l’ancienne version exige une différence documentée. Un démarrage réussi du conteneur avec de mauvais montages peut créer une nouvelle application vide et donner l’impression d’une perte de données.
Examinez la liste des montages et les journaux de l’application avant de vous connecter ou d’autoriser l’exécution des tâches en arrière-plan. Si l’application initialise une nouvelle base de données, arrêtez-la immédiatement et corrigez le chemin des données plutôt que d’importer les données au mauvais emplacement.
Validez le retour en arrière et conservez une voie de récupération vers l’avant
Testez la connexion, les lectures et écritures dans la base de données, les téléversements, les tâches planifiées, les intégrations ainsi qu’un redémarrage contrôlé. Comparez un échantillon des enregistrements et des fichiers avec l’inventaire établi avant le retour en arrière.
Le workflow de ZimaSpace consacré aux instantanés des données d’application avant mise à jour constitue une préparation plus sûre pour les prochaines mises à niveau.
Le retour en arrière n’est terminé que lorsque l’ancienne image utilise les données persistantes prévues, que le schéma est compatible ou restauré, et que le service résiste à une nouvelle recréation. Conservez l’image la plus récente, sa sauvegarde de données et les notes du retour en arrière jusqu’à ce que l’ancienne version soit restée stable pendant la durée normale d’utilisation.
Produits recommandés
Assistance et conseils
Plus à lire
Plex peut-il partager un GPU avec un autre conteneur Docker ?
Plex et un autre conteneur peuvent souvent accéder au même GPU, mais vous devez tester la prise en charge des pilotes, le mappage des...
Comment déterminer si une erreur Plex vient du client ou du serveur
Reproduisez le même élément sur un autre client, comparez le chemin de session, puis recueillez les preuves côté serveur uniquement après que la portée...
Comment configurer le cache de Plex et le stockage temporaire du transcodage
Protégez l’état persistant de Plex en plaçant les fichiers temporaires de transcodage sur un stockage local adapté, puis vérifiez le nettoyage, l’espace libre et...
