Veliko ljudi pozna in uporablja Terraform pri svojem vsakdanjem delu, vendar najboljše prakse zanj še niso oblikovane. Vsaka ekipa mora izumiti svoje pristope in metode.
Vaša infrastruktura se skoraj zagotovo začne preprosto: nekaj virov + nekaj razvijalcev. Sčasoma raste v vse možne smeri. Ali najdete načine za združevanje virov v module Terraform, organiziranje kode v mape in kaj še lahko gre narobe? (slavne zadnje besede)
Čas teče in čutite, da je vaša infrastruktura vaš novi hišni ljubljenček, toda zakaj? Skrbijo vas nerazložljive spremembe v infrastrukturi, bojite se dotikati infrastrukture in kode – posledično odložite nove funkcionalnosti ali zmanjšate kakovost...
Po treh letih upravljanja zbirke modulov skupnosti Terraform za AWS na Githubu in dolgoročnega vzdrževanja Terraforma v produkciji je Anton Babenko pripravljen deliti svoje izkušnje: kako napisati module TF, da v prihodnosti ne bo škodilo.
Do konca predavanja bodo udeleženci bolje seznanjeni z načeli upravljanja virov v Terraformu, najboljšimi praksami, povezanimi z moduli v Terraformu, in nekaterimi načeli neprekinjene integracije, povezanimi z upravljanjem infrastrukture.
Disclaimer: Ugotavljam, da je to poročilo datirano v november 2018 – dve leti sta že minili. Različica Terraform 2, obravnavana v poročilu, ni več podprta. V zadnjih 0.11 letih sta bili izdani 2 novi izdaji, ki vsebujeta veliko novosti, izboljšav in sprememb. Bodite pozorni na to in preverite dokumentacijo.
Reference:
- +
- — koda in dokumentacija za samodejno oblikovanje
- — generator modulov Terraform (WIP)
- — Generator kod terraform iz vizualnih diagramov (WIP)
- www.terraform-best-practices.com
- (Nove objave so na moji osebni spletni strani www.antonbabenko.com/)
- @antonbabenko - Twitter in kup različnih slackov
Moje ime je Anton Babenko. Nekateri ste verjetno uporabili kodo, ki sem jo napisal. Zdaj bom o tem govoril bolj samozavestno kot kdaj koli prej, saj imam dostop do statistike.
Delam na Terraformu in od leta 2015 aktivno sodelujem in prispevam k velikemu številu odprtokodnih projektov, povezanih s Terraformom in Amazonom.
Od takrat sem napisal dovolj kode, da jo predstavim na zanimiv način. In zdaj vam bom poskušal povedati o tem.
Govoril bom o zapletenosti in posebnostih dela s Terraformom. Toda to pravzaprav ni tema HighLoada. In zdaj vam bo jasno zakaj.
Čez čas sem začel pisati module Terraform. Uporabniki so pisali vprašanja, jaz sem jih prepisal. Nato sem napisal različne pripomočke za formatiranje kode z uporabo kljuke pred potrditvijo itd.
Bilo je veliko zanimivih projektov. Všeč mi je generiranje kode, ker mi je všeč, da računalnik opravi vse več dela zame in za programerja, zato trenutno delam na generatorju kode Terraform iz vizualnih diagramov. Morda ste jih nekateri že videli. To so lepe škatle s puščicami. In mislim, da je super, če lahko kliknete gumb »Izvozi« in dobite vse kot kodo.
Jaz sem iz Ukrajine. Že vrsto let živim na Norveškem.
Prav tako so bile informacije za to poročilo zbrane od ljudi, ki poznajo moje ime in me najdejo na družbenih omrežjih. Skoraj vedno imam isti vzdevek.
Kot sem že omenil, sem glavni vzdrževalec modulov Terraform AWS, ki je eden največjih repozitorijev na GitHubu, kjer gostimo module za najpogostejša opravila: VPC, Autoscaling, RDS.
In to, kar ste zdaj slišali, je najbolj osnovno. Če dvomite, da razumete, kaj je Terraform, potem je bolje, da svoj čas preživite kje drugje. Tukaj bo veliko strokovnih izrazov. In brez obotavljanja sem razglasil raven poročila za najvišjo. To pomeni, da lahko govorim z vsemi možnimi izrazi brez velike razlage.
Terraform se je pojavil leta 2014 kot pripomoček, ki vam je omogočil pisanje, načrtovanje in upravljanje infrastrukture kot kode. Ključni koncept tukaj je »infrastruktura kot koda«.
Vsa dokumentacija je, kot sem rekel, zapisana . Upam, da večina ljudi pozna to stran in je prebrala dokumentacijo. Če je tako, potem ste na pravem mestu.
Tako izgleda običajna konfiguracijska datoteka Terraform, kjer najprej definiramo nekaj spremenljivk.
V tem primeru definiramo "aws_region".
Nato opišemo, katere vire želimo ustvariti.
Zaženemo nekaj ukazov, zlasti »terraform init«, da naložimo odvisnosti in ponudnike.
Zaženemo ukaz »terraform apply«, da preverimo, ali se navedena konfiguracija ujema z viri, ki smo jih ustvarili. Ker še nismo ustvarili ničesar, nas Terraform poziva, da ustvarimo te vire.
To potrjujemo. Tako ustvarimo vedro, imenovano morski polž.
Obstaja tudi več podobnih pripomočkov. Mnogi od vas, ki uporabljate Amazon, poznate AWS CloudFormation ali Google Cloud Deployment Manager ali Azure Resource Manager. Vsak od njih ima svojo izvedbo neke vrste za upravljanje virov znotraj vsakega od teh javnih ponudnikov v oblaku. Terraform je še posebej uporaben, ker omogoča upravljanje preko 100 ponudnikov. (Več podrobnosti )
Cilji, ki jim Terraform sledi že od vsega začetka:
- Terraform ponuja enoten pogled na vire.
- Omogoča podporo vsem sodobnim platformam.
- In Terraform je bil od vsega začetka zasnovan kot pripomoček, ki vam omogoča varno in predvidljivo spreminjanje infrastrukture.
Leta 2014 je beseda »predvidljivo« v tem kontekstu zvenela zelo nenavadno.
Terraform je univerzalni pripomoček. Če imate API, potem lahko nadzirate popolnoma vse:
- Za upravljanje vsega, kar želite, lahko uporabite več kot 120 ponudnikov.
- Terraform lahko na primer uporabite za opis dostopa do repozitorijev GitHub.
- V Jiri lahko celo ustvarite in zaprete hrošče.
- Upravljate lahko meritve New Relic.
- Če res želite, lahko ustvarite datoteke v dropboxu.
Vse to dosežemo s ponudniki Terraform, ki imajo odprt API, ki ga je mogoče opisati v Go.
Recimo, da smo začeli uporabljati Terraform, prebrali nekaj dokumentacije na spletnem mestu, pogledali nekaj videoposnetkov in začeli pisati main.tf, kot sem pokazal na prejšnjih diapozitivih.
In vse je super, imate datoteko, ki ustvari VPC.
Če želite ustvariti VPC, potem določite približno teh 12 vrstic. Opišite, v kateri regiji želite ustvariti, kateri cidr_block naslovov IP uporabiti. To je vse.
Seveda bo projekt postopoma rasel.
Tam boste dodali ogromno novih stvari: vire, vire podatkov, integrirali se boste z novimi ponudniki, nenadoma boste želeli uporabiti Terraform za upravljanje uporabnikov v vašem računu GitHub itd. Morda boste želeli uporabiti različni ponudniki DNS, prečka vse. Terraform to olajša.
Poglejmo si naslednji primer.
Internet_gateway dodajate postopoma, ker želite, da imajo viri iz vašega VPC dostop do interneta. To je dobra ideja.
Rezultat je ta main.tf:
To je zgornji del main.tf.
To je spodnji del main.tf.
Nato dodate podomrežje. Ko boste želeli dodati NAT prehode, poti, usmerjevalne tabele in kopico drugih podomrežij, ne boste imeli 38 vrstic, ampak približno 200-300 vrstic.
To pomeni, da vaša datoteka main.tf postopoma raste. In pogosto ljudje dajo vse v eno datoteko. 10-20 Kb se prikaže v main.tf. Predstavljajte si, da je 10-20 Kb besedilna vsebina. In vse je povezano z vsem. S tem postopoma postaja težko delati. 10-20 Kb je dober uporabniški primer, včasih več. In ljudje ne mislijo vedno, da je to slabo.
Kot pri običajnem programiranju, torej ne infrastrukture kot kode, smo navajeni uporabljati kup različnih razredov, paketov, modulov, skupin. Terraform vam omogoča, da naredite približno enako.
- Koda raste.
- Vse večja je tudi odvisnost med viri.
In imamo veliko, veliko potrebo. Zavedamo se, da tako ne moremo več živeti. Naša koda postaja neizmerna. 10-20 Kb seveda ni veliko, vendar govorimo samo o omrežnem skladu, torej imate samo dodane omrežne vire. Ne govorimo o Application Load Balancerju, razmestitvenem grozdu ES, Kubernetesu itd., kjer je mogoče enostavno vtkati 100 Kb. Če si vse to zapišete, boste zelo kmalu izvedeli, da Terraform ponuja Terraform module.
Moduli Terraform so samostojna konfiguracija Terraform, ki se upravlja kot skupina. To je vse, kar morate vedeti o modulih Terraform. Sploh niso pametni, ne dovolijo vam, da naredite kakršne koli zapletene povezave glede na nekaj. Vse to pade na ramena razvijalcev. Se pravi, to je samo nekakšna konfiguracija Terraform, ki ste jo že napisali. In lahko ga preprosto pokličete kot skupino.
Zato poskušamo razumeti, kako bomo optimizirali naših 10-20-30 Kb kode. Postopoma ugotavljamo, da moramo uporabljati nekatere module.
Prva vrsta modulov, s katerimi se srečate, so moduli virov. Ne razumejo, kakšna je vaša infrastruktura, s čim se ukvarjate, kje in kakšni so pogoji. To so točno tisti moduli, ki jih skupaj z odprtokodno skupnostjo upravljam in ki smo jih postavili kot začetne gradnike vaše infrastrukture.
Primer modula virov.
Ko pokličemo modul virov, določimo, s katere poti naj naložimo njegovo vsebino.
Označimo, katero različico želimo prenesti.
Tam posredujemo kup argumentov. To je vse. To je vse, kar moramo vedeti, ko uporabljamo ta modul.
Mnogi mislijo, da bo vse stabilno, če bodo uporabljali najnovejšo različico. Vendar ne. Infrastruktura mora biti verzionirana, jasno moramo odgovoriti, v katero različico je bila nameščena ta ali ona komponenta.
Tukaj je koda, ki je znotraj tega modula. Modul varnostne skupine. Tukaj gre drsenje do 640. vrstice. Ustvarjanje varnostnega vira v Amazonu v vseh možnih konfiguracijah je zelo nepomembna naloga. Ni dovolj preprosto ustvariti varnostno skupino in ji povedati, katera pravila naj ji posreduje. Bilo bi zelo preprosto. V Amazonu obstaja milijon različnih omejitev. Na primer, če uporabljate Končna točka VPC, seznam predpon, različni API-ji in poskuša vse to združiti z vsem ostalim, potem vam Terraform tega ne dovoli. In tudi Amazon API tega ne dovoljuje. Zato moramo vso to strašno logiko skriti v modul in dati uporabniško kodo, ki izgleda takole.
Uporabniku ni treba vedeti, kako je narejeno v notranjosti.
Druga vrsta modulov, ki je sestavljena iz modulov virov, že rešuje probleme, ki so bolj uporabni za vaše podjetje. Pogosto je to mesto, ki je razširitev za Terraform in določa nekatere toge vrednosti za oznake, za standarde podjetja. Tam lahko dodate tudi funkcionalnost, ki vam je Terraform trenutno ne dovoljuje. To je prav zdaj. Zdaj različica 0.11, ki bo kmalu postala preteklost. Še vedno pa so predprocesorji, jsonnet, piškotki in kup drugih stvari pomožni mehanizem, ki ga je treba uporabiti za polno delo.
Nato bom pokazal nekaj primerov tega.
Infrastrukturni modul se kliče na povsem enak način.
Naveden je vir, od koder želite prenesti vsebino.
Veliko vrednosti je posredovanih in posredovanih v ta modul.
Nato se znotraj tega modula pokliče kup modulov virov za ustvarjanje VPC ali izravnalnika obremenitve aplikacij ali za ustvarjanje varnostne skupine ali za gručo Elastic Container Service.
Obstajata dve vrsti modulov. To je pomembno razumeti, ker večina informacij, ki sem jih združil v to poročilo, ni zapisana v dokumentaciji.
In dokumentacija v Terraformu je zdaj precej problematična, ker samo pravi, da te funkcije obstajajo, da jih lahko uporabljate. Vendar ne pove, kako uporabljati te funkcije, zakaj jih je bolje uporabljati. Zato zelo veliko ljudi napiše nekaj, s čimer ne more živeti.
V nadaljevanju si poglejmo, kako napisati te module. Nato bomo videli, kako jih poklicati in kako delati s kodo.
Register Terraform -
Nasvet št. 0 je, da ne pišete modulov virov. Večina teh modulov je že napisanih za vas. Kot sem rekel, so odprtokodni, ne vsebujejo nobene vaše poslovne logike, nimajo trdo kodiranih vrednosti za naslove IP, gesla itd. Modul je zelo prilagodljiv. In najverjetneje je že napisano. Obstaja veliko modulov za vire iz Amazona. Približno 650. In večina jih je kakovostnih.
V tem primeru je nekdo prišel k vam in rekel: »Želim biti sposoben upravljati bazo podatkov. Ustvari modul, da bom lahko ustvaril zbirko podatkov." Oseba ne pozna podrobnosti izvajanja niti Amazona niti Terraforma. Preprosto reče: "Želim upravljati MSSQL." To pomeni, da bo poklical naš modul, tja posredoval vrsto motorja in navedel časovni pas.
In oseba ne bi smela vedeti, da bomo znotraj tega modula ustvarili dva različna vira: enega za MSSQL, drugega za vse ostalo, samo zato, ker v Terraform 0.11 ne morete določiti vrednosti časovnega pasu kot neobvezne.
In na izhodu iz tega modula bo oseba lahko preprosto prejela naslov. Ne bo vedel, iz katere baze, iz katerega vira ustvarjamo vse to interno. To je zelo pomemben element prikrivanja. In to ne velja samo za tiste module, ki so javni v odprti kodi, ampak tudi za tiste module, ki jih boste pisali znotraj svojih projektov in skupin.
To je drugi argument, ki je zelo pomemben, če že nekaj časa uporabljate Terraform. Imate repozitorij, v katerega shranite vse module Terraform za vaše podjetje. In povsem normalno je, da bo sčasoma ta projekt zrasel na velikost enega ali dveh megabajtov. To je v redu.
Toda težava je v tem, kako Terraform imenuje te module. Na primer, če pokličete modul za ustvarjanje vsakega posameznega uporabnika, bo Terraform najprej naložil celotno skladišče in se nato pomaknil do mape, kjer se nahaja določen modul. Tako boste vsakič prenesli en megabajt. Če upravljate 100 ali 200 uporabnikov, boste prenesli 100 ali 200 megabajtov in nato šli v to mapo. Torej seveda ne želite prenesti kopice stvari vsakič, ko pritisnete "Terraform init".
Za to težavo obstajata dve rešitvi. Prvi je uporaba relativnih poti. Tako v kodi označite, da je mapa lokalna (./). In preden karkoli zaženete, naredite Git klon tega repozitorija lokalno. Na ta način to storite enkrat.
Slabosti pa je seveda veliko. Na primer, ne morete uporabljati različic. In s tem je včasih težko živeti.
Druga rešitev. Če imate veliko podmodulov in že imate nekakšen vzpostavljen cevovod, potem je tu projekt MBT, ki vam omogoča, da zberete veliko različnih paketov iz monorepozitorija in jih naložite v S3. To je zelo dober način. Tako bo datoteka iam-user-1.0.0.zip tehtala samo 1 Kb, ker je koda za ustvarjanje tega vira zelo majhna. In delovalo bo veliko hitreje.
Pogovorimo se o tem, česa ni mogoče uporabiti v modulih.
Zakaj je to zlo v modulih? Najslabše je prevzeti uporabnika. Predpostavimo, da je uporabnik možnost preverjanja pristnosti ponudnika, ki jo lahko uporabljajo različni ljudje. Na primer, vsi bomo asimilirali vlogo. To pomeni, da bo Terraform prevzel to vlogo. In potem bo s to vlogo izvajal druga dejanja.
In zlo je v tem, da če se Vasya rad poveže z Amazonom na en način, na primer z uporabo privzete spremenljivke okolja, in Petya rad uporablja svoj skupni ključ, ki ga ima na skrivnem mestu, potem ne morete določiti obojega v Terraform. In da ne bi doživeli trpljenja, tega bloka v modulu ni treba navesti. To mora biti navedeno na višji ravni. To pomeni, da imamo modul virov, infrastrukturni modul in sestavo na vrhu. In to bi moralo biti označeno nekje višje.
Drugo zlo je oskrbovalec. Tukaj zlo ni tako nepomembno, kajti če pišete kodo in deluje za vas, potem lahko mislite, da če deluje, zakaj bi jo potem spreminjali.
Slabost je v tem, da najprej ne nadzorujete vedno, kdaj se bo ta ponudnik zagnal. In drugič, ne nadzorujete, kaj pomeni aws ec2, tj. ali govorimo o Linuxu ali Windowsih. Torej ne morete napisati nečesa, kar bo enako delovalo na različnih operacijskih sistemih ali za različne uporabniške primere.
Najpogostejši primer, ki je naveden tudi v uradni dokumentaciji, je, da če napišete aws_instance in podate kup argumentov, potem ni nič narobe s tem, če tam podate ponudnika “local-exec” in zaženete svoj ansible- igrana knjiga.
Pravzaprav ja, s tem ni nič narobe. Toda dobesedno kmalu boste ugotovili, da ta stvar local-exec ne obstaja, na primer v launch_configuration.
In ko uporabljate launch_configuration in želite ustvariti skupino za samodejno skaliranje iz enega primerka, potem v launch_configuration ni pojma »provisioner«. Obstaja koncept "uporabniških podatkov".
Zato je bolj univerzalna rešitev uporaba uporabniških podatkov. In zagnal se bo na samem primerku, ko je primerek vklopljen, ali v istih uporabniških podatkih, ko skupina za samodejno skaliranje uporabi to launch_configuration.
Če še vedno želite zagnati ponudnika, ker gre za komponento lepljenja, ko je en vir ustvarjen, morate v tistem trenutku zagnati svojega ponudnika, svoj ukaz. Takih situacij je veliko.
In najbolj pravilen vir za to se imenuje null_resource. Null_resource je navidezni vir, ki ni nikoli dejansko ustvarjen. Ne dotika se ničesar, nobenega API-ja, nobenega samodejnega skaliranja. Vendar vam omogoča nadzor, kdaj zagnati ukaz. V tem primeru se ukaz izvaja med ustvarjanjem.
Povezava
Znakov je več. Ne bom se spuščal v vse znake v podrobnosti. Obstaja članek o tem. Toda če ste delali s Terraformom ali uporabljali module drugih ljudi, potem ste pogosto opazili, da so veliko modulov, tako kot večino odprtokodne kode, napisali ljudje za svoje potrebe. Človek je to napisal in rešil svoj problem. Zataknil sem ga v GitHub, naj živi. Živel bo, a če tam ni dokumentacije in primerov, ga nihče ne bo uporabljal. In če ni nobene funkcionalnosti, ki bi vam omogočala, da rešite malo več kot svojo specifično nalogo, potem je tudi nihče ne bo uporabil. Obstaja toliko načinov, kako izgubiti uporabnike.
Če želite nekaj napisati, da bodo ljudje to uporabljali, priporočam, da sledite tem znakom.
So:
- Dokumentacija in primeri.
- Popolna funkcionalnost.
- Razumne privzete vrednosti.
- Čista koda.
- Testi.
Testi so drugačna situacija, ker jih je precej težko napisati. Bolj verjamem v dokumentacijo in primere.
Torej, pogledali smo, kako napisati module. Obstajata dva argumenta. Prvi, ki je najpomembnejši, je, da ne pišeš, če lahko, ker je pred tabo te naloge opravilo že kup ljudi. In drugič, če se še vedno odločite, poskusite ne uporabljati ponudnikov v modulih in ponudnikih.
To je sivi del dokumentacije. Morda zdaj razmišljate: »Nekaj ni jasno. Nisem prepričan." Bomo pa videli čez šest mesecev.
Zdaj pa se pogovorimo o tem, kako poklicati te module.
Zavedamo se, da naša koda sčasoma raste. Nimamo več ene datoteke, imamo že 20 datotek. Vsi so v eni mapi. Ali morda pet map. Mogoče jih začnemo nekako razčlenjevati po regijah, po nekaterih komponentah. Potem razumemo, da imamo zdaj nekaj zametkov sinhronizacije in orkestracije. To pomeni, da moramo razumeti, kaj bi morali storiti, če bi spremenili omrežne vire, kaj bi morali storiti s preostalimi našimi viri, kako povzročiti te odvisnosti itd.
Obstajata dve skrajnosti. Prva skrajnost je vse v enem. Imamo eno glavno datoteko. Zaenkrat je bila to uradna najboljša praksa na spletni strani Terraform.
Toda zdaj je zapisano kot zastarelo in odstranjeno. Sčasoma je skupnost Terraform ugotovila, da to še zdaleč ni najboljša praksa, saj so ljudje začeli projekt uporabljati na različne načine. In obstajajo težave. Na primer, ko na enem mestu navedemo vse odvisnosti. Obstajajo situacije, ko kliknemo “Terraform plan” in dokler Terraform ne posodobi stanja vseh virov, lahko preteče veliko časa.
Veliko časa je na primer 5 minut. Za nekatere je to veliko časa. Videl sem primere, ko je trajalo 15 minut. API AWS je 15 minut poskušal ugotoviti, kaj se dogaja s stanjem vsakega vira. To je zelo veliko območje.
In seveda se bo pojavila sorodna težava, ko želite nekaj spremeniti na enem mestu, potem počakate 15 minut in vam prikaže platno nekaterih sprememb. Pljunil si, napisal "Da" in nekaj je šlo narobe. To je zelo resničen primer. Terraform vas ne poskuša zaščititi pred težavami. Se pravi, napišite, kar želite. Težave bodo - vaše težave. Medtem ko vam Terraform 0.11 na noben način ne poskuša pomagati. Obstaja nekaj zanimivih mest v 0.12, ki vam omogočajo, da rečete: "Vasja, res si želiš tega, ali lahko prideš k sebi?"
Drugi način je zmanjšanje tega območja, to pomeni, da so lahko klici z enega mesta manj povezani z drugega mesta.
Edina težava je, da morate napisati več kode, tj. spremenljivke morate opisati v velikem številu datotek in to posodobiti. Nekaterim to ni všeč. To je zame normalno. In nekateri si mislijo: "Zakaj bi to pisal na različnih mestih, vse bom dal na eno mesto." To je možno, vendar je to druga skrajnost.
Komu vse to živi na enem mestu? En, dva, trije ljudje, torej nekdo ga uporablja.
In kdo imenuje eno določeno komponento, en blok ali en infrastrukturni modul? Pet do sedem ljudi. To je kul.
Najpogostejši odgovor je nekje na sredini. Če je projekt velik, boste pogosto imeli situacijo, ko nobena rešitev ni primerna in ne deluje vse, tako da na koncu dobite mešanico. S tem ni nič narobe, če razumete, da imata oboje prednosti.
Če se je nekaj spremenilo v skladu VPC in ste te spremembe želeli uporabiti za EC2, tj. želeli ste posodobiti skupino za samodejno skaliranje, ker ste imeli novo podomrežje, potem imenujem to vrsto orkestracije odvisnosti. Obstaja nekaj rešitev: kdo kaj uporablja?
Lahko predlagam, kakšne rešitve obstajajo. Za čarovnijo lahko uporabite Terraform ali pa uporabite makefile za uporabo Terraforma. In preverite, ali se je tam kaj spremenilo, lahko ga zaženete tukaj.
Kako vam je všeč ta odločitev? Ali kdo verjame, da je to kul rešitev? Vidim nasmeh, očitno so se prikradli dvomi.
Seveda tega ne poskušajte doma. Terraform ni bil nikoli zasnovan za vodenje iz Terraforma.
Ob enem poročilu so mi rekli: "Ne, to ne bo šlo." Bistvo je, da ne bi smelo delovati. Čeprav je videti tako impresivno, ko lahko zaženete Terraform iz Terraforma in nato Terraform, tega ne bi smeli storiti. Terraform se mora vedno začeti zelo enostavno.
Če potrebujete orkestracijo klicev, ko se na enem mestu kaj spremeni, potem je tu Terragrunt.
Terragrunt je pripomoček, dodatek za Terraform, ki vam omogoča usklajevanje in orkestriranje klicev infrastrukturnih modulov.
Tipična konfiguracijska datoteka Terraform je videti takole.
Določite, kateri določen modul želite poklicati.
Kakšne odvisnosti ima modul?
In katere argumente sprejema ta modul. To je vse, kar je treba vedeti o Terragruntu.
Dokumentacija je tam in na GitHubu je 1 zvezdic. Toda v večini primerov je to tisto, kar morate vedeti. In to je zelo enostavno implementirati v podjetjih, ki šele začenjajo delati s Terraformom.
Orkestracija je torej Terragrunt. Obstajajo še druge možnosti.
Zdaj pa se pogovorimo o tem, kako delati s kodo.
Če morate svoji kodi dodati nove funkcije, je to v večini primerov enostavno. Pišete nov vir, vse je preprosto.
Če imate vir, ki ste ga ustvarili vnaprej, na primer, ste izvedeli za Terraform, potem ko ste odprli račun AWS in želite uporabiti vire, ki jih že imate, potem bi bilo primerno razširiti svoj modul na ta način, tako da podpira uporabo obstoječih virov.
In podprl ustvarjanje novih virov z uporabo blokovnega vira.
Na izhodu vedno vrnemo izhodni ID, odvisno od tega, kaj je bilo uporabljeno.
Druga zelo pomembna težava v Terraform 0.11 je delo s seznami.
Težava je v tem, da če imamo tak seznam uporabnikov.
In ko te uporabnike ustvarimo z uporabo blokovnega vira, gre vse v redu. Pregledamo celoten seznam in za vsakega ustvarimo datoteko. Vse je vredu. In potem je treba na primer uporabnika3, ki je na sredini, odstraniti od tukaj, potem bodo vsi viri, ki so bili ustvarjeni za njim, znova ustvarjeni, ker se bo indeks spremenil.
Delo s seznami v okolju z ohranjanjem stanja. Kaj je okolje s stanjem? To je situacija, ko se ob ustvarjanju tega vira ustvari nova vrednost. Na primer AWS Access Key ali AWS Secret Key, torej ko ustvarimo uporabnika, prejmemo nov Access ali Secret Key. In vsakič, ko izbrišemo uporabnika, bo ta uporabnik imel nov ključ. Ampak to ni feng shui, saj uporabnik ne bo želel biti prijatelj z nami, če mu ustvarimo novega uporabnika vsakič, ko nekdo zapusti ekipo.
To je rešitev. To je koda, napisana v Jsonnetu. Jsonnet je Googlov jezik za predloge.
Ta ukaz vam omogoča, da sprejmete to predlogo in kot izhod vrne datoteko json, ki je narejena v skladu z vašo predlogo.
Predloga izgleda takole.
Terraform vam omogoča delo s HCL in Json na enak način, tako da, če imate možnost ustvariti Json, ga lahko vstavite v Terraform. Datoteka s pripono .tf.json bo uspešno prenesena.
In potem delamo z njim kot običajno: terraform init, terramorm apply. In ustvarimo dva uporabnika.
Zdaj nas ni več strah, če bo kdo zapustil ekipo. Samo uredili bomo datoteko json. Vasya Pupkin je odšel, Petya Pyatochkin je ostal. Petya Pyatochkin ne bo prejel novega ključa.
Integracija Terraforma z drugimi orodji pravzaprav ni Terraformova naloga. Terraform je bil ustvarjen kot platforma za ustvarjanje virov in to je to. In vse, kar pride kasneje, ni Terraformova skrb. In tam ga ni treba vpletati. Obstaja Ansible, ki naredi vse, kar potrebujete.
Toda pride do situacij, ko želimo razširiti Terraform in pokličemo nek ukaz, potem ko je nekaj dokončano.
Prvi način. Ustvarimo izhod, kamor zapišemo ta ukaz.
Nato pokličemo ta ukaz iz izhoda shell terraform in podamo vrednost, ki jo želimo. Tako se ukaz izvede z vsemi zamenjanimi vrednostmi. Je zelo udobno.
Drugi način. To je uporaba null_resource glede na spremembe v naši infrastrukturi. Isti lokalni exe lahko pokličemo takoj, ko se ID nekega vira spremeni.
Seveda je na papirju vse gladko, saj ima Amazon, tako kot vsi drugi javni ponudniki, kup svojih edge casejev.
Najpogostejši robni primer je, da ko odprete račun AWS, je pomembno, katere regije uporabljate; ali je ta funkcija tam omogočena; morda ste ga odprli po decembru 2013; morda uporabljate privzeto v VPC itd. Obstaja veliko omejitev. In Amazon jih je raztresel po vsej dokumentaciji.
Nekaj stvari priporočam, da se jim izognete.
Za začetek se izogibajte vsem neskrivnim argumentom znotraj načrta Terraform ali Terraform CLI. Vse to lahko vstavite v datoteko tfvars ali v spremenljivko okolja.
Vendar se vam ni treba zapomniti celotnega čarobnega ukaza. Terraform načrt – var in gremo. Prva spremenljivka je var, druga spremenljivka je var, tretja, četrta. Najpomembnejše načelo infrastrukture kot kode, ki ga najpogosteje uporabljam, je, da moram že s pogledom na kodo jasno razumeti, kaj je tam razporejeno, v kakšnem stanju in s kakšnimi vrednostmi. In zato mi ni treba brati dokumentacije ali vprašati Vasje, katere parametre je uporabil za ustvarjanje naše gruče. Samo odpreti moram datoteko s končnico tfvars, ki se pogosto ujema z okoljem, in pogledati vse tam.
Prav tako ne uporabljajte ciljnih argumentov za zmanjšanje obsega. Za to je veliko lažje uporabiti majhne infrastrukturne module.
Prav tako ni potrebe po omejevanju in povečevanju vzporednosti. Če imam 150 virov in želim povečati vzporednost Amazona s privzetih 10 na 100, potem bo najverjetneje šlo nekaj narobe. Lahko pa gre zdaj dobro, a ko bo Amazon rekel, da kličete preveč, boste v težavah.
Terraform bo poskušal ponovno zagnati večino teh težav, vendar ne boste dosegli skoraj nič. Parallelism=1 je pomembna stvar, ki jo morate uporabiti, če naletite na kakšno napako v API-ju AWS ali znotraj ponudnika Terraform. In potem morate podati: parallelism=1 in počakati, da Terraform konča en klic, nato drugega, nato tretjega. Izstrelil jih bo enega za drugim.
Ljudje me pogosto sprašujejo: "Zakaj mislim, da so delovni prostori Terraform zlo?" Menim, da je načelo infrastrukture kot kode videti, katera infrastruktura je bila ustvarjena in s kakšnimi vrednostmi.
Delovnih prostorov niso ustvarili uporabniki. To ne pomeni, da so uporabniki v vprašanjih GitHub zapisali, da ne moremo živeti brez delovnih prostorov Terraform. Ne, ne tako. Terraform Enterprise je komercialna rešitev. Terraform iz HashiCorp se je odločil, da potrebujemo delovne prostore, zato smo ga pospravili. Veliko lažje ga dam v posebno mapo. Potem bo malo več datotek, vendar bo bolj jasno.
Kako delati s kodo? Pravzaprav je delo s seznami edina bolečina. Terraform lažje vzemite. To ni stvar, ki bo naredila vse odlično za vas. Tja ni treba stlačiti vsega, kar piše v dokumentaciji.
Tema poročila je bila zapisana »za prihodnost«. O tem bom govoril zelo na kratko. Za prihodnost to pomeni, da bo 0.12 kmalu izdan.
0.12 je tona novih stvari. Če prihajate iz običajnega programiranja, potem pogrešate vse vrste dinamičnih blokov, zank, pravilne in pogojne primerjalne operacije, kjer se leva in desna stran ne izračunata hkrati, ampak odvisno od situacije. Zelo pogrešate, zato bo 0.12 rešil namesto vas.
Ampak! Če pišete manj in bolj preprosto z uporabo že pripravljenih modulov in rešitev tretjih oseb, potem vam ne bo treba čakati in upati, da bo prišel 0.12 in vse popravil namesto vas.
Hvala za poročilo! Govorili ste o infrastrukturi kot kodi in dobesedno rekli eno besedo o testih. Ali so potrebni testi v modulih? Čigava odgovornost je to? Ali ga moram napisati sam ali so za to odgovorni moduli?
Naslednje leto bo polno poročil, da smo se odločili testirati vse. Kaj testirati, je največje vprašanje. Veliko je odvisnosti, veliko omejitev različnih ponudnikov. Ko se midva pogovarjava in rečeš: "Potrebujem teste," potem vprašam: "Kaj boš testiral?" Pravite, da boste testirali v svoji regiji. Potem rečem, da to v moji regiji ne deluje. Se pravi, o tem se sploh ne bomo mogli dogovoriti. Da ne omenjam, da je veliko tehničnih težav. Se pravi, kako napisati te teste, da bodo ustrezni.
Aktivno raziskujem to temo, tj. kako samodejno ustvariti teste na podlagi infrastrukture, ki ste jo napisali. Se pravi, če ste napisali to kodo, potem jo moram zagnati, na podlagi tega lahko ustvarim teste.
je ena najpogosteje omenjenih knjižnic, ki omogoča pisanje integracijskih testov za Terraform. To je eden od pripomočkov. Raje imam vrsto DSL, na primer rspec.
Anton, hvala za poročilo! Moje ime je Valery. Naj postavim malo filozofsko vprašanje. Obstaja, pogojno, zagotavljanje, obstaja razporeditev. Oskrba ustvari mojo infrastrukturo, pri uvajanju jo napolnimo z nečim uporabnim, na primer s strežniki, aplikacijami itd. In v moji glavi je, da je Terraform bolj za oskrbo, Ansible pa bolj za uvajanje, ker je Ansible tudi za fizično infrastrukturo. omogoča namestitev nginx, Postgres. Hkrati pa se zdi, da Ansible omogoča zagotavljanje, na primer, virov Amazon ali Google. Toda Terraform vam omogoča tudi namestitev določene programske opreme z uporabo njegovih modulov. Ali z vašega vidika obstaja nekakšna meja med Terraform in Ansible, kje in kaj je bolje uporabiti? Ali pa na primer mislite, da je Ansible že smeti, bi morali poskusiti uporabiti Terraform za vse?
Dobro vprašanje, Valery. Menim, da se Terraform od leta 2014 namensko ni spremenil. Ustvarjena je bila za infrastrukturo in umrla za infrastrukturo. Še vedno smo imeli in bomo potrebovali upravljanje konfiguracije Ansible. Izziv je, da so uporabniški podatki znotraj launch_configuration. In tam potegneš Ansible itd. To je standardna razlika, ki mi je najbolj všeč.
Če govorimo o čudoviti infrastrukturi, potem obstajajo pripomočki, kot je Packer, ki zbirajo to sliko. Nato Terraform uporabi vir podatkov, da poišče to sliko in posodobi njeno launch_configuration. To pomeni, da na ta način poteka tako, da najprej potegnemo Tracker, nato pa Terraform. In če pride do gradnje, pride do nove spremembe.
Zdravo! Hvala za poročilo! Moje ime je Misha, podjetje RBS. Ansible lahko pokličete prek ponudnika, ko ustvarjate vir. Ansible ima tudi temo, imenovano dinamični popis. In lahko najprej pokličete Terraform in nato Ansible, ki bo vzel sredstva od države in jo izvršil. Kaj je bolje?
Ljudje uporabljajo oboje z enakim uspehom. Zdi se mi, da je dinamični popis v Ansibleu priročna stvar, če ne govorimo o skupini za samodejno skaliranje. Ker v skupini za samodejno skaliranje že imamo svoj komplet orodij, ki se imenuje launch_configuration. V launch_configuration zabeležimo vse, kar je treba zagnati, ko ustvarimo nov vir. Zato je pri Amazonu uporaba dinamičnega popisa in branje datoteke Terraform ts po mojem mnenju pretirana. In če uporabljate druga orodja, kjer ni koncepta »skupine za samodejno skaliranje«, na primer uporabljate DigitalOcean ali katerega drugega ponudnika, kjer ni skupine za samodejno skaliranje, potem boste tam morali ročno potegniti API, poiskati naslove IP, ustvariti dinamično inventarno datoteko in Ansible se bo že potepal po njej. To pomeni, da za Amazon obstaja launch_configuration, za vse ostalo pa dinamični inventar.
Vir: www.habr.com