Lista de verificação pré-atualização para contentores e dependências do Home Assistant

Eva Wong

IceWhale author

Eva Wong é a Redatora Técnica e e entusiasta residente na ZimaSpace. Uma geek de longa data com paixão por homelabs e software de código aberto, ela é especialista em traduzir conceitos técnicos complexos em guias acessíveis e práticos . Eva acredita que o auto-hospedagem deve ser divertida, não intimidante. Através dos seus tutoriais, ela capacita a comunidade adesmistificar configurações de hardware , desde a construção do seu primeiro NAS até dominar os contêineres Docker., from building their first NAS to mastering Docker containers.

A Pre-Upgrade Checklist for Home Assistant Containers and Dependencies - Zima Store Online

Antes de atualizar o Home Assistant Container, registe o contrato do contentor em execução, verifique uma cópia de segurança fora do contentor, confirme a preparação das dependências e preserve uma imagem de reversão testada.

A configuração persistente pode sobreviver à recriação do contentor, mas os rádios USB, os serviços de base de dados, os modos de rede, os segredos, as integrações personalizadas ou os contentores complementares podem não sobreviver. Elabore a lista de verificação com base na implementação atual exata, não num exemplo genérico de Compose. Não faça pull nem reinicie até ser possível localizar a cópia de segurança fora do contentor, confirmar o espaço livre necessário e restaurar a referência da imagem anterior.

Registe o contrato do contentor em execução

Registe o digest ou a versão exata da imagem do Home Assistant, os argumentos do contentor, o modo de rede, as portas publicadas, as variáveis de ambiente, a política de reinício, o fuso horário, as opções de segurança, a verificação de estado, os caminhos montados e os mapeamentos de dispositivos. Exporte a definição atual do Compose ou da orquestração e compare-a com o contentor em execução para detetar divergências.

As migrações de contentores dependem frequentemente de mais do que o diretório de configuração visível. Um relato da comunidade sobre a passagem do Home Assistant OS para contentores destaca definições separadas para Zigbee2MQTT, o broker e a stack, mostrando por que motivo toda a stack de contentores tem de ser inventariada.

PASSA significa que outro administrador poderia recriar o contentor atual a partir do registo, sem ter de adivinhar. FALHA significa que uma montagem, um dispositivo, um segredo ou um comando existe apenas no estado de execução. Reconcilie o ficheiro de implementação antes de atualizar; caso contrário, a reversão poderá recriar um ambiente diferente.

Verifique a cópia de segurança fora do contentor

Crie a cópia de segurança planeada, copie-a ou armazene-a fora do sistema de ficheiros do contentor e, de preferência, fora do mesmo domínio de falha do anfitrião; em seguida, registe a respetiva data, hora e tamanho. Confirme que inclui a configuração persistente, os registos de armazenamento ocultos, os segredos necessários para a reposição e qualquer cópia de segurança de base de dados externa exigida pela arquitetura escolhida.

Uma discussão sobre a reposição no Docker recomenda explicitamente manter as cópias de segurança fora do contentor e copiar a cópia de segurança mais recente antes de remover a instância antiga. Essa regra da cópia de segurança fora do contentor impede que a substituição do contentor elimine a única cópia de recuperação.

PASSA significa que o ficheiro pode ser lido a partir do ambiente de recuperação e que o seu conteúdo ou uma reposição de teste foi verificado. FALHA significa que a cópia de segurança existe apenas no volume que está a ser alterado ou depende de credenciais não documentadas. Pare a atualização até a recuperação ser independente do novo contentor.

Verifique as dependências de base de dados, armazenamento e rádio

Registe o motor e a versão da base de dados, as versões do broker e da ponte, os caminhos dos dispositivos USB, o estado do firmware do rádio, os endereços de rede, os nomes DNS e o estado de todos os serviços complementares necessários. Verifique o espaço livre atual para camadas de imagens, operações de migração da base de dados, registos e a cópia de reversão.

Um fluxo de trabalho prático para atualizar contentores alerta para o facto de a migração do esquema da base de dados poder atrasar a disponibilidade da API e de reinícios repetidos poderem interromper o progresso. A sequência apresentada em uma atualização Docker com reversão apoia a definição de uma janela de observação da migração antes de tocar na imagem em execução.

PASSA significa que todas as dependências estão saudáveis, acessíveis, compatíveis com a versão de destino e incluídas no planeamento da reversão. FALHA significa que um caminho de rádio está instável, uma base de dados já não está saudável ou o espaço livre é insuficiente. Corrija primeiro a linha de base, para que uma falha preexistente não seja atribuída à atualização.

-15% OFF

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

Single board computer zimaboard2

Analise as integrações personalizadas e o risco da versão

Faça uma lista das integrações personalizadas, dos recursos de frontend, dos temas, das automações que chamam serviços obsoletos e dos componentes complementares fixados a versões específicas. Verifique o respetivo estado de manutenção e a compatibilidade com a versão de destino. Não desative nada por predefinição; em vez disso, identifique qual o componente opcional que pode ser isolado primeiro se o arranque falhar.

Os utilizadores do Home Assistant que planeiam atualizações do Docker verificam habitualmente os passos de cópia de segurança e reversão antes de alterar uma versão em execução há muito tempo. Uma discussão sobre a preparação da atualização do contentor ilustra por que motivo a imagem antiga e os dados persistentes têm de permanecer disponíveis em conjunto.

PASSA significa que os riscos de compatibilidade conhecidos têm uma ordem de isolamento e que nenhum bloqueia o controlo local essencial. FALHA significa que é necessário um componente personalizado sem manutenção, mas não testado. Adie, teste a imagem de destino contra uma cópia ou aceite um modo degradado documentado antes de agendar a indisponibilidade em produção.

Defina o critério de atualização e o acionador de reversão

Escreva a ordem exata de paragem, os passos para fazer pull da imagem e recriar o contentor, os sinais de migração esperados, a lista de validação, o período máximo de indisponibilidade e o comando de reversão. Preserve o digest da imagem antiga e não altere manualmente os dados persistentes durante o período de observação do primeiro arranque. Escolha uma janela de manutenção com controlo manual local disponível.

Utilize a lista de verificação para uma migração segura da ZimaSpace, incluindo rádios, armazenamento, definições de rede, integrações e uma alternativa de recuperação testada para além do próprio contentor.

Avance apenas quando todos os critérios anteriores forem cumpridos. Após a atualização, verifique os registos, o Recorder, as integrações essenciais, uma automação local, um caminho remoto, a criação de uma cópia de segurança e um segundo reinício. Reverta quando os erros de migração se repetirem, o controlo essencial ultrapassar o limite de indisponibilidade ou o novo contentor não conseguir reproduzir o contrato registado.