Herdar configurações

1) Por que é preciso herdar configurações

• Reutilizar valores gerais (logs, retratos, temporizações).
• Compartilhar responsabilidades: a plataforma define políticas básicas, os comandos de serviços são apenas desvios.
• Evitar duplicação e reduzir o risco de desabastecimento.
• Acelerar lançamentos: as alterações padrão são transmitidas para baixo na árvore.
• Manter ambientes multi e multi-tenência com uma única abordagem.

2) Modelos de herança

2. 1 Hierárquico (pai → filho)

Base (global) → ambiente (prod/estágio/dave) → região/cluster → serviço → instância.
Simples e transparente, mas pode levar a «cadeias profundas» e depurações complexas.

2. 2 Camadas (base/overlays)

Camada básica + conjunto de overleys (função-x, region-eu, security-hardening).
Combina bem com GitOps e Kustomize; os overleys são independentes e compostos.

2. 3 Composição (pods/pacotes)

A configuração é selecionada a partir de «logging @ v2», «metrics @ v1», «http @ v3».
Gerenciamento de versões de módulos, compatibilidade semântica, dependências explícitas.

2. 4 Políticas acima dos valores (Policy-as-Code)

Limitadores e invariantes básicos (OPA/Rego, Kyverno, Conftest).
Os valores não são herdados, são as regras de permissividade.

3) Algoritmos de fusão e prioridades

1. Ordem de origem: da esquerda para a direita (base eng region service).

• «O último a vencer» (last-write-wins).
• Objeto: Merj recorsal por chave.

• `append`/`prepend`
• 'uniqueBy (key)' (muitas por chave)
• 'patch' (procurar um item por 'name' e um merj parcial).
• 3. Chaves reservadas (por exemplo, '_ merge: replace '/' _ merge: deep' ao nível do nó).

• Bandeiras de início/variáveis END> segredos de rating> arquivos em disco> valores padrão no código.

Exemplo de merja YAML

yaml base. yaml http:
port: 8080 timeouts:
read: 2s write: 2s features:
- name: audit enabled: false

prod. yaml http:
timeouts:
read: 1s features:
- name: audit enabled: true
- name: billing enabled: true

Result (under policy: object = deep merge, array = uniqueBy (name) + patch)
http:
port: 8080 timeouts:
read: 1s write: 2s features:
- name: audit enabled: true
- name: billing enabled: true

4) Esquemas e validação

O esquema é uma condição de herança segura.

JSON Schema/OpenAPI: tipos, campos obrigatórios, enum, pattern, limitações ('minimum', 'format', 'patternProperties').
Versionagem de circuitos (semver): major - quebra, menor - novos campos, patch - fixação.
Pré-merge e Post-merge verificação: validar fatias e resultados.
Default: definir em nível de esquema (draft-07 + suporta 'default').

5) Ambiente e matriz de implantação

• env: dev, test, stage, prod region: eu-central-1, us-east-1 tier: batch, realtime, internal tenant: A/B/C (white-label, B2B)
• As combinações formam a árvore dos overleys; evite a profundidade excedente (nível 3-4 suficiente).

6) Multi-tenência

• Separação rígida: arquivos/pastas individuais por tenante.
• Configuração: um modelo + values per tenant.
• Políticas herdadas: limites de recursos/quotas, SLO, retalhos de logs.
• Importante: os limites de segurança (segredos/chaves) não devem ser emitidos entre os tenentes.

7) Segredos e segurança

Não herdem segredos de forma clara. As referências são «secretRef», «vaultPath».
KMS/Vault/SOPS: Armazenar valores criptografados no Git e as chaves fora.
Partilhe a responsabilidade: a plataforma gere caminhos e políticas; a equipe do serviço é o que realmente precisa.
Políticos: banir 'plaintext' segredos em verificações CI.
Rotation: não «regravar para baixo» - use alias/abstrações ('db/primary/spd @ 2025-Q4').

Exemplo com referência Vault

yaml db:
host: postgres. service user: app passwordFrom:
vaultPath: "kv/prod/app-db"
key: "password" # secret is taken at the deploy stage, not stored in files

8) Versionização e migração

Versões dos módulos de configuração: 'logging @ 2. 3. 1`.
Changelog para diagramas: migração com jsonnet/ytt/castômicos.
Migrações bidirecionais (up/down) para retração segura.
Ramos longos: evitar a deriva; regularmente, requer overleys para a base.

9) Ferramentas e práticas

9. 1 Kubernetes

Kustomize (overlays): modelo de herança natural através de 'bases '/' resources', 'patchesStrategicMerge '/' patchesJSON6902'.
Helm (values): hierarquia 'values. yaml '+' -set '(mas cuidado com as redefinições do CI).
Kyverno/OPA: políticas como «malhas de seguro».

yaml overlays/prod/kustomization. yaml resources:
-../../base patchesStrategicMerge:
- patch-resources. yaml commonLabels:
env: prod

9. 2 Terraform

Módulos + 'variáveis. tf 'como um contrato.
'locals' para valores computáveis, 'override' arquivos - use camadas de diretório e espaço de trabalho ('workspaces').
Ordem de origem: os valores padrão <se os arquivos <'-var '/' -var-arquivo'.

hcl module "svc" {
source = "./modules/svc"
replicas = var. env == "prod"? 4: 2 logging = local. logging_base
}

9. 3 Ansible

Hierarquia clara de variáveis (por prioridade crescente): role defaults <inventory group _ vars <host _ vars <extra vars.
Para herdar, a estrutura é 'group _ vars/se-à-diante de...

9. 4 Jsonnet / ytt

Rica composição, funções e «chave de intenção» ('overlay. replace`, `overlay. merge`).

10) Contratos e limites de responsabilidade

Plataforma (platformm team): define o padrão, as políticas, os valores básicos, a lógica do merj.
Comandos de alimentos, apenas overleys dentro do contrato.
SRE/Segurança: auditorias, validações, assinaturas, enforcement.

11) CI/CD и GitOps

1. Lint (formato, exclusão de chaves desconhecidas).

2. Validate (JSON Schema/OpenAPI).

3. Dry-run/Render (helm template/kustomize build).

4. Policy check (OPA/Kyverno/Conftest).

5. Diff contra o cluster de destino (kubectl diff/ArgoCD diff).

6. Avançive delivery: overleys canários com tráfego limitado.

7. Assinatura de artefatos (comprovação SLSA).

12) Observabilidade e depuração

Traçamento de origem (provenance): quem e quando colocou o campo, de qual camada veio o valor final.
Visualização do Merj, relatório das chaves vencedoras.
Rottime-exportação de configuração ativa (endpoint '/config 'com camuflagem de segredos).
Alertas à deriva, divergências entre o declarado e o real.

13) Anti-pattern

«Magia» sem regras claras de prioridade.
Cadeias profundas (> 4-5 camadas): aumenta a carga cognitiva.
Os segredos estão nos ficheiros herdados.
Substituições ocultas por '-set' em CI.
Nenhum padrão ou teste de renderização.

14) Folha de cheque de implementação

• Defina o modelo (hierarquia/camadas/composição).
• Fixe a ordem do merj e as estratégias por tipo.
• Publicar o esquema e a versionização.
• Compartilhe segredos (apenas links/refis).
• Adicione policy-checks e assinaturas de artefatos.
• Inclua dry-run, difs e visualização de origem.
• Certifique-se de exportar a configuração ativa no rentame.
• Configure os lançamentos progressivos para alterações configh.

15) FAQ

Como compreender que a camada é muito profunda?
A: Se você deseja abrir> 3 arquivos e «rolar»> 2 níveis de abstração, reveja a estrutura.

O que fazer com as matrizes em conflito?
A: Digite estratégias explícitas: «replace», «append», «uniqueBy (key)», «patchBy (name)» - e anote-as na documentação.

Podemos herdar segredos?
A: Não. Apenas links (URI/Refis) são herdados para o armazenamento secreto e políticas de acesso.

Q: Como testar herança?
A: Retire os «cortes» para combinações essenciais de overlay e verifique os arquivos golden; Corra renderização para CI para cada PR.

Anexo A: Mini-spec merja

`scalars`: last-write-wins

'object': deep-merge por chave

• padrão 'replace'

• `append`
• `uniqueBy(key)`
• 'patchBy (key)', com merjom recursal de elementos

• `_merge: replace|deep`
• `_strategy. array: replace|append|uniqueBy(name)|patchBy(name)`

Anexo B: Exemplos

B.1 Helm values (prod acima da base)

yaml values. base. yaml replicas: 2 resources:
requests:
cpu: "100m"
memory: "128Mi"
logging:
level: info

values. prod. yaml replicas: 4 logging:
level: warn

helm template svc chart/ -f values. base. yaml -f values. prod. yaml

A prioridade do último arquivo é 'values. prod. yaml`.

B.2 Kustomize overlays

yaml base/deployment. yaml apiVersion: apps/v1 kind: Deployment metadata:
name: app spec:
replicas: 2

overlays/prod/patch. yaml apiVersion: apps/v1 kind: Deployment metadata:
name: app spec:
replicas: 4

B.3 Ansible vars

group_vars/prod. yml # values of prod host_vars/prod-eu-1. yml # clarifications for extra vars host in CLI have highest priority

Resumo

1. modelo claro e prioridades,

2. esquemas de validação e overleads independentes,

3. não herdar segredos,

4. GitOps-pipline com dry-run, policy-checks e difs,

5. observabilidade da origem dos valores finais.

Seguindo estes princípios, você terá configurações previsíveis, escaláveis e seguras para qualquer ambiente e topologia.