DevOps

Terraform modulok, amiket nem bánsz meg fél év múlva

A jó modulhatár nem a DRY-elv, hanem a változás iránya mentén húzódik. Néhány józan szabály, amivel a Terraform-modulok segítenek, nem gátolnak fél év múlva.

Röviden: A jó modulhatár nem a DRY-elv, hanem a változás iránya mentén húzódik. Néhány józan szabály, amivel a Terraform-modulok segítenek, nem gátolnak fél év múlva.

A Terraform-modul csábító absztrakció: kiemelsz egy ismétlődő mintát, becsomagolod, és onnantól egyetlen helyen karbantartod. A gyakorlatban viszont a rosszul megvágott modulok több fájdalmat okoznak, mint amennyit megspórolnak. A tünet ismerős: minden apró változtatáshoz három modult kell módosítani, a változók száma elszabadul, és senki nem meri hozzányúlni a közös modulhoz, mert nem tudja, mit tör el vele.

A DRY tévút

A leggyakoribb hiba, hogy a modulhatárt a kódismétlés alapján húzzuk meg: „ezt a hat sort már kétszer leírtam, csináljunk belőle modult”. A DRY jó elv kódban, de az infrastruktúránál félrevezető. Két erőforrás lehet szintaktikailag hasonló, mégis teljesen külön okból, külön ütemben változik. Ha egy modulba kényszeríted őket, minden változtatásnál egymás lábára lépnek.

A jó határ: a változás iránya

A használható elv az, hogy azok az erőforrások tartoznak egy modulba, amelyek együtt, azonos okból változnak. Ha egy alkalmazás hálózati beállítása és a jogosultsága mindig együtt módosul, akkor egy modul. Ha a hálózat ritkán, a jogosultság gyakran változik, akkor inkább kettő. A kérdés nem az, hogy hasonlítanak-e, hanem hogy együtt mozognak-e.

Az interfész a modul valódi terméke

Egy modul értéke nem a benne lévő kódban van, hanem a felületében: milyen bemeneteket kér, mit ad vissza kimenetként, és mennyire stabil ez az interfész. A rossz modul mindent kivezet változóként — és így semmit nem absztrahál, csak áttol egy réteget. A jó modul kevés, értelmes bemenetet kér, józan alapértékekkel.

  1. Minimalizáld a kötelező bemeneteket; adj biztonságos alapértéket, ahol lehet.
  2. Adj vissza minden olyan kimenetet, amire a hívónak szüksége lehet — utólag hozzáadni könnyű, elvenni breaking change.
  3. Kezeld az interfészt szerződésként: a változtatása verziózott, tudatos döntés.

Verziózás és a blast radius

A megosztott modul azért ijesztő, mert egy módosítása egyszerre sok helyen csaphat be. Ezt két dolog oldja: a modulok verziózása (a hívók egy konkrét verzióra hivatkoznak, nem a mozgó fejre), és a hatókör tudatos szűkítése. Ha egy modul túl sok helyen használatos ahhoz, hogy bátran módosítsd, az jel: talán két külön felhasználási esetet zsúfoltál egybe.

Mikor NE csinálj modult?

Nem minden érdemel absztrakciót. Egy erőforrás, ami csak egy helyen létezik, és egyedi, nyugodtan maradhat sima kódként. A korai, spekulatív modularizáció — amikor „biztos, ami biztos” alapon mindent modulba teszel — pont azt a rugalmasságot öli meg, amiért az infrastruktúra kódban van. Előbb írd meg konkrétan, és csak akkor emeld ki modulba, amikor a második, valódi felhasználási eset megjelenik és tényleg hasonló mozgással bír.

A verziózás gyakorlata

A megosztott modulok verziózása nem opcionális, ha a csapatod nagyobb egy-két embernél. A hívók egy konkrét, rögzített verzióra hivatkozzanak, ne a modul mozgó fejére. Így egy modul módosítása nem söpör végig azonnal minden felhasználón — mindenki a maga tempójában, tudatosan frissít az új verzióra, miután meggyőződött róla, hogy nem tör el semmit.

Ez a gyakorlat teszi lehetővé a modulok biztonságos fejlesztését: kiadhatsz egy új verziót, a régi felhasználók háborítatlanul futnak tovább a régin, és a migráció ütemezhető, nem kényszerített.

A dokumentáció és a példák

Egy modul akkor használható igazán, ha van hozzá világos leírás: milyen bemeneteket vár, mit ad vissza, és egy-két konkrét használati példa. A dokumentálatlan modul, még ha technikailag jó is, olyan, mint egy zárt doboz — mindenki inkább újraírja, mint hogy kitalálja, hogyan kell használni. A jó példa gyakran többet ér, mint a részletes leírás.

A modulhierarchia veszélye

Amikor modulok modulokat hívnak, mély hierarchia alakulhat ki, ami átláthatatlanná válik: egy apró változtatás hatása több szinten át gyűrűzik, és nehéz követni, mi mit befolyásol. Tartsd a hierarchiát laposnak, ahol lehet. A túl sok absztrakciós réteg pont azt a kiszámíthatóságot öli meg, amiért az infrastruktúra kódban van. A jó modul segít; a rosszul rétegzett modulhalom gátol.

Mit jelent ez neked?

A Terraform-modult ne a kódismétlés, hanem a változás iránya alapján vágd meg: ami együtt változik, az tartozzon össze. Fektess energiát a modul felületébe, mert az a valódi terméke, és kezeld verziózott szerződésként. Ne modularizálj idő előtt — a konkrét, kicsit ismétlődő kód gyakran kevésbé fájdalmas, mint egy rosszul megvágott absztrakció, amit fél év múlva mindenki kerülget.