detachbox
PáginasMantenha o nó rodando

Mantenha o nó rodando

O nó se atualiza sozinho e confere a própria saúde. O seu administrador mantém o Ubuntu e o kernel em dia e pode escolher o momento em que o Incus e o cloudflared mudam.

Confira com o doctor

sudo detachbox-node-host doctor

O doctor confere o nó de ponta a ponta e não muda nada. Cada verificação tem 20 segundos e mostra a linha dela assim que termina:

  • se o detachbox ainda aceita o token do nó, o node-host e a versão dele, e a última resposta do servidor;
  • as conexões do túnel com a Cloudflare e o caminho de volta por ele, até o node-host e até o gateway de terminais;
  • HTTPS e TLS de saída para api.detachbox.com;
  • o Incus e se ele está em hold, e se há builds mais novos do Incus ou do cloudflared esperando;
  • o módulo ZFS carregado agora e o que o próximo kernel vai carregar, a deduplicação, a saúde do pool e o quanto ele está cheio;
  • as suas redes privadas comparadas com o firewall dos terminais;
  • a imagem base e quando começou o último build dela.

Cada ✗ vem com a correção. Uma parte que trava, como o Incus ou o ZFS, mostra … within 20 s na linha ✗ dela, e as verificações seguintes dessa parte mostram not checked: … did not answer above em vez de esperar. Um … marca o que não faz a verificação falhar: o que ainda não dá para saber, como a primeira resposta do servidor nos minutos depois de o node-host reiniciar, ou uma atualização que está esperando. A linha de atualizações mostra ✓ Updates Incus <version>, cloudflared <version>: the newest builds apt knows of, ou … Updates not yet: …; <build> waits: sudo detachbox-node-host upgrade installs it (node-host does on a day no terminal runs).

sudo detachbox-node-host doctor --report envia o resultado ao detachbox, e o seu contato no detachbox vê o mesmo que você.

O que se atualiza sozinho

  • O node-host se atualiza sozinho poucos minutos depois de cada versão do detachbox. Ele só instala o que a chave de versões do detachbox assinou, e volta para a versão anterior se a nova não subir.
  • A imagem base dos seus terminais é reconstruída a cada 6 horas com as atualizações do Ubuntu e as últimas versões do Claude Code, do Codex e do OpenCode. Ela só entra no ar depois de um smoke test; um build que falha deixa o último bom no lugar. Os terminais em execução mantêm a imagem com que começaram, e um terminal novo ou reiniciado recebe a atual.

Incus e cloudflared

Os dois ficam em hold no apt, e o hold nunca é retirado: o seu próprio apt upgrade não mexe neles. Reiniciar o cloudflared derruba uma vez todas as conexões que passam pelo túnel do nó (abas de terminal, previews, uploads), e reiniciar o Incus derruba as conexões das abas de terminal abertas. Nos dois casos elas se reconectam sozinhas em segundos, e os terminais continuam rodando, com as sessões tmux, os agentes e todos os processos dentro deles. Um terminal iniciado ou parado nesses segundos falha uma vez e funciona quando você pede de novo, e um build da imagem base em andamento falha e é feito de novo em até 6 horas. Por isso eles só mudam num momento que você escolher, ou num dia em que nenhum terminal roda.

sudo detachbox-node-host upgrade --check      # consulta os repositórios dos dois fornecedores; nada muda
sudo detachbox-node-host upgrade              # diz o que há de mais novo e o que acontece com os terminais, pergunta [y/N]
sudo detachbox-node-host upgrade --confirm    # atualiza sem perguntar

O upgrade lista o que há de mais novo, quantos terminais estão rodando e o que os reinícios fazem com eles, e depois pergunta. Rodado sem um terminal onde perguntar, ele recusa e indica --confirm. Depois que os pacotes começam a ser instalados, o upgrade vai até o fim, aconteça o que acontecer com a sua sessão; sudo tail -f /var/lib/detachbox-node/install/install.log acompanha. Ele termina com o doctor e ✓ Upgraded: …, depois de cerca de um minuto no nosso nó de teste.

O node-host tenta o mesmo upgrade uma vez por dia, a primeira 15 minutos depois de subir, e só quando nada além do edge está rodando: nenhum terminal, nenhum build da imagem base. Com um terminal rodando, ele registra no log que o upgrade está esperando e tenta de novo um dia depois. Um nó onde sempre há algum terminal rodando nunca se atualiza sozinho: o doctor continua mostrando a atualização até você rodar upgrade.

Atualizações de kernel

O Ubuntu e o kernel ficam por sua conta. Instale cada kernel novo com o linux-headers dele, e o DKMS compila sozinho o ZFS 2.4.4 do nó para ele; no nosso nó de teste isso levou uns 4 minutos. Aí o doctor mostra uma linha ZFS for <kernel> para o kernel em execução e outra para o kernel instalado mais novo, o que o próximo boot carrega. As duas precisam mostrar ✓ antes de você reiniciar; depois de um reboot no kernel novo, o nó volta sozinho.

Se algum dia um kernel der boot sem o ZFS do nó, o node-host desliga a deduplicação antes que um terminal grave um único byte, e avisa no doctor e ao detachbox. Ele liga a deduplicação de novo no primeiro boot com um módulo corrigido.

Reboots

Um reboot para os processos em execução e as sessões tmux. O node-host e o túnel sobem com o servidor, e os seus terminais voltam sozinhos com os arquivos, os pacotes apt e as imagens Docker no lugar; os contêineres Docker com uma política restart: sobem de novo. Cada agente volta sozinho na última conversa e espera o engenheiro dele. Um agente que não voltou recomeça ali com Reiniciar o terminal nesta conversa.

Quando o nó fica offline

Um minuto depois de o nó parar de responder, o painel mostra Nó offline desde 14:02 na barra superior e na página Compute, e um terminal aberto avisa que se reconecta sozinho assim que o nó voltar. Os arquivos continuam no servidor. Depois de 10 minutos de silêncio, a conta dona do nó recebe um e-mail, que informa o horário e aponta para sudo detachbox-node-host doctor, e mais um quando o nó voltar a responder. Um reboot ou uma atualização do node-host nunca demora tanto.

Mais núcleos ou memória

Adicione-os ao servidor e avise o seu contato no detachbox. O node-host informa ao detachbox os núcleos, a memória e o pool do servidor, e o seu contato aplica o novo tamanho; nada muda sozinho. O Compute em execução assume o novo tamanho sem reiniciar, e a Atividade registra a mudança.

Quando o detachbox retira o nó

Se o registro do seu nó for cancelado, o doctor avisa numa linha, "✗ Account taken off", com o que fazer: sudo detachbox-node-host uninstall --confirm, ou, se você não esperava por isso, mande essa linha para o seu contato no detachbox. Até lá, o node-host fica quieto, com o túnel e o edge como estão, e consulta o detachbox a cada 15 minutos, então um nó recusado por engano volta dentro desse prazo. Uma recusa que não vem nas palavras do servidor do detachbox, como a de um proxy que pede o próprio login, não quer dizer que o nó foi retirado: o doctor avisa isso na linha Account. Libere o nó nesse proxy sem login, ou mande a linha para o seu contato no detachbox.