Så bygger du en återställningsbar Home Assistant-distribution med containrar

Eva Wong är Teknisk skribent och den boende fixaren på ZimaSpace. En livslång nörd med en passion för hemma-labb och öppen källkod, hon specialiserar sig på att översätta komplexa tekniska koncept till tillgängliga, praktiska guider. Eva tror att självhosting ska vara roligt, inte skrämmande. Genom sina handledningar ger hon gemenskapen verktyg att avmystifiera hårdvaruinstallationer, från att bygga sin första NAS till att bemästra Docker-containrar.

En återställningsbar containerdistribution av Home Assistant behandlar containeravbildningen som förbrukningsbar, medan tillstånd, konfiguration, hemligheter, enhetsmappningar, nätverksbeteende och återställningsprocedur utgör det verkliga systemet.

Målet är inte bara att få Docker att starta om Home Assistant. Målet är att kunna bygga upp tjänsten på en ren värd efter en misslyckad uppdatering, förlorad disk eller ersättning av värden och återfå samma användare, integrationer, automatiseringar, radioenheter, databastillstånd och nätverksidentitet inom en känd tidsram.

Håll beständigt tillstånd utanför containeravbildningen

Montera hela Home Assistants konfigurationskatalog på beständig lagring på värden och säkerhetskopiera allt i den, inklusive dolda kataloger. Vid community-migreringar misslyckas återställningen upprepade gånger när administratörer kopierar synliga YAML-filer men missar .storage, där UI-hanterade entiteter, integrationer och annat tillstånd lagras. En misslyckad containermigrering visar hur skalets globbning tyst kan utelämna dessa punktfiler.

Håll Compose-filen, mallen för miljövariabler, tidszon, nätverksläge, enhetsmappningar, sökvägar för bind-monteringar och eventuella nödvändiga gruppbehörigheter i versionshanterade infrastrukturanteckningar. Baka inte in unikt hushållstillstånd i en anpassad avbildning om du inte också har ett reproducerbart bygge och en separat återställningskopia.

ZimaSpaces fullständiga Home Assistant-servertopologi visar det övergripande mönstret: håll kontrollvägen liten, separera beständigt tillstånd från masslagring och placera återställningen utanför den aktiva felzonen innan du lägger till fler tjänsteberoenden.

Säkerhetskopiera tillstånd konsekvent, inte bara ofta

En säkerhetskopia är bara användbar om filerna representerar en sammanhängande tidpunkt. För en enkel lokal SQLite-distribution är det lätt att förstå en underhållsperiod där den beständiga konfigurationsvolymen stoppas och kopieras. För en extern databas ska du säkerhetskopiera databasen med en databaskonsistent metod och dokumentera vilken säkerhetskopia av Home Assistants konfiguration den hör ihop med.

Ett aktuellt arbetsflöde för säkerhetskopiering av Docker-volymer betonar att kopian ska återställas i stället för att man antar att ett lyckat arkiveringskommando innebär återställningsbarhet. Förvara minst en generation utanför Docker-värden så att ett SSD-fel, filsystemfel eller oavsiktlig rensning inte kan ta bort både tjänsten och säkerhetskopian.

Dokumentera säkerhetskopians ålder, programversion, databasversion, storlek, kontrollsumma, platsen för krypteringsnyckeln och stegen för återställning på en ren värd. Lagring utan återställningsmetadata skapar en hög arkiv snarare än ett återställningssystem.

Modellera beroenden och beredskap i Compose

När Home Assistant är beroende av MQTT, en extern databas, en proxy eller en annan lokal tjänst är startordningen för containrar inte samma sak som att tjänsten är redo. En process kan vara igång medan dess socket, schema eller hälsoslutpunkt fortfarande är otillgänglig. En beredskapsguide för Compose visar hur hälsokontroller och beroendevillkor minskar startkollisioner.

Ge varje beroende en egen hälsosignal och ett eget felbeteende. Home Assistant bör försöka igen när en databas håller på att starta, men en upprepade gånger ohälsosam databas ska synas som ett fel i stället för att döljas bakom ändlösa omstarter. Använd omstartspolicyer för att återhämta dig efter processavslut och hälsokontroller samt övervakning för att avgöra om tjänsten faktiskt är redo.

Håll valfria tjänster utanför den kritiska startkedjan när det är möjligt. En trasig instrumentpanelsrenderare, medietjänst eller metrikeexportör bör inte hålla automationsstyrenheten offline.

-15% OFF
Single board computer zimaboard2

Lås förändringsgränser och bevara ett återställningspar

Före en uppdatering ska du dokumentera aktuell Home Assistant-tag för avbildningen, Compose-definitionen, databasversionen, konfigurationssäkerhetskopian och versionerna av eventuella medföljande tjänster som deltar i starten. Ändra ett lager i taget. Om en uppdatering misslyckas kan det vara osäkert att bara återställa containeravbildningen efter att konfigurations- eller databastransaktioner har ändrat det beständiga tillståndet.

Använd en återställning i stagingmiljö eller en klonad återställningskatalog för att testa målversionen före en större värd- eller datasmigrering. Bevara den tidigare kända fungerande avbildningen och tillståndsögonblicksbilden som skapades omedelbart före uppdateringen som ett par. Ta bort paret först när den nya versionen har klarat tester av automatiseringar, historik, radioenheter, instrumentpaneler, aviseringar och omstart.

En nyare artikel om design av Home Assistant Docker Compose behandlar nätverk, beständig lagring och säkerhetskopiering som uttryckliga distributionsbeslut. Det är rätt modell för återställning: bevara det tillstånd och den distributionsdefinition som en ersättningscontainer behöver, inte själva det förbrukningsbara containerfilsystemet.

Bygg upp systemet på en ren värd innan du kallar distributionen återställningsbar

Välj en reservmaskin, virtuell maskin eller isolerad testkatalog och genomför återställningen utan att läsa filer från det aktiva containerfilsystemet. Installera containermotorn, placera Compose-definitionen, återställ beständigt tillstånd, återskapa hemligheter, anslut radioenheter med stabila enhetssökvägar, starta nödvändiga beroenden och starta Home Assistant.

Kontrollera filägarskap och behörigheter innan du antar att en säkerhetskopia är dålig. Skillnader i behörigheter efter en migrering kan visa en ny installationsskärm även när data finns. Ett fall med återställning efter Docker-migrering visar hur behörigheter och dolt tillstånd var för sig kan hindra den återställda installationen från att visas.

  1. Logga in med det befintliga administratörskontot.
  2. Verifiera integrationer, entiteter, automatiseringar, instrumentpaneler och historik.
  3. Bekräfta ägarskap för Zigbee, Z-Wave, Thread, Bluetooth eller andra radioenheter.
  4. Koppla från internet och kör en kritisk lokal automatisering.
  5. Starta om värden och alla nödvändiga beroenden.
  6. Mät den totala återställningstiden från tom värd till fungerande hushållsstyrning.

Använd ett återställningsavtal för varje containeriserat beroende

Komponent Beständigt objekt Bevis på återställning
Home Assistant Fullständigt /config-tillstånd Befintligt konto och automatiseringar återkommer
Databas Konsistent databassäkerhetskopia Historikfrågor och Recorder-skrivningar lyckas
MQTT/mäklare Konfiguration, autentiseringsuppgifter och kvarhållet tillstånd vid behov Enheter återansluter och publicerar
Radioenheter Enhetsidentitet, nätverksnycklar och mappning Koordinatorn återansluter utan ny parkoppling
Nätverk/proxy Portar, namn, certifikat och rutter Lokala och avsedda fjärrklienter återansluter

En återställningsbar distribution har en versionshanterad definition, tillstånd utanför värden, beroendeberedskap, ett återställningspar och en tidsmätt återställning på en ren värd. När dessa tester är godkända blir containrar det de är tänkta att vara: utbytbara körtidsenheter i stället för oersättliga husdjur.

NAS- och serverinstallation

Mer att läsa

Get More Builds Like This

Stay in the Loop

Get updates from Zima - new products, exclusive deals, and real builds from the community.

Stay in the Loop preferences

We respect your inbox. Unsubscribe anytime.