Ambientes & Promoção de Configuração

A paridade de ambientes captura falhas específicas do Rust antes da produção: contagens de workers do Tokio, tamanhos de pool do sqlx, níveis de RUST_LOG e flags de funcionalidades. A promoção de configuração move valores testados através de dev, staging e prod com segredos injetados em tempo de execução, não copiados entre laptops.

Receita

Cartão de receita de referência rápida - pronto para copiar e colar.

dev:     docker-compose local, apenas .env.example (sem segredos reais)
staging: teste de carga de 50% RPS de prod, pool max = prod, snapshot anonimizado de prod
prod:    segredos injetados pelo Vault, imagem imutável SHA, janela de alteração
 
Promoção: PR atualiza config/values.staging.yaml -> soak 48h -> PR values.prod.yaml

Quando usar isso:

• Inicialização de novo serviço
• Incidentes repetidos de "funciona em staging, falha em prod"
• Auditoria de manuseio de segredos
• Expansão multi-região

Exemplo de Trabalho

use serde::Deserialize;
 
#[derive(Debug, Deserialize)]
pub struct AppConfig {
    pub database_url: String,
    pub database_max_connections: u32,
    pub tokio_worker_threads: usize,
    pub git_sha: String,
}
 
impl AppConfig {
    pub fn from_env() -> Result<Self, config::ConfigError> {
        config::Config::builder()
            .add_source(config::Environment::default().separator("__"))
            .build()?
            .try_deserialize()
    }
 
    pub fn validate(&self) -> Result<(), String> {
        if self.database_max_connections < 5 {
            return Err("DATABASE_MAX_CONNECTIONS must be >= 5".into());
        }
        if self.tokio_worker_threads == 0 {
            return Err("TOKIO_WORKER_THREADS must be set".into());
        }
        Ok(())
    }
}

# CI: valida fixture de staging contra esquema
cargo test -p orders-api -- config_validate_staging_fixture
 
# Promover (exemplo GitOps)
cp deploy/staging/values.yaml deploy/prod/values.yaml
# revisão de diff: apenas deltas pretendidos (réplicas, URLs)

O que isso demonstra:

• Configuração tipada com validação captura erros de digitação antes da implantação
• Chaves de ambiente aninhadas via separador __ mapeiam para campos de struct
• A promoção é um PR revisado, não kubectl edit manual

Mergulho Profundo

Dimensões de Paridade

Fluxo de Segredos

• Desenvolvedores: credenciais falsas ou função de dev local do vault.
• CI: tokens de curta duração do OIDC.
• Staging/prod: Operador de segredos Vault/K8s; monta como env no início do pod.
• Nunca comitar .env com segredos de prod; cargo deny + scanners de segredos em CI.

Configuração vs Código

• Flags de funcionalidades e tamanhos de pool: camada de configuração.
• Lógica de negócios: código + lançamento normal.
• Documentar quais alterações precisam apenas de promoção de configuração vs. reconstrução de imagem.

Armadilhas

• Staging com 1/100 do tráfego - Bugs no pool se escondem. Correção: Teste de carga com 50% do pico trimestralmente.
• Erro de digitação de variável de ambiente apenas de prod - Incidente clássico. Correção: Validar esquema de todas as fixtures de ambiente em CI.
• Diferentes workers Tokio em staging vs prod - Corrida se esconde. Correção: TOKIO_WORKER_THREADS explícito em ambos.
• Copiar DB de prod para laptop - Violação de conformidade. Correção: Pipeline de snapshot anonimizado.
• Edição manual de configuração de prod - Desvio do GitOps. Correção: Reverter + PR dentro da política de 24h.

Alternativas

FAQs

Relacionados

• Gerenciamento de Releases - tempo de promoção
• Flags de Funcionalidades & Entrega Progressiva - flag por env
• Gerenciamento de Segredos - padrões de segredos
• Design de Configuração e Funcionalidades - design
• Depuração de Produção - repro de env

Versões da Stack: Esta página foi escrita para Rust 1.97.0 (edição 2024), Tokio 1.x, Axum 0.8, serde 1.0, sqlx 0.8, clap 4, e Polars 0.46+.