Ansible (agentless, push, YAML) × Puppet (agente, pull, DSL, Facter)

A ideia que organiza o assunto

Configurar uma máquina à mão funciona. Configurar quinhentas, e garantir que continuem iguais seis meses depois, não. A gerência de configuração nasce daí: em vez de executar comandos em cada servidor, descreve-se em código o estado desejado — este pacote instalado, este serviço ativo, este arquivo com este conteúdo — e uma ferramenta se encarrega de fazer a realidade coincidir com a descrição.

Disso decorre a propriedade que sustenta o modelo: idempotência. Executar a mesma descrição uma vez ou dez produz o mesmo resultado, porque a ferramenta verifica antes de agir e só mexe no que está diferente. É o que permite rodar a automação todo dia, em cima de máquinas em estados variados, sem medo.

As ferramentas se distinguem por duas escolhas de arquitetura, e é aí que o tópico se decide: o que fica instalado na máquina gerida e quem inicia a conversa. O Ansible não instala nada e empurra a configuração a partir de um nó de controle; o Puppet instala um agente, que puxa periodicamente do servidor o que deve aplicar. Guarde esse par e a maioria dos itens se responde antes de terminar a frase.

Por que se usa (e o que custa)

A escolha entre os dois modelos é uma troca real, e a banca cobra os dois lados dela.

Sem agente, adota-se rápido: basta acesso por SSH (ou WinRM) e credencial, nada é instalado nos servidores, não há processo a monitorar nem versão de agente a manter compatível em centenas de máquinas. Paga-se em continuidade e escala — a configuração só é aplicada enquanto alguém executa o playbook a partir do nó de controle, e cada execução abre conexão com cada destino, o que cresce mal quando os destinos são milhares.

Com agente, paga-se antes: instalar e manter um processo em cada nó, com o servidor central que o atende. Em troca, ganha-se aplicação contínua — o agente volta sozinho, de tempos em tempos, e desfaz a alteração manual que alguém fez no servidor —, e o custo de coordenação passa a crescer devagar, porque é cada nó que puxa quando lhe convém.

Resumido para a prova: sem agente compra simplicidade; com agente compra continuidade.

Como funciona

Ansible. Roda em um nó de controle — a máquina onde a ferramenta está instalada e de onde partem as conexões. Os destinos são os nós gerenciados, listados em um inventário. A conexão usa o transporte nativo de cada sistema: SSH no Linux, WinRM no Windows. Para cada tarefa, o Ansible copia o módulo ao destino, executa e o remove; nada permanece lá depois. É o que se chama agentless.

A automação se escreve em YAML. Um playbook contém plays, cada play aponta para um conjunto de hosts (hosts: all) e traz uma lista de tasks, executadas na ordem em que estão escritas. Antes das tarefas, o Ansible coleta fatos sobre cada máquina (ansible_facts), que alimentam condicionais e agrupamentos — o módulo group_by, por exemplo, cria grupos dinâmicos em tempo de execução, como pôr cada host no grupo do nome da sua distribuição. Para uma ação avulsa, existe o comando ad hoc: ansible <padrão de hosts> -m <módulo> -a "<argumentos>", como em ansible all -m ping.

Puppet. Modelo oposto. Em cada nó gerido roda um agente, que periodicamente (por padrão, a cada trinta minutos) contata o servidor, envia os fatos da máquina e recebe um catálogo compilado a partir dos manifestos — escritos na linguagem própria do Puppet, declarando o estado de pacotes, serviços, arquivos e usuários. O agente aplica o catálogo localmente. A ordem de execução não vem da sequência do arquivo, e sim das dependências declaradas entre recursos.

PowerShell DSC. A resposta da Microsoft ao mesmo problema: a configuração desejada é escrita em código e aplicada pelo Local Configuration Manager de cada máquina. Ela aceita os dois modos de entrega — push, em que a configuração é empurrada para o nó, e pull, em que o nó a busca em um servidor. É o exemplo que mostra que push e pull são escolhas de arquitetura, não propriedade fixa de um produto.

Execução remota no Windows. Aparece com frequência ao lado do tópico. O Invoke-Command do PowerShell só age remotamente se receber o destino: -ComputerName, que abre a conexão, ou -Session, que reaproveita uma sessão persistente. Com apenas -ScriptBlock, o bloco roda na máquina local, ainda que exista sessão remota ativa.

O que decide os itens

Ansible × Puppet — o par central:

	Ansible	Puppet
agente no nó gerido	nenhum (agentless)	agente instalado e residente
direção	push: o nó de controle empurra	pull: o agente puxa o catálogo
quem inicia	o nó de controle	o nó gerido, periodicamente
transporte	SSH (Linux), WinRM (Windows)	canal próprio do agente, sobre TLS
linguagem	YAML (playbooks)	linguagem própria (manifestos)
ordem de execução	a das tarefas no playbook	a das dependências declaradas

Nó de controle × nó gerenciado — o nó de controle é um só e é de onde se dispara; os nós gerenciados são muitos e é para onde se empurra. O Ansible conecta-se a nós gerenciados, nunca a nós de controle.

Provisionar × configurar — Terraform e CloudFormation criam a máquina; Ansible, Puppet e Chef configuram o que existe dentro dela. Ferramentas de papéis diferentes se encadeiam na mesma esteira.

A etapa no ciclo DevOps — Ansible e Puppet são ferramentas de deploy, não de plan. O mapa que a banca embaralha: planejar, com quadros de tarefas; codificar, com Git; construir, com Maven e Jenkins; testar, com JUnit e Selenium; implantar, com Ansible, Puppet e Kubernetes; operar e monitorar, com Zabbix, Nagios e Prometheus.

Sintaxe que cai — ansible all -m ping (grupo all para todo o inventário, módulo com -m, argumentos com -a); no playbook, hosts: e tasks:, com o nome do módulo como chave da tarefa.

Como a CEBRASPE derruba você aqui

A medição está fechada. São 8 itens explicados: 4 Certos e 4 Errados — e o título nomeia três ferramentas das quais a amostra só cobra uma com regularidade. 5 dos 8 itens são de Ansible, 1 é de Puppet (e é Certo) e nenhum é de Chef; os dois restantes são de PowerShell — o DSC e um Invoke-Command que instala o papel Hyper-V —, e entram no tópico pelo enunciado do caderno, não pela matéria. O Chef está na seção anterior porque é edital, não porque tenha caído aqui.

Quatro itens errados não sustentam percentual nenhum. O que sustentam é que os quatro atacam pontos diferentes — arquitetura, direção da conexão, sintaxe e condição de execução —, e é assim que estão descritos abaixo.

A característica trocada entre as duas ferramentas. É a pegadinha assinatura do tópico: “O Ansible é uma solução de software que permite controlar um dispositivo, através de agentes nele instalados […] sendo que a comunicação entre o servidor e o dispositivo ocorre por meio dos referidos agentes.” A descrição é fiel — ao Puppet. O nome é do Ansible. Defesa: leia o modelo descrito, diga de quem ele é e só depois olhe o nome no sujeito.

A direção da conexão invertida. “Para a sua automatização no Windows, o Ansible se conecta a nós de controle” — conecta-se a nós gerenciados; o nó de controle é de onde ele sai. Repare que o resto do item costuma estar impecável, inclusive a parte sobre idempotência: a frase inteira é verdadeira menos o destino da conexão.

O comando com a opção ou o alvo alterados. “ansible full -x ping” traz duas trocas em três palavras: o grupo de todo o inventário é all, e o módulo se indica com -m. Como a linha continua plausível, é fácil aceitá-la. Decore o formato do comando ad hoc e compare palavra por palavra.

A condição externa que supriria um parâmetro ausente. “O comando Hyper-V a seguir será executado diretamente se a sessão remota do servidor remoto já estiver ativa”, com um Invoke-Command que só tem -ScriptBlock. Sessão ativa não é sinônimo de sessão usada: sem -Session ou -ComputerName, o bloco roda localmente. Sempre que o enunciado oferecer uma condição de ambiente, procure no comando escrito o que endereça a ação ao destino.

O tópico que não é o do título. Três dos oito itens não são de Ansible: são Puppet, DSC do PowerShell e um Invoke-Command de Hyper-V. O conhecimento cobrado, porém, é o mesmo par — push × pull, agente × sem agente, local × remoto —, e é assim que se deve lê-los.

E o aviso inverso: o item genérico sobre a ferramenta costuma estar certo. “A ferramenta puppet permite escrever e executar um conjunto de diretivas para gerenciar a configuração de um sistema, seja o operacional, seja uma aplicação” é uma descrição correta e foi gabarito C, e os outros três Certos fazem o mesmo: associam o Ansible à etapa de deploy, dão ao DSC os dois modos de entrega e leem um group_by de playbook. Quando não houver troca de arquitetura, de direção nem de sintaxe, não invente uma.

Erros clássicos

Ler agentless como “não precisa de nada no destino”. O Ansible não instala agente permanente, mas o nó gerenciado precisa de acesso por SSH e de Python para a maioria dos módulos — e, no Windows, de WinRM habilitado.

Achar que o Windows exige agente. Não exige: o transporte muda de SSH para WinRM, e o modelo continua sem agente.

Confundir idempotência com “executar uma vez só”. É poder reexecutar à vontade: a tarefa verifica o estado antes e só age se houver diferença.

Tratar push e pull como marcas de fábrica. Ansible empurra, Puppet puxa, o DSC faz os dois. Item que negue um dos modos ao DSC está errado.

Pôr o Ansible na etapa de planejamento. Ele automatiza instalação, configuração e publicação nas máquinas de destino — trabalho de entrega.