Vererbung von Konfigurationen

1) Warum müssen Konfigurationen vererbt werden

• Allgemeine Werte (Logging, Retrays, Timeouts) erneut verwenden.
• Verantwortung teilen: Die Plattform legt grundlegende Richtlinien fest, Service-Teams nur Abweichungen.
• Vermeiden Sie Doppelarbeit und verringern Sie das Risiko von Nicht-Synchronisierung.
• Releases beschleunigen: Änderungen werden standardmäßig im Baum nach unten übertragen.
• Pflegen Sie Multi-Umgebungen und Multi-Tenant mit einem einheitlichen Ansatz.

2) Vererbungsmodelle

2. 1 hierarchisch (Eltern → Kind)

Basis (global) → Umgebung (prod/stage/dev) → Region/Cluster → Service → Instances.
Einfach und transparent, kann aber zu „tiefen Ketten“ und komplexen Debugging führen.

2. 2 Geschichtet (base/overlays)

Basisschicht + Overlay-Set (feature-x, region-eu, security-hardening).
Passt gut zu GitOps und Kustomize; Overlays sind unabhängig und kompositorisch.

2. 3 Komposition (Module/Pakete)

Die Konfiguration wird aus den Modulen „logging @ v2“, „metrics @ v1“, „http @ v3“ zusammengestellt.
Versionierung von Modulen, semantische Kompatibilität, explizite Abhängigkeiten.

2. 4 Richtlinie über Werte (Policy-as-Code)

Grundlegende „Limiter“ und Invarianten (OPA/Rego, Kyverno, Conftest).
Nicht die Bedeutungen selbst werden vererbt, sondern die Regeln ihrer Zulässigkeit.

3) Fusionsalgorithmen und Prioritäten

1. Die Reihenfolge der Quellen: von links nach rechts (base ← env ← region ← service ← instance).

• Skalar: „der Letzte hat gewonnen“ (last-write-wins).
• Objekt: rekursive Schlüsselmerge.

• `append`/`prepend`
• 'uniqueBy (key)' (Menge nach Schlüssel)
• 'patch' (Suche nach einem Element durch 'name' und partielle Merge).
• 3. Reservierte Schlüssel (z.B.'_ merge: replace '/' _ merge: deep 'auf Knotenebene).

• Startflags/ENV-Variablen> Rantime-Geheimnisse> Dateien auf Festplatte> Standardwerte im Code.

Beispiel für 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) Schemata und Validierung

Das Vorhandensein eines Schemas ist eine Voraussetzung für eine sichere Vererbung.

JSON Schema/OpenAPI: Typen, Pflichtfelder, enum, Muster, Einschränkungen ('minimum', 'format', 'patternProperties').
Die Versionierung der Schemen (semver): major - break, minor - die neuen Felder, patch - die Fixe.
Pre-Merge und Post-Merge-Prüfungen: Validieren Sie sowohl die Fragmente als auch das Ergebnis.
Defaults: auf Schemaebene setzen (draft-07 + unterstützt 'default').

5) Umgebungen und Einsatzmatrix

• env: dev, test, stage, prod region: eu-central-1, us-east-1 tier: batch, realtime, internal tenant: A/B/C (white-label, B2B)
• Kombinationen bilden einen Overlay-Baum; Vermeiden Sie übermäßige Tiefe (3-4 Ebenen sind ausreichend).

6) Multi-Tenante

• Harte Trennung: einzelne Dateien/Ordner pro Tenant.
• Parametrierung: ein Muster + Werte pro Tenant.
• Geerbte Richtlinien: Ressourcenlimits/Kontingente, SLOs, Log-Retention.
• Wichtig: Die Sicherheitsgrenzen (Geheimnisse/Schlüssel) dürfen nicht zwischen den Tenanten fließen.

7) Geheimnisse und Sicherheit

Erben Sie Geheimnisse nicht explizit. Die Links werden vererbt: 'secretRef', 'vaultPath'.
KMS/Vault/SOPS: verschlüsselte Werte in Git speichern, Schlüssel raus.
Verantwortung teilen: Die Plattform managt Wege und Richtlinien, das Service-Team das, was wirklich gebraucht wird.
Richtlinien: Verbot von „plaintext“ -Geheimnissen bei CI-Kontrollen.
Rotation: nicht „überschreiben nach unten“ - verwenden Sie alias/Abstraktionen ('db/primary/password @ 2025-Q4').

Beispiel für einen Vault-Link

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) Versionierung und Migration

Versionen der Konfigurationsmodule: 'logging @ 2. 3. 1`.
Changelog für Schemas: Migrationen mit jsonnet/ytt/custom scripts.
Bidirektionale Migrationen (up/down) für sicheres Rollback.
Lange Äste: Driften vermeiden; regelmäßig die Overlays auf die Basis umbuchen.

9) Werkzeuge und Praktiken

9. 1 Kubernetes

Kustomize (overlays): natürliches Vererbungsmodell durch 'bases '/' resources', 'patchesStrategicMerge '/' patchesJSON6902'.
Helm (Werte): Hierarchie' Werte. yaml'+ '--set' (aber Vorsicht bei Überschreibungen in CI).
Kyverno/OPA: Politiker als „Sicherheitsnetze“.

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

9. 2 Terraform

Module + 'variables. tf 'als Vertrag.
'locals' für berechnete Werte, 'override' keine Dateien - verwenden Sie Verzeichnisebenen und Arbeitsbereiche ('workspaces').
Reihenfolge der Quellen: Standardwerte <tfvars-files <'-var '/' -var-file'.

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

9. 3 Ansible

Klare Hierarchie der Variablen (aufsteigende Priorität): role defaults <inventory group_vars <host_vars <extra vars.
Für die Vererbung ist die Struktur 'group _ vars/{ env }/{ region} .yml'.

9. 4 Jsonnet / ytt

Reiche Komposition, Funktionen und „Schlüssel-Absichten“ ('overlay. replace`, `overlay. merge`).

10) Verträge und Haftungsgrenzen

Plattform (Plattform-Team): Definiert Schema, Richtlinien, Basiswerte, Merge-Logik.
Produktteams: Nur Overlays innerhalb des Vertrages.
SRE/Sicherheit: Auditierung, Validierung, Signaturen, Durchsetzung.

11) CI/CD и GitOps

1. Lint (Format, Verbot unbekannter Schlüssel).

2. Validate (JSON Schema/OpenAPI).

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

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

5. Diff versus Ziel-Cluster (kubectl diff/ArgoCD diff).

6. Progressive Lieferung: kanarische Overlays mit begrenztem Verkehr.

7. Signatur von Artefakten (Cosign, SLSA-Bescheinigungen).

12) Beobachtbarkeit und Debugging

Provenienzverfolgung (Provenance): Wer wann das Feld eingetragen hat, aus welcher Schicht der endgültige Wert kam.
Visualisierung von Merge: Bericht der „siegreichen“ Schlüssel.
Laufzeitexport der aktiven Konfiguration (endpoint '/config 'mit Geheimmaskierung).
Drift Alerts: Diskrepanzen zwischen deklariert und tatsächlich.

13) Anti-Muster

„Magie“ ohne explizite Prioritätsregeln.
Tiefe Ketten (> 4-5 Schichten): erhöhen die kognitive Belastung.
Geheimnisse in vererbten Dateien.
Versteckte Überschreibungen durch '--set' in CI.
Kein Schema und keine Rendering-Tests.

14) Checkliste Umsetzung

• Modell definieren (Hierarchie/Ebenen/Komposition).
• Merge-Reihenfolge und Strategien nach Typ festlegen.
• Veröffentlichen Sie das Schema und die Versionierung.
• Teile die Geheimnisse (nur Links/Refs).
• Fügen Sie Policy-Checks und Artefakt-Signaturen hinzu.
• Aktivieren Sie Dry-Run, Diffuse und Herkunftsvisualisierung.
• Stellen Sie sicher, dass die aktive Konfiguration in der Rantime exportiert wird.
• Richten Sie progressive Releases für config-Änderungen ein.

15) FAQ

F: Woran erkenne ich, dass die Schicht zu tief ist?
A: Wenn Sie> 3 Dateien öffnen und> 2 Abstraktionsebenen „scrollen“ müssen, um den Parameter zu ändern, überprüfen Sie die Struktur.

F: Was tun mit kollidierenden Arrays?
A: Geben Sie explizite Strategien ein: 'replace', 'append', 'uniqueBy (key)', 'patchBy (name)' - und fixieren Sie sie in der Dokumentation.

F: Können Geheimnisse vererbt werden?
A: Nein. Nur Verweise (URIs/Refs) auf Secret Storage und Zugriffsrichtlinien werden vererbt.

F: Wie testet man Vererbung?
A: Entfernen Sie „Slices“ für Schlüsselüberlayerkombinationen und überprüfen Sie die Golden-Dateien; Rendering in CI für jede PR.

Anhang A: Mini-Speck Merja

`scalars`: last-write-wins

'Objekte': Deep-Merge durch Schlüssel

• Standard 'replace'

• `append`
• `uniqueBy(key)`
• 'patchBy (key)' mit rekursivem Element-Merge

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

Anhang B: Beispiele

B.1 Helm Werte (prod über Basis)

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

Die Priorität der letzten Datei ist '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

Ergebnisse

1. ein klares Modell und Prioritäten,

2. Validierungsschemata und unabhängige Overlays,

3. Verzicht auf die Vererbung von Geheimnissen,

4. GitOps-Pipeline mit Dry-Run, Policy-Checks und Diffs,

5. Beobachtung des Ursprungs der endgültigen Werte.

Nach diesen Prinzipien erhalten Sie berechenbare, skalierbare und sichere Konfigurationen für alle Umgebungen und Topologien.