5 Kiro workflow, ami segíti az IaC fejlesztést

Az OpenTofu modulok előállításától és a dokumentációk elkészítésétől kezdve a tesztelés automatizálásáig az AI-alapú fejlesztői eszközök egyre fontosabb szerepet töltenek be az Infrastructure as Code világában. Ahhoz azonban, hogy valódi értéket teremtsenek, nem elegendő néhány ügyesen megfogalmazott prompt. Jól felépített folyamatokra és konzisztens struktúrára van szükség.

Ebben a cikkben öt gyakorlati eszközt és folyamatot mutatunk be, amelyek segítségével a Kiro hatékonyan integrálható a mindennapi IaC fejlesztésbe. Legyen szó egy új projekt felépítéséről, OpenTofu modulok generálásáról vagy névkonvenciók betartásáról egy többfiókos landing zone környezetben, ezek a módszerek segítenek abban, hogy többet hozhass ki a Kiro-ból, miközben a kódod tiszta, jól dokumentált és hosszú távon is karbantartható marad.

Kiro alapfogalmak

A Kiro egy AWS által fejlesztett, mesterséges intelligenciával támogatott IDE, amely jóval többet nyújt az egyszerű kódgenerálásnál. A steering file-ok, hook-ok, specifikációk (specs) és skill-ek segítségével egy olyan rendszert ad, amellyel egyedi fejlesztési szabványok alakíthatók ki, automatizálhatók az ismétlődő feladatok és végig biztosítható a konzisztencia az infrastruktúrakód teljes életciklusa során.

Kiro szolgáltatások összehasonlítása

Az ebben a cikkben ismertetett tippeken felül ezt a nyilvános skill-t az AWS API és a Terragrunt Docs MCP szerverekkel együtt használjuk.

1. A projekt vázának felhúzása

Egy új IaC projekt indítása általában mindig ugyanazoknak az alapfájloknak a másolgatásával kezdődik: mappastruktúra, gyökérkonfigurációk, CI pipeline-ok és pre-commit hookok. Ez önmagában nem bonyolult feladat, viszont időigényes, monoton, és ha manuálisan végezzük, könnyű is hibázni benne.

Ennek megoldására egy felhasználói szintű (user-level) steering fájlt használunk. Az ilyen steering fájlok a ~/.kiro/steering/ könyvtárban találhatók, és minden workspace-re érvényesek, nemcsak egyetlen projektre. A mi konfigurációnk olyan utasításokat tartalmaz, amelyek egy helyi sablonkönyvtárra irányítják a Kirót, ahol a szabványos projektszerkezetünk található.

Amikor megnyitunk egy új workspace-t és megkérjük a Kirót a projekt inicializálására, az beolvassa a steering fájlt, átmásolja a szükséges fájlokat a sablonkönyvtárból, majd automatikusan létrehozza a teljes projektvázat. A mappastruktúra, a mise.toml, a root.hcl, a project.hcl, a GitHub Actions workflow-k és a pre-commit konfigurációk egyetlen lépésben kerülnek a helyükre, már a kezdetektől követve a konvenciókat.

Ennek legnagyobb előnye a következetesség. Minden új projekt ugyanarról az alapokról indul, és nem kell fejben tartani, hogy mely fájlokat kell átmásolni vagy mely értékeket kell módosítani. Ha időközben változik a projekt-sablonunk, elegendő azt egy helyen frissíteni, és minden jövőbeli projekt automatikusan az új verzióval indul.

2. OpenTofu modul generálás

A legtöbb esetben, amikor egy projekthez új infrastruktúrát építünk ki, szívesen támaszkodunk már meglévő, nyilvános modulokra. Így nem kell saját modulokat fejlesztenünk és karbantartanunk, hanem olyan megoldásokra építhetünk, amelyek már bizonyítottak éles környezetben.

Vannak azonban olyan esetek, amikor jelentős testreszabásra és speciális erőforrásokra van szükség. Ilyenkor egyedi modult adunk hozzá az infrastruktúránkhoz. Az OpenTofu-modulok létrehozása viszonylag egyszerű és ismétlődő feladat, ezért ideális jelölt a mesterséges intelligenciával támogatott automatizálásra. Ahelyett, hogy manuálisan készítenénk el a modulstruktúrát, a változókat, a kimeneteket, a dokumentációt és a teszteket, a Kiro segítségével automatizálhatjuk a sablonjellegű részeket, és a figyelmünket azokra a részletekre fordíthatjuk, amelyek épp az adott projekt szempontjából fontosak és egyediek.

A folyamat megbízhatóbbá tétele érdekében két komponenst vezettünk be:

1. Kiro steering file, amely tartalmazza az összes irányelvet és konvenciót

Bár a Skill, amit alkalmazunk, már magában foglalja az IaC fejlesztéséhez kapcsolódó best practice-eket, fenntartunk egy külön steering file-t is, ami a saját követelményeit és szabványait definiálja. Ez biztosítja, hogy a generált kód ne csak az általános IaC-ajánlásoknak feleljen meg, hanem a belső szabványainknak, elnevezési konvencióinknak és architekturális irányelveinknek is.

2. Kiro hook a folyamat gyors indításához

Ez az egyedi hook úgy van konfigurálva, hogy csak manuális indításkor fusson le. Ahelyett, hogy egy hosszú és részletes promptot tartalmazna, a steering file-ban meghatározott konvenciókra hivatkozik. Ennek az az előnye, hogy a hook karbantartása egyszerűbbé válik: a kódolási szabványok vagy projektkövetelmények változásait csak egyetlen helyen kell frissíteni. Emellett biztosítja, hogy az ellenőrzések mindig a legfrissebb irányelvekkel legyenek összhangban, anélkül, hogy magát a hookot módosítani kellene.

Kiro steering:

Kiro hook:

3. Konveniciók kialakítása

Ahogy egy projekt növekszik, egyre nehezebb fenntartani a konvenciók következetességét. A Kiro segítségével ezeket a konvenciókat is tárolhatjuk közvetlenül steering file-okban. A Kiro arra is képes, hogy elemezzen egy meglévő kódbázist és kinyerje belőle a megfelelő szabályokat. Megvizsgálja a már használt mintákat, például a változók elnevezését, a tag-struktúrákat és a modulok felépítését, majd ezekből egy Markdown dokumentumot készít, amely szabályként rögzíti őket.

Íme néhány jó részlet példaként:

Projekt struktúrára vonatkozó konvenciók:

Terragrunt konvenciók:

4. Ellenőrzés

Korábban a legjobb gyakorlatok ellenőrzését általában külső eszközök, például a checkov vagy a tfsec végezték. Természetesen ezek használatát nem hagytuk el. Továbbra is megbízható eszközök lokális használatra és CI-folyamatokba egyaránt. Ugyanakkor most már a Kiro képességeit is kihasználjuk.

Például úgy, hogy hook-okat hoztunk létre. Amikor egy OpenTofu vagy Terragrunt fájlt módosítunk, a hook megkéri az agentet, hogy vizsgálja át a változtatásokat az ismert bevált gyakorlatok alapján. Ez olyan dolgokat foglal magában, mint például:

• hiányzó titkosítási beállítások storage erőforrásoknál
• túlzottan megengedő IAM policy-k
• megfelelő tagelés nélküli erőforrások
• túlságosan nyitott ingress szabályok security groupoknál
• hiányzó lifecycle policy-k vagy backup konfigurációk

A hookok egy askAgent műveletet használnak, amely egy prompton keresztül hivatkozik a steering file-jainkra és a Terraform skillre. Ez nem helyettesíti a CI-ben futó valódi security scanereket, de segít időben kiszűrni a nyilvánvaló hibákat, és megakadályozza, hogy olyan kód kerüljön commitálásra, amit később javítani kellene.

Az alábbi egy egyszerű példa. Ez a hook minden mentéskor automatikusan ellenőrzi a fájlokat a bevált gyakorlatok alapján:

A fentebbi példát aktív fejlesztés közben viszont nem ajánlott így alkalmazni, mert minden mentésnél lefut, és így túl sok tokent fogyaszt.

5. Dokumentáció

A dokumentáció az első dolog, ami elavul, amikor az infrastruktúra gyorsan változik. A modulok README-jei könnyen elavulnak, a változók leírásai nem követik a módosításokat, és az architekturális döntések gyakran csak valakinek a fejében maradnak meg.

A Kiro-t arra használjuk, hogy a dokumentációt szinkronban tartsuk a kóddal két megközelítés kombinálásával:

1. Először egy hook segítségével, amely akkor fut le, amikor a modul fájljai módosulnak. Amikor a main.tf, variables.tf vagy outputs.tf fájlok változnak, a hook automatikusan lefuttatja a terraform-docs-ot és újragenerálja a modul README-jét. Ez biztosítja, hogy a változók leírásai, típusai, alapértékei és kimenetei mindig naprakészek legyenek manuális beavatkozás nélkül.
2. Másodszor, a magasabb szintű dokumentációhoz közvetlenül az agentet használjuk. Egy jelentősebb módosítás után megkérjük a Kiro-t, hogy dokumentálja, mi történt és miért. Mivel a steering file-ok és az éppen módosított fájlok révén teljes kontextussal rendelkezik a kódbázisról, az így létrehozott dokumentáció nem általános sablon, hanem pontos és specifikus leírás.

A két megközelítés együtt biztosítja, hogy a dokumentáció mindkét szinten naprakész maradjon: a modulok technikai dokumentációja (ami automatikusan generálódik) és az emberi olvasásra szánt, magyarázó jellegű leírások (amelyek kontextus alapján készülnek).

Kérdésed van? Írj nekünk és mi segítünk megtalálni a számodra ideális megoldást.