Úgy tűnik, hogy a Terraform fejlesztői meglehetősen kényelmes bevált gyakorlatokat kínálnak az AWS infrastruktúrával való munkához. Csak egy árnyalat van. Idővel a környezetek száma növekszik, mindegyiknek megvan a maga sajátossága. Az alkalmazásverem majdnem másolata megjelenik a szomszédos régióban. A Terraform kódot pedig gondosan át kell másolni és az új követelményeknek megfelelően szerkeszteni, vagy hópehelyet készíteni.
Jelentésem a Terraform mintáiról a káosz és a kézi rutin leküzdésére nagy és hosszú projekteknél.
videók:
40 éves vagyok, 20 éve foglalkozom informatikával. 12 éve dolgozom az Ixtensnél. E-kereskedelem által vezérelt fejlesztéssel foglalkozunk. És 5 éve gyakorolom a DevOps gyakorlatokat.
A történetem egy titoktartási megállapodás mögé bújva egy olyan cégnél, amelynek a nevét nem mondom meg, egy projektben szerzett tapasztalataimról fog szólni.
A dián szereplő számok azért vannak feltüntetve, hogy megértsük a projekt mértékét. És minden, amit a továbbiakban elmondok, az Amazonhoz kapcsolódik.
4 éve csatlakoztam ehhez a projekthez. Az infrastruktúra átalakítása pedig javában zajlott, mert a projekt nőtt. És a használt minták már nem voltak megfelelőek. És tekintettel a projekt tervezett növekedésére, valami újat kellett kitalálni.
Köszönet Matvey-nek, aki tegnap elmondta, mi történt a Dodo Pizzában. Ez történt itt 4 éve.
Jöttek a fejlesztők és elkezdték az infrastruktúra kódját.
A legnyilvánvalóbb ok, amiért erre szükség volt, a piacra jutás ideje volt. Biztosítani kellett, hogy a DevOps csapata ne jelentsen szűk keresztmetszetet a bevezetés során. És többek között a Terraformot és a Puppet-et használták a legelső szinten.
A Terraform a HashiCorp nyílt forráskódú projektje. És azoknak, akik nem is tudják, mi ez, a következő néhány dia.
Az infrastruktúra mint kód azt jelenti, hogy leírhatjuk infrastruktúránkat, és megkérhetünk néhány robotot, hogy győződjön meg arról, hogy megkapjuk az általunk leírt erőforrásokat.
Például szükségünk van egy virtuális gépre. Leírunk és hozzáadunk néhány szükséges paramétert.
Ezt követően a konzolon konfiguráljuk az Amazonhoz való hozzáférést. És Terraform tervet fogunk kérni. A Terraform terv a következőt fogja mondani: „Rendben, megtehetjük ezeket a dolgokat az Ön erőforrásáért.” És legalább egy erőforrás hozzáadásra kerül. És nem várható változás.
Ha mindennel elégedett, megkérheti a Terraformot, hogy jelentkezzen, és a Terraform létrehoz egy példányt Önnek, és kap egy virtuális gépet a felhőben.
A projektünk tovább fejlődik. Néhány változtatást adunk hozzá. További példányokat kérünk, 53 bejegyzést adunk hozzá.
És ismételjük. Kérem tervezzen. Látjuk, milyen változtatásokat terveznek. Jelentkezünk. És így növekszik az infrastruktúránk.
A Terraform valami úgynevezett állapotfájlt használ. Ez azt jelenti, hogy az Amazonhoz érkezett összes módosítás egy fájlba kerül, ahol minden egyes Ön által leírt erőforráshoz hozzátartoznak az Amazonban létrehozott megfelelő erőforrások. Így amikor egy erőforrás leírása megváltozik, a Terraform pontosan tudja, mit kell változtatni az Amazonon.
Ezek az állapotfájlok eredetileg csak fájlok voltak. És a Gitben tároltuk őket, ami rendkívül kényelmetlen volt. Valaki mindig elfelejtett változtatásokat végrehajtani, és sok konfliktus alakult ki.
Most már lehetőség van a háttérprogram használatára, azaz a Terraform megadása, hogy az állapotfájlt melyik vödörbe és milyen kulccsal kell menteni. És maga a Terraform gondoskodik arról, hogy megkapja ezt az állapotfájlt, megcsinálja a varázslatot és visszaállítja a végeredményt.
Infrastruktúránk növekszik. Íme a kódunk. És most nem csak egy virtuális gépet akarunk létrehozni, hanem egy tesztkörnyezetet is.
A Terraform lehetővé teszi, hogy egy ilyen dolgot modulként hozzon létre, vagyis ugyanazt írja le valamilyen mappában.
És például a tesztelés során hívja meg ezt a modult, és ugyanazt kapja, mintha magában a modulban végrehajtottuk volna a Terraform apply-et. A teszteléshez ez a kód lesz.
A termeléshez néhány változtatást elküldhetünk oda, mert a tesztelésnél nincs szükségünk nagy példányokra, élesben a nagy példányok csak hasznosak.
És akkor visszatérek a projekthez. Nehéz feladat volt, nagyon nagy volt a tervezett infrastruktúra. És valahogyan el kellett helyezni az összes kódot, hogy mindenki számára kényelmes legyen: mind azok számára, akik karbantartást végeznek ezen a kódon, és azoknak, akik módosítanak. A tervek szerint pedig bármelyik fejlesztő elmehetne és megjavíthatná az infrastruktúrát a platform saját részének igénye szerint.
Ez egy könyvtárfa, amelyet maga a HashiCorp ajánl, ha nagy projektje van, és célszerű a teljes infrastruktúrát felosztani néhány apró darabra, és minden egyes részt külön mappában leírni.
Az erőforrások kiterjedt könyvtárával megközelítőleg ugyanazt hívhatja a tesztelés és a gyártás során.
Esetünkben ez nem volt teljesen megfelelő, mert a fejlesztői vagy tesztelési tesztvermet valahogy egyszerűbben kellett beszerezni. De nem akartam végigmenni a mappákon, és a kívánt sorrendben alkalmazni őket, és attól tartani, hogy az adatbázis felemelkedik, majd az adatbázist használó példány emelkedni fog. Ezért az összes tesztelés egy mappából indult el. Ugyanazokat a modulokat hívták oda, de minden egy futásban történt.
A Terraform gondoskodik az összes függőségről. És mindig a sorozatban hoz létre erőforrásokat, így például egy újonnan létrehozott példányból kaphat egy IP-címet, és megkaphatja ezt az IP-címet a route53 rekordban.
Ráadásul a platform nagyon nagy. És egy tesztverem elindítása, még ha egy órára is, még ha 8 órára is, meglehetősen drága vállalkozás.
És automatizáltuk ezt az ügyet. És Jenkins munkája lehetővé tette a verem futtatását. Ebben el kellett indítani egy pull kérést a fejlesztő által tesztelni kívánt változtatásokkal, megadni az összes szükséges opciót, komponenst, méretet. Ha teljesítménytesztet akar, akkor több példányt is vállalhat. Ha csak azt kell ellenőriznie, hogy kinyílik-e valamilyen nyomtatvány, akkor minimálbérről indulhat. És azt is jelezze, hogy szükség van-e klaszterre vagy sem stb.
Aztán Jenkins lenyomott egy shell szkriptet, amely kissé módosította a Terraform mappában lévő kódot. Eltávolítottam a szükségtelen fájlokat, és hozzáadtam a szükséges fájlokat. Aztán egy Terraform alkalmazással a verem megemelkedett.
Aztán voltak más lépések is, amelyekbe nem akarok belemenni.
Tekintettel arra, hogy a teszteléshez valamivel több lehetőségre volt szükségünk, mint a termelésben, a modulokról másolatokat kellett készítenünk, hogy ezekbe a másolatokba a csak teszteléshez szükséges funkciókat tudtuk hozzáadni.
És úgy történt, hogy a tesztelés során szeretném tesztelni azokat a változtatásokat, amelyek végül gyártásba kerülnek. De valójában egy dolgot teszteltek, és egy kicsit mást használtak a gyártásban. És volt egy kis törés a mintában, hogy a termelésben minden változtatást az üzemeltető csapat alkalmazott. És néha kiderült, hogy azok a változtatások, amelyeknek a tesztelésből a gyártásba kellett kerülniük, egy másik verzióban maradtak.
Ezen kívül volt egy olyan probléma, hogy egy új szolgáltatás került be, ami kissé eltér néhány már meglévőtől. És ahelyett, hogy egy meglévő modult módosítanánk, másolatot kellett készítenünk róla, és hozzáadni kellett a szükséges változtatásokat.
Lényegében a Terraform nem igazi nyelv. Ez egy nyilatkozat. Ha nyilatkoznunk kell valamit, akkor kijelentjük. És mindez működik.
Valamikor, amikor az egyik húzási kérésemet tárgyalták, az egyik kollégám azt mondta, hogy nem kell hópelyheket készíteni. Kíváncsi voltam, mire gondol. Tudományos tény, hogy nincs két egyforma hópehely a világon, mindegyik kissé különbözik. És amint ezt meghallottam, azonnal megéreztem a Terraform kód teljes súlyát. Ugyanis amikor verzióról verzióra kellett váltani, a Terraform megszakító lánc változtatásokat követelt meg, vagyis a kód már nem volt kompatibilis a következő verzióval. És le kellett tennünk egy lehívási kérelmet, amely az infrastruktúrában lévő fájlok majdnem felét fedte le, hogy az infrastruktúrát a Terraform következő verziójába hozzuk.
És miután megjelent egy ilyen hópehely, az összes Terraform kód, amit egy nagy-nagy hókupacsá változtattunk.
A működésen kívül álló külső fejlesztőnek ez nem sokat számít neki, mert pull kérést adott, beindult az erőforrása. És ez minden, ez már nem az ő gondja. És a DevOps csapata, akik gondoskodnak arról, hogy minden rendben legyen, köteles végrehajtani ezeket a változtatásokat. És ezeknek a változtatásoknak a költsége nagyon-nagyon megnőtt minden további hópehellyel.
Van egy történet arról, hogy egy szemináriumon egy diák krétával két tökéletes kört rajzol a táblára. És a tanár meglepődik, hogyan tudott ilyen gördülékenyen rajzolni iránytű nélkül. A diák így válaszol: „Nagyon egyszerű, két évet töltöttem a hadseregben húsdaráló forgatásával.”
És abból a négy évből, amióta részt veszek ebben a projektben, körülbelül két éve csinálom a Terraformot. És természetesen van néhány trükköm, néhány tanácsom a Terraform kód egyszerűsítésére, programozási nyelvként való használatára, valamint a fejlesztők terheinek csökkentésére, akiknek ezt a kódot naprakészen kell tartaniuk.
Az első dolog, amivel kezdeném, az a Symlinks. A Terraformnak sok ismétlődő kódja van. Például a szolgáltató hívása szinte minden olyan ponton, ahol létrehozunk egy infrastruktúrát, ugyanaz. És logikus, hogy külön mappába helyezzük. És mindenhol, ahol a szolgáltatónak Symlinkeket kell létrehoznia ehhez a fájlhoz.
Például a termelésben a feltételezett szerepkört használja, amely lehetővé teszi, hogy hozzáférési jogokat szerezzen bizonyos külső Amazon-fiókokhoz. És miután megváltoztatott egy fájlt, az erőforrásfában lévő összes többi rendelkezik a szükséges jogokkal, hogy a Terraform tudja, melyik Amazon-szegmenshez kell hozzáférnie.
Hol hibáznak a Symlinkek? Mint mondtam, a Terraformnak vannak állapotfájljai. És nagyon-nagyon menők. De a helyzet az, hogy a Terraform a legelső helyen inicializálja a hátteret. És nem használhat semmilyen változót ezekben a paraméterekben, azokat mindig szövegbe kell írni.
Ennek eredményeként, ha 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 vödörrel. Például homokozót készít a homokozóból, majd gyártásban készíti el. És így kiderülhet, hogy a gyártásban lévő vödröt homokozóból fogják használni. Persze gyorsan megtalálják. Ezt valahogy meg lehet majd oldani, de ennek ellenére idő- és bizonyos mértékig erőforrás-pazarlás.
Mit tehetünk ezután? Mielőtt a Terraformmal dolgozna, inicializálnia kell. Inicializáláskor a Terraform letölti az összes beépülő modult. Egy bizonyos ponton a monolitból egy mikroszolgáltatási architektúrává váltak. És mindig meg kell csinálni a Terraform init-et, hogy felhúzza az összes modult, minden bővítményt.
És használhat egy shell szkriptet, amely először is megkapja az összes változót. A shell script semmilyen módon nincs korlátozva. Másodszor pedig az utak. Ha az állapotfájl kulcsaként mindig a repository-ban lévő elérési utat használjuk, akkor ennek megfelelően az itteni hiba megszűnik.
Hol szerezhetem be az adatokat? JSON fájl. A Terraform lehetővé teszi az infrastruktúra írását nem csak hcl-ben (HashiCorp Configuration Language), hanem JSON-ban is.
A JSON könnyen olvasható shell-szkriptből. Ennek megfelelően a konfigurációs fájlt elhelyezheti egy helyen. És használja ezt a tárolót a Terraform kódban és a shell szkriptben is az inicializáláshoz.
Miért fontos, hogy legyen vödör a Terraform számára? Mert létezik olyan, hogy távoli állapotú fájlok. Ez azt jelenti, hogy amikor felvetek valamilyen erőforrást, hogy azt mondhassam az Amazonnak: „Kérem, emelje fel a példányt”, meg kell adnom egy csomó kötelező paramétert.
És ezek az azonosítók egy másik mappában vannak tárolva. És mehetek, és azt mondhatom: „Terraform, kérem, futtasson az adott erőforrás állapotfájljába, és szerezze meg nekem ezeket az azonosítókat.” És így egy bizonyos egységesülés jelenik meg a különböző régiók vagy környezetek között.
Nem mindig lehet távoli állapotfájlt használni. Például kézzel készített egy VPC-t. A VPC-t létrehozó Terraform kód pedig olyan különböző VPC-ket hoz létre, hogy ez nagyon hosszú ideig tart, és az egyiket a másikhoz kell igazítania, így használhatja a következő trükköt.
Ez azt jelenti, hogy készítsen egy modult, amely úgy tűnik, hogy VPC-t hoz létre, és mintha azonosítókat adna, de valójában egyszerűen van egy kemény kódolt értékekkel rendelkező fájl, amely felhasználható ugyanazon példány létrehozására.
Nem mindig szükséges az állapotfájlt a felhőbe menteni. Például modulok tesztelésekor használhat backend inicializálást, ahol a fájl a tesztelés idején egyszerűen lemezre kerül.
Most egy kicsit a tesztelésről. Mit lehet tesztelni a Terraformban? Valószínűleg sok minden lehetséges, de erről a 4 dologról fogok beszélni.
A HashiCorp tisztában van azzal, hogyan kell a Terraform kódot formázni. A Terraform fmt pedig lehetővé teszi, hogy a szerkesztett kódot ennek a meggyőződésnek megfelelően formázza. Ennek megfelelően a teszteknek feltétlenül ellenőrizniük kell, hogy a formázás megfelel-e annak, amit a HashiCorp hagyott jóvá, így nem kell megváltoztatni a zárójelek helyét stb.
A következő a Terraform validate. Alig tesz mást, mint a szintaxis ellenőrzését – ja, hogy minden zárójel párosítva van-e. Mi itt a fontos? Infrastruktúránk nagyon kiterjedt. Nagyon sokféle apuka van benne. És mindegyikben le kell futtatnia a Terraform validálást.
Ennek megfelelően a tesztelés felgyorsítása érdekében párhuzamosan több folyamatot is futtatunk párhuzamosan.
A párhuzamos nagyon klassz dolog, használd.
De minden alkalommal, amikor a Terraform inicializál, elmegy a HashiCorp-hoz, és megkérdezi: „Melyek a legújabb bővítményverziók? És a gyorsítótárban lévő bővítmény – a megfelelő vagy a rossz?” És ez minden lépésnél lelassult.
Ha elmondja a Terraformnak, hogy hol vannak a beépülő modulok, akkor a Terraform azt mondja: „Oké, ez valószínűleg a legújabb dolog, ami ott van. Nem megyek sehova, azonnal elkezdem a Terraform kód érvényesítését."
Annak érdekében, hogy a mappát megtöltsük a szükséges bővítményekkel, van egy nagyon egyszerű Terraform kódunk, amelyet csak inicializálni kell. Itt természetesen meg kell adnia az összes szolgáltatót, amely valamilyen módon részt vesz a kódjában, különben a Terraform azt mondja: "Nem ismerek egy bizonyos szolgáltatót, mert nincs a gyorsítótárban."
A következő a Terraform terv. Mint mondtam, a fejlődés ciklikus. Módosítjuk a kódot. Utána pedig ki kell deríteni, milyen változtatásokat terveznek az infrastruktúrában.
És amikor az infrastruktúra nagyon-nagyon nagy, módosíthat egy modult, javíthat egy tesztkörnyezetet vagy egy adott régiót, és megszakíthat egy szomszédosat. Ezért a Terraform tervet a teljes infrastruktúrára kell elkészíteni, és megmutatni, milyen változtatásokat terveznek.
Ezt okosan meg tudod csinálni. Például írtunk egy Python-szkriptet, amely feloldja a függőségeket. És attól függően, hogy mi változott: egy Terraform modul vagy csak egy adott komponens, az összes függő mappához terveket készít.
Kérésre terraform terveket kell készíteni. Legalábbis mi ezt tesszük.
Persze jó minden változtatásnál, minden commitnál tesztet csinálni, de a tervek elég drága dolog. És egy lehívási kérelemben azt mondjuk: "Kérem, adja meg a terveket." A robot elindul. És elküldi a megjegyzéseket vagy csatolja az összes tervet, amely a változtatásoktól várható.
Egy terv elég drága dolog. Időbe telik, mert a Terraform elmegy az Amazonhoz, és megkérdezi: „Létezik még ez a példány? Ennek az automatikus skálának pontosan ugyanazok a paraméterei? Ennek felgyorsítása érdekében használhat egy paramétert, például refresh=false. Ez azt jelenti, hogy a Terraform letölti az állapotot az S3-ból. És azt fogja hinni, hogy az állam pontosan megegyezik azzal, ami az Amazonban van.
Egy ilyen Terraform terv sokkal gyorsabban megy, de az állapotnak meg kell felelnie az infrastruktúrának, azaz valahol, valamikor el kell indulnia a Terraform frissítésnek. A Terraform frissítés pontosan ezt teszi: az állapot megegyezik a tényleges infrastruktúra tartalmával.
És beszélnünk kell a biztonságról. Itt kellett kezdenünk. Ahol a Terraform és a Terraform fut az infrastruktúráján, ott van egy biztonsági rést. Vagyis lényegében a kódot hajtod végre. És ha a lekérési kérelem valamilyen rosszindulatú kódot tartalmaz, akkor az túl sok hozzáféréssel rendelkező infrastruktúrán végrehajtható. Tehát legyen óvatos, hol futtatja a Terraform tervet.
A következő dolog, amiről szeretnék beszélni, az a felhasználói adatok tesztelése.
Mi az a felhasználói adatok? Az Amazonban, amikor létrehozunk egy példányt, elküldhetünk egy bizonyos levelet a példánysal - meta adatokkal. Amikor a példány elindul, általában a felhő init mindig jelen van ezeken a példányokon. A Cloud init elolvassa ezt a levelet, és azt mondja: „Rendben, ma én vagyok a terheléselosztó.” És ezekkel a szövetségekkel összhangban végrehajt néhány cselekedetet.
De sajnos, amikor a Terraform tervet és a Terraformot alkalmazzuk, a felhasználói adatok efféle számpépnek tűnnek. Vagyis egyszerűen elküldi neked a hash-t. A tervben pedig csak annyit lehet megnézni, hogy lesznek-e változások, vagy a hash változatlan marad.
És ha erre nem figyelsz, akkor néhány törött szövegfájl kerülhet az Amazonra, a valódi infrastruktúrára.
Alternatív megoldásként a végrehajtás során nem a teljes infrastruktúrát, hanem csak a sablont adhatja meg. A kódban pedig ezt írja: „Kérem, jelenítse meg ezt a sablont a képernyőmön.” Ennek eredményeként kinyomtathatja, hogyan fognak kinézni az adatok az Amazonon.
Egy másik lehetőség egy modul használata a felhasználói adatok generálására. Ezt a modult fogja alkalmazni. Megkapja a fájlt lemezen. Hasonlítsd össze a referenciával. És így, ha valaki úgy dönt, hogy egy kicsit korrigálja a felhasználói adatokat, akkor a tesztek azt mondják: "Rendben, itt-ott van néhány változás - ez normális."
A következő dolog, amiről szeretnék beszélni, a Terraform automatizálása.
Persze elég ijesztő, hogy a Terraformot automata módban alkalmazzák, mert ki tudja, milyen változások történtek ott, és milyen romboló hatásúak lehetnek az élő infrastruktúrára.
Tesztkörnyezetben ez teljesen normális. Vagyis egy tesztkörnyezetet létrehozó munka az, amire minden fejlesztőnek szüksége van. És egy olyan kifejezés, mint a „minden működött nekem”, nem egy vicces mém, hanem annak bizonyítéka, hogy egy személy összezavarodott, emelt egy veremet, és néhány tesztet futtatott ezen a veremön. És megbizonyosodott arról, hogy ott minden rendben van, és azt mondta: "Rendben, a kódot, amit kiadok, tesztelték."
A termelésben, a sandboxban és más üzleti szempontból kritikusabb környezetekben bizonyos erőforrásokat részben egészen biztonságosan használhat fel, mert ez nem okoz senki halálát. Ezek a következők: autoscale csoportok, biztonsági csoportok, szerepek, route53, és az ott található lista elég nagy lehet. De tartsa szemmel, hogy mi történik, olvassa el az automatizált alkalmazásjelentéseket.
Ahol veszélyes vagy ijesztő az alkalmazás, például ha ezek egy adatbázisból származó tartós erőforrások, akkor kapjon jelentést arról, hogy az infrastruktúra egyes részein nem alkalmazott változtatások történtek. A mérnök pedig felügyelet mellett elindítja a jelentkező munkákat, vagy a konzoljáról végzi el.
Az Amazonnak van egy olyan dologja, mint a védelem megszüntetése. És bizonyos esetekben megvédheti az Ön számára nem szükséges változtatásoktól. Vagyis a Terraform elment az Amazonhoz, és azt mondta: "Meg kell ölnöm ezt a példányt, hogy készítsek egy másikat." Az Amazon pedig azt mondja: „Sajnos nem ma. Megszünteti a védelmet."
A hab a tortán pedig a kódoptimalizálás. Amikor Terraform kóddal dolgozunk, nagyon sok paramétert kell átadnunk a modulnak. Ezek azok a paraméterek, amelyek szükségesek valamilyen erőforrás létrehozásához. A kód pedig nagy paraméterlistákká alakul, amelyeket modulról modulra, modulról modulra kell átadni, különösen, ha a modulok egymásba vannak ágyazva.
És nagyon nehéz olvasni. Ezt nagyon nehéz áttekinteni. És nagyon gyakran kiderül, hogy bizonyos paramétereket felülvizsgálnak, és nem pontosan azok, amelyekre szükség van. És ennek későbbi javítása időbe és pénzbe kerül.
Ezért azt javaslom, hogy egy ilyen dolgot használjon összetett paraméterként, amely egy bizonyos értékfát tartalmaz. Vagyis szüksége van valamilyen mappára, ahol minden olyan érték megtalálható, amelyet valamilyen környezetben szeretne.
Ennek a modulnak a meghívásával pedig egy olyan fát kaphatunk, amely egyetlen közös modulban generálódik, vagyis egy közös modulban, amely ugyanúgy működik a teljes infrastruktúrában.
Ebben a modulban néhány számítást végezhet a Terraform egy olyan friss funkciójával, mint a helyiek. Ezután egy kimenettel adjon meg valamilyen összetett paramétert, amely tartalmazhat tömbkivonatokat stb.
Itt ért véget a legjobb lelet. És szeretnék elmesélni egy történetet Kolumbuszról. Amikor pénzt keresett Indiát felfedező expedíciójához (ahogy akkor gondolta), senki sem hitt neki, és azt hitték, hogy ez lehetetlen. Aztán így szólt: „Győződjön meg arról, hogy a tojás nem esik le.” Az összes bankár, nagyon gazdag és valószínűleg okos ember, megpróbálta valahogy elhelyezni a tojást, és az folyton leesett. Aztán Kolumbusz fogta a tojást, és egy kicsit megnyomta. A héj összegyűrődött, és a tojás mozdulatlan maradt. Azt mondták: "Ó, ez túl könnyű!" És Kolumbusz így válaszolt: „Igen, ez túl egyszerű. És amikor megnyitom Indiát, mindenki ezt a kereskedelmi utat fogja használni."
És amit az imént mondtam, az valószínűleg egészen egyszerű és triviális dolgok. És amikor megismeri őket és elkezdi használni őket, az a dolgok sorrendjében történik. Tehát használja ki. És ha ezek teljesen normális dolgok számodra, akkor legalább tudod, hogyan kell elhelyezni a tojást, hogy ne essen le.
Összefoglalva:
- Próbáld meg elkerülni a hópelyheket. És minél kevesebb hópehely, annál kevesebb erőforrásra lesz szüksége a nagy infrastruktúra módosításához.
- Állandó változások. Ez azt jelenti, hogy ha a kódban változás történik, akkor az infrastruktúráját a lehető leggyorsabban összhangba kell hoznia ezekkel a változtatásokkal. Nem fordulhat elő olyan helyzet, amikor valaki két-három hónappal később eljön megnézni az Elasticsearch-et, elkészít egy Terraform tervet, és van egy csomó olyan változás, amire nem számított. És sok időbe telik, mire mindent rendbe tesznek.
- Tesztek és automatizálás. Minél jobban le van fedve a kódja tesztekkel és funkciókkal, annál jobban bízik abban, hogy mindent helyesen csinál. Az automatikus kézbesítés pedig többszörösére növeli önbizalmát.
- A teszt- és éleskörnyezet kódjának közel azonosnak kell lennie. Gyakorlatilag azért, mert a gyártás még mindig egy kicsit más, és még mindig lesznek olyan árnyalatok, amelyek túlmutatnak a tesztkörnyezeten. De ennek ellenére, plusz vagy mínusz, ez biztosítható.
- És ha sok Terraform kódja van, és sok időbe telik a kód naprakészen tartása, akkor soha nem késő újratervezni és jó állapotba hozni.
- Változatlan infrastruktúra. AMI szállítás menetrend szerint.
- A route53 szerkezete, ha sok bejegyzése van, és azt szeretné, hogy azok következetes sorrendben legyenek.
- Küzdelem az API-korlátok ellen. Ilyenkor az Amazon azt mondja: "Ennyi, nem tudok több kérést elfogadni, kérem, várjon." Az iroda fele pedig arra vár, hogy beindíthassa infrastruktúráját.
- Helyszíni példányok. Az Amazon nem egy olcsó esemény, és a szpotok meglehetősen sokat spórolhatnak. És ott egy egész riportot lehet elmondani róla.
- Biztonsági és IAM-szerepek.
- Elveszett erőforrások után kutatva, ha ismeretlen eredetű példányai vannak az Amazone-ban, pénzt esznek. Még ha az példányok havi 100-150 dollárba kerülnek, ez több mint 1 dollár évente. Az ilyen források megtalálása jövedelmező üzlet.
- És fenntartott példányok.
Nekem ennyi. A Terraform nagyon klassz, használd. Köszönöm!
kérdések
Köszönöm a beszámolót! Az állapotfájlja az S3-ban van, de hogyan lehet megoldani azt a problémát, hogy többen is elvehetik ezt az állapotfájlt és megpróbálhatják bővíteni?
Először is nem sietünk. Másodszor, vannak zászlók, amelyekben arról számolunk be, hogy dolgozunk valamilyen kódrészleten. Vagyis annak ellenére, hogy nagyon nagy az infrastruktúra, ez nem jelenti azt, hogy valaki folyamatosan használ valamit. És amikor volt egy aktív fázis, ez probléma volt; az állapotfájlokat Gitben tároltuk. Ez fontos volt, különben valaki csinált egy állapotfájlt, és ezeket manuálisan kellett összeraknunk, hogy minden folytatódjon. Most már nincs ilyen probléma. Általában a Terraform megoldotta ezt a problémát. És ha valami folyamatosan változik, akkor használhat zárakat, amelyek megakadályozzák, amit mondtál.
Nyílt forráskódú vagy vállalati verziót használ?
Nincs vállalkozás, azaz minden, amit ingyen letölthetsz.
A nevem Stanislav. Egy kis kiegészítést akartam tenni. Ön beszélt egy Amazon-funkcióról, amely lehetővé teszi, hogy egy példányt megölhetetlenné tegye. Ez magában a Terraformban is megvan, a Life Second blokkban megadhatja a változtatások tilalmát vagy a megsemmisítés tilalmát.
Az idő korlátozott volt. Jó megállapítás.
Két dolgot is akartam kérdezni. Először is a tesztelésről beszéltél. Használtál valamilyen tesztelő eszközt? Hallottam a Test Kitchen bővítményről. Talán van még valami. És a Helyi értékekről is szeretnék kérdezni. Miben különböznek alapvetően a bemeneti változóktól? És miért nem tudok valamit paraméterezni csak a Helyi értékeken keresztül? Próbáltam kitalálni ezt a témát, de valahogy magamtól nem tudtam rájönni.
Ezen a szobán kívül beszélhetünk részletesebben. Teszteszközeink teljesen saját készítésűek. Nincs mit tesztelni. Általában vannak olyan lehetőségek, amikor az automatizált tesztek felveszik valahol az infrastruktúrát, ellenőrzik, hogy rendben van-e, majd mindent megsemmisítenek egy jelentéssel, hogy az infrastruktúra még mindig jó állapotban van. Nálunk nincs ilyen, mert a tesztveremek minden nap futnak. És ez elég. És ha valami elkezd eltörni, akkor el fog törni anélkül, hogy máshol ellenőriznénk.
A Helyi Értékekkel kapcsolatban folytassuk a beszélgetést a termen kívül.
Helló! Köszönöm a beszámolót! Nagyon informatív. Azt mondta, hogy sok azonos típusú kóddal írja le az infrastruktúrát. Gondolt már arra, hogy létrehozza ezt a kódot?
Remek kérdés, köszönöm! A lényeg az, hogy amikor az infrastruktúrát kódként használjuk, feltételezzük, hogy megnézzük a kódot, és megértjük, milyen infrastruktúra rejlik a kód mögött. Ha kódot generálunk, akkor el kell képzelnünk, hogy milyen kódot generálunk, hogy megértsük, milyen infrastruktúra lesz ott. Vagy generálunk kódot, véglegesítjük, és lényegében ugyanaz történik. Követtük hát a megírt utat, meg is kaptuk. A plusz generátorok valamivel később jelentek meg, amikor elkezdtük gyártani őket. És már késő volt változtatni.
Hallottál valamit a jsonnetről?
Nem.
Nézd, ez nagyon klassz dolog. Konkrét esetet látok, amikor lehet alkalmazni és adatstruktúrát generálni.
A generátorok akkor jók, ha megvannak, mint a borotvagépről szóló viccben. Vagyis először más az arc, de aztán mindenkinek ugyanaz az arca. A generátorok nagyon jól működnek. De sajnos az arcunk kicsit más. Ez probléma.
Csak nézd. Köszönöm!
A nevem Maxim, a Sberbanktól származom. Beszéltél egy kicsit arról, hogyan próbáltad a Terraformot a programozási nyelv megfelelőjére hozni. Nem egyszerűbb az Ansible használata?
Ezek nagyon különböző dolgok. Erőforrásokat hozhat létre az Ansible-ben, a Puppet pedig az Amazonban. De a Terraform egyenesen kiélezett.
Csak Amazonod van?
Nem arról van szó, hogy csak Amazonunk van. Szinte csak Amazonunk van. De a legfontosabb jellemző az, hogy a Terraform emlékszik. Ha az Ansible-ben azt mondod: „Adj 5 esetet”, akkor fel fog emelkedni, majd azt mondod: „És most 3 kell.” És Terraform azt mondja: "Rendben, megölök 2-t", Ansible pedig azt mondja: "Rendben, itt van a 3." Összesen 8.
Helló! Köszönjük a beszámolót! Nagyon érdekes volt hallani a Terraformról. Azonnal szeretnék egy kis megjegyzést tenni azzal kapcsolatban, hogy a Terraform még mindig nem rendelkezik stabil kiadással, ezért nagyon óvatosan kezelje a Terraformot.
Egy jó kanál vacsorára. Vagyis ha megoldásra van szükséged, akkor néha halogatod, ami instabil, stb., de működik és nekünk segített.
A kérdés ez. Távoli háttérrendszert használsz, S 3-at használsz. Miért nem használod a hivatalos hátteret?
Hivatalos?
Terraform felhő.
Mikor jelent meg?
4hónappal ezelőtt.
Ha 4 éve jelent meg, akkor valószínűleg válaszoltam volna a kérdésére.
Van már beépített funkció és zárak, és tárolhatunk állapotfájlt is. Megpróbál. De én sem teszteltem.
Egy nagy vonaton utazunk, amely nagy sebességgel halad. És nem lehet csak úgy elvenni néhány autót és kidobni őket.
A hópelyhekről beszéltél, miért nem használtál ágat? Miért nem így sikerült?
Megközelítésünk az, hogy a teljes infrastruktúra egy adattárban van. Terraform, Puppet, az összes script, ami valahogy ehhez kapcsolódik, mind egy tárban van. Így biztosíthatjuk, hogy az inkrementális változtatások egymás után kerüljenek tesztelésre. Ha egy csomó ágról lenne szó, akkor egy ilyen projektet szinte lehetetlen lenne fenntartani. Eltelik hat hónap, és annyira eltérnek egymástól, hogy ez csak valamiféle büntetés. Ez az, ami elől el akartam menekülni a refaktorálás előtt.
Tehát nem működik?
Ez egyáltalán nem működik.
Az ágban kivágtam a mappacsúszdát. Vagyis ha minden tesztveremhez megteszi, például az A csapatnak saját mappája van, a B csapatnak saját mappája van, akkor ez szintén nem működik. Egységes tesztkörnyezeti kódot hoztunk létre, amely elég rugalmas volt ahhoz, hogy mindenkinek megfeleljen. Vagyis egy kódot szolgáltunk ki.
Helló! A nevem Yura! Köszönöm a beszámolót! Kérdés a modulokkal kapcsolatban. Azt mondja, modulokat használ. Hogyan oldja meg a problémát, ha az egyik modulon olyan változtatásokat hajtottak végre, amelyek nem kompatibilisek egy másik személy módosításával? Valahogy verziózod a modulokat, vagy megpróbálsz egy wunderwaffle-t hozni, hogy megfeleljen két követelménynek?
Ez egy nagy hókupac probléma. Ez az, amitől szenvedünk, ha valamilyen ártalmatlan változás eltörheti az infrastruktúra egy részét. És ez csak hosszú idő után lesz észrevehető.
Vagyis még nincs megoldva?
Univerzális modulokat készít. Kerülje a hópelyheket. És minden sikerülni fog. A jelentés második fele arról szól, hogyan lehet ezt elkerülni.
Helló! Köszönöm a beszámolót! szeretném tisztázni. A színfalak mögött egy nagy kupac volt, amiért jöttem. Hogyan integrálódik a báb és a szereposztás?
Felhasználói adat.
Vagyis csak kiköpöd a fájlt és valahogy végrehajtod?
A felhasználói adatok egy megjegyzés, vagyis amikor a képről klónt készítünk, Daemon ott emelkedik, és megpróbálja kitalálni, hogy ki ő, elolvassa a megjegyzést, hogy ő egy terheléselosztó.
Vagyis ez valamiféle külön folyamat, amit odaadnak?
Nem mi találtuk ki. Használjuk.
Helló! Csak egy kérdésem lenne a Felhasználói adatokkal kapcsolatban. Azt mondtad, ott vannak problémák, esetleg valaki rossz helyre küld valamit. Van valami mód a felhasználói adatok tárolására ugyanabban a Gitben, hogy mindig világos legyen, mire utalnak a felhasználói adatok?
Felhasználói adatokat generálunk sablonból. Vagyis ott bizonyos számú változót használnak. A Terraform pedig elkészíti a végeredményt. Ezért nem lehet csak ránézni a sablonra, és megmondani, hogy mi fog történni, mert minden probléma azzal kapcsolatos, hogy a fejlesztő úgy gondolja, hogy egy karakterláncot ad át ebben a változóban, de ott egy tömböt használnak. És ő - bam és én - ez-az, ez-az, a következő sor, és minden elromlott. Ha ez egy új erőforrás, és valaki felveszi, és látja, hogy valami nem működik, akkor gyorsan megoldódik. És ha ezt az automatikus skálázási csoportot frissítik, akkor egy bizonyos ponton az automatikus skálázási csoport példányai lecserélődnek. És bumm, valami nem működik. Ez fáj.
Kiderült, hogy az egyetlen megoldás a tesztelés?
Igen, látja a problémát, hozzáadja a tesztlépéseket. Vagyis a kimenet is tesztelhető. Lehet, hogy nem olyan kényelmes, de néhány jelölést is elhelyezhet - ellenőrizze, hogy itt vannak-e leszögezve a felhasználói adatok.
A nevem Timur. Nagyon jó, hogy vannak jelentések a Terraform megfelelő megszervezéséről.
Még el sem kezdtem.
Azt hiszem, a következő konferencián talán lesz. Lenne egy egyszerű kérdésem. Miért kódolja az értéket egy külön modulban, ahelyett, hogy tfvars-t használna, azaz miért jobb egy értékkel rendelkező modul, mint a tfvars?
Vagyis ide írjam (dia: Termelés/környezet/settings.tf): domain = változó, domain vpcnetwork, változó vpcnetwork és stvars – megkaphatom ugyanezt?
Pontosan ezt tesszük. Hivatkozunk például a beállítási forrás modulra.
Lényegében ez az ilyen tfvars. A Tfvars nagyon kényelmes tesztkörnyezetben. Van tfvarom nagy példányokhoz, kicsikhez. És bedobtam egy fájlt a mappába. És megkaptam, amit akartam. Amikor az infrastruktúrát levágjuk, azt akarjuk, hogy mindent meg lehessen nézni és azonnal megérteni. És így kiderül, hogy ide kell nézni, aztán a tfvarokat.
Lehetséges, hogy minden egy helyen legyen?
Igen, a tfvars az, amikor egy kódod van. És több helyen használják, különböző árnyalatokkal. Akkor tfvarokat dobnál, és megkapnád az árnyalatait. És mi vagyunk az infrastruktúra, mint kód a legtisztább formájában. Megnéztem és megértettem.
Helló! Találkoztál már olyan helyzetekkel, amikor a felhőszolgáltató beavatkozik a Terraform által készített termékbe? Tegyük fel, hogy szerkesztjük a metaadatokat. Vannak ssh kulcsok. A Google pedig folyamatosan odateszi a metaadatait és a kulcsait. A Terraform pedig mindig azt írja, hogy vannak változásai. Minden futás után, még ha semmi sem változik, mindig azt mondja, hogy most frissíti ezt a mezőt.
Kulcsokkal, de igen, az infrastruktúra egy részét érinti ez a dolog, vagyis a Terraform nem tud semmit megváltoztatni. A kezünkkel sem változtathatunk semmit. Egyelőre élünk vele.
Vagyis találkozott már ilyesmivel, de nem jutott eszébe semmi, hogyan csinálja és csinálja ő maga?
Sajnos igen.
Helló! A nevem Starkov Stanislav. Levél. ru Csoport. Hogyan oldja meg a címke generálásának problémáját a...-n, hogyan adja át? Ha jól értem, a User - data segítségével adja meg a gazdagép nevét, állítsa be a Puppet on? És a kérdés második része. Hogyan oldja meg ezt a problémát az SG-ben, azaz amikor több száz azonos típusú példányt generál SG-ben, mi a helyes elnevezésük?
A számunkra nagyon fontos eseteket szépen elnevezzük. Azoknál, amelyekre nincs szükség, van egy megjegyzés, hogy ez egy automatikus skálázási csoport. És elméletileg le lehet szögezni és újat venni.
Ami a címkével kapcsolatos problémát illeti, nincs ilyen probléma, de van ilyen feladat. A címkéket pedig nagyon-nagyon sokat használjuk, mert az infrastruktúra nagy és drága. És meg kell néznünk, hogy hová megy a pénz, így a címkék segítségével lebonthatjuk, mi hová ment. És ennek megfelelően itt költenek valami olyasmire, ami sok pénzt jelent.
Mire vonatkozott még a kérdés?
Amikor az SG több száz példányt hoz létre, meg kell őket különböztetni valahogy?
Nem, nem. Minden esetben van egy ügynök, aki jelenti, hogy problémám van. Ha egy ügynök jelent, akkor az ügynök tud róla, és legalább az IP-címe létezik. Máris elfuthatsz. Másodszor, a Consul for Discovery-t használjuk, ahol a Kubernetes nem. És a Consul megmutatja a példány IP-címét is.
Vagyis kifejezetten az IP-re koncentrálsz, és nem a hostnévre?
Gazdanév alapján nem lehet navigálni, vagyis rengeteg van. Vannak példányazonosítók - AE stb. Valahol megtalálod, be tudod dobni a keresésbe.
Helló! Rájöttem, hogy a Terraform jó dolog, a felhőkre szabva.
Nem csak.
Pontosan ez a kérdés érdekel. Ha úgy döntesz, hogy az összes példányoddal tömegesen költözöl mondjuk a Bare Metalhoz? Lesz valami probléma? Vagy továbbra is más termékeket kell használnia, például ugyanazt az Ansible-t, amelyet itt említettek?
Az Ansible egy kicsit másról szól. Vagyis az Ansible már működik, amikor a példány elindult. A Terraform pedig a példány indulása előtt működik. Váltás Bare Metalra – nem.
Nem most, de jön az üzlet, és azt mondják: „Gyerünk!”
Váltás másik felhőre – igen, de itt van egy kicsit más trükk. A Terraform kódot úgy kell megírnia, hogy kisebb erőfeszítéssel át tudjon váltani más felhőre.
Kezdetben az volt a feladat, hogy a teljes infrastruktúránk agnosztikus legyen, azaz bármilyen felhőnek megfelelőnek kell lennie, de valamikor az üzlet feladta, és azt mondta: „Rendben, a következő N évben nem megyünk sehova, használhatjuk a szolgáltatásokat. az Amazonról"
A Terraform lehetővé teszi Front-End munkák létrehozását, a PagerDuty konfigurálását, adatdokumentumot stb. Sok farka van. Gyakorlatilag az egész világot irányítani tudja.
Köszönöm a beszámolót! Én is a Terraformot használom 4 éve. A Terraformra, az infrastruktúrára, a deklaratív leírásra való zökkenőmentes átmenet szakaszában olyan helyzettel szembesültünk, hogy valaki kézzel csinál valamit, te pedig tervet próbáltál készíteni. És ott van valami hiba. Hogyan kezeli az ilyen problémákat? Hogyan találja meg a felsorolt elveszett erőforrásokat?
Főleg a kezünkkel és a szemünkkel, ha valami furcsát látunk a riportban, akkor elemezzük, mi történik ott, vagy egyszerűen ölünk. Általánosságban elmondható, hogy a lehívási kérések gyakoriak.
Ha hiba van, visszaállítod? Próbáltad ezt megtenni?
Nem, ez egy személy döntése abban a pillanatban, amikor problémát lát.
Forrás: will.com