Ansible se destaca entre as ferramentas de automação de infraestrutura por um motivo simples: não precisa de agente. Conecta-se via SSH, usa YAML para definir o estado desejado, e executa playbooks idempotentes que configuram servidores, instalam software e deployam aplicações. Se Terraform é para provisionar infraestrutura, Ansible é para configurar e gerenciar o que roda dentro dela.
Conceitos fundamentais
Ansible opera com três conceitos: inventário (quais servidores), playbook (o que fazer), e roles (pacotes reutilizáveis de tarefas). O inventário lista seus servidores por grupo — [webservers], [databases], [staging], [production]. Playbooks são arquivos YAML que declaram o estado desejado: “o Nginx deve estar instalado e configurado com este template”. Tasks dentro do playbook usam módulos (apt, yum, copy, template, service) para executar ações específicas.
Idempotência é o princípio central: rodar o mesmo playbook 10 vezes tem o mesmo resultado que rodar uma vez. Se o Nginx já está instalado, o módulo apt não faz nada — reporta “ok” em vez de “changed”. Isso significa que você pode rodar playbooks regularmente sem medo de efeitos colaterais. O estado real do servidor converge para o estado declarado no playbook, automaticamente.
Playbooks para deploy de aplicação
Um playbook de deploy típico para uma aplicação web inclui: verificar se o código mais recente está no servidor (módulo git), instalar dependências (pip, npm), rodar migrations de banco de dados, copiar configurações com templates Jinja2 (que substituem variáveis por ambiente), reiniciar o serviço da aplicação, e verificar que a aplicação está respondendo (módulo uri para health check).
Variáveis por ambiente mantêm o playbook genérico. Um grupo_vars/production.yml define a URL do banco de produção, domínio, e settings específicos. O mesmo playbook roda contra staging ou production, trocando apenas o inventário. Templates Jinja2 geram arquivos de configuração com as variáveis corretas — um único nginx.conf.j2 serve todos os ambientes, interpolando server_name, upstream, e SSL paths automaticamente.
Roles: reutilização organizada
Roles empacotam tarefas, handlers, templates, e variáveis em unidades reutilizáveis. Uma role “nginx” pode ser compartilhada entre projetos: instala o Nginx, configura virtual hosts via template, habilita SSL com certbot, e configura logrotate. Uma role “postgresql” instala, configura, cria banco e usuário. O playbook principal apenas aplica roles aos grupos de servidores corretos — 5 linhas de YAML configuram uma infraestrutura completa.
Ansible Galaxy é o repositório público de roles — milhares de roles da comunidade para instalar Docker, configurar firewalls, setup de monitoring, e integração com cloud providers. Use roles da Galaxy como ponto de partida e customize para suas necessidades. Para projetos internos, crie um Galaxy privado ou use git submodules para compartilhar roles entre equipes.
Segurança com Ansible Vault
Ansible Vault criptografa arquivos de variáveis sensíveis — senhas de banco, API keys, certificados SSL. O arquivo vault.yml é criptografado com AES-256 e pode ser versionado no git com segurança. Ao rodar o playbook, Ansible pede a vault password (ou lê de arquivo/script) e descriptografa automaticamente. Nunca mais senhas em texto plano no repositório, e o ciclo de rotação de credenciais se torna um simples edit no vault e re-run do playbook.
Para pipelines automatizados, a vault password pode vir de variável de ambiente no CI/CD ou de um secrets manager como HashiCorp Vault. Combine com ansible-lint para validar playbooks antes da execução, molecule para testar roles em containers Docker, e AWX/Ansible Tower para interface web com controle de acesso, agendamento e auditoria de execuções em equipes grandes.
Tem um projeto em mente?
Somos especialistas em transformar ideias em produtos digitais. Apps, sites, automações e IA — vamos construir juntos.
