Como migrar o Home Assistant de um único contentor para uma pilha de serviços resiliente

Passe o Home Assistant de um único contentor para uma stack de serviços resiliente, preservando primeiro o estado funcional do Home Assistant e, em seguida, separando os dados persistentes, os serviços complementares, os percursos de rede, as dependências de arranque e as cópias de segurança em funções explícitas. O objetivo não é criar mais contentores, mas reduzir a probabilidade de uma falha num serviço deitar abaixo toda a casa inteligente.

Faça a migração por etapas. Mantenha o contentor original e os respetivos dados intactos até que a nova stack consiga arrancar, passar nos testes de controlo local, sobreviver ao reinício do anfitrião e ser restaurada a partir de uma cópia de segurança. Uma stack resiliente é aquela cujo funcionamento consegue compreender em caso de falha, não aquela que tem o ficheiro Compose mais comprido.

Imobilize o contentor funcional e mapeie todas as dependências

Antes de alterar a topologia, registe a imagem/versão exata do Home Assistant, o caminho da configuração, as variáveis de ambiente, o modo de rede, os mapeamentos de dispositivos USB, os caminhos montados e as portas do anfitrião. Em seguida, faça uma lista de tudo de que o Home Assistant depende fora do contentor: broker MQTT, base de dados, Zigbee2MQTT, proxy inverso, VPN, DNS, certificados, cópias de segurança e quaisquer partilhas de rede. Isto será o mapa da migração.

Classifique cada dependência como estado autoritativo, serviço recriável ou infraestrutura externa. A configuração e o estado da base de dados do Home Assistant são autoritativos. Uma imagem de contentor transferida pode ser recriada. O DNS e o encaminhamento podem ser infraestrutura externa. Esta classificação evita um erro comum: fazer cópias de segurança da definição do contentor, mas esquecer os dados ou o serviço de que este precisa para funcionar.

Separe os dados persistentes dos contentores substituíveis

Atribua a cada serviço com estado um caminho persistente explícito ou um volume com nome, cuja propriedade e política de cópias de segurança conheça. A configuração do Home Assistant, o estado do MQTT, se for retido, os ficheiros da base de dados, os certificados e os segredos relacionados com as automatizações não devem existir apenas numa camada de escrita do contentor. As imagens e os contentores devem poder ser substituídos sem perder o estado da casa.

A recuperação de volumes também exige ter em conta a aplicação. Um artigo sobre um padrão portátil de cópia de segurança e restauro de volumes do Docker explica por que motivo copiar diretórios de execução em bruto não equivale a uma cópia de segurança portátil. No caso das bases de dados, coordene o método de cópia de segurança com a base de dados, em vez de assumir que uma cópia de ficheiros feita durante escritas ativas é consistente.

Adicione verificações de saúde, políticas de reinício e dependências de arranque de forma deliberada

Uma política de reinício responde à pergunta «o que deve o ambiente de execução fazer quando este processo termina?». Uma verificação de saúde responde à pergunta «o serviço está realmente pronto para ser utilizado?». São perguntas diferentes. Um contentor de base de dados pode estar em execução enquanto ainda reproduz registos; um mediador MQTT pode ter um processo ativo sem ainda aceitar a ligação esperada pelo Home Assistant.

Use verificações de saúde nos serviços que tenham uma condição de prontidão significativa e só acrescente ordenação de dependências quando o serviço dependente realmente precisar dela. Um artigo sobre as diferenças entre políticas de reinício e sinais de saúde dos serviços explica por que motivo os reinícios automáticos não comprovam a prontidão. Outro artigo sobre um padrão de prontidão no Compose para serviços dependentes é útil quando precisa de condicionar o arranque de um serviço dependente a uma condição de saúde real, em vez de a um temporizador de espera fixo.

Featured

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

Single board computer zimaboard2

$339.00 - $529.00

Buy Now

Limite os domínios de falha com redes, recursos e ordem de manutenção

Evite que uma análise de multimédia, uma migração de base de dados ou um contentor experimental consuma todos os ciclos de CPU, toda a RAM disponível ou todo o SSD da aplicação enquanto se espera que o Home Assistant continue a responder. Defina expectativas explícitas de recursos para serviços adjacentes exigentes, coloque as caches descartáveis longe do estado crítico sempre que possível e mantenha o caminho de controlo do Home Assistant numa rede local estável.

Separe também a ordem de atualização. Altere uma camada de cada vez: anfitrião, ambiente de execução de contentores, Home Assistant, base de dados e, por fim, os componentes complementares opcionais. Se tudo for atualizado na mesma janela de manutenção e a pilha falhar, deixa de ser possível identificar qual camada causou a regressão. A topologia Home Assistant da ZimaSpace, que separa as funções de computação, armazenamento e cópias de segurança, apresenta um mapa mais abrangente das funções de computação, armazenamento, rede e recuperação.

Faça a transição apenas depois de os testes de reinício e restauração serem aprovados

Inicie a nova pilha com uma cópia da configuração ou uma restauração controlada. Teste um painel local, uma automatização local, um percurso Zigbee ou Thread, o MQTT, se utilizado, o acesso ao histórico e à base de dados, as notificações e o acesso remoto, se fizer parte da conceção. Depois, reinicie o anfitrião inteiro - não apenas os contentores - e verifique se a ordem de arranque e os mapeamentos dos dispositivos continuam a funcionar sem intervenção manual.

Por fim, comprove a recuperação. Restaure para um destino temporário limpo ou, pelo menos, restaure os componentes dependentes do estado num espaço de nomes de teste separado. Uma cópia de segurança do plano de gestão pode induzir em erro se excluir os volumes das cargas de trabalho; este artigo sobre porque é que uma cópia de segurança do plano de gestão pode omitir dados das cargas de trabalho ilustra a razão pela qual as definições da pilha e os dados das aplicações precisam de coberturas de recuperação separadas.

1. Crie um instantâneo ou uma cópia de segurança do estado funcional do contentor único.
2. Mapeie as dependências e classifique os componentes como dependentes do estado ou reconstruíveis.
3. Crie caminhos persistentes e definições de serviços explícitos.
4. Adicione políticas de estado de funcionamento, reinício e recursos apenas quando resolverem um modo de falha real.
5. Teste o controlo local, os rádios, a base de dados, o acesso remoto, o reinício completo e a restauração.
6. Desative o contentor antigo apenas depois de a nova pilha passar em todos os testes.

O endpoint resiliente não significa «mais serviços». É uma pilha que permite reconstruir o Home Assistant sem perder o estado, recuperar dependências por uma ordem conhecida, impedir que os sistemas vizinhos mais exigentes esgotem os recursos do plano de controlo e isolar uma atualização que falhou, em vez de transformar o problema num mistério que afeta toda a casa.