Úgy tűnik, hogy a Terraform fejlesztői elég kényelmes legjobb gyakorlatokat kínálnak az AWS-infrastruktúrával való munkához. Csak van egy apró bökkenő. Idővel a környezetek száma növekszik, mindegyikben megjelennek a sajátosságok. Szinte ugyanannak az alkalmazásstáknak a másolata jelenik meg egy szomszédos régióban. A Terraform kódot gondosan másolni és a új követelményeknek megfelelően szerkeszteni kell, vagy készíteni kell egy hópelyhet.
Az én előadásom a Terraform mintázatairól szól, amelyek segítenek a káosz és a kézi rutinfeladatok leküzdésében nagyobb és hosszú távú projektek esetén.
Videó:
40 éves vagyok, 20 éve dolgozom az IT területén. 12 éve az Ixtens cégnél dolgozom. Ecommerce-alapú fejlesztéssel foglalkozunk. Az elmúlt 5 évben DevOps gyakorlatokat folytatok.
A történetem egy projektről szól, egy olyan cégnél, amelynek a nevét nem fogom elmondani, a titoktartási megállapodásra hivatkozva.
A dián látható számok arra szolgálnak, hogy érzékeljük a projekt nagyságát. Minden, amiről ezután beszélni fogok, Amazonnal kapcsolatos.
Négy évvel ezelőtt csatlakoztam ehhez a projekthez. Pont a legnagyobb fordulópontnál zajlott az infrastruktúra refaktorálása, mert a projekt növekedett. Azok a minták, amelyeket használtunk, már nem voltak megfelelőek. Figyelembe véve a projekt tervezett növekedését, valami újat kellett kitalálni.
Köszönet Matvéjnek, aki tegnap elmondta, mi történt a Dodo Pizzánál. Ez az, ami nálunk négy éve történt.
A fejlesztők bejöttek, és kezdték írni az infrastruktúrával kapcsolatos kódot.
A legnyilvánvalóbb okok közé tartozik, hogy szükség volt a piacon való megjelenés (time to market) felgyorsítására. Biztosítani kellett, hogy a DevOps csapat ne legyen szűk keresztmetszet a kiadás során. Ráadásul az első szinten a Terraformot és a Puppe-t használták.
A Terraform a HashiCorp nyílt forráskódú projektje. És azok számára, akik nem tudják, hogy mi ez, az elkövetkező néhány dia.
Az infrastruktúra mint kód azt jelenti, hogy leírhatjuk az infrastruktúránkat, és megkérhetjük a különféle robotokat, hogy biztosítsák számunkra azokat az erőforrásokat, amelyeket leírtunk.
Például szükségünk van virtuális gép. Leírjuk, hozzáadunk néhány kötelező paramétert.
Ezután a konzolon beállítjuk az Amazonhoz való hozzáférést. Kérjük, a Terraform tervet (plan). A Terraform terv azt fogja mondani: „Rendben, az Ön erőforrásához ilyen dolgokat tudunk csinálni.” És legalább egy erőforrás hozzá fog adódni. És nem várható változás.
Miután minden rendben van, kérheti a Terraform alkalmazását, és a Terraform létrehoz egy példányt, így megkapja a virtuális gépet a felhőjében.
A projekt tovább fejlődik. Változtatásokat adunk hozzá. További példányokat kérünk, 53 bejegyzést adunk hozzá.
Ismételjük meg. Kérjük a tervet. Látjuk, milyen változások tervezettek. Alkalmazzuk. Így nő az infrastruktúránk.
A Terraform használ egy úgynevezett állapotfájlt. Azaz minden változtatást, ami az Amazonra kerül, egy fájlban tárol, ahol minden egyes leírt erőforráshoz tartoznak az Amazonban létrehozott megfelelő erőforrások. Így amikor egy erőforrás leírását megváltoztatjuk, a Terraform pontosan tudja, mit kell módosítani az Amazonban.
Ezek az állapotfájlok eredetileg csak sima fájlok voltak. Gitben tároltuk őket, ami rendkívül kényelmetlen volt. Folyamatosan elfelejtette valaki a változtatásokat elkövetni, és sok konfliktus merült fel.
Most lehetőség van backend használatára, azaz a Terraform megmondja, hogy melyik bucketbe, milyen kulccsal kell az állapotfájlt menteni. A Terraform magától gondoskodik róla, hogy előhívja az állapotfájlt, elvégezze a varázslatot, és visszahelyezze a végső eredményt.
Nő az infrastruktúránk. Itt a kódunk. Most már nem csak virtuális gépet szeretnénk létrehozni, hanem tesztkörnyezetet akarunk.
A Terraform lehetővé teszi modulok létrehozását, azaz azonos leírások rögzítését egy mappában.
Például a tesztelés során meghívhatjuk ezt a modulot, és ugyanazt kapjuk, mintha a Terraform alkalmazását végeznénk a modulban. A teszteléshez ilyen kódra lesz szükség.
A termeléshez küldhetünk bármilyen változást, mivel a teszteléshez nem szükségesek nagy példányok, a termeléshez viszont hasznosak a nagy példányok.
Ezután visszatérek a projekthez. Bonyolult feladat volt, mivel az infrastruktúrát nagyon nagyra terveztük. Valahogy rendezni kellett a teljes kódot, hogy kényelmes legyen mindenki számára: azoknak, akik karbantartják a kódot, és azoknak, akik változtatásokat végeznek rajta. Úgy terveztük, hogy bármilyen fejlesztő elmehet és módosíthatja az infrastruktúrát, ahogyan szükséges a platformjának egyes részeihez.
Ez a könyvtári struktúra, amelyet a HashiCorp ajánl, ha nagy projektje van, és érdemes az egész infrastruktúrát kis darabokra osztani, minden darabot külön mappában leírni.
A kiterjedt erőforrás könyvtár segítségével a tesztelés és a termelés során körülbelül ugyanazt lehet hívni.
Ebben az esetben nem éppen volt megfelelő, mert a fejlesztők vagy a teszteléshez szükséges tesztkészletet egyszerűbb módon kellett megkapni. Nem akartunk az mappák között járkálni, alkalmazni a szükséges sorrendben, és aggódni amiatt, hogy az adatbázis fel fog állni, aztán egy példány, amely ezt az adatbázist használja, is fel fog állni. Ezért az egész tesztelést egy mappából indítottuk. A legtöbb modul itt lett behívva, de az összes futtatás egy lépésben történt.
A Terraform gondoskodik az összes függőségről. Mindig olyan sorrendben hozza létre az erőforrásokat, hogy például IP-címet kaphassunk egy frissen létrehozott példányból, és ezt az IP-címet a route53 rekordban is fel lehessen használni.
Ezen kívül a platform nagyon nagy. A tesztkészlet indítása, akár egy órára is, akár 8 órára – elég költséges feladat.
Azt is automatizáltuk. A Jenkins feladat lehetővé tette a készlet indítását. Itt pull requestet kellett indítani a változtatásokkal, amelyeket a fejlesztő tesztelni akart, megadva az összes szükséges opciót, összetevőt és méretet. Ha teljesítménytesztelésre van szüksége, akkor több példányt vehet. Ha csak azt akarja ellenőrizni, hogy egy űrlap megnyílik, akkor minimális beállításokkal indíthatja. Azt is meg lehetett adni, hogy szükség van-e klaszterre vagy sem, stb.
A Jenkins pedig tolta a shell-skriptet, amely kicsit módosította a kódot a Terraform mappában. Eltávolította a felesleges fájlokat és hozzáadta a szükséges fájlokat. Ezután a Terraform apply egy lépésben emelte fel a készletet.
A további lépések már mások voltak, amelyekbe nem szeretnék részletesebben belemenni.
Mivel a teszteléshez kicsit több opcióra volt szükség, mint a termelés esetében, kénytelenek voltunk másolatokat készíteni a modulokról, hogy ezekben a másolatokban hozzáadhassuk azokat a funkciókat, amelyek csak a teszteléshez szükségesek.
Így történt, hogy a tesztelés során úgy tűnt, hogy azokat a változásokat szeretnénk tesztelni, amelyek végül a termelésre mennek. De valójában egy dolgot teszteltünk, míg a termelésben egy kicsit más alkalmazásra került sor. Volt egy kis eltérés a mintázatban, hogy a termelésben minden változást a működtetési csapat alkalmazott. Néha előfordult, hogy azok a változások, amelyeknek át kellett volna menniük a tesztelésből a termelésbe, egy másik verzióban maradtak.
Ezen kívül volt egy probléma, hogy egy új szolgáltatás került bevezetésre, amely kicsit eltért egy már létezőtől. Ahelyett, hogy a meglévő modult módosítottuk volna, a másolatát kellett elkészíteni, és hozzáadni a szükséges változtatásokat.
Tulajdonképpen a Terraform nem valódi nyelv. Ez egy deklaráció. Ha valamit deklarálni akarunk, akkor azt deklaráljuk. És minden működik.
Egy pillanatban, amikor az egyik pull request-emről beszélgettünk, az egyik kollégám azt mondta, hogy nem kellene hópelyheket szaporítani. Érdeklődtem, mire gondol. Van egy tudományos tény, hogy a világban nincs két egyforma hópehely, mindegyik kicsit eltér. És amint ezt meghallottam, azonnal megtapasztaltam a Terraform-kód súlyát. Mert amikor verzióról verzióra kellett lépni, a Terraform megszakító lánc változtatásokat követelt, azaz a kód többé már nem volt kompatibilis a következő verzióval. Így olyan pull requestet kellett készíteni, amely szinte a fájlok felét lefedte az infrastruktúrában, hogy az infrastruktúrát a Terraform következő verziójára hozzuk.
És miután megjelent egy ilyen hópehely, az összes meglévő Terraform-kódunk egy hatalmas hókupaccá vált.
A külső fejlesztő számára, aki kívül van az operation-en, ennek nem nagy jelentősége van, mert készített egy pull request-et, az ő erőforrása elindult. És ennyi, ez már nem az ő gondja. A DevOps csapatnak, akik figyelik, hogy minden rendben legyen, mindezeket a változtatásokat meg kell csinálnia. És ezeknek a változásoknak a költsége nagyon-nagyon megemelkedett minden egyes új hópehellyel.
Van egy történet arról, hogyan rajzol egy diák krétával a táblára két tökéletes kört a szemináriumon. A tanár meglepődik, hogyan sikerült neki ilyen pontosan, körző nélkül rajzolnia. A diák válasza: „Nagyon egyszerű, két évet a hadseregben töltöttem a húsdaráló forgatásával.”
A négy évből, amelyben részt veszek ebben a projektben, körülbelül két éve foglalkozom a Terraformmal. És persze, van néhány trükköm, néhány tanácsom, hogyan lehet egyszerűsíteni a Terraform-kódot, úgy dolgozni vele, mint egy programozási nyelvvel, és csökkenteni a fejlesztők terhelését, akiknek ezt a kódot naprakészen kell tartaniuk.
Ami a Symlinkekkel kezdődik, az a Terraform. A Terraformban sok ismétlődő kód található. Például a provider hívása szinte mindenhol, ahol egy infrastruktúra darabot létrehozunk, ugyanaz. Így ésszerű, hogy külön mappába helyezzük. És mindenhol, ahol szükséges, a provider számára Symlinkeket kell létrehozni erre a fájlra.
Például, ha a produkciós környezetben használt assume role lehetővé teszi, hogy jogosultságokat szerezzünk egy külső Amazon-fiókhoz. Ha megváltoztatunk egy fájlt, az összes többi, amely a forrástérfában van, megkapja a szükséges jogosultságokat, hogy a Terraform tudja, melyik Amazon szegmenshez kell fordulnia.
Hol nem működnek a Symlinkek? Ahogy mondtam, a Terraform állományfájlokat használ. És ezek nagyon-nagyon klasszak. De a lényeg az, hogy a Terraform az első lépésben inicializálja a backendet. És nem használhat semmilyen változót ezekben a paraméterekben, azokat mindig szövegként kell megadni.
Így amikor valaki új erőforrást hoz létre, a kód egy részét más mappákból másolja. És hibázhat a kulccsal vagy a bucket-tel. Például a sandboxból készít egy sandbox dolgot, majd átkapcsol a produkcióra. Így előfordulhat, hogy a produkciós bucket a sandboxból kerül felhasználásra. Persze, ezt gyorsan észreveszik. Lehet, hogy javítani tudják, de ettől függetlenül ez idő- és erőforráspazarlás.
Mit tehetünk ezután? Mielőtt a Terraformmal dolgoznánk, inicializálni kell. Az inicializálás során a Terraform letölti az összes plugint. Ezek egy időben monolitból mikroservices architektúrára estek szét. Mindig meg kell csinálni a Terraform init-et, hogy lehúzza az összes modult, az összes plugint.
Használhatunk egy shell-scriptet, amely először is, képes kiolvasni az összes változót. A shell-scriptnek nincsenek korlátai. Másodszor, az utak. Ha mindig azt az utat használjuk, amely a repóban van, mint kulcs az állományfájlhoz, így a hiba kizárt.
Honnan szerezzük az adatokat? JSON-fájl. A Terraform lehetővé teszi, hogy az infrastruktúrát ne csak hcl (HashiCorp Configuration Language) formátumban, hanem JSON-ban is rögzítsük.
A JSON könnyen olvasható a shell-scriptekből. Ennek megfelelően elhelyezhetjük a konfigurációs fájlt a buckethez. És ezt a bucketet használhatjuk a Terraform kódban és a shell-scriptben az inicializáláshoz.
Miért fontos, hogy legyen egy bucket a Terraform számára? Mert létezik egy dolog, amit remote state fájloknak hívunk. Azaz, amikor egy erőforrást hozok létre, ahhoz, hogy azt mondhassam az Amazonnak: „Kérlek, indíts el egy instance-t”, nagyon sok kötelező paramétert kell megadnom.
Ezeket az azonosítókat egy másik mappában tárolják. És azt mondhatom: „Terraform, kérlek, fuss el a megfelelő erőforrás state fájljába, és hozd ki nekem ezeket az azonosítókat.” Így egyfajta egységesítés jön létre a különböző régiók vagy környezetek között.
Nem mindig használható távoli state fájl. Például, amikor manuálisan hoztunk létre egy VPC-t. És az a Terraform kód, amely a VPC-t hozza létre, olyan mértékben eltérő VPC-t hoz létre, hogy nagyon hosszú időbe telik majd az egyiket a másikhoz igazítani, ezért használhatunk egy következő trükköt.
Azaz készítsünk egy modult, amely úgy tesz, mintha VPC-t készítene, és egyfajta azonosítókat adna át nekünk, de valójában van egy fájl benne, keménykódolt értékekkel, amelyet fel lehet használni ugyanannak az instance-nek a létrehozásához.
Nem mindig szükséges a state fájlt a felhőben tárolni. Például, amikor modulokat tesztelünk, használhatunk backend inicializációt, amikor a fájl csak a lemezen lesz tárolva a tesztelés ideje alatt.
Most egy kicsit a tesztelésről. Mit lehet tesztelni a Terraform-ban? Valószínűleg sok mindent, de én ezekről a 4 dologról fogok beszélni.
A HashiCorpnak van egy elképzelése arról, hogyan kell formázni a Terraform kódot. A Terraform fmt lehetővé teszi számodra, hogy a szerkesztett kódodat ennek az elképzelésnek megfelelően formázd. Ezért a teszteknek feltétlenül ellenőrizniük kell, hogy a formázás megfelel-e a HashiCorp által előírtaknak, hogy ne kelljen megváltoztatni a zárójelek elhelyezését stb.
A következő a Terraform validate. Ez egy kicsit többet csinál, mint a szintaxis ellenőrzése — mint például, hogy minden zárójel párba van-e állítva. Mi itt a fontos? Az infrastruktúránk nagyon széleskörű. Nagyon sok különböző mappa található benne. És mindegyikre le kell futtatni a Terraform validate-et.
Tehát, hogy felgyorsítsuk a tesztelést, párhuzamosan több folyamatot indítunk, kihasználva a párhuzamosságot.
A párhuzamosság egy nagyon klassz dolog, használjátok.
De minden alkalommal, amikor a Terraform inicializálásra kerül, elmegy a HashiCorp-ra és megkérdezi: „Mik az utolsó plugin verziók? Az a plugin, ami a cache-ben van – az az-e vagy nem?” Ez pedig minden lépésnél késleltetést okoz.
Ha a Terraform-ot tájékoztatják arról, hol találhatóak a pluginok, akkor a Terraform megmondja: „Rendben, valószínűleg ez a legfrissebb, ami van. Nem megyek sehová, azonnal elkezdem validálni a Terraform kódodat.”
Ahhoz, hogy a megfelelő pluginokkal töltsük fel a mappát, van egy nagyon egyszerű Terraform-kódunk, amit csak inicializálni kell. Itt természetesen fel kell tüntetni az összes szolgáltatót, aki részt vesz a kódodban, különben a Terraform azt mondja: „Nem ismerem ezt a szolgáltatót, mert nincs a cache-ben.”
A következő lépés a Terraform terv. Ahogy mondtam, a fejlesztés ciklikus. Kódot készítünk változtatásokkal. És utána meg kell tudni, hogy milyen változások tervezettek az infrastruktúrára.
És amikor az infrastruktúra nagyon-nagyon nagy, lehet kicserélni egy modult, megjavítani valamilyen tesztkörnyezetet vagy egy adott régiót, és tönkretenni egy szomszédos részt. Ezért a Terraform tervet az egész infrastruktúrára kell készíteni, és meg kell mutatnia, hogy milyen változások tervezettek.
Ezt okosan is lehet csinálni. Például írtunk egy Python szkriptet, ami megoldja a függőségeket. És attól függően, hogy mi változott: Terraform modul vagy valamilyen konkrét komponens, terveket készít az összes függő mappára.
A Terraform tervet kérésre kell készíteni. Legalábbis ezt csináljuk mi.
Természetesen jó tesztelni minden változtatásnál, minden elkötelezésnél, de a tervek – ezek elég drága dolgok. És mi a pull requestben azt mondjuk: „Kérlek, adj nekem terveket”. Elindul egy robot, és megküldi a megjegyzésekben vagy mellékletként az összes tervet, ami a változtatásaidból adódik.
A terv – elég drága dolog. Időt vesz igénybe, mert a Terraform elmegy az Amazonra és megkérdezi: „Még létezik ez az instance? Ennek az autoscale-nek biztosan ilyen paraméterei vannak?” És annak érdekében, hogy ezt felgyorsítsuk, használhatjuk a refresh=false paramétert. Ez azt jelenti, hogy a Terraform az S3-ból fogja lekérni az állapotot. És hinni fogja, hogy az állapot pontosan megfelel annak, ami az Amazonban található.
Ez a Terraform terv sokkal gyorsabb, de az állapotnak meg kell felelnie az infrastruktúrájának, azaz valahol, valamikor futtatnia kell a Terraform refresh-t. A Terraform refresh pontosan azt csinálja, hogy az állapot megfeleljen annak, ami a tényleges infrastruktúrában található.
És beszélni kell a biztonságról. Ezt kellett volna kezdeni. Ott, ahol futtatja a Terraform-ot, és a Terraform az infrastruktúrájával dolgozik, van egy sebezhetőség. Azaz lényegében kódot futtat. És ha a pull request olyan rosszindulatú kódot tartalmaz, akkor ez végrehajtható egy olyan infrastruktúrán, amelynek túl sok hozzáférése van. Ezért legyünk óvatosak, hol futtatjuk a Terraform tervet.
A következő téma, amiről szeretnék beszélni, a user-data tesztelése.
Mi az a user-data? Az Amazonnál, amikor instance-ot hozunk létre, küldhetünk egy levelet az instance-ból - meta-adatokat. Amikor az instance elindul, a cloud init általában mindig jelen van ezeken az instance-okon. A cloud init elolvassa ezt a levelet, és azt mondja: „Rendben, ma én egy load balancer vagyok”. És ezeknek az utasításoknak megfelelően alakulnak az események.
De sajnos, amikor Terraform tervet és Terraform alkalmazást végzünk, a user-data úgy néz ki, mint egy ilyen számokból álló pép. Azaz csak egy hash-t küld el Önnek. És amit a tervben nézhet, az az, hogy lesznek-e változások, vagy a hash ugyanaz marad.
Ha erre nem figyelünk, akkor az Amazonra, a tényleges infrastruktúrára egy sérült szövegfájl is távozhat.
Alternatív megoldásként a végrehajtás során megadhatjuk nem az egész infrastruktúrát, hanem csak a template-et. És a kódban azt mondhatjuk: „Kérlek, jelenítsd meg nekem ezt a template-et”. Így végül kinyomtathatjuk, hogy hogyan fog megjelenni az adatai az Amazonon.
Egy másik lehetőség, hogy modulokat használunk a user-data generálására. Alkalmazza ezt a modult. Kap egy fájlt a lemezen. Összehasonlítja a referencia fájllal. Így, ha egy junior kicsit módosítani próbál a user-data-n, a tesztjei azt fogják mondani: „Rendben, itt és itt vannak változások - ez rendben van”.
A következő téma, amiről szeretnék beszélni, az Automate Terraform apply.
Természetesen meglehetősen ijesztő a Terraform apply automatizált módon történő végrehajtása, mert ki tudja, milyen változások jöttek, és mennyire lehetnek károsak az élő infrastruktúrára.
A tesztkörnyezet esetében ez teljesen rendben van. Vagyis a feladat, amely létrehozza a tesztkörnyezetet, az minden fejlesztő számára szükséges. És az olyan kifejezés, mint a „minden működött” – ez nem vicces mém, hanem bizonyíték arra, hogy az illető megoldotta a problémát, felállította a stack-et, futtatta a teszteket ezen a stack-en. És megerősítette, hogy minden rendben van, és azt mondta: „Rendben, az a kód, amelyet kiadok, tesztelve lett.”
A production, sandbox és más környezetek esetében, amelyek fontosabbak a vállalat számára, a források egy részét biztonságosan lehet alkalmazni, mert ez nem vezet ahhoz, hogy bárki meghal. Ezek lehetnek: autoscale csoportok, security csoportok, szerepek, route53, és a lista elég hosszú lehet. De figyeljetek arra, hogy mi történik, olvassátok az automatikus alkalmazásokról szóló jelentéseket.
Ahol a használat veszélyes vagy ijesztő, például, ha ez valamilyen eljárás a persistent forrásokkal, adatbázisokkal kapcsolatos, akkor kérjetek jelentéseket arról, hogy az infrastruktúrában van-e alkalmazásra váró módosítás. Az engineer már felügyelt környezetben indítja a feladatokat, hogy alkalmazza őket, vagy saját konzolján végzi el.
Az Amazonban van egy olyan dolog, mint a Terminate protection. Ez bizonyos esetekben megvédhet a nem kívánt módosításoktól. Vagyis a Terraform bemegy az Amazonba, és azt mondja: „Meg kell ölnöm ezt az instance-t, hogy újat készítsek.” Az Amazon pedig azt válaszolja: „Sajnálom, nem ma. Van Terminate protection nálunk.”
A torta teteje pedig a kód optimalizálása. Amikor a Terraform kóddal dolgozunk, nagyon sok paramétert kell átadnunk a modulnak. Ezek azok a paraméterek, amelyek szükségesek ahhoz, hogy létrehozzunk egy forrást. A kód pedig nagy paraméterlistákká alakul, amelyeket modulról modulra kell átadni, különösen, ha a modulok beágyazottak.
Ez pedig nagyon nehezen olvasható. Nagyon nehéz áttekinteni. Nagyon gyakran előfordul, hogy egyes paraméterek átmennek az áttekintésen, és nem pontosan azok, amelyekre szükség van. Ennek javítása időbe és pénzbe kerül később.
Ezért ajánlom nektek, hogy használjatok egy olyan megoldást, mint a bonyolult paraméter, amely tartalmaz egy értékfát. Vagyis szükségetek van egy mappára, ahol meg vannak adva azok az értékek, amelyeket szeretnétek látni egy adott környezetben.
Ezzel a modul segítségével egy olyan fát kaphatunk, amely egy általános modulban generálódik, azaz egy olyan általános modulban, amely minden infrastruktúrára egyformán működik.
Ebben a modulban elvégezhet bizonyos számításokat, használva a Terraform egyik új funkcióját, a locals-t. Ezután egy output segítségével kiadhatunk egy összetett paramétert, amely tartalmazhat hasht, tömböket stb.
Ezek voltak az utolsó legjobb felfedezéseim. Szeretném megosztani egy történetet Kolumbuszról. Amikor pénzt keresett expedíciójára, hogy felfedezze Indiát (ahogyan akkor gondolta), senki nem hitt neki, és azt mondták, hogy ez lehetetlen. Akkor azt mondta: "Tegye úgy, hogy a tojás ne essen le." Minden bankár, nagyon gazdag és valószínűleg okos ember megpróbálta valahogy megdönteni a tojást, de az folyamatosan leesett. Akkor Kolumbusz vette a tojást, egy kicsit megnyomta. A héj megszorult, és a tojás mozdulatlan maradt. Azt mondták: "Ó, ez túl egyszerű!". Kolumbusz válaszolt: "Igen, ez túl egyszerű. Amikor felfedezem Indiát, mindenki ezt a kereskedelmi útvonalat fogja használni."
Amit most elmondtam, azok valószínűleg viszonylag egyszerű és trivialis dolgok. Amikor tudomást szerzel róluk és elkezded használni, ez magától értetődő. Használjátok őket. És ha számotokra ezek teljesen normális dolgok, akkor legalább tudjátok, hogyan állítsátok fel a tojást, hogy ne essen le.
Összefoglalva:
- Próbálja elkerülni a hópehely problémákat. Minél kevesebb hópehely van, annál kevesebb erőforrásra lesz szüksége a nagy infrastruktúrájában történt változások kezelésére.
- Folyamatos változtatások. Azaz, amikor a kódban valami változás történik, a lehető leggyorsabban korszerűsíteni kell az infrastruktúráját ezekkel a változtatásokkal. Nem lehet olyan helyzet, hogy valaki két-három hónap múlva jön, hogy megnézze az Elasticsearch-t, csinál egy Terraform plan-t, és ott rengeteg váratlan változás található. Nagy időt igényel, hogy visszaállítsuk mindent rendbe.
- Tesztelés és automatizálás. Minél több kód van lefedve tesztekkel és funkciókkal, annál nagyobb a bizalom, hogy mindent helyesen csinál. Az automatikus szállítás többszörös bizalmat fog növelni.
- A teszt- és a termelési környezet kódja gyakorlatilag azonos kell, hogy legyen. Gyakorlatilag, mert a termelési környezet egy kicsit más, és ott mindig lesznek olyan részletek, amelyek túllépnek a tesztkörnyezet keretein. De mindenesetre plusz-mínusz ezt lehet biztosítani.
- És ha nagyon sok Terraform-kódod van, és ennek a kódnak a karbantartása nagyon sok időt vesz igénybe, sosem késő refaktorálni és jó formába hozni azt.
- Immutable infrastruktúra. AMI szállítása ütemezés szerint.
- Struktúra a route53-hoz, amikor nagyon sok bejegyzésed van, és szeretnéd, ha azok rendezett sorrendben lennének.
- Harcolni az API sebességkorlátozásokkal. Ez amikor Amazon azt mondja: "Minden, nem tudok több kérést fogadni, kérlek várj egy kicsit". És a cég fele vár, míg elindíthatja az infrastruktúráját.
- Spot példányok. Az Amazon nem olcsó, és a spotok rengeteget spórolhatnak. Erről egész előadást lehetne tartani.
- Biztonság és IAM szerepkörök.
- Elveszett erőforrások keresése, amikor az Amazonban vannak ismeretlen eredetű példányok, amelyek pénzt költenek. Még ha egy példány havi 100-150 dollárt is ér, az évente több mint 1000 dollár. Az ilyen erőforrások keresése jövedelmező üzlet.
- És a fenntartott példányok.
Ennyit rólam. A Terraform nagyon klassz, használjátok. Köszönöm!
Kérdések
Köszönjük az előadást! Az állományod az S3-ban van, de hogyan oldjátok meg azt a problémát, ha többen is megpróbálják letölteni ezt az állományt és átállni?
Először is, nem sietünk. Másodszor, vannak flags, amivel jelezzük, hogy egy kód egy részén dolgozunk. Azaz, bár az infrastruktúra nagyon nagy, ez nem jelenti azt, hogy folyamatosan valaki valamit alkalmaz. Amikor aktív fázis volt, ez probléma volt, az állományaink a Git-ben tárolódtak. Ez fontos volt, különben valaki létrehoz egy állományt, és nekünk manuálisan kellett összeszednünk őket, hogy minden további folytatódhasson. Most ilyen probléma nincs. Egyébként a Terraform megoldotta ezt a feladatot. Ha folyamatosan változik valami, akkor használhatók a zárolások, amelyek megakadályozzák, amiről beszéltél.
Ti az ingyenes verziót vagy az enterprise-t használjátok?
Nincs enterprise, azaz minden, amit ingyen el lehet tölteni.
A nevem Sztanyiszláv. Szerettem volna egy kis kiegészítést tenni. Beszéltél az Amazon funkciójáról, amely lehetővé teszi, hogy az instance ne lehessen elpusztítani. Ez a Terraform-ban is megtalálható, a Life Second blokkban meg lehet határozni a módosítás vagy az eltávolítás megszorítását.
Időben korlátozva voltam. Jó megjegyzés.
Még két dolgot szerettem volna megkérdezni. Először is, beszéltél a tesztelésről. Használtál valamilyen tesztelő eszközt? Hallottam a Test Kitchen pluginról. Lehet, hogy van még valami. És szeretném még megkérdezni a Local Values-ról. Miben különböznek az Input Variables-tól? És miért nem tudok valamit csak Local Values-on keresztül paraméterezni? Próbáltam megérteni ezt a témát, de valahogy nem sikerült.
Részletesebben beszélhetünk erről a teremben. A tesztelő eszközeink teljesen házi készítésűek. Nincs semmi, amivel tesztelni lehessen. Általában vannak olyan lehetőségek, amikor az automatikus tesztek felszedik az infrastruktúrát valahol, ellenőrzik, hogy rendben van-e, majd mindent elpusztítanak egy jelentéssel, hogy az infrastruktúrád még mindig jó állapotban van. Nálunk ez nincs, mert a tesztelő kötegek minden nap futnak. Ez elegendő. Ha valami elkezd romlani, akkor az úgyis el fog romlani anélkül, hogy máshol ellenőriznénk.
A Local Values-ról folytassuk a beszélgetést a teremben.
Helló! Köszönöm a beszámolót! Nagyon tanulságos. Azt mondtad, hogy nagyon sok hasonló kódotok van az infrastruktúra leírására. Nem fontolgattátok a kód generálásának lehetőségét?
Kiváló kérdés, köszönöm! Az a helyzet, hogy amikor infrastruktúrát kód formájában használunk, feltételezzük, hogy megnézzük a kódot, és megértjük, milyen infrastruktúra rejlik mögötte. Ha a kódot generálják, akkor meg kell értenünk, hogy milyen kódot fognak generálni, hogy tudjuk, milyen infrastruktúra lesz ott. Vagy generálunk egy kódot, elkötelezzük azt, és lényegében ugyanazt kapjuk. Ezért azon az úton indultunk el, ahogyan megírtuk, ezzel megkaptuk. Ráadásul a generátorok később jelentek meg, amikor elkezdtük csinálni. Már késő volt váltani.
Hallottál a jsonnet-ről?
Nem.
Nézd, ez egy nagyon klassz dolog. Látom, hogy van egy konkrét eset, ahol alkalmazni lehet és generálni adatstruktúrát.
A generátorok jók, mint a vicc a borotvára. Azaz, az első alkalommal mindenki arca eltérő, de utána mindenkinek ugyanaz az arca. A generátorok nagy sikert arattak. De sajnos, nálunk az arcok kicsit eltérőek. Ez probléma.
Csak nézd. Köszönöm!
Maxim vagyok, a Sberbanktól. Kicsit meséltetek arról, hogy megpróbáltátok a Terraformot egy programozási nyelv analógjára hozni. Nincs egyszerűbb használni az Ansible-t?
Ezek nagyon különböző dolgok. Az Ansible-lel is lehet erőforrásokat létrehozni, és a Puppet is tud erőforrásokat létrehozni az Amazonban. De a Terraform kifejezetten erre készült.
Csak Amazonotok van?
Nem arról van szó, hogy csak Amazonunk van. Szinte csak Amazonunk van. De a kulcsfontosságú funkció az, hogy a Terraform emlékszik. Az Ansible-nél, ha azt mondod: „Hozz létre 5 példányt”, akkor az létrehozza, majd te mondod: „Most 3 kellene”. A Terraform azt mondja: „Oké, kettőt törlök”, míg az Ansible azt mondja: „Oké, itt van 3”. Összesen 8.
Üdvözlöm! Köszönöm a prezentációját! Nagyon érdekfeszítő volt hallani a Terraformról. Azonnal szeretném megemlíteni, hogy a Terraformnak nincs stabil kiadása, ezért nagyon óvatosan bánjon vele.
Jó étkezéshez jó kanál. Azaz, ha szükséged van egy megoldásra, akkor néha el kell halasztanod azt, ami instabil stb., de működik és nekünk segített.
A kérdésem az, hogy használjátok a Remote backendet, használjátok az S3-at. Miért nem használjátok a hivatalos backendet?
Hivatalos?
Terraform Cloud.
Mikor jelent meg?
Körülbelül 4 hónapja.
Ha 4 évvel ezelőtt jelent volna meg, akkor valószínűleg válaszoltam volna a kérdésedre.
Már van beépített funkciója a zárolásoknak, és tárolhatod a state fájlt. Próbáld ki. De én sem teszteltem.
Nagy vonaton utazunk, ami nagy sebességgel halad. Nem lehet csak úgy kidobni néhány kocsit.
Az időjárásról beszéltetek, miért nem használtátok a branch-t? Miért nem sikerült így megoldani?
Nálunk az a megközelítés, hogy az egész infrastruktúra egy repóban van. A Terraform, Puppet, minden script, ami kapcsolódik ehhez, mind egy repóban van. Így garantálni tudjuk, hogy az inkrementális változások egymás után tesztelve vannak. Ha ez sok branche lenne, akkor egy ilyen projektet gyakorlatilag lehetetlen karbantartani. Fél év telik el, és annyira eltérőek lesznek, hogy ez valami büntetés. Ez az, amiből menekülni akartam a refaktorálás előtt.
Azaz, ez nem működik?
Ez egyáltalán nem működik.
A branch-en kivágtam a mappa diáit. Vagyis, ha minden tesztelési stackhez csinálunk egy külön mappát, például az A csapatnak van egy mappája, a B csapatnak meg a sajátja, akkor ez sem működik. Készítettünk egy egységesített kódot a tesztkörnyezethez, ami elég rugalmas volt ahhoz, hogy mindenki számára megfelelő legyen. Vagyis egy kódot kezeltünk.
Helló! Az én nevem Jura! Köszönöm az előadást! Kérdésem van a modulokról. Önök azt mondják, hogy modulokat használnak. Hogyan oldják meg, ha az egyik modulban módosításokat végeznek, amelyek nem kompatibilisek egy másik személy változtatásaival? Valamilyen módon verzionálják a modulokat, vagy próbálnak egy bonyolult megoldást hozni, hogy megfeleljenek a két követelménynek?
Ez egy nagy hókupac problémája. Ezt szenvedjük el, amikor egy ártalmatlan változtatás tönkretehet egy részét az infrastruktúrának. És ez csak hosszú idő elteltével lesz észlelhető.
Vagyis jelenleg semmilyen módon nem oldódik meg?
Univerzális modulokat hoznak létre. Kerüljék a hópehely megoldásokat. És minden rendben lesz. Az előadás második fele arról szól, hogyan lehet ezt elkerülni.
Üdvözlöm! Köszönöm az előadást! Szeretném pontosítani. A háttérben maradt egy nagy kupac, amiért eljöttem. Hogyan integrálódnak a Puppet és a szerepkiosztás?
User-data.
Vagyis egyszerűen kiveti a fájlt, és valahogy végrehajtja?
A User-data egy megjegyzés, vagyis amikor klónozunk egy képet, akkor elindul egy Daemon, és próbálja kideríteni, hogy ki ő, olvassa a megjegyzést, hogy ő load balancer.
Vagyis ez valamilyen külön folyamat, amely átadásra kerül?
Nem mi találtuk ki. Mi használjuk.
Üdvözlöm! Van egy kérdésem a User-data-val kapcsolatban. Ön azt mondta, hogy ott problémák merülnek fel, hogy valaki valamit nem oda küldött. Van valamilyen mód a user-data tárolására ugyanabban a Git-ben, hogy mindig világos legyen, hogy mire hivatkozik a User-data?
A User-data generálunk a template-ből. Azaz, jön oda egy bizonyos számú változó. A Terraform generálja a végső eredményt. Ezért nem lehet csak úgy ránézni a template-re és megmondani, hogy mi fog kisülni, mert az összes probléma azzal kapcsolatos, hogy a fejlesztő azt hiszi, hogy egy stringet ad át ebben a változóban, de közben egy tömb érkezik. És hopp, itt van – az egyes, az egyes, a következő sor, és minden eltörik. Ha ez egy új erőforrás, és az ember beindítja, és észreveszi, hogy valami nem működik, akkor ez gyorsan megoldható. De ha ez egy autoscale-csoport, amely frissült, akkor egy bizonyos pillanatban az autoscale-csoportban az instances kezd átkonfigurálódni. És hopp, valami nem működik. Ez bosszantó.
Tehát az egyetlen megoldás, hogy tesztelni kell?
Igen, látod a problémát, akkor hozzáadsz tesztlépéseket. Azaz az output-al is lehet tesztelni. Lehet, hogy nem olyan kényelmes, de lehet, hogy adhatsz valamilyen címkét – ellenőrizd, hogy a User-data itt szögekkel van rögzítve.
A nevem Timur. Nagyon jó, hogy vannak előadások arról, hogyan kell jól megszervezni a Terraform-ot.
Még el sem kezdtem.
Azt hiszem, a következő konferencián talán lesz. Van egy egyszerű kérdésem. Miért hardcode-olod az értéket egy külön modulban, miért nem használod a tfvars-t, azaz miben jobb a modul értékekkel, mint a tfvars?
Tehát itt (dia: Production/environment/settings.tf) azt kellene írnom: domain = változó, domain vpcnetwork, változó vpcnetwork és stvars – ugyanazt az értéket kinyerni?
Éppen így csináljuk. Hivatkozunk a modul beállítási forrására, például.
Lényegében ez egy tfvars. A tfvars nagyon hasznos a tesztkörnyezetben. Van tfvars a nagy instances-hez, a kis instances-hez. És csak bedobok egy fájlt a mappába. És megkapom, amit akarok. Amikor az infrastruktúrán dolgozunk, azt szeretnénk, hogy minden egy helyen legyen, és azonnal megértsük. De így az jön ki, hogy ide kell nézni, majd a tfvars-ra.
Tehát minden egy helyen lenne?
Igen, a tfvars az, amikor egy kódod van. És az több különböző helyen használódik, különböző árnyalatokkal. Akkor bedobtad volna a tfvars-t, és megkaptad a te árnyalataidat. Mi pedig az infrastruktúra, mint kód a tiszta formájában. Megnézted és megértetted.
Helló! Találkoztál már olyan helyzetekkel, amikor a felhőszolgáltató beavatkozik abba, amit a Terraformmal csináltál? Tegyük fel, hogy módosítjuk a metaadatokat. Ott vannak az ssh kulcsok. A Google folyamatosan beteszi a saját metaadatait, a saját kulcsait. És a Terraform mindig azt írja, hogy vannak változások. Minden egyes futtatás után, még ha semmi sem változik, mindig azt mondja, hogy most frissíteni fogja ezt a mezőt.
A kulcsokkal, de – igen, az infrastruktúra egy része ilyen dologgal sújtott, tehát a Terraform semmit sem tud változtatni. Mi saját kezűleg sem tudunk semmit megváltoztatni. Egyelőre ezzel élünk.
Tehát, te már találkoztál ilyesmivel, de nem találtál megoldást, csak csinálja- és csinálja tovább?
Sajnos igen.
Helló! Az én nevem Sztarkov Sztaniszlav. Mail.ru Group. Hogyan oldjátok meg a címke generálás problémáját a ...-on, hogyan adjátok át azt belül? Úgy értem, User data-n keresztül, hogy megadjátok a host nevet, hogy a Puppetet irányítsátok? És a kérdés második része. Hogyan oldjátok meg ezt SG-ben, tehát amikor generáljátok az SG-t, egy köteg azonos típusú példányt, hogyan nevezzétek el őket helyesen?
Azokat a példányokat, amelyek nagyon fontosak számunkra, szépen elnevezzük. Azokat, amelyek nem szükségesek, a megnevezéshez hozzátesszük, hogy ez egy autoscale-csoport. Elvileg ezt le lehet deaktiválni, és újat kapni.
A címkével kapcsolatos problémáról nincs probléma, hanem van egy feladat. A címkék nálunk nagyon-nagyon erősen használva vannak, mert az infrastruktúra nagy és drága. És figyelnünk kell, hova mennek a pénzek, ezért a címkék segítenek megérteni, hogy mi és hova ment. Így könnyebben keresünk rá arra, hogy úgymond egyes dolgok mennyibe kerülnek.
Milyen más kérdés volt még?
Amikor az SG létrehoz számos példányt, azokat valahogyan meg kell különböztetni?
Nem, nem szükséges. Minden egyes példányon van egy ügynök, amely értesít, hogy problémám van. Ha az ügynök értesít, akkor az ügynök tud arról, és legalább az IP-címe létezik. Már el lehet menni. Másodszor, a Consul-t használjuk Discovery-re, ahol nem Kubernetes van. A Consul is mutatja a példány IP-címét.
Tehát az IP-re fókuszáltok, nem a host névre?
Nem lehet a host névre támaszkodni, nagyon sok van belőlük. Van példányazonosító – AE és így tovább. Valahol meg lehet találni, keresésbe be lehet dobni.
Helló! Értem, hogy a Terraform egy jó dolog, ami felhőkre van optimalizálva.
Nem csak.
Éppen ez a kérdés érdekel. Ha úgy dönt, hogy tömegesen átköltözik a Bare Metal-re az összes instance-jével, nem lesz semmi probléma? Vagy mégis más termékeket kell használni, például a már itt említett Ansible-t?
Az Ansible kicsit más. Azaz az Ansible akkor működik, amikor az instance már elindult. A Terraform pedig azelőtt működik, hogy az instance elindult volna. Tehát a Bare Metal-re való átállás nem lehetséges.
Jelenleg nem, de ha a business azt mondja: "Csináljuk!"
Átállás másik felhőre – igen, de itt egy kicsit más a helyzet. Olyan Terraform-kódot kell írni, amely lehetővé teszi, hogy kevesebb nehézséggel tudjunk átállni egy másik felhőszolgáltatásra.
Kezdetben az volt a feladatunk, hogy az összes infrastruktúránk agnosztikus legyen, azaz bármilyen felhő megfelelő legyen, de egy idő után a business feladta és azt mondta: "Rendben, az elkövetkező N évben nem fogunk elköltözni, használhatjuk az Amazon szolgáltatásait."
A Terraform lehetővé teszi Front-End munkák létrehozását, a PagerDuty konfigurálását, adatdokkokat stb. Nagyon sok lehetőséget kínál. Gyakorlatilag irányítani tudja az egész világot.
Köszönöm a bemutatót! Én is már 4 éve foglalkozom a Terraformmal. Az utolsó simítások során, amikor a Terraformra és az infrastruktúrára, a deklaratív leírásra átálltunk, találkoztunk olyan helyzetekkel, amikor valaki manuálisan végzett valamit, és te próbáltál tervet kialakítani. Ekkor valami hibát kaptál. Hogyan oldjátok meg az ilyen problémákat? Hogyan találjátok meg az elveszett erőforrásokat, amelyek szerepeltek?
Főként kézi és okuláris módszerekkel, ha valami furcsát látunk a jelentésben, elemezzük, hogy mi történik, vagy csak töröljük. Egyébként a pull requestek teljesen normálisak.
Ha hiba van, végrehajtotok rollbacket? Próbáltatok már ilyet?
Nem, ez az ember döntése abban a pillanatban, amikor látja a problémát.
Forrás: habr.com
