( 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.