Comment créer un déploiement Home Assistant récupérable avec des conteneurs

Un déploiement récupérable de Home Assistant en conteneur considère l’image du conteneur comme remplaçable ; le système réel est constitué de l’état, de la configuration, des secrets, des mappages de périphériques, du comportement réseau et de la procédure de restauration.

L’objectif n’est pas simplement de faire redémarrer Home Assistant par Docker. Il s’agit de reconstruire le service sur un hôte vierge après une mise à jour ayant échoué, la perte d’un disque ou le remplacement de l’hôte, puis de retrouver les mêmes utilisateurs, intégrations, automatisations, radios, données de base de données et identité réseau dans un délai connu.

Conserver l’état persistant hors de l’image du conteneur

Montez l’intégralité du répertoire de configuration Home Assistant sur un espace de stockage persistant de l’hôte et sauvegardez tout son contenu, y compris les répertoires cachés. Les migrations réalisées par la communauté échouent régulièrement lorsque les opérateurs copient les fichiers YAML visibles, mais oublient .storage, où sont conservés les éléments gérés depuis l’interface, les intégrations et d’autres données d’état. Un échec de migration de conteneur montre comment l’expansion des jokers du shell peut omettre silencieusement ces fichiers cachés.

Conservez le fichier Compose, le modèle de variables d’environnement, le fuseau horaire, le mode réseau, les mappages de périphériques, les chemins de montage liés et les éventuelles autorisations de groupe nécessaires dans des notes d’infrastructure versionnées. N’intégrez pas l’état propre à un foyer dans une image personnalisée, sauf si vous disposez aussi d’une compilation reproductible et d’une copie de récupération distincte.

La topologie complète du serveur Home Assistant ZimaSpace offre un modèle plus général : garder le chemin de contrôle réduit, séparer l’état persistant du stockage en masse et prévoir la récupération en dehors du domaine de défaillance actif avant d’ajouter d’autres dépendances de service.

Sauvegarder l’état de manière cohérente, pas seulement fréquemment

Une sauvegarde n’est utile que si ses fichiers représentent un instantané cohérent. Pour un déploiement SQLite local simple, arrêter le service pendant une fenêtre de maintenance et copier le volume de configuration persistant est facile à comprendre. Pour une base de données externe, sauvegardez-la avec une méthode garantissant la cohérence des données et indiquez avec quelle sauvegarde de configuration Home Assistant elle doit être associée.

Un récent flux de travail de sauvegarde de volumes Docker insiste sur la restauration de la copie plutôt que de supposer qu’une commande d’archivage réussie garantit la récupérabilité. Conservez au moins une génération hors de l’hôte Docker afin qu’une panne de SSD, du système de fichiers ou une suppression accidentelle ne puisse pas effacer à la fois le service et sa sauvegarde.

Consignez l’ancienneté de la sauvegarde, la version de l’application, la version de la base de données, la taille, la somme de contrôle, l’emplacement de la clé de chiffrement et les étapes de restauration sur un hôte vierge. Sans métadonnées de restauration, la conservation ne fait que créer une pile d’archives, pas un système de récupération.

Modéliser les dépendances et la disponibilité dans Compose

Lorsque Home Assistant dépend de MQTT, d’une base de données externe, d’un proxy ou d’un autre service local, l’ordre de démarrage des conteneurs ne garantit pas que les services sont prêts. Un processus peut être en cours d’exécution alors que son socket, son schéma ou son point de terminaison de contrôle d’état est encore indisponible. Un guide de disponibilité de Compose montre comment les vérifications d’état et les conditions de dépendance réduisent les problèmes de démarrage simultané.

Attribuez à chaque dépendance son propre indicateur d’état et son comportement en cas de panne. Home Assistant devrait réessayer de se connecter à une base de données en cours de démarrage, mais une base de données qui reste défaillante devrait être signalée comme telle plutôt que masquée derrière des redémarrages sans fin. Utilisez des stratégies de redémarrage pour récupérer après l’arrêt d’un processus ; utilisez des vérifications d’état et la surveillance pour déterminer si le service est réellement prêt.

Dans la mesure du possible, gardez les services facultatifs en dehors de la chaîne de démarrage critique. Un moteur de rendu de tableau de bord, un outil multimédia ou un exportateur de métriques défaillant ne devrait pas maintenir le contrôleur d’automatisation hors ligne.

Featured

ZimaBoard 2 - Mini-serveur domestique pour vos grandes idées

Single board computer zimaboard2

$339.00 - $529.00

Buy Now

Définir les limites des modifications et conserver une paire de retour arrière

Avant une mise à jour, consignez la balise de l’image Home Assistant actuelle, la définition Compose, la version de la base de données, la sauvegarde de la configuration et les versions des éventuels services auxiliaires qui participent au démarrage. Ne modifiez qu’une seule couche à la fois. En cas d’échec d’une mise à jour, revenir uniquement à l’image du conteneur peut être risqué si des migrations de configuration ou de base de données ont modifié l’état persistant.

Utilisez un environnement de restauration de test ou un répertoire de récupération cloné pour tester la version cible avant une migration majeure de l’hôte ou de la base de données. Conservez ensemble l’image précédemment reconnue comme fiable et l’instantané de l’état créé juste avant la mise à jour. Ne supprimez cette paire qu’une fois que la nouvelle version a passé les tests des automatisations, de l’historique, des radios, des tableaux de bord, des notifications et du redémarrage.

Un article plus récent sur la conception de Home Assistant avec Docker Compose considère la mise en réseau, le stockage persistant et les sauvegardes comme des décisions de déploiement explicites. C’est le bon modèle pour le retour arrière : préservez l’état et la définition du déploiement nécessaires à un conteneur de remplacement, et non le système de fichiers du conteneur lui-même, qui est jetable.

Reconstruisez le déploiement sur un hôte vierge avant de le déclarer récupérable

Choisissez une machine de réserve, une machine virtuelle ou un répertoire de test isolé, puis effectuez la récupération sans lire de fichiers depuis le système de fichiers du conteneur actif. Installez le moteur de conteneurs, placez-y la définition Compose, restaurez l’état persistant, recréez les secrets, connectez les radios à l’aide de chemins d’appareil stables, démarrez les dépendances requises, puis lancez Home Assistant.

Vérifiez la propriété et les permissions des fichiers avant de supposer que la sauvegarde est défectueuse. Les différences de permissions après la migration peuvent afficher un nouvel écran de configuration initiale alors que les données sont bien présentes. Un cas de récupération après une migration Docker montre comment les permissions et l’état masqué peuvent, chacun indépendamment, empêcher l’installation restaurée d’apparaître.

1. Connectez-vous avec le compte administrateur existant.
2. Vérifiez les intégrations, les entités, les automatisations, les tableaux de bord et l’historique.
3. Vérifiez la prise en charge des radios Zigbee, Z-Wave, Thread, Bluetooth ou autres.
4. Déconnectez Internet et exécutez une automatisation locale critique.
5. Redémarrez l’hôte et toutes les dépendances requises.
6. Mesurez le temps total de restauration entre un hôte vierge et le rétablissement du contrôle du foyer.

Utilisez un contrat de récupération pour chaque dépendance conteneurisée

Un déploiement récupérable repose sur une définition versionnée, un état stocké hors de l’hôte, des dépendances prêtes, une paire de versions permettant le retour arrière et une restauration chronométrée sur un hôte vierge. Une fois ces tests réussis, les conteneurs deviennent ce qu’ils sont censés être : des unités d’exécution remplaçables plutôt que des animaux de compagnie irremplaçables.