Konfiguracja jako dane

(Sekcja: Architektura i protokoły)

1) Pomysł i różnica od „konfiguracji jako kodu”

Konfiguracja jako dane (CaD) jest reprezentacją konfiguracji jako typowanego, deklaratywnego, zatwierdzonego modelu, niezależnego od kodu wykonywalnego i zarządzanego jako dane biznesowe: z wersjami, schematami, migracjami, audytami i testami.
W przeciwieństwie do „konfiguracji jako kodu”, gdzie logika generowania konfiguracji żyje w szablonach/skryptach, CaD wyklucza konieczność ze źródła prawdy: brak pętli, warunki i ukrytą logikę w konfiguracjach. Wszystkie - czyste dane + ścisły system + polityki.

Kluczowe cele: przewidywalność, możliwość różnicowania, zmiana bezpieczeństwa, szybkie rolki, zdolność do stopniowego i automatycznego kontrolowania zgodności.

2) Zasady „konfig jako dane”

1. Deklaratywność i jednoznaczność: opisujemy pożądany stan, a nie kroki osiągnięcia.
2. Bezpieczeństwo typu i systemy: JSON Schema/Protobuf/Avro/OpenAPI dla ścisłych umów.
3. Artefakt immutability: konfig strzały są wersjonowane i podpisane (pochodzenie).
4. Walidacja i polityka: w rurociągu - składnia → semantyka → policy-as-code (OPA, zasady).
5. Obserwowalność konfiguracji: odcisk palca w wersji w logach/metrykach/śladach.
6. Podział odpowiedzialności: dane (konfiguracja), schemat (umowa), polityka (ograniczenia), administrator (wdrożenie).
7. Modularność i warstwy: globalny, regionalny, najemnik-, produkt, poziomy funkcji, z przewidywalnym połączeniem i priorytetami.

3) Symulacja konfiguracji: Schemat jako kontrakt

Rodziny podmiotów: routing, limity, phicheflags, taryfy, segmenty AB, kontyngenty, zasady ryzyka, ustawienia finansowe itp.
Rodzaje: explicit enum/oneOf, ranges, regex, reference integrity (ref/ID).
Schemat wersji: 'v1 → v1beta2 → v2' (plan odrzucenia, migracje).
Default/Mutacja: bezpieczne domyślne na etapie walidacji; deterministyczny porządek stosowania.
Ograniczenia: ograniczenia biznesowe (na przykład, „ Limit <= 2000 rps” dla najemcy).

yaml apiVersion: config. example. io/v1 kind: RateLimitPolicy metadata:
scope: tenant:acme spec:
targets:
- service: checkout endpoint: /api/pay method: POST limit:
unit: second value: 500 burst: 200 strategy: tokenBucket

4) Warstwy, dziedzictwo i rozwiązywanie konfliktów

Иерардий: „globalny → region → środowisko → tenist → produkt → kohort → użytkownik”.
Zasady łączenia: deklaratywne - „ostatnia wygrana” (przekroczenie) lub strategiczne (połączenie/łata/wymiana na pole).
Walidacja na skrzyżowaniach: zabrania kolidujących kluczy, wymaga wyraźnego przekroczenia.
Konieczna jest wizualizacja ostatecznej skutecznej konfiguracji (dyfuzje deterministyczne).

5) Cykl życia konfiguracji (paradygmat GitOps)

1. Źródło prawdy: repozytorium z danymi + schematy + zasady.

• kontrola składni (lint),
• walidacja zgodnie z systemem,
• kontrole/badania semantyczne,
• kod polityki (np. OPA/Rego),
• bezpieczne migracje (zob. § 7),
• podpisanie i publikacja migawki.
• 3. Promocja: PRs między katalogami 'dev/qa/staging/prod' or rings' ring-0/.../ring-N '.
• 4. Dostawa: kontrolerzy/operatorzy wyciągają świeże migawki, stosują cykl uzgodnienia.
• 5. Audyt i odwracalność: wszystkie zmiany są śledzone; rollback - cofnij migawkę commit/rollback.

6) Dostawa i dystrybucja konfiguracji

Statyczny (pull-on-start): załaduj migawkę na początku, uruchom ponownie, aby zaktualizować.
Dynamiczny (zegarek/strumień): etcd/Consul/ZooKeeper, Kubernetes API/CRD, zastrzeżony Config Service.
Protokoły: gRPC/REST z ETag/If-None-Match, long-survey/watch, snapshots + incremental diffusions.
Buforowanie: lokalne migawki z TTL i podpisem; zmiana atomowa (podwójne buforowanie).
Sekwencja: strong (leader/quorum) vs eventual (edge/IoT). Dla systemów krytycznych - kworum + RA.
Walcowanie globalne: według regionów/pierścieni (rozmieszczenie pierścieni), z ograniczeniem stref równoczesnych.

7) Migracja danych konfiguracyjnych

• Rozwiń: wprowadzamy nowe pola z domyślnymi przepisami, nie łamiąc konsumentów.
• Migrate: backfills/converters (migrant provider scripts, idempotence).
• Kontrakt: usunąć przestarzałe, gdy wszystkie sterowniki są na nowej wersji schematu.
• Zasada zgodności: stara logika rozumie nowe, nowe - stare w okresie przejściowym.

8) Polityka, zgodność i bezpieczeństwo

Kod polityki: Rego/Conftest/OPA Gatekeeper - zakazy niebezpiecznych wartości (na przykład „timeout = 0”, wyłączanie TLS, nieograniczone kwoty).
RBAC/ABAC: kto może zmienić sekcje i na których warstwach.
Cztery oczy dla segmentów wrażliwych (płatności/limity).
Sekrety: nie mamy wspólnych konfiguracji (KMS, Vault, SOPS), w konfiguracji - tylko linki/referencje.
Podpisy i zaufanie: weryfikacja dostaw (zaświadczeń), zakaz niezapisanych migawek.
Oczyszczanie: ochrona przed wtryskiem w szablony i podczas utylizacji.

9) Obserwowalność, SLO i zarządzanie ryzykiem

Tagi config w telemetrii: '{config _ digest, config_version, ring, scope}' w logach/metrykach/utworach.
Złote metryki karabinów konfiguracyjnych: czas aplikacji, wskaźnik sukcesu, liczba wałków, czas konsystencji.
Bramki podczas walcowania konfiguracje: jak dla kodu - kroki kanaryjskie i auto-stop dla degradacji SLO.
Dogfooting: kohorta wewnętrzna/beta najpierw.

10) Przeładowanie na gorąco, transakcyjność i bezpieczeństwo stosowania

Przełącznik atomowy: Nowa konfiguracja jest przygotowywana w pamięci → pojedynczy przełącznik atomowy.
Dry-run: zatwierdzamy i symulujemy aplikację (w tym konflikt pól/polityki).
Częściowa awaria: strategia „wszystko lub nic” dla powiązanych komponentów lub jasny opis degradacji.
Backoff/Retry: na błędzie aplikacji - bezpieczny rollback i powtarzać z wykładniczym opóźnieniem.

11) Ficheflags jako podzbiór konfiguracji

Ficheflags to dane konfiguracyjne o specjalnej polityce: ukierunkowanie segmentu, ograniczenia promienia włączenia, przełącznik zabójstw.
Wymagania: deterministyczne semantyka celowania, audyt, bezpieczne domyślne, kompatybilność wersji klient/serwer.

12) Narzędzia i media

Media: JSON/YAML/TOML/Protobuf/Avro (do dostarczania sieci - częściej Protobuf/JSON).
Render/skład: Kustomize/Helm/Jsonnet (jak generatory, ale wynik jest czyste dane).
Magazyny/autobusy: Git, rejestry OCI (jako artefakty), magazyny S3-compatible, etcd/Consul/KV.
Kontrolerzy: operatorzy własnościowi, agenci GitOps, dostawcy konfig Sidecar.
Polityka: OPA/Rego, mechanizmy podobne do Kyverno.

13) Listy kontrolne

Projekt

• Program jest pierwszy (JSON Schema/Proto), typy/ograniczenia/domyślne są opisane.
• Udokumentowano wersję schematu i migrację.
• Hierarchia warstw i strategia łączenia zdefiniowane i przetestowane.

Rurociąg

• Lint → schemat-validate → testy semantyczne → kontrola polityki → znak → opublikować.
• Sucha i skuteczna wizualizacja konfig dla recenzentów.
• Kanaryjskie walcowanie konfiguracji z automatycznymi bramami przez SLO.

Prod

• W dziennikach/metrykach znajduje się 'config _ digest'.
• Rolka konfiguracji - ten sam przycisk co depozyt kodu.
• Konfiguracje migawki/kopie zapasowe i historia audytu są dostępne i weryfikowane.

14) Częste anty-wzory

Konieczność w konfiguracji: warunki/skrypty/szablony z logiką nie są sprawdzone i nieprzewidywalne.
Wymieszaj sekrety i ustawienia udostępnione w jednym pliku/repozytorium.
Nieprzezroczyste połączenie: Nie jest jasne, skąd się wzięła dolna linia.

Brak schematu: „wszystko jest ważne”

Global Ring/Canary Darmowe edycje: Natychmiastowa degradacja dla wszystkich.
Dryf otoczenia: ręczne edycje w czasie przeszłym źródło prawdy.
Długie TTL w konfiguracji pamięci podręcznej bez wymuszonego wyłączonego mechanizmu.

15) Scenariusze (szkice)

A. Granice ruchu dostrajającego według regionów

1. PR wraz ze zmianami „ LimitPolicy” na „ring-0” (klienci wewnętrzni).
2. Schemat/polityka AutoChecks (2k rps ≤ limit).
3. Promocja na 'ring-1' (5% użytkowników), monitorowanie p95/poziom błędu.
4. Rozszerzenie do 'ring-N', naprawianie migawki, zamykanie zadania.

B. Aktualizacja harmonogramu taryfowego (ustawienia finansowe)

silna semantyka i polityka biznesowa: podwójny przegląd, dwustopniowa promocja, wejście w okno czasowe, audyt i możliwość natychmiastowego wstecznego.

C. Global payment fifflag konfig flag with kill-switch: targeting „pracownicy → beta → 10% → 100%”, automatyczne zatrzymanie, gdy udana stawka płatności spadnie poniżej progu.

16) Integracja z zero-przestoju i progresywna dostawa

Kanary Config są zsynchronizowane z pierścieniami uwalniania.
Kompatybilność wersji: najpierw pola rozszerzające, następnie kod, a następnie dokręcanie.
Konfiguracje cieni: równoległe obliczanie rozwiązań (na przykład ograniczenie) do porównania z walką.

17) Podsumowanie

Podejście konfiguracji jako danych przekształca ustawienia z niestabilnych plików w solidne modele domeny z jasnymi umowami, walidacją i zasadami. Jest to podstawa przewidywalnego walcowania, bezpiecznych eksperymentów i szybkiej reakcji na incydenty. Sformalizować systemy, oddzielne tajemnice, wdrożyć GitOps i kanaryjskie poochy konfiguracyjne - a konfiguracja przestanie być ryzykiem, stając się aktywem platformy zarządzanej.