Mnogi ljudi poznaju i koriste Terraform u svom svakodnevnom radu, ali najbolje prakse za njega još nisu formirane. Svaki tim mora izmisliti vlastite pristupe i metode.
Vaša infrastruktura gotovo sigurno počinje jednostavno: nekoliko resursa + nekoliko programera. S vremenom raste u svim mogućim smjerovima. Pronalazite li načine za grupiranje resursa u Terraform module, organiziranje koda u mape i što još može poći po zlu? (poznate posljednje riječi)
Vrijeme prolazi i osjećate se kao da je vaša infrastruktura vaš novi ljubimac, ali zašto? Zabrinuti ste zbog neobjašnjivih promjena u infrastrukturi, bojite se dotaknuti infrastrukturu i kodirati - kao rezultat toga, odgađate novu funkcionalnost ili smanjujete kvalitetu...
Nakon tri godine upravljanja zbirkom Terraform modula zajednice za AWS na Githubu i dugotrajnog održavanja Terraforma u produkciji, Anton Babenko spreman je podijeliti svoje iskustvo: kako napisati TF module tako da to ne boli u budućnosti.
Do kraja predavanja sudionici će se bolje upoznati s načelima upravljanja resursima u Terraformu, najboljim praksama povezanim s modulima u Terraformu i nekim načelima kontinuirane integracije povezanim s upravljanjem infrastrukturom.
Odricanje: Napominjem da je ovo izvješće datirano u studenom 2018. — već su prošle 2 godine. Verzija Terraform 0.11 o kojoj se govori u izvješću više nije podržana. U protekle 2 godine izdana su 2 nova izdanja koja sadrže mnogo inovacija, poboljšanja i promjena. Obratite pozornost na ovo i provjerite dokumentaciju.
reference:
- +
- — kod za automatsko formatiranje i dokumentacija
- — generator Terraform modula (WIP)
- — Generator terraform koda iz vizualnih dijagrama (WIP)
- www.terraform-best-practices.com
- (Novi postovi su na mojoj osobnoj web stranici www.antonbabenko.com/)
- @antonbabenko - Twitter, i hrpa raznih Slacksa
Moje ime je Anton Babenko. Neki od vas su vjerojatno koristili kôd koji sam napisao. Sada ću o tome govoriti s više povjerenja nego ikada, jer imam pristup statistici.
Radim na Terraformu i aktivan sam sudionik i suradnik na velikom broju open source projekata vezanih uz Terraform i Amazon od 2015. godine.
Od tada sam napisao dovoljno koda da to postavim na zanimljiv način. I pokušat ću vam sada ispričati o ovome.
Govorit ću o zamršenostima i specifičnostima rada s Terraformom. Ali to zapravo nije tema HighLoada. A sada ćete shvatiti i zašto.
S vremenom sam počeo pisati Terraform module. Korisnici su napisali pitanja, ja sam ih prepisao. Zatim sam napisao razne pomoćne programe za formatiranje koda pomoću zakačke za pre-commit, itd.
Bilo je mnogo zanimljivih projekata. Volim generiranje koda jer volim da računalo radi sve više i više posla za mene i programera, tako da trenutno radim na Terraform generatoru koda iz vizualnih dijagrama. Možda su ih neki od vas vidjeli. Ovo su prekrasne kutije sa strelicama. I mislim da je sjajno ako možete kliknuti gumb "Izvezi" i dobiti sve to kao kod.
Ja sam iz Ukrajine. Živim u Norveškoj mnogo godina.
Također, informacije za ovo izvješće prikupljene su od ljudi koji znaju moje ime i nalaze me na društvenim mrežama. Gotovo uvijek imam isti nadimak.
Kao što sam spomenuo, glavni sam održavatelj Terraform AWS modula, koji je jedan od najvećih repozitorija na GitHubu gdje hostiramo module za najčešće zadatke: VPC, Autoscaling, RDS.
A ono što ste sada čuli je najosnovnije. Ako sumnjate da razumijete što je Terraform, onda je bolje da vrijeme provedete negdje drugdje. Ovdje će biti puno tehničkih pojmova. I nisam oklijevao proglasiti razinu izvješća najvišom. To znači da mogu govoriti koristeći sve moguće termine bez puno objašnjavanja.
Terraform se pojavio 2014. kao uslužni program koji vam je omogućio pisanje, planiranje i upravljanje infrastrukturom kao kodom. Ključni koncept ovdje je "infrastruktura kao kod".
Sva dokumentacija je, kao što rekoh, zapisana . Nadam se da većina ljudi zna za ovu stranicu i da je pročitala dokumentaciju. Ako je tako, onda ste na pravom mjestu.
Ovako izgleda obična Terraform konfiguracijska datoteka, u kojoj prvo definiramo neke varijable.
U ovom slučaju definiramo "aws_region".
Zatim opisujemo koje resurse želimo stvoriti.
Pokrećemo neke naredbe, posebno "terraform init" kako bismo učitali ovisnosti i pružatelje usluga.
I pokrećemo naredbu “terraform apply” kako bismo provjerili odgovara li navedena konfiguracija resursima koje smo stvorili. Budući da dosad nismo ništa stvorili, Terraform nas potiče da stvorimo ove resurse.
Ovo potvrđujemo. Tako stvaramo kantu koja se zove morski puž.
Postoji i nekoliko sličnih uslužnih programa. Mnogi od vas koji koriste Amazon poznaju AWS CloudFormation ili Google Cloud Deployment Manager ili Azure Resource Manager. Svaki od njih ima vlastitu implementaciju neke vrste za upravljanje resursima unutar svakog od ovih pružatelja javnih oblaka. Terraform je posebno koristan jer vam omogućuje upravljanje preko 100 pružatelja usluga. (Više detalja )
Ciljevi kojima je Terraform težio od samog početka:
- Terraform pruža jedinstveni prikaz resursa.
- Omogućuje vam podršku za sve moderne platforme.
- Terraform je od samog početka osmišljen kao uslužni program koji vam omogućuje da promijenite infrastrukturu na siguran i predvidljiv način.
U 2014. riječ "predvidljivo" zvučala je vrlo neobično u ovom kontekstu.
Terraform je univerzalni alat. Ako imate API, tada možete kontrolirati apsolutno sve:
- Možete koristiti više od 120 pružatelja usluga za upravljanje svime što želite.
- Na primjer, možete koristiti Terraform za opisivanje pristupa GitHub repozitoriju.
- Možete čak stvarati i zatvarati bugove u Jiri.
- Možete upravljati mjernim podacima New Relic.
- Možete čak i stvarati datoteke u dropboxu ako to stvarno želite.
Sve se to postiže korištenjem Terraform pružatelja usluga, koji imaju otvoreni API koji se može opisati u Go.
Recimo da smo počeli koristiti Terraform, pročitali dokumentaciju na stranici, pogledali neki video i počeli pisati main.tf, kao što sam pokazao na prethodnim slajdovima.
I sve je super, imate datoteku koja stvara VPC.
Ako želite stvoriti VPC, tada navedite otprilike ovih 12 redaka. Opišite u kojoj regiji želite stvoriti, koji cidr_block IP adresa koristiti. To je sve.
Naravno, projekt će postupno rasti.
I tu ćete dodati gomilu novih stvari: resurse, izvore podataka, integrirat ćete se s novim pružateljima usluga, odjednom ćete htjeti koristiti Terraform za upravljanje korisnicima na svom GitHub računu, itd. Možda ćete htjeti koristiti različiti DNS pružatelji, križati sve. Terraform ovo olakšava.
Pogledajmo sljedeći primjer.
Postupno dodajete internet_gateway jer želite da resursi s vašeg VPC-a imaju pristup internetu. Ovo je dobra ideja.
Rezultat je ovaj main.tf:
Ovo je gornji dio main.tf.
Ovo je donji dio main.tf.
Zatim dodajete podmrežu. Dok budete htjeli dodati NAT pristupnike, rute, tablice usmjeravanja i hrpu drugih podmreža, nećete imati 38 linija, već otprilike 200-300 linija.
To jest, vaša main.tf datoteka postupno raste. I prilično često ljudi stavljaju sve u jednu datoteku. 10-20 Kb pojavljuje se u main.tf. Zamislite da je 10-20 Kb tekstualni sadržaj. I sve je povezano sa svime. S tim postupno postaje teško raditi. 10-20 Kb je dobar korisnički slučaj, ponekad i više. I ljudi ne misle uvijek da je to loše.
Kao iu običnom programiranju, tj. ne infrastrukturi kao kodu, navikli smo koristiti hrpu različitih klasa, paketa, modula, grupacija. Terraform vam omogućuje da učinite gotovo istu stvar.
- Šifra raste.
- Ovisnosti između resursa također rastu.
A mi imamo veliku, veliku potrebu. Shvaćamo da ovako više ne možemo živjeti. Naš kod postaje golem. 10-20 Kb, naravno, nije previše, ali govorimo samo o mrežnom stogu, tj. dodali ste samo mrežne resurse. Ne govorimo o Application Load Balancer-u, deployment ES cluster-u, Kubernetes-u itd., gdje se 100 Kb lako može utkati. Ako sve ovo zapišete, vrlo brzo ćete saznati da Terraform nudi Terraform module.
Terraform moduli su samostalna Terraform konfiguracija kojom se upravlja kao grupa. To je sve što trebate znati o Terraform modulima. Nisu nimalo pametni, ne dopuštaju vam nikakve složene veze ovisno o nečemu. Sve to pada na pleća programera. Odnosno, ovo je samo neka vrsta Terraform konfiguracije koju ste već napisali. I možete to jednostavno nazvati kao grupu.
Stoga pokušavamo razumjeti kako ćemo optimizirati naših 10-20-30 Kb koda. Postupno shvaćamo da trebamo koristiti neke module.
Prva vrsta modula s kojima se susrećete su moduli resursa. Oni ne razumiju kakva je vaša infrastruktura, čime se bavite, gdje i kakvi su uvjeti. Upravo su to moduli koje ja, zajedno sa zajednicom otvorenog koda, administriram i koje smo postavili kao početne blokove za izgradnju vaše infrastrukture.
Primjer modula resursa.
Kada pozivamo modul resursa, specificiramo s koje staze trebamo učitati njegov sadržaj.
Označavamo koju verziju želimo preuzeti.
Tu prenosimo hrpu argumenata. To je sve. To je sve što trebamo znati kada koristimo ovaj modul.
Mnogi misle da će sve biti stabilno ako koriste najnoviju verziju. Ali ne. Infrastruktura mora biti verzionirana, moramo jasno odgovoriti na koju verziju je ova ili ona komponenta postavljena.
Ovdje je kod koji se nalazi unutar ovog modula. Modul sigurnosne grupe. Ovdje svitak ide do 640. retka. Stvaranje sigurnosnog resursa u Amazonu u svim mogućim konfiguracijama vrlo je netrivijalan zadatak. Nije dovoljno jednostavno stvoriti sigurnosnu grupu i reći joj koja pravila da joj proslijedi. Bilo bi vrlo jednostavno. Unutar Amazona postoji milijun različitih ograničenja. Na primjer, ako koristite Krajnja točka VPC-a, popis prefiksa, različiti API-ji i pokušava sve to kombinirati sa svime ostalim, onda vam Terraform to ne dopušta. A Amazon API to također ne dopušta. Stoga svu tu strašnu logiku trebamo sakriti u modul i dati korisnički kod koji izgleda upravo ovako.
Korisnik ne mora znati kako je napravljen unutra.
Druga vrsta modula, koja se sastoji od modula resursa, već rješava probleme koji su primjenjiviji na vaše poslovanje. Često je ovo mjesto koje je proširenje za Terraform i postavlja neke krute vrijednosti za oznake, za standarde tvrtke. Tamo također možete dodati funkcionalnost koju vam Terraform trenutno ne dopušta. Ovo je upravo sada. Sada verzija 0.11, koja će uskoro postati prošlost. Ali ipak, pretprocesori, jsonnet, cookiecutter i hrpa drugih stvari su pomoćni mehanizam koji se mora koristiti za punopravni rad.
Zatim ću pokazati neke primjere ovoga.
Infrastrukturni modul se poziva na potpuno isti način.
Naznačen je izvor odakle se preuzima sadržaj.
Hrpa vrijednosti se prosljeđuje i prosljeđuje u ovaj modul.
Zatim, unutar ovog modula, poziva se hrpa modula resursa za stvaranje VPC-a ili Application Load Balancera, ili za stvaranje sigurnosne grupe ili za klaster Elastic Container Service.
Postoje dvije vrste modula. Ovo je važno razumjeti jer većina informacija koje sam grupirao u ovom izvješću nije zapisana u dokumentaciji.
A dokumentacija u Terraformu trenutno je prilično problematična jer samo kaže da postoje te značajke, da ih možete koristiti. Ali ona ne kaže kako koristiti te značajke, zašto ih je bolje koristiti. Stoga jako velik broj ljudi napiše nešto s čim ne može živjeti.
Pogledajmo kako dalje napisati ove module. Zatim ćemo vidjeti kako ih pozvati i kako raditi s kodom.
Terraform registar -
Savjet #0 je da ne pišete module resursa. Većina ovih modula već je napisana za vas. Kao što sam rekao, oni su otvorenog koda, ne sadrže nikakvu vašu poslovnu logiku, nemaju tvrdo kodirane vrijednosti za IP adrese, lozinke itd. Modul je vrlo fleksibilan. I najvjerojatnije je već napisano. Postoji mnogo modula za resurse iz Amazona. Oko 650. I većina ih je dobre kvalitete.
U ovom primjeru, netko vam je došao i rekao: "Želim biti u mogućnosti upravljati bazom podataka. Napravite modul kako bih mogao stvoriti bazu podataka." Osoba ne zna detalje implementacije ni Amazona ni Terraforma. On jednostavno kaže: "Želim upravljati MSSQL-om." Odnosno, mislimo da će pozvati naš modul, proslijediti tip motora tamo i naznačiti vremensku zonu.
I osoba ne bi trebala znati da ćemo stvoriti dva različita resursa unutar ovog modula: jedan za MSSQL, drugi za sve ostalo, samo zato što u Terraform 0.11 ne možete odrediti vrijednosti vremenske zone kao izborne.
A na izlazu iz ovog modula, osoba će moći jednostavno primiti adresu. Neće znati iz koje baze podataka, iz kojeg resursa mi sve to interno stvaramo. Ovo je vrlo važan element prikrivanja. I to se ne odnosi samo na one module koji su javni u otvorenom kodu, već i na one module koje ćete pisati unutar svojih projekata i timova.
Ovo je drugi argument, koji je vrlo važan ako već neko vrijeme koristite Terraform. Imate repozitorij u koji stavljate sve svoje Terraform module za svoju tvrtku. I sasvim je normalno da će s vremenom ovaj projekt narasti na veličinu od jednog ili dva megabajta. Ovo je u redu.
Ali problem je kako Terraform naziva te module. Na primjer, ako pozovete modul za kreiranje svakog pojedinačnog korisnika, Terraform će prvo učitati cijelo spremište, a zatim otići do mape u kojoj se nalazi taj određeni modul. Na taj način ćete svaki put preuzeti jedan megabajt. Ako upravljate sa 100 ili 200 korisnika, tada ćete preuzeti 100 ili 200 megabajta, a zatim otići u tu mapu. Dakle, prirodno ne želite preuzeti hrpu stvari svaki put kada pritisnete "Terraform init".
Za ovaj problem postoje dva rješenja. Prvi je korištenje relativnih putanja. Na taj način u kodu označavate da je mapa lokalna (./). I prije nego bilo što pokrenete, napravite Git klon ovog repozitorija lokalno. Ovako to radite jednom.
Ima, naravno, i dosta loših strana. Na primjer, ne možete koristiti verziju. A s tim je ponekad teško živjeti.
Drugo rješenje. Ako imate puno podmodula i već imate neku vrstu uspostavljenog cjevovoda, onda je tu MBT projekt, koji vam omogućuje da prikupite mnogo različitih paketa iz monorepozitorija i postavite ih na S3. Ovo je jako dobar način. Stoga će datoteka iam-user-1.0.0.zip težiti samo 1 Kb jer je kod za stvaranje ovog resursa vrlo mali. I radit će puno brže.
Razgovarajmo o tome što se ne može koristiti u modulima.
Zašto je ovo zlo u modulima? Najgore je pretpostaviti korisnika. Pretpostavimo da je korisnik opcija provjere autentičnosti davatelja koju mogu koristiti različiti ljudi. Na primjer, svi ćemo asimilirati ulogu. To znači da će Terraform preuzeti tu ulogu. A onda će s ovom ulogom obavljati druge radnje.
A zlo je u tome što ako se Vasya voli spajati na Amazon na jedan način, na primjer, koristeći zadanu varijablu okruženja, a Petya voli koristiti svoj zajednički ključ, koji ima na tajnom mjestu, onda ne možete navesti oba u Terraform. A kako ne bi doživjeli patnju, nema potrebe označavati ovaj blok u modulu. To mora biti naznačeno na višoj razini. To jest, imamo modul resursa, modul infrastrukture i sastav na vrhu. I to bi trebalo biti naznačeno negdje više.
Drugo zlo je opskrbljivač. Ovdje zlo nije tako trivijalno, jer ako napišete kod i on radi za vas, onda možete pomisliti da ako radi, zašto ga onda mijenjati.
Loša je činjenica da prvo ne kontrolirate uvijek kada će se ovaj pružatelj usluga pokrenuti. I drugo, ne kontrolirate što znači aws ec2, tj. govorimo li sad o Linuxu ili Windowsu. Dakle, ne možete napisati nešto što će raditi isto na različitim operativnim sustavima ili za različite korisničke slučajeve.
Najčešći primjer, koji je također naveden u službenoj dokumentaciji, je da ako napišete aws_instance i navedete hrpu argumenata, onda nema ništa loše u tome ako tamo navedete pružatelja usluga “local-exec” i pokrenete svoj ansible- igraonica .
Zapravo, da, nema ništa loše u tome. Ali doslovce uskoro ćete shvatiti da ta stvar s lokalnim izvršenjem ne postoji, na primjer, u launch_configuration.
A kada koristite launch_configuration i želite stvoriti grupu za automatsko skaliranje iz jedne instance, tada u launch_configuration ne postoji koncept "provisioner". Postoji koncept "korisnički podaci".
Stoga je univerzalnije rješenje korištenje korisničkih podataka. I bit će pokrenut ili na samoj instanci, kada je instanca uključena, ili u istim korisničkim podacima, kada grupa za automatsko skaliranje koristi ovu launch_configuration.
Ako ipak želite pokrenuti provider, jer je to komponenta za lijepljenje, kada se kreira jedan resurs, u tom trenutku morate pokrenuti vaš provider, svoju naredbu. Puno je takvih situacija.
A najispravniji resurs za ovo zove se null_resource. Null_resource je lažni resurs koji zapravo nikada nije stvoren. Ne dira ništa, nema API-ja, nema automatskog skaliranja. Ali vam omogućuje kontrolu kada pokrenuti naredbu. U ovom slučaju, naredba se pokreće tijekom kreiranja.
Link
Postoji nekoliko znakova. Neću ulaziti u detalje o svim znakovima. O tome postoji članak. Ali ako ste radili s Terraformom ili koristili tuđe module, onda ste često primijetili da su mnoge module, kao i većinu koda u otvorenom kodu, napisali ljudi za svoje potrebe. Čovjek je to napisao i riješio svoj problem. Stavio sam ga u GitHub, neka živi. Živjet će, ali ako tamo nema dokumentacije i primjera, onda ga nitko neće koristiti. A ako ne postoji funkcionalnost koja vam omogućuje da riješite malo više od svoje specifične zadaće, tada je nitko neće koristiti. Postoji toliko mnogo načina da izgubite korisnike.
Ako želite napisati nešto tako da će ljudi to koristiti, preporučujem da slijedite ove znakove.
To su:
- Dokumentacija i primjeri.
- Potpuna funkcionalnost.
- Razumne zadane vrijednosti.
- Čisti kod.
- Ispitivanja.
Testovi su druga situacija jer ih je dosta teško napisati. Više vjerujem dokumentaciji i primjerima.
Dakle, pogledali smo kako napisati module. Dva su argumenta. Prvo, ono najvažnije, nemoj pisati ako možeš, jer je hrpa ljudi već radila te zadatke prije tebe. I drugo, ako se ipak odlučite, pokušajte ne koristiti pružatelje usluga u modulima i pružateljima usluga.
Ovo je sivi dio dokumentacije. Možda sada mislite: “Nešto nije jasno. Nisam uvjeren." Ali vidjet ćemo za šest mjeseci.
Sada razgovarajmo o tome kako nazvati ove module.
Shvaćamo da naš kod s vremenom raste. Nemamo više jednu datoteku, već imamo 20 datoteka. Sve su u jednoj mapi. Ili možda pet mapa. Možda ih počinjemo nekako raščlanjivati po regijama, po nekim komponentama. Tada shvaćamo da sada imamo neke rudimente sinkronizacije i orkestracije. Odnosno, moramo razumjeti što bismo trebali učiniti ako smo promijenili mrežne resurse, što bismo trebali učiniti s ostatkom naših resursa, kako uzrokovati te ovisnosti itd.
Postoje dvije krajnosti. Prva krajnost je sve u jednom. Imamo jednu glavnu datoteku. Za sada je to bila službena najbolja praksa na web stranici Terraform.
Ali sada je napisano kao zastarjelo i uklonjeno. S vremenom je Terraform zajednica shvatila da je to daleko od najbolje prakse, jer su ljudi počeli koristiti projekt na različite načine. A problema ima. Na primjer, kada na jednom mjestu navedemo sve zavisnosti. Postoje situacije kada kliknemo na “Terraform plan” i dok Terraform ne ažurira stanja svih resursa može proći dosta vremena.
Puno vremena je, na primjer, 5 minuta. Za neke je to puno vremena. Vidio sam slučajeve u kojima je trebalo 15 minuta. AWS API proveo je 15 minuta pokušavajući shvatiti što se događa sa stanjem svakog resursa. Ovo je jako veliko područje.
I, naravno, pojavit će se srodni problem kada želite nešto promijeniti na jednom mjestu, onda pričekate 15 minuta, i to vam daje platno nekih promjena. Pljunuo si, napisao "Da" i nešto je pošlo po zlu. Ovo je vrlo stvaran primjer. Terraform vas ne pokušava zaštititi od problema. Odnosno, napišite što želite. Bit će problema – tvojih problema. Dok vam Terraform 0.11 ni na koji način ne pokušava pomoći. Postoje određena zanimljiva mjesta u 0.12 koja vam omogućuju da kažete: "Vasja, stvarno želiš ovo, možeš li doći k sebi?"
Drugi način je smanjenje tog područja, odnosno pozivi s jednog mjesta mogu biti manje povezani s drugog mjesta.
Jedini problem je što trebate napisati više koda, tj. morate opisati varijable u velikom broju datoteka i to ažurirati. Neki ljudi to ne vole. Meni je to normalno. I neki ljudi misle: "Zašto ovo pisati na različitim mjestima, stavit ću sve na jedno mjesto." To je moguće, ali ovo je druga krajnost.
Kome sve ovo živi na jednom mjestu? Jedan, dva, tri čovjeka, odnosno netko ga koristi.
A tko naziva jednu određenu komponentu, jedan blok ili jedan infrastrukturni modul? Pet do sedam ljudi. Ovo je cool.
Najčešći odgovor je negdje u sredini. Ako je projekt velik, često ćete imati situaciju da nijedno rješenje nije prikladno i da ne funkcionira sve, pa na kraju dobijete mješavinu. U tome nema ništa loše, sve dok razumijete da oboje imaju prednosti.
Ako se nešto promijenilo u stogu VPC i željeli ste primijeniti te promjene na EC2, tj. htjeli ste ažurirati grupu za automatsko skaliranje jer ste imali novu podmrežu, tada ovu vrstu orkestracije ovisnosti nazivam. Postoje neka rješenja: tko što koristi?
Mogu predložiti koja rješenja postoje. Možete koristiti Terraform da učinite magiju, ili možete koristiti makefile da biste koristili Terraform. I vidjeti je li se tamo nešto promijenilo, možete to pokrenuti ovdje.
Kako vam se sviđa ova odluka? Vjeruje li itko da je ovo cool rješenje? Vidim osmijeh, očito su se uvukle sumnje.
Naravno, nemojte ovo pokušavati kod kuće. Terraform nikada nije bio dizajniran za pokretanje iz Terraforma.
Na jednoj prijavi su mi rekli: "Ne, ovo neće uspjeti." Poanta je da ne bi trebalo raditi. Iako izgleda tako impresivno kada možete pokrenuti Terraform iz Terraforma, a zatim Terraform, ali to ne morate učiniti. Terraform uvijek treba započeti vrlo lako.
Ako vam treba orkestracija poziva kada se nešto promijeni na jednom mjestu, tu je Terragrunt.
Terragrunt je uslužni program, dodatak Terraformu, koji vam omogućuje koordinaciju i orkestriranje poziva infrastrukturnim modulima.
Tipična Terraform konfiguracijska datoteka izgleda ovako.
Vi određujete koji određeni modul želite pozvati.
Koje ovisnosti ima modul?
I koje argumente prihvaća ovaj modul. To je sve što treba znati o Terragruntu.
Dokumentacija je tu, a na GitHubu ima 1 zvjezdica. Ali u većini slučajeva to je ono što trebate znati. A to je vrlo lako implementirati u tvrtkama koje tek počinju raditi s Terraformom.
Dakle, orkestracija je Terragrunt. Postoje i druge mogućnosti.
Sada razgovarajmo o tome kako raditi s kodom.
Ako trebate dodati nove značajke svom kodu, to je u većini slučajeva jednostavno. Vi pišete novi resurs, sve je jednostavno.
Ako imate neki resurs koji ste kreirali unaprijed, na primjer, saznali ste za Terraform nakon što ste otvorili AWS račun i želite koristiti resurse koje već imate, tada bi bilo prikladno proširiti svoj modul na ovaj način, tako da podržava korištenje postojećih resursa.
I podržava stvaranje novih resursa pomoću blok resursa.
Na izlazu uvijek vraćamo ID izlaza ovisno o tome što je korišteno.
Drugi vrlo značajan problem u Terraform 0.11 je rad s listama.
Poteškoća je u tome što ako imamo takav popis korisnika.
A kada stvorimo te korisnike koristeći blok resurs, onda sve ide u redu. Prolazimo kroz cijeli popis, stvarajući datoteku za svaki. Sve je u redu. I onda, na primjer, korisnik3, koji je u sredini, treba biti uklonjen odavde, tada će se svi resursi koji su stvoreni nakon njega ponovno stvoriti jer će se indeks promijeniti.
Rad s popisima u okruženju sa statusom. Što je okruženje sa statusom? Ovo je situacija u kojoj se nova vrijednost stvara kada se ovaj resurs stvori. Na primjer, AWS Access Key ili AWS Secret Key, tj. kada kreiramo korisnika, dobivamo novi Access ili Secret Key. I svaki put kada izbrišemo korisnika, ovaj će korisnik imati novi ključ. Ali to nije feng shui, jer korisnik neće htjeti biti prijatelj s nama ako mu kreiramo novog korisnika svaki put kad netko napusti tim.
Ovo je rješenje. Ovo je kod napisan u Jsonnetu. Jsonnet je Googleov jezik za izradu predložaka.
Ova vam naredba omogućuje prihvaćanje ovog predloška i kao izlaz vraća json datoteku koja je napravljena prema vašem predlošku.
Predložak izgleda ovako.
Terraform vam omogućuje rad s HCL-om i Jsonom na isti način, pa ako imate mogućnost generiranja Jsona, možete ga ubaciti u Terraform. Datoteka s nastavkom .tf.json bit će uspješno preuzeta.
I onda radimo s njim kao i obično: terraform init, terramorm apply. I kreiramo dva korisnika.
Sad se ne bojimo hoće li netko otići iz momčadi. Samo ćemo urediti json datoteku. Vasya Pupkin je otišao, Petya Pyatochkin je ostao. Petja Pjatočkin neće dobiti novi ključ.
Integracija Terraforma s drugim alatima zapravo nije Terraformov posao. Terraform je nastao kao platforma za stvaranje resursa i to je to. A sve što kasnije iskrsne nije Terraformova briga. I nema potrebe da ga tu utkate. Tu je Ansible, koji radi sve što trebate.
Ali dolazi do situacija kada želimo proširiti Terraform i pozvati neku naredbu nakon što se nešto završi.
Prvi način. Stvaramo izlaz gdje pišemo ovu naredbu.
Zatim pozivamo ovu naredbu iz izlaza shell terraform i specificiramo vrijednost koju želimo. Dakle, naredba se izvršava sa svim zamijenjenim vrijednostima. Vrlo je udoban.
Drugi način. Ovo je upotreba null_resource ovisno o promjenama u našoj infrastrukturi. Isti lokalni-exe možemo pozvati čim se promijeni ID nekog resursa.
Naravno, sve je to glatko na papiru, jer Amazon, kao i svi drugi javni pružatelji usluga, ima hrpu vlastitih rubnih kućišta.
Najčešći krajnji slučaj je da kada otvorite AWS račun, važno je koje regije koristite; je li ova značajka tamo omogućena; možda ste ga otvorili nakon prosinca 2013.; možda koristite default u VPC itd. Postoje mnoga ograničenja. A Amazon ih je razbacao po dokumentaciji.
Postoji nekoliko stvari koje preporučujem izbjegavati.
Za početak, izbjegavajte sve netajne argumente unutar Terraform plana ili Terraform CLI. Sve se to može staviti ili u datoteku tfvars ili u varijablu okruženja.
Ali ne morate zapamtiti cijelu ovu čarobnu naredbu. Plan terraforme – var i idemo. Prva varijabla je var, druga varijabla je var, treća, četvrta. Najvažnije načelo infrastrukture kao koda koje najčešće koristim je da samim pogledom na kod trebam imati jasno razumijevanje o tome što je tamo raspoređeno, u kojem stanju i s kojim vrijednostima. I tako ne moram čitati dokumentaciju ili pitati Vasju koje je parametre koristio za stvaranje našeg klastera. Samo trebam otvoriti datoteku s ekstenzijom tfvars, koja često odgovara okruženju, i pogledati sve tamo.
Također, nemojte koristiti ciljne argumente za smanjenje opsega. Za to je puno lakše koristiti male infrastrukturne module.
Također, nema potrebe ograničavati i povećavati paralelizam. Ako imam 150 resursa i želim povećati Amazonov paralelizam sa zadanih 10 na 100, tada će najvjerojatnije nešto poći po zlu. Ili bi sada moglo proći dobro, ali kada Amazon kaže da obavljate previše poziva, bit ćete u nevolji.
Terraform će pokušati ponovno pokrenuti većinu ovih problema, ali nećete postići gotovo ništa. Parallelism=1 je važna stvar koju treba koristiti ako naiđete na neku pogrešku unutar AWS API-ja ili unutar Terraform providera. Zatim trebate navesti: parallelism=1 i pričekati dok Terraform ne završi jedan poziv, zatim drugi, pa treći. On će ih lansirati jednog po jednog.
Ljudi me često pitaju: "Zašto mislim da su Terraform radni prostori zli?" Vjerujem da je načelo infrastrukture kao koda vidjeti koja je infrastruktura stvorena i s kojim vrijednostima.
Radne prostore nisu izradili korisnici. To ne znači da su korisnici u problemima GitHuba napisali da ne možemo živjeti bez Terraform radnih prostora. Ne ne ovako. Terraform Enterprise je komercijalno rješenje. Terraform iz HashiCorpa odlučio je da nam trebaju radni prostori, pa smo ga arhivirali. Mnogo mi je lakše staviti ga u zasebnu mapu. Tada će biti malo više datoteka, ali će biti jasnije.
Kako raditi s kodom? Zapravo, rad s popisima je jedina muka. I uzmi Terraform lakše. Ovo nije stvar koja će sve učiniti sjajno za vas. Ne treba tamo gurati sve što piše u dokumentaciji.
Tema izvješća je napisana "za budućnost". Govorit ću o ovome vrlo kratko. Za budućnost to znači da će 0.12 uskoro biti objavljen.
0.12 je tona novih stvari. Ako dolazite iz redovnog programiranja, onda vam nedostaju razni dinamički blokovi, petlje, ispravne i uvjetne operacije usporedbe, gdje se lijeva i desna strana ne računaju istovremeno, već ovisno o situaciji. Puno ti fali pa će ti 0.12 to riješiti.
Ali! Ako pišete manje i jednostavnije, koristeći gotove module i rješenja trećih strana, tada nećete morati čekati i nadati se da će 0.12 doći i sve popraviti umjesto vas.
Hvala na izvješću! Govorili ste o infrastrukturi kao kodu i doslovno rekli jednu riječ o testovima. Jesu li testovi potrebni u modulima? Čija je to odgovornost? Trebam li to sam napisati ili je to odgovornost modula?
Sljedeća godina bit će puna izvješća da smo odlučili sve testirati. Što testirati najveće je pitanje. Postoji puno ovisnosti, puno ograničenja od različitih pružatelja usluga. Kad razgovaramo ti i ja i kažeš: "Trebaju mi testovi", onda ja pitam: "Što ćeš testirati?" Kažete da ćete testirati u svojoj regiji. Onda kažem da to ne funkcionira u mojoj regiji. Odnosno oko toga se nećemo moći ni dogovoriti. Da ne spominjem da ima puno tehničkih problema. Odnosno kako te testove napisati da budu adekvatni.
Aktivno istražujem ovu temu, tj. kako automatski generirati testove na temelju infrastrukture koju ste napisali. Odnosno, ako ste vi napisali ovaj kod, onda ga moram pokrenuti, na temelju toga mogu kreirati testove.
je jedna od najčešće spominjanih biblioteka koja vam omogućuje pisanje integracijskih testova za Terraform. Ovo je jedan od uslužnih programa. Više volim DSL tip, na primjer, rspec.
Anton, hvala na izvješću! Moje ime je Valery. Da postavim jedno malo filozofsko pitanje. Postoji, uvjetno, provizija, postoji raspoređivanje. Omogućavanje stvara moju infrastrukturu, u implementaciji je punimo nečim korisnim, na primjer, poslužiteljima, aplikacijama itd. I u mojoj je glavi da je Terraform više za pružanje usluga, a Ansible je više za implementaciju, jer je Ansible također za fizičku infrastrukturu. omogućuje instalaciju nginx, Postgres. Ali u isto vrijeme, čini se da Ansible dopušta pružanje, na primjer, resursa Amazona ili Googlea. Ali Terraform vam također omogućuje da postavite neki softver pomoću njegovih modula. S vaše točke gledišta, postoji li neka granica između Terraforma i Ansiblea, gdje i što je bolje koristiti? Ili, na primjer, mislite da je Ansible već smeće, trebali biste pokušati koristiti Terraform za sve?
Dobro pitanje, Valery. Smatram da Terraform nije mijenjao namjenu od 2014. godine. Stvoren je za infrastrukturu i umro je za infrastrukturu. I dalje smo imali i imat ćemo potrebu za Ansible upravljanjem konfiguracijom. Izazov je što postoje korisnički podaci unutar launch_configuration. I tu povučete Ansible, itd. Ovo je standardna razlika koja mi se najviše sviđa.
Ako govorimo o lijepoj infrastrukturi, onda postoje uslužni programi poput Packera koji prikupljaju ovu sliku. Zatim Terraform koristi izvor podataka da pronađe ovu sliku i ažurira njezinu launch_configuration. Odnosno, na ovaj je način cjevovod da prvo povučemo Tracker, a zatim Terraform. A ako dođe do izgradnje, tada dolazi do nove promjene.
Zdravo! Hvala na izvješću! Moje ime je Misha, tvrtka RBS. Ansible možete pozvati putem pružatelja usluga prilikom izrade resursa. Ansible također ima temu pod nazivom dinamički inventar. I možete prvo pozvati Terraform, a zatim pozvati Ansible, koji će uzeti resurse od države i izvršiti ga. Što je bolje?
Ljudi koriste oboje s jednakim uspjehom. Čini mi se da je dinamički popis u Ansibleu zgodna stvar, ako ne govorimo o grupi za automatsko skaliranje. Budući da u grupi za automatsko skaliranje već imamo vlastiti alat, koji se zove launch_configuration. U launch_configuration bilježimo sve što treba pokrenuti kada kreiramo novi resurs. Stoga je s Amazonom korištenje dinamičkog inventara i čitanje Terraform ts datoteke, po mom mišljenju, pretjerano. A ako koristite druge alate gdje ne postoji koncept "grupe za automatsko skaliranje", na primjer, koristite DigitalOcean ili nekog drugog pružatelja usluga gdje nema grupe za automatsko skaliranje, tada ćete tamo morati ručno povući API, pronaći IP adrese, stvoriti datoteku dinamičkog popisa, a Ansible će već lutati kroz nju. Odnosno za Amazon postoji launch_configuration, a za sve ostalo postoji dinamički inventar.
Izvor: www.habr.com