Automação de Redes com Ansible, Puppet e Chef

O que é

Ferramentas de gerenciamento de configuração são soluções de software que permitem o controle centralizado de grandes quantidades de dispositivos de rede. Ansible, Puppet e Chef são as três principais ferramentas dessa categoria cobradas no exame CCNA 200-301 (tópico 6.6).

Essas ferramentas surgiram para resolver o problema que os administradores de sistemas enfrentavam ao gerenciar centenas ou milhares de máquinas virtuais. Com o tempo, passaram a ser amplamente utilizadas também no gerenciamento de dispositivos de rede — especialmente o Ansible, que se tornou o mais popular nesse contexto.

O conceito central que justifica o uso dessas ferramentas é o de Infrastructure as Code (IaC): a ideia de que a infraestrutura de rede deve ser descrita e gerenciada por meio de arquivos de código versionáveis, auditáveis e reutilizáveis, em vez de configurações manuais aplicadas dispositivo por dispositivo.

Como funciona

O problema: configuration drift

Em redes com muitos dispositivos, engenheiros frequentemente fazem alterações pontuais para resolver problemas, testar configurações ou aplicar correções de emergência. Com o tempo, essas mudanças acumulam e o dispositivo passa a ter uma configuração que diverge do padrão definido pela equipe — fenômeno chamado de configuration drift.

Sem automação, rastrear essas mudanças exige disciplina manual (salvar arquivos de config com timestamps, por exemplo), o que não escala bem em redes com centenas de dispositivos.

A solução: templates + variáveis

Todas as três ferramentas utilizam o mesmo princípio básico:

Template: arquivo com o modelo de configuração, onde valores específicos (hostname, IP, OSPF process ID etc.) são representados por variáveis
Variáveis: arquivo separado que fornece os valores específicos de cada dispositivo

Com um template único e um arquivo de variáveis por dispositivo, é possível gerar e aplicar configurações corretas para centenas de equipamentos de forma simultânea e padronizada.

Idempotência

As três ferramentas implementam o conceito de idempotência: aplicar a mesma configuração múltiplas vezes produz sempre o mesmo resultado final. Se um dispositivo já está configurado corretamente, a ferramenta não faz nenhuma alteração. Isso garante segurança nas operações automatizadas e permite executar verificações de conformidade sem risco de sobrescrever configurações corretas.

Ansible

Desenvolvido por: Red Hat
Linguagem: Python
Modelo: Push (o control node empurra as configurações para os dispositivos)
Comunicação: SSH (porta 22) — sem necessidade de agente nos dispositivos gerenciados
Agentless: sim — principal vantagem, pois qualquer dispositivo com SSH pode ser gerenciado

Arquivos principais:

Arquivo	Função	Formato
Playbook	Define as tarefas e a lógica de automação	YAML
Inventory	Lista os dispositivos gerenciados e seus grupos	INI ou YAML
Template	Modelo de configuração com variáveis	Jinja2
Variables	Valores das variáveis por dispositivo	YAML

Fluxo: Inventory + Templates + Variables → Playbook → SSH → dispositivos gerenciados

Puppet

Linguagem: Ruby
Modelo: Pull (os agentes nos dispositivos se conectam ao Puppet Master para buscar configurações)
Servidor: Puppet Master
Porta: TCP 8140 (HTTPS/REST API)
Agentless: não por padrão — requer o Puppet Agent instalado nos dispositivos. Pode operar sem agente via proxy externo que usa SSH

Arquivos principais:

Manifest: define o estado desejado de configuração de um dispositivo (linguagem proprietária baseada em Ruby)
Templates: auxiliam na geração dos manifests

Limitação para redes: nem todos os dispositivos Cisco suportam o Puppet Agent, o que reduz sua popularidade para gerenciamento de rede.

Chef

Linguagem: Ruby (DSL — Domain-Specific Language)
Modelo: Pull (Chef clients buscam configurações do Chef Server)
Servidor: Chef Server
Porta principal: TCP 10002
Agentless: não — requer Chef Agent instalado nos dispositivos

Arquivos principais:

Conceito	Analogia	Descrição
Resource	Ingrediente	Objeto de configuração gerenciado pelo Chef
Recipe	Receita	Lógica e ações a executar nos resources
Cookbook	Livro de receitas	Conjunto de recipes relacionadas
Run list	Lista de preparo	Ordem de execução das recipes

Fluxo: Workstation → Chef Server ← Chef Clients (pull)

Comparação das três ferramentas

Característica	Ansible	Puppet	Chef
Linguagem	Python	Ruby	Ruby
Agentless	Sim	Não (padrão)	Não
Modelo	Push	Pull	Pull
Comunicação	SSH (22)	TCP 8140	TCP 10002
Formato dos arquivos	YAML	Proprietário (Ruby-like)	DSL Ruby
Servidor	Control Node	Puppet Master	Chef Server
Popularidade em redes	Alta	Média	Baixa

Na prática

Exemplo de playbook Ansible para configurar um roteador Cisco

---
- name: Configurar roteadores WAN
  hosts: wan_routers
  gather_facts: no

  vars:
    snmp_community: "fsudo_ro"
    syslog_server: "192.168.1.100"

  tasks:
    - name: Configurar SNMP read-only
      ios_config:
        lines:
          - "snmp-server community {{ snmp_community }} RO"

    - name: Configurar Syslog
      ios_config:
        lines:
          - "logging host {{ syslog_server }}"
          - "logging trap informational"

    - name: Salvar configuração
      ios_config:
        save_when: always

Inventory correspondente (INI):

[wan_routers]
r1 ansible_host=10.0.0.1
r2 ansible_host=10.0.0.2
r3 ansible_host=10.0.0.3

[wan_routers:vars]
ansible_network_os=ios
ansible_connection=network_cli
ansible_user=admin

Ao executar este playbook, o Ansible se conecta via SSH a cada roteador listado no inventory e aplica as configurações de SNMP e Syslog definidas. Se o roteador já tiver essas configurações corretas (idempotência), nenhuma mudança é feita.

Usos comuns dessas ferramentas

Provisioning de novos dispositivos: gerar e aplicar configurações completas em equipamentos recém-instalados
Aplicação de mudanças em massa: alterar configurações de SNMP, AAA, NTP em toda a rede de uma vez
Verificação de conformidade: checar se todos os dispositivos seguem os padrões definidos e alertar sobre desvios
Comparação de versões de configuração: comparar a config atual com uma versão anterior ou com o padrão

Por que cai no exame

O tópico 6.6 do CCNA exige que o candidato reconheça as capacidades das ferramentas de gerenciamento de configuração. As questões focam em diferenciar as três ferramentas pelos seguintes critérios:

Qual é agentless? → Ansible
Qual usa push? → Ansible
Quais usam pull? → Puppet e Chef
Qual usa YAML? → Ansible
Qual porta o Puppet usa? → TCP 8140
Qual porta o Chef usa? → TCP 10002 (principal)
Qual é escrito em Python? → Ansible
Quais são escritos em Ruby? → Puppet e Chef
O que são playbooks? → Blueprints de automação do Ansible, escritos em YAML
O que são manifests? → Arquivos do Puppet que definem o estado desejado de configuração

Questões no estilo "selecione todas que se aplicam" sobre modelos push/pull e sobre qual ferramenta usa qual linguagem são recorrentes. A tabela comparativa é o principal material de estudo.

Resumo em uma linha

Ansible (agentless, push, YAML, SSH) é o mais popular para redes; Puppet (agented, pull, TCP 8140) e Chef (agented, pull, TCP 10002) requerem agentes instalados nos dispositivos e usam linguagem baseada em Ruby.