Ansible para redes: backup automático de Mikrotik e Huawei

Quase todo provedor descobre que não tem backup no pior momento: o roteador de borda reiniciou com a configuração de fábrica, o switch de agregação queimou, e a última cópia da configuração está num pendrive de dois anos atrás. Ansible para redes resolve isso com pouco código. Um servidor Linux entra por SSH em cada equipamento toda noite, salva a configuração num arquivo de texto e o Git guarda o histórico.

Em Ansible para redes, este é o primeiro playbook que vale a pena escrever, porque só lê. Nada é alterado nos equipamentos, então o risco é baixo e o ganho aparece na primeira vez que alguém pergunta o que mudou no roteador ontem. O roteiro abaixo cobre Mikrotik RouterOS v7 e Huawei VRP (switches e roteadores), foi montado em laboratório e usa só endereços de documentação.

Resposta rápida: Ansible para redes em seis passos

1. Crie um ambiente Python num servidor Linux e instale ansible-core e paramiko.
2. Instale as coleções ansible.netcommon, community.routeros e community.network com um requirements.yml.
3. Monte o inventário com um grupo por fabricante e o ansible_network_os certo para cada um.
4. Guarde as senhas com ansible-vault, nunca em texto puro.
5. Escreva o playbook: /export no Mikrotik e display current-configuration no Huawei, com a saída gravada num arquivo por equipamento.
6. Versione a pasta de backups com Git e agende o script no cron.

Por que Ansible para redes e não um script solto

Dá para fazer backup com um script em Python ou em shell, e muita gente faz. O script de backup da OLT Huawei MA5800 é um exemplo que funciona bem para um único tipo de equipamento. O problema aparece quando a rede cresce: cada fabricante tem um prompt, uma paginação e um jeito de mostrar a configuração, e o script vira uma coleção de casos especiais.

No Ansible, essa parte fica nas coleções. A conexão network_cli abre o SSH, reconhece o prompt de cada sistema, desliga a paginação e devolve a saída limpa. Você descreve o que quer num arquivo YAML, e o mesmo playbook roda em dois ou em duzentos equipamentos. O inventário vira a lista oficial de ativos da rede, o que por si só já ajuda bastante.

Ansible para redes não usa agente. Nada é instalado no roteador; ele só precisa de SSH e de um usuário. Se você já automatizou alguma coisa com Netmiko com Python na OLT Huawei, a ideia é parecida, só que com a parte repetitiva pronta.

Instalar o Ansible para redes no servidor de automação

O servidor de automação pode ser uma VM Debian ou Ubuntu pequena, com acesso SSH à rede de gerência. Instalar dentro de um venv separa as versões do Ansible das do sistema e facilita atualizar depois.

sudo apt install python3-venv git
sudo mkdir -p /opt/netbackup && sudo chown $USER /opt/netbackup
cd /opt/netbackup
python3 -m venv venv
. venv/bin/activate
pip install ansible-core paramiko

• python3-venv e git são as únicas dependências do sistema.
• A pasta /opt/netbackup vai ser o repositório Git com tudo: playbook, inventário e backups.
• ansible-core traz o motor e os módulos ansible.builtin. As coleções de rede vêm no passo seguinte.
• paramiko é a biblioteca SSH que a conexão network_cli usa por padrão, segundo o guia da coleção community.routeros.

Coleções: requirements.yml

Fixe as coleções num arquivo, para o servidor de amanhã ter exatamente o que o de hoje tem:

---
collections:
  - name: ansible.netcommon
  - name: community.routeros
  - name: community.network
    version: ">=5.0.0,<6.0.0"

ansible-galaxy collection install -r requirements.yml
ansible-galaxy collection list

A community.network merece um aviso. Ela foi retirada do pacote Ansible 12 e está marcada como sem manutenção, com remoção prevista na versão 6.0.0 da própria coleção. Ainda dá para instalar com ansible-galaxy, e por isso a versão está travada abaixo da 6. É ela que traz o plugin ce. Ele foi escrito para a linha CloudEngine, mas reconhece o prompt <nome> e [nome] de qualquer VRP. Teste num equipamento de cada modelo antes de colocar no cron e trate como solução de hoje.

ansible.cfg

[defaults]
inventory = inventario.yml
forks = 5

[persistent_connection]
command_timeout = 60

inventory evita repetir -i em todo comando. forks = 5 limita quantos equipamentos são lidos ao mesmo tempo. O command_timeout sobe de 30 para 60 segundos, porque o /export de um concentrador com muitas regras demora.

Inventário do Ansible para redes: grupos por fabricante

O inventário diz quem existe e como falar com cada um. Separe por fabricante, porque é nesse nível que mudam ansible_network_os e o comando de backup.

---
all:
  children:
    mikrotik:
      hosts:
        rb-borda-01:
          ansible_host: 192.0.2.11
        rb-concentrador-01:
          ansible_host: 192.0.2.12
      vars:
        ansible_connection: ansible.netcommon.network_cli
        ansible_network_os: community.routeros.routeros
        ansible_user: backup+cet512w
        ansible_password: "{{ vault_senha_mikrotik }}"
    huawei:
      hosts:
        sw-agregacao-01:
          ansible_host: 192.0.2.21
        ne-borda-01:
          ansible_host: 192.0.2.22
      vars:
        ansible_connection: ansible.netcommon.network_cli
        ansible_network_os: community.network.ce
        ansible_user: backup
        ansible_password: "{{ vault_senha_huawei }}"

• ansible_connection: ansible.netcommon.network_cli faz o Ansible tratar o equipamento como CLI de rede, sem tentar rodar Python do outro lado.
• ansible_network_os escolhe o plugin que entende o prompt e os erros de cada sistema.
• backup+cet512w não é o nome do usuário. O sufixo depois do + ajusta o terminal do RouterOS e evita quebra de linha antes de 512 caracteres, como recomenda o guia SSH da coleção. O usuário criado no Mikrotik se chama só backup.
• ansible_password aponta para uma variável do cofre, que entra no próximo passo.

Confira se o Ansible leu o arquivo como você imaginou:

ansible-inventory --graph

A saída desenha a árvore de grupos com os quatro hosts embaixo de mikrotik e huawei. Se um host aparecer fora do grupo, o problema é indentação no YAML.

Senhas do Ansible para redes com ansible-vault

Senha em texto puro dentro de um repositório Git fica lá para sempre, mesmo depois de apagada. O ansible-vault criptografa o arquivo de variáveis, e o Ansible abre na hora de rodar.

mkdir -p group_vars/mikrotik group_vars/huawei
ansible-vault create group_vars/mikrotik/vault.yml
ansible-vault create group_vars/huawei/vault.yml
ansible-vault view group_vars/huawei/vault.yml

O create pede a senha do cofre e abre o editor. Dentro de cada arquivo, uma linha só:

---
vault_senha_mikrotik: "troque-por-uma-senha-longa"

No grupo huawei, o nome da variável é vault_senha_huawei. O Ansible carrega sozinho tudo que está em group_vars/<grupo>/, então o inventário encontra as variáveis sem configuração extra. Com view você confere o conteúdo sem editar.

Usuário de leitura em cada equipamento

O backup não precisa de permissão de escrita. No Mikrotik, crie um usuário no grupo read, preso ao IP do servidor de automação:

/user add name=backup group=read address=192.0.2.10/32 password=TROQUE

O parâmetro address recusa login desse usuário vindo de qualquer outro endereço. Como no RouterOS v7 o /export já esconde senhas e chaves por padrão, o grupo de leitura basta e o arquivo salvo não carrega segredos. O guia de segurança do Mikrotik RouterOS v7 mostra como fechar o resto do acesso ao roteador.

No Huawei, crie um usuário local só para o backup, com SSH liberado e nível de privilégio suficiente para o display current-configuration, e restrinja as VTYs à rede de gerência. Os comandos básicos de usuário e VTY estão na lista de comandos para roteadores e switches Huawei.

O playbook de backup do Ansible para redes

Um arquivo, duas jogadas: uma para cada grupo de equipamentos do inventário de Ansible para redes. Salve como backup.yml na raiz do projeto.

---
- name: Backup dos Mikrotik
  hosts: mikrotik
  gather_facts: false
  vars:
    re_data: "(?m)^# .* by RouterOS .*$"
    pasta: "{{ playbook_dir }}/backups/mikrotik"
  tasks:
    - name: Exportar a configuração
      community.routeros.command:
        commands:
          - /export
      register: saida
      changed_when: false

    - name: Gravar o .rsc no repositório
      ansible.builtin.copy:
        content: "{{ saida.stdout[0] | regex_replace(re_data, '') }}\n"
        dest: "{{ pasta }}/{{ inventory_hostname }}.rsc"
        mode: "0640"
      delegate_to: localhost

- name: Backup dos Huawei
  hosts: huawei
  gather_facts: false
  vars:
    pasta: "{{ playbook_dir }}/backups/huawei"
  tasks:
    - name: Ler a configuração ativa
      ansible.netcommon.cli_command:
        command: display current-configuration
      register: saida

    - name: Gravar o .cfg no repositório
      ansible.builtin.copy:
        content: "{{ saida.stdout }}\n"
        dest: "{{ pasta }}/{{ inventory_hostname }}.cfg"
        mode: "0640"
      delegate_to: localhost

Linha a linha, o porquê de cada parte:

• gather_facts: false desliga a coleta de fatos, que em equipamento de rede só gasta tempo neste caso.
• community.routeros.command manda /export. Todo comando nesse módulo começa com barra, como diz a documentação.
• changed_when: false existe porque esse módulo sempre marca a tarefa como alterada. Sem isso, o relatório mostra mudança em todo Mikrotik, toda noite.
• regex_replace(re_data, '') apaga a linha de cabeçalho com data e hora que o RouterOS coloca no topo do export. Sem esse filtro, o Git registraria uma mudança por dia em cada roteador, mesmo sem nada ter mudado.
• ansible.builtin.copy com content grava a saída num arquivo. O delegate_to: localhost é o detalhe que mais confunde: a tarefa roda no servidor de automação, que é onde o arquivo deve ficar.
• mode: "0640" evita que qualquer usuário do servidor leia a configuração.
• Na jogada Huawei, ansible.netcommon.cli_command roda o comando pelo plugin ce, que já mandou screen-length 0 temporary ao abrir a sessão. A saída vem inteira, sem as pausas de paginação.

Primeira execução

Rode primeiro contra um único equipamento, com -v para ver o que acontece:

cd /opt/netbackup
mkdir -p backups/mikrotik backups/huawei
install -m 600 /dev/null ~/.vault-netbackup
nano ~/.vault-netbackup
ansible-playbook backup.yml --limit rb-borda-01 \
  --vault-password-file ~/.vault-netbackup -v

O arquivo ~/.vault-netbackup guarda a senha do cofre, a mesma usada no ansible-vault create, para execuções sem ninguém digitando, como no cron. O install -m 600 cria o arquivo já fechado para outros usuários, e o editor evita que a senha fique no histórico do shell. Se o host responder ok, abra backups/mikrotik/rb-borda-01.rsc e confira se a configuração está completa, do começo ao fim. Depois rode sem --limit.

Versionar os backups com Git

Arquivo salvo por cima toda noite é só a última foto. Com Git, cada noite vira um commit, e você ganha de graça o histórico, a diferença entre duas datas e a volta a qualquer versão.

cd /opt/netbackup
printf 'venv/\n' > .gitignore
git init -b main
git add .gitignore ansible.cfg requirements.yml inventario.yml
git add backup.yml group_vars backups
git commit -m "estrutura inicial e primeiro backup"

O .gitignore tira o venv do repositório. O cofre entra, porque está criptografado; o arquivo com a senha do cofre fica na pasta do usuário, fora do repositório. Para ter uma cópia fora do servidor, crie um repositório privado num Gitea ou GitLab interno e adicione com git remote add origin.

Script e agendamento no cron

#!/bin/sh
# /opt/netbackup/backup.sh
set -e
cd /opt/netbackup
. venv/bin/activate
ansible-playbook backup.yml --vault-password-file ~/.vault-netbackup \
  || echo "atenção: algum equipamento falhou, veja o log"
git add backups
git commit -q -m "backup $(date +%F_%H%M)" || echo "sem mudanças"

• set -e para o script em qualquer erro inesperado.
• O || echo depois do ansible-playbook é proposital. Se um roteador estiver fora do ar, o playbook termina com erro, mas os outros backups saíram e precisam ser commitados.
• O git commit falha quando nada mudou, e o segundo || echo evita que isso pareça erro no log.

chmod +x /opt/netbackup/backup.sh
crontab -e
30 3 * * * /opt/netbackup/backup.sh >> $HOME/netbackup.log 2>&1

A terceira linha vai dentro do editor do crontab -e: o backup roda às 3h30, horário com pouca mudança na rede, e a saída fica num log que você consulta quando algo der errado.

Consultar o histórico

git log --oneline -5 -- backups/mikrotik/rb-borda-01.rsc
git diff HEAD~1 -- backups/
git show HEAD~3:backups/huawei/ne-borda-01.cfg > ne-borda-01-antigo.cfg

O primeiro comando lista os dias em que a configuração daquele roteador mudou. O segundo mostra o que mudou desde o último backup. O terceiro recupera o arquivo do Huawei de três commits atrás, pronto para comparar ou restaurar. Uma diferença típica, em saída de exemplo:

--- a/backups/mikrotik/rb-borda-01.rsc
+++ b/backups/mikrotik/rb-borda-01.rsc
@@ -212,2 +212,3 @@
 /ip firewall address-list
 add address=203.0.113.0/24 list=gerencia
+add address=198.51.100.0/24 list=gerencia

Alguém incluiu uma rede na lista de gerência do firewall. Sem o Git, essa mudança só apareceria quando desse problema.

E a OLT Huawei?

A OLT MA5800 roda um sistema próprio, com enable, config e paginação diferente do VRP de roteador. O plugin ce manda screen-length 0 temporary ao conectar e trata o erro como falha de terminal, então não conte com ele na OLT. Para ela, mantenha o script de backup da OLT Huawei MA5800 ou use Netmiko com Python na OLT Huawei, e deixe o Ansible com os roteadores e switches.

Erros comuns de Ansible para redes no primeiro playbook

• Arquivo vazio ou cortado no Mikrotik. Faltou o sufixo +cet512w no usuário, ou o command_timeout venceu antes do fim do export. Aumente o tempo e rode de novo com -v.
• Nome do roteador com espaço ou acento. O guia da coleção pede identity só com letras, números e traço, com menos de 19 caracteres. Fora disso, o Ansible não reconhece o prompt.
• Login com senha recusado no Mikrotik. Se o usuário tem chave SSH cadastrada, o RouterOS moderno não aceita senha por SSH para ele. Use um usuário só para o backup.
• Commit todo dia sem mudança. Alguma linha com data entrou no arquivo. Descubra qual com git diff e filtre com regex_replace, como no cabeçalho do RouterOS.
• Arquivo gravado no lugar errado. Faltou delegate_to: localhost, e o Ansible tentou copiar para o próprio equipamento.
• Senha do cofre perdida. Sem ela, os arquivos do vault não abrem. Guarde no gerenciador de senhas da equipe.
• Huawei travado no login. Se o usuário de backup ainda tem a senha inicial, o VRP pergunta se quer trocá-la e a sessão fica parada até o command_timeout. Entre uma vez à mão, troque a senha e atualize o cofre.

Próximos passos no Ansible para redes depois do backup

Com inventário, cofre e Git funcionando, o resto do Ansible para redes fica mais fácil. Alguns caminhos naturais:

• Um playbook de auditoria que só lê e compara: versão de RouterOS, NTP configurado, serviços desligados.
• Avisar no chat da equipe quando o git diff da noite não estiver vazio.
• Rodar o mesmo repositório num GitLab com pipeline, onde cada mudança de configuração passa por revisão antes de ir para a rede.
• Só depois disso, playbooks que alteram configuração, sempre com --check e --limit num equipamento de teste primeiro.

Perguntas frequentes

Ansible para redes precisa de agente instalado no roteador?

Não. Para equipamentos de rede, o Ansible usa SSH com a conexão network_cli e roda tudo no servidor de automação. O roteador só precisa de um usuário e do SSH liberado para o IP do servidor.

Qual coleção usar para Mikrotik no Ansible?

A community.routeros, com ansible_network_os: community.routeros.routeros e o módulo community.routeros.command. Ela também tem módulos para a API do RouterOS, mas para backup por /export o SSH resolve.

O community.network ainda funciona com Huawei?

Para ler configuração, em geral sim: o plugin ce reconhece o prompt do VRP, mas foi feito para CloudEngine, então teste em cada modelo. A coleção saiu do pacote Ansible 12 e está sem manutenção. Instale à parte, trave a versão abaixo da 6.0.0 e reavalie a cada atualização do Ansible.

O /export do Mikrotik inclui as senhas?

No RouterOS v7, não. O export esconde dados sensíveis por padrão, e só os mostra com show-sensitive. Para o histórico em Git, o padrão é o mais seguro.

Por que gravar em Git e não só numa pasta com data no nome?

Pasta com data guarda cópias, mas não diz o que mudou. O Git guarda só as diferenças, mostra quando cada linha mudou e recupera qualquer versão com um comando.

Dá para usar Ansible com a OLT Huawei?

Com o plugin ce, não é recomendado, porque a OLT não aceita o comando de paginação que ele manda ao conectar. Para a OLT, use um script com Netmiko ou o script de backup próprio da OLT.

Conclusão

O backup é a porta de entrada do Ansible para redes porque não muda nada nos equipamentos e já devolve valor na primeira semana: configuração guardada fora do roteador, histórico de quem mudou o quê e um inventário que finalmente lista todos os ativos. Comece com dois ou três equipamentos, confira os arquivos com calma e só então coloque a rede inteira no cron.

Leitura recomendada: Orquestrando sua rede com Ansible e Gitlab, na wiki do Brasil Peering Forum (CC BY-NC 4.0), que leva a mesma ideia para pipeline com GitLab.