Pesquisa de site

3 coisas que você deve saber sobre o planejamento de atualizações OTA em seu homelab


Defina seu plano de atualização over-the-air para telefones celulares, dispositivos IoT e computação de ponta antes mesmo de começar a codificar seu aplicativo.

As atualizações de um sistema costumavam ser relativamente simples. Quando um desenvolvedor precisava revisar algo que já havia distribuído ao público, um atualizador seria lançado para as pessoas executarem. Os usuários executariam o atualizador, permitindo que arquivos antigos fossem substituídos por novos arquivos e novos arquivos fossem adicionados. Mesmo com essas atualizações “relativamente diretas”, havia um problema. O que acontece quando a instalação de um usuário está em um estado inesperado? O que acontece quando uma atualização é interrompida? Essas questões são igualmente relevantes agora, quando todos os tipos de dispositivos estão online e, às vezes, precisam de atualizações de segurança importantes. Muitas atualizações hoje são entregues sem fio, over-the-air (OTA), e o potencial para conexões ruins, perda repentina de sinal ou perda de energia pode ser potencialmente desastroso para o que deveria ser uma atualização menor. Estas são as três principais estratégias que você precisa considerar ao planejar o fornecimento de atualizações over-the-air.

1. Verificação

O protocolo TCP possui muitas verificações incorporadas, portanto, geralmente é verdade que, ao enviar pacotes para um dispositivo, você pode ter certeza de que cada pacote foi recebido intacto. No entanto, o TCP não pode relatar erros sobre algo que não conhece, então cabe a você verificar coisas como:

  • Você enviou todos os arquivos necessários para a atualização? Um dispositivo não pode receber o que não foi enviado inicialmente.

  • Os arquivos recebidos são iguais aos arquivos que você enviou? No mínimo, verifique as somas SHA para verificar a integridade do arquivo.

  • Sempre que possível, use assinatura digital para garantir que o arquivo seja de uma fonte confiável.

  • Você deve verificar se o dispositivo é capaz de aplicar uma atualização antes de permitir o início da atualização. Verifique as permissões e o estado da bateria antes de iniciar uma atualização e certifique-se de que o processo de atualização substitua quaisquer eventos inesperados do usuário, como uma reinicialização programada ou hibernação.

  • Finalmente, você deve verificar se uma atualização que afirma ter sido concluída com êxito foi realmente concluída. Verifique a localização e a integridade dos arquivos no dispositivo de destino antes de permitir que a atualização seja oficialmente marcada como resolvida pelo sistema.

2. Fallback e estados de falha

O pior cenário para uma atualização é que um dispositivo seja deixado em um estado quebrado, de modo que não possa nem mesmo ser usado para continuar uma atualização abortada. Nesse cenário, os arquivos do atualizador existem no dispositivo de destino, mas o processo foi interrompido. Isso pode deixar um dispositivo em um estado desconhecido, onde alguns arquivos foram substituídos por versões atualizadas, enquanto outros não foram alterados. Na pior das hipóteses, os arquivos que foram atualizados são incompatíveis com os arquivos que ainda não foram atualizados e, portanto, o dispositivo não pode funcionar conforme o esperado.

Existem algumas estratégias para lidar com isso. A etapa inicial da atualização pode ser a instalação de uma imagem de inicialização ou ambiente especial dedicado à conclusão da atualização e a definição de um "sinalizador" no sistema para estabelecer que uma atualização está em andamento. Isso garante que mesmo quando um dispositivo perde energia repentinamente no meio de uma atualização, o processo de atualização é reiniciado durante a próxima inicialização. O sinalizador que sinaliza uma atualização bem-sucedida é removido somente depois que a atualização é verificada.

Uma imagem de inicialização especial pode não ser viável ou necessária, dependendo da política de segurança do dispositivo de destino e do que você está atualizando. O princípio permanece o mesmo, no entanto. Depois de iniciada, uma atualização deve estabelecer um ambiente no qual a atualização pendente seja o único caminho a seguir até que seja resolvida.

Porém, até que uma atualização receba permissão para iniciar, um usuário (quando houver) deve ter a capacidade de atrasar ou ignorar a atualização.

3. Aditivo

Em muitos dispositivos de borda e IoT, a base do dispositivo alvo é imutável. As atualizações apenas adicionam um estado conhecido de um sistema. Projetos como o Fedora Silverblue estão a demonstrar que este modelo pode funcionar em muitos mercados, para que o luxo possa tornar-se comum. Até então, porém, parte da aplicação bem-sucedida de uma atualização é compreender o ambiente que você está prestes a afetar.

No entanto, você não precisa de um núcleo imutável para aplicar atualizações aditivas. Você pode arquitetar um sistema para usar o mesmo conceito, usando atualização como uma forma de adicionar bibliotecas ou pacotes sem revisar as versões antigas. Como etapa final dessa atualização, o executável com caminhos atualizados é a única revisão real que você faz.

Atualizações OTA

O mundo está cada vez mais sem fio. Para telefones celulares, dispositivos IoT e computação de ponta, as atualizações over-the-air costumam ser a única opção. A implementação de uma política de atualização OTA exige um planejamento cuidadoso e uma contabilização cuidadosa de cenários improváveis. Você conhece melhor seus dispositivos de destino, portanto, mapeie seu esquema de atualização bem antes de começar a codificar, para que sua arquitetura inicial seja projetada para OTA robusto e seguro.

Artigos relacionados: