Deklarativ konfiguration och miljödrift

Nordic vill uppgradera sitt standardpaket och en relaterad release. Git visar den nya önskade versionen. Helmfile diff ser rimlig ut. Apply avslutas utan fel. Är miljön nu korrekt konfigurerad?

Inte nödvändigtvis.

En deklaration kan ha renderats med fel default. Apply kan ha nått fel target. En controller kan legitimt ha ändrat ett runtimefält. En avstängd release kan ligga kvar. Ett post-check kan ha missat en del av populationen. Själva förändringen kan ha lyckats samtidigt som audit-eventet inte sparades.

Kapitlets kärnfråga är därför inte "ligger konfigurationen i Git?" utan:

Kan Matrix förklara hur en versionsbunden avsikt blev — eller inte blev — verifierad verklighet i rätt miljö?

1. Sex tillstånd, inte ett

Matrix deploymentmodell skiljer desired state från live state och drift (MATRIX-DEPLOYMENT-MODEL). För att göra själva förändringen granskningsbar behövs en ännu finare kedja:

1. Deklarerad: källfiler, paketbindning och policy uttrycker avsikt.
2. Renderad: defaults, overlays, templates och miljövärden har gett en effektiv konfiguration.
3. Planerad: skillnaden mot vald baslinje har beräknats och konsekvensbedömts.
4. Applicerad: ett försök har skickats till ett namngivet target och fått ett tekniskt utfall.
5. Observerad: runtime har lästs tillbaka vid en bestämd tid och identitet.
6. Verifierat konvergerad eller driftad: en versionsbunden predicate har jämfört normaliserat desired och live.

Varje steg är en egen claim (CLAIM-CONFIG-001). Ett Git-commit bevisar deklaration. Ett helmfile apply med exit 0 bevisar ett framgångsrikt applyförsök enligt verktygets kontrakt. Ett Ready-villkor bevisar ett runtimevillkor. Ingen av dem får ensam märkas "desired = live".

Figur FIG-09-01 visar hela kontrollslingan.

FIG-09-01 — Konfigurationens väg från deklaration till verifierad konvergens

Visa diagramdefinition

flowchart LR
    D[Deklarerad<br/>git, paket, miljövärden] --> R[Renderad<br/>effektiv konfiguration]
    R --> P[Planerad<br/>diff + konsekvens]
    P --> G{Godkänd<br/>för scope?}
    G -->|nej| X[Vägrad eller uppskjuten]
    G -->|ja| A[Applicerad<br/>försök + kvitto]
    A --> O[Observerad<br/>live state + tid]
    O --> N[Normaliserad jämförelse<br/>fältägare + ignorepolicy]
    N --> C{Verdict}
    C -->|converged| V[Verifierad konvergens]
    C -->|drift| F[Driftfinding<br/>ägare + risk + åtgärd]
    C -->|unknown| U[Samla evidens<br/>eller vägra beslut]
    F --> Q{Policy}
    Q -->|reconcile| RP[Nästa cykel:<br/>ny planerad diff]
    Q -->|accept| AD[Nästa baslinje:<br/>uppdaterad deklaration]
    Q -->|rollback| RB[Nytt rollback-intent<br/>till planering]
    V --> T[Övervaka förändring över tid]
    T --> NO[Nästa tidsbundna observation]

2. Effektiv konfiguration är en härledning

Konfiguration läses sällan från en enda fil. Matrix egen konfigurationsinventering visar en precedence med systemd drop-ins, processmiljö, TOML och koddefaults. Många variabler faller igenom till defaults, och vissa värden läses per anrop medan andra kräver restart (MATRIX-CONFIGURATION-ARCH).

Den effektiva konfigurationen kan därför skrivas:

effective = render(
  base,
  environment profile,
  tenant overlay,
  runtime injection,
  defaults,
  precedence rules,
  software version
)

En reproducerbar render bör bära:

input refs + immutable revisions/digests
renderer/tool version
precedence policy version
environment + tenant scope
resolved defaults
overlay operations
unresolved expressions
secret references, aldrig secretvärden
restart/reload requirement
rendered artifact digest

Om en parameter ändras i en ConfigMap som monteras via subPath kan poden behöva startas om. Samma textvärde får alltså olika operativ effekt beroende på reloadsemantik. "Filen är uppdaterad" säger inte "processen använder värdet" (CLAIM-CONFIG-002).

3. Bas, profil, overlay och runtime

En tydlig hierarki minskar både duplicering och oavsiktlig miljödrift:

produkt-/paketbas
  → gemensam plattformsprofil
    → miljöprofil
      → tenantoverlay
        → godkänd runtimeinjektion

Varje lager bör äga en bestämd sorts variation. Ett tenantlager ska inte behöva kopiera hela basen. Ett miljölager ska inte innehålla kunddata. Runtimeinjektion av secrets ska bära referens och version, inte hemligt värde i Matrix.

Precedence måste vara explicit. Två filer som sätter samma fält är inte automatiskt en konflikt om policyn anger att miljöprofilen får överstyra basen. Men om en manuell patch och en Helmrelease båda anser sig äga samma fält behövs en ägarkonflikt, inte bara "senaste värdet vann".

4. Miljön är en säkerhetsgräns

test, prod och demo är inte dekorativa etiketter. En förändring måste bindas till minst:

• stabil environment identity,
• cluster/account/subscription identity,
• namespace eller motsvarande scope,
• tenant,
• credential identity och mandat,
• expected endpoint/audience,
• tillåtet change window.

Matrix deployscript har en viktig hård regel: varje kubectl och Helmfile-anrop använder explicit kube context. Preflight jämför aktiv context med miljöns deklarerade target och vägrar mismatch (MATRIX-DEPLOY-RELEASE).

Detta är starkare än att lita på ett namespace som slutar på -prod. Namn kan vara fel, som den dokumenterade observationen av ett skillet-prod-namespace i testklustret visar. Miljöbevis kräver target identity och behörighetskontext, inte strängtolkning (CLAIM-CONFIG-004).

Samma princip gäller observation. En probe mot test får inte bevisa en proddefinition. Matrix PROVES-derivering parar redan miljö och hostname och vägrar bevis över miljögränser.

5. Vad betyder drift?

Den naiva definitionen är:

drift = desired != live

Den är för grov. Kubernetes lägger till defaults, status och metadata. Controllers ändrar replicas, certifikatstatus och andra fält med avsikt. Secret data kan rotera utan att referensen ändras. Listordning och genererade ID:n kan skapa byte-diff utan semantisk skillnad.

En användbar predicate är snarare:

drift = compare(
  normalize(desired, ownership, ignorePolicy),
  normalize(observed, ownership, ignorePolicy),
  scope,
  assessmentPolicyVersion
)

Resultatet bör klassificeras:

Drift är alltså en bedömning, inte en rå diff (CLAIM-CONFIG-003).

Samma princip gäller genererade paket före deployment. AppWorks-generatorn kontrollerar nu att IdentityPropertyId pekar på den Id/Id1-property som verkligen emitteras i samma building block och vägrar native-ID-modellen när pekaren annars skulle bli fantom-ID. Det flyttar ett runtimefel till en deterministisk buildinvariant. Äldre plain entities med historisk tom identitet är uttryckligen avgränsade och fortfarande teknisk skuld, inte tyst bevisade korrekta (MATRIX-APPWORKS-IDENTITY-EMISSION).

6. Fältägarskap

Kubernetes Server-Side Apply låter API-servern lagra vilka managers som äger vilka fält i metadata.managedFields. Ett apply som ändrar ett fält ägt av en annan manager kan ge konflikt om ändringen inte forceras (kubernetes-ssa).

Det är intressant för Matrix eftersom samma livevärde kan ha olika betydelse:

• replicas=5, ägt av HPA: förväntad divergence,
• replicas=5, manuellt patchat från en okänd manager: möjlig drift,
• replicas=5, överfört med godkänt ownershipbyte: ny desired baslinje.

Men managedFields är evidens, inte slutdom. Webhooks, äldre client-side apply, API-versioner och verktyg som använder update kan ge annan historik. RESEARCH-024 kräver därför en syntetisk pilot innan Matrix gör fältägarskap till kontrakt (CLAIM-CONFIG-008).

7. Matrix deklarerade deploymentgraf

Deploymentproducenten gör flera saker väl:

• miljöns egen Helmfile är auktoritativ och ordnad,
• prod får inte fantomnoder bara för att en katalog finns på disk,
• release, namespace, ingress och dependency får sourceRefs,
• EXPOSES citerar faktisk fil och rad som renderar hostname,
• olösliga templates blir varningar och får inte läcka in i ID:n,
• grafen passerar delad integrity gate.

Fem riktade tester låser dessa egenskaper (MATRIX-ENVIRONMENT-LAYER-GATE). De passerade 2026-08-11.

Men producenten är huvudsakligen en desired topology producer. Den läser Helmfile och values, inte Kubernetes live state. Den incheckade bunten mättes:

definition: 197
observation: 4
live: 0
drift: 0

De fyra observationerna är config-härledda cluster- och Key Vault-noder. En av dem har ID cluster:PROD-INFRA-EJ-UTRULLAD...: en values-platshållare som säger att prod inte är utrullad men ändå märks observation.

RESEARCH-022 är därför rekommenderad backlogkandidat. Values-härlett ska vara definition/desired; tidsatt runtimeintag ska ensam skapa observation/live. Det befintliga lagertestet är fortsatt värdefullt — det bevisar vilken deklaration som gäller, inte att deklarationen konvergerat.

8. Planen måste bli en artefakt

Deployscriptet bygger Helmfile, kör diff, frågar användaren och applicerar med include-needs. Det är en bra interaktiv sekvens. Men stdout-diffen är flyktig. För ett senare beslut behöver Matrix frysa:

changeId
scenario/intent
target identity
before desired revision
after desired revision
rendered digest
normalized plan/diff
affected objects and impactAssessment ref
prerequisite verdicts
approval identity, role, scope and expiry
createdAt

Planen ska vara content-addressed eller digestbunden till approval. Om konfigurationen renderas om efter godkännande måste apply vägras eller få ny approval. Annars godkändes A men B kördes.

Detta leder direkt till kapitel 10, där plan, mänsklig grind och verifierad handling behandlas mer generellt.

9. Apply är ett försök, inte ett slutläge

Matrix deployworkflow gör efter apply flera verklighetskontroller:

• väntar på förväntade workloads från Helmmanifestet,
• coverage-grindar saknade workloads,
• väntar på rollout,
• kontrollerar ingressadress, DNS och TLS,
• kör releasespecifika checks,
• skriver därefter DeploymentApplied.

Särskilt starkt är att förväntad workloadpopulation kommer från release- manifestet. Tidigare kunde noll labelträffar ge grön exit; nu blir okänd eller saknad population röd utan bokfört skäl (MATRIX-DEPLOY-RELEASE).

Men förändringskedjan är inte fullständig:

• planen sparas inte som Matrix-artefakt,
• startat applyförsök får inget eget beständigt event,
• misslyckade apply/post-checks får inget failure-event i denna väg,
• DeploymentApplied skrivs bara efter framgång,
• anropet till eventskrivaren avslutas med || true, så förändringen kan vara lyckad medan auditkvittot saknas.

Det sista ska inte nödvändigtvis rulla tillbaka en frisk deployment. Men systemet måste rapportera change succeeded, evidence persistence failed och skapa en separat röd auditfinding. Att låtsas att hela transaktionen misslyckats är lika fel som att dölja evidensluckan (CLAIM-CONFIG-006).

RESEARCH-023 provar en beständig state machine:

planned → approved → apply-started → applied|failed
        → verification-started → verified|verification-failed
        → rolled-back|accepted-with-deviation

10. Immutabel standard och separat overlay

Nordic-fallet har tre deklarativa parter:

• standardpaket version 1.0.0,
• ny standardversion 1.1.0,
• kundens overlay mot 1.0.0.

Paketgrinden förbjuder omskrivning av redan släppta versionskataloger och täckningskontrollerar strukturen (MATRIX-PACKAGE-IMMUTABILITY). Dess selftest passerade sju mutationer 2026-08-11. Ny funktionalitet får en ny version i stället för att historiken skrivs om.

Uppgraderingsanalysen gör en reproducerbar trevägsjämförelse över hela unionen:

standard vN ∪ standard vN+1 ∪ customer overlay

Varje objekt klassas clean, conflict, customer-only, unchanged eller unknown. För Nordic ger pilotrapporten 108 bedömda objekt, två konflikter och noll ohanterade. Testsviten har 20 gröna tester (MATRIX-PACKAGE-UPGRADE).

Detta är stark deklarativ förändringsanalys, men fortfarande ingen liveverifiering. Efter apply måste Matrix bevisa att rätt paketbindning och rätt overlay faktiskt används i rätt tenant och miljö (CLAIM-CONFIG-005).

11. Avstängt är inte avinstallerat

Driftloggen för Komodor visar ett viktigt felmönster: values deklarerade enabled=false, men en äldre secrets-release fanns kvar live. Helmfile tar inte automatiskt bort allt som blivit installed: false om rätt apply/destroy-väg inte körs.

Detta ger fyra separata claims:

1. flaggan är av i desired,
2. planen avser borttagning eller ignorerar releasen,
3. apply/destroy utfördes,
4. liveobservation visar att release och ägda resurser är borta.

Endast det fjärde kan verifiera konvergens. En driftvy bör därför göra orphan-live och missing-live till förstaklassresultat, inte bara jämföra värden på objekt som finns på båda sidor.

12. Ska drift korrigeras automatiskt?

OpenGitOps definierar fyra principer: desired state är deklarativt, versionsbundet och immutabelt, hämtas automatiskt och reconcileras kontinuerligt (opengitops100). De första tre passar stora delar av Matrix. Den fjärde är ett separat autonomibeslut.

Matrix kanon förbjuder Argo CD och föredrar explicit deploykontroll. Non-goals säger dessutom att Matrix inte är deploymentmotor. Det betyder inte att drift ska ignoreras. Det betyder att reconciliation kan delas:

Kontinuerlig observation och automatisk finding är inte samma sak som automatisk apply. Matrix tillförlitlighetsgradient bör styra autonomin (CLAIM-CONFIG-007). RESEARCH-025 bedömer GitOps-principerna var för sig i stället för att smuggla in ett verktygsbeslut.

13. Funktioner och use cases

Ett framtida gränssnitt för konfiguration och drift bör stödja följande kompletta funktionsfall.

UC9.1 — Visa effektiv konfiguration

En operatör väljer resurs, tenant och miljö. Matrix visar bas, profiler, overlays, resolved defaults, källa per fält, secret references och om restart krävs. Hemliga värden visas aldrig.

UC9.2 — Jämför miljöer

En arkitekt jämför test och prod per semantiskt fält. Matrix skiljer avsiktlig miljövariation, placeholder, saknad konfiguration och otillåtet scope. Jämförelsen är inte ett bevis på live state.

UC9.3 — Förhandsvisa förändring

En release manager väljer två revisionslås. Matrix renderar båda, visar normaliserad diff, dependency impact, overlaykonflikter, prerequisites och rollbackförutsättningar. Planen får stabil ID och digest.

UC9.4 — Verifiera target och godkänna

Beslutsfattaren ser environment/cluster/tenant identity, change digest, risk, tidfönster och vem som ska verkställa. Approval gäller exakt denna plan och förfaller om planen eller target ändras.

UC9.5 — Följ apply

Operatören ser started, current step, target, actor, tool version, partial effects och failure. UI skiljer runtimeutfall från om auditkvittot kunde persisteras.

UC9.6 — Verifiera konvergens

Efter apply läser Matrix tillbaka hela förväntade populationen och relevanta fält. Resultatet blir converged, pending, missing-live, orphan-live, drift, unknown eller refused med tidsatt evidens.

UC9.7 — Förklara drift

För en skillnad visar Matrix desired source, live source, fältägare, first seen, last seen, freshness, ignore/normalizationregel, påverkan och möjliga orsaker.

UC9.8 — Hantera drift

Ägaren väljer reconcile, acceptera som ny baslinje, tidsbegränsad avvikelse, rollback eller mer evidens. Varje val skapar en ny claim; historik skrivs inte över.

UC9.9 — Hantera standard och kundoverlay

En lösningsarkitekt jämför standard vN, vN+1 och tenantoverlay. Matrix visar clean/conflict/customer-only/unchanged/unknown och kräver beslut per konflikt innan ny binding kan föreslås.

UC9.10 — Återställ och verifiera

Vid fel väljs en verkligt applicerad tidigare version, inte en dry-run. Matrix visar data-/schemakompatibilitet, rollbackplan, approval, applykvitto och read-back.

UC9.11 — Granska flotta

En behörig fleetoperatör ser konfigurationsversioner och drift per tillåten tenant, inklusive saknade/stale manifest. Counts beräknas efter tenantfilter.

UC9.12 — Matrix granskar sig självt

Matrix visar effektiv coordinator-, agent-, modell-, timer- och gatewaykonfiguration, reloadsemantik samt skillnaden mot observerad process. Samma unknown- och evidensregler gäller det egna kontrollplanet.

14. Gränssnittshierarki

SCREEN-09-01 visar Design Studio efter F39-revisionen. Bilden skiljer den landade profil→manifest→blueprint→dry-run-kedjan från den ännu konceptuella scenarioportföljen, miljöobservationen och rollbacken.

SCREEN-09-01 — Design Studio med landad F39-kedja och markerad produktmålbild. Landad/dry-run-verifierad F39 blandas inte med konceptuell scenarioportfölj eller liveeffekt.

En bra konfigurationsyta börjar med beslut, inte YAML.

1. Portfolio: miljöer och tenants med converged/drift/unknown/refused, coverage och senaste observation.
2. Environment: desired revision, live snapshot, pågående changes, driftkategorier och avsiktliga avvikelser.
3. Change: scenario, plan, impact, approval, applytimeline, verifiering och rollback.
4. Resource: effektiv konfiguration per fält, precedence, ownership, desired/live-diff och evidens.
5. Package/overlay: versioner, härstamning, kundavvikelser och konflikter.
6. Audit: immutable events, findings, missing evidence och supersessions.

Rå YAML, Helmmanifest och logs är drill-down. Sammanfattningen ska först säga vad som avsågs, vad som observerades, om jämförelsen är komplett och vem som äger nästa beslut.

15. Nordic som full change loop

Nordics förändring kan genomföras som en evidensbevarande kedja:

1. Lås standard 1.0.0, 1.1.0 och tenantoverlay.
2. Kör trevägsanalys; lös de två konflikterna explicit.
3. Skapa ny desired binding utan att skriva om 1.0.0.
4. Rendera testmiljön med versionsbundna inputs och redovisa defaults.
5. Lås plan-digest och impactbedömning.
6. Verifiera kube context, tenant och credentialmandat.
7. Godkänn exakt plan och target.
8. Skriv apply-start, kör förändringen och spara utfall även vid fel.
9. Observera förväntad population och fältägarskap.
10. Klassificera live skillnader, inklusive kvarlämnad disabled release.
11. Verifiera paketbindning, flöde och kundoverlay.
12. Acceptera konvergens eller skapa ägd driftfinding/rollback.

Svaret "apply gick bra" ersätts av:

Plan change-42 för Nordic test, digest X, godkänd av roll Y, applicerades mot verifierat cluster Z. 37 av 37 förväntade workloads observerades. En HPA-ägd replicas-skillnad är förväntad. En disabled secrets-release finns kvar och klassas orphan-live. Paketbindningen 1.1.0 är verifierad, men miljön är inte fullt konvergerad förrän orphan-resursen hanterats.

Det är skillnaden mellan deploymentautomation och ett förklarande kontrollager.

Sammanfattning

• Deklarerad, renderad, planerad, applicerad, observerad och verifierad är skilda tillstånd.
• Effektiv konfiguration kräver precedence, defaults, scope och reloadsemantik.
• Miljöidentitet verifieras; namn och aktiv context antas inte.
• Drift kräver normalisering, coverage och fältägarskap.
• Desired-only och live-only objekt är lika viktiga som ändrade fält.
• Plan, failure, verification och rollback behöver beständiga artefakter.
• Immutabel standard plus separat overlay gör uppgradering reproducerbar.
• Kontinuerlig observation betyder inte automatiskt auto-apply.
• Matrix måste kunna redovisa sin egen effektiva konfiguration och drift med samma ärlighet som kundsystemens.