Se você administra servidores Linux, já deve ter sentido o peso de repetir a mesma configuração em dezenas de máquinas — ou, pior, de descobrir que uma delas ficou diferente das outras. É nesse cenário que a pergunta o que é Ansible aparece com frequência entre profissionais de infraestrutura, redes e cloud. Em vez de configurar cada host manualmente ou manter scripts Bash que quebram na segunda execução, o Ansible propõe uma abordagem declarativa: você descreve o estado desejado e a ferramenta aplica essa condição em todos os alvos a partir de um único ponto de controle.
Neste guia, a DEFTEC reúne o que você precisa saber para sair do zero e entender como a ferramenta se encaixa no dia a dia de quem trabalha com infraestrutura de TI. O texto percorre a arquitetura sem agente, o papel do inventário, a estrutura de módulos, tasks e roles, e chega a um playbook comentado linha a linha. Também trata de pontos que costumam ficar de fora das explicações introdutórias, como a idempotência na prática, os limites dos módulos shell e command e os critérios para decidir quando o Ansible é a escolha certa.
Se a ideia de tratar configuração como código ainda é nova para você, vale começar pelo conceito que sustenta tudo isso: infraestrutura como código. A partir dessa base, o restante do conteúdo faz mais sentido — e o caminho de aprendizado em redes, Linux e cloud da DEFTEC ajuda a consolidar a prática.
O que é Ansible, em uma frase que qualquer pessoa entende
Ansible é uma ferramenta de automação que permite configurar dezenas, centenas ou milhares de servidores ao mesmo tempo, executando tarefas idênticas em todos eles a partir de um único ponto de controle, sem precisar instalar nenhum programa especial nas máquinas gerenciadas. Na prática, você descreve em arquivos de texto o estado final desejado — por exemplo, "o Nginx deve estar instalado e rodando na porta 80" — e o Ansible se encarrega de aplicar essa condição em toda a sua infraestrutura.
O projeto nasceu em 2012, criado por Michael DeHaan, e foi adquirido pela Red Hat em 2015. Desde então, tornou-se uma das ferramentas centrais do movimento de infraestrutura como código (IaC), ao lado de nomes como Terraform e Puppet. Diferente de ferramentas que exigem um agente instalado em cada servidor, o Ansible opera por SSH — protocolo que praticamente todo servidor Linux já possui habilitado por padrão.
Para quem está começando em tecnologia, o apelo do Ansible está na curva de aprendizado relativamente baixa: os arquivos de automação são escritos em YAML, um formato legível por humanos, e a execução mostra exatamente o que mudou em cada máquina. Essa transparência reduz o medo de automatizar e permite que equipes pequenas administrem parques de servidores que antes exigiriam muito mais mão de obra manual.
Como o Ansible funciona: arquitetura sem agente explicada
A arquitetura do Ansible parte de um princípio simples: existe uma máquina que comanda e várias que obedecem. Não há servidor central permanente, não há banco de dados de estado, não há daemon rodando em background. Tudo acontece no momento da execução, o que reduz drasticamente a superfície de ataque e os requisitos de infraestrutura da própria ferramenta.
Control node, managed nodes e a conexão via SSH
O control node é a máquina onde o Ansible está instalado e de onde os comandos são disparados. Ele pode ser um notebook do administrador, um servidor dedicado ou até um container em uma esteira de CI/CD. Os managed nodes são os servidores, switches, roteadores e demais dispositivos que serão configurados — e eles não precisam de nenhum software do Ansible instalado.
A comunicação entre control node e managed nodes acontece por SSH em sistemas Linux, usando autenticação por chave criptográfica ou senha. O Ansible envia pequenos scripts em Python para o servidor de destino, executa a tarefa, coleta o resultado e remove os arquivos temporários. Em equipamentos de rede, o protocolo usado costuma ser o NETCONF ou APIs REST; em Windows, o WinRM cumpre papel análogo ao SSH. Para quem trabalha com infraestrutura de redes, essa capacidade de alcançar switches e roteadores sem agente é um diferencial importante.
Inventário: como o Ansible enxerga seus servidores
O inventário é o arquivo que lista os managed nodes e os organiza em grupos. Ele pode ser um simples arquivo INI ou YAML com endereços IP e nomes de host, ou pode ser dinâmico, consultando provedores de nuvem como AWS, Azure e GCP para descobrir automaticamente as máquinas existentes. Um inventário mínimo com três servidores web e dois bancos de dados ocupa menos de dez linhas.
- Grupos estáticos: definidos manualmente no arquivo de inventário
- Grupos dinâmicos: gerados por plugins que consultam APIs de nuvem
- Variáveis por host: usuário SSH, porta, caminho da chave privada
- Variáveis por grupo: configurações comuns a um conjunto de servidores
- Padrões de seleção: execute apenas em "webservers" ou "db[0:2]"
Essa organização em grupos é o que permite aplicar uma configuração apenas aos servidores de banco de dados, por exemplo, sem tocar nos servidores web. O inventário também armazena variáveis como o usuário de conexão e a porta SSH de cada host, centralizando informações que antes ficavam espalhadas em scripts soltos.
Módulos, tasks e roles: as peças de uma automação
Módulos são unidades de trabalho que executam uma ação específica: instalar um pacote, copiar um arquivo, criar um usuário, reiniciar um serviço. O Ansible possui centenas de módulos oficiais, cobrindo desde gerenciamento de pacotes (apt, yum, dnf) até serviços de nuvem (ec2, azure_rm, gcp_compute). Uma task é a invocação de um módulo com parâmetros concretos — por exemplo, "instale o pacote nginx na versão mais recente".
As roles são pacotes reutilizáveis que agrupam tasks, arquivos, templates e variáveis em uma estrutura padronizada de diretórios. Uma role chamada "nginx" pode conter tudo o que é necessário para instalar, configurar e iniciar o servidor web em qualquer ambiente. O Ansible Galaxy, repositório público da comunidade, hospeda milhares de roles prontas para uso, acelerando a adoção da ferramenta.
Playbooks e YAML: automação como código legível
Playbooks são arquivos YAML que descrevem a sequência de tasks a ser executada em um grupo de hosts. Eles são o coração do Ansible: é neles que a automação ganha forma de código versionável, revisável e testável. Um playbook pode ter um ou mais plays, e cada play define quais hosts serão alvo e quais tasks serão executadas neles.
Anatomia de um playbook que instala e configura o Nginx
O exemplo abaixo é um playbook completo, comentado linha a linha, que instala o Nginx em servidores Debian/Ubuntu e garante que o serviço esteja ativo. Ele ilustra os elementos essenciais de qualquer automação Ansible: alvo, privilégio, tasks e estado desejado.
---: marcador obrigatório de início de documento YAMLhosts: webservers: o play se aplica ao grupo "webservers" do inventáriobecome: yes: executa as tasks com privilégios de root via sudoapt: name=nginx state=present: garante que o pacote nginx esteja instaladoservice: name=nginx state=started enabled=yes: garante que o serviço esteja rodando e habilitado no bootcopy: src=index.html dest=/var/www/html/index.html: publica um arquivo local no servidor
Note que o playbook não diz "instale o Nginx" como um comando imperativo. Ele declara o estado desejado — state: present, state: started — e o módulo decide internamente quais comandos executar para chegar lá. Essa diferença sutil entre "faça isso" e "garanta que esteja assim" é o fundamento da idempotência.
Idempotência: por que rodar duas vezes não quebra nada
Idempotência é a propriedade que permite executar o mesmo playbook várias vezes e obter sempre o mesmo resultado final, sem efeitos colaterais acumulativos. Se o Nginx já está instalado, o módulo apt detecta essa condição, não executa nada e reporta ok em vez de changed. Se o serviço já está rodando, o módulo service não tenta iniciá-lo novamente.
Na prática, isso transforma a automação em algo seguro para rodar em horários agendados ou a cada deploy. Um playbook idempotente pode ser executado diariamente como rotina de conformidade: ele corrige qualquer desvio do estado desejado e não altera nada que já esteja correto. Essa característica é o que diferencia automação de verdade de scripts frágeis que quebram na segunda execução.
Quando a idempotência falha: os módulos shell e command
Os módulos shell e command executam comandos arbitrários no servidor de destino e são as principais fontes de quebra de idempotência. Como o Ansible não tem como saber o que um comando genérico faz, ele o executa sempre, em toda rodada, e reporta changed incondicionalmente. Um playbook com shell: useradd joao falhará na segunda execução, pois o usuário já existe — a menos que você adicione lógica condicional manual.
- Use módulos específicos (
user,file,lineinfile) sempre que existirem - Reserve
shellpara comandos sem módulo equivalente - Adicione
createsouremovespara dar pistas de idempotência ao módulocommand - Use
changed_when: falseem comandos de leitura, comocatoudf - Prefira
ansible.builtin.shellcomset -o pipefailpara capturar falhas em pipelines
O abuso de shell é um dos erros mais comuns de quem migra de scripts Bash para Ansible. A ferramenta oferece módulos para quase tudo — usuários, arquivos, serviços, cron, firewall — e usá-los preserva a idempotência e a legibilidade que justificam a adoção da ferramenta em primeiro lugar.
O que dá para automatizar com Ansible na prática
O escopo do Ansible vai muito além de instalar pacotes. Ele cobre praticamente todo o ciclo de vida de um servidor, desde o provisionamento inicial até o deploy de aplicações e a orquestração de containers.
Configuração de servidores e gestão de pacotes
O caso de uso mais clássico é o configuration management: garantir que todos os servidores de um parque tenham os mesmos pacotes, usuários, permissões, arquivos de configuração e serviços ativos. Um playbook pode padronizar a instalação de agentes de monitoramento, configurar o NTP, endurecer o SSH, aplicar políticas de senha e criar contas de serviço em centenas de hosts de uma só vez.
Além de instalar, o Ansible gerencia versões: é possível fixar uma versão específica de um pacote, fazer upgrade controlado ou remover software obsoleto. A gestão de configuração com Ansible é especialmente útil em ambientes que precisam atender normas de conformidade, pois o playbook funciona como documentação executável do estado aprovado de cada servidor.
Provisionamento em nuvem e ambientes híbridos
O Ansible possui módulos para provisionar recursos em AWS, Azure, Google Cloud, DigitalOcean, OpenStack e VMware. Com eles, você cria instâncias, discos, redes virtuais, balanceadores de carga e grupos de segurança diretamente do playbook. Isso permite um fluxo completo: provisionar a infraestrutura, configurar o sistema operacional e instalar a aplicação — tudo em uma única execução coordenada.
Em ambientes híbridos, onde parte da carga roda on-premises e parte na nuvem, o Ansible brilha por tratar todos os hosts da mesma forma. O mesmo playbook que configura um servidor físico no datacenter local pode configurar uma VM na AWS, desde que ambos estejam no inventário. Essa uniformidade elimina a necessidade de manter duas ferramentas e duas equipes com conhecimentos separados para cada ambiente.
Deploy de aplicações, Docker e Kubernetes
No deploy de aplicações, o Ansible orquestra a sequência completa: copiar o código novo, instalar dependências, rodar migrações de banco, reiniciar serviços e validar a saúde da aplicação. Estratégias de deploy como rolling update permitem atualizar servidores em lotes, garantindo que parte da frota continue atendendo tráfego enquanto o restante é atualizado.
Para Docker, módulos como docker_container e docker_compose gerenciam imagens, containers e redes. Para Kubernetes, o Ansible pode criar namespaces, aplicar manifests, gerenciar secrets e configurar operadores. Embora ferramentas dedicadas como Helm e Kustomize sejam mais adequadas para o dia a dia do cluster, o Ansible cumpre bem o papel de orquestrar o processo ao redor — preparar nodes, instalar o runtime, configurar o cluster e disparar os primeiros deploys. Quem precisa de uma rotina de limpeza em ambientes Docker, por exemplo, pode automatizar com Ansible o que faria manualmente com comandos como remover containers órfãos.
Ansible, Terraform, Puppet e Chef: qual usar em cada cenário
As quatro ferramentas ocupam espaços vizinhos no ecossistema de automação, mas com filosofias distintas. A escolha depende do problema que você precisa resolver, da equipe que vai operar e do ciclo de vida que deseja gerenciar. A tabela mental abaixo resume os critérios objetivos de decisão.
- Ansible: configuração e orquestração, sem agente, YAML, execução sob demanda
- Terraform: provisionamento de infraestrutura declarativa, com estado persistente e planejamento prévio
- Puppet: configuração contínua com agente, linguagem própria, modelo pull
- Chef: configuração com receitas em Ruby, agente, forte integração com testes
Se o objetivo é criar e destruir recursos de nuvem — VPCs, subnets, instâncias — o Terraform é a escolha natural, pois mantém um estado que permite planejar mudanças antes de aplicá-las. Se o objetivo é configurar o sistema operacional e as aplicações dentro de servidores já existentes, o Ansible tende a ser mais simples e direto. Na prática, muitas equipes usam os dois: Terraform provisiona a infraestrutura e chama o Ansible para configurar as máquinas recém-criadas.
Puppet e Chef exigem um agente instalado em cada nó e um servidor central que distribui as configurações. Esse modelo pull garante convergência contínua — se alguém alterar manualmente um arquivo, o agente corrige na próxima checagem — mas adiciona complexidade operacional. O Ansible, no modelo push, só age quando você executa o playbook. Para parques muito grandes com requisitos rígidos de conformidade contínua, Puppet ou Chef podem ser mais adequados; para a maioria dos cenários de DevOps, o Ansible vence pela simplicidade.
Ansible na esteira DevOps: do commit ao servidor configurado
No fluxo DevOps moderno, o Ansible costuma ocupar a etapa que conecta o código versionado ao ambiente de produção. Um pipeline típico começa com o desenvolvedor fazendo commit de uma alteração no repositório Git. O sistema de CI — Jenkins, GitLab CI, GitHub Actions — detecta a mudança, roda os testes e, se tudo passar, dispara o playbook Ansible contra os servidores de staging e depois produção.
Esse modelo, conhecido como GitOps quando o Git é a fonte única de verdade, garante que toda mudança em servidores passe por revisão de código, teste automatizado e rastreabilidade completa. Nada é alterado manualmente em produção; tudo passa pelo pipeline. Se um servidor apresentar comportamento inesperado, o histórico do Git mostra exatamente qual mudança de configuração foi aplicada e quem a aprovou.
O Ansible também se integra a ferramentas de orquestração de pipeline como Jenkins e a plataformas de gerenciamento como AWX, que adicionam interface web, agendamento e controle de acesso por cima do Ansible Core. Essa combinação permite que equipes inteiras compartilhem playbooks sem depender de um único especialista que os executa manualmente de seu notebook.
Como começar: instalação, primeiro inventário e primeiro playbook
O primeiro passo é instalar o Ansible no control node, que precisa ser um sistema Linux ou macOS — Windows só funciona como control node via WSL (Windows Subsystem for Linux). Em distribuições baseadas em Debian, o comando é apt install ansible; em RHEL/Fedora, dnf install ansible; e via pip, pip install ansible.
O segundo passo é criar o inventário. Um arquivo chamado hosts.ini com o conteúdo abaixo já é suficiente para começar: um grupo chamado test contendo um servidor acessível por SSH. O terceiro passo é escrever um playbook mínimo — por exemplo, instalar o pacote htop — e executá-lo com ansible-playbook -i hosts.ini primeiro.yml.
Erros comuns de quem está começando com Ansible
- Esquecer o
become: yese ver tasks de instalação falharem por falta de permissão - Usar
shellpara tudo, perdendo idempotência e legibilidade - Não configurar chave SSH, sofrendo com prompts de senha a cada execução
- Ignorar o
--check(dry run) e aplicar mudanças sem prever o efeito - Escrever playbooks gigantes no lugar de dividir a lógica em roles reutilizáveis
- Não versionar playbooks e inventário em Git, perdendo o histórico de mudanças
- Confundir YAML: espaços em vez de tabs, indentação inconsistente, dois-pontos sem espaço
O erro de sintaxe YAML é o mais frustrante para iniciantes, pois a mensagem de erro nem sempre aponta a linha exata do problema. Uma boa prática é validar o playbook com ansible-playbook --syntax-check antes de executar, e usar um editor com suporte a YAML que destaque indentação inconsistente. A maioria dos erros de iniciante desaparece com a prática de dois ou três playbooks reais.
Ansible Core, AWX e Red Hat Ansible Automation Platform: o que muda
O Ansible Core (também chamado de ansible-core) é o motor de código aberto, distribuído sob licença GPL, que contém a linguagem, o executor e os módulos essenciais. É o que você instala via pip ou gerenciador de pacotes e usa pela linha de comando. A partir da versão 2.10, os módulos foram separados em collections, pacotes independentes que podem ser instalados conforme a necessidade — o que reduz o tamanho da instalação base.
O AWX é o projeto open source que fornece interface web, API REST, agendamento de jobs, controle de acesso baseado em papéis e integração com sistemas de autenticação corporativa. Ele é o upstream do que a Red Hat comercializa como Ansible Automation Platform (AAP), que adiciona suporte empresarial, atualizações garantidas, integrações oficiais e componentes como o Automation Hub para hospedar collections privadas.
Para quem está aprendendo, a linha de comando do Ansible Core é o ponto de partida correto — ela expõe toda a lógica da ferramenta sem camadas de abstração. O AWX entra quando a automação precisa ser compartilhada por uma equipe, executada em horários programados ou acionada por eventos externos. A AAP é a escolha de empresas que precisam de SLA, suporte e governança em escala.
Perguntas frequentes sobre Ansible
Ansible é uma ferramenta de orquestração ou de configuração?
É as duas coisas. Como ferramenta de configuração, ela garante o estado desejado de servidores — pacotes, arquivos, serviços, usuários. Como ferramenta de orquestração, ela coordena a ordem das operações entre múltiplos hosts: primeiro atualizar os bancos de dados, depois os servidores de aplicação, por fim os balanceadores. Essa dupla natureza é uma das razões de sua popularidade: uma única ferramenta cobre o que antes exigia duas ou três.
Preciso saber programar para usar Ansible?
Não é obrigatório, mas ajuda. Playbooks são escritos em YAML, que é um formato de dados, não uma linguagem de programação — não há funções, loops complexos ou tipos de dados para dominar. No entanto, recursos avançados como Jinja2 templates, filtros e condicionais exigem familiaridade com lógica de programação. Quem já conhece redes de computadores e linha de comando Linux consegue produzir os primeiros playbooks funcionais em poucos dias de estudo.
Ansible serve para Windows?
Sim, com ressalvas. O Ansible gerencia hosts Windows por meio do protocolo WinRM em vez de SSH, e os módulos para Windows (win_package, win_service, win_feature, win_regedit) cobrem as operações mais comuns de administração. O control node, porém, continua precisando ser Linux ou macOS — Windows só funciona como control node dentro do WSL. A experiência em Windows é menos madura que em Linux, mas suficiente para cenários corporativos mistos.
Qual a diferença entre Ansible e Ansible Tower?
Ansible Tower era o nome do produto comercial da Red Hat que adicionava interface web, agendamento e controle de acesso ao Ansible Core. Em 2021, a Red Hat descontinuou a marca Tower e a substituiu pela Ansible Automation Platform, que engloba o Automation Controller (evolução do Tower), o Automation Hub e outras ferramentas. O AWX é a versão open source dessa mesma linhagem, gratuita e sem suporte oficial.
