Multisservidor

Conecte outros servidores seus a uma instalação do sh0 e rode parte dos seus apps neles. O servidor principal mantém o painel, os builds e o roteamento.

Requisitos

• Licença Business e o papel admin ou owner: sem eles, todas as rotas de nós são recusadas.
• No servidor remoto: Docker instalado e em execução. O sh0 não instala nada lá.
• Acesso SSH do servidor principal ao remoto, com um usuário que possa usar o socket do Docker (/var/run/docker.sock): root ou um membro do grupo docker.
• Uma chave SSH registrada antes no painel (gerenciamento de chaves SSH), ou a senha do usuário.

Funcionamento

• O servidor principal mantém o banco de dados, o painel e o Caddy. Um nó apenas roda contêineres; o sh0 controla o Docker dele por um túnel SSH.
• As imagens são sempre construídas no servidor principal e depois transferidas ao nó (a implantação mostra a etapa transferring).
• Os domínios continuam apontando para o servidor principal. O Caddy dele encaminha cada requisição ao contêiner do nó por um relay que passa pelo mesmo túnel SSH.
• Nomes internos (my-api.internal) só resolvem dentro de um mesmo servidor: um app num nó não alcança por esse nome um serviço do mesmo projeto em outro servidor. O log de build avisa quando um projeto se estende por vários nós.

Adicionar um nó

1. No painel, abra Nós e depois Adicionar nodo.
2. Informe um Nome (minúsculas, dígitos e hífens, no máximo 64 caracteres) e o Nome do host (IP ou nome DNS; localhost e endereços de loopback são recusados).
3. Defina a Porta SSH (22 por padrão), o Usuário (root por padrão) e a Autenticação: Chave SSH ou Senha.
4. Salve e use Testar conexão: o sh0 verifica a conexão SSH e o Docker no nó.

Pela CLI (nodes create aceita --port para uma porta SSH não padrão e --password no lugar de --ssh-key):

sh0 nodes create --name worker-1 --host 203.0.113.20 --ssh-user root --ssh-key <ssh-key-id>
sh0 nodes list
sh0 nodes info <node-id>
sh0 nodes test <node-id>

Pela API:

curl -X POST https://panel.example.com/api/v1/nodes \
  -H "Authorization: Bearer $SH0_TOKEN" -H "Content-Type: application/json" \
  -d '{"name":"worker-1","hostname":"203.0.113.20","port":22,"username":"root","auth_method":"ssh_key","ssh_key_id":"<ssh-key-id>"}'

• port, username e auth_method são opcionais (22, root, ssh_key). Com "auth_method":"password", envie password em vez de ssh_key_id; ela é guardada criptografada.
• Desde a 1.10.3: O sh0 tenta se conectar assim que o nó é criado: o status passa a online em caso de sucesso, a error com a mensagem em caso de falha. A tentativa é limitada a 15 segundos: em um endereço que não responde, o nó é registrado em error e a CLI sai com código 1, indicando nodes test para tentar novamente e nodes delete para removê-lo.
• A chave de host SSH do nó é registrada na primeira conexão e verificada depois. Se o servidor for reinstalado, a chave muda e a conexão é recusada: redefina a impressão digital (POST /api/v1/nodes/<id>/reset-fingerprint) para que a próxima conexão registre a nova chave.

Implantar num nó

Ao criar um app a partir de um repositório Git, um Dockerfile, uma imagem Docker, um framework ou um arquivo compactado, o campo Nodo destino escolhe o servidor; pela API, envie node_id (o ID ou o nome do nó). Um valor vazio significa o servidor principal; um valor que não corresponde a nenhum nó é recusado em vez de implantado em silêncio no principal.

Mover um app

Um app é movido trocando seu node_id com PATCH /api/v1/apps/<id>. O app precisa estar parado antes; caso contrário a troca é recusada, porque o contêiner continuaria rodando no servidor antigo. Uma string vazia traz o app de volta ao servidor principal.

curl -X PATCH https://panel.example.com/api/v1/apps/<app-id> \
  -H "Authorization: Bearer $SH0_TOKEN" -H "Content-Type: application/json" \
  -d '{"node_id":"worker-1"}'

Depois reimplante o app: a imagem é construída no principal e transferida ao novo nó. O contêiner do nó antigo não é migrado e os dados dos volumes não acompanham: copie-os você mesmo.

Status dos nós

Nós lista cada servidor com seu status (Online, Pendente, Erro, Offline), a versão do Docker, CPU e memória, e o último contato. Um monitor reverifica os nós a cada 30 segundos e reabre os relays dos apps em execução após uma reconexão.

Remover um nó

Um nó só pode ser removido quando nenhum app estiver mais associado a ele: “Cannot delete node: N app(s) still assigned. Migrate them first.” Mova ou exclua esses apps antes e depois exclua o nó em Nós, com sh0 nodes delete <id-do-nó> ou DELETE /api/v1/nodes/<id>.

Limitações

• O principal é um ponto único de falha. Se ele parar, o painel, os builds e o roteamento para todos os nós param junto.
• Todo o tráfego passa pelo principal. As requisições chegam a um nó pelo relay SSH; dimensione a banda do principal de acordo.
• Sem posicionamento automático. O sh0 não escolhe um nó por você nem distribui réplicas entre nós: cada app roda num único servidor.
• Sem drenagem nem migração automática. Esvaziar um nó significa parar, mover e reimplantar seus apps um a um.
• Sem rede entre servidores. Veja os nomes internos acima.
• Use o ID do nó na CLI. sh0 nodes test, info e delete anunciam “Node ID or name”, mas na v1.10.2 só o ID é encontrado.