( sinkog | 2025. 11. 16., v – 22:24 )

nézzük annyira nem bonyolult az egész viszont a végrelenségig lehet építeni szóval az.
Vannak a relay-ek ami adja a rendszer magját a kommunikációs ráteget és magát az OIS bizonyítási réteget (agy kicsit megkeverve a digitális aláírás). ezen a rétegen futtnak a modulok workflow leírások alapján. Maguk a moduloknak 3 fő funkciójuk van 1. set 2 get 3 notify azaz set: létrehoz beállít, get lekérdez notify: triggerel egy workflot mely mondjuk elindít egy lekérdezést ami felküldi a központba a változtást.

Maga a CIC azt teszi le az asztalra hogy amit felügyel annak az állapotát is ismeri, nem le tudja kérdezni hanem valahol mondjuk egy IaC state branch-en tárolva van... úgy hogy az elvárt állapotból (pl. IaC main branch) származtathatóés ezáltal a diffek egyszerűen detektálhatóak kezelhetőek benne és mivel minden IaC-ben pontosabban git alatt van ezért verziózott és dokumentáltá lehet tenni gyakorlatilag minimális erőforrás befektetéssel.

Igy az IaC state optimális esetben a kezelt obj-k azonosítóival kiegészülve érdemben egyenlő az IaC main adataival (mivel git azaz TXT ezért a sorrend is bejátszik....)