Kaique Mitsuo Silva Yamamoto
Arquitetura softwareInfra devops

Ansible — Automação de Infraestrutura

Guia técnico sobre Ansible 2.16+: arquitetura agentless, inventários, playbooks, módulos, roles, Galaxy, vault, collections, AWX/Automation Controller, CI/CD, testes com Molecule, casos de uso reais e comparativo com Terraform, Chef e Puppet.

Arquitetura do Ansible: control node e managed nodes

Ansible é uma ferramenta de automação agentless: não instala agentes persistentes nos servidores gerenciados.

Componentes principais:

  • Control node: máquina onde o Ansible é instalado, armazena playbooks, inventários, roles e collections; executa os comandos ansible/ansible-playbook e orquestra a automação.
  • Managed nodes: servidores/hosts gerenciados; em Linux/Unix, Ansible conecta via SSH; em Windows, via WinRM/PowerShell remoting.
  • Conexão e execução: o control node envia módulos (pequenos scripts Python ou comandos) para os managed nodes, executa remoto e remove ao final, garantindo que não haja daemon residente.

Pré‑requisitos típicos: Python 3 nos managed nodes Linux, acesso SSH com chave (sem senha) e um usuário com permissão de sudo quando necessário.

Inventários estáticos e dinâmicos

O inventário define quais hosts serão gerenciados:

  • Estático: arquivos INI ou YAML com grupos e variáveis, ex.: [webservers], [dbservers], [all:vars] com ansible_user, ansible_ssh_private_key_file, etc.
  • Dinâmico: scripts/plugins que consultam fontes externas (AWS, GCP, Azure, Kubernetes, CMDB, APIs customizadas) e retornam JSON no formato esperado pelo Ansible, permitindo descobrir hosts dinamicamente.

Boas práticas:

  • Usar grupos hierárquicos (ambiente, tipo, região) e variáveis por grupo/host.
  • Versionar inventários junto com o código (Git) e, em ambientes grandes, preferir inventário dinâmico de cloud/CMDB.

Playbooks YAML: tasks, handlers, variáveis, condicionais e loops

Playbooks descrevem o estado desejado de sistemas em YAML:

  • Play: mapeia um grupo de hosts a um conjunto de tasks.
  • Tasks: chamadas a módulos (ex.: apt, service, template); executadas na ordem declarada.
  • Handlers: tasks especiais acionadas via notify (ex.: restart de serviço) e executadas apenas uma vez no final do play se algo mudou.

Recursos de linguagem:

  • Variáveis: definidas em vars, vars_files, group_vars, host_vars e via linha de comando.
  • Conditionals: when para avaliar expressões (ex.: when: ansible_os_family == 'Debian').
  • Loops: loop, with_items, with_dict, etc., para iterar sobre listas/dicionários.

O design é declarativo e idempotente: tasks só aplicam mudanças quando necessário, reduzindo side effects em execuções repetidas.

Módulos principais

Ansible vem com centenas de módulos; alguns muito usados:

  • Gestão de pacotes: apt, yum, dnf, package (abstração genérica).
  • Arquivos: copy, template (Jinja2), file (permissões, donos, links), unarchive.
  • Serviços: service, systemd (iniciar/parar/enable).
  • Code & config: git (clonar repos), get_url, lineinfile, blockinfile.
  • Containers: docker_container, docker_image, docker_network, módulos para Podman, etc.

Esses módulos são idempotentes, descritos pela Red Hat como “resource models” do estado desejado; o Ansible verifica e só altera quando há divergência.

Roles, estrutura de projetos, Ansible Galaxy e Collections

Roles e layout padrão

Roles encapsulam automação reutilizável (tasks, handlers, templates, vars, defaults, files, meta):

  • Layout padrão: roles/<nome>/tasks/main.yml, handlers/main.yml, templates/, vars/, etc.
  • Projetos maduros organizam playbooks em roles e utilizam um diretório playbooks/ ou site.yml que inclui roles conforme ambiente.

Ansible Galaxy e Collections

  • Ansible Galaxy é o hub público de roles e collections compartilhadas pela comunidade e vendors (ex.: geerlingguy.*, community.general).
  • Collections agrupam módulos, plugins, roles e playbooks prontos sob um namespace (namespace.collection), permitindo distribuição versionada e tooling avançado (ex.: ansible-test).

Boas práticas: usar collections oficiais (ansible.posix, community.docker, kubernetes.core) e criar collections internas para consolidar automação da empresa.

Vault para secrets

Ansible Vault permite criptografar dados sensíveis (senhas, tokens, chaves) dentro de arquivos YAML:

  • Criptografia via ansible-vault encrypt/edit/view e uso de senha ou arquivo de senha.
  • Integração transparente em playbooks (vars criptografadas são descriptografadas em runtime).

Em pipelines CI/CD, a senha do vault é passada via environment/secrets, permitindo usar Git como único repositório de estado sem expor credenciais em texto puro.

AWX e Automation Controller (Ansible Automation Platform)

AWX (upstream)

  • Ansible AWX é a interface web open source, REST API e task engine para gerenciar Ansible de forma centralizada: inventários, credenciais, projects (Git), job templates, RBAC, schedules e logs.
  • Funciona como um “control tower” para automação em times, oferecendo RBAC, auditoria, workflows de jobs e notificações (Slack, e‑mail, etc.).

AWX é o projeto upstream; recomendado para lab/dev ou pequenos ambientes; produção enterprise tipicamente usa a versão suportada da Red Hat.

Automation Controller (ex‑Tower) / Ansible Automation Platform

  • Automation Controller é o componente enterprise (ex‑Ansible Tower) da Red Hat Ansible Automation Platform, com suporte, recursos avançados de RBAC, automation mesh, SSO, compliance e integrações corporativas.
  • A documentação do AWX/Controller CLI mostra como automatizar organizações, usuários, teams, inventories e job templates via awx CLI, que mapeia diretamente para a API HTTP.

Integração com CI/CD (GitHub Actions, Jenkins, etc.)

Automação de Ansible em CI/CD:

  • GitHub Actions: usar runners Linux com Python/Ansible instalados ou actions prontas; steps para ansible-lint, ansible-playbook ou molecule test.
  • Jenkins/GitLab CI/Azure DevOps: pipelines configuram ambiente (Python + Ansible), checkout de repo e execução de playbooks/roles; integração com AWX/Controller para disparar jobs via API/CLI.
  • Caminho recomendado:
    • PR → ansible-lint + molecule test para roles.
    • Merge em main → rodar playbook de staging; aprovação manual → produção.

Idempotência e boas práticas

Pilares de qualidade em Ansible, segundo Red Hat e melhores práticas da comunidade:

  • Escrever tasks idempotentes (sem command/shell desnecessários; preferir módulos específicos).
  • Evitar lógica complexa em templates; manter regras de negócio no código (vars, roles).
  • Usar check_mode e --diff para validar mudanças sem aplicá‑las.
  • Versionar tudo em Git, com revisões de código para playbooks/roles.
  • Separar variáveis por ambiente e evitar duplicação (usar group_vars/host_vars e defaults de roles).

Testes com Molecule

Molecule é o framework padrão para testar roles/collections Ansible:

  • Permite criar ambientes efêmeros (Docker, Vagrant, EC2) para testar roles de ponta‑a‑ponta.
  • Suporta múltiplos cenários (pastas com configurações diferentes), testando diversas distros, versões de Ansible e configurações de role.
  • Integra com CI (GitHub Actions, Jenkins, GitLab CI) para rodar molecule test a cada push/PR, garantindo qualidade contínua.

Fluxo típico:

  1. molecule init role para criar esqueleto de role com cenários default.
  2. Escrever playbook de convergência e testes (Testinfra/pytest ou ansible-test).
  3. Rodar molecule test (create → converge → verify → destroy).

Casos de uso reais

Exemplos comuns de uso de Ansible 2.16+:

  • Provisionamento de servidores: instalar pacotes base, hardening, usuários, SSH, firewall, logging, agentes (Zabbix, Datadog, etc.).
  • Deploy de aplicações: clonar repositórios (git), construir assets, configurar serviços (systemd), aplicar migrations, reconfigurar load balancers.
  • Configuração de Kubernetes:
    • Preparar nodes (OS tuning, container runtime, kubeadm/kubespray).
    • Gerenciar add‑ons (Ingress, CNI, storage, monitoring) via modules/collections (ex.: kubernetes.core).
  • Network automation: configurar switches/routers/firewalls via SSH/Netconf/API com collections específicas.

Comparativo com Terraform, Chef e Puppet

Ansible vs Terraform

  • Ansible:

    • Focado em configuração e orquestração (provisionar pacotes, serviços, arquivos, deployments).
    • Imperativo/declarativo misto; playbooks podem expressar fluxos e orquestrações complexas.

  • Terraform:

    • Focado em provisionamento de infraestrutura como código (cloud resources, redes, VMs) com estado remoto/backends.
    • Declarativo e baseado em grafo (HCL), com plano (terraform plan) e apply, excelente para recursos de cloud.

Na prática, muitas equipes usam Terraform para infra base (VPC, clusters, bancos) e Ansible para configuração dos hosts e aplicações.

Ansible vs Chef e Puppet

  • Chef/Puppet:

    • Tradicionalmente agent‑based, com servidores mestre/orquestradores que enviam configs para agentes residentes.
    • Linguagens próprias (Chef DSL/Ruby, Puppet DSL) e enfoques em convergência contínua.

  • Ansible:

    • Agentless (SSH/WinRM); configuração é “push” a partir do control node.
    • Usa YAML + Jinja2, mais fácil de adotar por times com menos background em Ruby/DSLs.

Em 2025, Ansible é frequentemente escolhido por sua curva de aprendizado menor, comunidade ampla, integração com Red Hat Automation Platform e tooling de teste (Molecule, ansible‑test), enquanto Chef/Puppet permanecem fortes em ambientes que já os adotaram há muitos anos.

Fontes e leituras recomendadas

Arquitetura, funcionamento e nós de controle:

AWX / Automation Controller:

Testes com Molecule:

Esses recursos servem como base para aprofundar em Ansible 2.16+, AWX/Automation Platform, práticas de projeto de roles e testes automatizados.

Infraestrutura & DevOps

Cloud, containers, CI/CD, observabilidade e DevOps.

Microsoft Azure — Cloud Computing

Guia técnico sobre Microsoft Azure: principais serviços, arquitetura de soluções (Well-Architected), identidade e IAM, DevOps, observabilidade, redes, IaC com Bicep/Terraform, AKS, certificações e comparação com AWS/GCP.

On this page

Arquitetura do Ansible: control node e managed nodesInventários estáticos e dinâmicosPlaybooks YAML: tasks, handlers, variáveis, condicionais e loopsMódulos principaisRoles, estrutura de projetos, Ansible Galaxy e CollectionsRoles e layout padrãoAnsible Galaxy e CollectionsVault para secretsAWX e Automation Controller (Ansible Automation Platform)AWX (upstream)Automation Controller (ex‑Tower) / Ansible Automation PlatformIntegração com CI/CD (GitHub Actions, Jenkins, etc.)Idempotência e boas práticasTestes com MoleculeCasos de uso reaisComparativo com Terraform, Chef e PuppetAnsible vs TerraformAnsible vs Chef e PuppetFontes e leituras recomendadas