Az infrastruktúra kód formájában, ismételhető szöveges formátumban való bemutatása – egyszerűen a legjobb gyakorlat a rendszerek számára, amivel nem kell sokat vesződni. E gyakorlat elnevezése — , és jelenleg a megvalósításához, különösen az AWS-nél, két népszerű eszköz áll rendelkezésre: és .
Összehasonlítom a Terraform és a CloudFormation használatának tapasztalataimat.
Mielőtt a (más néven ) helyre kerültem, dolgoztam és körülbelül három évig használtam a Terraformot. Az új helyemen is teljes mértékben alkalmaztam a Terraformot, majd a cég rákényszerítette a teljes átváltást az Amazon formájára, beleértve a CloudFormationt is. Szorgalmasan dolgoztam a legjobb gyakorlatok kidolgozásán mindkét esetben, és mindkét eszközt nagyon komplex munkafolyamatokban használtam a szervezet keretein belül. Később, alaposan mérlegelve a Terraformról a CloudFormationra való áttérés következményeit, arra a következtetésre jutottam, hogy a Terraform valószínűleg a legjobb választás a szervezet számára.
Terraform Borzalmas
Béta verziójú szoftver
A Terraformnak még a 1.0-ás verziója sem jelent meg, és ez – komoly ok arra, hogy ne használjuk. Amióta először kipróbáltam, óriási változások történtek, de abban az időben még terraform apply sokszor meghibásodott néhány frissítés után vagy csak pár év használat után. Azt mondanám, hogy „most minden más”, de… így mindenki mondja, nem? Vannak változások, amelyek nem kompatibilisek az előző verziókkal, bár jogosak, és még az is érezhető, hogy a szintaxis és az erőforrás-tárhelyek absztrakciói most már rendben vannak. Úgy tűnik, az eszköz valóban jobbá vált, de… :-0
Másrészt az AWS jól dolgozott a korábbi verziókkal való kompatibilitás fenntartásán. Valószínűleg azért, mert a szolgáltatásaikat gyakran alaposan letesztelik a szervezeten belül, és csak azután, hogy átnevezik, publikálják őket. Tehát a „jól dolgoztak” még gyengének is mondható. A korábbi API-verziók kompatibilitásának fenntartása egy olyan sokoldalú és bonyolult rendszer, mint az AWS, hihetetlenül nehéz. Mindazok számára, akiknek meg kellett tartaniuk a közpublic API-kat, amelyeket ilyen széles körben használnak, érteniük kell, milyen nehéz ezt évek hosszú során keresztül fenntartani. A CloudFormation viselkedése pedig emlékeim szerint egyszer sem változott az évek során.
Ismerkedj meg, láb… ez egy golyó
Amennyire tudom, eltávolítani egy erőforrást külső A CloudFormation stack cannot import from its own CF stack. The situation is similar with Terraform. It allows you to import existing resources into your stack. This feature is quite amazing, but with great power comes great responsibility. Once a resource is added to the stack, you cannot delete or change it while working with your stack. Once, this came back to haunt us. For instance, on the Twitch website, someone, without any malicious intent, accidentally imported someone else's AWS security group into their own Terraform stack. They executed a few commands and… the security group (along with incoming traffic) disappeared.
Terraform the Great
Recovery from incomplete states
Sometimes CloudFormation cannot completely transition from one state to another. In this case, it tries to return to the previous state. Unfortunately, this is not always feasible. Debugging what has resulted can be a bit scary — you never know if CloudFormation will be pleased that it's being tampered with — even if it’s for repairing. Whether it can return to the previous state is something it cannot determine clearly and by default, it hangs for hours waiting for a miracle.
On the other hand, Terraform is more graceful in recovering from unsuccessful transitions and offers advanced debugging tools.
Clearer changes in document states
"Alright, load balancer, you're changing. But how?"
— worried engineer ready to hit the 'accept' button.
Sometimes I need to make certain manipulations with the load balancer in the CloudFormation stack — for example, add a port number or modify the security group. CloudFormation shows changes poorly. I find myself on edge, checking the YAML file ten times to ensure I haven't deleted something important or added something unnecessary.
In this regard, Terraform is much more transparent. Sometimes it’s even too transparent (read: annoying). Fortunately, the latest version included improved change visualization — now it’s clear what changes are being made.
Rugalmasság
Write software backward.
Közvetlenül fogalmazva, a hosszú élettartamú szoftver legfontosabb jellemzője a változásokhoz való alkalmazkodás képessége. Bármilyen szoftvert visszafelé kell írni. Én gyakran abból a hibából estem, hogy egy "egyszerű" szolgáltatást választottam, majd megpróbáltam mindent belepréselni egy CloudFormation vagy Terraform stackbe. Persze hónapok múlva kiderült, hogy mindent félreértettem, és a szolgáltatás valójában nem is olyan egyszerű! És valahogyan fel kellene darabnom a nagy stacket kisebb összetevőkre. Amikor CloudFormation-nel dolgozol, ezt csak úgy lehet megtenni, ha először újra kell alkotni a meglévő stacket, amit én nem csinálok az adatbázisaimmal. A Terraform viszont lehetővé tette, hogy szétszedjem a stacket, és érthetőbb, kisebb részekre bontsam.
Git modulok
A Terraform kód megosztása a számos stack között sokkal egyszerűbb, mint a CloudFormation kódé. A Terraform lehetővé teszi, hogy a kódot egy git tárolóba helyezzük, és verziókezelésen keresztül hivatkozzunk rá. Bárki, akinek hozzáférése van ehhez a tárolóhoz, újra felhasználhatja a közös kódot. A CloudFormation megfelelője az S3, de annak nincsenek meg ugyanazok az előnyei, és nincs egyetlen ok sem, amiért le kellene mondanunk a git-ről az S3 javára.
A szervezet növekedett, és a közös stackek megosztásának képessége kritikus szintet ért el. A Terraformmal mindez könnyen és természetesen valósul meg, míg a CloudFormation arra kényszerít, hogy ugráljunk gyűrűk között, mielőtt valami hasonló működni kezd.
Operations as code
„Szkriptre írjunk, és kész.”
— mérnök három évvel azelőtt, hogy feltalálta a Terraformot.
Amikor szoftverfejlesztésről van szó, a Go vagy a Java program nem csupán kód.
Code as Code
Ott van az infrastruktúra is, amelyen fut.
Infrastructure as Code
De honnan is jön ez? Hogyan lehet monitorozni? Hol lakozik a kódod? Szükségük van a fejlesztőknek engedélyre a hozzáféréshez?
Operations as Code
Szoftverfejlesztőnek lenni nem pusztán annyit jelent, hogy kódot írsz.
Nem csak az AWS létezik: valószínűleg használ más szolgáltatók szolgáltatásait is. SignalFx, PagerDuty vagy Github. Lehet, hogy van egy belső Jenkins szervered a CI/CD-hez, vagy egy belső Grafana vezérlőpultod a monitorozáshoz. Az Infra as Code térnyerésének különböző okai vannak, és mindegyik ugyanolyan fontos minden szoftverrel kapcsolatos dologhoz.
Amikor a Twitch-nél dolgoztam, felgyorsítottuk a szolgáltatásokat vegyes beágyazott rendszerekben és az Amazon AWS rendszereiben. Sokan létrehoztunk és támogattunk számos mikroszolgáltatást, növelve a működési költségeket. A megbeszélések körülbelül így zajlottak:
- Én: Jé, elég sok mozgás egy mikroszolgáltatás felpörgetéséhez. Ezt a dolgot muszáj lesz használnom, hogy létrehozzak egy AWS fiókot (két fiókra mentünk a mikroszolgáltatás), aztán ezt az értesítések beállításához, még ezt a kódreposzthoz, és ezt az e-mail címek listájához, na meg ezt…
- Kapcsolat: Skriptezzünk és kész.
- Én: Rendben van, de a skript változni fog. Szükség lesz valamilyen módra, amivel ellenőrizni lehet, hogy ezek az Amazon beágyazott cuccai naprakészen állnak.
- Kapcsolat: Jól hangzik. És ezért írunk egy skriptet.
- Én: Remek! A skripthez valószínűleg még paramétereket is kell adni. Elfogadja azokat?
- Kapcsolat: Persze, hogy elfogadja, hová máshová mehetne!
- Én: A folyamat változhat, elveszett a visszafelé kompatibilitás. Szükséges lehet valamilyen szemantikai verziókontroll.
- Kapcsolat: Nagyszerű ötlet!
- Én: Az eszközöket manuálisan is meg lehet változtatni a felhasználói felületen belül. Szükségünk lesz arra, hogy ellenőrizzük és javítsuk ezt.
…3 évvel később:
- Kapcsolat: Így lett terraformunk.
A tanulság az, hogy még akkor is, ha teli vagy az Amazon cuccaival,akkor is használsz valamit, ami nem az AWS-től van, és ezeknek a szolgáltatásoknak van állapota, amelyet a konfigurációs nyelv használ a szinkronizálás érdekében.
CloudFormation lambda vs git modulok terraform
A lambda a CloudFormation megoldása a felhasználói logika kérdésére. A lambda segítségével vagy . Ez a megközelítés további bonyodalmakat jelent, amelyek nincsenek a Terraform git moduljainak szemantikai verziókontrolljában. Számomra a legnagyobb problémát a jogosultságok kezelése jelentette ezekkel a felhasználói lambda-kal (ezek pedig tucatnyi AWS fiókot jelentenek). Egy másik fontos probléma a „mi volt előbb: a tojás vagy a csirke?” típusú kérdés volt: ez a lambda kódhoz kapcsolódott. Maga a funkció – infrastruktúra és kód, és szüksége van monitoringra és frissítésekre is. Az utolsó szög a koporsóba a lambda kódváltozások szemantikai frissítésének nehézsége volt; olyan megoldást kellett keresni, hogy a verem műveletei ne változzanak közvetlen parancs nélkül sem az indítások között.
Emlékszem, egyszer kedvem támadt, hogy készítsek egy kanári telepítést az Elastic Beanstalk környezethez egy klasszikus terheléselosztóval. A legegyszerűbb az lett volna, ha készítek egy második telepítést az EB mellett a termelési környezethez, még egy lépéssel tovább haladva: összekapcsolva az automatikusan skálázható kanári telepítés csoportját a termelési környezet terheléselosztójával. Mivel a Terraform használja , ez 4 felesleges kódsort igényelne a Terraform-ban. Amikor megkérdeztem, van-e összehasonlítható megoldás a CloudFormation-ben, egy egész repositoriumra mutattak a git-ben, telepítési csatornával és egyebekkel: és mindezt azért, amit csupán 4 sor Terraform kód is megoldhatott volna.
Jobban észleli a driftet
Győződjön meg róla, hogy a valóság egyezik a várakozásokkal.
— egy nagyon erőteljes funkció az operations as code számára, mert segít biztosítani, hogy a valóság egyezzen a várakozásokkal. Ez elérhető a CloudFormation és a Terraform esetében is. De ahogy a munkahely nő, a drift keresése a CloudFormation-ben egyre több hamis értesítést adott.
A Terraform esetében sokkal fejlettebb életciklus-hook-okat van a drift érzékelésére. Például megadja a parancsot közvetlenül az ECS feladat definíciójában, ha szeretné figyelmen kívül hagyni a változásokat egy adott feladat definíciójában, anélkül, hogy figyelmen kívül hagyná a változásokat az egész ECS telepítésben.
CDK és a CloudFormation jövője
A CloudFormation kezelése nehéz nagy, interinfrastruktúrális mércéken. Sok ilyen nehézség elismert, és az eszköznek szüksége van olyan dolgokra, mint például , egy struktúra a felhőinfrastruktúra kódba történő definíciójához és annak AWS CloudFormation-en való végrehajtásához. Kíváncsi leszek, mi vár az aws-cdk-ra a jövőben, de nehézkes lesz, hogy versenyezzen a Terraform más előnyeivel; a CloudFormation felzárkóztatásához globális változások szükségesek.
Hogy a Terraform ne csalódást okozzon
Ez az 'infrastruktúra mint KÓD', nem pedig 'mint szöveg'.
Első benyomásom a Terraformról elég rossz volt. Azt hiszem, egyszerűen nem értettem meg a megközelítést. Szinte minden mérnök elsőre akaratlanul is szöveges formátumnak tekinti, amit át kell alakítani a kívánt infrastruktúrává. ERRE NINCS SZÜKSÉG.
A szoftverfejlesztés jó alapigazságai a Terraform-ra is vonatkoznak.
Láttam, hogy sok olyan gyakorlat, amit a jó kód létrehozására fogadtak el, figyelmen kívül marad a Terraform használata során. Évek óta tanultál, hogy jó programozó legyél. Ne mondj le erről a tapasztalatról csak azért, mert Terraformot használsz. A szoftverfejlesztés jó alapelvei a Terraformra is vonatkoznak.
Hogyan lehetne a kódot nem dokumentálni?
Találkoztam hatalmas Terraform veremmel, amely teljesen dokumentáció nélkül készült. Hogy lehet kódot írni oldalakon keresztül - teljesen dokumentáció nélkül? Adj hozzá dokumentációt, amelyben elmagyarázod a a kódot Terraform (itt a „kód” szóra helyeződik a hangsúly), hogy miért olyan fontos ez a rész, és mit csinálsz.
Hogyan lehet szolgáltatásokat telepíteni, amelyek egy nagy main() funkcióból származtak?
Nagyon összetett Terraform veremmel találkoztam, amely egyetlen modulba volt belefoglalva. Miért nem így telepítjük a szoftvert? Miért bontjuk le a nagy funkciókat kisebb darabokra? Ugyanezek a válaszok érvényesek a Terraformra is. Ha a modul túl nagy számodra - fel kell osztani kisebb modulokra.
A céged nem használ könyvtárakat?
Láttam, ahogy az mérnökök új projektet indítva Terraform használatával, simán másoltak hatalmas részeket más projektektől a sajátjaikba, majd szerkesztgették őket, amíg működni nem kezdtek. Te a cégednél így dolgoznál a „termelői” kódoddal? Nem véletlenül használunk könyvtárakat. Igen, de hová mennénk közös könyvtárak nélkül egyáltalán?!
Nem használod a PEP8-at vagy a gofmt-ot?
A legtöbb nyelvben van egy standard elfogadott formázási séma. A Pythonban ez a PEP8. A Go-ban a gofmt. A Terraformnak is megvan a sajátja: terraform fmt. Használjátok egészséggel!
Használni fogod a Reactot, anélkül, hogy tudnád a JavaScriptet?
A Terraform modulok egyszerűsíthetik a létrehozott bonyolult infrastruktúrád egy részét, de ez még nem jelenti, hogy teljesen értened kellene ahhoz. Szeretnéd helyesen használni a Terrraformot anélkül, hogy értenéd a forrásokat? Kárhoztattál: az idő múlik, de sosem fogod elsajátítani a Terraformot.
Singletonokkal kódolsz, vagy függőségeket injektálsz?
A függőségek injectálása bevett legjobb gyakorlat a szoftverfejlesztésben, amelyet a singletonok preferálnak. Hogyan segíthet ez a Terraformban? Találkoztam Terraform modulokkal, amelyek külső állapotoktól függenek. Ahelyett, hogy modulokat írnál, amelyek az külső állapotokból dolgoznak, írj olyan modult, amely paramétereket fogad. Azután ezeket a paramétereket add át a modulnak.
A könyvtáraid tíz dolgot végeznek jól, vagy egyet — kiválóan?
A legjobban azok a könyvtárak működnek, amelyek egy feladatra koncentrálnak, amit kiválóan végeznek. Ahelyett, hogy nagy Terraform modulokat írnál, amelyek mindent egyszerre próbálnak megvalósítani, alakítsd őket olyan részekké, amelyek jól végeznek el egy-egy dolgot. Azután kombináld őket úgy, ahogy szükséges.
Hogyan hajtasz végre változásokat a könyvtárakban visszafordíthatóság nélkül?
A Terraform közös moduljának, akárcsak a szokásos könyvtárnak, valahogy értesítenie kell a felhasználókat a visszafordíthatóság nélküli változásokról. Amikor ilyen változások történnek a könyvtárakban, az idegesítő, és pontosan ugyanannyira idegesítő, amikor a Terraform modulokban tesznek visszafordíthatóság nélküli módosításokat. Ajánlott git címkéket és semver-t használni a Terraform modulok alkalmazásakor.
A termelési szolgáltatásod a laptopodon vagy adatközpontban fut?
A Hashicorp-nak vannak olyan eszközei, mint a Terraformod futtatásához. Ezek a központosított szolgáltatások megkönnyítik a Terraform kezelését, auditálását és a változások jóváhagyását.
Nem írsz teszteket?
A mérnökök elismerik, hogy a kódot tesztelni kell, de gyakran figyelmen kívül hagyják a teszteket, amikor Terraformmal dolgoznak. Az infrastruktúra szempontjából ez csapdát rejthet. Azt tanácsolom, hogy "teszteld" vagy "példákat készíts" olyan stackekkel, amelyek helyesen telepíthetők a CI/CD során.
Terraform és mikroszolgáltatások
A mikroszolgáltatásokra épülő cégek élete és halála a sebességtől, a frissítésektől és az új mikroszolgáltatási munkafolyamatok megsemmisítésétől függ.
A leggyakoribb negatív szempont, amely a mikroszolgáltatás-architektúrákkal összefügg, és amelytől nem lehet megszabadulni, a munkával, nem pedig a kóddal kapcsolatos. Ha a Terraformot csupán úgy értelmezed, mint az infrastruktúra automatizálási módját a mikroszolgáltatás-architektúrában, akkor megfosztod magadat ezen rendszer valódi előnyeitől. Most már .
Forrás: habr.com
