Miért nincs valódi állapotfogalom az IaC-ben? És mit old meg ebből a CIC?

Fejlesztés

Az IaC eredetileg azt ígérte, hogy a deklarált leírásból és a valós infrastruktúraállapotból meg lehet határozni az eltérést.
A gyakorlatban azonban ez sosem működött igazán — és ennek oka egyszerű: az IaC-ben valójában nincs állapotmodell.

A deklaráció szándék, de nem állapot.
A valós rendszer állapota pedig nem vezethető vissza egyetlen IaC-fájlra vagy futtatásra sem.

Nincs Intent → nincs State → nincs következetes összevetés → nincs determinisztikus következménykezelés.

És itt jön képbe a CIC (Central Infrastructure Core) szemlélet, ami nem YAML-ekkel vagy szkriptekkel akar harcolni, hanem logikai modellel:

  • Actor – ki teszi a változtatást
  • Intent – mit akar elérni
  • State – milyen állapotot hoz létre vagy módosít
  • Obligation – milyen kötelezettségeket generál
  • Consequence – milyen következménye lesz
  • ProofTrace – bizonyítható lánc minden lépésről

A CIC lényege nem az eszköz, hanem a relációs modell:
az elvárt állapot és a tényleges állapot logikailag összevethető, mert mindkettő formálisan létezik a modellben.

A Relay réteg pedig gondoskodik arról, hogy az állapot átadása determinisztikus legyen — nem pipeline, hanem állapotöröklés.

💬 Vitára fel:

  • Szerintetek az IaC miért nem tudja valójában összevetni az elvárt és a meglévő állapotot?
  • Terraform state valóban állapot, vagy csak „futtatásközi tároló”?
  • Van-e ma olyan eszköz, amely formális Intent-modellt használ?
  • Ti milyen problémába futottatok bele a „valós vs deklarált állapot” területen?

Ha van rá igény, hozok példát konkrét Intent–State–Consequence láncra a CIC-ből.

  • 130 megtekintés

( yetii | 2025. 11. 14., p – 08:42 )

Első körben definiálnod kellene, hogy számodra mit jelent az állítás, hogy "nincs állapotmodell". Ugyanis nyilvánvalóan a legelterjedtebb IaC solutionökben (terraform/tofu, pulumi, CloudFormation/CDK etc.) van, de úgy tűnik, hogy valamiért az nem felel meg a követelményeidnek.

Alapvetően 2 okból van szükség az állapotra egy IaC tool esetében:

  • mapping: a desired state config-ot (azaz a deklaratív leírása a rendszernek) valamilyen módon le kell mappelni arra, hogy valójában milyen fizikai (legalábbis ebben az értelemben fizikai, amúgy kb 48 réteg vírtualizáció fölött van :D ) resource-ot reprezentál. Ezt azért kell egy független "state"-be menteni, mert ha provider és cloud agnosztikusak akarunk lenni, akkor nem feltételezhetünk semmit arról mi a resource amit kezelünk, és hogy azt a resource-t bármiféle mapping nélkül hozzá tudjuk-e rendelni a desired state configunkban definiált resourcehoz, vagy hogy tudunk esetleg olyan metaadatot tárolni hozzá ami alapján ezt meg lehetne csinálni. Ellenpéldaként ott van az Ansible, ahol ezt pont megpróbálták, de az kicsit más rétegben dolgozik, és az én véleményem szerint pont ez az egyik oka, hogy elég nehézkes lett az egész egy idő után.
  • egyéb metadata tárolására, ami önmagában nem reprezentálódik az infrában, de segíti, hogy konzisztens és reprodukálható legyen egy infra. Pl passwordök, timestampek etc. generálása, ami megmarad futások között ha jól definiáljuk.

 

Szóval kíváncsi vagyok, hogy miért gondolod, hogy ez a megközelítés hibás, és nem egyszerűen a probléma komplex, ami miatt nehéz ezt helyesen kezelni, és más modell-re van szükség a jelenlegi általánosan elterjedttel szemben amit mondjuk a terraform használ.

( nagyjoco | 2025. 11. 14., p – 09:12 )

Stroustrup a C++ programozási nyelv című könyvében az absztrakt osztályokról szóló fejezet elehjén valami ilyesmi idézet szerepelt: 

"Ezek az osztályok nem absztraktak, ugyanolyan konkrétak, minn az int vagy a float."

Szerintem a Terrafrom state egy valódi állapot, de szívesen meghallgatom, szerinted miért nem az.

 

Ha tartós rendszert építesz és okos csapatot nevelsz, akkor száz kiadásban sem érheti baj; ha csak a gépekre hagyatkozol, akkor egyszer jól jársz, máskor rosszul; de ha sem a rendszer nem bírja a terhet, sem a csapat nem tanul a hibákból, akkor minden egyes kiadás kockázat.

Van ilyen is, meg olyan is:

  • Pl. Terraformnak van allapota, tud deltat kepezni. Pl. leirobol torolt dologbol tudja, hogy az mar nem kell, ezert torolni kell a rendszerrol.
  • Pl. Ansible-nek nincs allapota, mindig futas kozben korrigalja az elterest. Pl. leirobol torolt dolgot nem torol a rendszerrol, hiszen arrol mar nem tud.

Szoval ez nem altalanossagban az IaC hibaja, hanem az adott eszkoz implementacios dontesen mulik.

Igen, szeinrtem is van a Terraformank állapota, a topiknyitó szerint az nem "igazi" állapot, amit nem értek, mire alapoz.

Ha tartós rendszert építesz és okos csapatot nevelsz, akkor száz kiadásban sem érheti baj; ha csak a gépekre hagyatkozol, akkor egyszer jól jársz, máskor rosszul; de ha sem a rendszer nem bírja a terhet, sem a csapat nem tanul a hibákból, akkor minden egyes kiadás kockázat.