Herencia de configuración

1) Por qué es necesario heredar configuraciones

• Volver a usar valores comunes (lógica, retraídas, temporizadores).
• Compartir responsabilidad: la plataforma establece las políticas básicas, los equipos de servicios son sólo desviaciones.
• Evitar duplicaciones y reducir el riesgo de resincronización.
• Acelerar las versiones: los cambios predeterminados se transmiten por el árbol.
• Mantener el multi-entorno y multi-tenencia con un enfoque unificado.

2) Modelos de herencia

2. 1 Jerárquico (padre → hijo)

Base (global) → entorno (prod/stage/dev) → región/clúster → servicio → instalaciones.
Es simple y transparente, pero puede conducir a «cadenas profundas» y depuraciones complejas.

2. 2 Capas (base/overlays)

Capa base + conjunto de sobrecostes (feature-x, region-eu, security-hardening).
Combina bien con GitOps y Kustomize; los overlays son independientes y compositivos.

2. 3 Compuesto (módulos/paquetes)

La configuración se recoge desde los módulos: 'logging @ v2', 'metrics @ v1', 'http @ v3'.
Control de versiones de módulos, compatibilidad semántica, dependencias explícitas.

2. 4 Política sobre valores (Policy-as-Code)

Los «limitadores» básicos e invariantes (OPA/Rego, Kyverno, Conftest).
No se heredan los valores en sí, sino las reglas de su validez.

3) Algoritmos de fusión y prioridades

1. Orden de origen: de izquierda a derecha (base ← env ← región ← servicio ← instance).

• Scalar: «el último ganó» (last-write-wins).
• Objeto: valor recursivo por clave.

• `append`/`prepend`
• 'uniqueBy (clave)' (muchos por clave)
• 'patch' (buscar un elemento por 'name' y un merge parcial).
• 3. Claves reservadas (por ejemplo, '_ merge: replace '/' _ merge: deep' en el nivel de nodo).

• Indicadores de inicio/variables ENV> secretos de rantime> archivos en disco> valores predeterminados en código.

Ejemplo YAML-merge

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 y validación

Tener un esquema es un requisito previo para una herencia segura.

JSON Schema/OpenAPI: tipos, campos obligatorios, enum, patrones, restricciones ('minimum', 'format', 'patternProperties').
Versioning Scheme (semver): major - rompiendo, minor - nuevos campos, patch - fixes.
Pre-merge y Post-merge de validación: validar tanto los fragmentos como el resultado.
Impagos: especificar a nivel de esquema (draft-07 + admite 'default').

5) Entorno y matriz de despliegue

• env: dev, test, stage, prod region: eu-central-1, us-east-1 tier: batch, realtime, internal tenant: A/B/C (white-label, B2B)
• Las combinaciones forman un árbol de overlay; evitar el exceso de profundidad (3-4 niveles es suficiente).

6) Multi-tenencia

• División rígida: archivos/carpetas individuales en tenantes.
• Parametrización: una plantilla + valores per tenant.
• Directivas heredadas: límites de recursos/cuota, SLO, retinga de registros.
• Importante: los límites de seguridad (secretos/claves) no deben fluir entre los tenantes.

7) Secretos y seguridad

No heredes secretos de forma explícita. Las referencias heredadas son: 'secretRef', 'vaultPath'.
KMS/Vault/SOPS: almacena los valores cifrados en Git, las claves están fuera.
Comparte la responsabilidad: la plataforma gestiona los caminos y las políticas, el equipo del servicio es lo que realmente se necesita.
Políticas: prohibir 'plaintext' secretos en las comprobaciones de CI.
Rotación: no «sobrescribir hacia abajo» - use alias/abstracciones ('db/primary/password @ 2025-Q4').

Ejemplo con enlace 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) Versificación y migración

Versiones de los módulos de configuración: 'logging @ 2. 3. 1`.
Changelog para esquemas: migración mediante jsonnet/ytt/scripts personalizados.
Migraciones bidireccionales (up/down) para revertir de forma segura.
Ramas largas: evitar la deriva; Regularmente rebotar overlay en la base.

9) Instrumentos y prácticas

9. 1 Kubernetes

Kustomize (overlays): modelo natural de herencia a través de 'bases '/' recursos', 'patchesStrategicMerge '/' patchesJSON6902'.
Helm (valores): jerarquía 'valores. yaml '+' --set '(pero tenga cuidado con las redefiniciones en CI).
Kyverno/OPA: pólizas como «redes de seguros».

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

9. 2 Terraform

Módulos + 'variables. tf 'como un contrato.
'locals' para los valores calculados, 'override' no hay archivos - utilizar capas de directorio y espacios de trabajo ('workspaces').
Orden de origen: valores predeterminados <archivos tfvars <'-var '/' -var-file'.

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

9. 3 Ansible

Jerarquía clara de variables (por prioridad ascendente): role defaults <inventory group_vars <host_vars <extra vars.
Para herencia: estructura 'group _ vars/{ env }/{ region} .yml'.

9. 4 Jsonnet / ytt

Rica composición, funciones y «clave-intención» ('overlay. replace`, `overlay. merge`).

10) Contratos y límites de responsabilidad

Plataforma (platform team): define el esquema, las políticas, los valores de referencia, la lógica del merge.
Equipos de productos: sólo sobreesfuerzos dentro del contrato.
SRE/Seguridad: auditoría, validación, firmas, enforcement.

11) CI/CD и GitOps

1. Enlace (formato, prohibición de claves desconocidas).

2. Validate (JSON Schema/OpenAPI).

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

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

5. Diff versus el clúster de destino (kubectl diff/ArgoCD diff).

6. Entrega progresiva: sobrecostes canarios con tráfico limitado.

7. Firma de artefactos (Cosign, certificación SLSA).

12) Observabilidad y depuración

Seguimiento de origen (Provenance): quién y cuándo aportó el campo, de qué capa procedía el valor final.
Visualización del merge: informe de las claves «ganadoras».
Runtime-exporta la configuración activa (endpoint '/config 'enmascarando secretos).
Alertas a la deriva: discrepancias entre lo declarado y lo real.

13) Anti-patrones

«Magia» sin reglas explícitas de prioridad.
Cadenas profundas (> 4-5 capas): aumentan la carga cognitiva.
Secretos en archivos heredados.
Redefiniciones ocultas a través de '--set' en CI.
Falta de esquema y pruebas de renderizado.

14) Lista de verificación de implementación

• Defina el modelo (jerarquía/capas/composición).
• Fije el orden del valor y las estrategias por tipo.
• Publique el diagrama y versionar.
• Separe los secretos (sólo referencias/refs).
• Agregue los controles de políticas y las firmas de artefactos.
• Incluya dry-run, diffs y visualización de origen.
• Asegúrese de exportar la configuración activa en el rantime.
• Configure las versiones progresivas para los cambios de configuración.

15) FAQ

P: ¿Cómo entender que la capa es demasiado profunda?
R: Si desea abrir> 3 archivos y «desplazarse»> 2 niveles de abstracción para cambiar el parámetro, revise la estructura.

P: ¿Qué hacer con las matrices en conflicto?
R: Introduzca estrategias explícitas: 'replace', 'append', 'uniqueBy (key)', 'patchBy (name)' - y fijarlas en la documentación.

P: ¿Es posible heredar secretos?
R: No. Sólo se heredan las referencias (URI/refs) a las políticas de almacenamiento secreto y acceso.

P: ¿Cómo probar la herencia?
R: Retire los «cortes» para las combinaciones de overlay clave y compruebe con archivos de oro; correr renderizado en CI para cada PR.

Anexo A: Mini Spec Merge

`scalars`: last-write-wins

'objects': deep-merge por claves

• 'replace' predeterminado

• `append`
• `uniqueBy(key)`
• 'patchBy (key)' con merjet recursivo de elementos

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

Anexo B: Ejemplos

B.1 Helm values (prod encima de 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

La prioridad del último archivo es 'valores. 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

1. un modelo claro y prioridades,

2. los esquemas de validación y los sobrecostes independientes,

3. renunciando a la herencia de secretos,

4. GitOps-pipeline con dry-run, policy-checks y diffs,

5. la observabilidad del origen de los valores totales.

Siguiendo estos principios, obtendrá configuraciones predecibles, escalables y seguras para cualquier entorno y topologías.