Une checklist préalable à la mise à niveau pour les conteneurs et les dépendances de Home Assistant

Avant de mettre à niveau Home Assistant Container, consignez le contrat du conteneur en cours d’exécution, vérifiez l’existence d’une sauvegarde hors conteneur, contrôlez la disponibilité des dépendances et conservez une image de restauration testée.

La configuration persistante peut survivre à la recréation du conteneur, contrairement aux dongles USB, aux services de base de données, aux modes réseau, aux secrets, aux intégrations personnalisées ou aux conteneurs associés. Établissez la checklist à partir du déploiement actuel exact, et non d’un exemple générique de Compose. Ne téléchargez pas la nouvelle image et ne redémarrez pas tant que la sauvegarde n’est pas localisable en dehors du conteneur, que l’espace libre requis n’est pas confirmé et que la référence de l’ancienne image ne peut pas être restaurée.

Consigner le contrat du conteneur en cours d’exécution

Consignez le condensat ou la version exacte de l’image Home Assistant, les arguments du conteneur, le mode réseau, les ports publiés, les variables d’environnement, la politique de redémarrage, le fuseau horaire, les options de sécurité, la vérification d’état, les chemins montés et les mappages de périphériques. Exportez la définition Compose ou d’orchestration actuelle et comparez-la au conteneur en cours d’exécution afin de détecter les écarts.

Les migrations de conteneurs dépendent souvent de bien plus que du répertoire de configuration visible. Un témoignage de la communauté sur le passage de Home Assistant OS aux conteneurs présente des définitions distinctes pour Zigbee2MQTT, le broker et la pile, montrant pourquoi l’ensemble de la pile de conteneurs doit être inventorié.

RÉUSSI signifie qu’un autre administrateur pourrait recréer le conteneur actuel à partir de ces informations, sans rien deviner. ÉCHEC signifie qu’un montage, un périphérique, un secret ou une commande n’existe que dans l’état d’exécution. Mettez le fichier de déploiement en conformité avant la mise à niveau ; sinon, la restauration risque de recréer un environnement différent.

Vérifier la sauvegarde en dehors du conteneur

Créez la sauvegarde prévue, copiez-la ou stockez-la en dehors du système de fichiers du conteneur et, de préférence, en dehors du même domaine de panne que l’hôte, puis consignez son horodatage et sa taille. Vérifiez qu’elle inclut la configuration persistante, les enregistrements de stockage masqués, les secrets nécessaires à la restauration et toute sauvegarde de base de données externe requise par l’architecture choisie.

Une discussion sur la restauration Docker recommande explicitement de conserver les sauvegardes en dehors du conteneur et de copier la sauvegarde la plus récente avant de supprimer l’ancienne instance. Cette règle de sauvegarde hors conteneur empêche le remplacement du conteneur de supprimer l’unique copie de récupération.

RÉUSSI signifie que le fichier est lisible depuis l’environnement de récupération et que son contenu ou une restauration de test a été vérifié. ÉCHEC signifie que la sauvegarde existe uniquement dans le volume modifié ou qu’elle dépend d’identifiants non documentés. Arrêtez la mise à niveau jusqu’à ce que la récupération soit indépendante du nouveau conteneur.

Vérifier les dépendances liées à la base de données, au stockage et aux dongles radio

Consignez le moteur et la version de la base de données, les versions du broker et du pont, les chemins des périphériques USB, l’état du micrologiciel radio, les adresses réseau, les noms DNS et l’état de santé de chaque service associé requis. Vérifiez l’espace libre actuel pour les couches d’image, les opérations de migration de la base de données, les journaux et la copie de restauration.

Une procédure pratique de mise à jour des conteneurs avertit qu’une migration de schéma de base de données peut retarder la disponibilité de l’API et que des redémarrages répétés peuvent interrompre sa progression. La séquence présentée dans une mise à jour Docker prenant en compte la restauration recommande de définir une fenêtre d’observation de la migration avant de modifier l’image en cours d’exécution.

RÉUSSI signifie que chaque dépendance est saine, accessible, compatible avec la version cible et incluse dans la stratégie de restauration. ÉCHEC signifie qu’un chemin radio est instable, qu’une base de données est déjà défaillante ou que l’espace libre est limite. Réparez d’abord la référence de base afin qu’un problème préexistant ne soit pas attribué à la mise à niveau.

-15% OFF

ZimaBoard 2 - Mini serveur domestique pour votre grande idée

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Examiner les intégrations personnalisées et les risques liés à la version

Répertoriez les intégrations personnalisées, les ressources d’interface, les thèmes, les automatisations qui appellent des services obsolètes et les composants associés dont la version est figée. Vérifiez leur état de maintenance et leur compatibilité avec la version cible. Ne désactivez rien par défaut ; déterminez plutôt quel composant facultatif peut être isolé en premier en cas d’échec du démarrage.

Les utilisateurs de Home Assistant qui prévoient des mises à niveau Docker vérifient généralement les étapes de sauvegarde et de restauration avant de modifier une version utilisée depuis longtemps. Une discussion sur la préparation d’une mise à jour de conteneur montre pourquoi l’ancienne image et les données persistantes doivent rester disponibles ensemble.

RÉUSSI signifie que les risques de compatibilité connus disposent d’un ordre d’isolement et qu’aucun ne bloque le contrôle local essentiel. ÉCHEC signifie qu’un composant personnalisé non maintenu est requis mais n’a pas été testé. Reportez l’opération, testez l’image cible sur une copie ou acceptez un mode dégradé documenté avant de planifier l’interruption de service en production.

Définir le seuil de mise à niveau et le déclencheur de restauration

Écrivez l’ordre exact d’arrêt, les étapes de téléchargement et de recréation de l’image, les signaux de migration attendus, la checklist de validation, la durée maximale d’interruption et la commande de restauration. Conservez le condensat de l’ancienne image et ne modifiez pas manuellement les données persistantes pendant la période d’observation du premier démarrage. Choisissez une fenêtre de maintenance durant laquelle un contrôle local manuel est disponible.

Utilisez la checklist de migration sécurisée de ZimaSpace pour inclure les dongles radio, le stockage, les paramètres réseau, les intégrations et une solution de repli testée qui ne se limite pas au conteneur lui-même.

Ne poursuivez que lorsque toutes les étapes précédentes sont validées. Après la mise à niveau, vérifiez les journaux, Recorder, les intégrations essentielles, une automatisation locale, un accès distant, la création d’une sauvegarde et un second redémarrage. Revenez en arrière si les erreurs de migration se répètent, si le contrôle essentiel dépasse la durée d’interruption autorisée ou si le nouveau conteneur ne peut pas reproduire le contrat consigné.