Gerenciando variáveis de ambiente com o SecretsFoundry

Built for Speed: ~10ms Latency, Even Under Load
Blazingly fast way to build, track and deploy your models!
- Handles 350+ RPS on just 1 vCPU — no tuning needed
- Production-ready with full enterprise support
Escrevi sobre as diferentes formas de gerenciar variáveis de ambiente anteriormente no meu post aqui. Para facilitar o gerenciamento de configurações em nossa startup na Truefoundry, desenvolvemos uma pequena ferramenta chamada SecretsFoundry que tornou muito mais fácil para todas as equipes de aplicação manterem suas configurações no Git. Pensamos que poderia ser útil para outras equipes de desenvolvedores e, por isso, decidimos disponibilizá-lo como código aberto .
Antes de entrar em detalhes, é bom entender qual problema o SecretsFoundry resolve. Toda aplicação possui variáveis de configuração, tanto não sensíveis quanto sensíveis, que precisam ser fornecidas à aplicação quando ela está em execução. Para as variáveis não sensíveis, as pessoas geralmente as colocam em um arquivo e depois as carregam na aplicação usando bibliotecas como dotenv. Para as variáveis sensíveis, as pessoas geralmente armazenam os valores em gerenciadores de segredos como AWS SecretManager, Hashicorp Vault e então escrevem código na aplicação para buscar os segredos do armazenamento. A outra abordagem é ter algum sistema externo que injete as variáveis do armazenamento de segredos no ambiente da aplicação — caso em que o domínio das variáveis de ambiente se torna mais uma responsabilidade de DevOps e os desenvolvedores perdem o controle sobre elas — levando a mais bugs e depuração mais difícil quando ocorrem problemas.
O SecretsFoundry tenta resolver os problemas acima fazendo o seguinte:
Todas as chaves sensíveis e não sensíveis podem residir em um único arquivo.
Para variáveis não sensíveis, você pode inserir as variáveis diretamente. Para variáveis sensíveis, colocamos o caminho no armazenamento de segredos como o valor dessas variáveis. Dessa forma, informamos ao SecretsFoundry como buscar esses valores. Um exemplo de tal arquivo seria:
Arquivo .env
NODE_ENV = development
HOST = localhost
DB_NAME = example_app_db
DB_USER = ${aws-secret:/development/example_app/DB_USER}
DB_PASSWORD = ${aws-secret:/development/example_app/DB_PASSWORD}
No exemplo acima, o DB_USER e o DB_PASSWORD reais são armazenados no AWS Secrets Manager. Os desenvolvedores podem mencionar o caminho no arquivo .env e o secretsfoundry irá buscá-los para você.
Nenhum código específico da aplicação para buscar variáveis de ambiente
O Secretsfoundry funciona infundindo os valores reais no ambiente da aplicação antes de ela iniciar, em vez de dentro da própria aplicação. Isso tem duas vantagens:
- Sem dependências na aplicação e não precisamos adicionar bibliotecas em uma infinidade de linguagens diferentes.
- Caso o secretsfoundry não consiga encontrar uma determinada variável de ambiente, o próprio secretsfoundry gera um erro e fornece um sinal precoce de não-saudável para todos os sistemas de implantação como o Kubernetes. Caso contrário, cabe à aplicação fazer a validação e lidar com as falhas.
Suporte para múltiplos gerenciadores de segredos
O SecretsFoundry se integra com AWS Parameter Store, AWS S3, AWS SecretsManager e Hashicorp Vault para gerenciamento de segredos. Adicionar um novo armazenamento de segredos é bastante fácil e planejamos estender o suporte para GCP e Azure Vault no futuro.
Usando o SecretsFoundry
A forma de usar o secretsfoundry é:
secretsfoundry run -c "node start.js"
ou se você tiver múltiplos comandos no seu script de inicialização:
secretsfoundry run -s "node run_migration_script && node start.js"
Quando executamos secretsfoundry run, ele procura por um arquivo .env naquele diretório e imprime os valores das variáveis. Se houver um -c ou -s como argumento, ele os infunde no ambiente daquela aplicação. Então, se você considerar o arquivo .env que escrevemos anteriormente, executar secretsfoundry run naquele diretório irá gerar a saída
secretsfoundry run
NODE_ENV = development
HOST = localhost
DB_NAME = example_app_db
DB_USER = admin
DB_PASSWORD = password
Podemos ter uma pequena aplicação de exemplo em start.js que se parece com o seguinte:

secretsfoundry run -c “node start.js”

SecretsFoundry também pode carregar qualquer outro arquivo .env.<stage> usando
secretsfoundry run — stage=<stage>
SecretsFoundry pode obter arquivos de configuração de outro diretório usando
secretsfoundry run -p <Caminho para o diretório de configuração, que contém os arquivos .env.>
Também pode receber como entrada o caminho para um arquivo que pode estar no formato .env / json / yaml e gerar as variáveis resolvidas para um arquivo diferente. Usamos isso para integrar com vários sistemas Kubernetes, sobre os quais escreverei em outro blog.
secretsfoundry run -i <Arquivo de entrada contendo variáveis (.env/json/yaml)> -o <arquivo_de_saída>
SecretsFoundry precisa de credenciais para obter os parâmetros do SecretStore — então você terá que fornecer essas variáveis manualmente ao seu ambiente.
Instalação e Documentação
Você pode baixar o secretsfoundry usando npm ou yarn (https://www.npmjs.com/package/secretsfoundry)
npm install -g secretsfoundry
SecretsFoundry reside neste repositório do Github e sua documentação pode ser encontrada em https://truefoundry.gitbook.io/secretsfoundry.
Experimente o SecretsFoundry e nos conte sua experiência. Temos usado internamente de forma bastante extensiva com o AWS Parameter Store — no entanto, a integração com o Hashicorp Vault não foi bem testada. Experimente e nos avise se encontrar algum bug ou tiver alguma solicitação de recurso.
Publicado originalmente em Medium
TrueFoundry AI Gateway delivers ~3–4 ms latency, handles 350+ RPS on 1 vCPU, scales horizontally with ease, and is production-ready, while LiteLLM suffers from high latency, struggles beyond moderate RPS, lacks built-in scaling, and is best for light or prototype workloads.
The fastest way to build, govern and scale your AI

















.webp)






.webp)

.webp)
.webp)





.png)



