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 verdadeiro sistema.

O objetivo não é simplesmente fazer com que o Docker reinicie o Home Assistant. O objetivo é reconstruir 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.

Manter o estado persistente fora da imagem do contentor

Monte o diretório completo de configuração do Home Assistant em armazenamento persistente do anfitrião e faça uma cópia de segurança de tudo o que se encontra no seu interior, incluindo diretórios ocultos. As migrações da comunidade falham repetidamente quando os operadores copiam os ficheiros YAML visíveis, mas não incluem o .storage, onde são mantidas as entidades geridas pela interface, as 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 dos bind mounts e quaisquer permissões de grupo necessárias em notas de infraestrutura versionadas. Não incorpore o estado exclusivo da casa numa imagem personalizada, a menos que disponha também de uma compilação reproduzível e de uma cópia separada para recuperação.

A topologia completa de servidor Home Assistant da ZimaSpace apresenta o padrão mais abrangente: mantenha reduzido 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ço.

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

Uma cópia de segurança só é útil se os seus ficheiros representarem um ponto coerente no tempo. Para uma implementação SQLite local simples, parar o serviço durante uma janela de manutenção e copiar o volume de configuração persistente é fácil de compreender. Para uma base de dados externa, faça a cópia de segurança utilizando 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 recente de cópia de segurança de volumes Docker salienta a importância de restaurar a cópia, em vez de presumir que um comando de arquivo concluído com sucesso equivale a capacidade 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 elimine simultaneamente o serviço e a cópia de segurança.

Registe a idade 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 de restauro num anfitrião limpo. A retenção sem metadados de restauro cria uma pilha de arquivos, não um sistema de recuperação.

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

Quando o Home Assistant depende de MQTT, de uma base de dados externa, de um proxy ou de outro serviço local, a ordem de arranque dos contentores não equivale à 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 de dependência reduzem as condições de corrida no arranque.

Dê a cada dependência o seu próprio sinal de estado e comportamento em caso de falha. O Home Assistant deve voltar a tentar ligar-se a uma base de dados que está a iniciar, mas uma base de dados repetidamente não saudável deve ser visível como uma falha, em vez de ficar escondida por reinícios intermináveis. Utilize políticas de reinício para recuperar de encerramentos de processos; utilize verificações de estado e monitorização para determinar se o serviço está realmente pronto.

Mantenha os serviços opcionais fora da cadeia crítica de arranque sempre que possível. Um processador de painéis avariado, uma ferramenta multimédia ou um exportador de métricas não deve manter o controlador de automatizações offline.

-15% OFF

ZimaBoard 2 - Mini Servidor Doméstico para a Sua Grande Ideia

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Fixar os limites das alterações e preservar um par de reversão

Antes de uma atualização, registe a etiqueta atual da imagem 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 quaisquer versões dos serviços complementares que participem no arranque. Altere uma camada de cada vez. Se uma atualização falhar, reverter apenas a imagem do contentor pode ser inseguro depois de as migrações da configuração ou da base de dados terem alterado o estado persistente.

Utilize um restauro de teste ou um diretório de recuperação clonado para testar a versão pretendida antes de uma migração importante do anfitrião ou da base de dados. Preserve a imagem anterior conhecida como 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 os testes das automatizações, do histórico, dos rádios, dos painéis, das notificações e do reinício.

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

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

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

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

1. Inicie sessão com a conta de administrador existente.
2. Verifique as integrações, entidades, automatizações, painéis e o histórico.
3. Confirme a posse do Zigbee, Z-Wave, Thread, Bluetooth ou de outros rádios.
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.

Utilizar um contrato de recuperação para cada dependência em contentor

Uma implementação recuperável tem uma definição versionada, estado fora do anfitrião, prontidão das dependências, um par de reversão e um restauro cronometrado num anfitrião limpo. Quando esses testes passam, os contentores tornam-se naquilo que devem ser: unidades de runtime substituíveis, em vez de animais de estimação insubstituíveis.