Administrar um servidor na mão é tranquilo. Administrar dez, atualizando pacote por pacote via SSH, é pedir para errar. O Ansible resolve isso: você descreve o estado desejado em YAML e ele aplica em todos os servidores — sem agente, só com SSH. Este guia é o passo seguinte para quem já conhece o básico; se você está começando do zero (instalação, estrutura de pastas, primeiro ping), comece pelos nossos primeiros passos com Ansible.
Inventário: seus servidores
Instalação e primeiro contato estão no guia de primeiros passos — aqui vamos direto ao ponto.
Crie o arquivo inventario.ini listando as máquinas:
[web]
web1.exemplo.com.br
web2.exemplo.com.br
[db]
db1.exemplo.com.br ansible_user=root
Teste a conexão com todos de uma vez:
ansible -i inventario.ini all -m ping
Playbook completo: pacote, serviço, firewall e handler
Um playbook descreve o que deve existir no servidor. Exemplo real — garantir nginx instalado, rodando, com firewall liberado e configuração versionada via template:
---
- name: Configurar servidores web
hosts: web
become: true
vars:
dominio: exemplo.com.br
tasks:
- name: Instalar nginx
ansible.builtin.apt:
name: nginx
state: present
update_cache: true
- name: Garantir nginx ativo no boot
ansible.builtin.service:
name: nginx
state: started
enabled: true
- name: Liberar HTTP e HTTPS no ufw
community.general.ufw:
rule: allow
port: "{{ item }}"
proto: tcp
loop: ["80", "443"]
- name: Aplicar configuração do site (template Jinja2)
ansible.builtin.template:
src: templates/site.conf.j2
dest: /etc/nginx/sites-available/{{ dominio }}.conf
notify: Recarregar nginx
handlers:
- name: Recarregar nginx
ansible.builtin.service:
name: nginx
state: reloaded
Dois recursos novos aqui: o template (arquivo .j2 com variáveis Jinja2 — um modelo de config que vale para qualquer domínio) e o handler, que só recarrega o nginx se a configuração de fato mudou. Execute com simulação antes:
ansible-playbook -i inventario.ini playbook.yml --check --diff # mostra o que mudaria, linha a linha
ansible-playbook -i inventario.ini playbook.yml # aplica
O pulo do gato: idempotência
Rode o playbook duas vezes: na segunda, o Ansible não muda nada — ele só age quando o estado real difere do declarado. É isso que torna a automação segura: o playbook vira a documentação viva do servidor.
Segredos com ansible-vault
Senha de banco não vive em YAML aberto. O ansible-vault criptografa o arquivo de variáveis e o Git guarda só o texto cifrado:
ansible-vault create group_vars/db/vault.yml # cria criptografado
ansible-vault edit group_vars/db/vault.yml # edita depois
ansible-playbook -i inventario.ini playbook.yml --ask-vault-pass # pede a senha ao executar
Atualização em ondas (rolling update)
Com vários servidores atrás de um balanceador, ninguém quer derrubar todos ao mesmo tempo. O serial aplica o playbook em lotes — e --limit restringe a execução a um host ou grupo quando você quer testar em um antes dos demais:
- name: Atualizar frota web sem downtime
hosts: web
become: true
serial: 1 # um servidor por vez (aceita número ou porcentagem)
max_fail_percentage: 0
tasks:
- name: Atualizar pacotes
ansible.builtin.apt:
upgrade: dist
update_cache: true
ansible-playbook -i inventario.ini atualiza.yml --limit web1.exemplo.com.br
Comandos rápidos (ad-hoc)
# atualizar pacotes em todos os servidores web
ansible -i inventario.ini web -b -m apt -a "upgrade=dist update_cache=yes"
# reiniciar um serviço em um grupo
ansible -i inventario.ini db -b -m service -a "name=mariadb state=restarted"
Comece automatizando uma tarefa que você repete toda semana — em um mês você não vai mais lembrar como vivia sem. Para organizar tudo em roles reutilizáveis e aprofundar nos módulos, a referência é a documentação oficial; e se automação é o seu rumo de carreira, o Ansible é peça central da certificação LPI DevOps Tools Engineer.