Automação de redes com Ansible e NetBox: do cadastro à configuração

Automatizar a configuração da rede costuma começar com um script que resolve um problema e termina com dezenas de scripts que ninguém sabe exatamente o que fazem. O que muda o jogo é separar o que a rede deve ser (os dados) de como aplicar (a automação).

Neste tutorial você vai ver como o NetBox e o Ansible trabalham juntos nesse modelo: o NetBox como fonte da verdade, o Ansible gerando e aplicando a configuração, e os cuidados que fazem a diferença entre um playbook que funciona no laboratório e uma automação em que a equipe confia em produção.

O modelo: intenção, geração e aplicação

1. Intenção: o NetBox guarda como a rede deve estar: equipamentos, interfaces, IPs, VLANs, sites e dados como servidores NTP e de syslog (veja o tutorial sobre recursos e vantagens do NetBox).
2. Geração: o Ansible lê esses dados e gera a configuração de cada equipamento a partir de templates.
3. Aplicação: o Ansible compara com a configuração atual, mostra a diferença e aplica.

A regra que sustenta o modelo: ninguém altera o equipamento direto. Muda o cadastro, roda a automação. Quando isso é seguido, a documentação nunca fica desatualizada, porque ela é a origem da configuração.

Inventário dinâmico a partir do NetBox

A coleção netbox.netbox do Ansible traz um plugin de inventário que monta a lista de equipamentos e os grupos direto do NetBox, sem manter arquivos de inventário à mão:

# netbox.yml
plugin: netbox.netbox.nb_inventory
api_endpoint: https://netbox.exemplo.net.br
token: "{{ lookup('env', 'NETBOX_TOKEN') }}"
config_context: true
group_by:
  - sites
  - platforms
  - tags
query_filters:
  - status: active

# Grupos e equipamentos montados a partir do NetBox
ansible-inventory -i netbox.yml --graph

Com os grupos por site e por plataforma, um playbook pode mirar "todos os roteadores RouterOS do POP Campinas" sem que essa lista exista em lugar nenhum além do próprio NetBox. Um equipamento novo cadastrado como ativo entra na automação sozinho.

Dados por site, função e equipamento

Boa parte da configuração de um equipamento não é dele, e sim do lugar e do papel que ele ocupa: os servidores NTP do POP, os servidores de syslog da região, as comunidades SNMP da função. No NetBox, esses dados ficam nos contextos de configuração, em JSON, aplicados por região, site, função, plataforma ou tag:

{
  "ntp_servers": ["10.0.0.10", "10.0.0.11"],
  "syslog_server": "10.0.0.20",
  "dns_servers": ["10.0.0.53", "10.0.1.53"]
}

Com config_context: true no inventário, esses dados chegam ao Ansible como variáveis de cada equipamento, já combinados por ordem de prioridade. Trocar o servidor NTP de um POP inteiro vira uma alteração em um único contexto.

Templates Jinja2

A configuração de cada equipamento é gerada por templates Jinja2, que combinam a estrutura do fabricante com os dados do NetBox. Um trecho, para visualizar a ideia:

{# ntp.j2: RouterOS 7 #}
/system ntp client set enabled=yes
/system ntp client servers remove [find]
{% for servidor in ntp_servers %}
/system ntp client servers add address={{ servidor }}
{% endfor %}

O exemplo é propositalmente simples. Na prática, os templates de interfaces, VLANs, BGP e filtros são os que dão trabalho: precisam tratar o que existe no equipamento e não está no cadastro, a ordem em que os comandos podem ser aplicados e as diferenças entre versões do mesmo sistema.

Verificar antes de aplicar

O Ansible tem dois recursos que deveriam ser obrigatórios em qualquer automação de rede:

# Mostra o que mudaria, sem aplicar nada
ansible-playbook -i netbox.yml ntp.yml --check --diff --limit pop-campinas

• --check simula a execução sem alterar os equipamentos;
• --diff mostra exatamente o que seria alterado em cada um;
• --limit restringe a execução a um grupo, para aplicar primeiro em poucos equipamentos.

Atenção: nem todo módulo suporta o modo de verificação. Módulos que só enviam comandos não sabem o que vai mudar e, dependendo de como foram escritos, podem até aplicar a alteração mesmo em --check. Saber como cada módulo se comporta é parte do trabalho.

Cada fabricante, um desafio

Em provedores, é comum ter os três tipos na mesma rede, e o MikroTik, muito presente no Brasil, exige cuidado especial com a ordem dos comandos e com regras de firewall e filtros, em que a posição importa.

O que separa um playbook de uma automação confiável

• Dados confiáveis. Automação com cadastro errado espalha o erro por toda a rede, rápido. O NetBox precisa estar saneado antes de virar origem da configuração.
• Idempotência. Rodar o mesmo playbook duas vezes não pode alterar nada na segunda. Se altera, algo está errado.
• Escopo do que é gerenciado. Decidir quais partes da configuração a automação controla e o que fica manual, para ela não apagar o que não conhece.
• Segredos. Senhas e chaves fora do repositório, no Ansible Vault ou em um cofre de segredos.
• Laboratório e aplicação gradual. Testar em laboratório e aplicar em poucos equipamentos antes de liberar para a rede inteira.
• Rollback. Saber como voltar quando algo der errado, de preferência automaticamente.
• Histórico. Playbooks e templates em Git, e registro de cada execução: quem rodou, quando e o que mudou.

Do tutorial à produção

O inventário dinâmico e o primeiro template funcionam em um dia. Uma automação que configura a rede inteira de um provedor, com segurança, é o que fica fora deste tutorial:

• NetBox modelado e saneado. Dados confiáveis o suficiente para serem a origem da configuração, com processo para mantê-los assim.
• Templates por fabricante. Interfaces, VLANs, BGP, filtros e serviços para MikroTik, Huawei, Juniper, Cisco e o que mais existir na rede.
• Aplicação segura. Verificação, diferença, aplicação gradual, rollback e validação depois de cada alteração.
• Integrações. Filtros BGP do IRR, reverso DNS, monitoramento e provisionamento de clientes a partir do mesmo cadastro.
• Operação pela equipe. Interface de execução, permissões, histórico e documentação para o NOC usar sem depender de quem escreveu.

Perguntas frequentes

Por que usar o NetBox com o Ansible em vez de arquivos de inventário?

Arquivos de inventário e variáveis viram uma segunda fonte da verdade, que fica desatualizada em relação à documentação. Com o NetBox como inventário, o mesmo cadastro que a equipe consulta é o que a automação usa, e alterar a rede começa por alterar o cadastro.

O Ansible funciona com MikroTik e Huawei?

Sim. Existem coleções do Ansible para RouterOS, para equipamentos Huawei, Cisco, Juniper e outros. O nível de suporte varia: em alguns fabricantes há módulos que entendem a configuração e aplicam só a diferença; em outros, a automação envia comandos e precisa tratar sozinha a idempotência.

Preciso de AWX ou Ansible Automation Platform?

Não para começar: o Ansible roda pela linha de comando. Em equipes maiores, uma interface como o AWX ou o Semaphore ajuda a controlar quem executa o quê, guardar o histórico de execuções e agendar tarefas.

Ansible ou scripts em Python?

Os dois têm espaço. O Ansible é bom para aplicar configuração em muitos equipamentos com estrutura padronizada. Scripts em Python, com bibliotecas como pynetbox, Netmiko ou NAPALM, são melhores para lógica complexa, validações e integrações. Muitas automações combinam os dois.