#dusk $DUSK @Dusk
Uma atualização de nó pode ter sucesso tecnicamente e ainda assim falhar operacionalmente.
Isso é o que considero importante no processo de atualização da Dusk.
O instalador foi projetado para proteger as partes que devem sobreviver a uma atualização, incluindo chaves de consenso e o estado da cadeia. Ao mesmo tempo, alguns arquivos de configuração e a definição do serviço systemd são recriados. Isso significa que o operador precisa restaurar explicitamente as configurações que definem o que a máquina deve fazer.
Para um validador normal, perder um sinalizador de recurso pode ser inconveniente. Para um operador de arquivo, pode ser muito mais sério: o nó pode permanecer online, produzir ou seguir blocos e parecer saudável enquanto, silenciosamente, perde as funções de arquivo das quais as aplicações dependem.
Eu também gosto do fato de que a Dusk verifica o binário de substituição antes de parar a Rusk e deixa o serviço parado depois. Isso dá ao operador uma chance de inspecionar a nova configuração em vez de reiniciar tudo às cegas.
Mas isso coloca uma responsabilidade importante sobre o ser humano.
A atualização mais segura não é necessariamente a que exige o menor trabalho manual. É aquela em que o operador consegue confirmar que o nó voltou com a função, os recursos e as configurações de rede corretos.
Para mim, esse é o verdadeiro critério de atualização na Dusk:
O nó está rodando — ou está rodando o trabalho para o qual ele foi realmente implantado?
#DUSK @DuskFoundation $GPS $ACE
Uma atualização de nó pode ter sucesso tecnicamente e ainda assim falhar operacionalmente.
Isso é o que considero importante no processo de atualização da Dusk.
O instalador foi projetado para proteger as partes que devem sobreviver a uma atualização, incluindo chaves de consenso e o estado da cadeia. Ao mesmo tempo, alguns arquivos de configuração e a definição do serviço systemd são recriados. Isso significa que o operador precisa restaurar explicitamente as configurações que definem o que a máquina deve fazer.
Para um validador normal, perder um sinalizador de recurso pode ser inconveniente. Para um operador de arquivo, pode ser muito mais sério: o nó pode permanecer online, produzir ou seguir blocos e parecer saudável enquanto, silenciosamente, perde as funções de arquivo das quais as aplicações dependem.
Eu também gosto do fato de que a Dusk verifica o binário de substituição antes de parar a Rusk e deixa o serviço parado depois. Isso dá ao operador uma chance de inspecionar a nova configuração em vez de reiniciar tudo às cegas.
Mas isso coloca uma responsabilidade importante sobre o ser humano.
A atualização mais segura não é necessariamente a que exige o menor trabalho manual. É aquela em que o operador consegue confirmar que o nó voltou com a função, os recursos e as configurações de rede corretos.
Para mim, esse é o verdadeiro critério de atualização na Dusk:
O nó está rodando — ou está rodando o trabalho para o qual ele foi realmente implantado?
#DUSK @DuskFoundation $GPS $ACE