Para Atingir O Estado Almejado É Fundamental

Entendendo o problema do estado desejado em sistemas

Você já tentou configurar um servidor e percebeu que depois de três meses o sistema já não estava mais no estado que você projetou inicialmente. Isso acontece porque configurações manuais tendem a divergir com o tempo. Logs sendo rotacionados, serviços sendo reiniciados fora do padrão, pacotes atualizados sem coordenação — tudo isso empurra o sistema para longe do que você originally definiu. A diferença entre um sistema que funciona e um que funciona consistentemente geralmente está na capacidade de definir o que você quer e fazer com que o sistema alcance e mantenha esse estado automaticamente. Não é mágica, é repetibilidade com supervisão.

Na prática, eu trabalho com infra como código há cerca de oito anos, e a primeira vez que eu realmente entendi o valor disso foi quando passei dois dias corrigindo uma inconsistência entre três servidores de produção que pareciam idênticos mas se comportavam de formas diferentes sob carga. A causa raiz era uma configuração manual feita por alguém seis meses antes. Depois disso, parei de confiar em memória e comecei a tratar cada sistema como algo que precisava ser descrito declarativamente. Um detalhe que muita gente perde: o Ansible não precisa de agente instalado nos nós gerenciados. Ele se conecta via SSH e executa comandos. Isso significa que qualquer servidor Linux acessível por SSH pode ser gerido dessa forma, sem configurações preliminares. A desvantagem é que a performance cai em larga escala porque cada execução faz uma verificação completa de estado. Se você tem centenas de servidores, considere ferramentas como Puppet ou Chef, que mantêm agentes permanentes. A estrutura de diretórios que eu uso segue um padrão que funciona para a maioria dos projetos:

project-root/ inventory/ production staging group_vars/ webservers databases host_vars/ (arquivos por hostname) roles/ nginx/ tasks/ main.yml templates/ handlers/ defaults/ (outros roles) site.yml Cada role representa um componente independente do seu sistema. O nginx lida com o servidor web. O firewall gerencia regras de iptables ou ufw. O app deploy é responsável por colocar seu código no lugar certo. Isso separação evita que uma mudança em um serviço quebre outro sem aviso.

Exemplo concreto: configuring nginx com SSL

Aqui está como eu descrevo o estado desejado para um servidor nginx com certificado TLS. O arquivo principal de tarefas parece com isso:

- name: Ensure nginx is installed apt: name: nginx state: present notify: Restart nginx - name: Deploy nginx configuration template: src: nginx-site.conf.j2 dest: /etc/nginx/sites-available/{{ domain }} owner: root group: root mode: '0644' notify: Reload nginx - name: Ensure SSL certificate exists become: yes command: certbot certonly --nginx -d {{ domain }} creates: /etc/letsencrypt/live/{{ domain }}/fullchain.pem

O handler de "Restart nginx" só é executado quando a tarefa de instalação realmente faz uma mudança. O handler de "Reload nginx" é acionado apenas quando o arquivo de configuração é modificado. Essa distinção é importante — restart mataria conexões ativas, reload não. Eu prefiro reload sempre que possível.

Erros comuns que eu vi acontecerem repetidamente

A primeira coisa errada que a maioria das pessoas faz é tentar controlar tudo numa única playbook. O resultado é um arquivo enorme que demora horas para executar e é impossível de debugar. Separe responsabilidades. Cada role deve fazer uma coisa e fazê-la bem. Outro erro frequente é não testar antes de aplicar em produção. Eu rodo ansible-playbook com a flag --check em todos os ambientes primeiro. Isso mostra o que seria alterado sem realmente fazer mudanças. Depois vejo a saída, confirmo que está correto, e só então executo sem a flag. Leva uns minutos a mais no início mas economiza horas de troubleshooting depois.

Um problema específico que eu encontrei recentemente: um Playbook que funcionava perfeitamente em staging mas falhava em produção porque o nome do host em produção continha um hífen e a variável que eu usava nos templates do nginx não escapava caracteres especiais adequadamente. O certificado SSL simplesmente não era emitido. A solução foi usar a filter chain do Jinja2 com | regex_replace para normalizar o hostname antes de usá-lo em qualquer contexto. A frequência ideal depende do seu cenário. Sistemas estáticos como repositórios de artefatos podem ser verificados semanalmente. Serviços financeiros que manipulam dados sensíveis merecem verificação horária. O custo operacional é baixo — uma execução completa do Ansible em um servidor tipicamente leva entre 30 segundos e 2 minutos, dependendo do número de módulos sendo avaliados. Você também deve versionar todo o seu estado desejado no Git. Cada mudança no playbook deve ser uma commit com mensagem clara. Isso cria um histórico do que foi alterado, quando e por quê. Quando algo quebra, você consegue fazer bisect rapidamente para identificar a introdução do problema.

Quando essa abordagem não funciona bem

Existem cenários onde controle declarativo de estado é menos eficaz. Sistemas com estado dinâmico complexo, como filas de mensagens com milhares de mensagens em trânsito, não se beneficiam muito dessa abordagem. O objetivo aqui é consistency de configuração, não gerenciamento de estado aplicativo em tempo real.

Também não recomendo depender exclusivamente de Ansible para configurações que exigem respostas em tempo real a eventos do sistema. Se você precisa de algo que reaja instantaneamente a mudanças de rede ou a falhas de hardware, considere combinar com ferramentas como etcd ou Consul para descoberta de serviço e configuração dinâmica.