O que é Ansible? Arquitetura, casos de uso e como adotar

Autor: Pedro Tebaldi PM do KeepGreen

Publicado mar/2026Atualizado set/2026

Ansible é uma ferramenta open source de automação de TI. Com ela, você provisiona, configura e orquestra infraestruturas inteiras a partir de um único nó de controle. Além disso, o processo dispensa agentes instalados nos servidores gerenciados.

Em ambientes que crescem rapidamente, seja em cloud, híbrido ou on-premises, gerenciar configurações manualmente é uma receita para configuration drift e incidentes silenciosos.

Equipes de infraestrutura que ainda dependem de scripts shell isolados ou processos manuais de configuração acumulam inconsistências difíceis de rastrear. Como resultado, as métricas denunciam o problema: MTTR elevado, deploys frágeis e noites acordado investigando por que dois servidores “idênticos” se comportam de formas diferentes.

Neste artigo, você entende o que é Ansible e como sua arquitetura funciona na prática. Em seguida, percorre os principais casos de uso em ambientes corporativos. Por fim, vê como a ferramenta se posiciona numa estratégia de automação orientada à confiabilidade.

O que é Ansible?

Ansible é um mecanismo de automação open source desenvolvido originalmente por Michael DeHaan em 2012 e adquirido pela Red Hat em 2015. Sua proposta central é simples: descrever o estado desejado da infraestrutura em arquivos YAML legíveis por humanos. Dessa forma, o mesmo estado se aplica a qualquer quantidade de hosts.

Mais de uma década depois, o projeto segue ativo: o repositório oficial no GitHub marcava 70.533 stars em 1º de setembro de 2026.

A principal diferença em relação a ferramentas como Puppet e Chef é a arquitetura agentless. Por isso, o Ansible não exige a instalação de nenhum software adicional nos servidores gerenciados. A comunicação corre por SSH no Linux e por WinRM no Windows, com credenciais já existentes no ambiente.

Neste sentido, o Ansible reduz drasticamente a barreira de adoção. Em menos de 30 minutos, você instala a ferramenta no nó de controle e configura o inventário. Depois disso, os primeiros comandos já rodam em múltiplos servidores.

Arquitetura do Ansible: como ele funciona por dentro

A arquitetura do Ansible separa “onde executar” de “o que executar”. Entender essa divisão é o que permite sair de dois para duzentos hosts sem reescrever o playbook.

Control Node e Managed Nodes

O Control Node é a máquina onde o Ansible está instalado e a partir da qual toda a automação é orquestrada. Pode ser um servidor dedicado, uma estação de trabalho ou um agente de CI/CD. Portanto, não existe servidor central de estado: toda a lógica parte deste nó.

Os Managed Nodes são os alvos da automação: servidores físicos, VMs, instâncias cloud, dispositivos de rede ou containers. O Ansible conecta-se a eles por SSH, executa os módulos necessários e os remove após a conclusão. Nenhum processo persistente fica nos hosts gerenciados.

Testamos essa afirmação num laboratório em containers, em 1º de setembro de 2026. O nó de controle roda ansible-core 2.21.3 sobre Python 3.12.14. Os três alvos são Debian 12 com sshd, python3 e sudo, sem nenhum pacote do Ansible instalado.

# nenhum pacote do Ansible foi instalado nos tres alvos
$ ansible all -m ping
db1 | SUCCESS => {
    "ansible_facts": {
        "discovered_interpreter_python": "/usr/bin/python3.11"
    },
    "changed": false,
    "ping": "pong"
}
web1 | SUCCESS => {
    "ansible_facts": {
        "discovered_interpreter_python": "/usr/bin/python3.11"
    },
    "changed": false,
    "ping": "pong"
}
web2 | SUCCESS => {
    "ansible_facts": {
        "discovered_interpreter_python": "/usr/bin/python3.11"
    },
    "changed": false,
    "ping": "pong"
}

Duas informações saltam da saída. O campo discovered_interpreter_python mostra que o Ansible achou sozinho o Python 3.11 de cada alvo. Além disso, changed: false confirma que o módulo ping testa a conexão sem alterar o host.

Inventário, Playbooks e Modules

O Inventário é o arquivo (estático ou dinâmico) que lista todos os hosts gerenciados, seus grupos e variáveis. Por exemplo, um inventário dinâmico nasce direto das APIs de AWS, Azure e GCP.

Os Playbooks são arquivos YAML que descrevem sequências de tarefas a serem executadas nos hosts definidos. Cada tarefa invoca um Module, ou seja, uma unidade de código que executa uma ação específica. Assim, um módulo instala pacotes (apt, yum), outro gerencia serviços (systemd) e outro configura firewalls.

As Roles agrupam tarefas, variáveis, handlers e templates em estruturas reutilizáveis. Com elas, equipes versionam e compartilham automações entre projetos via Ansible Galaxy.

No laboratório, o inventário separa os três hosts em dois grupos e reúne ambos sob um grupo pai. Um único playbook, portanto, mira web, banco ou producao.

[web]
web1
web2

[banco]
db1

[producao:children]
web
banco

[producao:vars]
ansible_user=deploy
ansible_ssh_private_key_file=/root/.ssh/id_ed25519

Este playbook instala o nginx, publica um arquivo de status e garante o serviço no ar. Repare que cada tarefa declara o estado desejado em vez do comando a executar.

---
- name: Configuração base dos servidores web
  hosts: web
  become: true
  tasks:
    - name: Garante o nginx instalado
      ansible.builtin.apt:
        name: nginx
        state: present
        update_cache: true

    - name: Publica a página de status
      ansible.builtin.copy:
        content: "ok\n"
        dest: /var/www/html/status.html
        owner: www-data
        group: www-data
        mode: "0644"

    - name: Garante o nginx no ar
      ansible.builtin.service:
        name: nginx
        state: started

Idempotência: o que muda na segunda execução

No Ansible, idempotência é a propriedade que faz a segunda execução do mesmo playbook não repetir nada. Na primeira passagem, o laboratório instalou o nginx, gravou o arquivo de status e subiu o serviço nos dois servidores web.

# primeira execucao: o ambiente ainda nao esta no estado desejado
$ ansible-playbook site.yml
PLAY [Configuração base dos servidores web] ************************************

TASK [Gathering Facts] *********************************************************
ok: [web2]
ok: [web1]

TASK [Garante o nginx instalado] ***********************************************
changed: [web1]
changed: [web2]

TASK [Publica a página de status] **********************************************
changed: [web1]
changed: [web2]

TASK [Garante o nginx no ar] ***************************************************
changed: [web1]
changed: [web2]

PLAY RECAP *********************************************************************
web1                       : ok=4    changed=3    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0   
web2                       : ok=4    changed=3    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0   

Em seguida, rodamos o mesmo comando sem tocar no playbook. O Ansible conferiu cada tarefa, encontrou tudo no estado pedido e não alterou nenhum arquivo.

# segunda execucao, sem alterar uma linha do playbook
$ ansible-playbook site.yml
PLAY [Configuração base dos servidores web] ************************************

TASK [Gathering Facts] *********************************************************
ok: [web1]
ok: [web2]

TASK [Garante o nginx instalado] ***********************************************
ok: [web1]
ok: [web2]

TASK [Publica a página de status] **********************************************
ok: [web1]
ok: [web2]

TASK [Garante o nginx no ar] ***************************************************
ok: [web1]
ok: [web2]

PLAY RECAP *********************************************************************
web1                       : ok=4    changed=0    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0   
web2                       : ok=4    changed=0    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0   

Comparar changed=3 com changed=0 é o teste mais barato que existe para um playbook. Se a segunda passagem ainda acusa mudança, alguma tarefa saiu imperativa.

Onde a idempotência quebra: shell e command

Idempotência vem do módulo, não do Ansible em si. Os módulos shell e command executam texto arbitrário e não sabem comparar estado. Por isso marcam changed em toda passagem, mesmo quando o resultado já existe.

---
- name: Onde a idempotência quebra
  hosts: web1
  become: true
  tasks:
    - name: shell sem guarda, reporta changed em toda execução
      ansible.builtin.shell: echo "release-2026.09" > /opt/release.txt

    - name: command com creates, pula quando o arquivo já existe
      ansible.builtin.command: touch /opt/release.txt
      args:
        creates: /opt/release.txt

Ambas as tarefas acima gravam o mesmo arquivo, porém por caminhos diferentes. Veja o que a segunda execução reporta:

# segunda execucao: nada mudou no host desde a primeira
$ ansible-playbook armadilha-shell.yml
PLAY [Onde a idempotência quebra] **********************************************

TASK [Gathering Facts] *********************************************************
ok: [web1]

TASK [shell sem guarda, reporta changed em toda execução] **********************
changed: [web1]

TASK [command com creates, pula quando o arquivo já existe] ********************
ok: [web1]

PLAY RECAP *********************************************************************
web1                       : ok=3    changed=1    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0   

Nada mudou no host. Ainda assim, o shell acusa changed e polui o relatório de mudanças. Em contrapartida, o command ficou em ok, porque o parâmetro creates mandou checar o arquivo antes de rodar.

Na prática, todo shell dentro de um playbook pede uma guarda. Sem creates, removes ou changed_when, o relatório perde o sinal do que mudou de verdade. A documentação do módulo command descreve os dois primeiros.

Principais casos de uso do Ansible em ambientes de TI

O Ansible cobre um espectro amplo de necessidades operacionais. O mesmo playbook roda em servidores bare-metal, VMs e ambientes Kubernetes sem alteração estrutural.

Gerenciamento de configuração: manter todos os servidores de um grupo num estado idêntico e auditável. Logo, o configuration drift entre desenvolvimento, homologação e produção deixa de aparecer.

Provisionamento de infraestrutura: criar e configurar instâncias em provedores cloud (AWS EC2, Azure VMs, GCP Compute) com módulos nativos. Inclusive, o mesmo pipeline configura o sistema operacional e as aplicações.

Deploy de aplicações: orquestrar a implantação inteira, ou seja, parar serviços, atualizar código, aplicar migrações e reiniciar aplicações em ordem definida. Isso inclui rolling updates e rollback automatizado.

Automação de segurança: aplicar patches em múltiplos servidores simultaneamente, auditar configurações de conformidade (CIS Benchmarks, STIG) e revogar acessos de forma centralizada e rastreável.

Orquestração de workflows: coordenar sequências de ações entre sistemas heterogêneos, integrando com ferramentas de monitoramento de servidores, pipelines de CI/CD e plataformas de ITSM.

Ansible vs Terraform vs Puppet: quando usar cada um

A confusão entre ferramentas de automação é comum. Cada uma ocupa um espaço específico no ciclo de vida da infraestrutura. Por isso, na maioria dos ambientes maduros, as três convivem.

Compare as três pelas dimensões que decidem a escolha, em vez da lista de recursos de cada uma.

Essa última linha resolve a maior parte das dúvidas. Se o servidor já responde no inventário, o trabalho é de configuração. Se ele ainda não existe, o trabalho é de provisionamento.

Em ambientes cloud-native maduros, a receita mais comum é: Terraform para provisionar + Ansible para configurar. Cada ferramenta opera na sua camada, sem sobreposição.

Ansible, DevOps e SRE: automação como pilar de confiabilidade

Em uma estratégia de SRE, o Ansible ocupa um lugar estrutural. Ele elimina trabalho manual repetitivo (toil) e faz procedimentos operacionais críticos rodarem idênticos toda vez.

Runbooks manuais são fontes conhecidas de erro humano durante incidentes. Convertê-los em playbooks muda quem pode agir: um engenheiro júnior dispara a resposta com o mesmo resultado de um sênior. Como resultado, o MTTR cai.

Ademais, playbooks versionados em Git funcionam como documentação viva do ambiente. Toda mudança de configuração passa por revisão de código, gerando rastreabilidade e facilitando a análise de causa raiz em postmortems. Sob este prisma, o Ansible transforma operações reativas em práticas de engenharia auditáveis.

Versionar playbook em Git traz uma consequência imediata: a senha do banco não pode ficar em texto puro no repositório. O ansible-vault cifra o valor e mantém o arquivo legível para revisão.

# saida de: ansible-vault encrypt_string --stdin-name db_password
db_password: !vault |
          $ANSIBLE_VAULT;1.1;AES256
          64613363613166346537303036306632373464353364323265633636343966353635353638666130
          6332623863323761333265643565616339623436343831640a356438336633383535616565636362
          61656637323438376566336535376230656334333637646262346630373437346634393338626562
          3065373538363563660a633466343737626330366161643261326463356464633963383961303139
          66396433343561336230353832343638353736353863393834366231323862653461

Sem a senha do cofre, o playbook para antes de conectar no host. Por outro lado, com ela, a variável abre em memória e o valor não aparece na saída.

# sem a senha do cofre
$ ansible-playbook cofre.yml 2>&1 | grep -E "^fatal|^db1|msg\""
fatal: [db1]: FAILED! => {"msg": "Task failed: Finalization of task args for 'ansible.builtin.debug' failed: Error while resolving value for 'msg': Error rendering template: Attempt to use undecryptable variable: Attempting to decrypt but no vault secrets found."}
db1                        : ok=1    changed=0    unreachable=0    failed=1    skipped=0    rescued=0    ignored=0   

# com a senha do cofre
$ ansible-playbook cofre.yml --vault-password-file ~/.vault-pass 2>&1 | grep -E "^fatal|^db1|msg\""
    "msg": "senha lida: 20 caracteres"
db1                        : ok=2    changed=0    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0   

No laboratório, o playbook leu uma senha de 20 caracteres sem imprimi-la em nenhum momento. Portanto, o mesmo repositório guarda a automação junto da credencial cifrada. O guia de proteção de dados sensíveis detalha os modos de senha e os vault IDs.

A integração com ferramentas de observabilidade fecha o ciclo. Assim, o monitoramento detecta o desvio, o alerta dispara o playbook de remediação e o sistema volta ao estado esperado. Esse padrão, chamado de event-driven automation, está na base de arquiteturas de AIOps modernas.

Conclusão

O Ansible consolidou-se como uma das ferramentas de automação mais adotadas em ambientes DevOps e SRE pela combinação de simplicidade, flexibilidade e arquitetura agentless. Sua curva de aprendizado curta permite que equipes entreguem valor cedo. Ao mesmo tempo, o ecossistema de coleções sustenta operações em escala enterprise.

Contudo, o valor real do Ansible aparece quando ele deixa de ser ferramenta pontual. Ele passa a integrar um pipeline mais amplo: provisionamento com Terraform, observabilidade ativa e práticas de SRE. É nessa composição de camadas que a automação de infraestrutura atinge maturidade operacional.

Para estruturar uma estratégia de automação alinhada ao seu ambiente, fale com nossos especialistas. Dessa forma, você descobre como conectar as peças certas para operar com mais velocidade e menos risco.