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...
Pontosan ez az, amit a Terraform is csinál. Alapvetően a Terraform azt csinálja, hogy a "kódban" leírt vágyott állapotot lefordítja a konkrét providerre specifikusan (plan), ezt összenézi a tényleges beállításokkal, hogy össze tudja állítani az elvégzendő módosítások listáját. Amikor vége a módosításoknak, akkor az eredményül előálló állapotot rögzítjük egy terraform state fájlban, ez reprezentálja a felhőben levő állapotot.
Ez a state fájl szükségképpen csak annyira lesz teljes körű, amennyire a kiinduló IaC kód az volt. Ha az IaC csak RDS instance-ket hozott létre, mert az EC2 gépeket kézzel csináljuk (akármiért) akkor az EC2 -k nem lesznek benne, hiszen az IaC által kezelt infrának azok nem részei.
Egy ilyen IaC -nél azonban időnként mindenképpen le kell diffelni az elmentett state fájlt a tényleges állapotokkal, egyszerűen azért, mert bármilyen állapotmodell szükségképpen egy "fénykép" egy valamikori állapotról. Ha azóta bármi megváltozott, azt érzékelni és kezelni is kell tudni. Mindazonáltal, mindaddig, amíg nem akarunk operatívan beleavatkozni az infrastruktúrába, az állapotmodell alapján lehet tervezni, analizálni, stb.
Az Ansible esete azért tér el egy kicsit, mert neki már el kell tudnia kezelni az IaC-n kívülről jövő állapotváltozásokat is. És ez nem feltétlenül rossz dolog, vagy a rendszer ellen van. Pl, ha van egy auto-update folyamat, az elképzelhető, hogy kívülről, az Ansible kontextusától függetlenül módosítja a gép állapotát (frissít egy csomagot), így az állapot modell instant elavult lesz. Ez az IaC szempontjából egy szerencsétlen esemény, de az üzemeltetés szempontjából meg pont hogy kívánatos, hiszen az IaC -nak nem feladata a gép naprakészen tartása (secu szempontból).
Így az IaC state optimális esetben a kezelt obj-k azonosítóival kiegészülve érdemben egyenlő az IaC main adataival
Nem teljesen. Az IaC state az a legtöbb esetben nem provider-agnosztikus, hanem a tényleges állapotot tárolja le a tényleges provideren. Ha nekem van egy olyan IaC eszközöm, ahol le tudok definiálni mondjuk database, database_user, database_permission objektumokat, akkor a plan az lehet érdemben egyenlő az IaC main adataival, de a state már a tényleges állapotot kell tükrözze, ami viszont fel van gazdagítva a provider által lekérdezett adatokkal. Ebben az esetben a state tehát több lesz, mint ami az IaC main-ból egyenesen következne.
És így a végére engedj meg egy kis rantelést. Tök szép meg tök jó ötlet ez az IaC dolog, azonban az üzemeltetés egy nagyon gyakorlatias művészet, ahol a tényleges üzemeltetési igényekhez igazítunk minden elméleti cuccot. Ez azt jelenti, hogy nem szükségképpen fogjuk az eszközöket az ideális módon használni. Pl nekem most van egy infrám, ami most kerül be IaC alá, és utólag sakkozok a state-tel, meg ignorálok attributumokat, hogy az IaC ne bontsa el a meglevő node-okat, csak kreáljon újabbakat. Mert ez egy "legacy" cucc abban az értelemben, hogy maga az infra alapjai nem IaC -vel lettek elkezdve. Ez szembe megy egy csomó dologgal, ami az IaC elméletében le van fektetve, azonban nekem nem elméleti infrákat kell üzemeltetnem, hanem olyanokat, amik tényleges vason futnak. Így igenis elvárás egy IaC eszköztől, hogy képes legyen lekérdezni és figyelembe venni a tényleges, valódi állapotot is, és valamelyest képes legyen összevetni az IaC kódban megfogalmazott vágyott állapotokkal. Nem azért, mert az elmélet megköveteli, hanem mert a gyakorlatban van erre szükség.