Primeiros passos com Ansible

Se você ainda configura servidor na mão — entra por SSH, edita arquivo, instala pacote, repete tudo na máquina seguinte —, o Ansible é a ferramenta que vai aposentar esse ritual. Ele descreve o estado desejado das suas máquinas em arquivos YAML legíveis, aplica tudo via SSH sem instalar agente nenhum nos servidores, e pode rodar mil vezes que o resultado é o mesmo. Neste guia você vai instalar o Ansible no Ubuntu, entender a estrutura de pastas de um projeto e rodar seus primeiros comandos e playbooks — e, de quebra, conhecer a história curiosa de como ele nasceu.

Como nasceu o Ansible

O Ansible foi criado em fevereiro de 2012 por Michael DeHaan, um engenheiro que conhecia o problema de perto: na Red Hat, ele havia criado o Cobbler (provisionamento de servidores) e trabalhado no Func (execução remota de comandos). A experiência com essas ferramentas — e com a complexidade dos concorrentes da época, Puppet e Chef, que exigiam agentes instalados e linguagens próprias — moldou os três princípios do projeto: sem agente (só SSH e Python, que já existem em qualquer servidor Linux), YAML legível em vez de linguagem de programação, e curva de aprendizado mínima.

Até o nome tem uma boa história: ansible é o comunicador instantâneo interplanetário da ficção científica — termo cunhado por Ursula K. Le Guin em 1966 e popularizado por O Jogo do Exterminador, de Orson Scott Card. A metáfora é perfeita: comandar máquinas distantes instantaneamente, sem intermediários.

O projeto explodiu em adoção, virou empresa (AnsibleWorks, depois Ansible Inc.) e, em outubro de 2015, foi comprado pela Red Hat — que o mantém open source até hoje. Do ecossistema vieram o Ansible Galaxy (repositório de roles e collections prontas) e o AWX/Ansible Automation Platform (interface web e orquestração corporativa). Hoje o núcleo vive no pacote ansible-core, e o pacote ansible completo agrega as collections da comunidade.

Instalando no Ubuntu

O jeito mais simples é pelo repositório oficial do Ubuntu:

sudo apt update
sudo apt install ansible -y
ansible --version

Para ter uma versão mais recente que a dos repositórios, use o PPA oficial do projeto:

sudo add-apt-repository --yes --update ppa:ansible/ansible
sudo apt install ansible -y

Uma terceira via, boa para quem quer isolar a instalação do sistema, é o pipx:

sudo apt install pipx -y
pipx install --include-deps ansible
pipx ensurepath   # abra um novo terminal depois deste comando

Importante: o Ansible só precisa estar instalado na sua máquina (o “control node”). Nos servidores gerenciados basta haver SSH e Python — nada de agente, nada de daemon.

A estrutura de pastas de um projeto

O Ansible funciona a partir de qualquer diretório, mas adotar a estrutura convencional desde o primeiro dia evita retrabalho. Um projeto típico:

meu-projeto/
├── ansible.cfg          # configuração local do projeto
├── inventory.ini        # inventário: quais máquinas gerenciar
├── site.yml             # playbook principal
├── group_vars/          # variáveis por grupo de hosts
│   └── webservers.yml
├── host_vars/           # variáveis por host individual
│   └── web01.yml
└── roles/               # unidades reutilizáveis de automação
    └── nginx/
        ├── tasks/main.yml      # o que fazer
        ├── handlers/main.yml   # reações (ex.: restart do serviço)
        ├── templates/          # arquivos .j2 (Jinja2)
        ├── files/              # arquivos estáticos para copiar
        ├── defaults/main.yml   # variáveis com valores padrão
        └── vars/main.yml       # variáveis fixas da role

O essencial de cada peça:

• ansible.cfg — configurações do projeto (qual inventário usar, usuário SSH padrão etc.). O Ansible lê o do diretório atual antes do global;
• Inventário — a lista de máquinas, simples assim: grupos entre colchetes, hosts embaixo;
• Playbook — o roteiro YAML: “nesses hosts, execute estas tarefas”;
• Roles — playbooks embalados para reuso: a role nginx de um projeto funciona em qualquer outro;
• group_vars/host_vars — valores que mudam por ambiente (IP do banco, versão do pacote), separados da lógica.

Primeiros testes: o ping

Crie o projeto e um inventário mínimo:

mkdir meu-projeto && cd meu-projeto

cat > inventory.ini <<'EOF'
[webservers]
web01 ansible_host=192.168.0.10 ansible_user=ubuntu
EOF

cat > ansible.cfg <<'EOF'
[defaults]
inventory = inventory.ini
host_key_checking = False   # so para laboratorio; em producao, mantenha a checagem
EOF

Garanta que sua chave SSH chegue ao servidor (ssh-copy-id ubuntu@192.168.0.10) e teste a comunicação:

ansible all -m ping
# web01 | SUCCESS => { "ping": "pong" }

Sem servidor à mão? Teste tudo contra a própria máquina: ansible localhost -m ping (no localhost o Ansible usa conexão local, nem precisa de SSH). O módulo ping não é ICMP — ele confirma que consegue se conectar e executar Python do outro lado, que é o que importa.

Comandos ad-hoc: poder imediato

Antes de escrever playbooks, você já resolve muita coisa com comandos avulsos:

ansible all -m shell -a "uptime"                     # comando em todos os hosts
ansible webservers -m apt -a "name=htop state=present" --become   # instalar pacote
ansible all -m setup -a "filter=ansible_distribution*"            # coletar fatos

O --become pede sudo do outro lado; -m escolhe o módulo e -a passa os argumentos.

O primeiro playbook

Agora o roteiro completo — site.yml, que instala e garante o Nginx no ar:

---
- name: Configurar servidores web
  hosts: webservers
  become: true

  tasks:
    - name: Instalar o Nginx
      ansible.builtin.apt:
        name: nginx
        state: present
        update_cache: true

    - name: Garantir Nginx ativo e habilitado no boot
      ansible.builtin.service:
        name: nginx
        state: started
        enabled: true

Execute — primeiro em modo de simulação, depois de verdade:

ansible-playbook site.yml --check   # dry-run: mostra o que mudaria
ansible-playbook site.yml           # aplica

Rode a segunda vez e repare no resumo: changed=0. Essa é a idempotência, o coração do Ansible — ele não “executa comandos”, ele garante estados. Se o Nginx já está instalado e rodando, nada é tocado.

Próximos passos

Daqui, os caminhos naturais: transformar o playbook em role (ansible-galaxy role init roles/nginx), versionar o projeto no Git e explorar módulos no docs.ansible.com. Quando a base estiver confortável, siga para o nosso guia mais avançado — Automatizando Servidores Linux com Ansible — e, se automação virar carreira, o Ansible é peça central da certificação LPI DevOps Tools Engineer.

Instale, faça o ping, rode o playbook duas vezes e veja o changed=0: nesse momento você entende por que tanta gente não configura mais servidor na mão. 🐧