Como criar uma implementação recuperável do Home Assistant com contentores

Uma implementação recuperável do Home Assistant em contentor trata a imagem do contentor como descartável e considera o estado, a configuração, os segredos, os mapeamentos de dispositivos, o comportamento da rede e o procedimento de restauro como o sistema propriamente dito.

O objetivo não é apenas fazer com que o Docker reinicie o Home Assistant. É voltar a implementar o serviço num anfitrião limpo após uma atualização falhada, a perda de um disco ou a substituição do anfitrião e recuperar os mesmos utilizadores, integrações, automatizações, rádios, estado da base de dados e identidade de rede dentro de um prazo conhecido.

Mantenha o estado persistente fora da imagem do contentor

Monte o diretório completo de configuração do Home Assistant num armazenamento persistente do anfitrião e faça cópias de segurança de tudo o que contém, incluindo os diretórios ocultos. As migrações da comunidade falham repetidamente quando os operadores copiam ficheiros YAML visíveis, mas não incluem .storage, onde são guardadas entidades geridas pela interface, integrações e outros dados de estado. Uma falha de migração de contentor mostra como a expansão de padrões da shell pode omitir silenciosamente esses ficheiros ocultos.

Mantenha o ficheiro Compose, o modelo de variáveis de ambiente, o fuso horário, o modo de rede, os mapeamentos de dispositivos, os caminhos de montagem vinculada e as permissões de grupo necessárias em notas de infraestrutura com controlo de versões. Não incorpore num imagem personalizada o estado específico da casa, a menos que também tenha uma compilação reproduzível e uma cópia de recuperação separada.

A topologia completa do servidor Home Assistant da ZimaSpace apresenta o padrão mais abrangente: mantenha pequeno o caminho de controlo, separe o estado persistente do armazenamento em massa e coloque a recuperação fora do domínio de falha ativo antes de adicionar mais dependências de serviços.

Faça cópias de segurança do estado de forma consistente, não apenas frequente

Uma cópia de segurança só é útil se os ficheiros representarem um momento coerente. Numa instalação SQLite local simples, parar o serviço durante uma janela de manutenção e copiar o volume de configuração persistente é uma abordagem fácil de compreender. Para uma base de dados externa, faça a cópia de segurança com um método consistente com a base de dados e registe a que cópia de segurança da configuração do Home Assistant corresponde.

Um fluxo de trabalho recente para criar cópias de segurança de volumes Docker salienta a importância de restaurar a cópia, em vez de presumir que um comando de arquivo bem-sucedido garante a possibilidade de recuperação. Mantenha pelo menos uma geração fora do anfitrião Docker, para que uma falha do SSD, do sistema de ficheiros ou uma limpeza acidental não possa eliminar tanto o serviço como a cópia de segurança.

Registe a antiguidade da cópia de segurança, a versão da aplicação, a versão da base de dados, o tamanho, a soma de verificação, a localização da chave de encriptação e os passos para restaurar num anfitrião limpo. A retenção sem metadados de restauro cria um amontoado de arquivos, não um sistema de recuperação.

Modele as dependências e a prontidão no Compose

Quando o Home Assistant depende do MQTT, de uma base de dados externa, de um proxy ou de outro serviço local, a ordem de arranque dos contentores não é o mesmo que a prontidão do serviço. Um processo pode estar em execução enquanto o respetivo socket, esquema ou ponto de acesso de estado ainda não está disponível. Um guia de prontidão do Compose mostra como as verificações de estado e as condições das dependências reduzem as condições de corrida no arranque.

Defina um sinal de estado e um comportamento em caso de falha para cada dependência. O Home Assistant deve voltar a tentar ligar-se a uma base de dados que esteja a arrancar, mas uma base de dados que permaneça repetidamente em estado não saudável deve ser assinalada como falha, em vez de ficar oculta por reinícios intermináveis. Utilize políticas de reinício para recuperar de saídas dos processos; utilize verificações de estado e monitorização para determinar se o serviço está realmente pronto.

Sempre que possível, mantenha os serviços opcionais fora da cadeia de arranque crítica. Um renderizador de painéis, uma ferramenta multimédia ou um exportador de métricas com problemas não deve impedir o controlador de automatizações de funcionar.

Featured

ZimaBoard 2 - Mini servidor doméstico para a sua grande ideia

Single board computer zimaboard2

$339.00 - $529.00

Buy Now

Defina limites para as alterações e preserve um par para reversão

Antes de uma atualização, registe a etiqueta da imagem atual do Home Assistant, a definição do Compose, a versão da base de dados, a cópia de segurança da configuração e as versões de quaisquer serviços complementares envolvidos no arranque. Altere uma camada de cada vez. Se uma atualização falhar, reverter apenas a imagem do contentor pode ser inseguro depois de alterações persistentes ao estado provocadas por migrações da configuração ou da base de dados.

Utilize um ambiente de teste ou um diretório de recuperação clonado para testar a versão de destino antes de uma migração importante do anfitrião ou da base de dados. Preserve a imagem anterior comprovadamente funcional e o instantâneo do estado criado imediatamente antes da atualização como um par. Elimine esse par apenas depois de a nova versão passar nos testes de automatizações, histórico, rádios, painéis, notificações e reinício.

Um artigo mais recente sobre a conceção do Home Assistant Docker Compose trata a rede, o armazenamento persistente e as cópias de segurança como decisões explícitas da implementação. Esse é o modelo adequado para a reversão: preserve o estado e a definição da implementação de que um contentor de substituição necessita, não o próprio sistema de ficheiros descartável do contentor.

Recrie a instalação num anfitrião limpo antes de considerar a implementação recuperável

Escolha uma máquina suplente, uma VM ou um diretório de teste isolado e efetue a recuperação sem ler ficheiros do sistema de ficheiros do contentor em execução. Instale o runtime de contentores, coloque a definição Compose, restaure o estado persistente, recrie os segredos, ligue os rádios através de caminhos de dispositivo estáveis, inicie as dependências necessárias e arranque o Home Assistant.

Verifique a propriedade dos ficheiros e as permissões antes de presumir que a cópia de segurança está danificada. As diferenças de permissões após a migração podem apresentar um ecrã de configuração inicial, mesmo quando os dados existem. Um caso de recuperação de uma migração do Docker mostra como as permissões e o estado oculto podem, de forma independente, impedir que a instalação restaurada apareça.

1. Inicie sessão com a conta de administrador existente.
2. Verifique as integrações, entidades, automatizações, painéis e histórico.
3. Confirme a associação de Zigbee, Z-Wave, Thread, Bluetooth ou outro rádio.
4. Desligue a Internet e execute uma automatização local crítica.
5. Reinicie o anfitrião e todas as dependências necessárias.
6. Meça o tempo total de restauro, desde um anfitrião vazio até ao controlo funcional da casa.

Utilize um contrato de recuperação para cada dependência em contentores

Uma implementação recuperável tem uma definição versionada, estado fora do anfitrião, dependências prontas, um par de reversão e uma restauração cronometrada num anfitrião limpo. Depois de estes testes passarem, os contentores tornam-se aquilo que devem ser: unidades de execução substituíveis, em vez de animais de estimação insubstituíveis.