Zdi se, da razvijalci Terraform ponujajo precej priročne najboljše prakse za delo z infrastrukturo AWS. Samo obstaja odtenek. Sčasoma se število okolij poveča, v vsakem se pojavijo funkcije. Pojavi se skoraj kopijo sklada aplikacij v sosednji regiji. In kodo Terraform je treba skrbno kopirati in urediti v skladu z novimi zahtevami ali narediti snežinko.
Moje poročilo govori o vzorcih v Terraformu za boj proti kaosu in ročni rutini pri velikih in dolgih projektih.
Video:
Star sem 40 let, v IT sem že 20 let. V podjetju Ixtens delam že 12 let. Ukvarjamo se z razvojem, ki temelji na e-trgovini. Prakse DevOps izvajam že 5 let.
Moja zgodba bo govorila o izkušnji pri projektu v podjetju, katerega imena ne bom povedal, skriva se za pogodbo o nerazkritju podatkov.
Številke na diapozitivu so podane, da bi razumeli obseg projekta. In vse, kar bom povedal v nadaljevanju, je povezano z Amazonom.
Temu projektu sem se pridružil pred 4 leti. In prenova infrastrukture je bila v polnem teku, ker je projekt zrasel. In tisti vzorci, ki so bili uporabljeni, ne ustrezajo več. In ob vsej načrtovani rasti projekta je bilo treba pripraviti nekaj novega.
Hvala Matveyu, ki nam je včeraj povedal, kaj se je zgodilo v Dodo Pizzi. To se nam je zgodilo pred 4 leti.
Prišli so razvijalci in začeli ustvarjati infrastrukturno kodo.
Najbolj očiten razlog, zakaj je bilo to potrebno, je bil čas za trženje. Treba je bilo zagotoviti, da ekipa DevOps ni bila ozko grlo pri uvajanju. In med drugim sta bila na prvi stopnji uporabljena Terraform in Puppet.
Terraform je odprtokodni projekt podjetja HashiCorp. In za tiste, ki ne vedo, kaj sploh je, naslednjih nekaj diapozitivov.
Infrastruktura kot koda pomeni, da lahko opišemo svojo infrastrukturo in prosimo nekaj robotov, da zagotovijo, da dobimo vire, ki smo jih opisali.
Na primer, potrebujemo virtualni stroj. Opisali bomo, dodali nekaj zahtevanih parametrov.
Po tem bomo v konzoli konfigurirali dostop do Amazona. In prosite za načrt Terraform. Načrt Terraform bo rekel: "V redu, za vaš vir lahko naredimo te stvari." Dodan bo vsaj en vir. In sprememb ni pričakovati.
Ko vam bo vse ustrezalo, lahko zahtevate Terraform prijavo in Terraform vam bo ustvaril instanco, vi pa boste dobili virtualni stroj v vašem oblaku.
Nadalje se naš projekt razvija. Tam dodajamo nekaj sprememb. Prosimo za več primerkov, dodamo 53 vnosov.
In ponavljamo. Prosim, načrtujte. Vidimo, kakšne spremembe so načrtovane. Prijavite se. In tako raste naša infrastruktura.
Terraform uporablja tako stvar, kot so državne datoteke. To pomeni, da shrani vse spremembe, ki gredo v Amazon, v datoteko, kjer za vsak vir, ki ste ga opisali, obstajajo ustrezni viri, ki so bili ustvarjeni v Amazonu. Tako pri spreminjanju opisa vira Terraform točno ve, kaj je treba spremeniti v Amazonu.
Te državne datoteke so bile prvotno samo datoteke. In shranili smo jih v Git, kar je bilo zelo neprijetno. Nenehno je nekdo pozabil izvesti spremembe in bilo je veliko konfliktov.
Sedaj je mogoče uporabiti backend, tj. Terraform je označeno, v katero vedro, s katerim ključem naj se shrani datoteka stanja. In Terraform bo sam poskrbel, da bo pridobil to datoteko stanja, izvedel vse čarovnije in vrnil končni rezultat.
Naša infrastruktura raste. Tukaj je naša koda. In zdaj ne želimo samo ustvariti virtualnega stroja, ampak želimo imeti testno okolje.
Terraform vam omogoča, da naredite nekaj takega kot modul, tj. opišete isto stvar v neki mapi.
In na primer pri testiranju pokličemo ta modul in dobimo isto stvar, kot če bi izvajali aplikacijo Terraform v samem modulu. Tukaj je koda za testiranje.
Za produkcijo lahko tja pošljemo nekaj sprememb, saj pri testiranju ne potrebujemo velikih instanc, v produkciji bodo velike instance prišle prav.
In potem se bom vrnil k projektu. To je bila težka naloga, infrastruktura je bila načrtovana zelo velika. In vso kodo je bilo treba nekako postaviti tako, da bi bila primerna za vse: za tiste, ki izvajajo vzdrževanje te kode, in za tiste, ki spreminjajo. Načrtovano je bilo, da lahko vsak razvijalec popravi infrastrukturo, kot je potrebno za svoj del platforme.
To je imeniško drevo, ki ga HashiCorp priporoča, če imate velik projekt in je smiselno celotno infrastrukturo razdeliti na nekaj majhnih kosov in vsak del opisati v ločeni mapi.
Če imate obsežno knjižnico virov, lahko kličete približno isto stvar pri testiranju in proizvodnji.
V našem primeru to ni bilo povsem primerno, saj je bilo treba testni sklad za razvijalce oziroma za testiranje dobiti nekako enostavneje. Vendar nisem želel iti skozi mape in jih uporabiti v zahtevanem zaporedju ter skrbeti, da bi se baza podatkov dvignila, nato pa bi se povečal primerek, ki uporablja to bazo podatkov. Zato je bilo vse testiranje zagnano iz ene mape. Tam so bili poklicani isti moduli, vendar je bilo vse narejeno v enem zagonu.
Terraform poskrbi za vse odvisnosti. In vedno ustvari vire v tem zaporedju, tako da lahko dobite naslov IP, na primer iz sveže ustvarjene instance, in dobite ta naslov IP v vnosu route53.
Poleg tega je platforma zelo velika. In izvajanje testnega sklada, četudi za eno uro, četudi za 8 ur, je precej drag posel.
In ta posel smo avtomatizirali. In Jenkinsova naloga je omogočila zagon sklada. V njem je bilo treba zagnati zahtevo za vleko s spremembami, ki jih želi razvijalec preizkusiti, določiti vse potrebne možnosti, komponente in velikosti. Če želi testiranje zmogljivosti, lahko sprejme več primerov. Če mora samo preveriti, ali se odpre kakšen obrazec, bi lahko začel z minimalno plačo. In tudi navedite, ali je gruča potrebna ali ne, itd.
In potem je Jenkins potisnil lupinski skript, ki je rahlo spremenil kodo v mapi Terraform. Odstranjene nepotrebne datoteke, dodane potrebne datoteke. In potem, z enim nanosom Terraforma, se je kup povečal.
In potem so bili drugi koraki, v katere se ne želim spuščati.
Ker smo za testiranje potrebovali malo več možnosti kot v produkciji, smo morali narediti kopije modulov, da smo lahko v te kopije dodali tiste lastnosti, ki so potrebne samo pri testiranju.
In zgodilo se je, da se pri testiranju zdi, kot da želite preizkusiti tiste spremembe, ki bodo na koncu šle v proizvodnjo. Toda v resnici je bila testirana ena stvar, v proizvodnji pa uporabljena malo drugačna. In prišlo je do majhnega preloma v vzorcu, da je v proizvodnji vse spremembe uporabila operativna ekipa. In včasih se je izkazalo, da so tiste spremembe, ki naj bi šle iz testiranja v proizvodnjo, ostale v drugi različici.
Poleg tega je prišlo do takšne težave, da je bila dodana nova storitev, ki je bila nekoliko drugačna od nekaterih že obstoječih. In namesto da bi spremenili obstoječi modul, smo morali narediti njegovo kopijo in dodati potrebne spremembe.
Pravzaprav Terraform ni pravi jezik. To je izjava. Če moramo nekaj razglasiti, potem to razglasimo. In vse deluje.
Na neki točki, ko sem razpravljal o eni od mojih zahtev za vlečenje, je eden od mojih kolegov rekel, da ni treba proizvajati snežink. Spraševal sem se, kaj je mislil. Obstaja tako znanstveno dejstvo, da na svetu ni dveh enakih snežink, vse so nekoliko, a različne. In takoj ko sem to slišal, sem takoj začutil vso težo kode Terraform. Ker ko je bilo treba preiti iz različice v različico, je Terraform zahteval spremembo prekinitve verige, tj. koda ni bila več združljiva z naslednjo različico. Moral sem narediti zahtevo za vleko, ki je pokrila skoraj polovico datotek v infrastrukturi, da bi infrastrukturo prenesli v naslednjo različico Terraforma.
In ko se je pojavila taka snežinka, se je vsa koda Terraform, ki smo jo imeli, spremenila v velik, velik kup snega.
Za zunanjega razvijalca, ki je zunaj delovanja, mu to ni veliko pomembno, ker je naredil zahtevo za vleko, se je njegov vir začel. In to je to, to ni njegova skrb. In ekipa DevOps, ki skrbi, da je vse v redu, mora izvesti vse te spremembe. In stroški teh sprememb so se zelo, zelo povečali z vsako dodatno snežinko.
Obstaja zgodba o tem, kako študent na seminarju s kredo na tablo nariše dva popolna kroga. In učitelj je presenečen, kako mu je uspelo tako gladko risati brez šestila. Študent odgovori: "Zelo preprosto, dve leti v vojski sem obračal mlinček za meso."
In od štirih let, kolikor sem bil na tem projektu, sem približno dve leti delal Terraform. In seveda imam nekaj trikov, nekaj nasvetov, kako poenostaviti kodo Terraform, delati z njo kot s programskim jezikom in zmanjšati obremenitev za razvijalce, ki morajo to kodo posodabljati.
Prva stvar, s katero bi rad začel, so simbolne povezave. Terraform ima veliko ponavljajoče se kode. Na primer, klic ponudnika skoraj na vsaki točki, kjer ustvarimo delček infrastrukture, je enak. In logično je, da ga postavite v ločeno mapo. In povsod, kjer mora ponudnik narediti simbolne povezave do te datoteke.
Uporabite na primer prevzem vloge v proizvodnji, ki vam omogoča, da pridobite pravice dostopa do nekega zunanjega računa Amazon. Če spremenite eno datoteko, bodo vse preostale, ki so v drevesu virov, imele zahtevane pravice, tako da Terraform ve, do katerega Amazonovega segmenta mora dostopati.
Kje simbolne povezave ne delujejo? Kot sem rekel, ima Terraform državne datoteke. In so zelo, zelo kul. Dejstvo pa je, da Terraform inicializira zaledje že v prvem. In v teh parametrih ne more uporabiti nobenih spremenljivk, vedno jih je treba zapisati v besedilu.
In posledično, ko nekdo ustvari nov vir, kopira del kode iz drugih map. In lahko se zmoti s ključem ali z vedrom. Na primer, naredi peskovnik iz peskovnika, nato pa ga naredi v proizvodnji. In tako se lahko izkaže, da bo vedro v proizvodnji uporabljeno iz peskovnika. Seveda ga bodo hitro našli. To bo mogoče nekako popraviti, vendar je to izguba časa in do neke mere sredstev.
Kaj lahko naredimo naslednje? Preden delate s Terraformom, ga morate inicializirati. V času inicializacije Terraform prenese vse vtičnike. Na neki točki so iz monolita prešli v bolj mikrostoritveno arhitekturo. In vedno morate narediti Terraform init, da potegne vse module, vse vtičnike.
In lahko uporabite lupinski skript, ki lahko najprej pridobi vse spremenljivke. Skript lupine je neomejen. In drugič, način. Če vedno uporabljamo pot, ki je v repozitoriju, kot ključ do datoteke stanja, potem bo v skladu s tem napaka tukaj izključena.
Kje dobiti podatke? datoteka JSON. Terraform vam omogoča pisanje infrastrukture ne le v hcl (konfiguracijski jezik HashiCorp), ampak tudi v JSON.
JSON je enostavno brati iz lupinskega skripta. V skladu s tem lahko postavite konfiguracijsko datoteko z vedrom na neko mesto. In uporabite to vedro tako v kodi Terraform kot v lupinskem skriptu za inicializacijo.
Zakaj je pomembno imeti žlico Terraform? Ker obstajajo datoteke oddaljenega stanja. To pomeni, da ko dvignem vir, da Amazonu rečem: »Prosim dvignite primerek«, moram določiti veliko zahtevanih parametrov.
In ti identifikatorji so shranjeni v neki drugi mapi. In lahko ga vzamem in rečem: "Terraform, prosim teči do datoteke stanja tega vira in mi priskrbi te identifikatorje." In tako pride do neke vrste poenotenja med različnimi regijami oziroma okolji.
Oddaljene datoteke stanja ni vedno mogoče uporabiti. Na primer, ročno ste ustvarili VPC. In koda Terraform, ki ustvari VPC, ustvari tako drugačen VPC, da traja zelo dolgo in morate enega prilagoditi drugemu, zato lahko uporabite naslednji trik.
Se pravi, narediti modul, ki tako rekoč izdeluje VPC in vam daje identifikatorje, v resnici pa obstaja samo datoteka s trdo kodiranimi vrednostmi, ki se lahko uporabijo za ustvarjanje istega primerka.
Datoteke stanja ni vedno treba shraniti v oblak. Na primer, pri testiranju modulov lahko uporabite zaledno inicializacijo, ko bo datoteka v času testiranja shranjena samo na disku.
Zdaj pa malo o testiranju. Kaj lahko preizkusite v Terraformu? Verjetno je marsikaj mogoče, a govoril bom o teh 4 stvareh.
HashiCorp ve, kako oblikovati kodo Terraform. In Terraform fmt vam omogoča, da kodo, ki jo urejate, oblikujete v skladu s tem prepričanjem. V skladu s tem morajo testi nujno preveriti, ali se oblikovanje ujema s tem, kar je zapustil HashiCorp, tako da vam ni treba spreminjati lokacije oklepajev itd.
Naslednji je Terraform validate. Naredi malo več kot preverjanje sintakse - ala, ali so vsi oklepaji seznanjeni. Kaj je tukaj pomembno? Imamo zelo tanko infrastrukturo. Ima veliko različnih map. In v vsakem morate zagnati preverjanje Terraform.
V skladu s tem za pospešitev testiranja izvajamo več procesov vzporedno z uporabo parallel.
Parallel je zelo kul stvar, uporabite jo.
Toda vsakič, ko je Terraform inicializiran, gre do HashiCorp in vpraša: »Kateri so najnovejši vtičniki? In vtičnik, ki ga imam v predpomnilniku - je tisti ali ni tisti? In na vsakem koraku se je upočasnilo.
Če vam Terraform pove, kje so vtičniki, bo Terraform rekel: »V redu, to je verjetno najbolj sveža stvar, kar obstaja. Ne bom šel nikamor, takoj bom začel preverjati vašo kodo Terraform."
Da bi mapo napolnili s potrebnimi vtičniki, imamo zelo preprosto kodo Terraform, ki jo je treba le inicializirati. Tukaj morate seveda navesti vse ponudnike, ki kakorkoli sodelujejo v vaši kodi, sicer bo Terraform rekel: "Ne poznam nobenega ponudnika, ker ga ni v predpomnilniku."
Naslednji je načrt Terraform. Kot rečeno, razvoj je cikličen. Izdelujemo kodo s spremembami. In potem morate ugotoviti, kakšne spremembe so načrtovane za infrastrukturo.
In ko je infrastruktura zelo, zelo velika, lahko spremenite en modul, popravite neko testno okolje ali določeno regijo in zlomite nekaj sosednjega. Zato bi bilo treba za celotno infrastrukturo izdelati načrt Terraform in pokazati, kakšne spremembe so predvidene.
To lahko storite na pameten način. Na primer, napisali smo skript Python, ki razrešuje odvisnosti. In glede na to, kaj je bilo spremenjeno: modul Terraform ali samo določena komponenta, naredi načrte za vse odvisne mape.
Načrt teraforme je treba izdelati na zahtevo. Vsaj mi tako delamo.
Teste je seveda dobro narediti za vsako spremembo, za vsako objavo, vendar so načrti precej draga stvar. In v zahtevi za vlečenje rečemo: "Prosim, dajte mi načrte." Robot se zažene. In pošlje v komentarje ali priloži vse načrte, ki se pričakujejo od vaših sprememb.
Načrt je precej draga stvar. Potreben je čas, ker Terraform odide na Amazon in vpraša: »Ali ta primerek še obstaja? Ali ima ta samodejna lestvica popolnoma enake parametre?”. Da bi ga pospešili, lahko uporabite parameter, kot je refresh=false. To pomeni, da bo Terraform znižal stanje S3. In bo verjel, da se bo država natančno ujemala s tem, kar je v Amazonu.
Tak načrt Terraform je veliko hitrejši, vendar mora stanje ustrezati vaši infrastrukturi, torej nekje, včasih se mora začeti osveževanje Terraforma. Terraform refresh naredi točno to, da stanje ustreza temu, kar je v realni infrastrukturi.
In moram reči o varnosti. Tukaj bi se moralo začeti. Kjer izvajate Terraform in Terraform deluje z vašo infrastrukturo, obstaja ranljivost. To pomeni, da v bistvu izvajate kodo. In če zahteva za vlečenje vsebuje nekakšno zlonamerno kodo, se lahko izvede na infrastrukturi, ki ima preveč dostopa. Zato bodite previdni, kje zaženete načrt Terraform.
Naslednja stvar, o kateri bi rad govoril, je testiranje uporabniških podatkov.
Kaj so uporabniški podatki? V Amazonu, ko ustvarimo instanco, lahko pošljemo nekakšno pismo iz instance – meta podatke. Ko se primerek zažene, je na teh primerkih običajno vedno prisoten oblak init. Cloud init prebere to pismo in reče: "V redu, danes sem izenačevalnik obremenitve." In v skladu s temi predpisi izvaja nekaj dejanj.
Toda na žalost, ko naredimo načrt Terraform in uporabimo Terraform, so podatki o uporabnikih videti kot ta mešanica številk. To pomeni, da vam samo pošlje hash. In vse, kar lahko vidite v načrtu, je, ali bo prišlo do sprememb ali bo hash ostal enak.
In če na to ne boste pozorni, potem lahko kakšna pretepena besedilna datoteka odide v Amazon, v pravo infrastrukturo.
Druga možnost je, da med izvajanjem ne podate celotne infrastrukture, ampak samo predlogo. In v kodi recite: "Prosim, prikaži mi to predlogo." Posledično lahko dobite izpis, kako bodo vaši podatki videti na Amazonu.
Druga možnost je uporaba modula za ustvarjanje uporabniških podatkov. Ta modul boste uporabili. Prenesite datoteko na disk. Primerjaj ga z referenco. In tako, če se kakšen junij odloči popraviti malo uporabniških podatkov, bodo vaši testi rekli: "V redu, tu in tam so nekatere spremembe - to je normalno."
Naslednja stvar, o kateri bi rad govoril, je uporaba Automate Terraform.
Seveda je zelo strašljivo uporabljati Terraform v samodejnem načinu, ker kdo ve, kakšne spremembe so tam prišle in kako uničujoče so lahko za življenjsko infrastrukturo.
Za testno okolje je to vse v redu. To pomeni, da vsi razvijalci potrebujejo delo, ki ustvarja testno okolje. In izraz, kot je "vse je delovalo zame", ni smešen meme, ampak dokaz, da se je oseba zmešala, dvignila kup, zagnala nekaj testov na tem kupu. In se prepričal, da je tam vse v redu, in rekel: "V redu, koda, ki jo izdam, je bila testirana."
V produkcijskih, peskovnikih in drugih okoljih, ki so bolj kritična za poslovanje, je varno delno uporabiti nekatere vire, ker to ne povzroči smrti nikogar. To so: skupine za samodejno spreminjanje velikosti, varnostne skupine, vloge, route53 in tam je seznam lahko precej velik. Vendar bodite pozorni na dogajanje, preberite poročila o avtomatiziranih aplikacijah.
Kjer je uporaba nevarna ali strašljiva, na primer, če so to trajni viri iz baze podatkov, dobite poročila, da so v nekem delu infrastrukture neuporabljene spremembe. Inženir je že pod nadzorom, ko izvaja opravila za prijavo ali jih izvaja s svoje konzole.
Amazon ima nekaj takega, kot je zaščita prekinitve. In lahko v nekaterih primerih zaščiti pred spremembami, ki za vas niso potrebne. Torej je Terraform šel v Amazon in rekel: "Moram ubiti ta primerek, da naredim drugega". In Amazon pravi: »Oprosti, ne danes. Imamo zaščito pred prekinitvijo.«
Češnja na torti pa je optimizacija kode. Ko delamo s kodo Terraform, moramo modulu posredovati zelo veliko število parametrov. To so parametri, ki so potrebni za ustvarjanje neke vrste vira. In koda se spremeni v velike sezname parametrov, ki jih je treba posredovati od modula do modula, od modula do modula, še posebej, če so moduli ugnezdeni.
In zelo težko ga je brati. To je zelo težko pregledati. In zelo pogosto se izkaže, da se nekateri parametri pregledujejo in niso ravno tisti, ki so potrebni. Kasnejša popravila pa stanejo čas in denar.
Zato predlagam, da uporabite nekaj takega, kot je kompleksen parameter, ki vključuje določeno drevo vrednosti. To pomeni, da potrebujete nekakšno mapo, kjer imate vse vrednosti, ki bi jih radi imeli v nekem okolju.
In s klicem tega modula lahko dobite drevo, ki je generirano v enem skupnem modulu, torej v skupnem modulu, ki deluje enako za celotno infrastrukturo.
V tem modulu lahko naredite nekaj izračunov z uporabo tako sveže funkcije v Terraformu, kot so lokalci. In nato v enem izhodu izdajte nekakšen zapleten parameter, ki lahko vključuje zgoščene vrednosti, nize itd.
Na tem so vse najboljše ugotovitve, ki sem jih končal. In rad bi povedal zgodbo o Kolumbu. Ko je iskal denar za svojo ekspedicijo, da bi odkril Indijo (kot je takrat mislil), mu nihče ni verjel in verjel, da je to nemogoče. Potem je rekel: "Pazi, da jajce ne pade." Vsi bankirji, zelo bogati in verjetno pametni ljudje, so na nek način poskušali postaviti jajce, pa je ves čas padalo. Potem je Kolumb vzel jajce in ga malo stisnil. Lupina se je zmečkala in jajce je ostalo nepremično. Rekli so: "Oh, to je prelahko!" In Kolumb je odgovoril: »Da, preveč preprosto je. In ko bom odprl Indijo, bodo vsi uporabljali to trgovsko pot.«
In to, kar sem vam pravkar povedal, so verjetno precej preproste in trivialne stvari. In ko izveš zanje in jih začneš uporabljati, je vse v redu. Zato ga uporabite. In če so to za vas čisto normalne stvari, potem vsaj znate postaviti jajce, da ne pade.
Sumiramo:
- Poskusite se izogniti snežinkam. In manj kot je snežink, manj sredstev boste potrebovali za kakršne koli spremembe vaše celotne velike infrastrukture.
- Stalne spremembe. To pomeni, da ko pride do nekaterih sprememb v kodi, morate svojo infrastrukturo čim prej uskladiti s temi spremembami. Ne bi smelo priti do situacije, ko pride nekdo čez dva ali tri mesece pogledat Elasticsearch, naredi načrt Terraform in je veliko sprememb, ki jih ni pričakoval. In potrebno je veliko časa, da se vse spet uredi.
- Testi in avtomatizacija. Bolj kot je vaša koda pokrita s testi in čipi, več zaupanja imate, da delate vse prav. Samodejna dostava pa bo večkrat povečala vaše zaupanje.
- Koda za testno in produkcijsko okolje bi morala biti skoraj enaka. Praktično, ker je konec koncev produkcija malo drugačna in bo še vedno nekaj nians, ki bodo presegle testno okolje. Toda kljub temu je mogoče zagotoviti plus ali minus.
- In če imate veliko kode Terraform in potrebujete veliko časa, da to kodo posodabljate, potem ni nikoli prepozno, da jo predelate in spravite v dobro obliko.
- nespremenljivo infrastrukturo. AMI dostava po urniku.
- Struktura za route53, ko imate veliko vnosov in želite, da so v doslednem vrstnem redu.
- Boj proti omejitvam hitrosti API-ja. Takrat Amazon reče: "To je to, ne morem več sprejeti nobenih zahtev, počakajte." In polovica pisarne čaka, da lahko zažene svojo infrastrukturo.
- spot primere. Amazon ni poceni dogodek in mesta vam omogočajo, da prihranite precej. In tam lahko poveš celo poročilo o tem.
- Varnost in vloge IAM.
- Iščite izgubljene vire, ko imate primerke neznanega izvora v Amazoneju, jedo denar. Tudi če primerki stanejo 100–150 USD na mesec, je to več kot 1 USD na leto. Iskanje takšnih virov je donosen posel.
- In rezervirani primerki.
To je vse zame. Terraform je zelo kul, uporabite ga. Hvala vam!
vprašanja
Hvala za poročilo! Vaša datoteka stanja je v S3, toda kako rešite težavo, da lahko več ljudi vzame to datoteko stanja in jo poskuša razširiti?
Prvič, ne mudi se nam. Drugič, obstajajo zastavice, v katerih poročamo, da delamo na nekem delu kode. To pomeni, da kljub temu, da je infrastruktura zelo velika, to ne pomeni, da nekdo nenehno nekaj uporablja. In ko je bila aktivna faza, je bila to težava, hranili smo državne datoteke v Gitu. To je bilo pomembno, sicer bi nekdo naredil državno datoteko in smo jih morali ročno zbirati na kup, da bi lahko nadaljevali. Zdaj tega problema ni. Na splošno je Terraform rešil ta problem. In če se nekaj nenehno spreminja, potem lahko uporabite ključavnice, ki preprečijo, kar ste rekli.
Ali uporabljate odprto kodo ali podjetje?
Brez podjetja, to je vse, kar lahko prenesete brezplačno.
Moje ime je Stanislav. Želel sem narediti majhen dodatek. Govorili ste o funkciji Amazon, ki vam omogoča, da naredite primerek neuničljiv. To je tudi v samem Terraformu, v bloku Life Second, lahko predpišete prepoved spreminjanja ali prepoved uničenja.
Časovno je bil omejen. Dobra opazka.
Tudi jaz sem hotel vprašati dve stvari. Najprej ste govorili o testiranju. Ste uporabili kakšna orodja za testiranje? Slišal sem za vtičnik Test Kitchen. Morda je še kaj več. Prav tako bi rad vprašal o lokalnih vrednotah. Kako se bistveno razlikujejo od vhodnih spremenljivk? In zakaj ne morem nekaj parametrizirati samo prek lokalnih vrednosti? Poskušal sem ugotoviti to temo, vendar nekako sam nisem mogel ugotoviti.
Za to dvorano se lahko podrobneje pogovarjamo. Orodja za testiranje smo v celoti izdelali sami. Tam ni ničesar za testirati. Sploh so opcije, ko avtomatski testi nekje dvignejo infrastrukturo, preverijo, če je v redu, potem pa vse porušijo s poročilom, da je tvoja infrastruktura še v redu. Tega nimamo, ker se testni nizi izvajajo vsak dan. In to je dovolj. In če se bo kaj začelo kvariti, potem se bo začelo kvariti, ne da bi to kje drugje preverili.
Glede lokalnih vrednot nadaljujmo pogovor zunaj sobe.
Zdravo! Hvala za poročilo! Zelo informativno. Rekli ste, da imate veliko iste vrste kode za opis infrastrukture. Ali ste razmišljali o ustvarjanju te kode?
Odlično vprašanje, hvala! Bistvo je, da ko infrastrukturo uporabljamo kot kodo, predpostavljamo, da pogledamo kodo in razumemo, kakšna infrastruktura se skriva za to kodo. Če je koda ustvarjena, si moramo predstavljati, kakšna koda bo ustvarjena, da bi razumeli, kakšna infrastruktura bo tam. Ali pa ustvarimo kodo, jo potrdimo in dejansko dobimo isto stvar. Zato smo šli tako, kot smo zapisali, dobili smo. Poleg tega so se generatorji pojavili malo kasneje, ko smo začeli izdelovati. In bilo je prepozno za spremembo.
Ste že slišali za jsonnet?
Ne
Glej, to je res kul. Vidim poseben primer, kjer ga lahko uporabite in ustvarite podatkovno strukturo.
Generatorji so dobri, če jih imaš, kot v šali o brivskem stroju. Se pravi, prvič je obraz drugačen, potem pa imajo vsi enak obraz. Generatorji so zelo kul. A na žalost so naši obrazi malo drugačni. To je problem.
Samo poglej. Hvala vam!
Moje ime je Maxim, sem iz Sberbank. Malo ste rekli, da ste poskušali Terraform pripeljati do analognega programskega jezika. Ali ni lažje uporabljati Ansible?
To so zelo različne stvari. Ansible lahko ustvari vire, Puppet pa vire v Amazonu. Toda Terraform je naravnost nabrušen.
Imate samo Amazon?
Ne gre za to, da imamo samo Amazon. Imamo skoraj samo Amazon. Toda ključna lastnost je, da si Terraform zapomni. V Ansibleu, če rečete: "Pick me up 5 instances", se bo dvignilo, nato pa rečete: "In zdaj potrebujem 3". In Terraform bo rekel: "V redu, ubil bom 2", Ansible pa bo rekel: "V redu, tukaj so 3 zate." Skupaj 8.
Zdravo! Hvala za vaše poročilo! Bilo je zelo zanimivo slišati o Terraformu. Rad bi podal samo majhen komentar glede dejstva, da Terraform še vedno nima stabilne izdaje, zato bodite zelo previdni s Terraformom.
Lepa žlica za večerjo. Se pravi, če rabiš rešitev, potem včasih odložiš tisto, kar je nestabilno itd., ampak deluje in nam je pomagalo.
Vprašanje je. Uporabljate Remote backend, uporabljate S 3. Zakaj ne uporabljate uradnega backenda?
uradno?
Terraform Cloud.
Kdaj se je pojavil?
pred 4 meseci.
Če bi se pojavilo pred 4 leti, potem bi verjetno odgovoril na vaše vprašanje.
Obstaja že vgrajena funkcija in ključavnice, lahko pa shranite datoteko stanja. Poskusi. Ampak tudi jaz nisem testiral.
Smo na velikem vlaku, ki se premika z veliko hitrostjo. In ne moreš kar vzeti in vreči ven nekaj avtomobilov.
Govoril si o snežinkah, zakaj nisi uporabil veje? Zakaj se ni izšlo tako?
Imamo tak pristop, da je celotna infrastruktura v enem repozitoriju. Terraform, Puppet, vsi skripti, ki so nekako povezani s tem, vsi so v enem repozitoriju. Tako lahko zagotovimo, da se postopne spremembe testirajo ena za drugo. Če bi šlo za kup podružnic, bi bil tak projekt skoraj nemogoče vzdrževati. Šest mesecev mine in tako se razhajajo, da je to samo nekakšna kazen. To je tisto, od česar sem hotel pobegniti pred refactoringom.
se pravi ne deluje?
Sploh ne gre.
V podružnici sem izrezal diapozitiv mape. Se pravi, če naredite za vsak testni kup, na primer, ekipa A ima svojega očka, ekipa B ima svojega očka, potem tudi to ne deluje. Naredili smo enotno kodo testnega okolja, ki je bila dovolj prilagodljiva, da je ustrezala vsem. To pomeni, da smo postregli z eno kodo.
Zdravo! Moje ime je Yura! Hvala za poročilo! Vprašanje glede modulov. Pravite, da uporabljate module. Kako rešiti težavo, če so bile v enem modulu narejene spremembe, ki niso združljive s spremembo druge osebe? Nekako različico modulov ali poskušati pripeljati čudežni deček, ki bo izpolnil dve zahtevi?
To je problem velikega snežnega kupa. To je tisto, zaradi česar trpimo, ko lahko neka neškodljiva sprememba zlomi del infrastrukture. In to bo opazno šele čez nekaj časa.
Se pravi, še ni odločeno?
Izdelujete univerzalne module. Izogibajte se snežinkam. In vse se bo izšlo. Druga polovica poročila govori o tem, kako se temu izogniti.
Zdravo! Hvala za poročilo! Rad bi pojasnil. V zakulisju je bil velik kup, zaradi katerega sem prišel. Kako sta lutka in razdelitev vlog povezani?
uporabniški podatki.
Se pravi, ali samo izpljunete datoteko in jo nekako izvedete?
Uporabniški podatki so opomba, tj. ko naredimo klon slike, se tam dvigne Daemon in poskuša ugotoviti, kdo je, prebere opombo, da je load balancer.
Se pravi, ali gre za nekakšen ločen proces, ki se odda?
Nismo si ga izmislili. Uporabljamo ga.
Zdravo! Imam samo vprašanje o uporabniških podatkih. Rekli ste, da so tam težave, da lahko kdo kaj pošlje na napačno mesto. Ali obstaja kakšen način za shranjevanje uporabniških podatkov v isti Git, tako da je vedno jasno, na kaj se nanašajo uporabniški podatki?
Uporabniške podatke ustvarimo iz predloge. To pomeni, da se tam zateče določeno število spremenljivk. In Terraform ustvari končni rezultat. Zato ne morete samo pogledati predloge in reči, kaj se zgodi, ker so vse težave povezane z dejstvom, da razvijalec misli, da posreduje niz v tej spremenljivki, nato pa se uporabi niz. In on - bang in jaz - tako in tako, tako in tako, naslednja vrstica, in vse se je zlomilo. Če je to nov vir in ga človek dvigne, vidi, da nekaj ne deluje, potem se to hitro reši. In če je bila ta skupina samodejnega merila posodobljena, se na neki točki začnejo primerki v skupini samodejnega merila zamenjati. In ploskaj, nekaj ne deluje. Boli.
Izkazalo se je, da je edina rešitev testiranje?
Da, vidite težavo, tam dodate testne korake. To pomeni, da se lahko testira tudi izhod. Morda ni tako priročno, vendar lahko postavite tudi nekaj oznak - preverite, ali so uporabniški podatki tukaj prikovani.
Moje ime je Timur. Zelo kul je, da obstajajo poročila o tem, kako pravilno organizirati Terraform.
Sploh nisem začel.
Mislim, da na naslednji konferenci morda bo. Imam preprosto vprašanje. Zakaj trdo kodirate vrednost v ločenem modulu namesto uporabe tfvars, tj. ali je modul z vrednostmi boljši od tfvars?
To pomeni, da bi moral napisati tukaj (slide: Production/environment/settings.tf): domena = spremenljivka, domena vpcnetwork, vpcnetwork spremenljivka in stvari - dobite isto?
Mi počnemo točno to. Sklicujemo se na primer na izvorni modul nastavitve.
Pravzaprav je to tak tfvars. Tfvars je zelo priročen v testnem okolju. Imam tfvars za velike instance, za majhne. In eno datoteko sem vrgla v mapo. In dobil, kar sem hotel. Ko vidimo infrastrukturo, želimo imeti možnost videti in takoj razumeti vse. In tako se izkaže, da morate pogledati tukaj, nato pa pogledati v tfvars.
Izkazalo se je, da je bilo vse na enem mestu?
Da, tfvars je, ko imate eno kodo. In uporablja se na več različnih mestih z različnimi odtenki. Potem bi vrgli tfvars in dobili svoje nianse. In mi smo infrastruktura kot koda v najčistejši obliki. Pogledal sem in razumel.
Zdravo! Ali ste naleteli na situacije, ko ponudnik oblaka posega v to, kar ste storili s Terraform? Recimo, da uredimo metapodatke. Obstajajo ključi ssh. In Google nenehno pušča svoje metapodatke, svoje ključe. In Terraform vedno piše, da ima spremembe. Po vsaki vožnji, tudi če se nič ne spremeni, vedno reče, da bo zdaj posodobil to polje.
S ključi, ampak - ja, del infrastrukture je prizadet zaradi takega, torej Terraform ne more spremeniti ničesar. Tudi z rokami ne moremo ničesar spremeniti. Dokler živimo s tem.
Se pravi, naleteli ste na to, vendar se niste domislili ničesar, kako to počne in naredi sam?
Na žalost da.
Zdravo! Moje ime je Stanislav Starkov. Pošta. en Skupina. Kako rešiš problem z generiranjem oznake na ..., kako jo posreduješ notri? Kot sem razumel, prek uporabniških podatkov, da določite ime gostitelja, spodbudite lutko? In drugi del vprašanja. Kako rešite to težavo v SG, tj. ko ustvarite SG, sto primerkov istega tipa, kako jih pravilno poimenovati?
Tiste primere, ki so nam zelo pomembni, lepo poimenujemo. Tisti, ki niso potrebni, je postscript, da je to skupina samodejnega merila. In v teoriji ga je mogoče pribiti in dobiti novega.
Kar se tiče težave z oznako, te težave ni, obstaja pa taka naloga. Oznake uporabljamo zelo, zelo veliko, ker je infrastruktura velika in draga. Pogledati moramo, za kaj je denar porabljen, zato nam oznake omogočajo, da razvrstimo, kaj in kam je šlo. In zato je iskanje nečesa tukaj porabljenega veliko denarja.
O čem je bilo še vprašanje?
Ko SG ustvari sto primerkov, jih je treba nekako ločiti?
ne, ne. Vsak primer ima agenta, ki mi pove, da imam težavo. Če agent poroča, potem agent ve zanj in vsaj njegov IP naslov obstaja. Lahko že tečete. Drugič, uporabljamo Consul za Discovery, kjer ni Kubernetesa. In Consul prikazuje tudi naslov IP primerka.
To pomeni, da ciljate točno na IP in ne na ime gostitelja?
Nemogoče je krmariti po imenu gostitelja, kar pomeni, da jih je veliko. Obstajajo identifikatorji primerkov - AE itd. Lahko ga najdete nekje, lahko ga vržete v iskanje.
Zdravo! Spoznal sem, da je Terraform dobra stvar, po meri oblakov.
Ne le.
To je vprašanje, ki me zanima. Če se odločiš, da boš z vsemi svojimi instancami množično prešel recimo na Bare Metal? Bodo kakšne težave? Ali pa boste še vedno morali uporabljati druge izdelke, na primer isti Ansible, ki je bil omenjen tukaj?
Ansible govori o nečem drugem. To pomeni, da se Ansible že izvaja, ko se primerek zažene. In Terraform deluje, preden se primerek zažene. Prehod na Bare Metal ni.
Ne zdaj, ampak posel bo prišel in rekel: "Daj no."
Preklop na drug oblak – da, vendar je tukaj nekoliko drugačna funkcija. Kodo Terraform morate napisati tako, da lahko z manj krvi preklopite na drug oblak.
Sprva je bila naloga postavljena, da je naša celotna infrastruktura agnostična, torej vsak oblak bi moral biti primeren, vendar je podjetje na neki točki obupalo in reklo: »V redu, v naslednjih N letih ne bomo šli nikamor, lahko uporabljamo storitve iz Amazona"
Terraform vam omogoča ustvarjanje Front-End opravil, konfiguracijo PagerDuty, podatkovnih dokumentov itd. Ima veliko repov. Praktično lahko nadzoruje ves svet.
Hvala za poročilo! Tudi jaz vrtim Terraform že 4 leta. V fazi gladkega prehoda na Terraform, na infrastrukturo, na deklarativni opis, smo se soočili s situacijo, ko je nekdo nekaj delal ročno, vi pa ste poskušali narediti načrt. In tam sem dobil nekaj napak. Kako se spopadate s tovrstnimi težavami? Kako najdete izgubljene vire, ki so bili navedeni?
Večinoma z rokami in očmi, če v poročilu vidimo nekaj čudnega, potem analiziramo, kaj se tam dogaja, ali pa to preprosto ubijemo. Na splošno so zahteve po vleku pogosta stvar.
Če pride do napake, se vrnete nazaj? Ste že poskusili to narediti?
Ne, to je človekova odločitev v trenutku, ko vidi problem.
Vir: www.habr.com