Röviden: Nem a .tf fájlok okozzák a legtöbb fejfájást, hanem a state. A remote state, a lockolás és a workspace-stratégia dönti el, mennyire fájdalmas a csapatmunka.
A Terraform megígéri, hogy az infrastruktúra kódból reprodukálható lesz. A gyakorlatban azonban nem a konfigurációs fájlok okozzák a legtöbb fejfájást, hanem az a látszólag jelentéktelen állapotfájl (state), amiben a rendszer eltárolja, hogy szerinte mi van a valóságban. Ez a fájl a Terraform egyetlen forrása az igazságról, és amint többen dolgoznak ugyanazon a kódbázison, pontosan itt kezdődik a baj.
Miért olyan fontos a state?
A Terraform a state alapján tudja, mit hozott létre korábban, és mit kell módosítania vagy törölnie. Ha a state elveszik, sérül vagy elavul, a Terraform elveszíti a kapcsolatot a kód és a valóság között — és onnantól veszélyes műveleteket javasolhat, például újralétrehozni vagy törölni olyat, amit nem kellene. A state tehát nem melléktermék, hanem kritikus adat.
A remote state: az első és legfontosabb lépés
A leggyakoribb kezdő hiba, hogy a state a fejlesztő gépén, lokálisan él. Ez csapatmunkában katasztrófa: mindenkinek más a képe a valóságról, és egymás módosításait írják felül. Az első lépés mindig a közös, távoli (remote) state: egy megosztott, verziózott tárolóban, ahová mindenki ugyanahhoz az igazsághoz fér hozzá.
A lockolás: a párhuzamos írás ellen
Ha ketten egyszerre futtatnak módosítást ugyanazon a state-en, az korrupcióhoz vezethet. A megoldás a state-lockolás: amíg egy művelet fut, a state zárolva van, mások megvárják. Ez egyszerű, de kritikus védelem — remote state mellett általában együtt jár a tárolási megoldással. Lockolás nélkül a csapatmunka orosz rulett a state épségével.
A workspace- és felbontási stratégia
A másik nagy kérdés, hogy egyetlen hatalmas state-ben tartasz-e mindent, vagy felbontod. Az egyetlen óriási state veszélyes: minden művelet az egészet érinti, a lockolás mindenkit blokkol, és egy hiba nagy hatókörű. A jó gyakorlat a felbontás — környezetenként, komponensenként külön state —, hogy a változtatás hatóköre és kockázata kicsi maradjon.
- Bontsd a state-et logikai, lazán csatolt egységekre (környezet, réteg, komponens).
- Így egy művelet csak a saját hatókörét zárolja és érinti.
- A hibák hatóköre kisebb, a párhuzamos munka gördülékenyebb.
A state kézi módosításának veszélye
Van lehetőség a state kézi manipulálására, de ez éles fegyver. Csak akkor nyúlj hozzá, ha pontosan tudod, mit csinálsz, és lehetőleg mentés után. A rosszul végrehajtott kézi state-művelet könnyen elszakítja a kódot a valóságtól, és onnan a helyreállítás fájdalmas. A legtöbb esetben van biztonságosabb út, mint a state közvetlen szerkesztése.
A remote state és a lockolás
A state kezelésének első és legfontosabb lépése a közös, távoli (remote) state: egy megosztott, verziózott tárolóban, ahová mindenki ugyanahhoz az igazsághoz fér hozzá. A lokális, fejlesztő gépén élő state csapatmunkában katasztrófa — mindenkinek más a képe a valóságról. A remote state mellé kell a lockolás is: amíg egy művelet fut, a state zárolva van, mások megvárják. Lockolás nélkül a párhuzamos írás korrupcióhoz vezet.
Ez a két dolog — remote state és lockolás — a különbség a gördülékeny és a fájdalmas csapatmunka között. Nélkülük a state épsége orosz rulett.
A felbontási stratégia
A másik nagy kérdés, hogy egyetlen hatalmas state-ben tartasz-e mindent, vagy felbontod. Az egyetlen óriási state veszélyes: minden művelet az egészet érinti, a lockolás mindenkit blokkol, és egy hiba nagy hatókörű. A jó gyakorlat a felbontás — környezetenként, komponensenként külön state —, hogy a változtatás hatóköre és kockázata kicsi maradjon.
- Bontsd a state-et logikai, lazán csatolt egységekre.
- Így egy művelet csak a saját hatókörét zárolja és érinti.
- A hibák hatóköre kisebb, a párhuzamos munka gördülékenyebb.
A kézi módosítás veszélye
Van lehetőség a state kézi manipulálására, de ez éles fegyver. Csak akkor nyúlj hozzá, ha pontosan tudod, mit csinálsz, és lehetőleg mentés után. A rosszul végrehajtott kézi state-művelet könnyen elszakítja a kódot a valóságtól, és onnan a helyreállítás fájdalmas. A legtöbb esetben van biztonságosabb út, mint a state közvetlen szerkesztése — a state a Terraform egyetlen forrása az igazságról, kezeld kritikus adatként.
Mit jelent ez neked?
A Terraformnál a state a valódi kockázat, nem a konfiguráció. Tedd a state-et közös, titkosított, verziózott remote tárolóba, kapcsold be a lockolást a párhuzamos írás ellen, és bontsd fel logikai egységekre, hogy a változtatások hatóköre kicsi maradjon. A state-et kezeld érzékeny, kritikus adatként, és a kézi módosítást tartsd végső eszköznek. Ha ezt a hármat rendben tartod, a csapatmunka gördülékeny lesz — ha nem, a state fogja elrontani a hetedet.