Čini se da programeri Terraforma nude prilično prikladne najbolje prakse za rad s AWS infrastrukturom. Postoji samo nijansa. S vremenom se povećava broj okruženja, od kojih svako ima svoje značajke. Gotovo kopija hrpe aplikacija pojavljuje se u susjednoj regiji. A kod Terraforma treba pažljivo kopirati i urediti prema novim zahtjevima ili napraviti pahuljicu.
Moje izvješće o uzorcima u Terraformu za borbu protiv kaosa 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 usmjerenim na e-trgovinu. A DevOps praksu prakticiram već 5 godina.
Moja priča će biti o mom iskustvu na projektu u tvrtki čije ime neću reći, skrivajući se iza ugovora o tajnosti podataka.
Brojevi na slajdu su naznačeni kako bi se razumjela razmjera projekta. I sve što ću dalje reći vezano je za Amazon.
Pridružio sam se ovom projektu prije 4 godine. A refaktoriranje infrastrukture bilo je u punom jeku jer je projekt narastao. A obrasci koji su korišteni više nisu bili prikladni. A s obzirom na sav planirani rast projekta, bilo je potrebno osmisliti nešto novo.
Hvala Matveyu koji nam je jučer ispričao što se dogodilo u Dodo Pizzi. Ovo se dogodilo ovdje prije 4 godine.
Došli su programeri i počeli stvarati infrastrukturni kod.
Najočitiji razlozi zašto je to bilo potrebno bilo je vrijeme za izlazak na tržište. Bilo je potrebno osigurati da DevOps tim ne bude usko grlo tijekom uvođenja. Između ostalog, Terraform i Puppet korišteni su na prvoj razini.
Terraform je projekt otvorenog koda tvrtke HashiCorp. A za one koji uopće ne znaju što je ovo, sljedećih nekoliko slajdova.
Infrastruktura kao kod znači da možemo opisati našu infrastrukturu i zamoliti neke robote da osiguraju primanje resursa koje smo opisali.
Na primjer, trebamo virtualni stroj. Opisat ćemo i dodati nekoliko potrebnih parametara.
Nakon toga ćemo konfigurirati pristup Amazonu u konzoli. I tražit ćemo Terraform plan. Terraform plan će reći: "U redu, možemo učiniti ove stvari za vaš resurs." Dodat će se barem jedan resurs. I ne očekuju se nikakve promjene.
Nakon što budete zadovoljni sa svime, možete zatražiti od Terraforma da se prijavi i Terraform će za vas stvoriti instancu, a vi ćete dobiti virtualni stroj u svom oblaku.
Naš projekt se dalje razvija. Tu dodajemo neke izmjene. Tražimo više instanci, dodajemo 53 unosa.
I ponavljamo. Molim planirajte. Vidimo koje su promjene planirane. Prijavljujemo se. I tako raste naša infrastruktura.
Terraform koristi nešto što se naziva datotekama stanja. Odnosno, on sprema sve promjene koje idu u Amazon u datoteku gdje za svaki resurs koji ste opisali postoje odgovarajući resursi koji su stvoreni u Amazonu. Stoga, kada se promijeni opis resursa, Terraform točno zna što treba promijeniti u Amazonu.
Ove državne datoteke izvorno su bile samo datoteke. I pohranili smo ih u Git, što je bilo krajnje nezgodno. Netko je uvijek zaboravio izvršiti promjene, pa je došlo do mnogih sukoba.
Sada je moguće koristiti backend, tj. Terraformu je navedeno u kojoj kanti i po kojem ključu treba spremiti državnu datoteku. A Terraform će se sam pobrinuti za dobivanje ove datoteke stanja, napraviti svu magiju i vratiti konačni rezultat.
Naša infrastruktura raste. Evo našeg koda. A sada ne želimo samo stvoriti virtualni stroj, želimo imati testno okruženje.
Terraform vam omogućuje stvaranje takve stvari kao što je modul, odnosno opisivanje iste stvari u nekoj mapi.
I, na primjer, u testiranju pozovimo ovaj modul i dobijemo istu stvar kao da smo izvršili Terraform apply u samom modulu. Za testiranje će postojati ovaj kod.
Za proizvodnju, tamo možemo poslati neke izmjene, jer u testiranju ne trebamo velike instance; u proizvodnji su velike instance samo korisne.
A onda ću se vratiti na projekt. Bio je to težak zadatak, planirana infrastruktura bila je jako velika. I bilo je potrebno nekako smjestiti sav kod tako da bude prikladan za sve: i za one koji obavljaju održavanje ovog koda i za one koji vrše izmjene. I bilo je planirano da bilo koji programer može otići i popraviti infrastrukturu prema potrebi za svoj dio platforme.
Ovo je stablo direktorija koje sam HashiCorp preporučuje ako imate veliki projekt i ima smisla cijelu infrastrukturu podijeliti na male dijelove i svaki dio opisati u zasebnoj mapi.
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 se testni skup za programere ili za testiranje morao nabaviti nekako jednostavnije. Ali nisam želio proći kroz mape i primijeniti ih u potrebnom redoslijedu i brinuti se da će baza podataka porasti, a zatim će se povećati instanca koja koristi tu bazu podataka. Stoga su sva testiranja pokrenuta iz jedne mape. Tamo su pozvani isti moduli, ali sve je napravljeno u jednoj vožnji.
Terraform se brine za sve ovisnosti. I uvijek stvara resurse u nizu tako da možete dobiti IP adresu, na primjer, iz novostvorene instance i dobiti ovu IP adresu u zapisu route53.
Osim toga, platforma je vrlo velika. A pokretanje testnog skupa, makar i na sat vremena, makar i na 8 sati, prilično je skup pothvat.
I automatizirali smo ovu stvar. A Jenkinsov posao omogućio nam je da upravljamo hrpom. U njemu je bilo potrebno pokrenuti pull request s promjenama koje programer želi testirati, navesti sve potrebne opcije, komponente i dimenzije. Ako želi testiranje performansi, može uzeti više instanci. Ako samo treba provjeriti otvara li se neki obrazac, onda bi mogao početi s minimalnom plaćom. I također navedite je li klaster potreban ili ne, itd.
A onda je Jenkins gurnuo skriptu ljuske, koja je malo modificirala kod u mapi Terraform. Uklonio sam nepotrebne datoteke i dodao potrebne datoteke. A onda je s jednim nanošenjem Terraforma hrpa podignuta.
A tu su bili i drugi koraci u koje ne želim ulaziti.
S obzirom na to da nam je za testiranje trebalo nešto više opcija nego u proizvodnji, morali smo napraviti kopije modula kako bismo u te kopije mogli dodati one značajke koje su bile potrebne samo za testiranje.
I dogodilo se da u testiranju nekako želim testirati te promjene koje će na kraju ići u proizvodnju. Ali zapravo je jedna stvar 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 iz testiranja u proizvodnju ostale u drugoj verziji.
Osim toga, pojavio se takav problem da je dodana nova usluga, koja se malo razlikovala od neke već postojeće. 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 proglasimo. 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 pahulja. Pitao sam se što misli. Postoji znanstvena činjenica da na svijetu ne postoje dvije identične pahulje, sve su malo drugačije. I čim sam ovo čuo, odmah sam osjetio svu težinu Terraform koda. Jer kada je trebalo prijeći s verzije na verziju, Terraform je zahtijevao prekidanje lančanih promjena, tj. kod više nije bio kompatibilan sa sljedećom verzijom. I morali smo napraviti zahtjev za povlačenje, koji je pokrivao gotovo polovicu datoteka u infrastrukturi, kako bismo infrastrukturu doveli do sljedeće verzije Terraforma.
I nakon što se pojavila takva pahulja, sav Terraform kod koji smo pretvorili u veliku, veliku hrpu snijega.
Za vanjskog programera koji je izvan operacije, to mu nije bitno, 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 te promjene. A cijena tih promjena se jako, jako povećala sa svakom dodatnom pahuljom snijega.
Postoji priča o tome kako student na seminaru nacrta dva savršena kruga kredom na ploči. I učitelj je iznenađen kako je uspio crtati tako glatko bez šestara. Student odgovara: “Vrlo jednostavno, proveo sam dvije godine u vojsci okrećući stroj za mljevenje mesa.”
A od četiri godine koliko sam uključen u ovaj projekt, Terraformom se bavim oko dvije godine. I, naravno, imam neke trikove, nekoliko savjeta o tome kako pojednostaviti kod Terraforma, raditi s njim kao s programskim jezikom i smanjiti teret programerima koji moraju održavati ovaj kod ažuriranim.
Prva stvar s kojom bih želio započeti su simboličke veze. Terraform ima puno koda koji se ponavlja. Na primjer, poziv pružatelju na gotovo svakoj točki gdje stvaramo dio infrastrukture je isti. I logično je staviti ga u zasebnu mapu. I gdje god se od pružatelja zahtijeva da napravi simboličke veze na ovu datoteku.
Na primjer, u proizvodnji koristite pretpostaviti ulogu, koja vam omogućuje dobivanje prava pristupa nekom vanjskom Amazon računu. A nakon promjene jedne datoteke, sve preostale u stablu resursa imat će potrebna prava tako da Terraform zna kojem segmentu Amazona pristupiti.
Gdje simboličke veze ne uspijevaju? Kao što sam rekao, Terraform ima državne datoteke. I jako su, jako cool. Ali stvar je u tome što Terraform inicijalizira backend na prvom mjestu. I on ne može koristiti nikakve varijable u tim parametrima, oni uvijek moraju biti napisani u tekstu.
I kao rezultat toga, kada netko napravi novi izvor, on kopira dio koda iz drugih mapa. I može pogriješiti s ključem ili s kantom. Na primjer, on pravi pješčanik od pješčanika, a zatim ga proizvodi u proizvodnji. I tako se može ispostaviti da će se kanta u proizvodnji koristiti iz pješčanika. Naravno, brzo će ga pronaći. To će se nekako moći popraviti, ali ipak je to gubitak vremena i, donekle, resursa.
Što možemo sljedeće učiniti? Prije rada s 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 napraviti 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 repozitoriju kao ključ do datoteke stanja, tada će, prema tome, pogreška ovdje biti eliminirana.
Gdje mogu dobiti podatke? JSON datoteka. Terraform vam omogućuje pisanje infrastrukture ne samo u hcl (HashiCorp Configuration Language), već i u JSON-u.
JSON je lako čitati iz skripte ljuske. U skladu s tim, konfiguracijsku datoteku s kantom možete staviti na neko mjesto. I koristite ovu kantu iu Terraform kodu iu shell skripti za inicijalizaciju.
Zašto je važno imati kantu za Terraform? Jer postoji nešto poput udaljenih datoteka stanja. Odnosno, kada podignem neki resurs, da bih rekao Amazonu: "Molim vas podignite instancu", moram navesti mnogo potrebnih parametara.
I ti su identifikatori pohranjeni u nekoj drugoj mapi. I mogu otići i reći: "Terraforme, molim te otrči do datoteke stanja tog istog resursa i nabavi mi ove identifikatore." I tako se pojavljuje određeno sjedinjenje između različitih regija ili sredina.
Nije uvijek moguće koristiti datoteku udaljenog stanja. Na primjer, ručno ste izradili VPC. A kod Terraforma koji stvara VPC stvara toliko različite VPC-ove da će to trajati jako dugo i morat ćete prilagođavati jedan drugome, pa se možete poslužiti sljedećim trikom.
To jest, napravite modul za koji se čini da čini VPC i, takoreći, daje vam identifikatore, ali zapravo postoji jednostavno datoteka s tvrdo kodiranim vrijednostima koje se mogu koristiti za stvaranje iste instance.
Nije uvijek potrebno spremiti datoteku stanja u oblak. Na primjer, kada testirate module, možete koristiti backend inicijalizaciju, gdje će datoteka jednostavno biti spremljena na disk u vrijeme testiranja.
Sada malo o testiranju. Što možete testirati u Terraformu? Vjerojatno je mnogo toga moguće, ali ja ću govoriti o ove 4 stvari.
HashiCorp razumije kako Terraform kod treba biti formatiran. Terraform fmt vam omogućuje formatiranje koda koji uređujete u skladu s tim uvjerenjem. Sukladno tome, testovi moraju nužno provjeriti odgovara li oblikovanje onome što je HashiCorp ostavio u nasljeđe, tako da nema potrebe mijenjati mjesto zagrada i sl.
Sljedeći je Terraform validate. Čini malo više od provjere sintakse - ala, jesu li sve zagrade uparene. Što je tu važno? Naša infrastruktura je vrlo opsežna. U njemu ima puno različitih tatica. I u svakoj morate pokrenuti Terraform validaciju.
U skladu s tim, kako bismo ubrzali testiranje, paralelno izvodimo više procesa koristeći parallel.
Parallel je jako cool stvar, koristite je.
Ali svaki put kada se Terraform inicijalizira, odlazi u HashiCorp i pita: “Koje su najnovije verzije dodataka? I dodatak koji imam u predmemoriji – je li pravi ili krivi?” A ovo se usporavalo na svakom koraku.
Ako kažete Terraformu gdje su dodaci, tada će Terraform reći: “U redu, ovo je vjerojatno najnovija stvar koja postoji. Neću ići nigdje, odmah ću početi s provjerom valjanosti vašeg Terraform koda.”
Kako bismo popunili mapu s potrebnim dodacima, imamo vrlo jednostavan Terraform kod koji samo treba inicijalizirati. Ovdje, naravno, morate navesti sve pružatelje koji na neki način sudjeluju u vašem kodu, inače će Terraform reći: "Ne poznajem određenog pružatelja jer nije u cacheu."
Sljedeći je plan Terraform. Kao što sam rekao, razvoj je cikličan. Radimo izmjene koda. Zatim 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 pokvariti neki susjedni. Stoga treba napraviti Terraform plan za cjelokupnu infrastrukturu i pokazati kakve se promjene planiraju.
Možete to učiniti pametno. Na primjer, napisali smo Python skriptu koja rješava ovisnosti. I ovisno o tome što je promijenjeno: modul Terraform ili samo određena komponenta, izrađuje planove za sve zavisne mape.
Planovi terraforme moraju se izraditi na zahtjev. Barem mi to radimo.
Naravno, dobro je raditi testove za svaku promjenu, za svaki commit, ali planovi su prilično skupa stvar. A u zahtjevu za povlačenjem kažemo: "Molim vas, dajte mi planove." Robot počinje. I pošaljite komentare ili priložite sve planove koji se očekuju od vaših promjena.
Plan je prilično skupa stvar. Potrebno je vrijeme jer Terraform odlazi u Amazon i pita: “Postoji li još uvijek ova instanca? Ima li ova automatska skala potpuno iste parametre?" A kako biste ovo 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 točno odgovarati onome što je u Amazonu.
Takav Terraform plan ide puno brže, ali stanje mora odgovarati vašoj infrastrukturi, tj. negdje, nekad mora krenuti Terraform refresh. Terraform refresh čini 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, a Terraform radi na vašoj infrastrukturi, postoji ranjivost. To jest, vi u biti izvršavate kod. A ako zahtjev za povlačenjem sadrži neku vrstu zlonamjernog koda, tada se može izvršiti na infrastrukturi koja ima previše pristupa. Stoga budite oprezni gdje izvodite Terraform plan.
Sljedeća stvar o kojoj bih želio govoriti je testiranje korisničkih podataka.
Što su korisnički podaci? U Amazonu, kada kreiramo instancu, možemo poslati određeno slovo s instancom - meta podacima. Kada se instanca pokrene, init u oblaku obično je uvijek prisutan na tim instancama. Cloud init čita ovo pismo i kaže: "U redu, danas sam ja balanser opterećenja." I u skladu s tim savezima on izvodi neke radnje.
Ali, nažalost, kada napravimo Terraformov plan i Terraformovu aplikaciju, podaci o korisniku izgledaju kao ovakva mješavina brojeva. Odnosno, on vam jednostavno šalje hash. A sve što možete pogledati u planu je hoće li biti promjena ili će hash ostati isti.
A ako ne obratite pozornost na ovo, onda neka pokvarena tekstualna datoteka može završiti na Amazonu, na pravoj infrastrukturi.
Alternativno, prilikom izvođenja možete navesti ne cijelu infrastrukturu, već samo predložak. A u kodu recite: "Molim vas, prikažite ovaj predložak na mom zaslonu." Kao rezultat toga, možete dobiti ispis kako će vaši podaci izgledati na Amazonu.
Druga mogućnost je korištenje modula za generiranje korisničkih podataka. Primijenit ćete ovaj modul. Dobivate datoteku na disku. Usporedite ga s referentnim. I tako, ako neki tip odluči malo ispraviti korisničke podatke, onda će vaši testovi reći: "OK, tu i tamo ima nekih promjena - to je normalno."
Sljedeća stvar o kojoj bih želio govoriti je Automatska Terraform primjena.
Naravno, prilično je zastrašujuće raditi Terraform aplikaciju u automatskom načinu rada, jer tko zna kakve su promjene tamo stigle i koliko mogu biti destruktivne za živu infrastrukturu.
Za testno okruženje to je sve normalno. Odnosno, posao koji stvara testno okruženje ono je što treba svim programerima. A izraz poput "meni je sve radilo" nije smiješan meme, već dokaz da se osoba zbunila, podigla hrpu i pokrenula neke testove na ovoj hrpi. I on se uvjerio da je tamo sve u redu i rekao: "U redu, kod koji objavljujem je testiran."
U proizvodnji, sandboxu i drugim okruženjima koja su poslovno kritičnija, možete djelomično koristiti neke resurse sasvim sigurno jer to ne rezultira umiranjem ikoga. To su: autoscale grupe, sigurnosne grupe, uloge, route53, a popis tamo može biti prilično velik. Ali pratite što se događa, čitajte izvješća o automatiziranim prijavama.
Tamo gdje je opasno ili zastrašujuće primijeniti se, na primjer, ako su to neki postojani resursi iz baze podataka, tada primajte izvješća da postoje neprimijenjene promjene u nekom dijelu infrastrukture. A inženjer pod nadzorom pokreće poslove za prijavu ili to radi sa svoje konzole.
Amazon ima nešto poput zaštite od prekida. I može zaštititi u nekim slučajevima od promjena koje nisu potrebne za vas. Odnosno, Terraform je otišao u Amazon i rekao: "Moram ubiti ovu instancu kako bih napravio drugu." A Amazon kaže: “Žao mi je, ne danas. Imamo zaštitu od prekida."
A šlag na torti je optimizacija koda. Kada radimo s Terraform kodom, moramo proslijediti jako velik broj parametara modulu. To su parametri koji su potrebni da bi se stvorio nekakav resurs. A kod se pretvara u velike popise parametara koje treba proslijediti od modula do modula, od modula do modula, pogotovo ako su moduli ugniježđeni.
I jako ga je teško čitati. Vrlo je teško to pregledati. I vrlo često se ispostavi da neki parametri prolaze reviziju i nisu baš ono što je potrebno. A to košta vremena i novca da se kasnije popravi.
Stoga predlažem da upotrijebite nešto poput složenog parametra koji uključuje određeno stablo vrijednosti. Odnosno, potrebna vam je neka vrsta mape u kojoj imate sve vrijednosti koje biste željeli imati u nekom okruženju.
I pozivom 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 izračune koristeći tako noviju značajku u Terraformu kao što su lokalci. I onda, s jednim izlazom, dajte neki složeni parametar, koji može uključivati hashove polja itd.
Ovdje su završila sva moja najbolja otkrića. I želio bih ispričati priču o Kolumbu. Kada je tražio novac za svoju ekspediciju da otkrije Indiju (kako je tada mislio), nitko mu nije vjerovao i mislili su da je to nemoguće. Zatim je rekao: "Pazi da jaje ne padne." Svi bankari, vrlo bogati i vjerojatno pametni ljudi, pokušavali su nekako smjestiti 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. A kada otvorim Indiju, svi će koristiti ovaj trgovački put."
A ovo što sam vam upravo rekao vjerojatno su prilično jednostavne i trivijalne stvari. A kada naučite o njima i počnete ih koristiti, to je redoslijed stvari. Stoga iskoristite prednost. A ako su vam to sasvim normalne stvari, onda barem znate kako postaviti jaje da ne padne.
Ukratko,
- Pokušajte izbjeći snježne pahulje. A što je manje snježnih pahulja, to ćete manje resursa trebati da izvršite bilo kakve promjene u svojoj velikoj infrastrukturi.
- Stalne promjene. Odnosno, kada se u kodu dogode neke promjene, svoju infrastrukturu trebate uskladiti s tim promjenama što je prije moguće. Ne bi se smjela dogoditi situacija da netko nakon dva-tri mjeseca dođe pogledati Elasticsearch, napravi plan Terraforma i dogodi se hrpa promjena koje nije očekivao. I potrebno je puno vremena da se sve vrati u red.
- Testovi i automatizacija. Što je vaš kôd više pokriven testovima i značajkama, to imate više povjerenja da sve radite ispravno. A automatska isporuka višestruko će povećati vaše povjerenje.
- 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 biti nekih nijansi koje će nadilaziti testno okruženje. Ali svejedno, plus ili minus, to se može osigurati.
- A ako imate puno Terraform koda i potrebno je puno vremena da ovaj kod bude ažuran, tada nikada nije prekasno da ga refaktorirate i dovedete u dobro stanje.
- Nepromjenjiva infrastruktura. AMI isporuka prema planu.
- 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 prihvatiti više zahtjeva, pričekajte." A pola ureda čeka dok ne pokrene svoju infrastrukturu.
- Uočite primjere. Amazon nije jeftin događaj i spotovi vam omogućuju dosta uštede. I tamo možete ispričati cijelu reportažu o tome.
- Sigurnosne i IAM uloge.
- U potrazi za izgubljenim resursima, kada imate primjerke nepoznatog porijekla u Amazoneu, oni jedu novac. Čak i ako instance koštaju 100-150 USD mjesečno, to je više od 1 USD godišnje. Pronalaženje takvih resursa je isplativ posao.
- I rezervirane instance.
To je sve za mene. Terraform je jako cool, koristite ga. Hvala vam!
pitanja
Hvala na izvješću! Vaša datoteka stanja je u S3, ali kako riješiti problem da nekoliko ljudi može uzeti ovu datoteku stanja i pokušati je proširiti?
Prije svega, nikamo nam se ne žuri. Drugo, postoje zastavice, u kojima javljamo da radimo na nekom dijelu koda. Odnosno, unatoč činjenici da je infrastruktura jako velika, to ne znači da netko stalno nešto koristi. A kada je postojala aktivna faza, to je bio problem; pohranili smo datoteke stanja u Git. To je bilo važno, inače bi netko napravio datoteku stanja, a mi smo ih morali ručno spajati da bi se sve nastavilo. Sada tog problema više nema. 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 poduzeća, tj. sve što možete otići i preuzeti besplatno.
Moje ime je Stanislav. Htio sam napraviti mali dodatak. Govorili ste o Amazonovoj značajci koja vam omogućuje da instancu učinite neubojivom. To 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 poanta.
Također sam htio pitati dvije stvari. Prvo, govorili ste o testiranju. Jeste li koristili alate za testiranje? Čuo sam za dodatak Test Kitchen. Možda postoji nešto više. Također bih želio pitati o lokalnim vrijednostima. Kako se bitno razlikuju od ulaznih varijabli? I zašto ne mogu parametrizirati nešto samo kroz lokalne vrijednosti? Pokušao sam shvatiti ovu temu, ali nekako nisam mogao sam shvatiti.
Možemo razgovarati detaljnije izvan ove sobe. Naši alati za testiranje u potpunosti su sami napravljeni. Nema tu ništa za testirati. Općenito, postoje opcije kada automatizirani testovi negdje pokupe infrastrukturu, provjere je li u redu, a zatim sve unište s izvješćem da je vaša infrastruktura još uvijek u dobrom stanju. Mi to nemamo jer se testni skupovi izvode svaki dan. I to je dovoljno. A ako se nešto počne kvariti, počet će se kvariti i bez da to negdje drugdje provjerimo.
Što se tiče lokalnih vrijednosti, nastavimo razgovor izvan sobe.
Zdravo! Hvala na izvješću! Vrlo informativno. Rekli ste da imate mnogo iste vrste koda za opisivanje infrastrukture. Jeste li razmišljali o generiranju ovog koda?
Super pitanje, hvala! Poanta je da kada koristimo infrastrukturu kao kod, pretpostavljamo da gledamo kod i razumijemo koja infrastruktura leži iza tog koda. Ako se kod generira, tada moramo zamisliti koji će se kod generirati kako bismo razumjeli kakva će infrastruktura biti tamo. Ili generiramo kod, izvršimo ga i u biti se dogodi ista stvar. Pa smo slijedili put koji smo napisali, dobili smo ga. Plus generatori su se pojavili nešto kasnije kada smo ih počeli proizvoditi. I već je bilo prekasno za promjenu.
Jeste li čuli nešto o jsonnetu?
Ne.
Vidi, ovo je jako cool stvar. Vidim konkretan slučaj u kojem to možete primijeniti i generirati strukturu podataka.
Generatori su dobri kad ih imate, kao u onom vicu o aparatu za brijanje. Odnosno, prvi put je lice drugačije, ali onda svi imaju isto lice. Generatori rade jako dobro. Ali, nažalost, lica su nam malo drugačija. Ovo je problem.
Samo gledam. Hvala vam!
Moje ime je Maxim, ja sam iz Sberbanke. Govorili ste malo o tome kako ste pokušavali Terraform dovesti do ekvivalenta programskog jezika. Nije li lakše koristiti Ansible?
To su vrlo različite stvari. Možete stvarati resurse u Ansibleu, a Puppet može stvarati resurse u Amazonu. Ali Terraform je ravno naoštren.
Imate li samo Amazon?
Nije da imamo samo Amazon. Gotovo da imamo samo Amazon. Ali ključna značajka 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." A Terraform će reći: "U redu, ubit ću 2", a Ansible će reći: "U redu, evo 3 za tebe." Ukupno 8.
Zdravo! Hvala na vašem izvješću! Bilo je vrlo zanimljivo čuti o Terraformu. Želio bih odmah dati mali komentar na činjenicu da Terraform još uvijek nema stabilno izdanje, tako da se prema Terraformu odnosite s velikim oprezom.
Dobra žlica za večeru. Odnosno, ako ti treba neko rješenje, onda nekad odgodiš ono što je nestabilno itd., ali radi i nama je pomoglo.
Pitanje je ovo. Koristite Remote backend, koristite S 3. Zašto ne koristite službeni backend?
Službeno?
Terraform Cloud.
Kada se pojavio?
Prije otprilike 4 mjeseca.
Da se pojavio prije 4 godine, vjerojatno bih ti odgovorio na pitanje.
Već postoji ugrađena funkcija i brave, a možete pohraniti i datoteku stanja. Pokušati. Ali ni to nisam testirao.
Putujemo u velikom vlaku koji se kreće velikom brzinom. I ne možete samo uzeti nekoliko automobila i baciti ih.
Govorio si o snježnim pahuljama, zašto nisi upotrijebio granu? Zašto nije tako išlo?
Naš pristup je da je cijela infrastruktura u jednom repozitoriju. Terraform, Puppet, sve skripte koje su na neki način povezane s ovim, sve su u jednom repozitoriju. Na taj način možemo osigurati da se inkrementalne promjene testiraju jedna za drugom. Da se radi o hrpi grana, onda bi takav projekt bilo gotovo nemoguće održavati. Prođe šest mjeseci, a oni se toliko raziđu da je to samo neka vrsta kazne. To je ono od čega sam želio pobjeći prije refaktoriranja.
Znači ne radi?
Ovo nikako ne ide.
U grani sam izrezao slajd mape. To jest, ako to učinite za svaki testni stog, na primjer, tim A ima svoju vlastitu mapu, tim B ima svoju vlastitu mapu, onda to također ne radi. Stvorili smo objedinjeni kod testnog okruženja koji je bio dovoljno fleksibilan da odgovara svima. Odnosno, poslužili smo jedan kod.
Zdravo! Moje ime je Yura! Hvala na izvješću! Pitanje o modulima. Kažete da koristite module. Kako riješiti problem ako su na jednom modulu napravljene promjene koje nisu kompatibilne s promjenom druge osobe? Da li na neki način kreirate verzije modula ili pokušavate unijeti wunderwaffle da ispuni dva zahtjeva?
Ovo je veliki problem s hrpom snijega. Od toga patimo kada neka bezazlena promjena može pokvariti neki dio infrastrukture. A to će se primijetiti tek nakon dužeg vremena.
Odnosno, još nije riješeno?
Izrađujete univerzalne module. Izbjegavajte snježne pahulje. I sve će uspjeti. Druga polovica izvješća govori o tome kako to izbjeći.
Zdravo! Hvala na izvješću! Želio bih pojasniti. Iza kulisa bila je velika hrpa po koju sam došao. Kako su lutka i distribucija uloga integrirani?
Korisnički podaci.
Odnosno, samo ispljunete datoteku i nekako je izvršite?
Korisnički podaci su bilješka, tj. kada napravimo klon slike, Daemon se digne tamo i, pokušavajući shvatiti tko je, pročita bilješku da je on load balancer.
Odnosno, je li to neka vrsta odvojenog procesa koji se daje?
Nismo mi to izmislili. Mi ga koristimo.
Zdravo! Imam samo pitanje o korisničkim podacima. Rekli ste da tamo ima problema, da netko može nešto poslati na krivo mjesto. Postoji li neki način da se korisnički podaci pohrane u isti Git, tako da uvijek bude jasno na što se korisnički podaci odnose?
Generiramo korisničke podatke iz predloška. Odnosno, tu se koristi određeni broj varijabli. A Terraform generira konačni rezultat. Stoga ne možete samo pogledati predložak i reći što će se dogoditi, jer su svi problemi povezani s činjenicom da programer misli da prosljeđuje niz u ovoj varijabli, ali se tamo koristi niz. A on - bam i ja - tako-i-to, tako-i-to, sljedeći red, i sve se pokvarilo. Ako je to novi resurs i osoba ga uzme i vidi da nešto ne radi, onda se to brzo riješi. A ako se ova grupa s automatskim skaliranjem ažurira, tada će se u nekom trenutku instance u grupi s automatskim skaliranjem početi zamjenjivati. I bang, nešto ne ide. To boli.
Ispada da je jedino rješenje testiranje?
Da, vidite problem, tamo dodajete testne korake. Odnosno, izlaz se također može testirati. Možda nije tako zgodno, ali također možete staviti neke oznake - provjerite jesu li korisnički podaci zakovani ovdje.
Moje ime je Timur. Vrlo je cool što postoje izvješća o tome kako pravilno organizirati Terraform.
Nisam ni počeo.
Mislim da će možda na sljedećoj konferenciji biti. Imam jednostavno pitanje. Zašto tvrdo kodirate vrijednost u zasebnom modulu umjesto da koristite tfvars, tj. zašto je modul s vrijednostima bolji od tfvars?
Odnosno, trebam li napisati ovdje (slajd: Production/environment/settings.tf): domena = varijabla, domena vpcnetwork, varijabla vpcnetwork i stvari – mogu li dobiti isto?
To je upravo ono što mi radimo. Govorimo, na primjer, o izvornom modulu postavki.
U biti, ovo je takav tfvars. Tfvars je vrlo zgodan u okruženju za testiranje. Imam tfvars za velike instance, za male. I bacio sam jedan fajl u folder. I dobio sam što sam htio. Kada režemo infrastrukturu, želimo da se sve može vidjeti i odmah razumjeti. I tako ispada da trebate pogledati ovdje, a zatim pogledati tfvars.
Je li 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. Zatim biste bacili tfvars i dobili svoje nijanse. A mi smo infrastruktura kao kod u svom najčišćem obliku. Pogledao sam i shvatio.
Zdravo! Jeste li se susreli sa situacijama u kojima pružatelj usluga oblaka ometa ono što ste napravili Terraform? Recimo da uredimo metapodatke. Postoje ssh ključevi. A Google tamo neprestano stavlja svoje metapodatke i svoje ključeve. A Terraform uvijek piše da ima promjena. Nakon svakog pokretanja, čak i ako se ništa ne promijeni, uvijek kaže da će sada ažurirati ovo polje.
S ključevima, ali da, dio infrastrukture je zahvaćen time, tj. Terraform ne može ništa promijeniti. Ni rukama ne možemo ništa promijeniti. Živjet ćemo s tim za sada.
Odnosno, naišli ste na nešto poput ovoga, ali niste smislili ništa, kako on to radi i radi sam?
Nažalost da.
Zdravo! Moje ime je Starkov Stanislav. pošta. ru Grupa. Kako rješavate problem generiranja oznake na..., kako je prosljeđujete unutra? Koliko sam shvatio, preko User - data za navođenje imena glavnog računala, postaviti Puppet on? I drugi dio pitanja. Kako riješiti ovaj problem u SG-u, tj. kada generirate SG, stotine instanci istog tipa, koji je točan naziv za njih?
One instance koje su nam jako važne nazivamo lijepo. Oni koji nisu potrebni, postoji napomena da se radi o grupi s automatskim skaliranjem. I u teoriji ga možete srediti i nabaviti novi.
Što se tiče problema s oznakom, ne postoji takav problem, ali postoji takav zadatak. I koristimo oznake vrlo, vrlo intenzivno, jer je infrastruktura velika i skupa. I moramo pogledati kamo novac odlazi, tako da nam oznake omogućuju da raščlanimo što je kamo otišlo. I, shodno tome, ovdje se troši potraga za nečim što znači veliki novac.
O čemu je još bilo pitanje?
Kada SG stvara stotine instanci, treba li ih nekako razlikovati?
Ne, nemoj. Na svakoj instanci postoji agent koji javlja da imam problem. Ako agent prijavi, onda agent zna za njega i, barem, njegova IP adresa postoji. Već možete pobjeći. Drugo, koristimo Consul za Discovery, gdje Kubernetes nije. A Consul također prikazuje IP adresu instance.
Odnosno, fokusirate li se posebno na IP, a ne na naziv hosta?
Nemoguće je kretati se po imenu hosta, tj. ima ih puno. Postoje identifikatori primjeraka - AE itd. Možeš to negdje pronaći, možeš baciti u pretragu.
Zdravo! Shvatio sam da je Terraform dobra stvar, skrojena za oblake.
Ne samo.
Upravo to pitanje me zanima. Ako odlučite masovno prijeći recimo na 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 se instanca pokrene. I Terraform radi prije nego što se instanca pokrene. Prelazak na Bare Metal - ne.
Ne sada, ali posao će doći i reći: "Hajde."
Prelazak na drugi oblak - da, ali ovdje postoji malo drugačiji trik. Morate napisati Terraform kod na takav način da se možete prebaciti na neki drugi oblak s manje truda.
U početku je postavljen zadatak da je cijela naša infrastruktura agnostička, tj. bilo koji oblak bi trebao biti prikladan, ali u jednom trenutku posao je odustao i rekao: "U redu, u sljedećih N godina nećemo ići nikamo, možemo koristiti usluge iz Amazona"
Terraform vam omogućuje stvaranje Front-End poslova, konfiguriranje PagerDuty, data doc, itd. Ima puno repova. On praktički može kontrolirati cijeli svijet.
Hvala na izvješću! Također koristim Terraform već 4 godine. U fazi laganog prijelaza na Terraform, na infrastrukturu, na deklarativni opis, suočili smo se sa situacijom da netko nešto radi ručno, a vi pokušavate napraviti plan. I tu sam dobio nekakvu grešku. Kako se nosite s takvim problemima? Kako pronaći izgubljene resurse koji su navedeni?
Uglavnom rukama i očima, ako vidimo nešto čudno u izvješću, onda analiziramo što se tamo događa ili jednostavno ubijemo. Općenito, zahtjevi za povlačenjem su uobičajena stvar.
Ako postoji greška, vraćate li se? Jeste li pokušali ovo učiniti?
Ne, to je odluka osobe u trenutku kada vidi problem.
Izvor: www.habr.com