Gerenciando configurações e segredos na implantação
Aprenda a externalizar configurações e injetar com segurança segredos, como chaves de API, em aplicativos de LLM implantados usando variáveis de ambiente, mapas de configuração e gerenciadores de segredos.
Gerenciando configurações e segredos na implantação é uma aula grátis de LLM Apps in Production (RAG + Vector DB + Caching) no CoddyKit. Esta é a aula 4 de 4. Você pode ler a aula completa abaixo gratuitamente — depois pratica ao vivo no navegador com um editor de código integrado e um tutor de IA 24/7. Faz parte do caminho de aprendizado de LLM Apps in Production (RAG + Vector DB + Caching), e seu progresso é sincronizado entre a web e o app CoddyKit. O curso de LLM Apps in Production (RAG + Vector DB + Caching) inclui 4 aulas no total.
Partes desta aula ainda não foram traduzidas e aparecem em inglês.
Config Belongs Outside Code
The same LLM app image runs in dev, staging, and production. The only difference should be configuration, not the code. Hard-coding endpoints or keys forces a rebuild for every environment.
This is the core idea of config externalization.
Config vs Secrets
Two related but distinct concepts:
- Config — non-sensitive settings: model name, temperature, log level
- Secrets — sensitive values: API keys, DB passwords, tokens
Secrets need stricter handling and must never be logged.
Environment Variables
The simplest portable mechanism is environment variables.
import os
model = os.environ.get('LLM_MODEL', 'gpt-mini')
temp = float(os.environ.get('LLM_TEMPERATURE', '0.2'))
print('Using', model, 'at temp', temp)The Twelve-Factor Approach
The twelve-factor methodology says store config in the environment. This keeps the build artifact identical across environments and avoids accidentally committing secrets into version control.
Kubernetes ConfigMaps
In Kubernetes, non-sensitive config lives in a ConfigMap and is injected as env vars or files.
apiVersion: v1
kind: ConfigMap
metadata:
name: llm-config
data:
LLM_MODEL: 'gpt-mini'
LLM_TEMPERATURE: '0.2'Kubernetes Secrets
Sensitive values go in a Secret object, kept separate from ConfigMaps and mounted with tighter access controls. Base64 encoding is not encryption, so enable encryption at rest.
apiVersion: v1
kind: Secret
metadata:
name: llm-secrets
type: Opaque
stringData:
OPENAI_API_KEY: 'set-via-pipeline'Dedicated Secret Managers
For production, use a dedicated secret manager:
- HashiCorp Vault
- AWS Secrets Manager
- GCP Secret Manager
They offer rotation, audit logs, and fine-grained access far beyond plain env vars.
Fetching Secrets at Runtime
Apps can pull secrets at startup from a manager instead of baking them in. This centralizes rotation.
def load_secret(name):
store = {'OPENAI_API_KEY': 'sk-demo'}
if name not in store:
raise KeyError('missing secret: ' + name)
return store[name]
print(load_secret('OPENAI_API_KEY')[:7])Validating Config at Startup
Fail fast: validate that all required config and secrets are present when the app boots, not when the first request arrives. A clear startup error beats a confusing 500 in production.
Avoiding Secret Leaks
Common leak vectors to guard against:
- Logging full request objects that include keys
- Echoing env vars in debug endpoints
- Committing .env files
- Exposing secrets in error stack traces
Rotation and Per-Environment Keys
Use separate keys per environment and rotate them on a schedule. With a secret manager, rotation updates one place and all instances pick it up without a redeploy.
Quick Check
Test your understanding of Kubernetes config.
Recap
You learned to externalize config from code and separate it from secrets. Use environment variables and ConfigMaps for settings, Secrets and dedicated managers for sensitive values, validate everything at startup, and rotate keys per environment without leaking them in logs.
Perguntas Frequentes
A aula “Gerenciando configurações e segredos na implantação” é grátis?
Sim — o texto completo de “Gerenciando configurações e segredos na implantação” é grátis para ler aqui na web. Para praticá-la interativamente (um editor de código integrado e um tutor de IA 24/7) e desbloquear o restante do curso de LLM Apps in Production (RAG + Vector DB + Caching), atualize para CoddyKit PRO. O curso de LLM Apps in Production (RAG + Vector DB + Caching) inclui 4 aulas no total.
O que vou aprender em “Gerenciando configurações e segredos na implantação”?
Aprenda a externalizar configurações e injetar com segurança segredos, como chaves de API, em aplicativos de LLM implantados usando variáveis de ambiente, mapas de configuração e gerenciadores de seg… Você pratica LLM Apps in Production (RAG + Vector DB + Caching) com código prático que executa diretamente no navegador, e um tutor de IA 24/7 responde suas dúvidas enquanto trabalha na aula.
Preciso ter experiência prévia para começar LLM Apps in Production (RAG + Vector DB + Caching)?
Nenhuma experiência prévia é necessária. LLM Apps in Production (RAG + Vector DB + Caching) no CoddyKit é estruturado para alunos iniciantes até avançados, então você pode começar aqui ou desde o início e aprender no seu ritmo. Esta é a aula 4 de 4.
Quanto tempo leva a aula “Gerenciando configurações e segredos na implantação”?
A maioria das aulas CoddyKit leva cerca de 5–10 minutos. Cada uma é compacta e interativa, então você faz progresso constante e retoma exatamente de onde parou entre web e app.
Posso escrever e executar código nesta aula de LLM Apps in Production (RAG + Vector DB + Caching)?
Sim. Cada aula de LLM Apps in Production (RAG + Vector DB + Caching) inclui um editor de código integrado, então você escreve e executa código real direto no navegador e recebe feedback de IA instantaneamente — nenhuma configuração local necessária.
Todas as aulas deste curso
- Conteinerizando Aplicações de LLM com Docker
- Orquestração com Kubernetes para Escalabilidade
- CI/CD para Implantação de Aplicações de LLM
- Gerenciando configurações e segredos na implantação