Duket se zhvilluesit e Terraform ofrojnë praktika më të mira mjaft të përshtatshme për të punuar me infrastrukturën AWS. Ka vetëm një nuancë. Me kalimin e kohës, numri i mjediseve rritet, secili me veçoritë e veta. Pothuajse një kopje e pirgut të aplikacionit shfaqet në rajonin fqinj. Dhe kodi Terraform duhet të kopjohet dhe modifikohet me kujdes sipas kërkesave të reja ose të bëhet një flok dëbore.
Raporti im për modelet në Terraform për të luftuar kaosin dhe rutinën manuale në projekte të mëdha dhe të gjata.
Video:
Unë jam 40 vjeç, kam 20 vjet që jam në IT. Unë kam 12 vjet që punoj për Ixtens. Ne jemi të angazhuar në zhvillimin e bazuar në tregtinë elektronike. Dhe unë kam praktikuar praktikat DevOps për 5 vjet.
Historia ime do të jetë për përvojën time në një projekt në një kompani, emrin e së cilës nuk do ta them, duke u fshehur pas një marrëveshjeje moszbulimi.
Numrat në sllajd tregohen për të kuptuar shkallën e projektit. Dhe gjithçka që do të them më pas ka të bëjë me Amazon.
Unë iu bashkua këtij projekti 4 vjet më parë. Dhe rifaktorimi i infrastrukturës ishte në lëvizje të plotë sepse projekti ishte rritur. Dhe modelet që u përdorën nuk ishin më të përshtatshme. Dhe duke pasur parasysh të gjithë rritjen e planifikuar të projektit, ishte e nevojshme të dilte me diçka të re.
Faleminderit Matvey, i cili dje na tregoi se çfarë ndodhi në Dodo Pizza. Kjo është ajo që ndodhi këtu 4 vjet më parë.
Zhvilluesit erdhën dhe filluan të bëjnë kodin e infrastrukturës.
Arsyet më të dukshme pse kjo kërkohej ishte koha për të tregtuar. Ishte e nevojshme të sigurohej që ekipi i DevOps të mos ishte një pengesë gjatë prezantimit. Dhe ndër të tjera, Terraform dhe Puppet u përdorën në nivelin e parë.
Terraform është një projekt me burim të hapur nga HashiCorp. Dhe për ata që as nuk e dinë se çfarë është kjo, rrëshqitjet e ardhshme.
Infrastruktura si kod do të thotë që ne mund të përshkruajmë infrastrukturën tonë dhe të kërkojmë nga disa robotë të sigurohen që ne të marrim burimet që përshkruam.
Për shembull, na duhet një makinë virtuale. Ne do të përshkruajmë dhe shtojmë disa parametra të kërkuar.
Pas kësaj, ne do të konfigurojmë hyrjen në Amazon në tastierë. Dhe ne do të kërkojmë planin Terraform. Plani Terraform do të thotë: "Në rregull, ne mund t'i bëjmë këto gjëra për burimin tuaj." Dhe të paktën një burim do të shtohet. Dhe nuk priten ndryshime.
Pasi të jeni të kënaqur me gjithçka, mund t'i kërkoni Terraform-it të aplikojë dhe Terraform do të krijojë një shembull për ju dhe do të merrni një makinë virtuale në renë tuaj kompjuterike.
Më tej projekti ynë po zhvillohet. Ne po shtojmë disa ndryshime atje. Ne kërkojmë më shumë raste, shtojmë 53 hyrje.
Dhe ne përsërisim. Ju lutemi planifikoni. Ne shohim se çfarë ndryshimesh janë planifikuar. Ne aplikojmë. Dhe kështu rritet infrastruktura jonë.
Terraform përdor diçka të quajtur skedarë të gjendjes. Domethënë, ai ruan të gjitha ndryshimet që shkojnë në Amazon në një skedar ku për çdo burim që përshkruat, ka burime përkatëse që janë krijuar në Amazon. Kështu, kur përshkrimi i një burimi ndryshon, Terraform e di saktësisht se çfarë duhet ndryshuar në Amazon.
Këto skedarë të gjendjes fillimisht ishin vetëm skedarë. Dhe ne i ruajmë ato në Git, gjë që ishte jashtëzakonisht e papërshtatshme. Dikush harronte gjithmonë të bënte ndryshime dhe lindën shumë konflikte.
Tani është e mundur të përdoret backend, d.m.th. Terraform specifikohet se në cilën kovë dhe me cilin çelës duhet të ruhet skedari i gjendjes. Dhe vetë Terraform do të kujdeset për të marrë këtë dosje shtetërore, duke bërë të gjithë magjinë dhe për të rikthyer rezultatin përfundimtar.
Infrastruktura jonë po rritet. Këtu është kodi ynë. Dhe tani ne nuk duam vetëm të krijojmë një makinë virtuale, ne duam të kemi një mjedis testimi.
Terraform ju lejon të krijoni një gjë të tillë si një modul, domethënë të përshkruani të njëjtën gjë në një dosje.
Dhe, për shembull, në testim, telefononi këtë modul dhe merrni të njëjtën gjë sikur të kishim ekzekutuar Terraform application në vetë modulin. Për testim do të ketë këtë kod.
Për prodhimin, ne mund të dërgojmë disa ndryshime atje, sepse në testim nuk kemi nevojë për instanca të mëdha; në prodhim, instancat e mëdha janë thjesht të dobishme.
Dhe më pas do t'i rikthehem projektit. Ishte një detyrë e vështirë, infrastruktura e planifikuar ishte shumë e madhe. Dhe ishte e nevojshme që disi të vendosej i gjithë kodi në mënyrë që të ishte i përshtatshëm për të gjithë: si për ata që kryejnë mirëmbajtje në këtë kod, ashtu edhe për ata që bëjnë ndryshime. Dhe ishte planifikuar që çdo zhvillues të mund të shkonte dhe të rregullonte infrastrukturën sipas nevojës për pjesën e tij të platformës.
Kjo është një pemë drejtorie që rekomandohet nga vetë HashiCorp nëse keni një projekt të madh dhe ka kuptim të ndani të gjithë infrastrukturën në disa pjesë të vogla dhe të përshkruani secilën pjesë në një dosje të veçantë.
Duke pasur një bibliotekë të gjerë burimesh, mund të telefononi afërsisht të njëjtën gjë në testim dhe në prodhim.
Në rastin tonë, kjo nuk ishte plotësisht e përshtatshme, sepse pirgja e provës për zhvilluesit ose për testim duhej të merrej disi më e thjeshtë. Por nuk doja të kaloja nëpër dosje dhe t'i zbatoja ato në sekuencën e kërkuar dhe të shqetësohesha se baza e të dhënave do të ngrihej dhe më pas do të ngrihej shembulli që përdor këtë bazë të dhënash. Prandaj, të gjitha testimet u nisën nga një dosje. Aty u thirrën të njëjtat module, por gjithçka u bë në një drejtim.
Terraform kujdeset për të gjitha varësitë. Dhe gjithmonë krijon burime në sekuencë, në mënyrë që të mund të merrni një adresë IP, për shembull, nga një shembull i sapokrijuar, dhe ta merrni këtë adresë IP në rekordin route53.
Përveç kësaj, platforma është shumë e madhe. Dhe nisja e një pirg testimi, qoftë edhe për një orë, qoftë edhe për 8 orë, është një ndërmarrje mjaft e shtrenjtë.
Dhe ne e automatizuam këtë çështje. Dhe puna e Jenkins na lejoi të drejtonim pirgun. Në të, ishte e nevojshme të lëshohej një kërkesë tërheqëse me ndryshimet që zhvilluesi dëshiron të testojë, të specifikojë të gjitha opsionet, përbërësit dhe dimensionet e nevojshme. Nëse ai dëshiron testimin e performancës, atëherë ai mund të marrë më shumë raste. Nëse ai thjesht duhet të kontrollojë nëse hapet ndonjë formular, atëherë ai mund të fillojë me pagën minimale. Dhe gjithashtu tregoni nëse një grup është i nevojshëm apo jo, etj.
Dhe më pas Jenkins shtyu një skript shell, i cili modifikoi pak kodin në dosjen Terraform. I hoqa skedarët e panevojshëm dhe shtova skedarët e nevojshëm. Dhe pastaj me një ekzekutim të Terraform aplikoni pirg u ngrit.
Dhe pastaj kishte hapa të tjerë në të cilët nuk dua të shkoj.
Për faktin se për testim na duheshin pak më shumë opsione sesa në prodhim, na u desh të bënim kopje të moduleve në mënyrë që në këto kopje të shtonim ato veçori që duheshin vetëm për testim.
Dhe kështu ndodhi që gjatë testimit dua të testoj ato ndryshime që përfundimisht do të hyjnë në prodhim. Por në fakt, një gjë u testua, dhe një gjë paksa e ndryshme u përdor në prodhim. Dhe pati një thyerje të vogël në modelin që në prodhim të gjitha ndryshimet u aplikuan nga ekipi i operimit. Dhe ndonjëherë doli që ato ndryshime që supozohej të kalonin nga testimi në prodhim mbetën në një version tjetër.
Për më tepër, kishte një problem të tillë që u shtua një shërbim i ri, i cili ishte paksa i ndryshëm nga disa ekzistues. Dhe në vend që të modifikonim një modul ekzistues, ne duhej të bënim një kopje të tij dhe të shtonim ndryshimet e nevojshme.
Në thelb, Terraform nuk është një gjuhë e vërtetë. Kjo është një deklaratë. Nëse duhet të deklarojmë diçka, atëherë e deklarojmë atë. Dhe gjithçka funksionon.
Në një moment, kur po diskutohej një nga kërkesat e mia për tërheqje, një nga kolegët e mi tha se nuk kishte nevojë të krijonte bore. Pyesja veten se çfarë donte të thoshte. Ekziston një fakt shkencor se nuk ka dy fjolla identike në botë, të gjitha janë paksa të ndryshme. Dhe sapo e dëgjova këtë, ndjeva menjëherë peshën e plotë të kodit Terraform. Sepse kur ishte e nevojshme të kalonte nga versioni në version, Terraform kërkonte ndryshime të zinxhirit të ndërprerjes, d.m.th. kodi nuk ishte më i pajtueshëm me versionin tjetër. Dhe na u desh të bënim një kërkesë tërheqjeje, e cila mbulonte pothuajse gjysmën e skedarëve në infrastrukturë, për të sjellë infrastrukturën në versionin tjetër të Terraform.
Dhe pasi u shfaq një fjollë e tillë dëbore, i gjithë kodi Terraform që kishim u shndërrua në një grumbull të madh e të madh bore.
Për një zhvillues të jashtëm që është jashtë operacionit, kjo nuk ka shumë rëndësi për të, sepse ai bëri një kërkesë tërheqjeje, burimi i tij filloi. Dhe kjo është e gjitha, nuk është më shqetësimi i tij. Dhe ekipi i DevOps, i cili sigurohet që gjithçka është në rregull, kërkohet të bëjë të gjitha këto ndryshime. Dhe kostoja e këtyre ndryshimeve u rrit shumë, shumë me çdo fjollë dëbore shtesë.
Ekziston një histori se si një student në një seminar vizaton dy rrathë të përsosur me shkumës në dërrasën e zezë. Dhe mësuesi habitet se si arriti të vizatonte kaq mirë pa busull. Studenti përgjigjet: "Shumë e thjeshtë, kam kaluar dy vjet në ushtri duke kthyer një mulli mishi."
Dhe nga katër vitet që jam përfshirë në këtë projekt, kam rreth dy vjet që merrem me Terraform. Dhe, sigurisht, kam disa truke, disa këshilla se si të thjeshtoni kodin Terraform, të punoni me të si një gjuhë programimi dhe të zvogëloni barrën e zhvilluesve që duhet ta mbajnë këtë kod të përditësuar.
Gjëja e parë me të cilën do të doja të filloja është Symlinks. Terraform ka shumë kode të përsëritura. Për shembull, thirrja ndaj ofruesit pothuajse në çdo pikë ku krijojmë një pjesë të infrastrukturës është e njëjtë. Dhe është logjike ta vendosni në një dosje të veçantë. Dhe kudo që ofruesi kërkohet të krijojë Symlinks në këtë skedar.
Për shembull, në prodhim përdorni rolin e supozimit, i cili ju lejon të fitoni të drejta aksesi në një llogari të jashtme të Amazon. Dhe pasi të keni ndryshuar një skedar, të gjitha ato që mbeten në pemën e burimeve do të kenë të drejtat e kërkuara në mënyrë që Terraform të dijë se në cilin segment të Amazon duhet të qaset.
Ku dështojnë Symlinks? Siç thashë, Terraform ka dosje shtetërore. Dhe ata janë shumë, shumë të lezetshëm. Por gjëja është se Terraform inicializon backend-in në radhë të parë. Dhe ai nuk mund të përdorë asnjë ndryshore në këto parametra; ato duhet të shkruhen gjithmonë në tekst.
Dhe si rezultat, kur dikush krijon një burim të ri, ai kopjon disa nga kodet nga dosjet e tjera. Dhe ai mund të bëjë një gabim me çelësin ose me kovën. Për shembull, ai bën një send sandbox nga sandbox, dhe pastaj e bën atë në prodhim. Dhe kështu mund të rezultojë që kova në prodhim do të përdoret nga kutia e rërës. Sigurisht, ata do ta gjejnë shpejt. Kjo do të jetë e mundur të rregullohet disi, por megjithatë është humbje kohe dhe, deri diku, burime.
Çfarë mund të bëjmë më pas? Para se të punoni me Terraform, duhet ta inicializoni atë. Në fillimin, Terraform shkarkon të gjitha shtojcat. Në një moment ata u ndanë nga një monolit në një arkitekturë më mikroservice. Dhe gjithmonë duhet të bëni Terraform init në mënyrë që të tërheqë të gjitha modulet, të gjitha shtojcat.
Dhe mund të përdorni një skript shell, i cili, së pari, mund të marrë të gjitha variablat. Skenari i guaskës nuk është i kufizuar në asnjë mënyrë. Dhe së dyti, shtigjet. Nëse gjithmonë përdorim shtegun që është në depo si çelës për skedarin e gjendjes, atëherë, në përputhje me rrethanat, gabimi këtu do të eliminohet.
Ku mund t'i marr të dhënat? skedar JSON. Terraform ju lejon të shkruani infrastrukturë jo vetëm në hcl (HashiCorp Configuration Language), por edhe në JSON.
JSON është i lehtë për t'u lexuar nga një skrip shell. Prandaj, mund ta vendosni skedarin e konfigurimit me kovë në një vend. Dhe përdorni këtë kovë si në kodin Terraform ashtu edhe në skriptin e guaskës për inicializimin.
Pse është e rëndësishme të kesh një kovë për Terraform? Sepse ekziston një gjë e tillë si skedarët e gjendjes në distancë. Kjo do të thotë, kur ngre një burim, në mënyrë që t'i them Amazon: "Ju lutemi ngrini shembullin", më duhet të specifikoj shumë parametra të kërkuar.
Dhe këta identifikues ruhen në një dosje tjetër. Dhe unë mund të shkoj dhe të them: "Terraform, ju lutem vraponi në dosjen shtetërore të atij burimi dhe më merrni këto identifikues." Dhe kështu shfaqet një bashkim i caktuar midis rajoneve ose mjediseve të ndryshme.
Nuk është gjithmonë e mundur të përdoret një skedar shtetëror në distancë. Për shembull, keni krijuar një VPC me dorë. Dhe kodi Terraform që krijon VPC krijon VPC aq të ndryshme sa do të duhet një kohë shumë e gjatë dhe do t'ju duhet të përshtatni njërën me tjetrën, kështu që mund të përdorni trukun e mëposhtëm.
Kjo do të thotë, bëni një modul që duket se krijon një VPC dhe, si të thuash, ju jep identifikues, por në fakt ekziston thjesht një skedar me vlera të koduara që mund të përdoret për të krijuar të njëjtin shembull.
Nuk është gjithmonë e nevojshme të ruani skedarin e gjendjes në cloud. Për shembull, kur testoni module, mund të përdorni inicializimin e backend-it, ku skedari thjesht do të ruhet në disk në momentin e testimit.
Tani pak për testimin. Çfarë mund të testoni në Terraform? Ndoshta shumë është e mundur, por unë do të flas për këto 4 gjëra.
HashiCorp ka një kuptim se si duhet të formatohet kodi Terraform. Dhe Terraform fmt ju lejon të formatoni kodin që redaktoni sipas këtij besimi. Prandaj, testet duhet domosdoshmërisht të kontrollojnë nëse formatimi korrespondon me atë që la trashëgim HashiCorp, në mënyrë që të mos ketë nevojë të ndryshoni vendndodhjen e kllapave, etj.
Tjetri është verifikimi i Terraform. Ai bën pak më shumë sesa kontrollon sintaksën - ala, nëse të gjitha kllapat janë çiftuar. Çfarë është e rëndësishme këtu? Infrastruktura jonë është shumë e gjerë. Ka shumë baballarë të ndryshëm në të. Dhe në secilën prej tyre duhet të ekzekutoni verifikimin e Terraform.
Prandaj, për të përshpejtuar testimin, ne drejtojmë procese të shumta paralelisht duke përdorur paralelisht.
Paraleli është një gjë shumë e lezetshme, përdorni atë.
Por sa herë që Terraform inicializohet, ai shkon te HashiCorp dhe pyet: “Cilat janë versionet më të fundit të shtojcave? Dhe shtojca që kam në cache – është e duhura apo e gabuar?” Dhe kjo ngadalësohej në çdo hap.
Nëse i tregoni Terraform se ku janë shtojcat, atëherë Terraform do të thotë: “Mirë, kjo është ndoshta gjëja më e fundit që është atje. Unë nuk do të shkoj askund, do të filloj menjëherë të verifikoj kodin tuaj Terraform."
Për të mbushur dosjen me shtojcat e nevojshme, ne kemi një kod shumë të thjeshtë Terraform që thjesht duhet të inicializohet. Këtu, natyrisht, duhet të specifikoni të gjithë ofruesit që marrin pjesë disi në kodin tuaj, përndryshe Terraform do të thotë: "Unë nuk njoh një ofrues të caktuar sepse nuk është në cache".
Tjetra është plani Terraform. Siç thashë, zhvillimi është ciklik. Ne bëjmë ndryshime në kod. Dhe më pas duhet të zbuloni se çfarë ndryshimesh janë planifikuar për infrastrukturën.
Dhe kur infrastruktura është shumë, shumë e madhe, ju mund të ndryshoni një modul, të rregulloni një mjedis testimi ose një rajon specifik dhe të prishni një tjetër fqinj. Prandaj, plani Terraform duhet të bëhet për të gjithë infrastrukturën dhe të tregojë se çfarë ndryshimesh janë planifikuar.
Ju mund ta bëni këtë me zgjuarsi. Për shembull, ne kemi shkruar një skript Python që zgjidh varësitë. Dhe në varësi të asaj që është ndryshuar: një modul Terraform ose thjesht një komponent specifik, ai bën plane për të gjitha dosjet e varura.
Planet Terraform duhet të bëhen sipas kërkesës. Të paktën kështu bëjmë ne.
Sigurisht, është mirë të bësh teste për çdo ndryshim, për çdo angazhim, por planet janë një gjë mjaft e shtrenjtë. Dhe në një kërkesë tërheqëse ne themi, "Ju lutem më jepni planet." Roboti fillon. Dhe dërgon në komente ose bashkëngjit të gjitha planet që priten nga ndryshimet tuaja.
Një plan është një gjë mjaft e shtrenjtë. Duhet kohë sepse Terraform shkon në Amazon dhe pyet: “A ekziston ende ky shembull? A ka kjo shkallë automatike saktësisht të njëjtat parametra?” Dhe për ta përshpejtuar këtë, mund të përdorni një parametër të tillë si refresh=false. Kjo do të thotë që Terraform do të shkarkojë gjendjen nga S3. Dhe do të besojë se shteti do të përputhet saktësisht me atë që është në Amazon.
Një plan i tillë Terraform shkon shumë më shpejt, por gjendja duhet të korrespondojë me infrastrukturën tuaj, pra diku, diku duhet të fillojë rifreskimi i Terraform. Rifreskimi i Terraform bën pikërisht këtë: gjendja përputhet me atë që është në infrastrukturën aktuale.
Dhe ne duhet të flasim për sigurinë. Këtu duhej të fillonim. Aty ku ekzekutoni Terraform dhe Terraform funksionon në infrastrukturën tuaj, ka një cenueshmëri. Kjo do të thotë, ju në thelb po ekzekutoni kodin. Dhe nëse kërkesa për tërheqje përmban një lloj kodi me qëllim të keq, atëherë ai mund të ekzekutohet në një infrastrukturë që ka shumë akses. Pra, kini kujdes se ku e zbatoni planin Terraform.
Gjëja tjetër për të cilën do të doja të flisja është testimi i të dhënave të përdoruesit.
Çfarë janë të dhënat e përdoruesit? Në Amazon, kur krijojmë një shembull, mund të dërgojmë një letër të caktuar me shembullin - meta data. Kur shembulli fillon, zakonisht init cloud është gjithmonë i pranishëm në këto raste. Cloud init lexon këtë letër dhe thotë: "Ok, sot jam balancuesi i ngarkesës". Dhe në përputhje me këto besëlidhje ai kryen disa veprime.
Por, për fat të keq, kur bëjmë planin Terraform dhe zbatojmë Terraform, të dhënat e përdoruesve duken si ky lloj grumbulli numrash. Kjo është, ai thjesht ju dërgon hash. Dhe gjithçka që mund të shikoni në plan është nëse do të ketë ndonjë ndryshim apo nëse hash-i do të mbetet i njëjtë.
Dhe nëse nuk i kushtoni vëmendje kësaj, atëherë një skedar teksti i prishur mund të përfundojë në Amazon, në infrastrukturën reale.
Përndryshe, gjatë ekzekutimit, mund të specifikoni jo të gjithë infrastrukturën, por vetëm shabllonin. Dhe në kod thoni: "Ju lutemi shfaqni këtë shabllon në ekranin tim." Dhe si rezultat, mund të merrni një printim se si do të duken të dhënat tuaja në Amazon.
Një opsion tjetër është përdorimi i një moduli për të gjeneruar të dhëna të përdoruesit. Ju do të aplikoni këtë modul. Ju e merrni skedarin në disk. Krahasoni atë me atë referencë. Dhe kështu, nëse një djalë vendos të korrigjojë pak të dhënat e përdoruesit, atëherë testet tuaja do të thonë: "OK, ka disa ndryshime këtu dhe atje - kjo është normale."
Gjëja tjetër për të cilën do të doja të flisja është Automate Terraform.
Sigurisht, është shumë e frikshme të aplikosh Terraform në modalitetin automatik, sepse kush e di se çfarë ndryshimesh kanë ardhur atje dhe sa shkatërruese mund të jenë ato për infrastrukturën e gjallë.
Për një mjedis testimi, kjo është e gjitha normale. Kjo do të thotë, një punë që krijon një mjedis testimi është ajo që u nevojitet të gjithë zhvilluesve. Dhe një shprehje e tillë si "çdo gjë funksionoi për mua" nuk është një meme qesharake, por dëshmi se një person u hutua, ngriti një pirg dhe bëri disa teste në këtë pirg. Dhe ai u sigurua që gjithçka ishte mirë atje dhe tha: "Në rregull, kodi që po lëshoj është testuar."
Në prodhim, sandbox dhe mjedise të tjera që janë më kritike për biznesin, ju mund të përdorni pjesërisht disa burime mjaft të sigurta, sepse nuk rezulton në vdekjen e askujt. Këto janë: grupet automatike, grupet e sigurisë, rolet, rruga53 dhe lista atje mund të jetë mjaft e madhe. Por mbani një sy në atë që po ndodh, lexoni raportet e automatizuara të aplikacioneve.
Aty ku është e rrezikshme ose e frikshme të aplikohet, për shembull, nëse këto janë disa burime të vazhdueshme nga një bazë të dhënash, atëherë merrni raporte se ka ndryshime të pazbatuara në një pjesë të infrastrukturës. Dhe inxhinieri, nën mbikëqyrje, fillon punë për të aplikuar ose e bën atë nga tastiera e tij.
Amazon ka një gjë të tillë si Mbrojtja e Ndërprerjes. Dhe mund të mbrojë në disa raste nga ndryshimet që nuk kërkohen për ju. Kjo do të thotë, Terraform shkoi në Amazon dhe tha: "Më duhet ta vras këtë shembull për të krijuar një tjetër." Dhe Amazon thotë: “Më falni, jo sot. Ne kemi mbrojtjen e ndërprerjes."
Dhe qershia mbi tortë është optimizimi i kodit. Kur punojmë me kodin Terraform, duhet t'i kalojmë modulit një numër shumë të madh parametrash. Këto janë parametrat që janë të nevojshëm për të krijuar një lloj burimi. Dhe kodi kthehet në lista të mëdha parametrash që duhet të kalohen nga moduli në modul, nga moduli në modul, veçanërisht nëse modulet janë të ndërthurur.
Dhe është shumë e vështirë për t'u lexuar. Është shumë e vështirë ta rishikosh këtë. Dhe shumë shpesh rezulton se disa parametra i nënshtrohen rishikimit dhe ato nuk janë saktësisht ato që nevojiten. Dhe kjo kushton kohë dhe para për ta rregulluar më vonë.
Prandaj, ju sugjeroj të përdorni një gjë të tillë si një parametër kompleks që përfshin një pemë të caktuar vlerash. Kjo do të thotë, ju duhet një lloj dosjeje ku të keni të gjitha vlerat që dëshironi të keni në një mjedis.
Dhe duke thirrur këtë modul, ju mund të merrni një pemë që gjenerohet në një modul të përbashkët, domethënë në një modul të përbashkët që funksionon njësoj për të gjithë infrastrukturën.
Në këtë modul mund të bëni disa llogaritje duke përdorur një veçori të tillë të fundit në Terraform si vendas. Dhe më pas, me një dalje, jepni një parametër kompleks, i cili mund të përfshijë hash grupesh, etj.
Këtu kanë përfunduar të gjitha gjetjet më të mira që kam. Dhe unë do të doja të tregoja një histori për Kolombin. Kur ai po kërkonte para për ekspeditën e tij për të zbuluar Indinë (siç mendonte atëherë), askush nuk e besoi dhe menduan se ishte e pamundur. Pastaj tha: "Sigurohuni që veza të mos bjerë." Të gjithë bankierët, njerëz shumë të pasur dhe ndoshta të zgjuar, u përpoqën ta vendosnin disi vezën dhe ajo vazhdoi të binte. Pastaj Kolombi mori vezën dhe e shtypi pak. Lëvozhga u thërrmua dhe veza mbeti e palëvizshme. Ata thanë: "Oh, kjo është shumë e lehtë!" Dhe Kolombi u përgjigj: "Po, është shumë e thjeshtë. Dhe kur të hap Indinë, të gjithë do të përdorin këtë rrugë tregtare."
Dhe ajo që sapo ju thashë është ndoshta gjëra mjaft të thjeshta dhe të parëndësishme. Dhe kur mësoni rreth tyre dhe filloni t'i përdorni, është në rendin e gjërave. Pra përfitoni. Dhe nëse këto janë gjëra krejtësisht normale për ju, atëherë të paktën dini si ta vendosni vezën që të mos bjerë.
Le të përmbledhim:
- Mundohuni të shmangni flokët e borës. Dhe sa më pak flokë bore, aq më pak burime do t'ju nevojiten për të bërë ndonjë ndryshim në të gjithë infrastrukturën tuaj të madhe.
- Ndryshime të vazhdueshme. Kjo do të thotë, kur ndodhin disa ndryshime në kod, ju duhet të sillni infrastrukturën tuaj në përputhje me këto ndryshime sa më shpejt të jetë e mundur. Nuk duhet të ketë një situatë kur dikush vjen për të parë Elasticsearch dy ose tre muaj më vonë, bën një plan Terraform dhe ka një mori ndryshimesh që ai nuk i priste. Dhe duhet shumë kohë për të vendosur gjithçka në rregull.
- Testet dhe automatizimi. Sa më shumë kodi juaj të jetë i mbuluar me teste dhe veçori, aq më shumë besim keni se po bëni gjithçka në mënyrë korrekte. Dhe dorëzimi automatik do të rrisë besimin tuaj shumë herë.
- Kodi për mjediset e testimit dhe prodhimit duhet të jetë pothuajse i njëjtë. Praktikisht, sepse prodhimi është ende pak më ndryshe dhe do të ketë ende disa nuanca që do të shkojnë përtej mjedisit të testimit. Por megjithatë, plus ose minus, kjo mund të sigurohet.
- Dhe nëse keni shumë kode Terraform dhe ju duhet shumë kohë për ta mbajtur këtë kod të përditësuar, atëherë nuk është kurrë vonë për ta rindërtuar dhe për ta vendosur atë në gjendje të mirë.
- Infrastruktura e pandryshueshme. Dorëzimi AMI sipas planit.
- Struktura për route53 kur keni shumë hyrje dhe dëshironi që ato të jenë në një rend të qëndrueshëm.
- Luftimi i kufijve të normës së API. Kjo është kur Amazon thotë, "Kjo është ajo, nuk mund të pranoj më kërkesa, ju lutem prisni." Dhe gjysma e zyrës po pret derisa të nisë infrastrukturën e saj.
- Raste në vend. Amazon nuk është një ngjarje e lirë dhe spotet ju lejojnë të kurseni shumë. Dhe atje mund të tregoni një raport të tërë për të.
- Siguria dhe rolet IAM.
- Duke kërkuar burime të humbura, kur keni raste me origjinë të panjohur në Amazone, ata hanë para. Edhe nëse rastet kushtojnë 100-150 dollarë në muaj, kjo është më shumë se 1 dollarë në vit. Gjetja e burimeve të tilla është një biznes fitimprurës.
- Dhe raste të rezervuara.
Kjo është e gjitha për mua. Terraform është shumë i lezetshëm, ju e përdorni atë. Faleminderit!
Pyetjet tuaja
Faleminderit për raportin! Skedari juaj i gjendjes është në S3, por si ta zgjidhni problemin që disa njerëz mund ta marrin këtë skedar të gjendjes dhe të përpiqen ta zgjerojnë?
Para së gjithash, ne nuk nxitojmë. Së dyti, ka flamuj, në të cilët ne raportojmë se jemi duke punuar në një pjesë të kodit. Kjo do të thotë, pavarësisht se infrastruktura është shumë e madhe, kjo nuk do të thotë që dikush vazhdimisht përdor diçka. Dhe kur kishte një fazë aktive, ky ishte një problem; ne ruanim skedarët e gjendjes në Git. Kjo ishte e rëndësishme, përndryshe dikush do të bënte një dosje shtetërore dhe ne duhej t'i bashkonim manualisht në mënyrë që gjithçka të vazhdonte. Tani nuk ka një problem të tillë. Në përgjithësi, Terraform e zgjidhi këtë problem. Dhe nëse diçka ndryshon vazhdimisht, atëherë mund të përdorni bravë, të cilat parandalojnë atë që keni thënë.
A po përdorni burim të hapur ose ndërmarrje?
Asnjë ndërmarrje, pra gjithçka që mund të shkoni dhe të shkarkoni falas.
Emri im është Stanislav. Doja të bëja një shtesë të vogël. Ju folët për një veçori të Amazon që ju lejon të bëni një shembull të paarritshëm. Kjo është gjithashtu në vetë Terraform; në bllokun Life Second mund të specifikoni një ndalim të ndryshimeve ose një ndalim për shkatërrim.
Koha ishte e kufizuar. Pike e mire.
Doja te pyesja edhe dy gjera. Së pari, ju folët për testimin. A keni përdorur ndonjë mjet testimi? Kam dëgjuar për shtojcën Test Kitchen. Ndoshta ka diçka më shumë. Dhe gjithashtu do të doja të pyesja për vlerat lokale. Si ndryshojnë thelbësisht nga variablat e hyrjes? Dhe pse nuk mund të parametrizoj diçka vetëm përmes Vlerave Lokale? U përpoqa ta kuptoj këtë temë, por disi nuk munda ta kuptoja vetë.
Mund të flasim më në detaje jashtë kësaj dhome. Mjetet tona të testimit janë bërë plotësisht vetë. Nuk ka asgjë për të provuar. Në përgjithësi, ka opsione kur testet e automatizuara marrin infrastrukturën diku, kontrollojnë nëse është në rregull dhe më pas shkatërrojnë gjithçka me një raport që infrastruktura juaj është ende në gjendje të mirë. Ne nuk e kemi këtë sepse pirgjet e testimit ekzekutohen çdo ditë. Dhe kaq mjafton. Dhe nëse diçka fillon të prishet, do të fillojë të prishet pa e kontrolluar diku tjetër.
Lidhur me vlerat lokale, le të vazhdojmë bisedën jashtë sallës.
Përshëndetje! Faleminderit për raportin! Shumë informues. Ju thatë se keni shumë të njëjtin lloj kodi për të përshkruar infrastrukturën. A keni menduar të krijoni këtë kod?
Pyetje e mrekullueshme, faleminderit! Çështja është se kur përdorim infrastrukturën si kod, ne supozojmë se shikojmë kodin dhe kuptojmë se çfarë infrastrukture fshihet pas atij kodi. Nëse krijohet kodi, atëherë duhet të imagjinojmë se çfarë kodi do të gjenerohet në mënyrë që të kuptojmë se çfarë lloj infrastrukture do të jetë atje. Ose gjenerojmë kod, e kryejmë atë dhe në thelb e njëjta gjë ndodh. Kështu ndoqëm rrugën që shkruam, e morëm. Gjeneratorët Plus u shfaqën pak më vonë kur filluam t'i prodhonim. Dhe tashmë ishte tepër vonë për të ndryshuar.
Keni dëgjuar ndonjë gjë për jsonnet?
Jo.
Shikoni, kjo është një gjë shumë e lezetshme. Unë shoh një rast specifik ku mund ta aplikoni dhe të gjeneroni një strukturë të dhënash.
Gjeneratorët janë të mirë kur i keni, si në shaka për një makinë rroje. Domethënë, herën e parë fytyra është e ndryshme, por pastaj të gjithë kanë të njëjtën fytyrë. Gjeneratorët punojnë shumë mirë. Por, për fat të keq, fytyrat tona janë paksa të ndryshme. Ky është problem.
Vetëm shikoni. Faleminderit!
Emri im është Maxim, unë jam nga Sberbank. Ju folët pak se si po përpiqeshit ta sillni Terraform në ekuivalentin e një gjuhe programimi. A nuk është më e lehtë të përdorësh Ansible?
Këto janë gjëra shumë të ndryshme. Ju mund të krijoni burime në Ansible, dhe Puppet mund të krijojë burime në Amazon. Por Terraform është drejtpërdrejt i mprehur.
A keni vetëm Amazon?
Nuk është se kemi vetëm Amazon. Ne pothuajse kemi vetëm Amazon. Por tipari kryesor është se Terraform kujton. Në Ansible, nëse thoni: "Më jep 5 raste", atëherë do të ngrejë, dhe më pas thoni: "Dhe tani më duhen 3". Dhe Terraform do të thotë: "Mirë, unë do të vras 2", dhe Ansible do të thotë: "Mirë, këtu janë 3 për ju." Gjithsej 8.
Përshëndetje! Faleminderit për raportin tuaj! Ishte shumë interesante të dëgjoje për Terraform. Unë do të doja të bëja menjëherë një koment të vogël për faktin se Terraform ende nuk ka një lëshim të qëndrueshëm, kështu që trajtojeni Terraformin me shumë kujdes.
Një lugë e mirë për darkë. Kjo do të thotë, nëse keni nevojë për një zgjidhje, atëherë ndonjëherë ju shtyni atë që është e paqëndrueshme, etj., por funksionon dhe na ndihmoi.
Pyetja është kjo. Ju përdorni backend-in në distancë, përdorni S 3. Pse nuk përdorni backend-in zyrtar?
Zyrtare?
Re Terraform.
Kur u shfaq?
Rreth 4 muaj më parë.
Nëse do të ishte shfaqur 4 vjet më parë, atëherë ndoshta do t'i isha përgjigjur pyetjes suaj.
Ekziston tashmë një funksion i integruar dhe kyçje, dhe ju mund të ruani një skedar shtetëror. Provojeni. Por as unë nuk e kam testuar.
Ne po udhëtojmë me një tren të madh që lëviz me shpejtësi të madhe. Dhe nuk mund të marrësh vetëm disa makina dhe t'i hedhësh.
Ju folët për fjollat e borës, pse nuk e keni përdorur degën? Pse nuk funksionoi kështu?
Qasja jonë është që e gjithë infrastruktura të jetë në një depo. Terraform, Puppet, të gjithë skenarët që lidhen disi me këtë, janë të gjitha në një depo. Në këtë mënyrë ne mund të sigurohemi që ndryshimet në rritje të testohen njëra pas tjetrës. Nëse do të ishte një tufë degësh, atëherë një projekt i tillë do të ishte pothuajse i pamundur të mirëmbahej. Kalojnë gjashtë muaj dhe ato ndryshojnë aq shumë sa është vetëm një lloj ndëshkimi. Kjo është ajo nga e cila doja të shpëtoja përpara se të rifaktoroja.
Pra nuk funksionon?
Kjo nuk funksionon fare.
Në degë kam prerë rrëshqitjen e dosjes. Kjo do të thotë, nëse e bëni atë për secilën pirg provë, për shembull, ekipi A ka dosjen e tij, ekipi B ka dosjen e tij, atëherë kjo gjithashtu nuk funksionon. Ne krijuam një kod të unifikuar të mjedisit testues që ishte mjaft fleksibël për t'iu përshtatur të gjithëve. Kjo do të thotë, ne kemi shërbyer një kod.
Përshëndetje! Emri im është Yura! Faleminderit për raportin! Pyetje rreth moduleve. Ju thoni se po përdorni module. Si e zgjidhni problemin nëse në një modul janë bërë ndryshime që nuk janë në përputhje me ndryshimin e një personi tjetër? A po i modifikoni disi modulet apo po përpiqeni të sillni një wunderwaffle për të përmbushur dy kërkesa?
Ky është një problem i madh i grumbullit të borës. Kjo është ajo që ne vuajmë kur një ndryshim i padëmshëm mund të thyejë një pjesë të infrastrukturës. Dhe kjo do të jetë e dukshme vetëm pas një kohe të gjatë.
Kjo do të thotë, nuk është zgjidhur ende?
Ju bëni module universale. Shmangni flokët e borës. Dhe gjithçka do të funksionojë. Gjysma e dytë e raportit ka të bëjë me mënyrën se si të shmanget kjo.
Përshëndetje! Faleminderit për raportin! do të doja të sqaroja. Prapa skenave kishte një grumbull të madh për të cilin erdha. Si integrohen Kukulla dhe shpërndarja e roleve?
Të dhënat e përdoruesit.
Kjo do të thotë, ju thjesht e pështyni skedarin dhe disi e ekzekutoni atë?
Të dhënat e përdoruesit janë një shënim, d.m.th. kur bëjmë një klon të imazhit, Daemon ngrihet atje dhe, duke u përpjekur të kuptojë se kush është ai, lexon shënimin se ai është një balancues i ngarkesës.
Domethënë, a është ky një lloj procesi i veçantë që jepet?
Nuk e shpikëm ne. Ne e përdorim atë.
Përshëndetje! Unë kam vetëm një pyetje në lidhje me të dhënat e përdoruesit. Ju thatë se atje ka probleme, se dikush mund të dërgojë diçka në vendin e gabuar. A ka ndonjë mënyrë për të ruajtur të dhënat e përdoruesit në të njëjtin Git, në mënyrë që të jetë gjithmonë e qartë se çfarë i referohen të dhënat e përdoruesit?
Ne gjenerojmë të dhëna të përdoruesit nga shablloni. Domethënë, aty përdoren një numër i caktuar variablash. Dhe Terraform gjeneron rezultatin përfundimtar. Prandaj, nuk mund të shikoni vetëm shabllonin dhe të thoni se çfarë do të ndodhë, sepse të gjitha problemet lidhen me faktin që zhvilluesi mendon se po kalon një varg në këtë ndryshore, por aty përdoret një grup. Dhe ai - bam dhe unë - filani, filani, rreshti tjetër, dhe gjithçka u prish. Nëse ky është një burim i ri dhe një person e merr atë dhe sheh që diçka nuk po funksionon, atëherë ai zgjidhet shpejt. Dhe nëse ky grup i shkallës automatike përditësohet, atëherë në një moment rastet në grupin e shkallës automatike fillojnë të zëvendësohen. Dhe zhurmë, diçka nuk funksionon. Ajo dhemb.
Rezulton se zgjidhja e vetme është testimi?
Po, e shihni problemin, shtoni hapat e testimit atje. Kjo do të thotë, prodhimi gjithashtu mund të testohet. Ndoshta nuk është aq i përshtatshëm, por gjithashtu mund të vendosni disa shenja - kontrolloni që të dhënat e përdoruesit të jenë të vendosura këtu.
Emri im është Timur. Është shumë interesante që ka raporte se si të organizohet siç duhet Terraform.
Unë as që kam filluar.
Mendoj se ndoshta në konferencën e ardhshme do të ketë. Unë kam një pyetje të thjeshtë. Pse po e kodoni vlerën në një modul të veçantë në vend që të përdorni tfvars, d.m.th., pse një modul me vlera është më i mirë se tfvars?
Kjo do të thotë, a duhet të shkruaj këtu (rrëshqitje: Production/environment/settings.tf): domain = variable, domain vpcnetwork, variable vpcnetwork dhe stvars – a mund të marr të njëjtën gjë?
Kjo është pikërisht ajo që ne bëjmë. Ne i referohemi modulit të burimit të cilësimeve, për shembull.
Në thelb, këto janë tfvars të tillë. Tfvars është shumë i përshtatshëm në një mjedis testimi. Kam tfvare per instanca te medha, per ato te vogla. Dhe hodha një skedar në dosje. Dhe mora atë që doja. Kur po shkurtojmë infrastrukturën, duam që të jetë e mundur të shikojmë dhe të kuptojmë menjëherë gjithçka. Dhe kështu rezulton se ju duhet të shikoni këtu, pastaj shikoni tfvars.
A është e mundur të kesh gjithçka në një vend?
Po, tfvars është kur keni një kod. Dhe përdoret në disa vende të ndryshme me nuanca të ndryshme. Pastaj hidhje tfvare dhe merrje nuancat e tua. Dhe ne jemi infrastruktura si kod në formën e tij më të pastër. Shikova dhe kuptova.
Përshëndetje! A keni hasur në situata ku ofruesi i reve kompjuterike ndërhyn me atë që keni bërë Terraform? Le të themi se redaktojmë meta të dhënat. Ka çelësa ssh. Dhe Google vendos vazhdimisht meta të dhënat dhe çelësat e tij atje. Dhe Terraform gjithmonë shkruan se ka ndryshime. Pas çdo vrapimi, edhe nëse asgjë nuk ndryshon, ai gjithmonë thotë se do ta përditësojë këtë fushë tani.
Me çelësa, por po, një pjesë e infrastrukturës preket nga kjo gjë, pra Terraform nuk mund të ndryshojë asgjë. Ne nuk mund të ndryshojmë asgjë as me duart tona. Ne do të jetojmë me të tani për tani.
Domethënë, ju keni hasur në diçka të tillë, por nuk keni menduar asgjë, si e bën dhe e bën vetë?
Fatkeqësisht po.
Përshëndetje! Emri im është Starkov Stanislav. Postë. Grupi ru. Si e zgjidhni problemin e gjenerimit të një etikete në..., si e kaloni brenda? Siç e kuptoj unë, përmes të dhënave të Përdoruesit për të specifikuar emrin e hostit, vendosni Puppet? Dhe pjesa e dytë e pyetjes. Si e zgjidhni këtë çështje në SG, d.m.th. kur gjeneroni SG, qindra raste të të njëjtit lloj, cili është emri i saktë për to?
Ato raste që janë shumë të rëndësishme për ne, i emërtojmë bukur. Ato që nuk janë të nevojshme, ka një shënim se ky është një grup autoscale. Dhe në teori mund ta fiksoni dhe të merrni një të re.
Sa i përket problemit me etiketën, nuk ka një problem të tillë, por ka një detyrë të tillë. Dhe ne përdorim shumë, shumë etiketa, sepse infrastruktura është e madhe dhe e shtrenjtë. Dhe ne duhet të shikojmë se ku po shkojnë paratë, kështu që etiketat na lejojnë të zbërthejmë se ku shkoi. Dhe, në përputhje me rrethanat, kërkimi për diçka që do të thotë shumë para shpenzohet këtu.
Për çfarë tjetër ishte pyetja?
Kur SG krijon qindra raste, a duhet të dallohen disi?
Jo, mos. Në çdo rast ka një agjent që raporton se unë kam një problem. Nëse një agjent raporton, atëherë agjenti e di për të dhe, të paktën, ekziston adresa e tij IP. Ju tashmë mund të ikni. Së dyti, ne përdorim Konsullin për Discovery, ku Kubernetes nuk është. Dhe Konsulli tregon gjithashtu adresën IP të shembullit.
Kjo do të thotë, a jeni duke u fokusuar në mënyrë specifike në IP, dhe jo në emrin e hostit?
Është e pamundur të lundrosh sipas emrit të hostit, domethënë ka shumë prej tyre. Ka identifikues të shembujve - AE, etj. Mund ta gjeni diku, mund ta hidhni në kërkim.
Përshëndetje! Kuptova se Terraform është një gjë e mirë, e përshtatur për retë.
Jo vetem.
Kjo është pikërisht pyetja që më intereson mua. Nëse vendosni të lëvizni, le të themi, në Bare Metal masivisht me të gjitha rastet tuaja? A do të ketë ndonjë problem? Apo do t'ju duhet të përdorni akoma produkte të tjera, për shembull, të njëjtin Ansible që u përmend këtu?
Ansible ka të bëjë pak me diçka tjetër. Kjo do të thotë, Ansible tashmë funksionon kur shembulli ka filluar. Dhe Terraform punon përpara fillimit të shembullit. Kalimi në Bare Metal - nr.
Jo tani, por biznesi do të vijë dhe do të thotë: "Hajde".
Kalimi në një re tjetër - po, por këtu ka një mashtrim paksa të ndryshëm. Ju duhet të shkruani kodin Terraform në atë mënyrë që të mund të kaloni në një re tjetër me më pak përpjekje.
Fillimisht u vendos detyra që e gjithë infrastruktura jonë të ishte agnostike, d.m.th çdo re duhet të ishte e përshtatshme, por në një moment biznesi hoqi dorë dhe tha: "Mirë, në N vitet e ardhshme nuk do të shkojmë askund, mund të përdorim shërbime. nga Amazon"
Terraform ju lejon të krijoni punë në Front-End, të konfiguroni PagerDuty, doc të të dhënave, etj. Ka shumë bishta. Ai praktikisht mund të kontrollojë të gjithë botën.
Faleminderit për raportin! Unë gjithashtu kam përdorur Terraform për 4 vjet tani. Në fazën e një kalimi të qetë në Terraform, në infrastrukturë, në një përshkrim deklarativ, u përballëm me një situatë ku dikush po bënte diçka me dorë, dhe ju po përpiqeshit të bënit një plan. Dhe aty pata një lloj gabimi. Si i përballoni probleme të tilla? Si i gjeni burimet e humbura që janë renditur?
Kryesisht me duar dhe sy, nëse shohim diçka të çuditshme në raport, atëherë analizojmë se çfarë po ndodh atje, ose thjesht vrasim. Në përgjithësi, kërkesat për tërheqje janë një gjë e zakonshme.
Nëse ka një gabim, a riktheheni? A keni provuar ta bëni këtë?
Jo, ky është vendimi i një personi në momentin kur sheh një problem.
Burimi: www.habr.com