Configuração do ambiente — por que, o que e como?

O Gerenciamento de Configuração é um aspecto importante da engenharia de software. Este artigo destacará o porquê e o quê do problema e discutirá as diferentes soluções existentes.

A abordagem para gerenciar mudanças de configuração à medida que o aplicativo escala — tanto em termos de tráfego quanto do tamanho da equipe de desenvolvedores. Para ilustrar essa jornada, vamos começar com um aplicativo simples.

Este é um aplicativo de servidor simples que se conecta ao MongoDB e retorna a lista de usuários. O código é apenas pseudocódigo e não se destina a aderir a nenhuma linguagem.

Configuração hardcoded no aplicativo: um GRANDE NÃO!

Codificar o URI do MongoDB diretamente no aplicativo tornará muito difícil executar o aplicativo em qualquer outro ambiente — como nos laptops de colegas de equipe, ou em produção. Devemos seguir a metodologia de aplicativo de 12 fatores aqui para separar a configuração do código.

“ SEPARAR A CONFIGURAÇÃO DO CÓDIGO “

Agora a questão é o que compõe a configuração de um aplicativo? Citando de https://12factor.net/config

A configuração de um aplicativo é tudo o que provavelmente varia entre implantações (ambientes de staging, produção, desenvolvimento, etc). Isso inclui:

1. Manipuladores de recursos para o banco de dados, Memcached e outros serviços de retaguarda

2. Credenciais para serviços externos, como Amazon S3 ou Twitter

3. Valores por implantação, como o nome de host canônico para a implantação

A maneira mais fácil e comum de separar a configuração do código é colocar as variáveis em um arquivo .env.

Uma vez feito isso, precisamos carregar as variáveis no código a partir do arquivo .env. Existem vários pacotes para fazer isso, como dotenv e dotenv-expand. Nesse caso, o arquivo .env não é enviado para o Git e cada desenvolvedor sobrescreve a variável de acordo com seu próprio ambiente. Para dar a todos os desenvolvedores uma ideia de quais variáveis de ambiente precisam ser adicionadas, geralmente fazemos commit de um arquivo como .env.example para o Git.

Também precisaremos fornecer os valores dessas variáveis nos ambientes de staging e produção. Quase todos os sistemas de implantação oferecem uma maneira de armazenar e fornecer variáveis de ambiente, como ConfigMap e Secrets no Kubernetes, ou S3 para o Elastic Container Service.

Precisaremos copiar essas variáveis para esses ambientes e mantê-las sincronizadas sempre que os desenvolvedores adicionarem/removerem variáveis de ambiente. Uma abordagem possível é ter um arquivo .env separado para os ambientes de staging, produção, etc.

Como e onde armazenamos os arquivos .env específicos de cada ambiente?

Pode-se sugerir armazenar esses arquivos no Git, mas há um grande problema de segurança nesse caso — especialmente para algumas das credenciais sensíveis nos arquivos .env.

1. Provavelmente não queremos que todos os desenvolvedores tenham acesso a credenciais de banco de dados e outras informações sensíveis à segurança.
2. Armazenar todas as credenciais em texto simples no repositório do Github também é um grande risco de segurança do ponto de vista de vazamento de segurança.

As pessoas usam abordagens diferentes aqui — no entanto, alguns dos métodos bem conhecidos são:

1. Armazenar valores criptografados no repositório Git e os valores podem ser descriptografados apenas por alguém que possua as chaves. Uma boa biblioteca para conseguir isso é https://github.com/StackExchange/blackbox
2. Usar armazenamento externo: Esta abordagem baseia-se no armazenamento das variáveis de ambiente para staging, produção, etc. numa camada de armazenamento diferente, como S3 ou AWS Parameter Store. Apenas os ambientes de produção e staging têm permissão para ler esses valores e, portanto, podem ser protegidos dos desenvolvedores. Os SecretManagers também entram aqui, podendo armazenar os segredos criptografados, fornecer controle de acesso e também rotacionar automaticamente os segredos. Alguns exemplos de tais gerenciadores de segredos / armazenamentos de parâmetros são:

Ao usar qualquer um desses sistemas externos, dividimos agora a configuração entre os arquivos .env e os secretmanagers. Alguns dos parâmetros não sensíveis virão dos arquivos .env e outros virão do armazenamento remoto de credenciais. Podemos argumentar que podemos armazenar todos os parâmetros no armazenamento remoto — mas isso pode ser um exagero às vezes. Então, o que temos agora é:

Nossa aplicação agora precisa ter código para ler de ambas as fontes de configuração. A leitura dos arquivos .env pode ser feita usando o pacote dotenv, no entanto, obter as variáveis de ambiente dos secretmanagers exige que usemos suas APIs correspondentes para obter os valores.

Isso resolve a questão de manter nossa configuração segura e também seguir a metodologia de 12 fatores.

No entanto, escrever código de aplicação para obter segredos acaba sendo uma prática repetitiva, onde cada aplicação agora precisa adicionar código específico do secretmanager para obter os valores da API. Isso também significa que, se alguma vez mudarmos nosso provedor de secretsmanager, o código em todas as aplicações precisará ser alterado. Para resolver este problema, podem existir algumas abordagens:

1. Abstrair o código para extrair segredos como uma biblioteca padrão a ser compartilhada entre todas as suas aplicações. Isso pode simplificar o problema até certo ponto.
2. Sincronizar valores dos secretmanagers para o ambiente de hospedagem de forma assíncrona — isso requer um sistema externo que pode dificultar a sincronização de lançamentos de código e alterações de configuração. Por exemplo, vault-k8s permite sincronizar segredos do Vault com ambientes Kubernetes.
3. Use uma solução paga como Doppler (doppler.com)
4. Use soluções de código aberto como SecretsFoundry — isso permite que você se comunique com diferentes gerenciadores de segredos sem adicionar nenhum código em suas aplicações. Escreverei mais sobre o SecretsFoundry no meu próximo artigo.

O gerenciamento de configuração é complexo e deve ser feito corretamente desde o início para garantir que a velocidade do desenvolvedor permaneça alta sem sacrificar os aspectos de segurança. O Kubernetes, que é o mais amplamente utilizado hoje para implantar aplicações, vem com seu próprio gerenciamento de configuração e segredos, no qual me aprofundarei em outro artigo. Além disso, se você estiver usando alguma outra forma de gerenciamento de configuração, por favor, mencione nos comentários — adoraria saber mais e aprender com você!

TrueFoundry é um gateway de IA de nível empresarial que engloba um LLM, MCP e gateways de agente, permitindo que as empresas conectem, observem e governem com segurança o acesso a modelos, ferramentas, guardrails e agentes a partir de um único painel de controle. O AI Gateway permite cargas de trabalho agentivas que são:
a) Seguras — resolvendo questões de gerenciamento de chaves, autenticação e autorização
b) Eficientes — otimizando custos, latência e failovers multirregionais
c) Preparadas para o futuro — permitindo conexões unificadas e composíveis entre LLMs, MCPs e guardrails de qualquer provedor