Se você já passou uma madrugada inteira configurando manualmente um servidor que caiu, sabe exatamente o sentimento: o terminal aberto em cinco abas, pacotes sendo instalados na memória, arquivos de configuração copiados às pressas via SCP e aquela dúvida silenciosa de "será que esqueci de configurar alguma variável de ambiente ou permissão de firewall?".

A administração de servidores baseada em intervenções manuais não é sustentável quando a operação cresce. Bastam algumas semanas para o servidor se transformar no clássico "servidor floco de neve" — único, misterioso e com medo crônico de qualquer reboot. A saída prática e sem excesso de complexidade para times enxutos está na união de duas ferramentas consagradas: Ansible para a governança do host e Docker para o isolamento das aplicações.

O papel exato de cada ferramenta na esteira

Um erro comum ao desenhar uma infraestrutura é tentar forçar o Ansible a fazer o que o Docker faz melhor, ou usar containers para gerenciar aspectos do sistema operacional que deveriam ser tratados no host.

  • Ansible cuida do host: Atualização de pacotes de segurança do SO, hardening de SSH, regras de firewall (iptables/ufw), criação de usuários não-root com chaves autorizadas, instalação do Docker Engine e configuração de logs do sistema.
  • Docker cuida da aplicação: Empacotamento de código, dependências de runtime (Node, PHP, Python), isolamento de processos, controle de limites de memória/CPU e orquestração de serviços com Docker Compose.

Quando essa divisão de fronteiras fica clara, você elimina 90% dos scripts shell frágeis e cria uma infraestrutura previsível, versionada no Git e pronta para ser reconstruída em minutos caso a VPS precise ser recriada.

Estrutura prática de um Playbook enxuto

Em vez de playbooks quilométricos com dezenas de roles que ninguém na equipe tem coragem de auditar, mantenha tarefas diretas e idempotentes. O Ansible brilha quando cada bloco garante um estado desejado.

- name: Provisionar Host Base e Docker
  hosts: servidores_producao
  become: yes
  tasks:
    - name: Garantir pacotes essenciais instalados
      apt:
        name:
          - ufw
          - fail2ban
          - curl
          - htop
          - docker.io
          - docker-compose-plugin
        state: present
        update_cache: yes

    - name: Configurar firewall para liberar apenas portas seguras
      ufw:
        rule: allow
        port: "{{ item }}"
        proto: tcp
      loop:
        - 22
        - 80
        - 443

    - name: Garantir servico do Docker ativo e habilitado no boot
      systemd:
        name: docker
        state: started
        enabled: yes

Com poucas linhas declarativas, você garante que qualquer nova máquina adicionada ao inventário receba exatamente a mesma blindagem de rede e os mesmos utilitários operacionais, sem depender de memória humana.

3 Armadilhas comuns na automação (e como contornar)

1. Guardar segredos e senhas em texto puro nos repositórios

É tentador colocar senhas de banco ou tokens de API direto nos arquivos vars.yml. A regra aqui é simples: use o Ansible Vault para criptografar qualquer variável sensível antes de commitar no Git, ou passe variáveis de ambiente dinâmicas durante o deploy.

2. Esquecer a rotação e o limite de logs do Docker

Um dos motivos mais frequentes de servidores pararem de responder do nada é o esgotamento de disco causado por arquivos *-json.log gigantes do Docker. Configure o daemon global do Docker no host (via Ansible) com limite de tamanho e rotação automática:

{
  "log-driver": "json-file",
  "log-opts": {
    "max-size": "50m",
    "max-file": "3"
  }
}

3. Deploys sem verificação de integridade (Healthchecks)

Subir um container não significa que ele esteja funcional. Sempre configure diretivas de healthcheck nos seus arquivos docker-compose.yml. Assim, seu reverse proxy (Nginx, Traefik ou Caddy) só direciona tráfego quando a aplicação realmente estiver respondendo 200 OK.

Automação como documentação viva

O maior ganho de padronizar sua infraestrutura com Ansible e Docker não é apenas a agilidade no provisionamento, mas a tranquilidade operacional. O playbook passa a ser a documentação oficial e executável de como sua infraestrutura funciona.

Seja para subir um nó de contingência ou para integrar um novo desenvolvedor ao time, ter uma base reprodutível transforma tarefas que antes duravam dias de estresse em uma rotina de poucos minutos e um único comando.