Čini se da programeri Terraforma nude prilično zgodne najbolje prakse za rad sa AWS infrastrukturom. Postoji samo nijansa. Vremenom se povećava broj okruženja, svako sa svojim karakteristikama. Skoro kopija steka aplikacija pojavljuje se u susjednoj regiji. A Terraform kod treba pažljivo kopirati i urediti prema novim zahtjevima ili napraviti pahuljicu.
Moj govor o obrascima u Terraformu za borbu protiv haosa i ručne rutine na velikim i dugim projektima.
Video:
Imam 40 godina, u IT-u sam 20 godina. Za Ixtens radim 12 godina. Bavimo se razvojem zasnovanim na e-trgovini. I praktikujem DevOps prakse već 5 godina.
Moja priča će biti o mom iskustvu u projektu u kompaniji čije ime neću reći, skrivajući se iza ugovora o tajnosti.
Brojevi na slajdu su naznačeni kako bi se razumio obim projekta. A sve što ću dalje reći je vezano za Amazon.
Pridružio sam se ovom projektu prije 4 godine. A refaktoriranje infrastrukture bilo je u punom jeku jer je projekat porastao. A uzorci koji su korišteni više nisu bili prikladni. A s obzirom na sav planirani rast projekta, trebalo je smisliti nešto novo.
Hvala Matveyu, koji nam je jučer ispričao šta se dogodilo u Dodo Pizzi. Evo šta se desilo ovdje prije 4 godine.
Došli su programeri i počeli da prave infrastrukturni kod.
Najočigledniji razlozi zašto je to bilo potrebno je vrijeme za tržište. Bilo je neophodno osigurati da DevOps tim ne bude usko grlo tokom uvođenja. I između ostalog, Terraform i Puppet su korišteni na samom prvom nivou.
Terraform je projekat otvorenog koda kompanije HashiCorp. A za one koji ni ne znaju šta je ovo, narednih nekoliko slajdova.
Infrastruktura kao kod znači da možemo opisati našu infrastrukturu i zamoliti neke robote da se pobrinu da dobijemo resurse koje smo opisali.
Na primjer, potrebna nam je virtuelna mašina. Opisat ćemo i dodati nekoliko potrebnih parametara.
Nakon toga ćemo konfigurirati pristup Amazonu u konzoli. I tražićemo plan Terraforma. Plan Terraforma će reći: "U redu, možemo učiniti ove stvari za vaš resurs." I najmanje jedan resurs će biti dodan. I ne očekuju se nikakve promjene.
Kada budete zadovoljni sa svime, možete zamoliti Terraform da se prijavi i Terraform će kreirati instancu za vas, a vi ćete dobiti virtuelnu mašinu u svom oblaku.
Naš projekat se dalje razvija. Tu dodajemo neke izmjene. Tražimo više instanci, dodajemo 53 unosa.
I ponavljamo. Molimo planirajte. Vidimo kakve se promjene planiraju. Prijavljujemo se. I tako raste naša infrastruktura.
Terraform koristi nešto što se zove datoteke stanja. Odnosno, sve promjene koje idu na Amazon spremaju se u datoteku gdje za svaki resurs koji ste opisali postoje odgovarajući resursi koji su kreirani u Amazonu. Stoga, kada se promijeni opis resursa, Terraform tačno zna šta treba promijeniti u Amazonu.
Ovi državni fajlovi su prvobitno bili samo fajlovi. I pohranili smo ih u Git, što je bilo izuzetno nezgodno. Neko je uvek zaboravio da izvrši promene i nastalo je mnogo sukoba.
Sada je moguće koristiti backend, tj. Terraform je specificirano u kojoj kanti i po kojem ključu treba sačuvati datoteku stanja. A Terraform će se sam pobrinuti da dobije ovaj fajl stanja, učini svu magiju i vrati konačni rezultat.
Naša infrastruktura raste. Evo našeg koda. I sada ne želimo samo da kreiramo virtuelnu mašinu, želimo da imamo testno okruženje.
Terraform vam omogućava da kreirate nešto kao modul, odnosno opišete istu stvar u nekom folderu.
I, na primjer, u testiranju, pozovite ovaj modul i dobijete istu stvar kao da smo izvršili Terraform apply u samom modulu. Za testiranje će postojati ovaj kod.
Za proizvodnju možemo poslati neke promjene tamo, jer nam u testiranju nisu potrebne velike instance; u proizvodnji su velike instance samo korisne.
A onda ću se vratiti projektu. Bio je to težak zadatak, planirana infrastruktura je bila veoma velika. I bilo je potrebno nekako smjestiti sav kod tako da bude pogodan za sve: i za one koji održavaju ovaj kod i za one koji vrše promjene. I bilo je planirano da svaki programer može otići i popraviti infrastrukturu prema potrebi za njegov dio platforme.
Ovo je stablo direktorija koje preporučuje sam HashiCorp ako imate veliki projekat i ima smisla podijeliti cijelu infrastrukturu na nekoliko malih dijelova, i opisati svaki dio u zasebnom folderu.
Imajući opsežnu biblioteku resursa, možete pozvati približno istu stvar u testiranju iu proizvodnji.
U našem slučaju, to nije bilo sasvim prikladno, jer je test stack za programere ili za testiranje morao biti nabavljen nekako jednostavnije. Ali nisam želeo da prolazim kroz fascikle i primenjujem ih u traženom redosledu, i da brinem da će se baza podataka povećati, a zatim će se instanca koja koristi ovu bazu podataka povećati. Stoga su sva testiranja pokrenuta iz jednog foldera. Tamo su pozvani isti moduli, ali sve je urađeno u jednom ciklusu.
Terraform se brine za sve zavisnosti. I uvijek kreira resurse u nizu tako da možete dobiti IP adresu, na primjer, iz novokreirane instance, i dobiti ovu IP adresu u zapisu route53.
Osim toga, platforma je vrlo velika. A pokretanje testne grupe, čak i ako na sat, čak i na 8 sati, prilično je skup poduhvat.
I automatizovali smo ovu stvar. A Dženkinsov posao nam je omogućio da pokrenemo stek. U njemu je bilo potrebno pokrenuti pull request s promjenama koje programer želi testirati, specificirati sve potrebne opcije, komponente i dimenzije. Ako želi testiranje performansi, onda može uzeti više instanci. Ako samo treba da provjeri da li se otvara neki obrazac, onda bi mogao početi s minimalnom platom. I također naznačite da li je klaster potreban ili ne, itd.
A onda je Dženkins ubacio shell skriptu, koja je malo izmenila kod u fascikli Terraform. Uklonio sam nepotrebne fajlove i dodao potrebne fajlove. A onda je s jednom primjenom Terraforma stek podignut.
A onda su bili drugi koraci u koje ne želim da ulazim.
Zbog činjenice da nam je za testiranje bilo potrebno nešto više opcija nego u proizvodnji, morali smo napraviti kopije modula kako bismo u ove kopije mogli dodati one karakteristike koje su bile potrebne samo za testiranje.
I dogodilo se da u testiranju na neki način želim testirati one promjene koje će na kraju ući u proizvodnju. Ali u stvari, jedna stvar je testirana, a nešto drugačija je korištena u proizvodnji. I došlo je do malog prekida u obrascu da je u proizvodnji sve promjene primijenio operativni tim. A ponekad se pokazalo da su one promjene koje su trebale ići od testiranja do proizvodnje ostale u drugoj verziji.
Osim toga, došlo je do takvog problema da je dodana nova usluga, koja se malo razlikovala od nekih već postojećih. I umjesto da modificiramo postojeći modul, morali smo napraviti njegovu kopiju i dodati potrebne izmjene.
U suštini, Terraform nije pravi jezik. Ovo je deklaracija. Ako nešto trebamo proglasiti, onda to izjavljujemo. I sve radi.
U nekom trenutku, kada se raspravljalo o jednom od mojih zahtjeva za povlačenjem, jedan od mojih kolega je rekao da nema potrebe za stvaranjem pahuljica. Pitao sam se na šta misli. Postoji naučna činjenica da na svijetu ne postoje dvije identične pahulje, sve su malo različite. I čim sam ovo čuo, odmah sam osjetio svu težinu Terraform koda. Jer kada je bilo potrebno preći s verzije na verziju, Terraform je zahtijevao promjene lanca prekida, tj. kod više nije bio kompatibilan sa sljedećom verzijom. I morali smo da napravimo pull request, koji je pokrivao skoro polovinu fajlova u infrastrukturi, kako bismo infrastrukturu doveli u sledeću verziju Terraforma.
A nakon što se pojavila takva pahulja, sav kod Terraforma koji smo napravili pretvorio se u veliku, veliku hrpu snijega.
Za eksternog programera koji je izvan operacije, to mu nije mnogo važno, jer je napravio zahtjev za povlačenjem, njegov resurs je pokrenut. I to je sve, to više nije njegova briga. A DevOps tim, koji se brine da je sve u redu, mora izvršiti sve ove promjene. A trošak ovih promjena se povećavao jako, jako sa svakom dodatnom pahuljom.
Postoji priča o tome kako student na seminaru kredom na tabli crta dva savršena kruga. I učitelj se čudi kako je uspio tako glatko crtati bez kompasa. Učenik odgovara: „Vrlo jednostavno, proveo sam dvije godine u vojsci vrteći mašinu za mljevenje mesa.”
I od četiri godine koliko sam bio uključen u ovaj projekat, Terraform sam radio oko dvije godine. I, naravno, imam neke trikove, neke savjete kako pojednostaviti Terraform kod, raditi s njim kao programskim jezikom i smanjiti opterećenje za programere koji moraju održavati ovaj kod ažurnim.
Prva stvar s kojom bih želio da počnem su Symlinks. Terraform ima mnogo koda koji se ponavlja. Na primjer, poziv provajderu na gotovo svakoj tački gdje kreiramo dio infrastrukture je isti. I logično je staviti ga u poseban folder. I gdje god se od provajdera traži da napravi Symlinkove na ovu datoteku.
Na primjer, u produkciji koristite preuzetu ulogu, koja vam omogućava da dobijete prava pristupa nekom vanjskom Amazon računu. A nakon promjene jedne datoteke, svi preostali u stablu resursa imat će potrebna prava tako da Terraform zna kojem Amazon segmentu treba pristupiti.
Gdje Symlinks ne uspijevaju? Kao što sam rekao, Terraform ima državne dosijee. I oni su veoma, veoma cool. Ali stvar je u tome što Terraform inicijalizira pozadinu na prvom mjestu. I on ne može koristiti nikakve varijable u ovim parametrima; one uvijek moraju biti zapisane u tekstu.
I kao rezultat, kada neko napravi novi resurs, on kopira dio koda iz drugih foldera. I može pogriješiti s ključem ili s kantom. Na primjer, on pravi sandbox stvar od sandbox-a, a zatim je pravi u proizvodnji. I tako se može ispostaviti da će se kanta u proizvodnji koristiti iz sandbox-a. Naravno, brzo će ga pronaći. To će se nekako moći popraviti, ali je to gubljenje vremena i, donekle, resursa.
Šta možemo dalje? Prije rada sa Terraformom, morate ga inicijalizirati. Prilikom inicijalizacije, Terraform preuzima sve dodatke. U nekom trenutku su se odvojili od monolitne do više mikroservisne arhitekture. I uvijek morate raditi Terraform init tako da povuče sve module, sve dodatke.
I možete koristiti shell skriptu, koja, prvo, može dobiti sve varijable. Shell skripta nije ograničena ni na koji način. I, drugo, staze. Ako uvijek koristimo stazu koja se nalazi u spremištu kao ključ do datoteke stanja, onda će, u skladu s tim, greška ovdje biti eliminirana.
Gdje mogu dobiti podatke? JSON fajl. Terraform vam omogućava da pišete infrastrukturu ne samo u hcl-u (HashiCorp Configuration Language), već iu JSON-u.
JSON se lako čita iz shell skripte. U skladu s tim, možete staviti konfiguracijsku datoteku s bucketom na neko mjesto. I koristite ovu kantu iu Terraform kodu iu shell skripti za inicijalizaciju.
Zašto je važno imati kantu za Terraform? Zato što postoji takva stvar kao što su fajlovi udaljenih stanja. Odnosno, kada podignem neki resurs, da bih rekao Amazonu: „Molim vas, podignite instancu“, moram navesti puno potrebnih parametara.
I ovi identifikatori su pohranjeni u nekom drugom folderu. I mogu da odem i kažem: „Terraform, molim te, idi do datoteke stanja tog resursa i daj mi ove identifikatore.“ I tako se javlja određeno ujedinjenje između različitih regija ili sredina.
Nije uvijek moguće koristiti datoteku udaljenog stanja. Na primjer, kreirali ste VPC ručno. A Terraform kod koji kreira VPC stvara toliko različite VPC-ove da će to trajati jako dugo i moraćete da prilagodite jedan drugom, tako da možete koristiti sledeći trik.
Odnosno, napravite modul koji izgleda kao da pravi VPC i, takoreći, daje vam identifikatore, ali u stvari postoji jednostavno datoteka sa tvrdo kodiranim vrijednostima koja se može koristiti za kreiranje iste instance.
Nije uvijek potrebno sačuvati datoteku stanja u oblaku. Na primjer, kada testirate module, možete koristiti backend inicijalizaciju, gdje će datoteka jednostavno biti sačuvana na disku u vrijeme testiranja.
Sada malo o testiranju. Šta možete testirati u Terraformu? Vjerovatno je mnogo toga moguće, ali ja ću govoriti o ove 4 stvari.
HashiCorp razumije kako Terraform kod treba biti formatiran. A Terraform fmt vam omogućava da formatirate kod koji uređujete u skladu sa ovim uvjerenjem. Shodno tome, testovi moraju nužno provjeriti da li formatiranje odgovara onome što je HashiCorp ostavio, tako da nema potrebe za promjenom lokacije zagrada itd.
Sljedeći je Terraform validate. Ne radi ništa više od provjere sintakse - ala, da li su sve zagrade uparene. Šta je tu važno? Naša infrastruktura je veoma obimna. U njemu ima mnogo različitih tata. I u svakom od njih trebate pokrenuti Terraform validate.
Shodno tome, da bismo ubrzali testiranje, paralelno pokrećemo više procesa koristeći paralelno.
Paralela je jako dobra stvar, iskoristite je.
Ali svaki put kada se Terraform inicijalizira, ide u HashiCorp i pita: „Koje su najnovije verzije dodataka? I dodatak koji imam u kešu – da li je pravi ili pogrešan?” I to se usporavalo na svakom koraku.
Ako kažete Terraformu gdje se nalaze dodaci, onda će Terraform reći: „Ok, ovo je vjerovatno najnovija stvar koja postoji. Neću nigdje ići, odmah ću početi potvrđivati vaš Terraform kod.”
Da bismo fasciklu popunili potrebnim dodacima, imamo vrlo jednostavan Terraform kod koji samo treba inicijalizirati. Ovdje, naravno, trebate navesti sve provajdere koji na neki način sudjeluju u vašem kodu, inače će Terraform reći: “Ne znam određenog provajdera jer nije u kešu.”
Sljedeći je plan Terraform. Kao što sam rekao, razvoj je cikličan. Vršimo izmjene koda. A onda morate saznati koje su promjene planirane za infrastrukturu.
A kada je infrastruktura jako, jako velika, možete promijeniti jedan modul, popraviti neko testno okruženje ili neku specifičnu regiju i razbiti neki susjedni. Dakle, Terraform plan treba napraviti za cjelokupnu infrastrukturu i pokazati koje se promjene planiraju.
Možete to učiniti pametno. Na primjer, napisali smo Python skriptu koja rješava ovisnosti. I u zavisnosti od toga šta je promenjeno: Terraform modul ili samo određena komponenta, pravi planove za sve zavisne fascikle.
Planovi terraforma se moraju izraditi na zahtjev. Barem to radimo.
Naravno, dobro je raditi testove za svaku promjenu, za svaki urezivanje, ali planovi su prilično skupa stvar. I u zahtjevu za povlačenje kažemo: „Molim vas, dajte mi planove.“ Robot se pokreće. I šalje u komentarima ili prilaže sve planove koji se očekuju od vaših promjena.
Plan je prilično skupa stvar. Potrebno je vrijeme jer Terraform odlazi na Amazon i pita: „Da li ova instanca još uvijek postoji? Ima li ova automatska skala potpuno iste parametre?” A da biste to ubrzali, možete koristiti parametar kao što je refresh=false. To znači da će Terraform preuzeti stanje sa S3. I vjerovat će da će država u potpunosti odgovarati onome što je u Amazonu.
Takav Terraform plan ide mnogo brže, ali stanje mora odgovarati vašoj infrastrukturi, odnosno negdje, nekad mora početi osvježavanje Terraforma. Osvježavanje Terraforma radi upravo to: stanje odgovara onome što je u stvarnoj infrastrukturi.
I moramo razgovarati o sigurnosti. Ovdje smo morali početi. Tamo gdje pokrećete Terraform i Terraform radi na vašoj infrastrukturi postoji ranjivost. To jest, vi u suštini izvršavate kod. A ako zahtjev za povlačenjem sadrži neku vrstu zlonamjernog koda, onda se može izvršiti na infrastrukturi koja ima previše pristupa. Zato pazite gdje pokrećete Terraform plan.
Sljedeća stvar o kojoj bih želio govoriti je testiranje korisničkih podataka.
Šta su korisnički podaci? U Amazonu, kada kreiramo instancu, možemo poslati određeno pismo sa instancom – meta podacima. Kada se instanca pokrene, obično je cloud init uvijek prisutan na ovim instancama. Cloud init čita ovo pismo i kaže: „Ok, danas sam ja balansir za opterećenje.“ I u skladu sa ovim zavetima on vrši neke radnje.
Ali, nažalost, kada napravimo Terraform plan i Terraform se primjenjuje, korisnički podaci izgledaju kao ova vrsta kaše brojeva. Odnosno, on vam jednostavno šalje heš. A sve što možete pogledati u planu je da li će biti promjena ili će heš ostati isti.
A ako ne obratite pažnju na ovo, onda neka pokvarena tekstualna datoteka može završiti na Amazonu, na stvarnoj infrastrukturi.
Alternativno, prilikom izvršavanja možete navesti ne cijelu infrastrukturu, već samo predložak. I u kodu recite: "Prikaži ovaj predložak na mom ekranu." I kao rezultat, možete dobiti ispis kako će vaši podaci izgledati na Amazonu.
Druga opcija je korištenje modula za generiranje korisničkih podataka. Primijenit ćete ovaj modul. Dobijate fajl na disku. Uporedite ga sa referentnim. I stoga, ako neki tip odluči malo ispraviti korisničke podatke, onda će vaši testovi reći: “U redu, ima nekih promjena tu i tamo – to je normalno.”
Sljedeća stvar o kojoj bih želio da pričam je automatska primjena Terraforma.
Naravno, prilično je zastrašujuće raditi Terraform aplicirati u automatskom režimu, jer ko zna kakve promjene su se tu dogodile i koliko one mogu biti destruktivne za živu infrastrukturu.
Za testno okruženje, ovo je sve normalno. To jest, posao koji kreira testno okruženje je ono što je potrebno svim programerima. A izraz kao što je „sve je funkcionisalo kod mene“ nije smešan mem, već dokaz da se osoba zbunila, podigla stek i izvršila neke testove na ovom steku. I on se uvjerio da je tamo sve u redu i rekao: "U redu, kod koji puštam je testiran."
U proizvodnji, sandboxu i drugim okruženjima koja su kritičnija za poslovanje, možete djelomično koristiti neke resurse sasvim sigurno jer to ne dovodi do smrti ikoga. To su: autoscale grupe, sigurnosne grupe, uloge, route53, a lista može biti prilično velika. Ali držite na oku što se događa, pročitajte automatizirane izvještaje aplikacija.
Gdje je opasno ili zastrašujuće primijeniti, na primjer, ako su to neki trajni resursi iz baze podataka, onda primajte izvještaje da postoje neprimijenjene promjene u nekom dijelu infrastrukture. A inženjer, pod nadzorom, započinje poslove za prijavu ili to radi sa svoje konzole.
Amazon ima takvu stvar kao što je Terminate zaštita. I može zaštititi u nekim slučajevima od promjena koje vam nisu potrebne. Odnosno, Terraform je otišao u Amazon i rekao: “Moram ubiti ovu instancu da napravim drugu.” A Amazon kaže: „Izvinite, ne danas. Imamo zaštitu od prekida."
A šlag na tortu je optimizacija koda. Kada radimo sa Terraform kodom, modulu moramo proslediti veoma veliki broj parametara. Ovo su parametri koji su neophodni za stvaranje neke vrste resursa. I kod se pretvara u velike liste parametara koje je potrebno prenijeti od modula do modula, od modula do modula, posebno ako su moduli ugniježđeni.
I veoma je teško čitati. Vrlo je teško ovo pregledati. I vrlo često se ispostavi da su neki parametri podvrgnuti reviziji i nisu baš ono što je potrebno. A ovo košta vremena i novca da se kasnije popravi.
Stoga predlažem da koristite tako nešto kao složeni parametar koji uključuje određeno stablo vrijednosti. Odnosno, potrebna vam je neka vrsta fascikle u kojoj imate sve vrednosti koje biste želeli da imate u nekom okruženju.
A pozivanjem ovog modula možete dobiti stablo koje se generira u jednom zajedničkom modulu, odnosno u zajedničkom modulu koji radi isto za cijelu infrastrukturu.
U ovom modulu možete napraviti neke kalkulacije koristeći tako nedavnu funkciju u Terraformu kao što su lokalni stanovnici. I onda, sa jednim izlazom, dajte neki složeni parametar, koji može uključivati hešove niza, itd.
Ovdje su završili svi najbolji nalazi koje sam do sada. Hteo bih da ispričam priču o Kolumbu. Kada je tražio novac za svoju ekspediciju da otkrije Indiju (kako je tada mislio), niko mu nije vjerovao i mislili su da je to nemoguće. Zatim je rekao: "Pazi da jaje ne padne." Svi bankari, vrlo bogati i vjerovatno pametni ljudi, pokušavali su nekako staviti jaje, a ono je padalo. Tada je Kolumbo uzeo jaje i malo ga pritisnuo. Ljuska se zgužvala, a jaje je ostalo nepomično. Rekli su: "Oh, to je prelako!" A Kolumbo je odgovorio: „Da, previše je jednostavno. I kada otvorim Indiju, svi će koristiti ovaj trgovački put."
A ovo što sam vam upravo rekao su vjerovatno prilično jednostavne i trivijalne stvari. A kada naučite o njima i počnete ih koristiti, to je po redu stvari. Zato iskoristite prednost. A ako su vam to sasvim normalne stvari, onda barem znate kako staviti jaje da ne padne.
Hajde da sumiramo:
- Pokušajte izbjeći pahulje. I što je manje snježnih pahulja, to će vam biti potrebno manje resursa da napravite bilo kakve promjene u vašoj velikoj infrastrukturi.
- Konstantne promjene. To jest, kada dođe do nekih promjena u kodu, potrebno je da svoju infrastrukturu uskladite s tim promjenama što je prije moguće. Ne bi trebalo da dođe do situacije da neko dođe da pogleda Elasticsearch dva ili tri meseca kasnije, napravi Terraform plan, a postoji gomila promena koje nije očekivao. I potrebno je dosta vremena da se sve vrati u red.
- Testovi i automatizacija. Što je vaš kod više pokriven testovima i funkcijama, to ćete imati više samopouzdanja da sve radite ispravno. A automatska dostava će povećati vaše samopouzdanje višestruko.
- Kod za testno i proizvodno okruženje trebao bi biti gotovo isti. Praktično, jer je proizvodnja još uvijek malo drugačija i još će postojati neke nijanse koje će ići dalje od testnog okruženja. Ali ipak, plus ili minus, to se može osigurati.
- A ako imate puno Terraform koda i potrebno vam je puno vremena da ovaj kod bude ažuriran, onda nikada nije kasno da ga refaktorirate i dovedete u dobro stanje.
- Nepromjenjiva infrastruktura. AMI isporuka po rasporedu.
- Struktura za route53 kada imate puno unosa i želite da budu u dosljednom redoslijedu.
- Borba protiv ograničenja brzine API-ja. Tada Amazon kaže: "To je to, ne mogu više prihvatiti zahtjeve, sačekajte." A polovina ureda čeka da pokrene svoju infrastrukturu.
- Spot instance. Amazon nije jeftin događaj i spotovi vam omogućavaju da uštedite dosta. I tamo možete ispričati cijeli izvještaj o tome.
- Sigurnosne i IAM uloge.
- U potrazi za izgubljenim resursima, kada imate slučajeve nepoznatog porijekla u Amazoneu, oni jedu novac. Čak i ako instance koštaju 100-150 dolara mjesečno, to je više od 1 dolara godišnje. Pronalaženje takvih resursa je profitabilan posao.
- I rezervisane instance.
To je sve za mene. Terraform je jako kul, ti ga koristiš. Hvala ti!
Vaša pitanja
Hvala na izvještaju! Vaša datoteka stanja je u S3, ali kako riješiti problem da nekoliko ljudi može uzeti ovu datoteku stanja i pokušati proširiti?
Prije svega, nikamo nam se ne žuri. Drugo, tu su zastavice u kojima javljamo da radimo na nekom dijelu koda. Odnosno, uprkos činjenici da je infrastruktura veoma velika, to ne znači da neko stalno nešto koristi. A kada je postojala aktivna faza, to je bio problem; pohranili smo datoteke stanja u Git. Ovo je bilo važno, inače bi neko napravio državni fajl, a mi smo morali ručno da ih sastavljamo da bi se sve nastavilo. Sada nema takvog problema. Generalno, Terraform je riješio ovaj problem. A ako se nešto stalno mijenja, onda možete koristiti brave, koje sprječavaju ono što ste rekli.
Koristite li open source ili enterprise?
Bez preduzeća, tj. sve što možete besplatno preuzeti i preuzeti.
Moje ime je Stanislav. Hteo sam da napravim mali dodatak. Govorili ste o Amazonovoj funkciji koja vam omogućava da instancu učinite neubijenom. Ovo je također u samom Terraformu; u bloku Life Second možete odrediti zabranu promjena ili zabranu uništavanja.
Vrijeme je bilo ograničeno. Dobra tačka.
Hteo sam da pitam i dve stvari. Prvo ste govorili o testiranju. Jeste li koristili neki alat za testiranje? Čuo sam za dodatak Test Kitchen. Možda postoji nešto više. Takođe bih želeo da pitam o lokalnim vrednostima. Kako se one fundamentalno razlikuju od ulaznih varijabli? A zašto ne mogu nešto parametrizovati samo preko lokalnih vrijednosti? Pokušao sam da shvatim ovu temu, ali nekako nisam mogao sam da je shvatim.
Možemo detaljnije razgovarati van ove prostorije. Naši alati za testiranje su potpuno sami napravljeni. Nema tu šta da se testira. Općenito, postoje opcije kada automatizirani testovi pokupe negdje infrastrukturu, provjere da li je u redu, a zatim unište sve uz izvještaj da je vaša infrastruktura još uvijek u dobrom stanju. Ovo nemamo jer se testni nizovi pokreću svaki dan. I to je dovoljno. A ako nešto počne da se lomi, počeće da se lomi a da to ne proverimo negde drugde.
Što se tiče Lokalnih vrijednosti, nastavimo razgovor izvan sobe.
Zdravo! Hvala na izvještaju! Vrlo informativno. Rekli ste da imate mnogo istog tipa koda za opisivanje infrastrukture. Jeste li razmišljali o generiranju ovog koda?
Odlično pitanje, hvala! Poenta je da kada koristimo infrastrukturu kao kod, pretpostavljamo da gledamo u kod i razumijemo koja se infrastruktura krije iza tog koda. Ako je kod generisan, onda treba da zamislimo koji će kod biti generisan da bismo razumeli kakva će infrastruktura biti tamo. Ili generiramo kod, urezujemo ga i u suštini se dešava ista stvar. Išli smo putem koji smo napisali, i dobili smo ga. Plus generatori su se pojavili nešto kasnije kada smo počeli da ih pravimo. A već je bilo prekasno za promjenu.
Jeste li čuli nešto o jsonnetu?
Ne.
Vidite, ovo je jako kul stvar. Vidim specifičan slučaj u kojem ga možete primijeniti i generirati strukturu podataka.
Generatori su dobri kada ih imate, kao u vicu o mašini za brijanje. Odnosno, prvi put je lice drugačije, ali onda svi imaju isto lice. Generatori rade veoma dobro. Ali, nažalost, naša lica su malo drugačija. Ovo je problem.
Samo pogledaj. Hvala ti!
Moje ime je Maxim, ja sam iz Sberbanke. Malo ste pričali o tome kako pokušavate da Terraform dovedete do ekvivalenta programskog jezika. Nije li lakše koristiti Ansible?
To su veoma različite stvari. Možete kreirati resurse u Ansibleu, a Puppet može kreirati resurse u Amazonu. Ali Terraform je direktno izoštren.
Da li imate samo Amazon?
Nije da imamo samo Amazon. Imamo skoro samo Amazon. Ali ključna karakteristika je da Terraform pamti. U Ansibleu, ako kažete: „Daj mi 5 instanci“, onda će se podići, a onda kažete: „A sada mi trebaju 3.“ I Terraform će reći: "U redu, ubiću 2", a Ansible će reći: "U redu, evo 3 za tebe." Ukupno 8.
Zdravo! Hvala na izvještaju! Bilo je vrlo zanimljivo čuti o Terraformu. Želio bih odmah dati mali komentar o činjenici da Terraform još uvijek nema stabilno izdanje, pa se prema Terraformu odnosite s velikim oprezom.
Dobra kašika za večeru. Odnosno, ako vam treba rješenje, onda ponekad odložite ono što je nestabilno itd., ali funkcionira i pomoglo nam je.
Pitanje je ovo. Koristite Remote backend, koristite S 3. Zašto ne koristite službeni backend?
Zvanični?
Terraform Cloud.
Kada se pojavio?
Prije otprilike 4 mjeseca.
Da se pojavio prije 4 godine, vjerovatno bih odgovorio na vaše pitanje.
Već postoji ugrađena funkcija i brave, a možete pohraniti datoteku stanja. Pokušati. Ali nisam ni to testirao.
Putujemo velikim vozom koji se kreće velikom brzinom. I ne možete samo uzeti nekoliko automobila i baciti ih.
Pričali ste o pahuljama, zašto niste koristili granu? Zašto nije ispalo tako?
Naš pristup je da je cjelokupna infrastruktura u jednom spremištu. Terraform, Puppet, sve skripte koje su na neki način povezane sa ovim, sve su u jednom spremištu. Na ovaj način možemo osigurati da se inkrementalne promjene testiraju jedna za drugom. Da je u pitanju gomila grana, onda bi takav projekat bilo gotovo nemoguće održati. Prođe šest meseci, a oni se toliko raziđu da je to samo neka kazna. To je ono od čega sam želio pobjeći prije refaktoriranja.
Znači ne radi?
Ovo uopšte ne radi.
U grani sam izrezao fasciklu slajd. Odnosno, ako to učinite za svaki testni stog, na primjer, tim A ima svoju mapu, tim B ima svoju mapu, onda to također ne radi. Napravili smo objedinjeni kod testnog okruženja koji je bio dovoljno fleksibilan da odgovara svima. Odnosno, servirali smo jedan kod.
Zdravo! Moje ime je Yura! Hvala na izvještaju! Pitanje o modulima. Kažete da koristite module. Kako riješiti problem ako su u jednom modulu napravljene promjene koje nisu kompatibilne s promjenom druge osobe? Da li na neki način mijenjate verzije modula ili pokušavate dovesti wunderwaffle da ispuni dva zahtjeva?
Ovo je veliki problem sa snježnim gomilama. To je ono od čega patimo kada neka bezazlena promjena može slomiti dio infrastrukture. A to će se primijetiti tek nakon nekog vremena.
Odnosno, to još nije riješeno?
Pravite univerzalne module. Izbjegavajte pahulje. I sve će uspjeti. Druga polovina izvještaja govori o tome kako to izbjeći.
Zdravo! Hvala na izvještaju! Želeo bih da razjasnim. Iza kulisa je bila velika gomila po koju sam došao. Kako su integrisane lutke i distribucija uloga?
Korisnički podaci.
Odnosno, samo ispljuneš fajl i nekako ga izvršiš?
Korisnički podaci su bilješka, tj. kada napravimo klon slike, Daemon se diže tamo i, pokušavajući otkriti tko je on, čita bilješku da je on balansator opterećenja.
Odnosno, da li je ovo neka vrsta odvojenog procesa koji se poklanja?
Nismo mi to izmislili. Koristimo ga.
Zdravo! Imam samo pitanje o podacima korisnika. Rekli ste da tu ima problema, da neko može nešto poslati na pogrešno mjesto. Postoji li neki način za pohranjivanje korisničkih podataka u isti Git, tako da uvijek bude jasno na šta se korisnički podaci odnose?
Korisničke podatke generišemo iz šablona. Odnosno, tamo se koristi određeni broj varijabli. I Terraform generiše konačni rezultat. Dakle, ne možete samo da pogledate šablon i kažete šta će se desiti, jer su svi problemi vezani za to što programer misli da u ovu varijablu prosleđuje niz, ali se tu koristi niz. A on - bam i ja - tako-i-tako, tako-i-tako, sledeći red, i sve je puklo. Ako je ovo novi resurs i osoba ga uzme i vidi da nešto ne radi, onda se to brzo rješava. A ako se ova grupa za automatsko skaliranje ažurira, tada u nekom trenutku instance u grupi automatskog skaliranja počinju da se zamjenjuju. I bang, nešto ne radi. To boli.
Ispada da je jedino rješenje testiranje?
Da, vidite problem, dodajte testne korake tamo. To jest, izlaz se također može testirati. Možda nije tako zgodno, ali možete staviti i neke oznake - provjerite jesu li korisnički podaci zakucani ovdje.
Moje ime je Timur. Vrlo je cool što postoje izvještaji o tome kako pravilno organizirati Terraform.
Nisam ni počeo.
Mislim da će možda biti na sljedećoj konferenciji. Imam jednostavno pitanje. Zašto tvrdo kodirate vrijednost u zasebnom modulu umjesto da koristite tfvars, tj. zašto je modul sa vrijednostima bolji od tfvars-a?
Odnosno, da li treba da napišem ovde (slajd: Production/environment/settings.tf): domen = promenljiva, domen vpcnetwork, promenljiva vpcnetwork i stvars – mogu li dobiti istu stvar?
To je ono što mi radimo. Pozivamo se na izvorni modul podešavanja, na primjer.
U suštini, ovo su takvi tfvari. Tfvars je vrlo zgodan u okruženju za testiranje. Imam tfvarove za velike instance, za male. I bacio sam jedan fajl u folder. I dobio sam šta sam hteo. Kada sečemo infrastrukturu, želimo da je moguće sve sagledati i odmah razumeti. I tako ispada da trebate pogledati ovdje, a zatim pogledati tfvars.
Da li je moguće imati sve na jednom mjestu?
Da, tfvars je kada imate jedan kod. I koristi se na nekoliko različitih mjesta s različitim nijansama. Onda biste bacili tfvare i shvatili svoje nijanse. A mi smo infrastruktura kao kod u svom najčistijem obliku. Pogledao sam i shvatio.
Zdravo! Da li ste se susreli sa situacijama u kojima provajder oblaka ometa ono što ste napravili Terraform? Recimo da uređujemo metapodatke. Postoje ssh ključevi. I Google stalno stavlja svoje metapodatke i svoje ključeve tamo. A Terraform uvijek piše da ima promjena. Nakon svake vožnje, čak i ako se ništa ne promijeni, uvijek kaže da će ažurirati ovo polje sada.
Sa ključevima, ali da, dio infrastrukture je pod utjecajem ove stvari, tj. Terraform ne može ništa promijeniti. Ne možemo ništa promijeniti ni svojim rukama. Živećemo sa tim za sada.
Odnosno, susreli ste se sa nečim ovakvim, ali niste ništa smislili, kako on to radi i radi sam?
Rљ SЃRѕR¶R ° R »RµRЅRëSЋ, R °.
Zdravo! Moje ime je Starkov Stanislav. Mail. ru Group. Kako rješavate problem generiranja oznake na..., kako je proslijediti unutra? Koliko sam shvatio, preko User - data za određivanje imena hosta, postaviti Puppet? I drugi deo pitanja. Kako riješiti ovaj problem u SG-u, tj. kada generišete SG, stotine instanci istog tipa, koji je tačan naziv za njih?
One primjere koji su nam jako važni, lijepo ih imenujemo. Za one koji nisu potrebni, postoji napomena da je ovo grupa za automatsko skaliranje. A u teoriji ga možete zakucati i nabaviti novi.
Što se tiče problema sa oznakom, tog problema nema, ali postoji takav zadatak. I mi koristimo oznake veoma, veoma intenzivno, jer je infrastruktura velika i skupa. I treba da pogledamo kuda ide novac, tako da nam oznake omogućavaju da razbijemo šta je gde otišlo. I, shodno tome, ovdje se troši potraga za nečim što znači mnogo novca.
O čemu je još bilo pitanje?
Kada SG kreira stotine instanci, da li ih treba nekako razlikovati?
Ne, nemoj. Na svakoj instanci postoji agent koji javlja da imam problem. Ako agent prijavi, onda agent zna za njega i, u najmanju ruku, postoji njegova IP adresa. Već možeš pobjeći. Drugo, koristimo Consul za Discovery, gdje Kubernetes nije. I Consul također pokazuje IP adresu instance.
Odnosno, da li se fokusirate posebno na IP, a ne na ime hosta?
Nemoguće je navigirati po imenu hosta, odnosno ima ih puno. Postoje identifikatori instance - AE, itd. Možete ga pronaći negdje, možete ga baciti u pretragu.
Zdravo! Shvatio sam da je Terraform dobra stvar, skrojena za oblake.
Ne samo.
Upravo to pitanje me zanima. Ako se odlučite masovno preseliti, recimo, u Bare Metal sa svim svojim instancama? Hoće li biti problema? Ili ćete ipak morati koristiti druge proizvode, na primjer, isti Ansible koji je ovdje spomenut?
Ansible je malo o nečem drugom. To jest, Ansible već radi kada je instanca pokrenuta. A Terraform radi prije pokretanja instance. Prelazak na goli metal - ne.
Ne sada, ali posao će doći i reći: "Hajde."
Prebacivanje na drugi oblak – da, ali ovdje postoji malo drugačiji trik. Morate napisati Terraform kod na način da se možete prebaciti na neki drugi oblak uz manje truda.
Prvobitno je bio postavljen zadatak da nam cijela infrastruktura bude agnostična, tj. bilo koji oblak bi trebao biti prikladan, ali je u jednom trenutku posao odustao i rekao: „Dobro, u narednih N godina nećemo nigdje ići, možemo koristiti usluge sa Amazona"
Terraform vam omogućava da kreirate Front-End poslove, konfigurišete PagerDuty, data doc, itd. Ima puno repova. On praktično može da kontroliše ceo svet.
Hvala na izvještaju! Terraform također koristim već 4 godine. U fazi glatkog prelaska na Terraform, na infrastrukturu, na deklarativni opis, bili smo suočeni sa situacijom da neko nešto radi ručno, a vi pokušavate da napravite plan. I tu sam dobio neku grešku. Kako se nosite sa takvim problemima? Kako pronaći izgubljene resurse koji su navedeni?
Uglavnom rukama i očima, ako vidimo nešto čudno u izvještaju, onda analiziramo šta se tamo dešava ili jednostavno ubijemo. Općenito, zahtjevi za povlačenjem su uobičajena stvar.
Ako postoji greška, da li se vraćate nazad? Jeste li probali ovo?
Ne, to je odluka osobe u trenutku kada vidi problem.
izvor: www.habr.com