Come creare una distribuzione recuperabile di Home Assistant con i container

Una distribuzione containerizzata recuperabile di Home Assistant considera l’immagine del container come usa e getta, mentre lo stato, la configurazione, i segreti, le mappature dei dispositivi, il comportamento di rete e la procedura di ripristino costituiscono il sistema reale.

L’obiettivo non è semplicemente fare in modo che Docker riavvii Home Assistant. L’obiettivo è ricostruire il servizio su un host pulito dopo un aggiornamento non riuscito, la perdita di un disco o la sostituzione dell’host e recuperare gli stessi utenti, le integrazioni, le automazioni, le radio, lo stato del database e l’identità di rete entro un tempo noto.

Mantieni lo stato persistente al di fuori dell’immagine del container

Monta l’intera directory di configurazione di Home Assistant su uno storage persistente dell’host ed esegui il backup di tutto ciò che contiene, incluse le directory nascoste. Le migrazioni della community falliscono ripetutamente quando gli operatori copiano i file YAML visibili ma ignorano .storage, dove vengono conservate le entità gestite dall’interfaccia, le integrazioni e altri dati di stato. Una migrazione di container non riuscita mostra come il globbing della shell possa omettere silenziosamente quei file nascosti.

Conserva il file Compose, il modello delle variabili d’ambiente, il fuso orario, la modalità di rete, le mappature dei dispositivi, i percorsi dei bind mount e gli eventuali permessi di gruppo richiesti in note infrastrutturali versionate. Non incorporare lo stato specifico dell’abitazione in un’immagine personalizzata, a meno che tu non disponga anche di una build riproducibile e di una copia separata per il ripristino.

La topologia completa del server Home Assistant di ZimaSpace illustra il modello più ampio: mantieni ridotto il percorso di controllo, separa lo stato persistente dallo storage dei dati voluminosi e colloca il ripristino al di fuori del dominio di errore attivo prima di aggiungere altre dipendenze al servizio.

Esegui il backup dello stato in modo coerente, non solo frequente

Un backup è utile solo se i suoi file rappresentano un punto coerente nel tempo. Per una semplice distribuzione locale basata su SQLite, arrestare il servizio durante una finestra di manutenzione e copiare il volume di configurazione persistente è facile da comprendere. Per un database esterno, esegui il backup del database con un metodo coerente con il database e annota a quale backup della configurazione di Home Assistant deve essere associato.

Un recente workflow di backup dei volumi Docker sottolinea l’importanza di ripristinare la copia, invece di presumere che un comando di archiviazione completato con successo equivalga alla possibilità di recupero. Conserva almeno una generazione al di fuori dell’host Docker, così un SSD, un filesystem guasto o un prune accidentale non possano eliminare sia il servizio sia il backup.

Registra l’età del backup, la versione dell’applicazione, la versione del database, le dimensioni, il checksum, la posizione della chiave di cifratura e i passaggi per il ripristino su un host pulito. Conservare gli archivi senza i metadati di ripristino crea una pila di archivi, non un sistema di recupero.

Modella le dipendenze e la disponibilità in Compose

Quando Home Assistant dipende da MQTT, da un database esterno, da un proxy o da un altro servizio locale, l’ordine di avvio dei container non coincide con la disponibilità del servizio. Un processo può essere in esecuzione mentre il suo socket, lo schema o l’endpoint di integrità non sono ancora disponibili. Una guida alla disponibilità in Compose mostra come i controlli di integrità e le condizioni sulle dipendenze riducano le corse durante l’avvio.

Assegna a ogni dipendenza un proprio segnale di integrità e un comportamento in caso di errore. Home Assistant dovrebbe ritentare la connessione a un database in fase di avvio, ma un database che continua a non superare i controlli dovrebbe essere visibile come un errore, non nascosto da riavvii senza fine. Usa le policy di riavvio per recuperare dalle terminazioni dei processi; usa i controlli di integrità e il monitoraggio per stabilire se il servizio è realmente pronto.

Mantieni i servizi opzionali al di fuori della catena critica di avvio ogni volta che è possibile. Un renderer per dashboard, uno strumento multimediale o un esportatore di metriche guasto non dovrebbe tenere offline il controller delle automazioni.

-15% OFF

ZimaBoard 2 - Mini server domestico per la tua grande idea

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Definisci i confini delle modifiche e conserva una coppia per il rollback

Prima di un aggiornamento, annota il tag dell’immagine Home Assistant attualmente in uso, la definizione Compose, la versione del database, il backup della configurazione ed eventuali versioni dei servizi complementari coinvolti nell’avvio. Modifica un solo livello alla volta. Se un aggiornamento non riesce, eseguire il rollback della sola immagine del container può essere rischioso dopo che le migrazioni della configurazione o del database hanno modificato lo stato persistente.

Usa un ripristino di staging o una directory di ripristino clonata per testare la versione di destinazione prima di una migrazione importante dell’host o del database. Conserva come coppia l’immagine precedente sicuramente funzionante e lo snapshot dello stato creato immediatamente prima dell’aggiornamento. Elimina la coppia solo dopo che la nuova versione ha superato i test di automazioni, cronologia, radio, dashboard, notifiche e riavvio.

Un articolo più recente sulla progettazione di Home Assistant con Docker Compose considera rete, storage persistente e backup come decisioni esplicite di distribuzione. Questo è il modello corretto per il rollback: conserva lo stato e la definizione della distribuzione necessari al container sostitutivo, non il filesystem usa e getta del container stesso.

Ricostruisci su un host pulito prima di considerare recuperabile la distribuzione

Scegli una macchina di riserva, una macchina virtuale o una directory di test isolata ed esegui il ripristino senza leggere file dal filesystem del container in esecuzione. Installa il runtime dei container, inserisci la definizione Compose, ripristina lo stato persistente, ricrea i segreti, collega le radio usando percorsi di dispositivo stabili, avvia le dipendenze richieste e quindi avvia Home Assistant.

Controlla proprietario e permessi dei file prima di attribuire il problema a un backup difettoso. Differenze nei permessi dopo una migrazione possono mostrare una schermata iniziale di configurazione anche quando i dati sono presenti. Un caso di ripristino dopo una migrazione Docker mostra come i permessi e lo stato nascosto possano impedire indipendentemente la visualizzazione dell’installazione ripristinata.

1. Accedi con l’account amministratore esistente.
2. Verifica integrazioni, entità, automazioni, dashboard e cronologia.
3. Conferma la gestione di Zigbee, Z-Wave, Thread, Bluetooth o altre radio.
4. Disconnetti Internet ed esegui un’automazione locale critica.
5. Riavvia l’host e ogni dipendenza richiesta.
6. Misura il tempo totale di ripristino dall’host vuoto al controllo funzionante dell’abitazione.

Usa un contratto di ripristino per ogni dipendenza containerizzata

Una distribuzione recuperabile dispone di una definizione versionata, stato conservato al di fuori dell’host, disponibilità delle dipendenze, una coppia per il rollback e un ripristino temporizzato su un host pulito. Una volta superati questi test, i container diventano ciò che dovrebbero essere: unità runtime sostituibili, non animali domestici insostituibili.