Jende askok Terraform ezagutzen eta erabiltzen du bere eguneroko lanean, baina oraindik ez dira horretarako praktikarik onenak sortu. Talde bakoitzak bere planteamendu eta metodoak asmatu behar ditu.
Zure azpiegitura ia erraz hasten da: baliabide batzuk + garatzaile batzuk. Denborarekin, norabide guztietan hazten da. Baliabideak Terraform moduluetan multzokatzeko modurik aurkitzen al duzu, kodea karpetetan antolatzeko eta zer gehiago izan daiteke oker? (azken hitz ospetsuak)
Denbora pasatzen da eta zure azpiegitura zure maskota berria dela sentitzen duzu, baina zergatik? Azpiegituran azaldu ezin diren aldaketek kezkatzen zaituzte, azpiegitura eta kodea ukitzearen beldur zara; ondorioz, funtzionalitate berriak atzeratzen dituzu edo kalitatea murrizten duzu...
Hiru urtez Github-en AWSrako Terraform komunitateko moduluen bilduma kudeatzen eta ekoizpenean Terraform-en epe luzera mantentzen aritu ondoren, Anton Babenko prest dago bere esperientzia partekatzeko: nola idatzi TF moduluak etorkizunean minik ez izateko.
Hitzaldiaren amaieran, parte-hartzaileek Terraform-en baliabideak kudeatzeko printzipioak, Terraform-eko moduluekin lotutako praktika onak eta azpiegituren kudeaketarekin lotutako etengabeko integrazio-printzipio batzuk ezagutuko dituzte.
Legezko oharra: Txosten hau 2018ko azaroko data duela ohartzen naiz βdagoeneko 2 urte igaro diraβ. Txostenean eztabaidatutako Terraform 0.11 bertsioa jada ez da onartzen. Azken 2 urteetan, 2 bertsio berri kaleratu dira, berrikuntza, hobekuntza eta aldaketa asko dituztenak. Mesedez, arreta jarri honi eta egiaztatu dokumentazioa.
erreferentziak:
- +
- β Formateatu automatikoko kodea eta dokumentazioa
- - Terraform moduluen sortzailea (WIP)
- β Terraform kode-sorgailua diagrama bisualetatik (WIP)
- www.terraform-best-practices.com
- (Mezu berriak nire webgune pertsonalean daude www.antonbabenko.com/)
- @antonbabenko - Twitter, eta Slack ezberdin mordoa
Nire izena Anton Babenko da. Zuetako batzuek nik idatzitako kodea erabili duzue ziurrenik. Orain inoiz baino konfiantza handiagoarekin hitz egingo dut honetaz, estatistiketarako sarbidea dudalako.
Terraform-en lan egiten dut eta 2015az geroztik Terraform eta Amazon-ekin erlazionatutako kode irekiko proiektu ugaritan parte-hartzaile eta laguntzaile aktiboa naiz.
Harrezkero nahikoa kode idatzi dut modu interesgarri batean jartzeko. Eta horretaz kontatzen saiatuko naiz orain.
Terraform-ekin lan egitearen konplexutasun eta berezitasunei buruz hitz egingo dut. Baina hori ez da benetan HighLoad-en gaia. Eta orain ulertuko duzu zergatik.
Denborarekin, Terraform moduluak idazten hasi nintzen. Erabiltzaileek galderak idatzi zituzten, nik berridatzi. Ondoren, hainbat utilitate idatzi nituen kodea formateatzeko aurre-konpromisoaren kako bat erabiliz, etab.
Proiektu interesgarri asko egon ziren. Kode sortzea gustatzen zait ordenagailuak gero eta lan gehiago egitea gustatzen zaidalako niretzat eta programatzailearentzat, beraz, gaur egun, Terraform kode-sorgailu batean nabil diagrama bisualetatik abiatuta. Agian zuetako batzuek ikusi dituzue. Geziak dituzten kutxa ederrak dira. Eta oso ona iruditzen zait "Esportatu" botoian klik egin eta dena kode gisa eskuratzen baduzu.
Ukrainakoa naiz. Urte asko daramatzat Norvegian bizi.
Era berean, txosten honetarako informazioa nire izena ezagutzen duten eta sare sozialetan aurkitzen nauten pertsonengandik jaso da. Ia beti dut ezizen bera.
Esan dudan bezala, Terraform AWS moduluen mantentzaile nagusia naiz, hau da, GitHub-eko biltegi handienetako bat, non zeregin ohikoenetarako moduluak ostatatzen ditugun: VPC, Autoscaling, RDS.
Eta orain entzun duzuna oinarrizkoena da. Terraform zer den ulertzen duzun zalantza baduzu, hobe da denbora beste nonbait pasatzea. Hemen termino tekniko asko egongo dira. Eta ez nuen zalantzarik izan txostenaren maila gorena dela aldarrikatzeko. Horrek esan nahi du hitz egin dezakedala termino posible guztiak erabiliz, azalpen handirik gabe.
Terraform 2014an agertu zen azpiegitura kode gisa idazteko, planifikatzeko eta kudeatzeko aukera ematen zuen utilitate gisa. Hemen funtsezko kontzeptua "azpiegitura kode gisa" da.
Dokumentazio guztia, esan bezala, idatzita dago . Espero dut jende gehienak gune hau ezagutzea eta dokumentazioa irakurri izana. Hala bada, leku egokian zaude.
Hau da Terraform konfigurazio-fitxategi arrunt batek, non lehenik aldagai batzuk definitzen ditugun.
Kasu honetan "aws_region" definitzen dugu.
Ondoren, zer baliabide sortu nahi ditugun deskribatuko dugu.
Komando batzuk exekutatzen ditugu, bereziki "terraform init" mendekotasunak eta hornitzaileak kargatzeko.
Eta "terraform apply" komandoa exekutatzen dugu zehaztutako konfigurazioa sortu ditugun baliabideekin bat datorren egiaztatzeko. Aurretik ezer sortu ez dugunez, Terraformek baliabide hauek sortzeko eskatzen digu.
Hau baieztatzen dugu. Honela itsaslatza izeneko ontzi bat sortzen dugu.
Antzeko hainbat utilitate ere badaude. Amazon erabiltzen duzuen askok ezagutzen duzu AWS CloudFormation edo Google Cloud Deployment Manager edo Azure Resource Manager. Horietako bakoitzak bere nolabaiteko inplementazioa du hodei publikoko hornitzaile bakoitzaren barruan baliabideak kudeatzeko. Terraform bereziki erabilgarria da 100 hornitzaile baino gehiago kudeatzeko aukera ematen duelako. (Xehetasun gehiago )
Terraformek hasiera-hasieratik lortu dituen helburuak:
- Terraformek baliabideen ikuspegi bakarra eskaintzen du.
- Plataforma moderno guztiak onartzen ditu.
- Eta Terraform hasiera-hasieratik diseinatu zen azpiegitura modu seguruan eta aurreikuspenean aldatzeko aukera ematen duen erabilgarritasun gisa.
2014an, "aurreikusi" hitzak oso ezohikoa zen testuinguru honetan.
Terraform erabilgarritasun unibertsala da. API bat baduzu, dena kontrola dezakezu:
- 120 hornitzaile baino gehiago erabil ditzakezu nahi duzun guztia kudeatzeko.
- Adibidez, Terraform erabil dezakezu GitHub biltegietarako sarbidea deskribatzeko.
- Jira-n akatsak ere sortu eta itxi ditzakezu.
- New Relic neurketak kudea ditzakezu.
- Dropbox-en fitxategiak ere sor ditzakezu benetan nahi baduzu.
Hori guztia Terraform hornitzaileak erabiliz lortzen da, Go-n deskribatu daitekeen API irekia baitute.
Demagun Terraform erabiltzen hasi ginela, webguneko dokumentazio batzuk irakurri, bideo batzuk ikusi eta main.tf idazten hasi ginela, aurreko diapositibetan erakutsi nuen bezala.
Eta dena bikaina da, VPC bat sortzen duen fitxategi bat duzu.
VPC bat sortu nahi baduzu, 12 lerro hauek gutxi gorabehera zehaztuko dituzu. Deskribatu zein eskualdetan sortu nahi duzun, zein IP helbideen cidr_block erabili. Hori da dena.
Berez, proiektua pixkanaka hazten joango da.
Eta gauza berri mordoa gehituko dituzu bertan: baliabideak, datu-iturriak, hornitzaile berriekin integratuko zara, bat-batean Terraform erabili nahi izango duzu zure GitHub kontuko erabiltzaileak kudeatzeko, etab. Baliteke hainbat erabili nahi izatea. DNS hornitzaileak, gurutzatu dena. Terraformek hori errazten du.
Ikus dezagun hurrengo adibidea.
Apurka-apurka internet_gateway gehitzen duzu zure VPC-ko baliabideak Interneteko sarbidea izatea nahi duzulako. Hau ideia ona da.
Emaitza hau da main.tf:
Hau main.tf-ren goiko zatia da.
Hau main.tf-ren beheko zatia da.
Ondoren, azpisarea gehitzen duzu. NAT atebideak, ibilbideak, bideratze-taulak eta beste azpisare mordoa gehitu nahi dituzunerako, ez dituzu 38 lerro izango, 200-300 lerro gutxi gorabehera baizik.
Hau da, zure main.tf fitxategia pixkanaka hazten ari da. Eta askotan jendeak dena fitxategi batean jartzen du. 10-20 Kb agertzen da main.tf-n. Imajinatu 10-20 Kb testu-edukia dela. Eta dena denarekin lotuta dago. Pixkanaka-pixkanaka zaila da hori lantzea. 10-20 Kb erabiltzaile kasu ona da, batzuetan gehiago. Eta jendeak ez du beti uste hori txarra denik.
Programazio arruntean bezala, hau da, ez azpiegitura kode gisa, ohituta gaude klase, pakete, modulu, taldekatze ezberdin mordoa erabiltzera. Terraformek gauza bera egiteko aukera ematen dizu.
- Kodea hazten ari da.
- Baliabideen arteko menpekotasunak ere gero eta handiagoak dira.
Eta premia handia dugu. Ulertzen dugu ezin dugula gehiago horrela bizi. Gure kodea izugarria bihurtzen ari da. 10-20 Kb, noski, ez da oso zabala, baina sareko pilari buruz bakarrik ari gara, hau da, sareko baliabideak baino ez dituzu gehitu. Ez gara ari Application Load Balancer, inplementazio ES kluster, Kubernetes eta abar, non 100 Kb erraz ehundu daitezkeen. Hori guztia idazten baduzu, laster jakingo duzu Terraformek Terraform moduluak eskaintzen dituela.
Terraform moduluak talde gisa kudeatzen den Terraform konfigurazio autonomo bat dira. Hori da Terraform moduluei buruz jakin behar duzun guztia. Ez dira batere adimentsuak, ez dizute uzten zerbaiten arabera konexio konplexurik egiten. Hau guztia garatzaileen sorbaldetan erortzen da. Hau da, dagoeneko idatzi duzun Terraform konfigurazio moduko bat besterik ez da. Eta talde gisa deitu dezakezu.
Beraz, gure 10-20-30 Kb-ko kodea nola optimizatuko dugun ulertzen saiatzen ari gara. Modulu batzuk erabili behar ditugula konturatzen ari gara pixkanaka.
Topatzen dituzun lehenengo modulu motak baliabide moduluak dira. Ez dute ulertzen zer den zure azpiegitura, zer den zure negozioa, non eta zein diren baldintzak. Hauek dira, hain zuzen, nik, kode irekiko komunitatearekin batera, kudeatzen ditudan moduluak, eta zure azpiegituraren hasierako eraikuntza-bloke gisa planteatzen ditugunak.
Baliabide modulu baten adibidea.
Baliabide modulu bati deitzen diogunean, bere edukia zein bidetik kargatu behar dugun zehazten dugu.
Zein bertsio deskargatu nahi dugun adierazten dugu.
Argudio mordoa pasatzen dugu hor. Hori da dena. Hori da modulu hau erabiltzen dugunean jakin behar dugun guztia.
Jende askok uste du azken bertsioa erabiltzen badute, dena egonkorra izango dela. Baina ez. Azpiegitura bertsionatu behar da; argi eta garbi erantzun behar dugu zein bertsiotara zabaldu den osagai hau edo beste.
Hona hemen modulu honen barruan dagoen kodea. Segurtasun-talde modulua. Hemen korritua 640. lerrora doa. Amazonen segurtasun-croup baliabide bat sortzea posible den konfigurazio guztietan oso zeregin ez-hutsa da. Ez da nahikoa segurtasun talde bat sortzea eta hari zein arau pasatu behar zaizkion esatea. Oso erraza izango litzateke. Amazonen barruan milioi bat murrizketa ezberdin daude. Adibidez, erabiltzen baduzu VPC amaierako puntua, aurrizkien zerrenda, hainbat API eta hori guztia beste guztiarekin konbinatzen saiatzen da, orduan Terraformek ez dizu hau egiten uzten. Eta Amazon APIak ere ez du hau onartzen. Hori dela eta, logika ikaragarri hori guztia modulu batean ezkutatu eta honen itxura duen erabiltzailearen kodea eman behar dugu.
Erabiltzaileak ez du jakin behar barruan nola egiten den.
Bigarren motako moduluek, baliabideen moduluek osatzen dute, dagoeneko zure negoziorako aplikagarriagoak diren arazoak konpontzen dituzte. Askotan Terraform-en luzapena den lekua da eta etiketetarako balio zurrun batzuk ezartzen ditu, konpainiaren estandarrentzat. Gaur egun Terraformek erabiltzen uzten ez dizun funtzionalitateak gehi ditzakezu bertan. Hau oraintxe dago. Orain 0.11 bertsioa, iraganeko gauza bihurtzear dagoena. Baina, hala ere, aurreprozesadoreak, jsonnet, cookiecutter eta beste gauza mordoa dira lan osoa egiteko erabili beharreko mekanismo laguntzaileak.
Jarraian horren adibide batzuk erakutsiko ditut.
Azpiegitura-moduluari modu berean deitzen zaio.
Edukia deskargatzeko iturria adierazten da.
Balio mordoa pasatzen dira eta modulu honetara pasatzen dira.
Ondoren, modulu honen barruan, baliabide-modulu mordo bat deitzen dira VPC edo Aplikazioen karga-orekatzailea sortzeko, edo segurtasun-talde bat sortzeko edo Elastic Container Service kluster baterako.
Bi modulu mota daude. Hau ulertzea garrantzitsua da txosten honetan bildu dudan informazio gehiena ez baitago dokumentazioan idatzita.
Eta Terraform-en oraintxe bertan dokumentazioa nahiko problematikoa da, funtzio hauek daudela esaten duelako, erabil ditzakezula. Baina ez du esaten ezaugarri hauek nola erabili, zergatik den hobe horiek erabiltzea. Hori dela eta, jende kopuru handi batek bizi ezin duen zerbait idazten du.
Ikus dezagun hurrengo modulu hauek nola idatzi. Gero ikusiko dugu nola deitu eta nola lan egin kodearekin.
Terraform Erregistroa -
0 aholkua baliabide-modulurik ez idaztea da. Modulu horietako gehienak dagoeneko zuretzat idatzita daude. Esan bezala, kode irekikoak dira, ez dute zure negozio-logikarik, ez dute balio gogorreko koderik IP helbideak, pasahitzak, etab. Modulua oso malgua da. Eta ziurrenik dagoeneko idatzita dago. Amazon-en baliabideetarako modulu asko daude. 650 inguru. Eta gehienak kalitate onekoak dira.
Adibide honetan, norbait etorri zitzaizun eta esan zuen: βDatu-base bat kudeatu ahal izan nahi dut. Sortu modulu bat datu-base bat sortu ahal izateko". Pertsonak ez daki Amazon edo Terraform-en ezarpenaren xehetasunak. Besterik gabe, esaten du: "MSSQL kudeatu nahi dut". Hau da, gure moduluari deituko diola esan nahi dugu, hor motor mota pasako duela eta ordu-zona adieraziko duela.
Eta pertsona batek ez luke jakin behar modulu honen barruan bi baliabide ezberdin sortuko ditugula: bat MSSQLrako, bigarrena beste guztiarentzat, Terraform 0.11-n ezin duzulako zehaztu ordu-zonaren balioak hautazko gisa.
Eta modulu honetatik irteeran, pertsona batek helbide bat besterik gabe jaso ahal izango du. Ez du jakingo zein datu basetatik, zein baliabidetatik sortzen ari garen hori guztia barnean. Hau ezkutatzeko elementu oso garrantzitsua da. Eta kode irekian publikoak diren moduluei ez ezik, zure proiektu eta taldeen barruan idatziko dituzun moduluei ere aplikatzen zaie.
Hau bigarren argumentua da, eta hori nahiko garrantzitsua da denbora bat Terraform erabiltzen ari bazara. Biltegi bat duzu Terraform modulu guztiak zure enpresarako jartzen dituzunean. Eta nahiko normala da denborarekin proiektu hau megabyte bateko edo biko tamaina izatera iristea. Hau ondo dago.
Baina arazoa Terraformek modulu horiei nola deitzen dien da. Adibidez, erabiltzaile bakoitza sortzeko modulu bati deitzen badiozu, Terraformek lehenik biltegi osoa kargatuko du eta ondoren modulu zehatz hori dagoen karpetara joango da. Horrela megabyte bat deskargatuko duzu bakoitzean. 100 edo 200 erabiltzaile kudeatzen badituzu, 100 edo 200 megabyte deskargatuko dituzu, eta gero karpeta horretara joango zara. Beraz, jakina, ez duzu gauza mordoa deskargatu nahi "Terraform init" sakatzen duzun bakoitzean.
Arazo honen aurrean bi irtenbide daude. Lehenengoa bide erlatiboak erabiltzea da. Horrela karpeta lokala dela adieraziko duzu kodean (./). Eta ezer abiarazi aurretik, biltegi honen Git klon bat egiten duzu lokalean. Horrela behin egiten duzu.
Badira, noski, alde txarrak asko. Adibidez, ezin duzu bertsioa erabili. Eta hori batzuetan zaila da bizitzea.
Bigarren irtenbidea. Azpimodulu asko badituzu eta dagoeneko ezarrita dagoen kanalizazio moduko bat baduzu, MBT proiektua dago, eta horrek aukera ematen dizu pakete ezberdin asko biltzeko monobiltegi batetik eta S3ra igotzeko. Hau oso modu ona da. Horrela, iam-user-1.0.0.zip fitxategiak 1 Kb baino ez du pisua izango, baliabide hau sortzeko kodea oso txikia delako. Eta askoz azkarrago funtzionatuko du.
Hitz egin dezagun moduluetan erabili ezin denari buruz.
Zergatik dago gaitza moduluetan? Okerrena erabiltzailea suposatzea da. Demagun erabiltzailea pertsona ezberdinek erabil dezaketen hornitzaileen autentifikazio aukera bat dela. Adibidez, denok asimilatuko dugu rola. Horrek esan nahi du Terraformek rol hori hartuko duela. Eta gero rol honekin beste ekintza batzuk egingo ditu.
Eta gaiztoa da Vasyari Amazonera modu batean konektatzea gustatzen bazaio, adibidez, ingurune-aldagai lehenetsia erabiliz, eta Petya-ri bere gako partekatua erabiltzea gustatzen bazaio, leku sekretuan daukana, orduan ezin dituzu biak zehaztu. Terraforma. Eta sufrimendurik bizi ez dezaten, ez dago bloke hori moduluan adierazi beharrik. Hau maila altuago batean adierazi behar da. Hau da, baliabideen modulua, azpiegitura modulua eta konposizioa ditugu gainean. Eta hau nonbait gorago adierazi behar da.
Bigarren gaiztoa hornitzailea da. Hemen gaiztoa ez da hain hutsala, zeren kodea idazten baduzu eta zuretzat funtzionatzen badu, agian pentsatuko duzu funtzionatzen badu, zergatik aldatu.
Gaitza da ez duzula beti kontrolatzen hornitzaile hau noiz abiaraziko den, lehenik. Eta bigarrenik, ez duzu kontrolatzen zer esan nahi duen aws ec2, hau da, Linux edo Windows-i buruz ari gara orain. Beraz, ezin duzu idatzi sistema eragile ezberdinetan edo erabiltzaile kasu desberdinetan berdin funtzionatuko duen zerbait.
Adibiderik ohikoena, dokumentazio ofizialean ere adierazten dena, hau da: aws_instance idazten baduzu eta argumentu mordo bat zehazten baduzu, ez dago gaizki hornitzailea hor "local-exec" zehaztu eta zure ansible- exekutatzen baduzu. jolas liburua .
Izan ere, hori bai, ez dago gaizki. Baina literalki laster konturatuko zara exekuzio lokal hori ez dela existitzen, adibidez, launch_configuration-en.
Eta launch_configuration erabiltzen duzunean eta autoeskalatze-talde bat instantzia batetik sortu nahi duzunean, launch_configuration-en ez dago "hornitzaile" kontzepturik. "Erabiltzaileen datuak" kontzeptua dago.
Hori dela eta, irtenbide unibertsalagoa erabiltzailearen datuak erabiltzea da. Eta instantzian bertan abiaraziko da, instantzia aktibatuta dagoenean, edo erabiltzailearen datu berdinetan, eskalatze automatikoko taldeak launch_configuration hau erabiltzen duenean.
Hornitzailea oraindik exekutatu nahi baduzu, itsasteko osagai bat denez, baliabide bat sortzen denean, une horretan zure hornitzailea exekutatu behar duzu, zure komandoa. Horrelako egoera asko daude.
Eta horretarako baliabiderik zuzenena null_resource deitzen da. Null_resource benetan inoiz sortzen ez den baliabide finko bat da. Ez du ezer ukitzen, ez APIrik, ez autoeskalatzerik. Baina komandoa noiz exekutatu kontrolatzeko aukera ematen du. Kasu honetan, komandoa sorreran exekutatzen da.
Link
Hainbat seinale daude. Ez ditut seinale guztiak xehetasun handiz sartuko. Horri buruzko artikulu bat dago. Baina Terraform-ekin lan egin baduzu edo besteen moduluak erabili badituzu, askotan ohartu zara modulu asko, kode irekiko kode gehienak bezala, jendeak bere beharretarako idazten dituela. Gizon batek idatzi zuen eta bere arazoa konpondu zuen. GitHub-en itsatsi nuen, utzi bizi. Biziko da, baina hor dokumentazio eta adibiderik ez badago, inork ez du erabiliko. Eta bere zeregin zehatza baino apur bat gehiago ebazteko aukera ematen duen funtzionalitaterik ez badago, inork ere ez du erabiliko. Erabiltzaileak galtzeko modu asko daude.
Zerbait idatzi nahi baduzu jendeak erabili dezan, seinale hauek jarraitzea gomendatzen dizut.
Hauek dira:
- Dokumentazioa eta adibideak.
- Funtzionalitate osoa.
- Arrazoizko lehenetsiak.
- Garbitu kodea.
- Probak.
Probak beste egoera bat dira, idazteko nahiko zailak direlako. Gehiago sinesten dut dokumentazioan eta adibideetan.
Beraz, moduluak nola idatzi aztertu dugu. Bi argudio daude. Lehenengoa, garrantzitsuena dena, ahal baduzu ez idaztea da, jende pila batek egin baititu aurretik zeregin hauek. Eta bigarrenik, oraindik erabakitzen baduzu, saiatu hornitzaileak ez erabiltzen moduluetan eta hornitzaileetan.
Hau da dokumentazioaren zati grisa. Orain pentsatzen ari zara: Β«Zerbait ez dago argi. Konbentzitu gabe". Baina sei hilabete barru ikusiko dugu.
Orain hitz egin dezagun modulu horiei nola deitu.
Gure kodea denborarekin hazten dela ulertzen dugu. Jada ez dugu fitxategi bat, dagoeneko 20 fitxategi ditugu. Karpeta batean daude guztiak. Edo agian bost karpeta. Agian, nolabait eskualdeka, osagai batzuen arabera banatzen hasiak gara. Orduan ulertzen dugu orain sinkronizazio eta orkestrazio oinarri batzuk ditugula. Hau da, ulertu behar dugu zer egin beharko genukeen sareko baliabideak aldatuz gero, zer egin behar dugun gainerako baliabideekin, nola eragin menpekotasun horiek, etab.
Bi mutur daude. Lehenengo muturra dena batean dago. Fitxategi nagusi bat dugu. Momentuz, horixe izan da Terraform webguneko praktikarik onena ofiziala.
Baina orain zaharkituta eta kenduta dago idatzita. Denborarekin, Terraform komunitatea praktika onetik urrun zegoela konturatu zen, jendea proiektua modu ezberdinetan erabiltzen hasi zelako. Eta arazoak daude. Adibidez, mendekotasun guztiak leku bakarrean zerrendatzen ditugunean. Egoerak daude "Terraform plana" sakatzen dugunean eta Terraformek baliabide guztien egoerak eguneratzen dituen arte, denbora asko pasa daiteke.
Denbora asko, adibidez, 5 minutu dira. Batzuentzat denbora asko da. 15 minutu behar izan diren kasuak ikusi ditut. AWS APIak 15 minutu eman zituen baliabide bakoitzaren egoerarekin zer gertatzen ari zen asmatzen saiatzen. Oso eremu handia da.
Eta, jakina, erlazionatutako arazo bat agertuko da leku bakarrean zerbait aldatu nahi duzunean, gero 15 minutu itxaroten dituzunean, eta aldaketa batzuen mihisea ematen dizu. Tu egin duzu, "Bai" idatzi eta zerbait gaizki joan da. Hau oso adibide erreala da. Terraform ez da arazoetatik babesten saiatzen. Hau da, nahi duzuna idatzi. Arazoak izango dira - zure arazoak. Terraform 0.11 inola ere laguntzen saiatzen ari ez den bitartean. 0.12an badaude leku interesgarri batzuk esatea ahalbidetzen dizutenak: "Vasya, benetan nahi duzu hau, zentzura etor zaitezke?"
Bigarren modua eremu hori murriztea da, hau da, leku bateko deiak beste leku batetik gutxiago konektatu daitezke.
Arazo bakarra da kode gehiago idatzi behar duzula, hau da, fitxategi kopuru handietan aldagaiak deskribatu eta hau eguneratu behar dituzu. Batzuei ez zaie gustatzen. Hau normala da niretzat. Eta batzuek pentsatzen dute: "Zergatik idatzi hau leku ezberdinetan, dena leku batean jarriko dut". Hau posible da, baina hau bigarren muturra da.
Nork du hau guztia leku batean bizitzea? Bat, bi, hiru pertsona, hau da, norbait erabiltzen ari da.
Eta nork deitzen dio osagai jakin bati, bloke bati edo azpiegitura-modulu bati? Bost-zazpi lagun. Hau polita da.
Erantzun ohikoena erdialdean dago. Proiektua handia bada, sarritan irtenbiderik ez den eta dena funtzionatzen ez duen egoera bat izango duzu, beraz, nahasketa batekin amaitzen duzu. Ez dago ezer gaizki, biak abantailak dituztela ulertzen baduzu, betiere.
VPC pilan zerbait aldatu bada eta aldaketa hauek EC2-n aplikatu nahi badituzu, hau da, eskala automatikoko taldea eguneratu nahi baduzu azpisare berri bat duzulako, orduan mendekotasun orkestrazio mota honi deitzen diot. Irtenbide batzuk daude: nork erabiltzen du zer?
Zein irtenbide dauden iradoki dezaket. Terraform erabil dezakezu magia egiteko, edo makefiles erabil dezakezu Terraform erabiltzeko. Eta ikusi han zerbait aldatu den, hemen abiarazi dezakezu.
Nola gustatzen zaizu erabaki hau? Inork uste al du irtenbide polita dela? Irribarre bat ikusten dut, itxuraz zalantzak sartu dira.
Jakina, ez saiatu hau etxean. Terraform ez zen inoiz Terraformetik exekutatzeko diseinatu.
Txosten batean esan zidaten: "Ez, honek ez du funtzionatuko". Kontua da ez duela funtzionatu behar. Hain ikusgarria dirudien arren Terraform Terraform-etik eta gero Terraform abiarazi dezakezunean, ez zenuke hori egin behar. Terraform beti oso erraz hasi behar da.
Leku batean zerbait aldatu denean dei-orkestrazioa behar baduzu, Terragrunt dago.
Terragrunt erabilgarritasun bat da, Terraform-en gehigarri bat, azpiegitura moduluetarako deiak koordinatu eta orkestratzeko aukera ematen duena.
Terraform konfigurazio-fitxategi tipiko batek itxura hau du.
Zehazten duzu zein modulu zehatz deitu nahi duzun.
Zein menpekotasun ditu moduluak?
Eta zer argudio onartzen ditu modulu honek. Hori da Terragrunt-i buruz jakin behar dena.
Dokumentazioa hor dago, eta 1 izar daude GitHub-en. Baina kasu gehienetan hau da jakin behar duzuna. Eta hori oso erraza da inplementatzea Terraform-ekin lanean hasi berri diren enpresetan.
Beraz, orkestrazioa Terragrunt da. Beste aukera batzuk daude.
Orain hitz egin dezagun kodearekin nola lan egin.
Zure kodeari eginbide berriak gehitu behar badituzu, kasu gehienetan erraza da. Baliabide berri bat idazten ari zara, dena erraza da.
Aldez aurretik sortutako baliabideren bat baduzu, adibidez, Terraform-i buruz ikasi baduzu AWS kontu bat ireki ondoren eta lehendik dituzun baliabideak erabili nahi badituzu, egokia izango litzateke zure modulua modu honetan zabaltzea, horrela dauden baliabideen erabilera onartzen du.
Eta bloke baliabidea erabiliz baliabide berriak sortzea onartzen du.
Irteeran beti itzultzen dugu irteerako id erabilitakoaren arabera.
Terraform 0.11-en bigarren arazo oso esanguratsua zerrendekin lan egitea da.
Zailtasuna da erabiltzaileen zerrenda hori badugu.
Eta erabiltzaile hauek bloke-baliabidea erabiliz sortzen ditugunean, dena ondo doa. Zerrenda osoa zeharkatzen dugu, bakoitzarentzat fitxategi bat sortuz. Dena ondo dago. Eta gero, adibidez, erdian dagoen erabiltzailea 3 kendu behar da hemendik, gero bere ondoren sortu ziren baliabide guztiak birsortuko dira indizea aldatuko delako.
Zerrendekin lan egitea egoera egoera batean. Zer da estatu-inguru bat? Baliabide hori sortzen denean balio berri bat sortzen den egoera da. Adibidez, AWS Access Key edo AWS Secret Key, hau da, erabiltzaile bat sortzen dugunean, Sarbide edo Sekretu gako berri bat jasotzen dugu. Eta erabiltzaile bat ezabatzen dugun bakoitzean, erabiltzaile honek gako berri bat izango du. Baina hau ez da feng shui, erabiltzaileak ez baitu gurekin lagun izan nahi norbaitek taldea uzten duen bakoitzean erabiltzaile berri bat sortzen badiogu.
Hau da irtenbidea. Hau Jsonnet-en idatzitako kodea da. Jsonnet Google-ren txantiloi-lengoaia da.
Komando honek txantiloi hau onartzeko aukera ematen dizu eta irteera gisa zure txantiloiaren arabera egindako json fitxategi bat itzultzen du.
Txantiloiak honen itxura du.
Terraform-ek HCL eta Json-ekin modu berean lan egiteko aukera ematen du, beraz, Json sortzeko gaitasuna baduzu, Terraform-en sartu dezakezu. .tf.json luzapena duen fitxategia behar bezala deskargatuko da.
Eta gero, ohi bezala lan egiten dugu: terraform init, terramorm aplika. Eta bi erabiltzaile sortzen ditugu.
Orain ez dugu beldurrik norbait taldea uzten badu. Json fitxategia editatuko dugu. Vasya Pupkin joan zen, Petya Pyatochkin geratu zen. Petya Pyatochkinek ez du gako berririk jasoko.
Terraform beste tresnekin integratzea ez da benetan Terraformen lana. Terraform baliabideak sortzeko plataforma gisa sortu zen eta kitto. Eta gero ateratzen dena ez da Terraformen kezka. Eta ez dago hor barruan ehundu beharrik. Ansible dago, behar duzun guztia egiten duena.
Baina egoerak sortzen dira Terraform hedatu eta komandoren bat deitu nahi dugunean zerbait amaitu ondoren.
Lehenengo bidea. Irteera bat sortzen dugu non komando hau idazten dugun.
Eta gero komando honi shell terraform irteeratik deitzen diogu eta nahi dugun balioa zehaztu. Horrela, komandoa ordezkaturiko balio guztiekin exekutatzen da. Oso erosoa da.
Bigarren bidea. Hau da null_resource erabiltzea gure azpiegituraren aldaketen arabera. Local-exe berari dei diezaiokegu baliabide batzuen IDa aldatu bezain laster.
Jakina, hau guztia paperean leuna da, Amazonek, beste hornitzaile publiko guztiek bezala, bere ertz-kasu sorta bat baitu.
Ertz-kasurik ohikoena AWS kontu bat irekitzen duzunean zer eskualde erabiltzen dituzun garrantzitsua da; funtzio hau gaituta al dago bertan; agian 2013ko abenduaren ostean ireki zenuen; agian lehenetsia erabiltzen ari zara VPC-n etab. Murrizketa asko daude. Eta Amazonek dokumentazio osoan barreiatu zituen.
Badira gauza batzuk saihestea gomendatzen dudana.
Hasteko, saihestu sekretu gabeko argumentu guztiak Terraform planaren edo Terraform CLIren barruan. Hori guztia tfvars fitxategi batean edo ingurune-aldagai batean jar daiteke.
Baina ez duzu komando magiko hau guztia memorizatu behar. Terraform plana - var eta aurrera goaz. Lehenengo aldagaia var da, bigarren aldagaia var, hirugarrena, laugarrena. Gehien erabiltzen dudan kode gisa azpiegituraren printzipiorik garrantzitsuena da kodeari begiratuta, argi eta garbi ulertu behar dudala zer hedatzen den bertan, zein egoeratan eta zer baliorekin. Eta, beraz, ez diot zertan dokumentazioa irakurri edo Vasyari galdetu zer parametro erabili zituen gure cluster-a sortzeko. Tfvars luzapena duen fitxategi bat ireki behar dut, askotan ingurunearekin bat datorrena, eta bertan dagoen guztia begiratu.
Gainera, ez erabili helburu-argumentuak esparrua murrizteko. Horretarako askoz errazagoa da azpiegitura-modulu txikiak erabiltzea.
Gainera, ez dago paralelismoa mugatu eta handitu beharrik. 150 baliabide baditut eta Amazonen paralelismoa 10 lehenetsitik 100era handitu nahi badut, ziurrenik zerbait gaizki aterako da. Edo baliteke orain ondo ateratzea, baina Amazonek dei gehiegi egiten ari zarela esaten duenean arazoak izango dituzu.
Terraform arazo horietako gehienak berrabiarazten saiatuko da, baina ez duzu ia ezer lortuko. Paralelismoa=1 gauza garrantzitsua da AWS APIaren edo Terraform hornitzailearen barruan akatsen bat aurkitzen baduzu. Eta gero zehaztu behar duzu: paralelismoa=1 eta itxaron Terraformek dei bat amaitu arte, gero bigarrena, gero hirugarrena. Banan-banan abiaraziko ditu.
Jendeak askotan galdetzen dit: "Zergatik uste dut Terraform lan-eremuak gaiztoak direla?" Nire ustez, azpiegituraren printzipioa kode gisa zer azpiegitura sortu den eta zer baliorekin ikustea da.
Lan-eremuak ez dituzte erabiltzaileek sortu. Horrek ez du esan nahi erabiltzaileek GitHub-en gaiak idatzi zituztenik Terraform lan-eremurik gabe bizi ezin gintezkeela. Ez ez horrelakorik. Terraform Enterprise irtenbide komertziala da. HashiCorp-eko Terraform-ek laneko guneak behar genituela erabaki zuen, beraz, artxibatu egin genuen. Askoz errazagoa iruditzen zait aparteko karpeta batean jartzea. Gero fitxategi gehiago egongo dira, baina argiagoa izango da.
Nola lan egin kodearekin? Izan ere, zerrendekin lan egitea da min bakarra. Eta hartu Terraform errazago. Hau ez da dena bikain egingo dizun gauza. Ez dago dokumentazioan idatzitako guztia hor sartu beharrik.
Txostenaren gaia "etorkizunerako" idatzi zen. Honetaz oso labur hitz egingo dut. Etorkizunerako, horrek esan nahi du 0.12 laster kaleratuko dela.
0.12 gauza berri asko da. Programazio arruntetik bazatoz, bloke dinamiko, begiztak, konparazio eragiketa zuzenak eta baldintzatuak galduko dituzu, non ezkerreko eta eskuineko aldeak aldi berean kalkulatzen ez diren, egoeraren arabera baizik. Asko galduko duzu, beraz, 0.12k konponduko dizu.
Baina! Gero eta sinpleago idazten baduzu, prest egindako moduluak eta hirugarrenen soluzioak erabiliz, ez duzu itxaron beharko eta espero 0.12 etorriko zaizula dena konponduko zaizula.
Eskerrik asko erreportajeagatik! Azpiegituraz kode gisa hitz egin duzu eta hitz bat hitz egin duzu probei buruz. Moduluetan beharrezkoak al dira probak? Noren ardura da hau? Nik neuk idatzi behar dut ala moduluen ardura da?
Datorren urtean dena probatzea erabaki dugun txostenez beteko da. Zer probatu da galderarik handiena. Mendekotasun asko daude, hornitzaile ezberdinen murrizketa asko. Zu eta biok hizketan ari garenean eta esaten duzunean: "Probak behar ditut", orduan galdetzen dut: "Zer probatuko duzu?" Zure eskualdean proba egingo duzula diozu. Orduan esaten dut horrek ez duela balio nire eskualdean. Hau da, ezingo gara honetan ados jarri ere egin. Zer esanik ez arazo tekniko asko daudela. Hau da, nola idatzi proba hauek egokiak izan daitezen.
Gai hau aktiboki ikertzen ari naiz, hau da, idatzi duzun azpiegituran oinarrituta probak nola sortu automatikoki. Hau da, kode hau idatzi baduzu, orduan exekutatu behar dut, horretan oinarrituta probak sor ditzaket.
Terraform-en integrazio-probak idazteko aukera ematen duen liburutegietako bat da. Hau erabilgarritasunetako bat da. DSL mota nahiago dut, adibidez, rspec.
Anton, eskerrik asko erreportajeagatik! Nire izena Valery da. Utzidazu galdera filosofiko txiki bat egiten. Badago, baldintzatuta, hornidura, hedapena dago. Hornikuntzak nire azpiegitura sortzen du, hedapenean zerbait erabilgarriaz betetzen dugu, adibidez, zerbitzariak, aplikazioak, etab. Eta nire buruan dago Terraform hornikuntzarako gehiago dela, eta Ansible gehiago zabaltzeko, Ansible azpiegitura fisikorako ere bai. nginx, Postgres instalatzeko aukera ematen du. Baina, aldi berean, Ansiblek ematen du, adibidez, Amazon edo Google baliabideak hornitzea ahalbidetzen duela. Baina Terraformek bere moduluak erabiliz software batzuk zabaltzeko aukera ematen du. Zure ikuspuntutik, ba al dago Terraform eta Ansibleren artean doan mugarik, non eta zer da hobea erabiltzea? Edo, adibidez, Ansible jada zaborra dela uste duzu, saiatu beharko zenuke denetarako Terraform erabiltzen?
Galdera ona, Valery. Uste dut Terraform ez dela aldatu helburu aldetik 2014az geroztik. Azpiegituretarako sortu zen eta azpiegituretarako hil zen. Oraindik Ansible konfigurazio kudeaketaren beharra genuen eta izango dugu. Erronka launch_configuration barruan erabiltzaileen datuak daudela da. Eta hor tira duzu Ansible, etab. Hau da gehien gustatzen zaidan bereizketa estandarra.
Azpiegitura ederrez ari bagara, badaude irudi hau biltzen duten Packer bezalako utilitateak. Eta gero Terraformek datu-iturburua erabiltzen du irudi hau aurkitzeko eta bere launch_configuration eguneratzeko. Hau da, modu honetan kanalizazioa da lehenik Tracker tiratzen dugula, gero Terraform tira. Eta eraikuntza gertatzen bada, aldaketa berri bat gertatzen da.
Kaixo! Eskerrik asko erreportajeagatik! Nire izena Misha da, RBS konpainia. Ansiblera dei dezakezu hornitzailearen bidez baliabide bat sortzean. Inbentario dinamikoa izeneko gaia ere badu Ansiblek. Eta lehenik Terraform deitu dezakezu, eta gero Ansiblera deitu, horrek estatutik baliabideak hartuko ditu eta exekutatu egingo ditu. Zer hobe?
Jendeak arrakasta berdinarekin erabiltzen ditu biak. Iruditzen zait Ansible-n inbentario dinamikoa gauza erosoa dela, autoeskalatze taldeaz ari ez bagara. Autoscaling taldean dagoeneko badugulako gure tresna-kit, launch_configuration deritzona. launch_configuration-en baliabide berri bat sortzen dugunean abiarazi behar den guztia erregistratzen dugu. Horregatik, Amazonekin, inbentario dinamikoa erabiltzea eta Terraform ts fitxategia irakurtzea, nire ustez, gehiegizkoa da. Eta beste tresna batzuk erabiltzen badituzu, "autoscaling-talde" kontzepturik ez dagoenean, adibidez, DigitalOcean edo autoeskalatze talderik ez dagoen beste hornitzaileren bat erabiltzen baduzu, orduan APIa eskuz atera beharko duzu, IP helbideak aurkitu, sortu. inbentario-fitxategi dinamiko bat, eta Ansible dagoeneko ibiliko da. Hau da, Amazonentzat launch_configuration dago, eta gainerako guztiarentzat inbentario dinamikoa dago.
Iturria: www.habr.com