Dziedziczenie konfiguracji

1) Dlaczego potrzebuję dziedziczenia konfiguracji?

• Ponowne użycie wspólnych wartości (rejestrowanie, przekłady, timeouts).
• Wspólna odpowiedzialność: platforma określa podstawowe zasady, polecenia serwisowe - tylko odchylenia.
• Unikać powielania i zmniejszyć ryzyko niewłaściwego uzgodnienia.
• Przyspieszenie zwolnień: Zmiany są nadawane w dół drzewa domyślnie.
• Obsługa wielu środowisk i wielozadaniowości przy użyciu jednego podejścia.

2) Wzory dziedziczenia

2. 1 hierarchiczny (rodzic → dziecko)

Base (global) → environment (prod/stage/dev) → region/cluster → service → instance.
Proste i przejrzyste, ale może prowadzić do głębokiego łańcucha i skomplikowanego debugowania.

2. 2 Warstwy (podstawy/nakładki)

Warstwa bazowa + zestaw nakładek (funkcja-x, region-eu, zabezpieczenie-utwardzanie).
Działa dobrze z GitOps i Kustomize; nakładki są niezależne i kompozycyjne.

2. 3 Kompozyt (moduły/pakiety)

Konfiguracja jest montowana z modułów: 'logging @ v2', 'metrics @ v1', 'http @ v3'.
Wersioning modułu, kompatybilność semantyczna, wyraźne zależności.

2. 4 Kodeks polityki

Podstawowe „ograniczniki” i niezmienne (OPA/Rego, Kyverno, Conftest).
Same wartości nie są odziedziczone, ale zasady ich dopuszczalności.

3) Algorytmy i priorytety łączenia przedsiębiorstw

1. Kolejność źródeł: od lewej do prawej (podstawa ← ← region ← service ← instance).

• Skalar: "last-write-wins'.
• Obiekt: rekursywne połączenie na klawiszy.

• „załączenie ”/„ prepend”
• „ujednolicone przez (klucz)” (ustawiane przez klucz)
• 'patch' (znajdź element według 'name' i częściowego połączenia).
• 3. Zarezerwowane klucze (na przykład '_ merge: replace '/' _ merge: deep' na poziomie węzła).

• Flagi uruchamiania/zmienne WP> sekrety runtime> pliki na dysku> wartości domyślne w kodzie.

Przykład połączenia 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) Systemy i walidacja

Obecność schematu jest warunkiem koniecznym bezpiecznego dziedziczenia.

Schemat JSON/OpenAPI: typy, wymagane pola, enum, wzory, ograniczenia ('minimum', 'format', 'patternProperties').
Schemat versioning (semver): major - breaking, minor - new fields, patch - fixes.
Kontrole przed połączeniem i po połączeniu: zatwierdzanie zarówno fragmentów, jak i wyników.
Domyślne: ustawione na poziomie schematu (projekt-07 + obsługuje 'domyślny').

5) Środowisko i matryca wdrożeniowa

• •: dev, test, etap, region prod: eu-central-1, us-east-1 tier: partia, czas rzeczywisty, lokator wewnętrzny: A/B/C (biała etykieta, B2B)
• Kombinacje tworzą drzewo nakładkowe; unikać nadmiernej głębokości (3-4 poziomy są wystarczające).

6) Wielopoziomowość

• Hard split: oddzielne pliki/foldery na najemcę.
• Parametryzacja: jeden szablon + wartości na najemcę.
• Odziedziczona polityka: limity zasobów/kwot, SLO, zatrzymywanie dzienników.
• Ważne: granice bezpieczeństwa (sekrety/klucze) nie powinny płynąć między najemcami.

7) Tajemnice i bezpieczeństwo

Nie dziedzicz tajemnic wprost. Odziedziczone odniesienia: „secretRef”, „vaultPath”.
KMS/Vault/SOPS: przechowywać zaszyfrowane wartości w Git, klawisze - out.
Podziel się odpowiedzialnością: platforma zarządza ścieżkami i polityką, zespół serwisowy - czego naprawdę potrzebujesz.
Zasady: zakazać tajemnic „zwykłego tekstu” w kontrolach CI.
Obrót: nie „nadpisywać” - używać aliasu/abstrakcji ('db/primary/password @ 2025-Q4').

Przykład łącza skarbca

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) Weryfikacja i migracja

Wersje modułu konfiguracyjnego: 'logging @ 2. 3. 1`.
Changelog dla schematów: migracje przy użyciu skryptów jsonnet/ytt/custom.
Migracje w górę/w dół dla bezpiecznego zwrotu.
Długie gałęzie: unikać dryfu; regularnie nakłada się na podłoże.

9) Narzędzia i praktyki

9. 1 Kubernety

Kustomize (nakładki): naturalny model dziedziczenia poprzez „podstawy ”/„ zasoby”, „pat, Merge ”/„ pat, JSON6902”.
Helm (wartości): hierarchia 'values. yaml '+' --set '(ale uważaj z nadjazdami w CI).
Kyverno/OPA: Politycy jako „sieci bezpieczeństwa”.

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

9. 2 Terraform

+ 'moduły zmiennych. tf "jako umowa.
"locals" dla wartości obliczeniowych, "override 'no files - use directory layers and workspaces (" workspaces ").
Porządek źródłowy: domyślnie <tfvars-files <'-var '/' -var-file'.

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

9. 3 Niedostępne

Wyraźna hierarchia zmiennych (w priorytecie wzrastania): domyślne role <inventory group_vars <host_vars <extra vars.
Dla dziedziczenia - struktura 'group _ vars/{ α }/{ region} .yml'.

9. 4 Jsonnet/yt

Bogaty skład, funkcje i „klucze-intencje” ('nakładka. zastąpić nakładkę „,”. połączenie ").

10) Kontrakty i limity baterii

Platforma team-Definiuje schemat, zasady, wartości bazowe i logikę połączenia.
Zespoły produktów: tylko nakładki w ramach umowy.
SRE/Bezpieczeństwo: audyt, walidacja, podpisy, egzekwowanie.

11) CI/CD - GitOps

1. Lint (format, zakaz używania nieznanych kluczy).

2. Validate (JSON Schema/OpenAPI).

3. Dry-run/Render (szablon helplate/kustomize build).

4. Kontrola zasad (OPA/Kyverno/Conftest).

5. Diff kontra klaster docelowy (kubectl diff/ArgoCD diff).

6. Stopniowa dostawa: nakładki kanaryjskie o ograniczonym natężeniu ruchu.

7. Podpis artefaktów (Cosign, zaświadczenie SLSA).

12) Obserwowalność i debugowanie

Ślad pochodzenia: kto przyczynił się do pola i kiedy, z której warstwy przyszła ostateczna wartość.
Wizualizacja scalenia: raport z „wygrywających” kluczy.
Runtime-export aktywnej konfiguracji (punkt końcowy '/config 'z tajnym maskowaniem).
Wpisy dryfujące: rozbieżności między deklarowanymi a rzeczywistymi.

13) Anty-wzory

„Magia” bez wyraźnych reguł pierwszeństwa.
Głębokie łańcuchy (> 4-5 warstw): zwiększają obciążenie poznawcze.
Sekrety w odziedziczonych aktach.
Ukryte przełącza przez '--set' w CI.
Brak schematu i testów renderingowych.

14) Lista kontrolna wdrażania

• Zdefiniuj model (hierarchia/warstwy/skład).
• Ustaw kolejność połączeń i strategie według typu.
• Opublikuj schemat i wersję.
• Udostępnianie tajemnic (tylko linki/refs).
• Dodawanie kontroli politycznych i podpisów artefaktowych.
• Umożliwia wizualizację suchego biegu, dyfuzów i pochodzenia.
• Eksport aktywnej konfiguracji w czasie trwania.
• Konfiguracja progresywnych wersji dla zmian konfiguracyjnych.

15) FAQ

P: Jak zrozumieć, że warstwa jest zbyt głęboka?
Odp.: Jeśli chcesz otworzyć> 3 pliki i „przewijać”> 2 poziomy abstrakcji, aby zmienić parametr, zmień strukturę.

P: Co zrobić z sprzecznymi tablicami?
Odp.: Wprowadź wyraźne strategie: „zastąpić”, „dodać”, „Jednoosobowo (klucz)”, „patchBy (nazwa)” - i naprawić je w dokumentacji.

P: Czy sekrety można odziedziczyć?
Odp.: Nie. Odziedziczone są tylko linki (URI/refs) do tajnych sklepów i zasady dostępu.

P: Jak przetestować dziedzictwo?
Odp.: Strzelaj „plasterkami” do kombinacji nakładek kluczy i sprawdź za pomocą złotych plików; renderowanie rasy w CI na PR.

Dodatek A: Połączenie mini Speck

„skalary”: ostatnie wygrane pisemne

„objects”: głębokie połączenie przez klucz

• domyślnie 'replace'

• „załącznik”
• „ujednolicone przez (klucz)”
• „patchBy (key)” z elementem rekursywnym łączyć

• '_ merge: zastąpić' deep'
• "_ strategia. tablica: zastąpić 'append' uniwłaśnie (nazwa) |patchBy (nazwa) "

Dodatek B: Przykłady

B.1 Wartości Helm (prod over 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

Priorytetem ostatniego pliku jest 'values. prod. yaml'.

B.2 Nakładki Kustomize

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 Zmienne kątowe

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

Podsumowanie

1. jasny model i priorytety,

2. systemy walidacji i niezależne nakładki,

3. odmowa odziedziczenia tajemnic,

4. Rurociąg GitOps z suchymi, kontrolami i dyfuzami,

5. obserwowalność pochodzenia wartości końcowych.

Stosując się do tych zasad, otrzymujesz przewidywalne, skalowalne i bezpieczne konfiguracje dla wszystkich środowisk i topologii.