Sokan ismerik és használják a Terraformot mindennapi munkájuk során, de a legjobb gyakorlatok még nem alakultak ki. Minden csapatnak saját megközelítést és módszert kell kitalálnia.
Az infrastruktúra szinte biztosan egyszerűnek indul: néhány erőforrás + néhány fejlesztő. Idővel mindenféle irányba növekszik. Találsz módot arra, hogy az erőforrásokat Terraform modulokba csoportosítsd, a kódot mappákba rendezd, és mi hibázhat még? (híres utolsó szavak)
Telik az idő, és úgy érzed, az infrastruktúra az új kedvenced, de miért? Aggódsz az infrastruktúra megmagyarázhatatlan változásai miatt, félsz hozzányúlni az infrastruktúrához és a kódhoz - ennek következtében késlelteted az új funkcionalitást vagy rontja a minőséget...
Miután három évig kezelte a Terraform közösségi modulok gyűjteményét az AWS-hez a Githubon, és a Terraform hosszú távú karbantartását követően, Anton Babenko készen áll arra, hogy megossza tapasztalatait: hogyan írjon TF-modulokat úgy, hogy a jövőben ne fájjon.
Az előadás végére a résztvevők jobban megismerik a Terraform erőforrás-kezelési elveit, a Terraform moduljaihoz kapcsolódó legjobb gyakorlatokat és néhány, az infrastruktúra kezeléséhez kapcsolódó folyamatos integrációs elveket.
Jogi nyilatkozat: Megjegyzem, hogy ez a jelentés 2018 novemberében készült – már 2 év telt el. A jelentésben tárgyalt Terraform 0.11 verzió már nem támogatott. Az elmúlt 2 év során 2 új kiadás jelent meg, melyek rengeteg újítást, fejlesztést, változást tartalmaznak. Kérjük, figyeljen erre, és ellenőrizze a dokumentációt.
referenciák:
- +
- — automatikus formázó kód és dokumentáció
- — Terraform modulok generátora (WIP)
- — Terraform kódgenerátor vizuális diagramokból (WIP)
- www.terraform-best-practices.com
- (Az új bejegyzések a személyes honlapomon, www.antonbabenko.com/)
- @antonbabenko - Twitter, és egy csomó különböző nadrág
A nevem Anton Babenko. Néhányan valószínűleg az általam írt kódot használták. Erről most nagyobb bizalommal fogok beszélni, mint valaha, mert hozzáférek a statisztikákhoz.
A Terraformon dolgozom, és 2015 óta aktív résztvevője és közreműködője vagyok számos Terraformhoz és Amazonhoz kapcsolódó nyílt forráskódú projektnek.
Azóta elég kódot írtam ahhoz, hogy érdekes módon fogalmazzam meg. És most megpróbálok erről mesélni.
A Terraformmal való munka bonyolultságáról és sajátosságairól fogok beszélni. De ez nem igazán a HighLoad témája. És most meg fogod érteni, hogy miért.
Idővel elkezdtem Terraform modulokat írni. A felhasználók kérdéseket írtak, én átírtam őket. Aztán különféle segédprogramokat írtam a kód formázásához egy előre véglegesítési horog segítségével stb.
Sok érdekes projekt volt. Szeretem a kódgenerálást, mert szeretem, ha a számítógép egyre több munkát végez nekem és a programozónak, ezért jelenleg egy Terraform kódgenerátoron dolgozom vizuális diagramokból. Talán néhányan látták őket. Ezek gyönyörű nyilakkal ellátott dobozok. És szerintem nagyszerű, ha rákattint az „Exportálás” gombra, és kódként megkapja az egészet.
Ukrajnából származom. Sok éve élek Norvégiában.
Ezenkívül a jelentéshez információkat olyan emberektől gyűjtöttünk, akik ismerik a nevemet, és megtalálnak a közösségi hálózatokon. Szinte mindig ugyanaz a becenevem.
Mint említettem, én vagyok a Terraform AWS modulok fő karbantartója, amely a GitHub egyik legnagyobb tárolója, ahol modulokat tárolunk a leggyakoribb feladatokhoz: VPC, Autoscaling, RDS.
És amit most hallottál, az a legalapvetőbb. Ha kétségei vannak abban, hogy megérti-e, mi az a Terraform, akkor jobb, ha máshol tölti az idejét. Sok szakkifejezés lesz itt. És nem haboztam a jelentés szintjét a legmagasabbnak nyilvánítani. Ez azt jelenti, hogy minden lehetséges kifejezést használva tudok beszélni különösebb magyarázat nélkül.
A Terraform 2014-ben jelent meg olyan segédprogramként, amely lehetővé tette az infrastruktúra kódként történő írását, tervezését és kezelését. A kulcsfogalom itt az „infrastruktúra mint kód”.
Minden dokumentáció, mint mondtam, be van írva . Remélem, hogy a legtöbben ismerik ezt az oldalt, és elolvasták a dokumentációt. Ha igen, akkor jó helyen jár.
Így néz ki egy hagyományos Terraform konfigurációs fájl, ahol először definiálunk néhány változót.
Ebben az esetben az "aws_region"-t definiáljuk.
Ezután leírjuk, milyen erőforrásokat szeretnénk létrehozni.
Futtatunk néhány parancsot, különösen a „terraform init”-t a függőségek és szolgáltatók betöltése érdekében.
És lefuttatjuk a „terraform apply” parancsot annak ellenőrzésére, hogy a megadott konfiguráció megfelel-e az általunk létrehozott erőforrásoknak. Mivel még nem hoztunk létre semmit, a Terraform arra kér bennünket, hogy hozzuk létre ezeket az erőforrásokat.
Ezt megerősítjük. Így létrehozunk egy tengeri csiga nevű vödröt.
Számos hasonló segédprogram is létezik. Az Amazont használók közül sokan ismerik az AWS CloudFormationt, a Google Cloud Deployment Managert vagy az Azure Resource Managert. Mindegyiknek megvan a saját megvalósítása az erőforrások kezelésére ezeken a nyilvános felhőszolgáltatókon belül. A Terraform különösen hasznos, mert lehetővé teszi több mint 100 szolgáltató kezelését. (További részletek )
A Terraform céljai a kezdetektől fogva:
- A Terraform egységes nézetet biztosít az erőforrásokról.
- Lehetővé teszi az összes modern platform támogatását.
- A Terraformot pedig a kezdetektől fogva olyan segédprogramnak tervezték, amely lehetővé teszi az infrastruktúra biztonságos és kiszámítható megváltoztatását.
2014-ben a „kiszámítható” szó nagyon szokatlanul hangzott ebben az összefüggésben.
A Terraform egy univerzális segédprogram. Ha rendelkezik API-val, akkor abszolút mindent vezérelhet:
- Több mint 120 szolgáltatót használhat minden kívánt kezeléséhez.
- A Terraform segítségével például leírhatja a GitHub-tárolókhoz való hozzáférést.
- Még hibákat is létrehozhat és bezárhat a Jira-ban.
- Kezelheti az új ereklye mérőszámait.
- Akár a dropboxban is létrehozhat fájlokat, ha igazán akar.
Mindezt Terraform szolgáltatók segítségével érik el, amelyek egy nyitott API-val rendelkeznek, amely a Go-ban leírható.
Tegyük fel, hogy elkezdtük használni a Terraformot, elolvastunk néhány dokumentációt az oldalon, megnéztünk egy videót, és elkezdtük írni a main.tf-et, ahogy az előző diákon is bemutattam.
És minden nagyszerű, van egy fájl, amely létrehoz egy VPC-t.
Ha VPC-t szeretne létrehozni, akkor körülbelül ezt a 12 sort adja meg. Írja le, hogy melyik régióban kíván létrehozni, melyik cidr_block IP-címet használja. Ez minden.
Természetesen a projekt fokozatosan növekedni fog.
És egy csomó új dolgot ad hozzá: erőforrásokat, adatforrásokat, új szolgáltatókkal fog integrálódni, hirtelen a Terraformot szeretné majd használni a felhasználók kezelésére a GitHub-fiókjában stb. Érdemes lehet mást is használni. DNS-szolgáltatók, kereszteznek mindent. A Terraform ezt megkönnyíti.
Nézzük a következő példát.
Fokozatosan adja hozzá az internet_gateway-t, mert azt szeretné, hogy a VPC erőforrásai internet-hozzáférést kapjanak. Ez egy jó ötlet.
Az eredmény ez a main.tf:
Ez a main.tf felső része.
Ez a main.tf alsó része.
Ezután hozzáadja az alhálózatot. Mire NAT-átjárókat, útvonalakat, útválasztási táblákat és egy csomó más alhálózatot szeretne hozzáadni, nem 38 sor lesz, hanem körülbelül 200-300 sor.
Vagyis a main.tf fájlod fokozatosan növekszik. És gyakran az emberek mindent egy fájlba helyeznek. 10-20 Kb jelenik meg a main.tf-ben. Képzeld el, hogy 10-20 Kb szöveges tartalom. És minden mindennel összefügg. Ezzel fokozatosan nehéz dolgozni. 10-20 Kb jó felhasználói eset, néha több is. És az emberek nem mindig gondolják, hogy ez rossz.
A hagyományos programozáshoz hasonlóan, azaz nem az infrastruktúra kódként, itt is megszoktuk, hogy egy csomó különböző osztályt, csomagot, modult, csoportosítást használunk. A Terraform lehetővé teszi, hogy nagyjából ugyanezt tegye.
- A kód növekszik.
- Az erőforrások közötti függőség is nő.
És nagy, nagy szükségünk van. Megértjük, hogy nem élhetünk így tovább. Kódunk egyre hatalmasabb. A 10-20 Kb persze nem túl nagy, de csak a hálózati veremről beszélünk, vagyis csak hálózati erőforrásokat adott hozzá. Nem az Application Load Balancerről, a telepítési ES-fürtről, a Kubernetesről stb. beszélünk, ahol 100 Kb könnyen beleszőthető. Ha mindezt leírja, hamarosan megtudhatja, hogy a Terraform Terraform modulokat kínál.
A Terraform modulok egy önálló Terraform konfiguráció, amelyet csoportként kezelnek. Ennyit kell tudni a Terraform modulokról. Egyáltalán nem okosak, nem teszik lehetővé, hogy valamitől függően bonyolult kapcsolatokat hozz létre. Mindez a fejlesztők vállára esik. Vagyis ez csak egyfajta Terraform konfiguráció, amit már írtál. És egyszerűen hívhatod csoportnak.
Tehát megpróbáljuk megérteni, hogyan optimalizáljuk a 10-20-30 Kb-os kódunkat. Fokozatosan felismerjük, hogy szükségünk van néhány modul használatára.
Az első típusú modulok, amelyekkel találkozunk, az erőforrásmodulok. Nem értik, miről szól az infrastruktúrája, miről szól a vállalkozása, hol és mik a feltételek. Pontosan ezeket a modulokat adminisztrálom a nyílt forráskódú közösséggel együtt, és amelyeket az Ön infrastruktúrájának legelső építőköveiként terjesztünk elő.
Példa egy erőforrás modulra.
Amikor egy erőforrás modult hívunk, megadjuk, hogy melyik útvonalról töltsük be a tartalmát.
Jelezzük, hogy melyik verziót szeretnénk letölteni.
Egy csomó érvet átadunk ott. Ez minden. Ez minden, amit tudnunk kell, amikor ezt a modult használjuk.
Sokan azt gondolják, hogy ha a legújabb verziót használják, akkor minden stabil lesz. De nem. Az infrastruktúrát verziószámmal kell ellátni, egyértelműen meg kell válaszolnunk, hogy ez vagy az a komponens melyik verzióra lett telepítve.
Itt van a kód, amely ebben a modulban található. Biztonsági csoport modul. Itt a tekercs a 640. sorig megy. Egy biztonsági csoport erőforrás létrehozása az Amazonban minden lehetséges konfigurációban nagyon nem triviális feladat. Nem elég egyszerűen létrehozni egy biztonsági csoportot, és megmondani neki, milyen szabályokat kell átadnia neki. Nagyon egyszerű lenne. Millió különböző korlátozás van az Amazonon belül. Például ha használ VPC végpont, előtaglista, különféle API-k és megpróbálja mindezt minden mással kombinálni, akkor a Terraform ezt nem engedi meg. És az Amazon API ezt sem teszi lehetővé. Ezért el kell rejtenünk ezt a szörnyű logikát egy modulban, és meg kell adnunk a felhasználói kódot, amely pont így néz ki.
A felhasználónak nem kell tudnia, hogyan készül belülről.
A második típusú modulok, amelyek erőforrás-modulokból állnak, már olyan problémákat oldanak meg, amelyek jobban alkalmazhatók az Ön vállalkozására. Gyakran ez egy olyan hely, amely a Terraform kiterjesztése, és merev értékeket állít be a címkék számára, a vállalati szabványokhoz. Olyan funkciókat is hozzáadhat ott, amelyek használatát a Terraform jelenleg nem teszi lehetővé. Ez most van. Most a 0.11-es verzió, amely hamarosan a múlté lesz. De ennek ellenére az előfeldolgozók, a jsonnet, a cookiecutter és egy csomó más dolog a segédmechanizmus, amelyet a teljes értékű munkához használni kell.
A következőkben erre mutatok néhány példát.
Az infrastruktúra modult pontosan ugyanígy hívják.
Fel van tüntetve a forrás, ahonnan a tartalom letölthető.
Egy csomó érték kerül átadásra és átadásra ebbe a modulba.
Ezután ezen a modulon belül egy csomó erőforrás-modult hívunk meg egy VPC vagy Application Load Balancer létrehozásához, vagy egy biztonsági csoport vagy egy Elastic Container Service fürt létrehozásához.
Kétféle modul létezik. Ezt azért fontos megérteni, mert a jelentésben csoportosított információk többsége nem szerepel a dokumentációban.
A Terraform dokumentációja pedig most elég problémás, mert csak azt írja, hogy vannak ezek a szolgáltatások, használhatod őket. De nem mondja meg, hogyan kell használni ezeket a funkciókat, miért jobb használni őket. Ezért nagyon sok ember ír olyat, amivel nem tud együtt élni.
Nézzük meg, hogyan írjuk meg ezeket a modulokat. Aztán meglátjuk, hogyan hívjuk meg őket, és hogyan dolgozzunk a kóddal.
Terraform Registry -
0. tipp, hogy ne írjunk erőforrásmodulokat. E modulok többsége már meg van írva Önnek. Mint mondtam, nyílt forráskódúak, nem tartalmazzák az Ön üzleti logikáját, nem tartalmaznak kódolt IP-címeket, jelszavakat stb. A modul nagyon rugalmas. És valószínűleg már megírták. Számos modul létezik az Amazon erőforrásaihoz. Körülbelül 650. És a legtöbb jó minőségű.
Ebben a példában valaki odajött hozzád, és azt mondta: „Szeretnék tudni kezelni egy adatbázist. Hozzon létre egy modult, hogy létrehozhassak egy adatbázist." A személy nem ismeri sem az Amazon, sem a Terraform megvalósításának részleteit. Egyszerűen azt mondja: "Az MSSQL-t akarom kezelni." Ez azt jelenti, hogy meghívja a modulunkat, átadja a motor típusát, és jelzi az időzónát.
És az embernek nem szabad tudnia, hogy két különböző erőforrást fogunk létrehozni ebben a modulban: az egyiket az MSSQL-hez, a másodikat minden máshoz, csak azért, mert a Terraform 0.11-ben nem adhatja meg az időzóna értékeit opcionálisként.
És a modul kijáratánál egy személy egyszerűen megkaphatja a címet. Nem fogja tudni, hogy mindezt belsőleg melyik adatbázisból, milyen erőforrásból hozzuk létre. Ez az elrejtés nagyon fontos eleme. És ez nem csak azokra a modulokra vonatkozik, amelyek nyilvánosak a nyílt forráskódban, hanem azokra a modulokra is, amelyeket a projektjeibe és csapataiba fog írni.
Ez a második érv, ami nagyon fontos, ha már egy ideje használja a Terraformot. Van egy tárháza, amelyben elhelyezheti cége összes Terraform modulját. És teljesen normális, hogy idővel ez a projekt egy vagy két megabájtosra nő. Ez jó.
De a probléma az, hogy a Terraform hogyan hívja ezeket a modulokat. Például, ha meghív egy modult az egyes felhasználók létrehozásához, a Terraform először betölti a teljes tárat, majd navigál ahhoz a mappához, ahol az adott modul található. Így minden alkalommal egy megabájtot fog letölteni. Ha 100 vagy 200 felhasználót kezel, akkor 100 vagy 200 megabájtot fog letölteni, majd ebbe a mappába lép. Így természetesen nem akarsz egy csomó dolgot letölteni minden alkalommal, amikor megnyomod a "Terraform init" gombot.
Erre a problémára két megoldás létezik. Az első a relatív útvonalak használata. Így jelzi a kódban, hogy a mappa helyi (./). És mielőtt bármit elindítana, készítsen egy Git klónt erről a tárolóról helyben. Így csináld meg egyszer.
Természetesen sok árnyoldala is van. Például nem használhat verziókezelést. És ezzel néha nehéz együtt élni.
Második megoldás. Ha sok almodulod van, és már van valamilyen kiépített pipeline, akkor ott van az MBT projekt, amely lehetővé teszi, hogy sok különböző csomagot gyűjts össze egy monorepository-ból és töltsd fel az S3-ba. Ez egy nagyon jó módszer. Így az iam-user-1.0.0.zip fájl súlya csak 1 Kb, mivel az erőforrás létrehozásához szükséges kód nagyon kicsi. És sokkal gyorsabban fog működni.
Beszéljünk arról, hogy mi nem használható modulokban.
Miért rossz ez a modulokban? A legrosszabb az, ha felhasználót feltételezünk. Tegyük fel, hogy a felhasználó egy szolgáltatói hitelesítési lehetőség, amelyet különböző személyek használhatnak. Például mindannyian asszimilálni fogjuk a szerepet. Ez azt jelenti, hogy a Terraform átveszi ezt a szerepet. És akkor ezzel a szereppel más műveleteket hajt végre.
És az a rossz, hogy ha Vasya szeret egyféle módon csatlakozni az Amazonhoz, például az alapértelmezett környezeti változó használatával, és Petya szereti használni a megosztott kulcsát, ami egy titkos helyen van, akkor nem adhatja meg mindkettőt Terraform. És ahhoz, hogy ne szenvedjenek át, nem kell jelezni ezt a blokkot a modulban. Ezt magasabb szinten kell jelezni. Vagyis van egy erőforrás modulunk, egy infrastruktúra modulunk és egy kompozíciónk a tetején. És ezt valahol feljebb kellene jelezni.
A második rossz a gondozó. Itt nem annyira triviális a gonoszság, mert ha kódot írsz és neked működik, akkor azt gondolhatod, hogy ha működik, akkor minek változtatnál.
A rossz az, hogy először is nem mindig te irányítod, hogy mikor induljon el ez a szolgáltató. Másodszor, nem Ön szabályozza, hogy mit jelent az aws ec2, azaz most Linuxról vagy Windowsról beszélünk. Tehát nem írhat olyat, ami ugyanúgy működik különböző operációs rendszereken vagy különböző felhasználói esetekben.
A legáltalánosabb példa, amit a hivatalos dokumentáció is jelez, hogy ha az aws_instance parancsot írod és egy csomó argumentumot adsz meg, akkor nincs semmi baj, ha ott megadod a „local-exec” előállítót, és futtatod az ansible- játékkönyv .
Valójában igen, nincs ezzel semmi baj. De szó szerint hamarosan rájössz, hogy ez a local-exec dolog nem létezik, például a launch_configuration-ban.
És amikor a launch_configuration-t használja, és egy példányból szeretne létrehozni egy automatikus skálázási csoportot, akkor a launch_configuration-ban nincs szó „provisioner”-ről. Létezik a „felhasználói adatok” fogalma.
Ezért univerzálisabb megoldás a felhasználói adatok használata. És vagy magán a példányon indul el, amikor a példány be van kapcsolva, vagy ugyanazokban a felhasználói adatokban, amikor az automatikus skálázási csoport ezt a launch_configuration-t használja.
Ha továbbra is futtatni szeretné a létesítőt, mert ez egy ragasztó komponens, akkor az egyik erőforrás létrehozásakor abban a pillanatban kell futtatnia a létesítőt, a parancsot. Nagyon sok ilyen helyzet van.
És ehhez a legmegfelelőbb erőforrás a null_resource. A Null_resource egy hamis erőforrás, amely valójában soha nem jön létre. Nem érint semmit, nincs API, nincs automatikus skálázás. De lehetővé teszi a parancs futtatásának szabályozását. Ebben az esetben a parancs a létrehozás során fut le.
Link
Több jel is van. Nem térek ki minden jelre nagyon részletesen. Erről van egy cikk. De ha már dolgozott a Terraform-mal, vagy mások moduljait használta, akkor gyakran észrevette, hogy sok modult, mint a nyílt forráskódú kódok nagy részét, az emberek saját igényeikre írják. Egy férfi megírta és megoldotta a problémáját. Beraktam a GitHubba, hagyd élni. Élni fog, de ha nincs ott dokumentáció és példa, akkor senki nem fogja használni. Ha pedig nincs olyan funkcionalitás, amivel a konkrét feladatánál kicsit többet is megoldhatna, akkor azt sem fogja senki használni. Nagyon sok módja van a felhasználók elvesztésének.
Ha úgy szeretne írni valamit, hogy az emberek használják, akkor azt javaslom, hogy kövesse ezeket a jeleket.
Ezek a következők:
- Dokumentáció és példák.
- Teljes funkcionalitás.
- Ésszerű alapértelmezett értékek.
- Tiszta kód.
- Vizsgálatok.
A tesztek egy másik helyzet, mert meglehetősen nehéz őket megírni. Inkább a dokumentációban és a példákban hiszek.
Tehát megvizsgáltuk, hogyan kell modulokat írni. Két érv szól. Az első, ami a legfontosabb, hogy ne írj, ha tudsz, mert egy csomó ember már elvégezte előtted ezeket a feladatokat. Másodszor, ha mégis úgy dönt, próbálja meg ne használni a szolgáltatókat a modulokban és a szolgáltatókban.
Ez a dokumentáció szürke része. Lehet, hogy most azt gondolja: „Valami nem világos. Nem meggyőzött." De hat hónap múlva meglátjuk.
Most beszéljünk arról, hogyan hívjuk ezeket a modulokat.
Megértjük, hogy kódunk idővel növekszik. Már nincs egy fájlunk, már van 20 fájlunk. Mindegyik egy mappában van. Vagy talán öt mappa. Talán kezdjük valahogy régiónként, egyes összetevők szerint lebontani őket. Akkor megértjük, hogy most megvan a szinkronizálás és a hangszerelés néhány alapja. Vagyis meg kell értenünk, mit kell tennünk, ha megváltoztattuk a hálózati erőforrásokat, mit tegyünk a többi erőforrásunkkal, hogyan idézhetjük elő ezeket a függőségeket stb.
Két véglet létezik. Az első véglet egyben van. Egy törzsfájlunk van. Egyelőre ez volt a hivatalos legjobb gyakorlat a Terraform honlapján.
De most elavultnak írják és eltávolították. Idővel a Terraform közösség rájött, hogy ez messze nem a legjobb gyakorlat, mert az emberek különböző módokon kezdték használni a projektet. És vannak problémák. Például amikor az összes függőséget egy helyen felsoroljuk. Vannak helyzetek, amikor rákattintunk a „Terraform terv”-re, és amíg a Terraform nem frissíti az összes erőforrás állapotát, sok idő telhet el.
A sok idő például 5 perc. Egyesek számára ez sok idő. Láttam olyan esetet, amikor 15 percig tartott. Az AWS API 15 percet töltött azzal, hogy kitalálja, mi történik az egyes erőforrások állapotával. Ez egy nagyon nagy terület.
És természetesen megjelenik egy kapcsolódó probléma, amikor egy helyen szeretne valamit megváltoztatni, majd vár 15 percet, és ez egy vászonképet ad néhány változtatásról. Köpött, „Igen”-t írt, és valami elromlott. Ez egy nagyon valós példa. A Terraform nem próbál megvédeni a problémáktól. Vagyis írj, amit akarsz. Lesznek problémák – a te problémáid. Miközben a Terraform 0.11 semmilyen módon nem próbál segíteni. Vannak olyan érdekes helyek a 0.12-ben, ahol azt mondhatod: „Vasya, tényleg ezt akarod, észhez térsz?”
A második módszer ennek a területnek a csökkentése, vagyis az egyik helyről érkező hívások kevésbé kapcsolhatók össze egy másik helyről.
A probléma csak az, hogy több kódot kell írni, vagyis nagyszámú fájlban le kell írni a változókat és ezt frissíteni. Néhány embernek nem tetszik. Ez normális számomra. És néhányan azt gondolják: "Miért írd ezt különböző helyekre, én mindent egy helyre teszek." Ez lehetséges, de ez a második véglet.
Kinek éli meg mindez egy helyen? Egy, kettő, három ember, vagyis valaki használja.
És ki hív meg egy adott komponenst, egy blokkot vagy egy infrastrukturális modult? Öt-hét ember. Ez király.
A leggyakoribb válasz valahol középen van. Ha a projekt nagy, akkor gyakran lesz olyan helyzet, amikor egyetlen megoldás sem megfelelő, és nem minden működik, így a keveréket választja. Nincs ezzel semmi baj, ha megérted, hogy mindkettőnek megvan az előnye.
Ha valami megváltozott a verem VPC-ben, és ezeket a változtatásokat alkalmazni akarta az EC2-re, azaz frissíteni akarta az automatikus skálázási csoportot, mert új alhálózata volt, akkor ezt a fajta függőségi hangszerelést hívom. Van néhány megoldás: ki mit használ?
Tudok ajánlani, milyen megoldások vannak. Használhatod a Terraformot a varázslathoz, vagy makefile-eket a Terraform használatához. És ha valami változott ott, akkor itt elindíthatod.
Hogy tetszik ez a döntés? Elhiszi valaki, hogy ez jó megoldás? Mosolyt látok, úgy tűnik, kétségek támadtak.
Ezt persze ne otthon próbáld ki. A Terraformot soha nem úgy tervezték, hogy a Terraformból futtassák.
Egy jelentésnél azt mondták nekem: "Nem, ez nem fog működni." A lényeg, hogy ne működjön. Bár nagyon lenyűgözőnek tűnik, amikor elindíthatja a Terraformot a Terraformból, majd a Terraformot, ezt nem szabad megtennie. A Terraformnak mindig nagyon könnyen kell indulnia.
Ha hívás hangszerelésre van szüksége, amikor valami megváltozott egy helyen, akkor ott van a Terragrunt.
A Terragrunt egy segédprogram, a Terraform kiegészítője, amely lehetővé teszi az infrastrukturális modulok hívásainak koordinálását és lebonyolítását.
Egy tipikus Terraform konfigurációs fájl így néz ki.
Meghatározhatja, hogy melyik modult szeretné hívni.
Milyen függőségei vannak a modulnak?
És milyen érveket fogad el ez a modul. Ennyit lehet tudni Terragruntról.
A dokumentáció ott van, és 1 csillag van a GitHubon. De a legtöbb esetben ezt kell tudni. Ez pedig nagyon könnyen megvalósítható olyan cégeknél, amelyek csak most kezdenek dolgozni a Terraformmal.
Tehát a hangszerelés a Terragrunt. Vannak más lehetőségek is.
Most beszéljünk a kóddal való munkavégzésről.
Ha új funkciókat kell hozzáadnia a kódhoz, ez a legtöbb esetben egyszerű. Új forrást írsz, minden egyszerű.
Ha van olyan erőforrása, amelyet előre elkészített, például az AWS-fiók megnyitása után tanult a Terraformról, és szeretné használni a már meglévő erőforrásokat, akkor célszerű a modulját ilyen módon bővíteni, hogy a meglévő források felhasználását támogatja.
És támogatta az új erőforrások létrehozását a blokk erőforrás használatával.
A kimeneten mindig a kimeneti azonosítót adjuk vissza, attól függően, hogy mit használtunk.
A Terraform 0.11 második nagyon jelentős problémája a listákkal való munka.
A nehézség az, hogy ha van ilyen felhasználólistánk.
És amikor ezeket a felhasználókat blokk erőforrással hozzuk létre, akkor minden rendben megy. Végigmegyünk a teljes listán, és mindegyikhez létrehozunk egy fájlt. Minden rendben. És akkor például a középen lévő user3-t el kell távolítani innen, akkor minden erőforrás, ami utána jött létre, újra létrejön, mert megváltozik az index.
Listák kezelése állapotalapú környezetben. Mi az állapotalapú környezet? Ez az a helyzet, amikor új érték jön létre, amikor ez az erőforrás létrejön. Például AWS hozzáférési kulcs vagy AWS titkos kulcs, azaz amikor létrehozunk egy felhasználót, új hozzáférési vagy titkos kulcsot kapunk. És minden alkalommal, amikor törölünk egy felhasználót, ez a felhasználó új kulcsot kap. De ez nem feng shui, mert a felhasználó nem akar majd velünk barátkozni, ha minden alkalommal létrehozunk neki egy új felhasználót, amikor valaki kilép a csapatból.
Ez a megoldás. Ez a Jsonnetben írt kód. A Jsonnet egy sablonnyelv a Google-tól.
Ez a parancs lehetővé teszi ennek a sablonnak az elfogadását, és kimenetként egy json-fájlt ad vissza, amely a sablonnak megfelelően készült.
A sablon így néz ki.
A Terraform lehetővé teszi, hogy a HCL-lel és a Json-nal ugyanúgy dolgozzon, tehát ha képes Json-t generálni, akkor átcsúsztathatja a Terraformba. A .tf.json kiterjesztésű fájl letöltése sikeresen megtörténik.
És akkor a szokásos módon dolgozunk vele: terraform init, terramorm alkalmaz. És létrehozunk két felhasználót.
Most már nem félünk, ha valaki elhagyja a csapatot. Csak a json fájlt szerkesztjük. Vasya Pupkin távozott, Petya Pyatochkin maradt. Petya Pyatochkin nem kap új kulcsot.
A Terraform integrálása más eszközökkel nem igazán a Terraform feladata. A Terraformot az erőforrások létrehozásának platformjaként hozták létre, és ennyi. És minden, ami később felmerül, nem a Terraform érdeke. És nem kell oda beszőni. Van Ansible, ami mindent megtesz, amire szüksége van.
De előfordulnak olyan helyzetek, amikor ki akarjuk terjeszteni a Terraformot, és valamilyen parancsot akarunk hívni, miután valami befejeződött.
Első út. Létrehozunk egy kimenetet, ahová ezt a parancsot írjuk.
Ezután meghívjuk ezt a parancsot a shell terraform kimenetéből, és megadjuk a kívánt értéket. Így a parancs az összes behelyettesített értékkel végrehajtódik. Nagyon kényelmes.
Második út. Ez a null_resource használata az infrastruktúránk változásaitól függően. Meghívhatjuk ugyanazt a local-exe-t, amint néhány erőforrás azonosítója megváltozik.
Természetesen mindez papíron simán megy, mert az Amazonnak, mint minden más állami szolgáltatónak, van egy rakás saját szélső tokja.
A leggyakoribb szélső eset az, hogy amikor megnyit egy AWS-fiókot, számít, hogy melyik régiót használja; be van kapcsolva ez a funkció; talán 2013 decembere után nyitotta meg; talán alapértelmezettet használ a VPC-ben stb. Sok korlátozás van. Az Amazon pedig szétszórta őket a dokumentációban.
Van néhány dolog, amit javaslok kerülni.
Kezdésként kerüljön minden nem titkos argumentumot a Terraform tervben vagy a Terraform CLI-n belül. Mindezt akár egy tfvars fájlba, akár egy környezeti változóba helyezhetjük.
De nem kell megjegyezned ezt az egész varázsparancsot. Terraform terv – var és indulunk. Az első változó a var, a második változó a var, a harmadik, a negyedik. Az infrastruktúra, mint kód legfontosabb alapelve, amit leggyakrabban használok, hogy már csak a kódra pillantva világosan meg kell értenem, hogy mi van ott telepítve, milyen állapotban és milyen értékekkel. Így nem kell elolvasnom a dokumentációt, és nem kell megkérdeznem Vasját, hogy milyen paramétereket használt a klaszterünk létrehozásához. Csak meg kell nyitnom egy tfvars kiterjesztésű fájlt, ami gyakran megfelel a környezetnek, és ott mindent megnézek.
Ezenkívül ne használjon cél argumentumokat a hatókör csökkentésére. Ehhez sokkal egyszerűbb kis infrastrukturális modulokat használni.
Ezenkívül nincs szükség a párhuzamosság korlátozására és növelésére. Ha 150 erőforrásom van, és az Amazon párhuzamosságát az alapértelmezett 10-ről 100-ra szeretném növelni, akkor valószínűleg valami elromlik. Vagy lehet, hogy most jól megy, de amikor az Amazon azt mondja, hogy túl sok hívást kezdeményez, akkor bajban lesz.
A Terraform megpróbálja újraindítani a legtöbb ilyen problémát, de szinte semmit sem fog elérni. A Parallelism=1 fontos használat, ha valamilyen hibára botlik az AWS API-n vagy a Terraform szolgáltatón belül. Ezután meg kell adnia: parallelism=1, és várjon, amíg a Terraform befejezi az egyik hívást, majd a másodikat, majd a harmadikat. Egyenként indítja el őket.
Az emberek gyakran kérdezik tőlem: „Miért gondolom, hogy a Terraform munkaterületek gonoszak?” Úgy gondolom, hogy az infrastruktúra mint kód elve az, hogy lássuk, milyen infrastruktúrát hoztak létre és milyen értékekkel.
A munkaterületeket nem a felhasználók hozták létre. Ez nem jelenti azt, hogy a felhasználók azt írták a GitHub-problémákban, hogy nem tudunk élni Terraform munkaterületek nélkül. Nem, nem így. A Terraform Enterprise egy kereskedelmi megoldás. A HashiCorp-tól származó Terraform úgy döntött, hogy szükségünk van munkaterületekre, ezért elvittük. Sokkal egyszerűbbnek találom külön mappába tenni. Aztán lesz egy kicsit több fájl, de világosabb lesz.
Hogyan kell dolgozni a kóddal? Valójában a listákkal való munka az egyetlen fájdalom. És vegye könnyebben a Terraformot. Ez nem az a dolog, ami mindent nagyszerűen megtesz neked. Nem kell mindent oda tolni, ami a dokumentációban le van írva.
A jelentés témája „a jövőért” volt írva. Erről nagyon röviden szólok. A jövőre nézve ez azt jelenti, hogy hamarosan megjelenik a 0.12.
A 0.12 egy csomó újdonság. Ha szokványos programozásból jön, akkor hiányzik mindenféle dinamikus blokk, ciklus, helyes és feltételes összehasonlító művelet, ahol a bal és a jobb oldal nem egyszerre, hanem helyzettől függően kerül kiszámításra. Nagyon hiányzik, így a 0.12 megoldja helyetted.
De! Ha kevésbé és egyszerűbben ír, kész modulokat és külső megoldásokat használ, akkor nem kell várnia és remélnie, hogy jön a 0.12 és mindent megjavít.
Köszönjük a beszámolót! Ön az infrastruktúráról mint kódról beszélt, és szó szerint egy szót mondott a tesztekről. Szükség van-e tesztekre a modulokban? Kinek a felelőssége ez? Ezt magamnak kell megírnom, vagy ez a modulok felelőssége?
A következő év tele lesz olyan jelentésekkel, amelyek szerint úgy döntöttünk, hogy mindent tesztelünk. Mit kell tesztelni, az a legnagyobb kérdés. Nagyon sok függőség, sok korlátozás létezik a különböző szolgáltatóktól. Amikor te és én beszélgetünk, és azt mondod: „Tesztekre van szükségem”, akkor megkérdezem: „Mit fogsz tesztelni?” Azt mondja, hogy tesztelni fog a régiójában. Aztán azt mondom, hogy az én régiómban ez nem működik. Vagyis ebben nem is fogunk tudni megegyezni. Arról nem is beszélve, hogy sok a technikai probléma. Vagyis hogyan kell megírni ezeket a teszteket úgy, hogy megfelelőek legyenek.
Aktívan kutatom ezt a témát, azaz hogyan lehet automatikusan teszteket generálni az általad írt infrastruktúra alapján. Vagyis ha ezt a kódot írtad, akkor le kell futtatnom, ez alapján tudok teszteket készíteni.
az egyik leggyakrabban emlegetett könyvtár, amely lehetővé teszi a Terraform integrációs tesztek írását. Ez az egyik segédprogram. Inkább a DSL típust szeretem, pl. rspec.
Anton, köszönöm a beszámolót! A nevem Valerij. Hadd tegyek fel egy kis filozófiai kérdést. Feltételesen van ellátás, van telepítés. A kiépítés létrehozza az infrastruktúrámat, a telepítés során megtöltjük valami hasznossal, például szerverekkel, alkalmazásokkal stb. És az jár a fejemben, hogy a Terraform inkább a kiépítésre, az Ansible pedig inkább a telepítésre szolgál, mert az Ansible a fizikai infrastruktúra is. lehetővé teszi az nginx, Postgres telepítését. Ugyanakkor úgy tűnik, hogy az Ansible lehetővé teszi például az Amazon vagy a Google erőforrásainak biztosítását. A Terraform azonban lehetővé teszi bizonyos szoftverek telepítését is a moduljai segítségével. Az Ön szemszögéből nézve van valami határ, ami a Terraform és az Ansible között húzódik, hol és mit érdemes használni? Vagy pl szerinted az Ansible már szemétség, mindenhez meg kell próbálni a Terraformot használni?
Jó kérdés, Valerij. Úgy gondolom, hogy a Terraform célja nem változott 2014 óta. Az infrastruktúra számára hozták létre, és az infrastruktúráért halt meg. Továbbra is volt és lesz szükségünk az Ansible konfigurációkezelésére. A kihívás az, hogy a launch_configurationben felhasználói adatok találhatók. És ott húzza az Ansible-t stb. Ez az a szokásos megkülönböztetés, amely a legjobban tetszik.
Ha gyönyörű infrastruktúráról beszélünk, akkor vannak olyan segédprogramok, mint a Packer, amelyek összegyűjtik ezt a képet. Ezután a Terraform az adatforrás segítségével keresi meg ezt a képet, és frissíti a launch_configuration-t. Vagyis ilyen módon az a folyamat, hogy először a Trackert húzzuk, majd a Terraformot. És ha megtörténik az építkezés, akkor új változás következik be.
Helló! Köszönjük a beszámolót! A nevem Misha, RBS cég. Erőforrás létrehozásakor hívhatja az Ansible-t a szolgáltatón keresztül. Az Ansible-nek van egy dinamikus leltár témája is. És először hívhatja a Terraformot, majd hívhatja az Ansible-t, amely erőforrásokat vesz el az államtól és végrehajtja azt. Mi a jobb?
Az emberek mindkettőt egyforma sikerrel használják. Számomra úgy tűnik, hogy a dinamikus leltár az Ansible-ben kényelmes dolog, ha nem az automatikus skálázási csoportról beszélünk. Mert az autoscaling csoportban már megvan a saját eszközkészletünk, amit launch_configuration-nak hívnak. Az launch_configuration-ban mindent rögzítünk, amit el kell indítani, amikor új erőforrást hozunk létre. Ezért az Amazonnál a dinamikus leltár használata és a Terraform ts fájl olvasása véleményem szerint túlzás. És ha más eszközöket használ, ahol nincs „autoscaling group” fogalma, például DigitalOcean-t vagy más szolgáltatót használ, ahol nincs automatikus skálázási csoport, akkor ott kézzel kell kihúznia az API-t, meg kell keresnie az IP-címeket, létrehoznia egy dinamikus leltárfájlt , és az Ansible máris átmegy rajta. Vagyis az Amazonnál van launch_configuration, minden másnál pedig dinamikus leltár.
Forrás: will.com