Badirudi Terraform-eko garatzaileek AWS azpiegiturarekin lan egiteko praktika egokienak eskaintzen dituztela. Bakarrik ñabardura bat dago. Denborarekin, ingurune kopurua handitzen da, ezaugarriak agertzen dira bakoitzean. Alboko eskualdean aplikazio pilaren ia kopia bat agertzen da. Eta Terraform kodea kontu handiz kopiatu eta editatu behar da baldintza berrien arabera edo elur maluta bat egiteko.
Nire txostena Terraform-en ereduei buruzkoa da kaosa eta eskuzko errutinari aurre egiteko proiektu handi eta luzeetan.
Video:
40 urte ditut, 20 urte daramatzat informatikan. 12 urte daramatzat Ixtensen lanean. Merkataritza elektronikoak bultzatutako garapenean dihardugu. Eta 5 urte daramatzat DevOps praktikak praktikatzen.
Nire istorioa, izenik esango ez dudan enpresa bateko proiektu batean izandako esperientziari buruzkoa izango da, ezkutatzeko akordio baten atzean ezkutatuta.
Diapositibako zenbakiak proiektuaren irismena ulertzeko ematen dira. Eta jarraian esango dudan guztia Amazonekin lotuta dago.
Duela 4 urte sartu nintzen proiektu honetan. Eta azpiegituren birfactorizazioa pil-pilean zegoen, proiektua hazi egin zelako. Eta erabiltzen ziren eredu horiek, jada ez dira egokitzen. Eta proiektuak aurreikusitako hazkunde guztia ikusita, beharrezkoa zen zerbait berria egitea.
Eskerrik asko Matvey-ri, atzo Dodo Pizzan gertatutakoa kontatu zigun. Hauxe gertatu zitzaigun duela 4 urte.
Garatzaileak etorri ziren eta azpiegitura kodea egiten hasi ziren.
Hori eskatzen zen arrazoirik nabariena merkaturatzeko garaia izan zen. Ziurtatu behar zen DevOps taldea ez zela botila-lepo bat zabaltzean. Eta besteak beste, Terraform eta Puppet lehen mailan erabili ziren.
Terraform HashiCorp-en kode irekiko proiektu bat da. Eta zer den batere ez dakienarentzat, hurrengo diapositibak.
Azpiegiturak kode gisa esan nahi du gure azpiegitura deskribatu dezakegula eta robot batzuei deskribatu ditugun baliabideak lortzen ditugula ziurtatzeko eskatu.
Adibidez, makina birtual bat behar dugu. Deskribatuko dugu, beharrezko parametro batzuk gehituko ditugu.
Horren ostean, Amazonerako sarbidea konfiguratuko dugu kontsolan. Eta eskatu Terraform plana. Terraform planak esango du: "Ok, zure baliabideagatik, gauza hauek egin ditzakegu". Eta gutxienez baliabide bat gehituko da. Eta ez da aldaketarik espero.
Dena komeni zaizunean, Terraform-i aplikatzeko eska diezaiokezu eta Terraformek instantzia bat sortuko dizu eta makina birtual bat lortuko duzu zure hodeian.
Gainera, gure proiektua garatzen da. Aldaketa batzuk gehitzen ari gara hor. Instantzia gehiago eskatzen ditugu, 53 sarrera gehitzen ditugu.
Eta errepikatzen dugu. Mesedez, planifikatu. Ikusten dugu zer aldaketa aurreikusten diren. Aplikatu. Eta horrela gure azpiegiturak hazten dira.
Terraformek egoera fitxategiak bezalako gauza bat erabiltzen du. Hau da, Amazon-era doazen aldaketa guztiak fitxategi batean gordetzen ditu, non deskribatu duzun baliabide bakoitzeko, Amazon-en sortutako baliabideak dauden. Horrela, baliabide baten deskribapena aldatzean, Terraformek zehatz-mehatz daki zer aldatu behar den Amazonen.
Egoera-fitxategi hauek hasiera batean fitxategiak besterik ez ziren. Eta Git-en gorde genituen, eta hori oso deserosoa zen. Etengabe norbait ahaztu egiten zen aldaketak egitea, eta gatazka asko egon ziren.
Orain backend-a erabil daiteke, hau da, Terraform zein ontzitan adierazten da, zein gakorekin gorde behar den egoera fitxategia. Eta Terraform bera arduratuko da egoera-fitxategi hori lortzeaz, magia guztia eginez eta azken emaitza berriro jarriz.
Gure azpiegiturak hazten ari dira. Hona hemen gure kodea. Eta orain ez dugu makina birtual bat bakarrik sortu nahi, proba-ingurune bat izan nahi dugu.
Terraform-ek modulu gisako gauza bat egiteko aukera ematen du, hau da, karpeta batzuetan gauza bera deskribatzea.
Eta, adibidez, probak egiterakoan, deitu modulu honi eta lortu Terraform aplikazioa egingo bagenu moduluan bertan. Hona hemen probak egiteko kodea.
Ekoizpenerako, aldaketa batzuk bidali ditzakegu hara, probetan ez baitugu instantzia handirik behar, ekoizpenean instantzia handiak ondo etorriko dira.
Eta gero itzuliko naiz proiektura. Lan zaila zen, azpiegitura oso handia zen aurreikusita. Eta beharrezkoa zen kode guztia nolabait jartzea, guztiontzat erosoa izan zedin: kode horri mantentze lanak egiten dituztenentzat eta aldaketak egiten dituztenentzat. Eta aurreikusita zegoen edozein garatzaile joan zitekeela azpiegitura konpontzera bere plataformaren zatirako behar bezala.
HashiCorp-ek gomendatzen duen direktorio-zuhaitza da hau proiektu handi bat baduzu eta zentzuzkoa da azpiegitura osoa zati txiki batzuetan banatzea eta pieza bakoitza karpeta bereizi batean deskribatzea.
Baliabideen liburutegi zabala edukita, gauza bera dei dezakezu proban eta ekoizpenean.
Gure kasuan, hau ez zen guztiz egokia, garatzaileentzako edo probak egiteko proba pila nolabait errazagoa lortu behar zelako. Eta ez nuen nahi karpetetatik pasa eta sekuentzia egokian aplikatu, eta kezkatu oinarria igoko zela eta orduan oinarri hau erabiltzen duen instantzia igoko zela. Hori dela eta, proba guztiak karpeta batetik abiatu ziren. Han modulu berdinak deitzen ziren, baina dena korrika batean igaro zen.
Terraformek mendekotasun guztiak zaintzen ditu. Eta beti sortzen ditu baliabideak sekuentzia horretan, IP helbide bat lor dezakezu, adibidez, sortu berri den instantzia batetik, eta IP helbide hau route53 sarreran lor dezakezu.
Gainera, plataforma oso handia da. Eta proba-pila bat martxan jartzea, ordubetez bada ere, 8 orduz bada ere, nahiko negozio garestia da.
Eta negozio hau automatizatu dugu. Eta Jenkins-en lanak pila exekutatzen utzi zuen. Beharrezkoa zen bertan tira-eskaera bat abiarazi, garatzaileak probatu nahi dituen aldaketekin, beharrezko aukera, osagai eta tamaina guztiak zehaztu. Errendimendu-probak nahi baditu, kasu gehiago har ditzake. Formularioren bat irekitzen dela egiaztatu behar badu, gutxieneko soldatan has liteke. Eta kluster bat behar den ala ez ere adierazi, etab.
Eta gero Jenkinsek shell script bat bultzatu zuen Terraform karpetako kodea apur bat aldatu zuen. Behar ez ziren fitxategiak kendu, beharrezko fitxategiak gehitu. Eta gero, Terraform-en exekuzio bat aplikatuta, pila igo zen.
Eta gero, beste urrats batzuk eman nahi ez ditudanak.
Izan ere, probak egiteko ekoizpenean baino aukera apur bat gehiago behar genituenez, moduluen kopiak egin behar izan genituen, kopia horietan probak bakarrik behar diren ezaugarriak gehitu ahal izateko.
Eta gertatu da probetan, badirudi azkenean ekoizpenera joango diren aldaketa horiek probatu nahi dituzula. Baina, egia esan, gauza bat probatu zen, eta apur bat desberdina erabili zen ekoizpenean. Eta eten txiki bat zegoen ereduan, ekoizpenean aldaketa guztiak operazio-taldeak aplikatzen zituelako. Eta batzuetan, probatik ekoizpenera joan behar ziren aldaketa horiek beste bertsio batean geratzen zirela frogatu zen.
Horrez gain, halako arazo bat zegoenez, zerbitzu berri bat gehitu zen, lehendik zeuden batzuekin apur bat ezberdina zena. Eta lehendik dagoen modulu bat aldatu beharrean, horren kopia bat egin eta beharrezko aldaketak gehitu behar izan dituzu.
Izan ere, Terraform ez da benetako hizkuntza bat. Hau deklarazio bat da. Zerbait deklaratu behar badugu, orduan deklaratuko dugu. Eta denak funtzionatzen du.
Noizbait, nire tira-eskaera bati buruz eztabaidatzean, nire lankide batek esan zuen ez dela beharrezkoa elur malutak sortzea. Zer esan nahi zuen galdetzen nion. Hain datu zientifiko bat dago munduan ez daudela bi elur maluta berdinak, denak apur bat, baina desberdinak. Eta hori entzun bezain laster, berehala sentitu nuen Terraform kodearen pisu osoa. Bertsio batetik bestera pasatzea eskatzen zenean, Terraform-ek haustura-kate aldaketa eskatzen zuen, hau da, kodea ez zen jada hurrengo bertsioarekin bateragarria. Eta pull request bat egin behar izan nuen, azpiegiturako fitxategien ia erdia hartzen zuena, azpiegitura Terraform-en hurrengo bertsiora eramateko.
Eta halako elur maluta bat agertu ondoren, guk genuen Terraform kode guztia elur pila handi eta handi batean bihurtu zen.
Eragiketaz kanpo dagoen kanpoko garatzaile bati, ez dio asko axola, tira eskaera bat egin zuelako, bere baliabidea hasi zen. Eta kitto, ez da bere kezka. Eta dena ondo dagoela ziurtatzen duen DevOps taldeak aldaketa horiek guztiak egin behar ditu. Eta aldaketa horien kostua oso-oso handitu zen elur-maluta gehigarri bakoitzarekin.
Mintegi bateko ikasle batek arbelean klarionarekin bi zirkulu perfektu marrazten dituen istorio bat dago. Eta irakaslea harrituta dago iparrorratzarik gabe hain leun marraztea nola lortu zuen. Ikasleak erantzun dio: "Oso sinplea da, armadan bi urtez haragi birrintzailea egin nuen".
Eta proiektu honetan daramatzat lau urteetatik, bi urte inguru daramatzat Terraform egiten. Eta, noski, baditut trikimailu batzuk, aholku batzuk Terraform kodea sinplifikatzeko, programazio-lengoaia bezala lan egiteko eta kode hau eguneratuta eduki behar duten garatzaileen zama murrizteko.
Hastea gustatuko litzaidake lehen gauza esteka sinbolikoak dira. Terraformek kode errepikakor asko du. Adibidez, azpiegitura bat sortzen dugun ia puntu guztietan hornitzaile bati deitzea berdina da. Eta logikoa da aparteko aitatxo batean jartzea. Eta hornitzaileak fitxategi honetarako Esteka sinbolikoak egin behar dituen tokietan.
Esate baterako, bere gain hartzen duen rola erabiltzen duzu ekoizpenean, eta horrek aukera ematen dizu kanpoko Amazon kontu batzuetarako sarbide-eskubideak lortzeko. Eta fitxategi bat aldatuz gero, baliabideen zuhaitzean dauden gainerako guztiek beharrezko eskubideak izango dituzte Terraformek jakin dezan zein Amazon segmentu sartu behar den.
Non estekak ez dute funtzionatzen? Esan bezala, Terraformek estatu fitxategiak ditu. Eta oso-oso politak dira. Baina kontua da Terraform-ek backend-a hasieratzen duela lehenengoan. Eta ezin du aldagairik erabili parametro hauetan, beti testuan idatzi behar dira.
Eta, ondorioz, norbaitek baliabide berri bat egiten duenean, beste karpeta batzuetatik kodearen zati bat kopiatzen du. Eta akatsen bat egin dezake giltzarekin edo ontziarekin. Esaterako, hare-kutxako gauza bat egiten du hare-kutxa batetik, eta gero ekoizpenean egiten du. Eta, beraz, gerta daiteke produkzioan dagoen ontzia hareatzatik erabiliko dela. Noski, azkar aurkituko dute. Hori nolabait konpontzea posible izango da, baina, hala ere, denbora eta, neurri batean, baliabideak galtzea da.
Zer egin dezakegu gero? Terraform-ekin lan egin aurretik, hasieratu behar duzu. Hasierako momentuan, Terraformek plugin guztiak deskargatzen ditu. Noizbait, monolito batetik mikrozerbitzuen arkitekturara hautsi ziren. Eta beti egin behar duzu Terraform init, modulu guztiak, plugin guztiak atera ditzan.
Eta shell script bat erabil dezakezu, lehenik eta behin, aldagai guztiak lor ditzake. Shell script-a mugagabea da. Eta, bigarrenik, bidea. Biltegian dagoen bidea beti erabiltzen badugu egoera-fitxategiaren gako gisa, orduan, horren arabera, errorea hemen baztertuko da.
Non lortu datuak? JSON fitxategia. Terraformek azpiegitura hcl-n (HashiCorp Configuration Language) ez ezik, JSON-n ere idazteko aukera ematen du.
JSON erraz irakurtzen da shell script batetik. Horren arabera, ontzi batekin konfigurazio fitxategi bat jar dezakezu lekuren batean. Eta erabili ontzi hau bai Terraform kodean eta baita shell scriptean hasieratzeko.
Zergatik da garrantzitsua Terraform ontzi bat izatea? Urruneko egoera fitxategiak bezalako gauza bat dagoelako. Hau da, baliabideren bat planteatzen dudanean, Amazoni esateko: “Mesedez, igo instantzia”, beharrezkoak diren parametro asko zehaztu behar ditut.
Eta identifikatzaile horiek beste karpeta batean gordetzen dira. Eta hartu eta esan dezaket: "Terraform, mesedez, joan baliabide horren egoera-fitxategira eta lortu identifikatzaile hauek". Eta horrela eskualde edo ingurune ezberdinen arteko bateratze moduko bat dago.
Ez da beti posible urruneko egoera fitxategi bat erabiltzea. Adibidez, eskuz sortu duzu VPC bat. Eta VPC sortzen duen Terraform kodeak hain VPC ezberdin bat sortzen du, oso denbora luzea behar duela eta bata bestera egokitu behar duzu, beraz, honako trikimailu hau erabil dezakezu.
Hau da, VPC egiten duen eta identifikatzaileak ematen dizkizuen modulu bat egitea, baina, egia esan, instantzia bera sortzeko erabil daitekeen balio kodetutako fitxategi bat besterik ez dago.
Ez da beti beharrezkoa egoera-fitxategia hodeian gordetzea. Adibidez, moduluak probatzerakoan, backend hasierako hasiera erabil dezakezu, fitxategia diskoan bakarrik gordeko denean probak egiteko unean.
Orain probari buruz pixka bat. Zer probatu daiteke Terraform-en? Seguruenik, asko da posible, baina 4 gauza horietaz hitz egingo dut.
HashiCorp-ek Terraform kodea nola formateatu ulertzen du. Eta Terraform fmt-k sinesmen horren arabera editatzen duzun kodea formateatzen uzten dizu. Horren arabera, probek nahitaez egiaztatu behar dute formatua HashiCorp-ek utzitakoarekin bat datorren ala ez, parentesien kokapena aldatu beharrik ez izateko, etab.
Hurrengoa Terraform baliozkotzea da. Sintaxiaren egiaztapena baino apur bat gehiago egiten du - ala, parentesi guztiak parekatuta daude. Zer da garrantzitsua hemen? Oso azpiegitura mehea dugu. Karpeta ezberdin asko ditu. Eta bakoitzean Terraform validate exekutatu behar duzu.
Horren arabera, probak bizkortzeko, paraleloan hainbat prozesu exekutatzen ditugu paralelo erabiliz.
Paraleloa oso gauza polita da, erabili.
Baina Terraform hasieratzen den bakoitzean, HashiCorp-era joaten da eta galdetzen du: "Zein dira azken pluginak? Eta cachean daukadan plugina - hori da ala ez? Eta pauso bakoitzean moteldu egiten zen.
Terraformek pluginak non dauden esaten badizu, Terraformek esango du: "Ados, hau da ziurrenik dagoen gauzarik freskoena. Ez naiz inora joango, berehala hasiko naiz zure Terraform kodea balioztatzen".
Karpeta beharrezko pluginekin betetzeko, Terraform kode oso sinplea dugu, hasieratu besterik ez duena. Hemen, noski, zure kodean nolabait parte hartzen duten hornitzaile guztiak zehaztu behar dituzu, bestela Terraformek esango du: "Ez dut hornitzailerik ezagutzen, ez dagoelako cachean".
Hurrengoa Terraform plana da. Esan bezala, garapena ziklikoa da. Aldaketekin kodea egiten dugu. Eta gero jakin behar duzu zer aldaketa aurreikusten diren azpiegituretan.
Eta azpiegitura oso-oso handia denean, modulu bat alda dezakezu, proba-ingurune bat edo eskualde zehatz bat konpondu eta aldameneko bat hautsi. Hori dela eta, azpiegitura osorako Terraform plana egin beharko litzateke eta zer aldaketa aurreikusten diren erakutsi.
Modu adimendunean egin dezakezu. Adibidez, mendekotasunak ebazten dituen Python script bat idatzi dugu. Eta aldatutakoaren arabera: Terraform modulu bat edo osagai zehatz baten arabera, menpeko karpeta guztien planak egiten ditu.
Terraform plana eskatuta egin behar da. Guk behintzat horixe egiten dugu.
Probak, noski, onak dira aldaketa bakoitzerako, konpromiso bakoitzerako, baina planak nahiko gauza garestiak dira. Eta tira eskaeran esaten dugu: "Mesedez, emaidazu planak". Robota martxan jartzen da. Eta bidaltzen ditu iruzkinetara edo zure aldaketetatik espero diren plan guztiak eransteko.
Plana gauza nahiko garestia da. Denbora behar da Terraform Amazonera joaten delako eta galdetzen duelako: "Instantzia hau oraindik existitzen al da? Eskala automatiko honek parametro berdinak al ditu?”. Eta bizkortzeko, refresh=false bezalako parametro bat erabil dezakezu. Horrek esan nahi du Terraformek S3 egoera deflatuko duela. Eta estatua Amazonen dagoenarekin bat etorriko dela uste du.
Halako Terraform plan bat askoz azkarragoa da, baina egoerak zure azpiegitura bat etorri behar du, hau da, nonbait, noizbait Terraform freskatzea hasi behar da. Terraform freskatzeak horixe egiten du, egoera errealaren azpiegituran dagoenarekin bat etor dadin.
Eta segurtasunari buruz esan behar dut. Hemen hasi behar zen. Terraform exekutatzen duzun eta Terraform-ek zure azpiegiturarekin lan egiten duen tokian, ahultasun bat dago. Hau da, funtsean kodea exekutatzen ari zara. Eta tira eskaerak kode gaiztoren bat badu, sarbide gehiegi duen azpiegitura batean exekutatu daiteke. Beraz, kontuz ibili Terraform plana non abiarazten duzun.
Hitz egin nahiko nukeen hurrengo gauza erabiltzaileen datuen proba da.
Zer dira erabiltzaile-datuak? Amazonen, instantzia bat sortzen dugunean, instantziatik gutun motaren bat bidal dezakegu - metadatuak. Instantzia bat abiarazten denean, normalean cloud init beti dago instantzia horietan. Cloud init-ek gutun hau irakurtzen du eta honela dio: "Ados, gaur karga-orekatzailea naiz". Eta manu horien arabera, ekintza batzuk egiten ditu.
Baina, zoritxarrez, Terraform plana egiten dugunean eta Terraform aplikatzen dugunean, erabiltzaile-datuek zenbaki-sorta honen itxura dute. Hau da, hash bat besterik ez dizu bidaltzen. Eta planean ikusten dena da aldaketarik egongo den edo hashak berdin jarraituko duen.
Eta horri kasurik egiten ez badiozu, orduan irabiatutako testu-fitxategi batzuk Amazonera joan daitezke, benetako azpiegiturara.
Bestela, exekuzioan zehar azpiegitura osoa ez zehaztu dezakezu, txantiloia baizik. Eta kodean, esan: "Mesedez, erakutsi txantiloi hau niri". Eta, ondorioz, zure datuak Amazonen nolakoak izango diren inprimatu dezakezu.
Beste aukera bat modulu bat erabiltzea da erabiltzaile-datuak sortzeko. Modulu hau aplikatuko duzu. Lortu fitxategia diskoan. Konpara ezazu erreferentziarekin. Eta horrela, jun batzuek erabiltzaile-datu apur bat konpontzea erabakitzen badute, zure probek esango dute: "Ados, aldaketa batzuk daude hemen eta hemen - hau normala da".
Hitz egin nahiko nukeen hurrengo gauza da Automate Terraform aplikatzea.
Noski, nahikoa beldurgarria da Terraform modu automatikoan aplikatzea, nork daki zer aldaketa gertatu diren eta zein kaltegarriak izan daitezkeen azpiegitura bizi batentzat.
Proba-ingurune baterako, hau guztia ondo dago. Hau da, proba-ingurune bat sortzen duen lana garatzaile guztiek behar dutena da. Eta "denak funtzionatu dit" bezalako esamolde bat ez da meme dibertigarria, pertsona batek nahastu egin zela, pila bat altxatu eta proba batzuk abiarazi zituela pila honetan frogatzen duena baizik. Eta han dena ondo zegoela ziurtatu zuen eta esan zuen: "Ados, askatzen dudan kodea probatu da".
Ekoizpenean, sandboxetan eta negozio-kritikoagoak diren beste ingurune batzuetan, segurua da baliabide batzuk partzialki erabiltzea, ez baitu inor hiltzen eragiten. Hauek dira: autoscale taldeak, segurtasun taldeak, rolak, route53 eta hor zerrenda nahiko handia izan daiteke. Baina adi egon zer gertatzen den, irakurri aplikazio automatizatuen txostenak.
Erabiltzea arriskutsua edo beldurgarria den tokietan, adibidez, baliabide iraunkor batzuk badira, datu-base batetik, lortu azpiegituraren batean aplikatu gabeko aldaketak daudela dioen txostenak. Eta ingeniariari dagoeneko gainbegiratuta dago lanak martxan jartzeko edo bere kontsolatik egiteko.
Amazonek Amaitu babesa du. Eta kasu batzuetan behar ez dituzun aldaketetatik babestu dezake. Beraz, Terraform Amazonera joan zen eta esan zuen: "Instantzia hau hil behar dut beste bat egiteko". Eta Amazonek dio: “Barkatu, gaur ez. Amaitzeko babesa dugu".
Eta kodearen optimizazioa da. Terraform kodearekin lan egiten dugunean, parametro kopuru oso handia pasa behar diogu moduluari. Baliabide motaren bat sortzeko beharrezkoak diren parametroak dira. Eta kodea, modulu batetik bestera, modulutik modulu pasatu behar diren parametroen zerrenda handietan bihurtzen da, batez ere moduluak habiaratuta badaude.
Eta oso zaila da irakurtzea. Oso zaila da hau berrikustea. Eta askotan gertatzen da parametro batzuk berrikusten ari direla eta ez direla guztiz beharrezkoak. Eta denbora eta dirua kostatzen da gero konpontzea.
Hori dela eta, balioen zuhaitz jakin bat barne hartzen duen parametro konplexu gisa erabiltzea proposatzen dizut. Hau da, karpeta motaren bat behar duzu, non ingurune batean izan nahiko zenukeen balio guztiak dituzun.
Eta modulu honi deituz, modulu komun batean sortzen den zuhaitz bat lor dezakezu, hau da, azpiegitura osorako berdin funtzionatzen duen modulu komun batean.
Modulu honetan, kalkulu batzuk egin ditzakezu Terraform-en bertako ezaugarri berri bat erabiliz. Eta, ondoren, irteera batean, igorri nolabaiteko parametro konplexu bat, hashak, arrayak, etab.
Honetan, amaitu ditudan aurkikuntza onenak. Eta Kolonen istorio bat kontatu nahiko nuke. India ezagutzeko espediziorako diru bila zebilela (orduan uste zuen bezala), inork ez zion sinetsi eta ezinezkoa zela uste zuen. Orduan esan zuen: "Ziurtatu arrautza ez dela erori". Bankari guztiak, oso aberatsak eta ziurrenik argiak, arrautza nolabait jartzen saiatu ziren, eta denbora guztian erori zen. Orduan Kolonek arrautza hartu zuen, pixka bat zapaldu zuen. Oskola zimurtu eta arrautza geldirik geratu zen. Esan zuten: "Oh, hori errazegia da!" Eta Kolonek erantzun zion: “Bai, sinpleegia da. Eta India irekitzen dudanean, denek erabiliko dute merkataritza bide hau».
Eta esan berri dizudana gauza nahiko sinple eta hutsalak dira ziurrenik. Eta horiei buruz jakin eta erabiltzen hasten zarenean, gauzen ordenan dago. Beraz, erabili. Eta zuretzako gauza nahiko normalak badira, badakizu gutxienez arrautza bat nola jartzen den, erori ez dadin.
Laburbildu:
- Saiatu elur malutak saihesten. Eta zenbat eta elur maluta gutxiago, orduan eta baliabide gutxiago beharko dituzu zure azpiegitura handi osoan aldaketak egiteko.
- Etengabeko aldaketa. Hau da, kodean aldaketa batzuk gertatu direnean, zure azpiegitura aldaketa horiekin lehenbailehen jarri behar duzu. Ez luke egoerarik egon behar bizpahiru hilabeteren buruan norbait Elasticsearch-era begiratzera etortzen denean, Terraform plan bat egiten duenean eta espero ez zituen aldaketa asko daude. Eta denbora asko behar da dena ordenan jartzeko.
- Probak eta automatizazioa. Zenbat eta gehiago zure kodea testekin eta txipekin estalita egon, orduan eta konfiantza handiagoa izango duzu dena ondo egiten ari zarela. Eta entrega automatikoak zure konfiantza askotan areagotuko du.
- Proba eta ekoizpen inguruneetarako kodea ia berdina izan behar da. Praktikoki, azken finean, ekoizpena pixka bat ezberdina delako eta oraindik ere izango dira proba-ingurunetik haratago joango diren ñabardura batzuk. Baina, hala ere, gehi edo ken eman daiteke.
- Eta Terraform kode asko baduzu eta kode hau eguneratuta mantentzeko denbora asko behar baduzu, inoiz ez da beranduegi birfaktorizatu eta egoera onean ekartzeko.
- azpiegitura aldaezina. AMI-ren entrega ordutegian.
- Route53rako egitura sarrera asko dituzunean eta ordena koherentean egotea nahi duzunean.
- Borrokatu API tasaren mugen aurka. Hau da Amazonek: "Hori da, ezin ditut gehiago eskaerak hartu, itxaron mesedez". Eta bulegoaren erdia bere azpiegitura martxan jarri arte zain dago.
- lekuko instantziak. Amazon ez da ekitaldi merkea eta lekuek asko aurrezteko aukera ematen dute. Eta hor horri buruzko erreportaje oso bat kontatu dezakezu.
- Segurtasuna eta IAM rolak.
- Bilatu galdutako baliabideak, Amazonen jatorri ezezaguneko kasuak dituzunean, dirua jaten dute. Instantziak hilean 100-150 $ balio badu ere, urtean 1 $ baino gehiago da. Baliabide horiek aurkitzea negozio errentagarria da.
- Eta erreserbatutako kasuak.
Hori da niretzat dena. Terraform oso polita da, erabili. Eskerrik asko!
Zure galderak
Eskerrik asko erreportajeagatik! Egoera-fitxategi bat duzu S3-n, baina nola konpontzen duzu hainbat pertsonek egoera-fitxategi hau hartu eta zabaltzen saia dezaketen arazoa?
Lehenik eta behin, ez dugu presarik. Bigarrenik, banderak daude, zeinetan kode zatiren bat lantzen ari garela salatzen dugun. Hau da, azpiegitura oso handia den arren, horrek ez du esan nahi norbait etengabe zerbait erabiltzen ari denik. Eta fase aktibo bat zegoenean, arazo bat zen, egoera fitxategiak Git-en gordetzen genituen. Hau garrantzitsua zen, bestela norbaitek egoera fitxategi bat egingo zuen, eta eskuz pila batean bildu behar izan genituen gehiago jarraitzeko. Orain ez dago horrelako arazorik. Oro har, Terraformek arazo hau konpondu zuen. Eta zerbait etengabe aldatzen ari bada, esandakoa eragozten duten blokeoak erabil ditzakezu.
Kode irekia edo enpresa-kode irekia erabiltzen al duzu?
Enpresarik ez, hau da, doan deskargatu dezakezun guztia.
Nire izena Stanislav da. Gehigarri txiki bat egin nahi nuen. Instantzia bat hilezin bihurtzeko aukera ematen duen Amazon funtzioari buruz hitz egin duzu. Hau ere Terraform-en bertan dago, Life Second blokean, aldatzeko debekua edo suntsitzeko debekua agindu dezakezu.
Denboran mugatua zen. Puntu ona.
Bi gauza ere galdetu nahi nituen. Lehenik eta behin, probei buruz hitz egin duzu. Proba tresnarik erabili al duzu? Test Kitchen pluginaren berri izan nuen. Agian badago beste zerbait. Eta Tokiko Balioei buruz galdetu nahiko nuke. Zertan bereizten dira funtsean Sarrera aldagaietatik? Eta zergatik ezin dut zerbait parametrizatu Tokiko Balioen bidez soilik? Gai hau jorratzen saiatu nintzen, baina nolabait ez nuen neuk asmatu.
Areto honen atzean zehatzago hitz egin dezakegu. Proba-tresnak gure buruak eginak dira. Ez dago ezer probatzeko. Oro har, aukerak daude proba automatikoek azpiegitura nonbait altxatzen dutenean, ondo dagoela egiaztatzen eta gero guztia suntsitzen dutenean zure azpiegitura oraindik egoera onean dagoela dioen txostenarekin. Ez dugu horrelakorik proba-pilak egunero ibiltzen direlako. Eta nahikoa da. Eta zerbait apurtzen hasten bada, apurtzen hasiko da guk beste nonbait egiaztatu gabe.
Tokiko Balioei dagokienez, jarrai dezagun elkarrizketa publikotik kanpo.
Kaixo! Eskerrik asko erreportajeagatik! Oso informatzailea. Azpiegitura deskribatzeko kode mota bereko asko duzula esan duzu. Kode hau sortzea pentsatu al duzu?
Galdera bikaina, eskerrik asko! Kontua da azpiegitura kode gisa erabiltzen dugunean, kodea begiratu eta kode horren atzean zer azpiegitura dagoen ulertzen dugula suposatzen dugula. Kodea sortzen bada, zer kode sortuko den imajinatu behar dugu zer nolako azpiegitura egongo den ulertzeko. Edo kodea sortzen dugu, konprometitzen dugu eta, hain zuzen ere, gauza bera lortzen dugu. Horregatik, idatzi genuen bidetik joan ginen, lortu genuen. Gainera, sorgailuak pixka bat beranduago agertu ziren, egiten hasi ginenean. Eta beranduegi zen aldatzeko.
Entzun al duzu jsonnet-en berri?
N º.
Begira, gauza polita da hau. Kasu zehatz bat ikusten dut non aplikatu eta datu-egitura bat sor dezakezun.
Sorgailuak onak dira haiek dituzunean, bizarra egiteko makinari buruzko txantxetan bezala. Hau da, lehen aldiz aurpegia ezberdina da, baina gero denek aurpegi bera dute. Sorgailuak oso politak dira. Baina, zoritxarrez, gure aurpegiak apur bat desberdinak dira. Hau arazoa da.
Begiratu besterik ez. Eskerrik asko!
Nire izena Maxim da, Sberbankekoa naiz. Apur bat esan duzu Terraform programazio-lengoaia baten analogo batera eramaten saiatu zarela. Ez al da errazagoa Ansible erabiltzea?
Hauek oso gauza desberdinak dira. Ansiblek baliabideak sor ditzake, eta Puppet-ek Amazon-en. Baina Terraform erabat zorroztuta dago.
Amazon bakarrik daukazu?
Ez da Amazon bakarrik daukagula. Ia Amazon bakarrik daukagu. Baina funtsezko ezaugarria Terraformek gogoratzen duela da. Ansible-n, esaten baduzu: "Har nazazu 5 instantzia", orduan igoko da, eta orduan esaten duzu: "Eta orain 3 behar ditut". Eta Terraformek esango du: "Ok, 2 hilko ditut", eta Ansiblek: "Ok, hemen dituzu 3". Guztira 8.
Kaixo! Eskerrik asko zure txostenagatik! Oso interesgarria izan zen Terraformi buruz entzutea. Iruzkin txiki bat besterik ez dut egin nahi Terraform-ek oraindik bertsio egonkorrik ez duelako, beraz, kontu handiz ibili Terraform-ekin.
Koilara polita afaltzeko. Hau da, irtenbideren bat behar baduzu, batzuetan ezegonkorra dena atzeratzen duzu, etab., baina funtzionatzen du eta lagundu digu.
Galdera da. Urruneko backend erabiltzen ari zara, S 3 erabiltzen ari zara. Zergatik ez duzu backend ofiziala erabiltzen?
Ofiziala?
Terraform Hodeia.
Noiz agertu zen?
duela 4 hilabete.
Duela 4 urte agertu izan balitz, seguruenik, zure galderari erantzungo nioke.
Dagoeneko integratutako funtzio bat eta blokeoak daude, eta egoera fitxategi bat gorde dezakezu. Saiatu. Baina nik ere ez dut probatu.
Abiadura handian dabilen tren handi batean gaude. Eta ezin dituzu auto batzuk hartu eta bota.
Elur malutaz ari zinen, zergatik ez duzu adarra erabili? Zergatik ez zen horrela atera?
Halako ikuspegia dugu, non azpiegitura osoa biltegi batean dagoela. Terraform, Puppet, honekin nolabait erlazionatuta dauden gidoi guztiak, denak biltegi batean daude. Horrela, aldaketa gehigarriak banan-banan probatzen direla ziurtatu ahal izango dugu. Adar mordoa balitz, horrelako proiektu bat mantentzea ia ezinezkoa izango litzateke. Sei hilabete igarotzen dira, eta hainbeste alde egiten dute non zigor moduko bat besterik ez da. Hau da birfactorizatu aurretik ihes egin nahi nuena.
hau da, ez du funtzionatzen?
Ez du batere funtzionatzen.
Adarrean, karpetaren diapositiba moztu dut. Hau da, proba pila bakoitzerako egiten baduzu, adibidez, A taldeak bere aita dauka, B taldeak bere aita, orduan honek ere ez du funtzionatzen. Proba-inguruneko kode bateratu bat egin genuen, guztiontzat egokitzeko nahikoa malgua. Hau da, kode bat zerbitzatu genuen.
Kaixo! Nire izena Yura da! Eskerrik asko erreportajeagatik! Moduluei buruzko galdera. Moduluak erabiltzen ari zarela diozu. Nola konpondu arazoa modulu batean beste pertsona baten aldaketarekin bateragarriak ez diren aldaketak egin badira? Nolabait, moduluak bertsionatu edo bi eskakizun betetzeko prodigio bat ekartzen saiatzen ari zara?
Hau da elur pilaren arazo handia. Hori da jasaten duguna aldaketa inozoren batek azpiegituraren zatiren bat hauts dezakeenean. Eta denbora luze baten ondoren bakarrik nabarituko da.
Hau da, oraindik ez al da erabaki?
Modulu unibertsalak egiten dituzu. Saihestu elur malutak. Eta dena aterako da. Txostenaren bigarren zatia nola saihestu da.
Kaixo! Eskerrik asko erreportajeagatik! Argitu nahiko nuke. Eszena atzean pila handi bat zegoen, eta horretarako etorri nintzen. Nola integratzen dira Puppet eta rol banaketa?
erabiltzaile-datuak.
Hau da, fitxategia tu besterik ez duzu eta nolabait exekutatzen duzu?
Erabiltzaile-datuak ohar bat dira, hau da, irudi klona bat egiten dugunean, orduan Daemon altxatzen da eta nor den jakin nahian, karga-orekatzailea dela dioen ohar bat irakurtzen du.
Hau da, ematen den prozesu bereizi bat al da?
Guk ez dugu asmatu. Erabiltzen dugu.
Kaixo! Erabiltzaileari buruzko galdera bat besterik ez dut - datuak. Hor arazoak daudela esan duzu, norbaitek zerbait okerrera bidali dezakeela. Ba al dago erabiltzaile-datuak Git berean gordetzeko moduren bat, Erabiltzaile-datuek zeri egiten dioten erreferentzia beti argi izan dadin?
Erabiltzaile-datuak txantiloietatik sortzen ditugu. Hau da, aldagai kopuru jakin bat bertara jotzen da. Eta Terraform-ek azken emaitza sortzen du. Hori dela eta, ezin duzu txantiloiari begiratu eta zer gertatzen den esan, arazo guztiak garatzaileak aldagai honetan kate bat pasatzen ari dela pentsatzen duelako eta, ondoren, array bat erabiltzen delako. Eta berak - bang eta ni - hola-hala, hola-hala, hurrengo lerroa, eta dena hautsi zen. Baliabide berria bada eta pertsona batek planteatzen badu, zerbait ez dabilela ikusten badu, orduan hau azkar konponduko da. Eta autoscale talde hau eguneratu bada, orduan uneren batean autoscale taldeko instantziak ordezkatzen hasiko dira. Eta txalo, zerbait ez dabil. Min egiten du.
Irtenbide bakarra probatzea dela ematen du?
Bai, arazoa ikusten duzu, proba-urratsak gehitzen dituzu bertan. Hau da, irteera ere probatu daiteke. Agian ez da hain erosoa, baina marka batzuk ere jar ditzakezu - egiaztatu Erabiltzaile-datuak hemen iltzatuta daudela.
Nire izena Timur da. Oso polita da Terraform behar bezala antolatzeari buruzko txostenak egotea.
Ez nintzen hasi ere egin.
Hurrengo hitzaldian agian egongo dela uste dut. Galdera sinple bat daukat. Zergatik kodetzen duzu balioa aparteko modulu batean tfvars erabili beharrean, hau da, balioak dituen modulua tfvars baino hobea da?
Hau da, hemen idatzi beharko nuke (diapositiba: Production/environment/settings.tf): domeinua = aldagaia, domeinua vpcnetwork, vpcnetwork aldagaia eta stvars - gauza bera lortu?
Guk horixe egiten dugu. Ezarpen-iturburu-moduluari erreferentzia egiten diogu, adibidez.
Izan ere, hau tfvars bat da. Tfvars oso erabilgarria da proba-ingurunean. Instantzia handietarako tfvars ditut, txikietarako. Eta fitxategi bat karpetara bota nuen. Eta nahi nuena lortu. Azpiegiturak ikusi ditugunean, dena ikusi eta berehala ulertu nahi dugu. Eta, beraz, ikusten da hemen begiratu behar duzula, gero tfvars-etan begiratu.
Dena leku bakarrean zegoela ematen du?
Bai, tfvars kode bat duzunean da. Eta hainbat lekutan erabiltzen da ñabardura ezberdinekin. Orduan tfvar-ak bota eta zure ñabardurak lortuko zenituen. Eta kode gisa azpiegitura gara bere forma garbienean. Begiratu eta ulertu.
Kaixo! Hodeiko hornitzaileak Terraform-ekin egin duzuna oztopatzen duen egoerarekin egin al duzu topo? Demagun metadatuak editatzen ditugula. Ssh teklak daude. Eta Google-k etengabe sartzen ditu bere metadatuak, giltzak hor. Eta Terraformek beti idazten du aldaketak dituela. Korrika bakoitzaren ondoren, ezer aldatzen ez bada ere, eremu hau orain eguneratuko duela esaten du beti.
Giltzekin, baina - bai, azpiegituraren zati batek eragiten du horrelakoak, hau da, Terraformek ezin du ezer aldatu. Eskuekin ere ezin dugu ezer aldatu. Berarekin bizi garen bitartean.
Hau da, honekin topatu zenuen, baina ez zenuen ezer asmatu, nola egiten du eta berak egiten du?
Zoritxarrez bai.
Kaixo! Nire izena Stanislav Starkov da. Posta. eu Taldea. Nola konpontzen duzu etiketa bat sortzearen arazoa..., nola pasatzen duzu barrura? Ulertzen dudanez, Erabiltzaile - datuen bidez, ostalariaren izena zehazteko, Puppet incite? Eta galderaren bigarren zatia. Nola konpontzen duzu arazo hau SG-n, hau da, SG sortzen duzunean, mota bereko ehun instantzia, nola izendatu behar bezala?
Guretzat oso garrantzitsuak diren kasu horiek, ederki izendatuko ditugu. Behar ez direnak, autoscale talde bat dela dioen postscript bat dago. Eta teorian iltzatu daiteke, eta berria lortu.
Etiketaren arazoari dagokionez, ez dago arazorik, baina badago zeregin hori. Eta etiketak oso-oso asko erabiltzen ditugu, azpiegitura handia eta garestia delako. Eta zertan gastatzen den dirua aztertu behar dugu, beraz, etiketak zer eta nora joan den ordenatzeko aukera ematen digu. Eta, horren arabera, hemen zerbait bilatzea diru asko gastatzen da.
Zeri buruzko beste galdera zen?
SGk ehun instantzia sortzen dituenean, nolabait bereizi behar al dira?
Ez, ez. Instantzia bakoitzak arazo bat dudala esaten didan agente bat dauka. Agenteak salatzen badu, agenteak badaki haren berri eta, gutxienez, bere IP helbidea existitzen da. Dagoeneko korrika egin dezakezu. Bigarrenik, Consul for Discovery erabiltzen dugu, non Kubernetes ez dagoen. Eta Consul-ek instantziaren IP helbidea ere erakusten du.
Hau da, IP-ra zuzentzen ari zara, eta ez ostalari-izena?
Ezinezkoa da ostalariaren izenaren arabera nabigatzea, hau da, asko daude. Instantzia-identifikatzaileak daude - AE, etab. Nonbait aurki dezakezu, bilaketara bota dezakezu.
Kaixo! Konturatu nintzen Terraform gauza ona dela, hodeietara egokitua.
Ez bakarrik.
Hau da interesatzen zaidan galdera. Zure instantzia guztiekin Masa Bare Metalera mugitzea erabakitzen baduzu? Arazorik egongo al da? Edo oraindik beste produktu batzuk erabili behar dituzu, adibidez, hemen aipatu zen Ansible bera?
Ansible beste zerbaiti buruz da. Hau da, Ansible dagoeneko martxan dago instantzia hasi denean. Eta Terraformek instantzia hasi aurretik funtzionatzen du. Bare Metalera aldatzea ez da.
Orain ez, baina negozioak etorriko dira eta esango dute: "Zatoz".
Beste hodei batera aldatzea - bai, baina hemen ezaugarri apur bat desberdina da. Terraform kodea idatzi behar duzu odol isurketa gutxiago duen beste hodei batera aldatzeko moduan.
Hasieran, zeregina gure azpiegitura osoa agnostikoa izatea zen, hau da, edozein hodei ondo egon beharko luke, baina noizbait negozioak amore eman zuen eta esan zuen: “Ados, hurrengo N urteetan ez gara inora joango, zerbitzutik erabil ditzakezu. Amazon ".
Terraform-ek Front-End lanak sortzeko, PagerDuty, datu-dokumentuak eta abar konfiguratzeko aukera ematen du. Isats asko ditu. Ia mundu osoa kontrola dezake.
Eskerrik asko erreportajeagatik! Orain 4 urte daramatzat Terraform biraka ere. Terraformerako, azpiegituretarako, deskribapen deklaratiborako trantsizio arin baten fasean, norbait eskuz zerbait egiten ari zen egoera baten aurrean geunden, eta zu plan bat egiten saiatzen zinen. Eta akatsen bat izan dut hor. Nola aurre egiten diezu horrelako arazoei? Nola aurkitzen dituzu adierazitako baliabide galduak?
Gehienbat eskuekin eta begiekin, erreportajean zerbait arraroa ikusten badugu, orduan bertan gertatzen dena aztertzen dugu, edo besterik gabe hil egiten dugu. Orokorrean, tira eskaerak gauza arruntak dira.
Errore bat badago, atzera egiten al duzu? Saiatu al zara hau egiten?
Ez, arazoa ikusten duen momentuan pertsona baten erabakia da.
Iturria: www.habr.com