Zdá sa, že vývojári Terraform ponúkajú pomerne pohodlné najlepšie postupy pre prácu s infraštruktúrou AWS. Existuje len nuansa. Postupom času sa zvyšuje počet prostredí, z ktorých každé má svoje vlastné funkcie. V susednej oblasti sa objaví takmer kópia zásobníka aplikácií. A kód Terraform je potrebné starostlivo skopírovať a upraviť podľa nových požiadaviek alebo urobiť z neho snehovú vločku.
Moja reč o vzoroch v Terraforme na boj proti chaosu a manuálnej rutine na veľkých a dlhých projektoch.
Video:
Mám 40 rokov, v IT sa pohybujem 20 rokov. Pre Ixtens pracujem 12 rokov. Zaoberáme sa vývojom poháňaným elektronickým obchodom. A praktikám DevOps sa venujem už 5 rokov.
Môj príbeh bude o mojej skúsenosti z projektu v spoločnosti, ktorej meno nepoviem, skrývajúcej sa za dohodu o mlčanlivosti.
Čísla na snímke sú uvedené, aby ste pochopili rozsah projektu. A všetko, čo poviem ďalej, súvisí s Amazonom.
Do tohto projektu som sa zapojil pred 4 rokmi. A refaktoring infraštruktúry bol v plnom prúde, pretože projekt sa rozrástol. A vzory, ktoré sa používali, už neboli vhodné. A vzhľadom na celý plánovaný rast projektu bolo potrebné prísť s niečím novým.
Vďaka Matveymu, ktorý nám včera povedal, čo sa stalo v Dodo Pizza. Toto sa tu stalo pred 4 rokmi.
Prišli vývojári a začali vytvárať kód infraštruktúry.
Najzrejmejším dôvodom, prečo to bolo potrebné, bol čas uvedenia na trh. Bolo potrebné zabezpečiť, aby tím DevOps nebol prekážkou počas zavádzania. A okrem iného boli na úplne prvej úrovni použité Terraform a Puppet.
Terraform je open source projekt od HashiCorp. A pre tých, ktorí ani nevedia, čo to je, niekoľko ďalších snímok.
Infraštruktúra ako kód znamená, že môžeme opísať našu infraštruktúru a požiadať niektoré roboty, aby sa uistili, že dostaneme zdroje, ktoré sme opísali.
Napríklad potrebujeme virtuálny stroj. Popíšeme a doplníme niekoľko požadovaných parametrov.
Potom nakonfigurujeme prístup k Amazonu v konzole. A požiadame o plán Terraform. Plán Terraform hovorí: "Dobre, môžeme urobiť tieto veci pre váš zdroj." A pribudne aspoň jeden zdroj. A neočakávajú sa žiadne zmeny.
Keď budete so všetkým spokojní, môžete požiadať Terraform o prihlásenie a Terraform vám vytvorí inštanciu a vy dostanete virtuálny stroj do svojho cloudu.
Náš projekt sa ďalej rozvíja. Pridávame tam nejaké zmeny. Žiadame ďalšie prípady, pridávame 53 záznamov.
A opakujeme. Prosím plánujte. Vidíme, aké zmeny sa plánujú. Aplikujeme. A takto rastie naša infraštruktúra.
Terraform používa niečo, čo sa nazýva stavové súbory. To znamená, že všetky zmeny, ktoré prejdú na Amazon, sa uložia do súboru, kde pre každý zdroj, ktorý ste opísali, existujú zodpovedajúce zdroje, ktoré boli vytvorené v Amazone. Keď sa teda zmení popis zdroja, Terraform presne vie, čo treba v Amazone zmeniť.
Tieto stavové súbory boli pôvodne len súbory. A uložili sme ich v Git, čo bolo mimoriadne nepohodlné. Vždy niekto zabudol urobiť zmeny a vzniklo veľa konfliktov.
Teraz je možné použiť backend, t.j. Terraform je špecifikovaný, do ktorého vedra a akým kľúčom sa má súbor stavu uložiť. A samotný Terraform sa postará o získanie tohto súboru stavu, urobí všetky kúzla a vráti konečný výsledok.
Naša infraštruktúra rastie. Tu je náš kód. A teraz nechceme len vytvoriť virtuálny stroj, chceme mať testovacie prostredie.
Terraform vám umožňuje vytvoriť niečo ako modul, to znamená opísať to isté v nejakom priečinku.
A napríklad pri testovaní zavolajte tento modul a získate to isté, ako keby sme v samotnom module spustili aplikáciu Terraform. Na testovanie bude tento kód.
Pre produkciu tam môžeme poslať nejaké zmeny, pretože pri testovaní nepotrebujeme veľké inštancie, v produkcii sú veľké inštancie len užitočné.
A potom sa vrátim späť k projektu. Bola to náročná úloha, plánovaná infraštruktúra bola veľmi rozsiahla. A bolo potrebné nejakým spôsobom umiestniť celý kód tak, aby to bolo vhodné pre všetkých: pre tých, ktorí vykonávajú údržbu tohto kódu, aj pre tých, ktorí robia zmeny. A plánovalo sa, že každý vývojár môže ísť opraviť infraštruktúru podľa potreby pre jeho časť platformy.
Toto je strom adresárov, ktorý odporúča samotný HashiCorp, ak máte veľký projekt a má zmysel rozdeliť celú infraštruktúru na niekoľko malých častí a opísať každú časť v samostatnom priečinku.
S rozsiahlou knižnicou zdrojov môžete pri testovaní a výrobe volať približne to isté.
V našom prípade to nebolo úplne vhodné, pretože testovací zásobník pre vývojárov alebo na testovanie bolo potrebné získať akosi jednoduchšie. Nechcel som však prechádzať priečinky a aplikovať ich v požadovanom poradí a obávať sa, že databáza narastie a potom vzrastie inštancia, ktorá túto databázu používa. Preto bolo celé testovanie spustené z jedného priečinka. Volali sa tam rovnaké moduly, ale všetko sa robilo na jeden chod.
Terraform sa postará o všetky závislosti. A vždy vytvára zdroje v poradí, aby ste mohli získať IP adresu napríklad z novovytvorenej inštancie a získať túto IP adresu v zázname route53.
Platforma je navyše veľmi veľká. A spustenie testovacieho zásobníka, aj keď na hodinu, aj keď na 8 hodín, je dosť nákladná záležitosť.
A túto záležitosť sme zautomatizovali. A Jenkinsova úloha nám umožnila spustiť zásobník. V ňom bolo potrebné spustiť pull request so zmenami, ktoré chce vývojár otestovať, špecifikovať všetky potrebné možnosti, komponenty a rozmery. Ak chce testovanie výkonu, môže vykonať viac inštancií. Ak potrebuje len skontrolovať, či sa otvára nejaký formulár, potom by mohol začať na minimálnej mzde. A tiež uveďte, či je klaster potrebný alebo nie, atď.
A potom Jenkins vložil shell skript, ktorý mierne upravil kód v priečinku Terraform. Odstránil som nepotrebné súbory a pridal potrebné súbory. A potom jedným spustením aplikácie Terraform sa zásobník zdvihol.
A potom boli ďalšie kroky, do ktorých nechcem ísť.
Vzhľadom na to, že na testovanie sme potrebovali trochu viac možností ako vo výrobe, museli sme urobiť kópie modulov, aby sme do týchto kópií mohli pridať tie funkcie, ktoré boli potrebné len na testovanie.
A tak sa stalo, že pri testovaní som tak trochu chcel otestovať tie zmeny, ktoré sa nakoniec dostanú do výroby. Ale v skutočnosti sa testovala jedna vec a pri výrobe bola použitá trochu iná. A došlo k malému zlomu v modeli, že vo výrobe všetky zmeny aplikoval operačný tím. A niekedy sa ukázalo, že tie zmeny, ktoré mali prejsť z testovania do výroby, zostali v inej verzii.
Navyše sa vyskytol taký problém, že pribudla nová služba, ktorá sa mierne líšila od niektorých už existujúcich. A namiesto úpravy existujúceho modulu sme museli urobiť jeho kópiu a pridať potrebné zmeny.
Terraform v podstate nie je skutočný jazyk. Toto je vyhlásenie. Ak niečo potrebujeme deklarovať, tak to deklarujeme. A všetko to funguje.
V určitom okamihu, keď sa diskutovalo o jednej z mojich požiadaviek na ťahanie, jeden z mojich kolegov povedal, že nie je potrebné vytvárať snehové vločky. Zaujímalo ma, čo tým myslel. Existuje vedecký fakt, že na svete neexistujú dve rovnaké snehové vločky, všetky sú mierne odlišné. A hneď ako som to počul, okamžite som pocítil celú váhu kódu Terraform. Pretože keď bolo potrebné prejsť z verzie na verziu, Terraform vyžadoval zmeny reťazca prerušenia, t. j. kód už nebol kompatibilný s ďalšou verziou. A museli sme zadať požiadavku na stiahnutie, ktorá pokrývala takmer polovicu súborov v infraštruktúre, aby sme infraštruktúru preniesli do ďalšej verzie Terraformu.
A potom, čo sa objavila takáto snehová vločka, všetok kód Terraform, ktorý sme premenili na veľkú, veľkú hromadu snehu.
Pre externého vývojára, ktorý je mimo prevádzky, to nemá veľký význam, pretože zadal požiadavku na stiahnutie, jeho zdroj sa spustil. A to je všetko, už to nie je jeho starosť. A všetky tieto zmeny musí vykonať tím DevOps, ktorý sa stará o to, aby bolo všetko v poriadku. A náklady na tieto zmeny sa s každou ďalšou snehovou vločkou veľmi, veľmi zvyšovali.
Existuje príbeh o tom, ako študent na seminári nakreslí kriedou na tabuľu dva dokonalé kruhy. A učiteľ je prekvapený, ako dokázal tak hladko kresliť bez kružidla. Študent odpovedá: "Veľmi jednoducho, dva roky som strávil v armáde a otáčal mlynčekom na mäso."
A zo štyroch rokov, čo sa tomuto projektu venujem, robím Terraform asi dva roky. A, samozrejme, mám nejaké triky, pár rád, ako zjednodušiť kód Terraform, pracovať s ním ako s programovacím jazykom a znížiť záťaž pre vývojárov, ktorí musia tento kód aktualizovať.
Prvá vec, ktorou by som chcel začať, sú Symlinks. Terraform má veľa opakujúceho sa kódu. Napríklad volanie poskytovateľovi takmer v každom bode, kde vytvárame časť infraštruktúry, je rovnaké. A je logické umiestniť ho do samostatného priečinka. A všade tam, kde sa od poskytovateľa vyžaduje, aby vytvoril symbolické odkazy na tento súbor.
Napríklad v produkcii používate prevziať rolu, ktorá vám umožňuje získať prístupové práva k nejakému externému účtu Amazon. A po zmene jedného súboru budú mať všetky zostávajúce v strome zdrojov požadované práva, aby Terraform vedel, ku ktorému segmentu Amazonu má pristupovať.
Kde zlyhávajú symbolické odkazy? Ako som povedal, Terraform má stavové súbory. A sú veľmi, veľmi cool. Ide však o to, že Terraform v prvom rade inicializuje backend. A v týchto parametroch nemôže použiť žiadne premenné, tie musia byť vždy zapísané v texte.
A v dôsledku toho, keď niekto vytvorí nový zdroj, skopíruje časť kódu z iných priečinkov. A môže sa pomýliť s kľúčom alebo s vedrom. Napríklad vyrobí pieskovisko z pieskoviska a potom ho vyrobí vo výrobe. A tak to môže dopadnúť tak, že vedro vo výrobe bude použité z pieskoviska. Samozrejme, že to rýchlo nájdu. Dá sa to nejako napraviť, no napriek tomu je to strata času a do istej miery aj prostriedkov.
Čo môžeme urobiť ďalej? Pred prácou s Terraformom ho musíte inicializovať. Pri inicializácii Terraform stiahne všetky pluginy. V určitom bode sa rozdelili z monolitu na architektúru viac mikroslužieb. A vždy musíte vykonať Terraform init tak, aby stiahol všetky moduly, všetky pluginy.
A môžete použiť skript shellu, ktorý po prvé dokáže získať všetky premenné. Shell skript nie je nijako obmedzený. A po druhé, cesty. Ak vždy použijeme cestu, ktorá je v úložisku, ako kľúč k súboru stavu, potom sa chyba tu odstráni.
Kde môžem získať údaje? súbor JSON. Terraform umožňuje písať infraštruktúru nielen v hcl (HashiCorp Configuration Language), ale aj v JSON.
JSON je ľahko čitateľný zo skriptu shell. V súlade s tým môžete umiestniť konfiguračný súbor s vedro na nejaké miesto. A použite tento vedro v kóde Terraform aj v skripte shellu na inicializáciu.
Prečo je dôležité mať vedro pre Terraform? Pretože existuje niečo ako súbory vzdialeného stavu. To znamená, že keď zvýšim nejaký zdroj, aby som Amazonu povedal: „Prosím, zvýšte inštanciu“, musím zadať veľa požadovaných parametrov.
A tieto identifikátory sú uložené v nejakom inom priečinku. A môžem ísť a povedať: "Terraform, prosím, bež do štátneho súboru toho zdroja a prines mi tieto identifikátory." A tak dochádza k určitému zjednoteniu medzi rôznymi regiónmi či prostrediami.
Nie vždy je možné použiť vzdialený stavový súbor. Napríklad ste vytvorili VPC ručne. A kód Terraform, ktorý vytvára VPC, vytvára také rozdielne VPC, že to bude trvať veľmi dlho a budete musieť prispôsobiť jeden druhému, takže môžete použiť nasledujúci trik.
To znamená, že vytvorte modul, ktorý vyzerá, že vytvára VPC a ako keby vám dáva identifikátory, ale v skutočnosti existuje jednoducho súbor s pevne zakódovanými hodnotami, ktoré možno použiť na vytvorenie rovnakej inštancie.
Nie vždy je potrebné uložiť súbor stavu do cloudu. Napríklad pri testovaní modulov môžete využiť inicializáciu backendu, kde sa súbor v čase testovania jednoducho uloží na disk.
Teraz trochu o testovaní. Čo môžete v Terraforme testovať? Možno je toho veľa, ale budem hovoriť o týchto 4 veciach.
HashiCorp rozumie tomu, ako by sa mal kód Terraform formátovať. A Terraform fmt vám umožňuje formátovať kód, ktorý upravujete podľa tohto presvedčenia. V súlade s tým musia testy nevyhnutne skontrolovať, či formátovanie zodpovedá tomu, čo HashiCorp odkázal, takže nie je potrebné meniť umiestnenie zátvoriek atď.
Ďalším je Terraform validate. Robí o niečo viac, ako len skontroluje syntax - ala, či sú spárované všetky zátvorky. Čo je tu dôležité? Naša infraštruktúra je veľmi rozsiahla. Je v nej veľa rôznych tátošov. A v každom musíte spustiť Terraform validate.
V súlade s tým, aby sme urýchlili testovanie, spúšťame paralelne viacero procesov pomocou paralelného použitia.
Parallel je veľmi skvelá vec, použite ju.
Ale zakaždým, keď sa Terraform inicializuje, prejde do HashiCorp a spýta sa: „Aké sú najnovšie verzie doplnkov? A plugin, ktorý mám vo vyrovnávacej pamäti – je ten správny alebo nesprávny? A toto sa spomaľovalo na každom kroku.
Ak Terraformu poviete, kde sú pluginy, Terraform povie: „Dobre, toto je pravdepodobne najnovšia vec, ktorá tam je. Nikam nepôjdem, okamžite začnem overovať váš kód Terraform."
Aby sme naplnili priečinok potrebnými pluginmi, máme veľmi jednoduchý Terraform kód, ktorý stačí inicializovať. Tu, samozrejme, musíte špecifikovať všetkých poskytovateľov, ktorí sa nejakým spôsobom podieľajú na vašom kóde, inak Terraform povie: „Nepoznám určitého poskytovateľa, pretože nie je vo vyrovnávacej pamäti.“
Ďalej je plán Terraform. Ako som povedal, vývoj je cyklický. Vykonávame zmeny v kóde. A potom musíte zistiť, aké zmeny sa plánujú v infraštruktúre.
A keď je infraštruktúra veľmi, veľmi veľká, môžete zmeniť jeden modul, opraviť nejaké testovacie prostredie alebo určitú špecifickú oblasť a zlomiť susednú. Plán Terraform by sa preto mal urobiť pre celú infraštruktúru a ukázať, aké zmeny sa plánujú.
Môžete to urobiť šikovne. Napísali sme napríklad skript Python, ktorý rieši závislosti. A v závislosti od toho, čo sa zmenilo: modul Terraform alebo len konkrétny komponent, vytvára plány pre všetky závislé priečinky.
Teraformné plány je potrebné vypracovať na požiadanie. Aspoň to tak robíme.
Samozrejme, je dobré robiť testy pre každú zmenu, pre každý záväzok, ale plány sú dosť drahá vec. A v žiadosti o stiahnutie hovoríme: "Prosím, dajte mi plány." Robot sa spustí. A pošle komentáre alebo pripojí všetky plány, ktoré sa od vašich zmien očakávajú.
Plán je dosť drahá vec. Chce to čas, pretože Terraform ide do Amazonu a pýta sa: „Existuje ešte tento prípad? Má táto automatická mierka presne rovnaké parametre? A aby ste to urýchlili, môžete použiť parameter ako refresh=false. To znamená, že Terraform stiahne stav z S3. A bude veriť, že štát bude presne zodpovedať tomu, čo je v Amazone.
Takýto plán Terraform ide oveľa rýchlejšie, ale stav musí zodpovedať vašej infraštruktúre, teda niekde sa musí niekedy spustiť obnova Terraformu. Terraform refresh robí presne to: stav zodpovedá tomu, čo je v skutočnej infraštruktúre.
A musíme hovoriť o bezpečnosti. Tu sme museli začať. Tam, kde spúšťate Terraform a Terraform beží na vašej infraštruktúre, existuje zraniteľnosť. To znamená, že v podstate vykonávate kód. A ak požiadavka na stiahnutie obsahuje nejaký druh škodlivého kódu, môže byť vykonaná na infraštruktúre, ktorá má príliš veľký prístup. Takže buďte opatrní, kde spustíte plán Terraform.
Ďalšia vec, o ktorej by som chcel hovoriť, je testovanie používateľských údajov.
Čo sú používateľské údaje? V Amazone, keď vytvoríme inštanciu, môžeme poslať určitý list s inštanciou - meta dáta. Keď sa inštancia spustí, zvyčajne je v týchto inštanciách vždy prítomný cloud init. Cloud init prečíta tento list a povie: „Dobre, dnes som vyrovnávačom záťaže.“ A v súlade s týmito zmluvami vykonáva nejaké činy.
Ale, bohužiaľ, keď použijeme plán Terraform a použijeme Terraform, používateľské údaje vyzerajú ako takáto kaša čísel. To znamená, že vám jednoducho pošle hash. A v pláne sa môžete pozrieť len na to, či dôjde k nejakým zmenám alebo či hash zostane rovnaký.
A ak tomu nevenujete pozornosť, nejaký nefunkčný textový súbor môže skončiť na Amazone, v skutočnej infraštruktúre.
Prípadne pri vykonávaní môžete zadať nie celú infraštruktúru, ale iba šablónu. A v kóde povedzte: "Zobrazte túto šablónu na mojej obrazovke." A ako výsledok, môžete získať výtlačok toho, ako budú vaše dáta vyzerať na Amazone.
Ďalšou možnosťou je použiť modul na generovanie užívateľských dát. Tento modul použijete. Dostanete súbor na disku. Porovnajte ho s referenčným. A teda, ak sa nejaký chlapík rozhodne trochu opraviť používateľské údaje, potom vaše testy povedia: „OK, tu a tam sú nejaké zmeny – to je normálne.“
Ďalšia vec, o ktorej by som chcel hovoriť, je aplikácia Automate Terraform.
Samozrejme, je dosť strašidelné aplikovať Terraform v automatickom režime, pretože ktovie, aké zmeny tam nastali a aké deštruktívne môžu byť pre živú infraštruktúru.
V testovacom prostredí je to všetko normálne. To znamená, že práca, ktorá vytvára testovacie prostredie, je to, čo potrebujú všetci vývojári. A výraz ako „všetko pre mňa fungovalo“ nie je vtipný meme, ale dôkaz toho, že sa človek pomýlil, zdvihol stack a vykonal nejaké testy na tomto stacku. A uistil sa, že je tam všetko v poriadku a povedal: "Dobre, kód, ktorý vydávam, bol otestovaný."
V produkčných, karanténnych a iných prostrediach, ktoré sú kritickejšie pre podnikanie, môžete čiastočne používať niektoré zdroje celkom bezpečne, pretože to nevedie k žiadnej smrti. Sú to: skupiny automatického škálovania, bezpečnostné skupiny, roly, route53 a zoznam môže byť dosť veľký. Ale sledujte, čo sa deje, čítajte správy automatizovaných aplikácií.
Tam, kde je použitie nebezpečné alebo desivé, napríklad ak ide o nejaké trvalé zdroje z databázy, dostávajte správy, že v niektorej časti infraštruktúry sú neaplikované zmeny. A inžinier pod dohľadom spúšťa úlohy na aplikáciu alebo to robí zo svojej konzoly.
Amazon má takú vec ako Terminate protection. A v niektorých prípadoch môže chrániť pred zmenami, ktoré pre vás nie sú potrebné. To znamená, že Terraform išiel do Amazonu a povedal: "Musím zabiť túto inštanciu, aby som vytvoril ďalšiu." A Amazon hovorí: „Prepáčte, dnes nie. Máme ochranu Ukončiť."
A čerešničkou na torte je optimalizácia kódu. Keď pracujeme s kódom Terraform, musíme modulu odovzdať veľmi veľké množstvo parametrov. Toto sú parametre, ktoré sú potrebné na vytvorenie nejakého zdroja. A kód sa zmení na veľké zoznamy parametrov, ktoré je potrebné odovzdať z modulu do modulu, z modulu do modulu, najmä ak sú moduly vnorené.
A veľmi ťažko sa to číta. Je veľmi ťažké to posúdiť. A veľmi často sa ukáže, že niektoré parametre prechádzajú revíziou a nie sú presne to, čo je potrebné. A to stojí čas a peniaze na opravu neskôr.
Preto vám navrhujem použiť niečo ako komplexný parameter, ktorý zahŕňa určitý strom hodnôt. To znamená, že potrebujete nejaký priečinok, kde máte všetky hodnoty, ktoré by ste chceli mať v nejakom prostredí.
A volaním tohto modulu môžete získať strom, ktorý sa generuje v jednom spoločnom module, teda v spoločnom module, ktorý funguje rovnako pre celú infraštruktúru.
V tomto module môžete robiť nejaké výpočty pomocou takejto nedávnej funkcie v Terraforme ako miestni obyvatelia. A potom s jedným výstupom zadajte nejaký komplexný parameter, ktorý môže zahŕňať hash poľa atď.
Tu skončili všetky moje najlepšie nálezy. A rád by som porozprával príbeh o Kolumbovi. Keď zháňal peniaze na svoju výpravu za objavením Indie (ako si vtedy myslel), nikto mu neveril a mysleli si, že je to nemožné. Potom povedal: "Uisti sa, že vajce nespadne." Všetci bankári, veľmi bohatí a pravdepodobne chytrí ľudia, sa pokúšali vajíčko nejako umiestniť a stále padalo. Potom Kolumbus vzal vajce a trochu ho stlačil. Škrupina sa pokrčila a vajce zostalo nehybné. Povedali: "Ó, to je príliš ľahké!" A Kolumbus odpovedal: „Áno, je to príliš jednoduché. A keď otvorím Indiu, každý bude využívať túto obchodnú cestu.“
A to, čo som vám práve povedal, sú pravdepodobne celkom jednoduché a triviálne veci. A keď sa o nich dozviete a začnete ich používať, je to v poradí vecí. Tak využite. A ak sú to pre vás úplne bežné veci, tak aspoň viete, ako umiestniť vajíčko, aby nespadlo.
Zhrňte:
- Pokúste sa vyhnúť snehovým vločkám. A čím menej snehových vločiek, tým menej zdrojov budete potrebovať na vykonanie akýchkoľvek zmien vo vašej veľkej infraštruktúre.
- Neustále zmeny. To znamená, že keď sa v kóde vyskytnú nejaké zmeny, musíte čo najrýchlejšie uviesť svoju infraštruktúru do súladu s týmito zmenami. Nemala by nastať situácia, že sa niekto príde pozrieť na Elasticsearch o dva alebo tri mesiace neskôr, vytvorí plán Terraform a bude tam veľa zmien, ktoré neočakával. A dať všetko do poriadku si vyžaduje veľa času.
- Testy a automatizácia. Čím viac je váš kód pokrytý testami a funkciami, tým máte väčšiu istotu, že robíte všetko správne. A automatické doručovanie mnohonásobne zvýši vašu dôveru.
- Kód pre testovacie a produkčné prostredie by mal byť takmer rovnaký. Prakticky preto, že výroba je predsa len trochu iná a stále tu budú nejaké nuansy, ktoré budú presahovať testovacie prostredie. Ale napriek tomu sa to plus mínus dá zabezpečiť.
- A ak máte veľa kódu Terraform a udržiavanie tohto kódu v aktuálnom stave zaberie veľa času, potom nikdy nie je neskoro na to, aby ste ho zrefaktorovali a dostali do dobrého stavu.
- Nemenná infraštruktúra. Dodávka AMI podľa plánu.
- Štruktúra pre route53, keď máte veľa záznamov a chcete, aby boli v konzistentnom poradí.
- Boj proti rýchlostným limitom API. To je, keď Amazon hovorí: "To je všetko, nemôžem prijať žiadne ďalšie žiadosti, počkajte." A polovica úradu čaká, kým spustí svoju infraštruktúru.
- Spotové prípady. Amazon nie je lacná akcia a spoty vám umožňujú ušetriť pomerne veľa. A tam o tom môžete povedať celú správu.
- Roly zabezpečenia a IAM.
- Hľadanie stratených zdrojov, keď máte prípady neznámeho pôvodu v Amazone, žerú peniaze. Aj keď inštancie stoja 100 až 150 dolárov mesačne, je to viac ako 1 000 dolárov ročne. Hľadanie takýchto zdrojov je ziskový obchod.
- A vyhradené prípady.
To je z mojej strany všetko. Terraform je veľmi cool, používaš ho. Ďakujem!
otázky
Ďakujeme za správu! Váš súbor stavu je v S3, ale ako vyriešite problém, že niekoľko ľudí môže vziať tento súbor stavu a pokúsiť sa ho rozšíriť?
V prvom rade sa nikam neponáhľame. Po druhé, existujú príznaky, v ktorých oznamujeme, že pracujeme na nejakom kúsku kódu. To znamená, že napriek tomu, že infraštruktúra je veľmi veľká, neznamená to, že niekto neustále niečo používa. A keď bola aktívna fáza, bol to problém; stavové súbory sme uložili v Git. To bolo dôležité, inak by si niekto urobil štátny spis a my sme ich museli ručne poskladať, aby všetko pokračovalo. Teraz už takýto problém neexistuje. Vo všeobecnosti Terraform tento problém vyriešil. A ak sa niečo neustále mení, potom môžete použiť zámky, ktoré zabránia tomu, čo ste povedali.
Používate open source alebo enterprise?
Žiadny podnik, t. j. všetko, čo môžete ísť a stiahnuť zadarmo.
Volám sa Stanislav. Chcel som urobiť malý dodatok. Hovorili ste o funkcii Amazonu, ktorá vám umožňuje urobiť inštanciu nezničiteľnou. To je aj v samotnom Terraforme, v bloku Life Second môžete určiť zákaz zmien alebo zákaz ničenia.
Čas bol obmedzený. Dobrá poznámka.
Tiež som sa chcel opýtať na dve veci. Najprv ste hovorili o testovaní. Použili ste nejaké testovacie nástroje? Počul som o doplnku Test Kitchen. Možno existuje niečo viac. A ešte by som sa chcel opýtať na Miestne hodnoty. Ako sa zásadne líšia od vstupných premenných? A prečo nemôžem niečo parametrizovať iba cez Lokálne hodnoty? Snažil som sa prísť na túto tému, ale nejako som na to nemohol prísť sám.
Môžeme hovoriť podrobnejšie mimo tejto miestnosti. Naše testovacie nástroje sú vyrobené úplne sami. Nie je tam čo testovať. Vo všeobecnosti existujú možnosti, keď automatizované testy niekde vyberú infraštruktúru, skontrolujú, či je v poriadku, a potom všetko zničia s hlásením, že vaša infraštruktúra je stále v dobrom stave. Nemáme to, pretože testovacie zásobníky sa spúšťajú každý deň. A to stačí. A ak sa niečo začne lámať, začne sa to lámať bez toho, aby sme to niekde inde skontrolovali.
Čo sa týka miestnych hodnôt, pokračujme v rozhovore mimo miestnosti.
Ahoj! Ďakujeme za správu! Veľmi informatívne. Povedali ste, že máte veľa rovnakého typu kódu na popis infraštruktúry. Uvažovali ste o vygenerovaní tohto kódu?
Skvelá otázka, ďakujem! Ide o to, že keď používame infraštruktúru ako kód, predpokladáme, že sa pozrieme na kód a pochopíme, aká infraštruktúra sa za týmto kódom skrýva. Ak sa vygeneruje kód, musíme si predstaviť, aký kód sa vygeneruje, aby sme pochopili, aký druh infraštruktúry tam bude. Buď vygenerujeme kód, zaviažeme ho a v podstate sa stane to isté. Tak sme išli cestou, ktorú sme napísali, dostali sme ju. Plusové generátory sa objavili o niečo neskôr, keď sme ich začali vyrábať. A na zmenu už bolo neskoro.
Počuli ste niečo o jsonnete?
Nie.
Pozri, toto je veľmi skvelá vec. Vidím konkrétny prípad, keď ho môžete použiť a vygenerovať dátovú štruktúru.
Generátory sú dobré, keď ich máte, ako vo vtipe o holiacom strojčeku. To znamená, že prvýkrát je tvár iná, ale potom majú všetci rovnakú tvár. Generátory fungujú veľmi dobre. Ale, bohužiaľ, naše tváre sú trochu iné. Toto je problém.
Len sa pozri. Ďakujem!
Volám sa Maxim, som zo Sberbank. Hovorili ste trochu o tom, ako ste sa pokúšali priviesť Terraform na ekvivalent programovacieho jazyka. Nie je jednoduchšie použiť Ansible?
To sú veľmi odlišné veci. Môžete vytvárať zdroje v Ansible a Puppet môže vytvárať zdroje v Amazone. Ale Terraform je naostrený.
Máte iba Amazon?
Nie je to tak, že máme len Amazon. Máme takmer len Amazon. Ale kľúčovou vlastnosťou je, že si Terraform pamätá. Ak v Ansible poviete: „Daj mi 5 prípadov“, potom sa to zvýši a potom povieš: „A teraz potrebujem 3.“ A Terraform povie: "Dobre, zabijem 2," a Ansible povie: "Dobre, tu sú 3 pre teba." Celkom 8.
Ahoj! Ďakujeme za vašu správu! Bolo veľmi zaujímavé počuť o Terraforme. Hneď by som chcel urobiť malú poznámku o tom, že Terraform stále nemá stabilné vydanie, takže s Terraformom zaobchádzajte veľmi opatrne.
Dobrá lyžica na večeru. Teda ak potrebuješ riešenie, tak občas odložíš, čo je nestabilné a pod., ale funguje to a nám to pomohlo.
Otázkou je toto. Používate vzdialený backend, používate S 3. Prečo nepoužívate oficiálny backend?
Oficiálne?
Terraform Cloud.
Kedy sa objavil?
Asi pred 4 mesiacmi.
Ak by sa to objavilo pred 4 rokmi, asi by som na vašu otázku odpovedal.
K dispozícii je už vstavaná funkcia a zámky a môžete uložiť súbor stavu. Pokúsiť sa. Ale ani to nemám odskúšané.
Cestujeme vo veľkom vlaku, ktorý sa pohybuje vysokou rýchlosťou. A nemôžete len tak vziať pár áut a vyhodiť ich.
Hovorili ste o snehových vločkách, prečo ste nepoužili vetvu? Prečo to tak nevyšlo?
Náš prístup je taký, že celá infraštruktúra je v jednom úložisku. Terraform, Puppet, všetky skripty, ktoré s tým nejako súvisia, všetky sú v jednom úložisku. Týmto spôsobom môžeme zabezpečiť, aby sa prírastkové zmeny testovali jedna po druhej. Ak by išlo o kopu pobočiek, potom by sa takýto projekt takmer nedal udržať. Prejde šesť mesiacov a rozchádzajú sa natoľko, že je to len nejaký trest. To je to, z čoho som chcel uniknúť pred refaktorizáciou.
Takže to nejde?
Toto vôbec nefunguje.
Vo vetve som vyrezal diapozitív. To znamená, že ak to urobíte pre každý testovací zásobník, napríklad tím A má svoj vlastný priečinok, tím B má svoj vlastný priečinok, potom to tiež nefunguje. Vytvorili sme jednotný kód testovacieho prostredia, ktorý bol dostatočne flexibilný, aby vyhovoval všetkým. To znamená, že sme podávali jeden kód.
Ahoj! Moje meno je Yura! Ďakujeme za správu! Otázka o moduloch. Hovoríte, že používate moduly. Ako vyriešite problém, ak boli v jednom module vykonané zmeny, ktoré nie sú kompatibilné so zmenou inej osoby? Robíte nejakým spôsobom verzie modulov alebo sa snažíte priniesť wunderwaffle, aby ste splnili dve požiadavky?
Toto je veľký problém s kopou snehu. To je to, čím trpíme, keď nejaká neškodná zmena môže narušiť niektorú časť infraštruktúry. A to bude viditeľné až po dlhšom čase.
To znamená, že to ešte nie je vyriešené?
Vyrábate univerzálne moduly. Vyhnite sa snehovým vločkám. A všetko bude fungovať. Druhá polovica správy je o tom, ako sa tomu vyhnúť.
Ahoj! Ďakujeme za správu! Chcel by som to objasniť. V zákulisí bola veľká kopa, po ktorú som prišiel. Ako sú integrované bábky a distribúcia rolí?
Použivateľské dáta.
To znamená, že ste len vypľuli súbor a nejako ho spustili?
Používateľské údaje sú poznámka, t. j. keď vytvoríme klon obrazu, Daemon tam vstane a v snahe zistiť, kto to je, prečíta poznámku, že je vyrovnávačom zaťaženia.
To znamená, že je to nejaký samostatný proces, ktorý je daný?
My sme si to nevymysleli. Používame to.
Ahoj! Mám len otázku ohľadom Užívateľ - dáta. Povedali ste, že sú tam problémy, že niekto môže poslať niečo na nesprávne miesto. Existuje nejaký spôsob, ako uložiť používateľské údaje v rovnakom Gite, aby bolo vždy jasné, na čo sa používateľské údaje vzťahujú?
Vygenerujeme užívateľské dáta zo šablóny. To znamená, že sa tam používa určitý počet premenných. A Terraform generuje konečný výsledok. Preto sa nemôžete len pozrieť na šablónu a povedať, čo sa stane, pretože všetky problémy súvisia s tým, že vývojár si myslí, že v tejto premennej odovzdáva reťazec, ale používa sa tam pole. A on - bam a ja - taký a taký, taký a taký, ďalší riadok a všetko sa zlomilo. Ak je to nový zdroj a človek si ho zoberie a vidí, že niečo nefunguje, tak je to rýchlo vyriešené. A ak sa táto skupina automatického škálovania aktualizuje, potom sa v určitom bode začnú nahrádzať inštancie v skupine automatického škálovania. A bum, niečo nefunguje. Bolí to.
Ukazuje sa, že jediným riešením je test?
Áno, vidíte problém, pridáte tam testovacie kroky. To znamená, že výstup môže byť tiež testovaný. Možno to nie je také pohodlné, ale môžete tiež uviesť nejaké značky - skontrolujte, či sú tu uvedené údaje používateľa.
Volám sa Timur. Je skvelé, že existujú správy o tom, ako správne organizovať Terraform.
Ešte som ani nezačal.
Myslím, že možno na ďalšej konferencii bude. mam jednoduchu otazku. Prečo napevno kódujete hodnotu v samostatnom module namiesto použitia tfvars, t.j. prečo je modul s hodnotami lepší ako tfvars?
To znamená, že tu mám napísať (slide: Production/environment/settings.tf): doména = premenná, doména vpcnetwork, premenná vpcnetwork a stvars – môžem dostať to isté?
To je presne to, čo robíme. Odkazujeme napríklad na zdrojový modul nastavenia.
V podstate ide o také tfvary. Tfvars je veľmi pohodlný v testovacom prostredí. Mám tfvary pre veľké prípady, pre malé. A jeden súbor som hodil do priečinka. A dostal som, čo som chcel. Keď rúbeme infraštruktúru, chceme, aby sa na všetko dalo pozerať a okamžite mu porozumieť. A tak sa ukazuje, že sa musíte pozrieť sem a potom sa pozrieť na tfvars.
Je možné mať všetko na jednom mieste?
Áno, tfvars je, keď máte jeden kód. A používa sa na niekoľkých rôznych miestach s rôznymi nuansami. Potom by ste hodili tfvars a dostali svoje nuansy. A my sme infraštruktúra ako kód vo svojej najčistejšej forme. Pozrel som sa a pochopil.
Ahoj! Stretli ste sa so situáciami, keď poskytovateľ cloudu zasahoval do toho, čo ste vytvorili Terraform? Povedzme, že upravíme metadáta. Existujú ssh kľúče. A Google tam neustále ukladá svoje metadáta a svoje kľúče. A Terraform vždy píše, že má zmeny. Po každom spustení, aj keď sa nič nezmení, vždy povie, že toto pole teraz aktualizuje.
S kľúčmi, ale áno, časť infraštruktúry je ovplyvnená touto vecou, teda Terraform nemôže nič zmeniť. Ani rukami nič nezmeníme. Zatiaľ s tým budeme žiť.
To znamená, že ste sa s niečím takým stretli, ale na nič ste neprišli, ako to robí a robí to sám?
Bohužiaľ áno.
Ahoj! Volám sa Starkov Stanislav. Mail. skupina ru. Ako riešite problém s generovaním tagu na..., ako ho odovzdávate dovnútra? Ak tomu dobre rozumiem, cez Používateľ - údaje na zadanie názvu hostiteľa nastavte Puppet na? A druhá časť otázky. Ako vyriešite tento problém v SG, t. j. keď generujete SG, stovky inštancií rovnakého typu, aký je pre ne správny názov?
Tie prípady, ktoré sú pre nás veľmi dôležité, krásne pomenujeme. Pre tie, ktoré nie sú potrebné, je poznámka, že ide o skupinu automatického škálovania. A teoreticky ho môžete pripevniť a získať nový.
Čo sa týka problému s tagom, taký problém tam nie je, ale je tu taká úloha. A značky používame veľmi, veľmi intenzívne, pretože infraštruktúra je veľká a drahá. A musíme sa pozrieť, kam idú peniaze, takže tagy nám umožňujú rozobrať, čo kam išlo. A teda hľadanie niečoho, čo znamená veľa peňazí, sa tu míňa.
Čoho sa ešte týkala otázka?
Keď SG vytvára stovky inštancií, treba ich nejako rozlišovať?
Nie, nie. Na každej inštancii je agent, ktorý hlási, že mám problém. Ak sa agent ohlási, tak agent o ňom vie a minimálne existuje jeho IP adresa. Už môžeš utiecť. Po druhé, používame Consul pre Discovery, kde Kubernetes nie je. A Consul tiež zobrazuje IP adresu inštancie.
To znamená, že sa zameriavate konkrétne na IP a nie na názov hostiteľa?
Nie je možné navigovať podľa názvu hostiteľa, t.j. je ich veľa. Sú tam identifikátory inštancií - AE atď. Niekde to nájdeš, môžeš to hodiť do vyhľadávania.
Ahoj! Uvedomil som si, že Terraform je dobrá vec, ušitá na mieru pre oblaky.
Nielen.
Presne táto otázka ma zaujíma. Ak sa rozhodnete prejsť, povedzme, do Bare Metalu hromadne so všetkými vašimi inštanciami? Nastanú nejaké problémy? Alebo budete musieť stále používať iné produkty, napríklad ten istý Ansible, ktorý tu bol spomenutý?
Ansible je trochu o niečom inom. To znamená, že Ansible už funguje po spustení inštancie. A Terraform funguje pred spustením inštancie. Prechod na Bare Metal – nie.
Teraz nie, ale obchod príde a povie: "Poď."
Prepnutie na iný cloud – áno, ale je tu trochu iný trik. Kód Terraform musíte napísať tak, aby ste mohli prejsť na iný cloud s menšou námahou.
Pôvodne bola zadaná úloha, že celá naša infraštruktúra je agnostická, t. j. každý cloud by mal byť vhodný, no v istom momente to biznis vzdal a povedal: „Dobre, najbližších N rokov nikam nepôjdeme, môžeme využívať služby z Amazonu"
Terraform vám umožňuje vytvárať front-endové úlohy, konfigurovať PagerDuty, dátové dokumenty atď. Má veľa chvostov. Dokáže prakticky ovládať celý svet.
Ďakujeme za správu! Terraform používam už 4 roky. Vo fáze plynulého prechodu na Terraform, na infraštruktúru, na deklaratívny popis, sme boli postavení pred situáciu, keď niekto niečo robil ručne, a vy ste sa snažili urobiť plán. A mám tam nejakú chybu. Ako riešite takéto problémy? Ako nájdete stratené zdroje, ktoré boli uvedené?
Hlavne rukami a očami, ak v správe uvidíme niečo zvláštne, tak rozoberieme, čo sa tam deje, alebo jednoducho zabijeme. Vo všeobecnosti sú požiadavky na stiahnutie bežnou vecou.
Ak sa vyskytne chyba, vrátite sa späť? Skúsili ste to urobiť?
Nie, toto je rozhodnutie človeka v momente, keď vidí problém.
Zdroj: hab.com