Gerenciamento de Configurações em Produção

Toda aplicação que já foi além do laptop do desenvolvedor carrega consigo uma questão que parece simples até deixar de ser: onde vivem as configurações, quem pode mudá-las e o que acontece quando algo dá errado?

A resposta improvisada — variáveis hardcoded, arquivos .env copiados manualmente entre servidores, anotações num Notion compartilhado — funciona por um tempo. Até o dia em que alguém sobe para produção com as credenciais do banco de staging, ou uma configuração de timeout que estava errada há meses finalmente cobra seu preço durante um pico de tráfego.

Gerenciar configurações de forma séria não é burocracia. É o tipo de trabalho que fica invisível quando está funcionando e catastrófico quando não está.

---

O que conta como "configuração"

Vale ser preciso aqui, porque o escopo é mais amplo do que parece. Configuração é tudo que muda entre ambientes sem que o código mude: strings de conexão com bancos de dados, URLs de serviços externos, credenciais de APIs, flags de feature, limites de rate, timeouts, tamanhos de pool de conexão. Qualquer valor que você sentiria vontade de ajustar sem fazer um novo deploy é, provavelmente, configuração.

O The Twelve-Factor App define isso com precisão: se o código não poderia ser publicado como open source sem expor algo, esse algo é configuração e não deveria estar no repositório.

Separar segredos de configurações gerais

Antes de qualquer ferramenta, existe uma distinção conceitual importante: nem toda configuração é um segredo, mas todo segredo é uma configuração que merece tratamento especial.

Valores como APP_ENV=production ou MAX_CONNECTIONS=50 podem viver tranquilamente em arquivos versionados. Já senhas, tokens de API e chaves privadas precisam de um caminho diferente — cofres de segredos como HashiCorp Vault, AWS Secrets Manager ou Google Secret Manager. Esses serviços oferecem auditoria de acesso, rotação automática de credenciais e controle granular de permissões — coisas que um arquivo .env simplesmente não consegue entregar.

Misturar os dois numa mesma estratégia é o erro mais comum: tratar segredos com o mesmo descuido de uma variável de ambiente genérica.

Infraestrutura como código: a configuração que configura os servidores

Para a configuração dos próprios servidores e serviços — pacotes instalados, arquivos de sistema, estado dos serviços — a abordagem consolidada é declarar a intenção e deixar uma ferramenta garantir que a realidade bata com o que foi declarado. É o que se chama de Infrastructure as Code.

Ansible, Chef e Puppet operam nesse espaço. O Ansible, em particular, se popularizou pela ausência de agente nos servidores gerenciados e pela sintaxe declarativa em YAML. Um playbook real de configuração de servidor web se parece com isso:

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

  vars:
    app_domain: "exemplo.com"
    app_port: 8080

  tasks:
    - name: Instalar nginx
      apt:
        name: nginx
        state: present
        update_cache: true

    - name: Aplicar configuração do nginx
      template:
        src: templates/nginx.conf.j2
        dest: /etc/nginx/sites-available/app.conf
        mode: "0644"
      notify: Recarregar nginx

    - name: Ativar site
      file:
        src: /etc/nginx/sites-available/app.conf
        dest: /etc/nginx/sites-enabled/app.conf
        state: link

  handlers:
    - name: Recarregar nginx
      service:
        name: nginx
        state: reloaded

O detalhe do notify e do handler no final não é cosmético: ele garante que o nginx só seja recarregado se a configuração de fato mudou. Executar o mesmo playbook duas vezes num servidor já configurado não causa efeito colateral — isso é o que se chama de idempotência, e é uma propriedade que toda boa automação de configuração deve ter.

Versionamento não é opcional

Configuração que não está versionada é configuração que não existe — pelo menos não de forma auditável. Quando um problema aparece em produção, a primeira pergunta é sempre "o que mudou?". Sem histórico de versões, a resposta é um chute.

Manter os playbooks, templates e arquivos de variáveis num repositório Git separado (ou num diretório dedicado do repositório principal) resolve isso e abre outra possibilidade: usar Pull Requests para revisar mudanças de configuração antes que cheguem a produção. Uma alteração num timeout ou num parâmetro de banco de dados pode parecer trivial, mas merece o mesmo rigor que qualquer mudança de código.

Integração com CI/CD

O ponto de chegada natural dessa abordagem é que mudanças de configuração passem pelo mesmo pipeline que mudanças de código. Um commit no repositório de configuração dispara um pipeline que testa, valida e aplica as mudanças nos ambientes em sequência — primeiro staging, depois produção, com aprovação manual se necessário.

Ferramentas como GitHub Actions, GitLab CI e ArgoCD (para ambientes Kubernetes) suportam esse fluxo. O resultado é que ninguém aplica configuração diretamente nos servidores: tudo passa pelo repositório, fica registrado e é reversível.

O que costuma dar errado

Alguns padrões de problema aparecem com frequência suficiente para valer a menção:

Drift de configuração acontece quando servidores que deveriam ser idênticos acumulam diferenças ao longo do tempo — alguém ajustou algo manualmente numa emergência e nunca atualizou o repositório. A solução é rodar os playbooks periodicamente (não só quando há mudanças) para detectar e corrigir divergências automaticamente.

Segredos em variáveis de ambiente sem controle é o meio-termo perigoso: melhor que hardcoded no código, mas sem auditoria, rotação ou controle de acesso. Se a aplicação cresce, esse débito técnico cresce junto.

Ausência de teste de configuração é subestimada. Antes de aplicar qualquer mudança em produção, vale verificar a sintaxe (ansible-playbook --syntax-check), simular a execução (--check) e validar em staging. Configuração errada pode derrubar um serviço tão rapidamente quanto um bug de código.

Para ir mais fundo no tema, o guia de boas práticas do Ansible e o capítulo sobre configuração do The Twelve-Factor App são leituras curtas e densas que valem o tempo. Para quem trabalha com Kubernetes, o conceito de ConfigMaps e Secrets resolve boa parte dessas questões dentro do próprio ecossistema.