Az infrastruktúra kódként való megjelenítése megismételhető szöveges formátumban egyszerű bevált módszer azoknál a rendszereknél, amelyek nem igényelnek egereket. Ennek a gyakorlatnak neve van - , és eddig két népszerű eszköz létezik ennek megvalósítására, különösen az AWS-ben: и .
A Terraform és a CloudFormation szolgáltatással szerzett tapasztalatok összehasonlítása
Mielőtt idejönne (Aka ) Dolgoztam és három évig használta a Terraformot. Az új helyen is minden erőmmel a Terraformot használtam, majd a cég rátolta az átállást mindenre a la Amazonra, így a CloudFormationre is. Mindkettőhöz szorgalmasan dolgoztam ki a bevált gyakorlatokat, és mindkét eszközt nagyon összetett, az egész szervezetre kiterjedő munkafolyamatokban használtam. Később, miután átgondoltam a Terraformról a CloudFormationre való átállás következményeit, meggyőződtem arról, hogy a Terraform valószínűleg a legjobb választás a szervezet számára.
Terraform Borzalmas
Béta szoftver
A Terraform még az 1.0-s verziót sem adta ki, ami jó ok arra, hogy ne használjuk. Sokat változott, mióta először kipróbáltam magam, de akkoriban terraform apply gyakran többszöri frissítés vagy egyszerűen csak néhány év használat után tönkrement. Azt mondanám, hogy „most már minden más”, de... úgy tűnik, mindenki ezt mondja, nem? Vannak olyan változtatások, amelyek nem kompatibilisek a korábbi verziókkal, bár megfelelőek, sőt, úgy tűnik, hogy az erőforrás-tárak szintaxisára és absztrakcióira most szükségünk van. A hangszer mintha tényleg jobb lett volna, de... :-0
Másrészt az AWS jó munkát végzett a visszamenőleges kompatibilitás fenntartásában. Ennek valószínűleg az az oka, hogy szolgáltatásaikat a szervezeten belül gyakran alaposan tesztelik, és csak ezután, átnevezve teszik közzé. Tehát a „keményen igyekeztek” alábecsülés. Az API-kkal való visszamenőleges kompatibilitás fenntartása egy olyan változatos és összetett rendszer esetében, mint az AWS, hihetetlenül nehéz. Mindenkinek, akinek olyan széles körben használt nyilvános API-kat kellett karbantartania, meg kell értenie, milyen nehéz ezt oly sok éven át megtenni. De emlékeim szerint a CloudFormation viselkedése soha nem változott az évek során.
Találkozz a lábbal... ez egy golyó
Amennyire én tudom, törölje az erőforrást kívülálló CloudFormation verem a CF veremből nem lehetséges. Ugyanez igaz a Terraformra is. Lehetővé teszi, hogy meglévő erőforrásokat importáljon a verembe. A funkció elképesztőnek mondható, de nagy erővel nagy felelősség is jár. Csak hozzá kell adnia egy erőforrást a veremhez, és amíg a veremmel dolgozik, nem törölheti vagy módosíthatja ezt az erőforrást. Egy napon ez visszafelé sült el. Egy nap a Twitch-en valaki véletlenül valaki más AWS biztonsági csoportját importálta a saját Terraform veremébe, miközben nem végzett semmiféle huncutsággal. Több parancsot is megadtam és... a biztonsági csoport (a bejövő forgalommal együtt) eltűnt.
Terraform nagyszerű
Hiányos állapotokból való felépülés
Néha a CloudFormation nem képes teljesen átváltani egyik állapotból a másikba. Ugyanakkor megpróbál visszatérni az előzőhöz. Kár, hogy ez nem mindig kivitelezhető. Elég ijesztő lehet később hibakeresni a történteket – soha nem tudhatod, hogy a CloudFormation örülni fog-e annak, hogy feltörik – még csak azért is, hogy kijavítsák. Attól függetlenül, hogy vissza lehet-e térni az előző állapotba, tényleg nem tudja, hogyan határozza meg, és alapértelmezés szerint órákig lóg a csodára várva.
Ezzel szemben a Terraform sokkal kecsesebben tér vissza a sikertelen átmenetekből, és fejlett hibakereső eszközöket kínál.
Világosabb változások a dokumentum állapotában
– Oké, terheléselosztó, te változol. De hogyan?"
– aggódó mérnök, készen áll az „elfogadás” gomb megnyomására.
Néha el kell végeznem néhány manipulációt a CloudFormation veremben lévő terheléselosztóval, például portszámot kell hozzáadnom vagy biztonsági csoportot kell módosítanom. A ClouFormation rosszul jeleníti meg a változásokat. Én, tűkön, tízszer ellenőrzöm a yaml fájlt, hogy megbizonyosodjak arról, hogy nem töröltem ki semmi szükségeset, és nem adtam hozzá semmi feleslegeset.
A Terraform ebből a szempontból sokkal átláthatóbb. Néha még túlságosan is átlátszó (értsd: unalmas). Szerencsére a legújabb verzió a változások továbbfejlesztett megjelenítését tartalmazza, így most már pontosan láthatja, hogy mi változik.
rugalmasság
Írd vissza a szoftvert.
Őszintén szólva a hosszú élettartamú szoftverek legfontosabb jellemzője a változásokhoz való alkalmazkodás képessége. Írjon vissza bármilyen szoftvert. Leggyakrabban úgy követtem el hibákat, hogy igénybe vettem egy „egyszerű” szolgáltatást, majd elkezdtem mindent egyetlen CloudFormation vagy Terraform verembe zsúfolni. És persze hónapokkal később kiderült, hogy mindent rosszul értettem, és a szolgáltatás valójában nem volt egyszerű! És most valahogy szét kell bontanom egy nagy köteget apró alkatrészekre. Amikor a CloudFormation szolgáltatással dolgozik, ezt csak úgy lehet megtenni, hogy először újra létrehozza a meglévő veremeket, én ezt nem teszem meg az adatbázisaimmal. A Terraform viszont lehetővé tette a verem feldarabolását és érthetőbb kisebb részekre bontását.
Modulok a gitben
A Terraform kód megosztása több verem között sokkal egyszerűbb, mint a CloudFormation kód megosztása. A Terraform segítségével elhelyezheti kódját egy git tárolóba, és szemantikus verzióvezérléssel elérheti azt. Bárki, aki hozzáfér ehhez a tárolóhoz, újra felhasználhatja a megosztott kódot. A CloudFormation megfelelője az S3, de nem rendelkezik ugyanazokkal az előnyökkel, és nincs okunk arra, hogy egyáltalán elhagyjuk a git-et az S3 javára.
A szervezet növekedett, és a közös halmok megosztásának képessége elérte a kritikus szintet. A Terraform mindezt egyszerűvé és természetessé teszi, míg a CloudFormation segítségével átugorhat a karikán, mielőtt valami ilyesmit működésbe hozhatna.
Műveletek kódként
– Írjuk le, és oké.
– egy mérnök 3 évvel a Terraform kerékpár feltalálása előtt.
Ha szoftverfejlesztésről van szó, a Go vagy egy Java program nem csak kód.
Kód mint kód
Ott van az infrastruktúra is, amelyen működik.
Infrastruktúra mint kód
De honnan van? Hogyan kell figyelni? Hol él a kódod? Szükségük van a fejlesztőknek hozzáférési engedélyre?
Műveletek kódként
Szoftverfejlesztőnek lenni nem csak kódírást jelent.
Az AWS nem az egyetlen: valószínűleg más szolgáltatókat használ. SignalFx, PagerDuty vagy Github. Lehet, hogy van egy belső Jenkins szervere a CI/CD-hez vagy egy belső Grafana műszerfala a megfigyeléshez. Az Infra mint kódot különböző okok miatt választják, és mindegyik egyformán fontos minden szoftverrel kapcsolatos dolog szempontjából.
Amikor a Twitchnél dolgoztam, felgyorsítottuk a szolgáltatásokat az Amazon vegyes beágyazott és AWS rendszerein belül. Számos mikroszolgáltatást lebonyolítottunk és támogattunk, növelve ezzel a működési költségeket. A megbeszélések valahogy így zajlottak:
- Я: A fenébe, ez sok gesztus egy mikroszolgáltatás túlhajtására. Ezt a szemetet fel kell használnom egy AWS-fiók létrehozásához (2 fiókhoz mentünk tovább mikroszolgáltatás), majd ezt a riasztások beállításához, ezt a kódtárhoz, ezt az e-mail listához, majd ezt...
- Vezet: Írjuk le és oké.
- Я: Rendben, de maga a szkript megváltozik. Szükségünk lesz egy módra annak ellenőrzésére, hogy az összes beépített Amazon-gizmos naprakész-e.
- Vezet: Jól hangzik. És ehhez írunk egy forgatókönyvet.
- Я: Nagy! És a szkriptnek valószínűleg még paramétereket kell beállítania. Elfogadja őket?
- Vezet: Hadd vigye, amerre jár!
- Я: A folyamat megváltozhat, és a visszamenőleges kompatibilitás elveszik. Valamilyen szemantikai verzióvezérlésre lesz szükség.
- Vezet: Jó ötlet!
- Я: Az eszközök manuálisan, a felhasználói felületen belül módosíthatók. Szükségünk lesz egy módra ennek ellenőrzésére és javítására.
…3 év múlva:
- Vezet: És terraformot kaptunk.
A történet morálja: még ha te is fejjel mindenben az Amazon, továbbra is valamit nem az AWS-től használ, és ezeknek a szolgáltatásoknak van olyan állapota, amely egy konfigurációs nyelvet használ az állapot szinkronizálására.
CloudFormation lambda vs git modules terraform
A lambda a CloudFormation megoldása az egyéni logikai problémára. A lambdával meg lehet vagy . Ez a megközelítés további bonyolultságokat vezet be, amelyek nincsenek jelen a git-modulok Terraform szemantikai verziójában. Számomra a legégetőbb probléma az összes felhasználói lambda (és ezek tucatnyi AWS-fiók) engedélyeinek kezelése volt. Egy másik fontos probléma volt a „mi volt előbb, a tyúk vagy a tojás?” probléma: ez a lambda kóddal függött össze. Ez a funkció maga infrastruktúra és kód, és maga is felügyeletet és frissítést igényel. Az utolsó szög a koporsóban a lambda kód módosításainak szemantikai frissítésének nehézsége volt; arra is ügyelnünk kellett, hogy a közvetlen parancs nélküli veremműveletek ne változzanak a futások között.
Emlékszem, egyszer egy Canary telepítést akartam létrehozni az Elastic Beanstalk környezethez egy klasszikus terheléselosztóval. A legegyszerűbb az lenne, ha az éles környezet mellett egy második üzembe helyezést is végrehajtana az EB-hez, és ezzel egy lépéssel tovább lépne: az automatikus skálázású canary telepítési csoportot a telepítési LB-vel kombinálja az éles környezetbe. És mivel a Terraform használja , ehhez 4 extra kódsorra lesz szükség a Terraformban. Amikor megkérdeztem, hogy van-e hasonló megoldás a CloudFormationben, egy teljes git-tárra mutattak, telepítési folyamattal és mindennel, mindezt valami olyasmi miatt, amit szegény 4 soros Terraform kód meg tud tenni.
Jobban érzékeli a sodródást
Győződjön meg arról, hogy a valóság megfelel az elvárásoknak.
egy nagyon hatékony műveleti kód funkció, mert segít biztosítani, hogy a valóság megfeleljen az elvárásoknak. Elérhető a CloudFormation és a Terraform segítségével is. De ahogy a gyártási halom nőtt, a CloudFormationben történő sodródás keresése egyre több hamis észlelést eredményezett.
A Terraform sokkal fejlettebb életciklusú horgokkal rendelkezik az elsodródás észleléséhez. Például beírja a parancsot közvetlenül az ECS-feladatdefinícióban, ha figyelmen kívül szeretné hagyni egy adott feladatmeghatározás módosításait anélkül, hogy figyelmen kívül hagyná a teljes ECS-telepítés módosításait.
CDK és a CloudFormation jövője
A CloudFormation kezelése nehéz nagy, több infrastruktúra léptékben. E nehézségek közül sok felismerhető, és az eszköznek ehhez hasonló dolgokra van szüksége , egy keretrendszer a felhő-infrastruktúra kódban történő meghatározásához és az AWS CloudFormation segítségével történő futtatásához. Érdekes lesz látni, mit hoz a jövő az aws-cdk számára, de nehéz lesz felvenni a versenyt a Terraform egyéb erősségeivel; ahhoz, hogy a CloudFormation naprakész legyen, globális változtatásokra lesz szükség.
Hogy a Terraform ne okozzon csalódást
Ez „az infrastruktúra mint kód”, és nem „mint szöveg”.
Az első benyomásom a Terraformról meglehetősen rossz volt. Azt hiszem, egyszerűen nem értettem a megközelítést. Szinte minden mérnök önkéntelenül olyan szövegformátumként érzékeli, amelyet a kívánt infrastruktúrává kell alakítani. NE CSINÁLJA ÍGY.
A jó szoftverfejlesztés közhelyei a Terraformra is érvényesek.
Láttam, hogy a Terraformban sok jó kód létrehozására alkalmazott gyakorlatot figyelmen kívül hagytak. Évekig tanultál, hogy jó programozó legyél. Ne add fel ezt az élményt csak azért, mert a Terraformmal dolgozik. A jó szoftverfejlesztés közhelyei a Terraformra vonatkoznak.
Hogyan lehet nem dokumentálni a kódot?
Hatalmas Terraform-halmazokat láttam, dokumentáció nélkül. Hogyan írhat kódot oldalakra - teljesen dokumentáció nélkül? Adja hozzá a szükséges dokumentációt kód Terraform (a hangsúly a „kódon”), miért olyan fontos ez a rész, és mit csinálsz.
Hogyan telepíthetünk olyan szolgáltatásokat, amelyek egykor egy nagy main() függvények voltak?
Nagyon összetett Terraform veremeket láttam egyetlen modulként bemutatva. Miért nem telepítünk szoftvereket így? Miért bontjuk fel a nagy függvényeket kisebbekre? Ugyanezek a válaszok érvényesek a Terraformra is. Ha a modulja túl nagy, akkor kisebb modulokra kell bontania.
Az Ön cége nem használ könyvtárakat?
Láttam, ahogy a mérnökök egy új projektet felpörgetve a Terraform segítségével ostobán másoltak be hatalmas darabokat más projektekből a sajátjukba, majd addig bütykölték őket, amíg az működni nem kezdett. Dolgoznál így a „harci” kóddal a cégedben? Nem csak könyvtárakat használunk. Igen, de hol vagyunk elvileg megosztott könyvtárak nélkül?!
Nem PEP8-at vagy gofmt-t használsz?
A legtöbb nyelv szabványos, elfogadott formázási sémával rendelkezik. Pythonban ez a PEP8. In Go - gofmt. A Terraformnak megvan a maga: terraform fmt. Élvezze egészsége érdekében!
Használja a Reactot a JavaScript ismerete nélkül?
A Terraform modulok leegyszerűsíthetik az Ön által létrehozott összetett infrastruktúra egy részét, de ez nem jelenti azt, hogy egyáltalán ne bütykölhetne vele. Helyesen szeretné használni a Terraformot anélkül, hogy megértené az erőforrásokat? Pusztulásra vagy ítélve: telik az idő, és soha nem fogod elsajátítani a Terraformot.
Singletonnal vagy függőségi injekcióval kódolsz?
A függőségi befecskendezés elismert bevált gyakorlat a szoftverfejlesztésben, és előnyben részesítik a singletonokkal szemben. Mennyire hasznos ez a Terraformban? Láttam Terraform modulokat, amelyek távoli állapottól függenek. Ahelyett, hogy olyan modulokat írna, amelyek lekérik a távoli állapotot, írjon egy olyan modult, amely paramétereket vesz fel. Ezután adja át ezeket a paramétereket a modulnak.
A könyvtáraid tíz dolgot csinálnak jól, vagy egy dolgot nagyszerűen?
A legjobban azok a könyvtárak működnek, amelyek egy olyan feladatra összpontosítanak, amelyet nagyon jól végeznek. Ahelyett, hogy nagyméretű Terraform modulokat írna, amelyek mindent egyszerre próbálnak meg csinálni, építsetek be olyan részeket, amelyek egy dolgot jól teljesítenek. Aztán szükség szerint kombináld őket.
Hogyan lehet módosítani a könyvtárakat visszamenőleges kompatibilitás nélkül?
Egy általános Terraform modulnak, akárcsak egy hagyományos könyvtárnak, valamilyen módon kommunikálnia kell a felhasználókkal a változásokról anélkül, hogy visszafelé kompatibilis lenne. Bosszantó, amikor ezek a változások a könyvtárakban történnek, és ugyanilyen bosszantó, ha nem visszafelé kompatibilis változtatásokat hajtanak végre a Terraform modulokban. A Terraform modulok használatakor javasolt a git tagek és a semver használata.
A termelési szolgáltatás a laptopján vagy egy adatközpontban fut?
A Hashicorp olyan eszközökkel rendelkezik, mint hogy megfuttassa a terraformját. Ezek a központosított szolgáltatások megkönnyítik a terraform változtatások kezelését, auditálását és jóváhagyását.
Te nem írsz teszteket?
A mérnökök felismerik, hogy a kódot tesztelni kell, de ők maguk gyakran megfeledkeznek a tesztelésről, amikor a Terraformmal dolgoznak. Az infrastruktúra szempontjából ez árulkodó pillanatokkal jár. Azt tanácsolom, hogy „teszteljen” vagy „hozzon létre példa” veremeket olyan modulok használatával, amelyek megfelelően telepíthetők a CI/CD során történő teszteléshez.
Terraform és mikroszolgáltatások
A mikroszolgáltatással foglalkozó cégek élete és halála az új mikroszolgáltatási munkacsoportok sebességétől, innovációjától és megszakításától függ.
A mikroszolgáltatási architektúrákkal kapcsolatos leggyakoribb negatív szempont, amelyet nem lehet kiküszöbölni, a munkához kapcsolódik, nem a kódhoz. Ha úgy gondolja, hogy a Terraform csak egy módja annak, hogy egy mikroszolgáltatási architektúra infrastrukturális oldalát automatizálja, akkor elszalasztja a rendszer valódi előnyeit. Most már az .
Forrás: will.com