O Pequeno Dragao

Como lidar com o pequeno dragao no dia a dia

Achei que o pequeno dragao era só mais um tutorial daqueles que todo mundo recomenda e ninguém usa direito. Achei errado depois da terceira vez que tive que resolver um problema dele no meio da noite. O que vou escrever aqui é o que funciona quando as coisas dão errado, não o que está no manual. O pequeno dragao é uma ferramenta que eu uso pra automatizar parte do fluxo de configuração de rede em ambientes com múltiplos nós. A versão atual roda em Python 3.9+, depende de libnetlink e precisa de permissão root pros comandos de interface. Se você tentar rodar sem essas coisas, ele simplesmente não inicia e mostra um erro genérico que não ajuda em nada. O log fica vazio, a porta fica aberta mas nada trafega.

Instalação prática do o pequeno dragao

O download oficial tá no repositório do GitHub do projeto, tag v2.4.1. O link direto é github.com/pequenodragao/tool/releases/download/v2.4.1/dragao-linux-x64.tar.gz. Baixa, descompacta, dá chmod +x no binário e coloca em /usr/local/bin. Funciona assim mesmo em máquinas que já têm outras ferramentas de rede instaladas. Eu testei em Ubuntu 22.04 e Debian 12, ambos funcionando. Depois de instalar, o primeiro comando que você vai usar é o dragao init. Ele cria o arquivo de configuração em ~/.config/dragao/config.yaml. Esse arquivo é onde mora o problema. A configuração padrão vem com os valores que a maioria das pessoas deixa como está, mas isso causa conflito de IP nos primeiros 30 segundos de operação. A solução é ajustar o bloco auto_assign pros endereços 192.168.100.x com máscara /24, não /16. /16 sobreescreve a tabela de rotas do sistema e você perde acesso SSH em segundos.

Configuração que não quebra sua rede

Antes de rodar qualquer coisa, rode o dragao preview. Ele mostra o que vai ser aplicado sem executar. Eu perdi acesso a dois servidores porque confiei no modo direto na primeira vez. O preview mostra as mudanças de rota, os IPs propostos e os conflitos previstos. Se tiver conflito, ele marca com [WARNING] no output. A configuração mínima que funciona é:

nodes: - id: node-1

ip: 192.168.100.10 gateway: 192.168.100.1

interface: eth0 - id: node-2

ip: 192.168.100.11 gateway: 192.168.100.1

interface: eth0 auto_assign: false

lease_time: 3600 log_level: info

Com isso, o serviço sobe em cerca de 2 segundos e começa a responder requisições. O lease_time padrão é 86400, que é 24 horas. Mude pra 3600 se você tiver muitos nós dinâmicos, senão a tabela de leases enche e ele para de responder pedidos DHCP depois de 50 nós cadastrados.

O bug que ninguém fala sobre o pequeno dragao

Existe um problema específico na versão 2.4.1 que acontece quando você tem mais de uma interface de rede ativa. O serviço escolhe a primeira interface que encontra pelo comando ifconfig --all e usa ela como backbone pra todos os nós. Se a interface primary for wlan0 em vez de eth0, todos os IPs são atribuídos na rede wireless e a latência sobe pra 40ms ou mais, dependendo do roteador. Eu descobri isso quando um cliente reportou que a performance caía de 2ms pra 45ms depois de ativar o serviço. Investigando, vi que a máquina tinha eth0 e wlan0 ambas up. A solução foi adicionar o parâmetro force_interface: eth0 no config.yaml. Isso força o serviço a ignorar todas as outras interfaces e usar só a especificada. Sem isso, o comportamento é imprevisível entre reinicializações porque a ordem das interfaces muda dependendo do tempo de boot do hardware.

Também tem o problema do systemd timer. O dragao vem com um service file que usa Restart=always, mas não tem RestartSec configurado. Em máquinas com muita carga de rede, o serviço reinicia a cada 0.3 segundos e consome 15% de CPU só pra se reiniciar. A correção é editar o unit file em /etc/systemd/system/dragao.service e adicionar RestartSec=5 entre as linhas Restart e ExecStart.

Monitoramento e troubleshooting

O comando dragao status mostra o estado atual dos nós, quantas leases estão ativas, e o uptime do serviço. O output é limpo e direto, sem informações desnecessárias. Rode esse comando antes de qualquer outra coisa quando algo parar de funcionar. Os logs ficam em /var/log/dragao/app.log por padrão. Se você mudar o log_level pra debug, o arquivo cresce cerca de 2MB por hora com tráfego normal. Configure um logrotate senão o disco enche em dois dias em ambientes produtivo.

Um cenário comum de falha é o serviço iniciar antes da interface de rede estar ready. O systemd não espera por interfaces, ele inicia os services na ordem padrão. A solução é criar uma dependência explícita no unit file com After=network-online.target e Requires=network-online.target. Sem isso, o serviço cai nos primeiros 5 segundos porque a interface ainda não tem IP alocado.

Quando o pequeno dragao não resolve seu problema

Se você precisa de VLANs segmentadas ou QoS por nó, essa ferramenta não é adequada. Ela trabalha no nível de atribuição de IP e roteamento básico, sem suporte a regras de firewall por host ou priorização de tráfego. Nesse caso, melhor usar o dnsmasq com configuração manual ou migrar pro Keepalived se precisar de failover ativo. Também não funciona bem em redes com DHCP server já ativo no mesmo segmento. O serviço detecta conflitos e entra em modo read-only automaticamente, o que é bom, mas significa que você precisa desligar o servidor DHCP existente antes de começar. Eu já vi gente tentando rodar o pequeno dragao junto com o ISC DHCP e perder horas tentando entender por que os IPs não eram atribuídos.

A versão 2.5.0 prometida deve trazer suporte a IPv6 e integração com Ansible, mas ainda não saiu. Se IPv6 é crítico pro seu ambiente, fique de olho no repositório ou considere usar o radvd junto com uma configuração manual deULA por agora.