Azpiegiturak kode gisa irudikatzea testu-formatu errepikagarrian praktikarik egokiena da saguekin nahastea behar ez duten sistemetarako. Praktika honek izena du - , eta orain arte ezartzeko bi tresna ezagun daude, batez ere AWSn: ΠΈ .
Terraform eta CloudFormation-ekin esperientzia alderatuz
Etorri aurretik (Aka ) Lan egin nuen eta hiru urtez erabili zuen Terraform. Leku berrian, Terraform ere erabili nuen nire indar guztiekin, eta, ondoren, konpainiak Amazonen denerako trantsizioa bultzatu zuen, CloudFormation barne. Bientzako praktika onak arduraz garatu ditut, eta bi tresnak erakunde osoko lan-fluxu konplexuetan erabili ditut. Geroago, Terraform-etik CloudFormation-era migratzearen ondorioak ondo neurtu ondoren, ziurrenik Terraform erakundearentzat aukerarik onena zela sinetsi nuen.
Terraform Horrible
Beta softwarea
Terraformek 1.0 bertsioa ere ez du kaleratu oraindik, eta hori ez erabiltzeko arrazoi ona da. Nik neuk probatu nuenetik asko aldatu da, baina orduan terraform apply askotan matxuratu egiten da hainbat eguneratzeren ondoren edo, besterik gabe, pare bat urte erabili ondoren. βOrain dena ezberdina delaβ esango nuke, baina... badirudi denek esaten dutena, ez? Badaude aurreko bertsioekin bateraezinak diren aldaketak, egokiak diren arren, eta baliabide biltegien sintaxia eta abstrakzioak orain behar ditugunak direla iruditzen zaigu. Tresna benetan hobetu dela dirudi, baina... :-0
Bestalde, AWS-k lan ona egin du atzerako bateragarritasuna mantenduz. Hau da, ziurrenik, haien zerbitzuak erakundearen barnean sakonki probatzen direlako eta orduan bakarrik, izena aldatuta, argitaratzen direlako. Beraz, "gogor saiatu ziren" gutxiespena da. AWS bezain anitza eta konplexua den sistema baterako APIekin atzerako bateragarritasuna mantentzea izugarri zaila da. Erabiltzen diren API publikoak mantendu behar izan dituenak ulertu beharko luke zein zaila den hainbeste urtetan hori egitea. Baina CloudFormation-en jokabidea, nire oroimenean, ez da inoiz aldatu urteetan zehar.
Ezagutu hanka... bala bat da
Dakidanez, ezabatu baliabidea kanpotarra Zure CF pilatik CloudFormation pila ez da posible. Gauza bera gertatzen da Terraform-ekin. Lehendik dauden baliabideak zure pilara inportatzeko aukera ematen dizu. Funtzioa harrigarria dela esan daiteke, baina botere handiarekin erantzukizun handia dakar. Baliabide bat pilara gehitu besterik ez duzu behar, eta zure pilarekin lanean ari zaren bitartean, ezin duzu baliabide hau ezabatu edo aldatu. Egun batean atzera egin zuen. Egun batean Twitch-en, norbaitek ustekabean beste norbaiten AWS segurtasun-taldea inportatu zuen bere Terraform pilara, inolako gaiztakeriarik egin gabe. Hainbat komando sartu nituen eta... segurtasun taldea (sarrerako trafikoarekin batera) desagertu egin zen.
Terraform Handia
Egoera osatugabeetatik berreskuratzea
Batzuetan, CloudFormation-ek huts egiten du egoera batetik bestera erabat igarotzen. Aldi berean, aurrekora itzultzen saiatuko da. Pena da hori beti bideragarria ez izatea. Nahiko beldurgarria izan daiteke geroago gertatutakoa araztea - inoiz ez dakizu CloudFormation pozik egongo den hackeatzen ari den ala ez - konpontzeko besterik ez bada ere. Aurreko egoerara itzultzea posible izango den ala ez, benetan ez daki nola zehazten eta, berez, orduz zintzilik dago mirari baten zain.
Terraformek, berriz, huts egindako trantsizioetatik askoz dotoreago berreskuratu ohi du eta arazketa tresna aurreratuak eskaintzen ditu.
Dokumentuaren egoeran aldaketa argiagoak
"Ongi da, karga-orekatzailea, aldatzen ari zara. Baina nola?"
βingeniari urduri, βonartuβ botoia sakatzeko prest.
Batzuetan, manipulazio batzuk egin behar ditut CloudFormation pilako karga-orekatzailearekin, adibidez, ataka-zenbaki bat gehitzea edo segurtasun-talde bat aldatzea. ClouFormation-ek aldaketak gaizki erakusten ditu. Nik, pin eta orratzetan, hamar aldiz egiaztatzen dut yaml fitxategia beharrezkoa ez dudala ezer ezabatu eta alferrikako ezer gehitu ez dudala ziurtatzeko.
Terraform askoz gardenagoa da zentzu honetan. Batzuetan gardenegia ere bada (irakurri: aspergarria). Zorionez, azken bertsioak aldaketen bistaratzea hobetu du, orain zer aldatzen ari den zehatz-mehatz ikus dezazun.
malgutasuna
Idatzi softwarea atzerantz.
Argi eta garbi esateko, iraupen luzeko softwarearen ezaugarririk garrantzitsuena aldaketetara egokitzeko gaitasuna da. Idatzi edozein software atzerantz. Gehienetan akatsak egiten nituen zerbitzu "sinple" bat hartuz, eta gero dena CloudFormation edo Terraform pila bakarrean sartzen hasi nintzen. Eta, jakina, hilabete geroago dena gaizki ulertu nuela agerian geratu zen, eta zerbitzua ez zen erraza izan! Eta orain pila handi bat osagai txikitan zatitu behar dut nolabait. CloudFormation-ekin lan egiten duzunean, lehendik dagoen pila birsortuz bakarrik egin daiteke, baina ez dut hori egiten nire datu-baseekin. Terraformek, berriz, posible egin zuen pila disekzionatu eta zati txiki ulergarriagoetan zatitzea.
Moduluak git-en
Terraform kodea hainbat pilatan partekatzea askoz errazagoa da CloudFormation kodea partekatzea baino. Terraform-ekin, zure kodea git biltegi batean jar dezakezu eta bertsio-kontrol semantikoa erabiliz atzitu dezakezu. Biltegi honetara sarbidea duen edonork berrerabili dezake partekatutako kodea. CloudFormation-en baliokidea S3 da, baina ez ditu onura berdinak, eta ez dago inolako arrazoirik git S3-ren alde alde batera utzi behar izateko.
Erakundea hazi egin zen eta pila komunak partekatzeko gaitasuna maila kritikora iritsi zen. Terraform-ek hau guztia erraza eta naturala egiten du, eta CloudFormation-ek, berriz, uztaietatik salto egingo zaitu, horrelako zerbait funtzionatzen hasi aurretik.
Eragiketak kode gisa
"Idatz dezagun gidoia eta ados."
βTerraform bizikleta asmatu baino 3 urte lehenago ingeniari bat.
Software garapenari dagokionez, Go edo Java programa bat ez da kodea soilik.
Kode Kode gisa
Lan egiten duen azpiegitura ere badago.
Azpiegitura Kode gisa
Baina nongoa da? Nola kontrolatu? Non bizi da zure kodea? Garatzaileek sarbide-baimena behar al dute?
Eragiketak Kode gisa
Software garatzailea izateak ez du kodea idaztea soilik esan nahi.
AWS ez da bakarra: ziurrenik beste hornitzaile batzuk erabiltzen dituzu. SignalFx, PagerDuty edo Github. Agian barneko Jenkins zerbitzari bat duzu CI/CDrako edo Grafana barruko panel bat monitorizatzeko. Infra as Code arrazoi ezberdinengatik aukeratzen da, eta bakoitza berdin garrantzitsua da softwarearekin zerikusia duen guztiarentzat.
Twitch-en lan egin nuenean, zerbitzuak bizkortu genituen Amazon-en txertatutako eta AWS sistema mistoen barruan. Mikrozerbitzu asko sortu eta onartzen ditugu, kostu operatiboak handituz. Eztabaidak honelakoak izan ziren:
- Π―: Arraioa, hori mikrozerbitzu bat overclock egiteko keinu asko da. Zabor hau erabili beharko dut AWS kontu bat sortzeko (bi kontutara joan ginen mikrozerbitzua), gero hau alertak konfiguratzeko, hau kode biltegi baterako, eta hau posta-zerrenda baterako, eta gero hau...
- Beruna: Egin dezagun gidoia eta ados.
- Π―: Ados, baina gidoia bera aldatuko da. Eraikitako Amazon gizmo horiek guztiak eguneratuta daudela egiaztatzeko modu bat beharko dugu.
- Beruna: Ondo entzuten da. Eta horretarako gidoia idatziko dugu.
- Π―: Bikaina! Eta ziurrenik scriptak parametroak ezarri beharko ditu. Onartuko al ditu?
- Beruna: Har dezala nora doan!
- Π―: Prozesua alda daiteke eta atzerako bateragarritasuna galduko da. Nolabaiteko bertsio-kontrol semantiko bat beharko da.
- Beruna: Ideia bikaina!
- Π―: Tresnak eskuz alda daitezke, erabiltzailearen interfazearen barruan. Hau egiaztatzeko eta konpontzeko modu bat beharko dugu.
β¦ 3 urte geroago:
- Beruna: Eta terraforma lortu genuen.
Istorioaren morala hau da: nahiz eta burutik gora Amazon guztian, oraindik AWSkoa ez den zerbait erabiltzen ari zara, eta zerbitzu hauek egoera hori sinkronizatuta mantentzeko konfigurazio-lengoaia erabiltzen duen egoera dute.
CloudFormation lambda vs git moduluak terraform
lambda da CloudFormation-ek logika pertsonalizatuaren arazoaren irtenbidea. Lambdarekin dezakezu edo . Planteamendu honek Terraformen git moduluen bertsio semantikoan ez dauden konplexutasun gehigarriak sartzen ditu. Niretzat, arazo larriena erabiltzaile lambda hauen guztien baimenak kudeatzea izan zen (eta AWSko dozenaka kontu dira hauek). Beste arazo garrantzitsu bat βzer etorri zen lehenengo, oilaskoa ala arrautza?β arazoa zen: lambda kodearekin zerikusia zuen. Funtzio hau bera azpiegitura eta kodea da, eta berak monitorizazioa eta eguneraketak behar ditu. Hilkutxako azken iltzea lambda kodearen aldaketak semantikoki eguneratzeko zailtasuna izan zen; halaber, ziurtatu behar izan dugu zuzeneko komandorik gabeko pila-ekintzak exekuzioen artean aldatzen ez zirela.
Gogoan dut behin Elastic Beanstalk ingurunerako kanariar inplementazio bat sortu nahi nuela karga-orekatzaile klasiko batekin. Errazena ekoizpen-ingurunearen ondoan EBren bigarren inplementazioa egitea izango litzateke, urrats bat gehiago emanez: auto-eskalako canary inplementazio taldea eta inplementazioaren LB ekoizpen-ingurunean konbinatzea. Eta Terraformek erabiltzen duenez , horretarako 4 kode-lerro gehigarri beharko ditu Terraform-en. CloudFormation-en konponbide konparagarririk ba ote zegoen galdetu nionean, git biltegi oso batera seinalatu zidaten inplementazio kanalizazio batekin eta guzti, dena Terraform kode eskasaren 4 lerro eskasak egin ditzakeen zerbaitengatik.
Noraeza hobeto antzematen du
Ziurtatu errealitatea itxaropenekin bat datorrela.
Kode funtzio gisa oso eragiketa indartsua da, errealitatea itxaropenekin bat datorrela ziurtatzen laguntzen baitu. CloudFormation eta Terraform-ekin eskuragarri dago. Baina ekoizpen-pila hazi ahala, CloudFormation-en noraeza bilatzea gero eta detekzio faltsu gehiago sortu zen.
Terraform-ekin bizi-zikloko kako askoz aurreratuagoak dituzu noraeza detektatzeko. Adibidez, komandoa sartzen duzu zuzenean ECS atazen definizioan, zeregin zehatz baten definizioko aldaketak baztertu nahi badituzu zure ECS inplementazio osoko aldaketak alde batera utzi gabe.
CDK eta CloudFormation-en etorkizuna
CloudFormation zaila da kudeatzea azpiegitura arteko eskala handietan. Zailtasun horietako asko aitortzen dira eta tresnak bezalako gauzak behar ditu , hodeiko azpiegitura kodean definitzeko eta AWS CloudFormation bidez exekutatzeko esparru bat. Interesgarria izango da aws-cdk-i etorkizuna zer den ikustea, baina zaila izango da Terraformen beste indarguneekin lehiatzea; CloudFormation eguneratzeko, aldaketa globalak beharko dira.
Beraz, Terraformek ez du hutsik egiten
Hau da "azpiegitura kode gisa", eta ez "testu gisa".
Terraform-i buruz nuen lehen inpresioa txarra izan zen. Uste dut ez nuela planteamendua ulertu. Ia ingeniari guztiek nahi gabe hautematen dute nahi den azpiegitura bihurtu behar den testu formatu gisa. EZ EGIN HONELA.
Software garapen onaren truismoak Terraform-i ere aplikatzen zaizkio.
Terraform-en kode ona sortzeko praktika asko hartzen direla ikusi dut. Urte luzez ikasi duzu programatzaile on bat izateko. Ez utzi esperientzia honi Terraform-ekin lan egiten ari zarelako. Software garapen onaren truismoak Terraform-i aplikatzen zaizkio.
Nola ez da kodea dokumentatu?
Terraform pila handiak ikusi ditut dokumentaziorik gabe. Nola idatzi dezakezu kodea orrietan, dokumentaziorik gabe? Gehitu zurea azaltzen duen dokumentazioa kodea Terraform ("kode" hitza azpimarratzen da), zergatik den hain garrantzitsua atal hau eta zer egiten duzun.
Nola zabaldu dezakegu garai batean main() funtzio handi bat ziren zerbitzuak?
Modulu bakar gisa aurkezten diren Terraform pila oso konplexuak ikusi ditut. Zergatik ez dugu softwarea modu honetan zabaltzen? Zergatik zatitzen ditugu funtzio handiak txikiagoetan? Erantzun berdinak Terraform-i aplikatzen zaizkio. Zure modulua handiegia bada, modulu txikiagoetan banatu behar duzu.
Zure enpresak ez al ditu liburutegiak erabiltzen?
Ikusi dut nola ingeniariek, Terraform erabiliz proiektu berri bat sortuz, nola ergelki kopiatu eta itsatsi zituzten beste proiektuetako zati erraldoiak beren kabuz, eta gero haiekin moldatu zituzten lanean hasi zen arte. Horrela lan egingo zenuke zure enpresan "borroka" kodearekin? Ez ditugu liburutegiak soilik erabiltzen. Bai, baina non gaude printzipioz liburutegi partekaturik gabe?!
Ez al duzu PEP8 edo gofmt erabiltzen?
Hizkuntza gehienek formatu-eskema estandarra eta onartua dute. Python-en hau PEP8 da. Go - gofmt-en. Terraform-ek berea du: terraform fmt. Gozatu zure osasunagatik!
Erabiliko al duzu React JavaScript ezagutu gabe?
Terraform moduluek sortzen duzun azpiegitura konplexuaren zatiren bat sinplifikatu dezakete, baina horrek ez du esan nahi horrekin batere moldatu ezin denik. Terraform behar bezala erabili nahi duzu baliabideak ulertu gabe? Kondenatuta zaude: denbora pasatuko da, eta inoiz ez duzu Terraform menderatuko.
Singleton edo menpekotasun injekzioarekin kodetzen ari zara?
Mendekotasun-injekzioa software-garapenerako praktikarik onena da eta hobesten da singletonen aurrean. Nola da erabilgarria Terraform-en? Urruneko egoeraren araberakoak diren Terraform moduluak ikusi ditut. Urruneko egoera berreskuratzen duten moduluak idatzi beharrean, idatzi parametroak hartzen dituen modulua. Eta gero parametro hauek moduluari pasa.
Zure liburutegiek hamar gauza ondo egiten dituzte ala gauza bat bikain?
Ondoen funtzionatzen duten liburutegiak oso ondo egiten duten zeregin batean zentratzen direnak dira. Dena aldi berean egiten saiatzen diren Terraform modulu handiak idatzi beharrean, eraiki gauza bat ondo egiten duten zatiak. Eta gero konbinatu behar den moduan.
Nola egin aldaketak liburutegietan atzerako bateragarritasunik gabe?
Terraform modulu arrunt batek, ohiko liburutegi batek bezala, nolabait erabiltzaileei aldaketak helarazi behar dizkie atzerako bateragarriak izan gabe. Aldaketa hauek liburutegietan gertatzen direnean gogaikarria da eta Terraform moduluetan atzera-bateragarriak ez diren aldaketak egiten direnean bezain gogaikarria da. Terraform moduluak erabiltzean git etiketak eta semver erabiltzea gomendatzen da.
Zure ekoizpen-zerbitzua zure ordenagailu eramangarrian edo datu-zentro batean exekutatzen al da?
Hashicorp-ek bezalako tresnak ditu zure terraforma exekutatzeko. Zerbitzu zentralizatu hauek terraformaren aldaketak kudeatzea, ikuskatzea eta onartzea errazten dute.
Ez al dituzu probak idazten?
Ingeniariek onartzen dute kodea probatu behar dela, baina beraiek sarritan ahaztu egiten dituzte probak Terraform-ekin lan egiten dutenean. Azpiegituretarako, une traidorez beteta dago. Nire aholkua da pilak "probatu" edo "adibidez sortzea" CI/CD-an probak egiteko behar bezala inplementa daitezkeen moduluak erabiliz.
Terraform eta mikrozerbitzuak
Mikrozerbitzuen enpresen bizitza eta heriotza mikrozerbitzuen lan pila berrien abiaduraren, berrikuntzaren eta etenaren araberakoa da.
Mikrozerbitzuen arkitekturekin lotutako alderdi negatibo ohikoena, eta ezabatu ezin dena, lanari dagokio, ez kodeari. Terraform mikrozerbitzuen arkitektura baten azpiegituraren aldea automatizatzeko modu bat besterik ez dela uste baduzu, sistemaren benetako abantailak galtzen ari zara. Orain dagoeneko dago .
Iturria: www.habr.com