Hériter des configurations

1) Pourquoi faut-il hériter des configurations

• Réutiliser les valeurs communes (logging, retraits, temporisations).
• Partager la responsabilité : la plate-forme définit les politiques de base, les équipes de services ne définissent que les rejets.
• Évitez les doubles emplois et réduisez le risque de dissynchronisation.
• Accélérez les versions : les changements par défaut sont diffusés dans l'arbre.
• Maintenir les environnements multiples et la multitenance dans une approche unifiée.

2) Modèles d'héritage

2. 1 Hiérarchique (parent → enfant)

Base (global) → environnement (prod/stage/dev) → région/cluster → service → instance.
Simple et transparent, mais peut conduire à des « chaînes profondes » et des débogages complexes.

2. 2 Stratifiés (base/overlays)

Couche de base + jeu d'overleys (feature-x, region-eu, security-hardening).
Se combine bien avec GitOps et Kustomize ; les overleys sont indépendants et composites.

2. 3 Composites (modules/paquets)

La configuration est collectée à partir des modules : 'logging @ v2', 'metrics @ v1', 'http @ v3'.
Gestion des versions des modules, compatibilité sémantique, dépendances explicites.

2. 4 Politique au-dessus des valeurs (Policy-as-Code)

Les « limiteurs » de base et les invariants (OPA/Rego, Kyverno, Conftest).
Ce ne sont pas les valeurs elles-mêmes qui sont héritées, mais les règles de leur validité.

3) Algorithmes de fusion et priorités

1. Ordre des sources : de gauche à droite (base ← bou ← région ← service ← instance).

• Scalar : « le dernier a gagné ».
• Objet : merge récursive par clé.

• `append`/`prepend`
• 'UniqueBy (key) '(beaucoup par clé)
• 'patch' (recherche d'un élément par 'name' et merge partielle).
• 3. Clés réservées (par exemple, '_ merge : replace '/' _ merge : deep' au niveau du nœud).

• Flags de démarrage/LIV Values> Secrets de classement> Fichiers sur disque> Valeurs par défaut dans le code.

Exemple de 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) Schémas et validation

L'existence d'un système est une condition préalable à un héritage sûr.

JSON Schema/OpenAPI : types, champs obligatoires, enum, motifs, contraintes ('minimum', 'format', 'patternProperties').
Versioner les schémas (semver) : major - cassant, mineur - nouveaux champs, patch - fiches.
Vérification pré-merge et post-merge : valider à la fois les fragments et le résultat.
Défauts : définir au niveau du schéma (draft-07 + prend en charge 'default').

5) Environnement et matrice de déploiement

• env: dev, test, stage, prod region: eu-central-1, us-east-1 tier: batch, realtime, internal tenant: A/B/C (white-label, B2B)
• Les combinaisons forment un arbre overley ; éviter la profondeur excessive (3-4 niveaux suffisent).

6) Multi-ténacité

• Division rigide : fichiers/dossiers individuels en tenants.
• Paramétrage : un modèle + values per tenant.
• Politiques héritées : limites de ressources/quotas, SLO, rétentions de logs.
• Important : les limites de sécurité (secrets/clés) ne doivent pas s'écouler entre les tenants.

7) Secrets et sécurité

N'héritez pas explicitement de secrets. Les liens suivants sont hérités : 'secretRef', 'vaultPath'.
KMS/Vault/SOPS : Stockez les valeurs cryptées dans Git, les clés sont à l'extérieur.
Partagez la responsabilité : la plate-forme gère les chemins et les politiques, l'équipe de service est ce dont vous avez vraiment besoin.
Politiques : Interdiction des secrets 'platext' dans les vérifications CI.
Rotation : ne pas « écraser vers le bas » - utiliser alias/abstractions ('db/primary/password @ 2025-Q4').

Exemple avec lien 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 et migration

Versions des modules de configuration : 'logging @ 2. 3. 1`.
Changelog pour les schémas : migration avec jsonnet/ytt/scripts personnalisés.
Migration bidirectionnelle (up/down) pour un retour en arrière sécurisé.
Branches longues : éviter la dérive ; Rebaser régulièrement les overleys à la base.

9) Outils et pratiques

9. 1 Kubernetes

Kustomize (overlays) : modèle d'héritage naturel par 'bases '/' ressources', 'patchesStrategicMerge '/' patchesJSON6902'.
Helm (valeurs) : hiérarchie des valeurs. yaml '+' --set '(mais attention aux redéfinitions dans CI).
Kyverno/OPA : les politiques comme « filets de sécurité ».

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

9. 2 Terraform

Modules + 'variables. tf 'comme contrat.
'locals' pour les valeurs calculées, 'override' aucun fichier - utilisez les calques de répertoire et les espaces de travail ('workspaces').
Ordre des sources : valeurs par défaut <fichiers tfvars <'-var '/' -var-file'.

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

9. 3 Ansible

Hiérarchie claire des variables (priorité croissante) : role defaults <inventory group_vars <host_vars <extra vars.
Pour hériter, la structure 'group _ vars/{ bou} }/{ region} .yml'.

9. 4 Jsonnet / ytt

Composition riche, fonctions et « clé-intention » ('overlay. replace`, `overlay. merge`).

10) Contrats et limites de responsabilité

Plateforme (équipe platform) : définit le schéma, les politiques, les valeurs de base, la logique de merge.
Équipes de produits : seulement les overleys dans les limites du contrat.
SRE/Sécurité : audit, validation, signatures, enforcement.

11) CI/CD и GitOps

1. Lint (format, interdiction des clés inconnues).

2. Validate (JSON Schema/OpenAPI).

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

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

5. Diff contre le cluster cible (kubectl diff/ArgoCD diff).

6. Livraison progressive : Canaries à trafic limité.

7. Signature des artefacts (Cosign, certification SLSA).

12) Observabilité et débogage

Trace d'origine (provenance) : qui et quand a introduit le champ, de quelle couche est venue la valeur finale.
Visualisation de Merge : rapport des clés « gagnantes ».
Runtime-export de la configuration active (endpoint '/bou 'avec masquage des secrets).
Alerte à la dérive : écarts entre le déclaré et le réel.

13) Anti-modèles

« Magie » sans règles explicites de priorité.
Chaînes profondes (> 4-5 couches) : augmentent la charge cognitive.
Secrets dans les fichiers hérités.
Redéfinition masquée via '--set' dans CI.
Aucun schéma et aucun test de rendu.

14) Chèque de mise en œuvre

• Définir un modèle (hiérarchie/couches/composition).
• Fixez l'ordre de merge et la stratégie par type.
• Publiez le schéma et le versioning.
• Partagez les secrets (liens/refs uniquement).
• Ajoutez des policy-checks et des signatures d'artefacts.
• Inclure dry-run, diffamations et visualisation d'origine.
• Assurez-vous que la configuration active est exportée dans le rentim.
• Personnalisez les versions progressives pour les changements config.

15) FAQ

Q : Comment comprendre que la couche est trop profonde ?
R : Si vous devez ouvrir> 3 fichiers et « défiler »> 2 niveaux d'abstraction pour modifier le paramètre, révisez la structure.

Q : Que faire avec les tableaux en conflit ?
R : Entrez des stratégies explicites : 'replace', 'append', 'uniqueBy (key)', 'patchBy (name)' - et enregistrez-les dans la documentation.

Q : Est-il possible d'hériter de secrets ?
R : Non. Seuls les liens (URI/refs) vers le coffre-fort et les stratégies d'accès sont hérités.

Q : Comment tester l'héritage ?
R : Retirez les « tranches » pour les combinaisons clés d'overley et vérifiez les fichiers golden ; courez le rendu en CI pour chaque PR.

Annexe A : Mini-Specs Merge

`scalars`: last-write-wins

'Objects ': deep-merge par clés

• par défaut 'replace'

• `append`
• `uniqueBy(key)`
• 'PatchBy (key) 'avec un merge récursif d'éléments

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

Annexe B : Exemples

B.1 Helm values (prod top 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é du dernier fichier est '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

Résultats

1. d'un modèle et de priorités clairs,

2. par des systèmes de validation et d'autoverlay,

3. en renonçant à hériter des secrets,

4. GitOps-pipline avec dry-run, policy-checks et diffamations,

5. l'observation de l'origine des totaux.

En suivant ces principes, vous obtiendrez des configurations prévisibles, évolutives et sécurisées pour tous les environnements et topologies.