Rede como código: guia prático para provedores

O que é rede como código

É tratar a configuração da rede como se trata o código de um sistema: escrita em arquivos, guardada com histórico e alterada por um fluxo com revisão. O equipamento recebe o que está no repositório, e não o contrário.

Na rede tradicional, a configuração vive em cada equipamento e muda quando alguém digita comandos. Com o tempo, ninguém sabe ao certo o que mudou, quando, por quem e por quê, e dois switches iguais acabam configurados de jeitos diferentes.

Com rede como código, a verdade fica num repositório e os equipamentos recebem o que está lá. É o caminho que a automação de rede para provedores segue nos projetos maiores, depois que as rotinas de backup e de conferência já estão rodando.

Rede como código e automação são a mesma coisa?

Não exatamente. A automação é fazer uma rotina executar uma tarefa no lugar da pessoa, enquanto a rede como código é ter a configuração inteira descrita em arquivos, que passam a ser a referência oficial.

Dá para automatizar sem rede como código, por exemplo com um script que cria VLAN direto no switch. O contrário não funciona: a rede como código depende de automação para levar os arquivos até os equipamentos.

Como funciona a rede como código?

Os dados ficam na fonte da verdade, os modelos geram a configuração, a mudança passa por revisão e simulação e só então é aplicada. Depois, uma conferência periódica compara o repositório com o que está nos equipamentos.

NetBox ou planilha como fonte da verdade?

A planilha serve para começar, desde que seja uma só e tenha dono. O NetBox passa a valer a pena quando o inventário cresce e outras ferramentas precisam consultar os dados por API.

O mesmo inventário pode alimentar o monitoramento de rede: com uma rotina de integração, equipamento cadastrado entra também na coleta, sem ninguém lembrar de incluí-lo à mão.

Exemplo de modelo e aplicação com Ansible

O exemplo gera a configuração de VLANs de um switch a partir de uma lista e aplica com Ansible. Com simular verdadeiro, o Ansible mostra o que mudaria sem aplicar nada.

Os dados ficam separados do modelo. A lista de VLANs de cada switch fica num arquivo de variáveis, que pode vir da fonte da verdade ou ser mantido no próprio repositório.

# host_vars/sw-pop-centro.yml
vlans:
  - id: 110
    nome: CLIENTE-EMPRESA-A
  - id: 120
    nome: CLIENTE-EMPRESA-B

# modelos/vlans.j2
{% for vlan in vlans %}
vlan {{ vlan.id }}
 name {{ vlan.nome }}
{% endfor %}

# tarefas/vlans.yml
- name: Gerar configuração de VLANs
  ansible.builtin.template:
    src: modelos/vlans.j2
    dest: "gerado/{{ inventory_hostname }}-vlans.cfg"

- name: Aplicar no switch
  cisco.ios.ios_config:
    src: "gerado/{{ inventory_hostname }}-vlans.cfg"
  check_mode: "{{ simular | default(true) }}"

O padrão do exemplo é simular. Para aplicar de verdade, é preciso passar simular como falso na execução, o que evita que alguém altere a rede por engano ao rodar a tarefa para testar.

Como ler a tarefa do exemplo

São duas tarefas em sequência, e cada uma tem um papel separado. A primeira só escreve um arquivo no servidor; a segunda é a única que fala com o switch.

• Módulo template: junta o modelo com a lista de VLANs e grava o resultado na pasta gerado, um arquivo por switch.
• Variável inventory_hostname: usa o nome de cada equipamento do inventário para dar nome ao arquivo.
• Módulo ios_config: envia o arquivo gerado para o switch Cisco IOS e aplica só as linhas que faltam.
• Opção check_mode: quando ligada, o Ansible relata o que mudaria e não toca na configuração.

O arquivo gerado fica salvo e pode entrar no repositório. Assim, a revisão olha exatamente o texto que vai chegar ao equipamento.

Rede como código passo a passo

O caminho começa só lendo a rede e termina com mudanças revisadas e aplicadas por ferramenta. Cada passo já entrega valor sozinho, mesmo que o seguinte demore.

1. Guarde o backup em Git: uma rotina copia a configuração de cada equipamento todo dia e registra as diferenças.
2. Escolha uma tarefa repetitiva: VLANs de clientes corporativos, filtros ou usuários de gerência.
3. Monte a fonte da verdade: os dados dessa tarefa ficam num lugar só, com alguém responsável.
4. Escreva o modelo: o modelo Jinja2 gera a mesma configuração que a equipe faria à mão.
5. Compare com a rede: a configuração gerada precisa bater com a dos equipamentos antes de qualquer aplicação.
6. Ligue a revisão: toda mudança entra por pedido no repositório e é aprovada por outra pessoa.
7. Aplique com simulação: rode em modo de simulação, confira a diferença e só então aplique.
8. Amplie aos poucos: depois que a primeira tarefa estabiliza, traga a próxima parte da configuração.

Rede como código exige disciplina mais do que ferramenta. O passo que mais falha é o da revisão, porque na pressa alguém volta a mexer direto no equipamento e esquece de atualizar o repositório.

A Táquion Tech implanta a fonte da verdade, os modelos e o fluxo de revisão começando pelas rotinas que só leem a rede, e só depois libera as que escrevem.

Conferência de diferenças no dia a dia

A conferência periódica é o que mantém o repositório confiável. Ela compara a configuração gerada com a que está rodando e lista o que divergiu.

• Rotina agendada: a mesma tarefa de aplicação roda em modo de simulação, todo dia, em todos os equipamentos.
• Relatório curto: só os equipamentos com diferença aparecem, com as linhas que entrariam e sairiam.
• Decisão registrada: cada diferença vira atualização no repositório ou correção no equipamento.

O que muda na operação do provedor

Recuperar um equipamento perdido vira gerar e aplicar de novo, e auditar uma mudança vira consultar o histórico. O conhecimento sai da cabeça das pessoas e vai para arquivos que todos leem.

Compare com o caso de recuperar configuração de MikroTik sem backup, em que a equipe precisa reconstruir a configuração de memória. Com o repositório, o equipamento novo recebe a mesma configuração do antigo em minutos.

• Para o NOC: o histórico mostra o que mudou pouco antes de cada falha, o que acelera o diagnóstico.
• Para quem aprova: a revisão acontece sobre a diferença exata, e não sobre a descrição da mudança.
• Para o dono: a rede deixa de depender de um técnico que sabe tudo de cabeça.

No NOC, o registro de cada aplicação no repositório funciona como registro de mudança, e conversa com o fluxo descrito na implantação de ITIL na operação. A base estruturada também ajuda a inteligência artificial na operação de rede, que lê arquivos organizados com mais precisão do que anotações soltas.

Erros comuns na rede como código

Os erros mais comuns fazem o repositório e a rede divergirem até ninguém confiar no repositório. Quase todos aparecem nos primeiros meses e têm correção simples.

Senhas e chaves fora do repositório

Senha em arquivo versionado fica no histórico mesmo depois de apagada. Por isso as credenciais vão para um cofre, e o repositório guarda só a referência a elas.

• Ansible Vault: criptografa variáveis sensíveis dentro do próprio projeto.
• Cofre de senhas: um serviço separado entrega as credenciais na hora da execução.
• Acesso de emergência: documentado, guardado fora do repositório e com troca de senha depois do uso.

Checklist de validação do repositório

Confira com frequência se o repositório ainda reflete a rede real. Se não reflete, ele deixa de ser fonte da verdade e vira só mais um backup.

Mudanças revisadas e com caminho de volta também protegem o SLA dos clientes corporativos, porque a queda causada por erro de digitação passa a ser barrada antes de chegar ao equipamento.

Perguntas frequentes sobre rede como código

Thiago Manoel

Responsável técnico da Táquion Tech · Registro profissional [PREENCHER]

Mais de 15 anos em operações de rede, com gestão de infraestruturas de TI, administração de data centers e condução de equipes em migrações de TI e telecomunicações, com foco em alta disponibilidade e segurança.

A Táquion Tech é uma empresa de engenharia de redes de Balneário Camboriú (SC) que projeta, opera e dá suporte a redes de provedores de internet e de empresas.

Conheça a equipe da Táquion Tech