Eredità delle configurazioni

1) Perché è necessario ereditare le configurazioni

• Riutilizza i valori generali (logica, retrai, timeout).
• Condividi responsabilità: la piattaforma definisce le regole di base, i comandi di servizio solo le deviazioni.
• Evitare duplicazioni e ridurre il rischio di dissincronizzazione.
• Accelera le release: le modifiche predefinite vengono trasmesse in basso nella struttura.
• Mantenere il multi-ambiente e la multi-tenenza con un unico approccio.

2) Modelli di eredità

2. 1 Gerarchico (genitore)

Base (global) ambiente (prod/stage/uv), regione/cluster, servizio di istanza.
Semplice e trasparente, ma può portare a «catene profonde» e debug complessi.

2. 2 Strati (base/overlays)

Livello di base + insieme di overlay (feature-x, region-eu, security-hardening).
Ben combinato con GitOps e Kustomize; gli overlay sono indipendenti e compositi.

2. 3 Composizione (moduli/pacchetti)

La configurazione viene assemblata da «logging @ v2», «metrics @ v1», «http @ v3».
Gestione delle versioni dei moduli, compatibilità semantica, dipendenze evidenti.

2. 4 Criteri su valori (Policy-as-Code)

Limitatori e invarianti di base (OPA/Rego, Kyverno, Conftest).
Non ereditano i valori stessi, ma le regole di ammissibilità.

3) Algoritmi di fusione e priorità

1. Ordine delle sorgenti: da sinistra a destra (base)

• «Ultimo vincitore» (last-write-wins).
• Oggetto: Merge ricorsivo per chiave.

• `append`/`prepend`
• «uniqueBy (key)» (molti a chiave)
• «patch» (ricerca di un elemento per «name» e un murge parziale).
• 3. Chiavi riservate (ad esempio «_ merge: replace »/« _ merge: deep» a livello di nodo).

• Flag di avvio/V-variabili> Segreti Rent> File su disco> Valori predefiniti nel codice.

Esempio di 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) Schemi e convalida

Lo schema è una condizione obbligatoria per l'ereditarietà sicura.

JSON Schema/OpenAPI: tipi, campi obbligatori, enum, pattern, vincoli («minimo», «format», «patternProperties»).
Versioning diagrammi (semver) - Maggiore è il frammentario, minore è il nuovo campo, patch è il fisso.
Pre-merge e Post-merge convalida sia i frammenti che il risultato.
Default - Imposta a livello di schema (draft-07 + supporta default).

5) Ambienti e matrice di implementazione

• env: dev, test, stage, prod region: eu-central-1, us-east-1 tier: batch, realtime, internal tenant: A/B/C (white-label, B2B)
• Le combinazioni formano l'albero degli overlay; evitare la profondità eccessiva (3-4 livelli sono sufficienti).

6) Multi-tenenza

• Separazione rigida: file/cartelle separati per tenante.
• Parametrizzazione: un modello + values per tenant.
• Criteri ereditati: limiti di risorse/quote, SLO, rettifiche dei fogli.
• La cosa importante è che i limiti di sicurezza (segreti/chiavi) non devono passare tra i tenenti.

7) Segreti e sicurezza

Non ereditate i segreti in modo esplicito. Sono stati ereditati i riferimenti «secretRef», «vaultPath».
KMS/Vault/SOPRS - Memorizza i valori crittografati in Git, le chiavi sono fuori.
Condividi la responsabilità: la piattaforma gestisce percorsi e regole, il team del servizio è ciò di cui hai bisogno.
Regole: proibire i segreti «plaintext» nei controlli CI.
Rotation: non «sovrascrivere» - Usa alias/astrazioni ('db/primary/password @ 2025-Q4').

Esempio con riferimento 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) Versioning e migrazione

Le versioni dei moduli di configurazione sono "logging @ 2. 3. 1`.
Changelog per diagrammi: migrazione tramite jsonnet/ytt/script di custome.
Migrazioni bidirezionali (up/down) per un ripristino sicuro.
Lunghi rami: evitare la deriva; Riassorbire regolarmente gli overlay alla base.

9) Strumenti e pratiche

9. 1 Kubernetes

Kustomize (overlays) è un modello di eredità naturale tramite bases/resources, patchesStrategicMerge/ patchesJSON6902.
Helm (values) - Gerarchia "values. yaml '+' -set '(ma fai attenzione a ridefinire CI).
Kyverno/OPA: regole come «griglie di assicurazione».

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

9. 2 Terraform

Moduli + 'variabili. tf'come un contratto.
«locals» per i valori calcolati, «override» nessun file - utilizzare i livelli di directory e gli spazi di lavoro («workspkes»).
L'ordine di origine è il valore predefinito dei file <tfvars <'-var'/' -var-file'.

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

9. 3 Ansible

La gerarchia chiara delle variabili (per priorità crescente) è role defaults <inventory group _ vars <host _ vars <extra vars.
Per l'ereditario'group _ vars/{ env }/{ region} .yml '.

9. 4 Jsonnet / ytt

Ricca composizione, funzioni e «chiave-intento» ('overlay. replace`, `overlay. merge`).

10) Contratti e limiti di responsabilità

Piattaforma (platform team) - Definisce lo schema, i criteri, i valori di base, la logica di merge.
Comandi alimentari, solo overlay nel contratto.
SRE/Sicurezza: controllo, validazioni, firme, enforcement.

11) CI/CD и GitOps

1. Lint (formato, disabilitazione delle chiavi sconosciute).

2. Validate (JSON Schema/OpenAPI).

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

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

5. Diff contro il cluster di destinazione (kubectl ).

6. Progressive delivery - Overlay canari con traffico limitato.

7. Firma manufatti (Cosign, certificazione SLSA).

12) Osservabilità e debug

Traccia origine (provenance) - Chi e quando ha inserito il campo, da quale livello è arrivato il valore finale.
Visualizzazione del murge: il rapporto delle chiavi vincitrici.
Esporta runtime la configurazione attiva (endpoint'/config ').
Alert alla deriva, discrepanze tra dichiarati e fatti.

13) Anti-pattern

«Magia» senza regole esplicite di priorità.
Catene profonde (> 4-5 livelli) - Aumenta il carico cognitivo.
I segreti sono nei file ereditabili.
Ridefinizioni nascoste tramite --set in CI.
Nessun schema o test di rendering.

14) Assegno foglio di implementazione

• Definire il modello (gerarchia/livelli/composizione).
• Fissare l'ordine di merge e le strategie per tipo.
• Pubblicare lo schema e la versioning.
• Condividi i segreti (solo riferimenti/reef).
• Aggiungere policy-checks e firme di manufatti.
• Attivare dry-run, diffusioni e visualizzazione di origine.
• Consente di esportare la configurazione attiva in un rate.
• Impostare le release progressive per le modifiche config.

15) FAQ

Q: Come si capisce che lo strato è troppo profondo?
A: Se per modificare un parametro si desidera aprire> 3 file e scorrere> 2 livelli di astrazione, rivedere la struttura.

Q: Cosa fare con gli array in conflitto?
A: Inserisci le strategie esplicite: «replace», «append», «key», « (name)», e fissali nella documentazione.

Si possono ereditare i segreti?
A: No. Vengono ereditati solo i collegamenti (URI/Ref) al segreto-storage e ai criteri di accesso.

Q: Come testare l'eredità?
A: Taglia i tagli per le combinazioni chiave di overlay e controlla i file golden; corri il rendering in CI per ogni PR.

Allegato A: Mini-speck merja

`scalars`: last-write-wins

«objects»: deep-merge per chiavi

• predefinito'replace '

• `append`
• `uniqueBy(key)`
• «patchBy (key)» con un murge ricorsivo di elementi

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

Allegato B: Esempi

B.1 Helm values (prod sopra 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 priorità dell'ultimo file è '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

Riepilogo

1. modello e priorità chiari,

2. schemi validi e ori autonomi,

3. rifiuto di ereditare i segreti,

4. GitOps-pipline con dry-run, policy-checks e diffusi,

5. osservabilità dell'origine dei valori totali.

Questi principi consentono di ottenere configurazioni prevedibili, scalabili e sicure per qualsiasi ambiente e topologia.