Duket e thjeshtë, zhvilluesit e Terraform ofrojnë praktika të mira për të punuar me infrastrukturën AWS. Megjithatë, ka një nuancë. Me kalimin e kohës, numri i mjediseve rritet, dhe secili ka veçoritë e veta. Pjesërisht krijohet një kopje e stack-ut të aplikacioneve në rajonin fqinj. Dhe kodi i Terraform-it duhet kopjuar me kujdes dhe redaktuar sipas kërkesave të reja, ose të krijohet një 'snowflake'.
Raporti im është për modelet në Terraform për të luftuar kaosin dhe rutinën manuale në projekte të mëdha dhe afatgjata.
Video:
Jam 40 vjeç dhe kam 20 vjet në IT. Kam punuar 12 vjet në kompaninë Ixtens. Ne merremi me zhvillimin e bazuar në ecommerce. Dhe gjatë 5 viteve të fundit kam praktikuar praktikat DevOps.
Tregimi im do të jetë për përvojën në një projekt në një kompani, emrin e së cilës nuk do ta zbuloj për shkak të marrëveshjes për ruajtjen e sekretit.
Numrat në slajd janë tregues të shkallës së projektit. Të gjitha që do të flas më tej janë të lidhura me Amazon.
U bashkova me këtë projekt 4 vjet më parë. Dhe në mesin e procesit po kalonim një ristrukturim të infrastrukturës, për shkak se projekti kishte kaluar në një fazë rritjeje. Modelet që ishin përdorur, tashmë nuk ishin më të përshtatshme. Duke marrë parasysh rritjen e planifikuar të projektit, duhej të mendonim për një zgjidhje të re.
Faleminderit Matveit, i cili dje tregoi se çfarë ndodhi në Dodo Pizza. Kjo është ajo që ndodhi tek ne 4 vjet më parë.
Arritën zhvilluesit dhe filluan të krijojnë kodin e infrastrukturës.
Momentet më të dukshme, përse kjo ishte e nevojshme, ishte për të arritur kohën e tregut. Duhej të bëhej që ekipi DevOps të mos ishte bllokimi kryesor gjatë lançimit. Dhe, përveç të tjerave, në nivelin fillestar u përdorën Terraform dhe Puppet.
Terraform është një projekt open source i kompanisë HashiCorp. Dhe për ata që nuk e dinë se çfarë është, disa slajde të ardhshme.
Infrastruktura si kod do të thotë se mund të përshkruajmë infrastrukturën tonë dhe t'u kërkojmë disa robote të krijojnë burimet që kemi përshkruar.
Për shembull, na nevojitet makinë virtuale. Do ta përshkruajmë, do të shtojmë disa parametra të obligueshëm.
Pas kësaj, në konsolë do të konfigurojmë q 접근 në Amazon. Dhe do të kërkojmë Terraform plan. Terraform plan do të thotë: "Ok, për burimin tuaj ne mund të bëjmë gjëra të tilla". Dhe, të paktën, një burim do të shtohet. Dhe nuk parashikohen ndryshime.
Pasi të jeni të kënaqur me gjithçka, mund të kërkoni Terraform apply dhe Terraform do t'ju krijojë një instance, dhe do të merrni një makinë virtuale në cloud-in tuaj.
Më pas projekti ynë vazhdon të evoluoni. Shtojmë disa ndryshime aty. Kërkojmë më shumë instance, shtojmë një rekord 53.
Dhe përsërisim. Kërkojmë plan. Shikojmë çfarë ndryshimesh janë të planifikuara. Applikojmë. Dhe kështu infrastruktura jonë rritet.
Terraform përdor një gjë të quajtur skedarë të gjendjes. Pra, të gjitha ndryshimet që dërgohen në Amazon, ai i ruan në një skedar, ku për çdo burim që keni përshkruar, ekzistojnë burime përkatëse që janë krijuar në Amazon. Kështu që, kur ndryshoni përshkrimin e ndonjë burimi, Terraform e di saktësisht se çfarë duhet të ndryshojë në Amazon.
Këta skedarë të gjendjes fillimisht ishin thjesht skedarë. Dhe ne i ruanim në Git, gjë që ishte jashtëzakonisht e papërshtatshme. Fillimisht ndonjëherë dikush harronte t'i komitonte ndryshimet dhe ndodhnin shumë konflikte.
Tani ka mundësinë për të përdorur një backend, pra Terraform e tregon në cilin bucket, me çelësin e cilit duhet të ruhet skedari i gjendjes. Dhe Terraform do të kujdeset vetë që të marrë skedarin e gjendjes, të bëjë të gjithë magjinë dhe ta kthejë rezultatin përfundimtar.
Infrastruktura jonë rritet. Ja kodi ynë. Dhe tani nuk duam thjesht të krijojmë një makinë virtuale, duam të kemi një mjedis testimi.
Terraform lejon të krijosh një modul, pra të përshkruash të njëjtën gjë në një dosje të caktuar.
Dhe, për shembull, në testim të thërrasim këtë modul dhe të marrim të njëjtën gjë si të ishim duke ekzekutuar Terraform apply në vetë modul.
Për prodhim, mund të dërgojmë ndonjë ndryshim, sepse në testim nuk na nevojiten instance të mëdha, ndërsa në prodhim ato janë shumë të nevojshme.
Dhe tani kthehem sërish në projekt. Ishte një detyrë e vështirë, infrastruktura ishte planifikuar të ishte shumë e madhe. Dhe duhej të organizonim të gjithë kodin në një mënyrë që të ishte e lehtë për të gjithë: si për ata që bëjnë mirëmbajtjen e këtij kodi, ashtu edhe për ata që bëjnë ndryshime. Ishte planifikuar që çdo zhvillues të mund të shkonte dhe të rregullonte infrastrukturën siç ishte e nevojshme për pjesën e tij të platformës.
Ky është një pemë katalogësh, që rekomandohet nga HashiCorp vetë, nëse keni një projekt të madh dhe ka kuptim ta ndani gjithë infrastrukturën në disa copa të vogla, dhe të përshkruani çdo copë në një dosje të veçantë.
Duke pasur një bibliotekë të gjerë burimesh, mund të thërrasim në test dhe në prodhim më shumë ose më pak të njëjtën gjë.
Në rastin tonë, kjo nuk ishte krejtësisht e përshtatshme, sepse ishte më e thjeshtë të merrnim një stek testimi për zhvilluesit ose për testim. Të ecësh nëpër dosje dhe të aplikosh në rendin e duhur, duke u shqetësuar se baza do të ngrihej e pastaj do të ngrihej një instance që përdor këtë bazë, nuk ishte diçka që donim. Prandaj, të gjithë testimet kryheshin nga një dosje. Atje thirreshin të njëjtat module, por gjithçka ndodhte në një kalim.
Terraform merret me të gjitha varësitë. Ai gjithmonë krijon burime në atë rend që mund të merrni një IP adresë, për shembull, nga një instance e sapo krijuar dhe të merrni këtë IP adresë në regjistrimin route53.
Përveç kësaj, platforma është shumë e madhe. Dhe aktivizimi i stekut testues, edhe nëse për një orë, madje edhe për 8 orë – është një gjë mjaft e shtrenjtë.
Dhe ne e automatizuam këtë proces. Një punë në Jenkins lejonte aktivizimin e stekut. Në të duhej të aktivizohej një pull request me ndryshimet që dëshiron të testojë zhvilluesi, të shënosh të gjitha opsionet e duhura, komponentët, si dhe madhësitë. Nëse ai dëshiron testim performanca, mund të merrte më shumë instance. Nëse ai thjesht donte të kontrollonte nëse një formular hapet, mund ta aktivizonte me minimumet. Po ashtu, mund të specifikonte nëse duhej ose jo një klaster, etj.
Dhe pastaj Jenkins ekzekutonte një script shell, i cili modifikonte pak kodin në dosjen e Terraform. Hiqte skedarët e panevojshëm, shtonte skedarët e nevojshëm. Dhe pastaj me një kalim Terraform apply steku ngrihej.
Pas kësaj ndodhnin hapa të tjerë, në të cilat nuk dua të thellohem.
Për shkak se për testim na nevojiteshin pak më shumë opsione sesa në prodhim, na duhej të bënim kopje të modulave, që në ato kopje të mund të shtonim ato funksionalitete që ishin vetëm për testim.
Dhe kështu ndodhi që në testim dukej se donim të testonim ato ndryshime që në fund do të ishin në prodhim. Por në të vërtetë testoheshin një gjë, dhe në prodhim përdorej diçka tjetër. Dhe kishte një shkëputje të vogël, sepse në prodhim të gjitha ndryshimet aplikohej nga ekipi operativ. Disa herë ndodhte që ato ndryshime që duhej të kalonin nga testimi në prodhim, mbeteshin në një version tjetër.
Përveç kësaj kishte një problem, se shtohej një shërbim i ri, i cili ndryshonte pak nga ndonjë ekzistues. Dhe në vend që të modifikohej moduli ekzistues, duhej të bëhej një kopje e tij dhe të shtoheshin ndryshimet e nevojshme.
Në thelb, Terraform nuk është një gjuhë e vërtetë. Është një deklaratë. Nëse na nevojitet të deklarojmë diçka, ne e deklarojmë. Dhe gjithçka funksionon.
Në një moment, kur u diskutua një nga pull request-et e mia, një koleg tha se nuk duhej të shumëzohej snjefra. Unë u interesova për atë që ai kishte parasysh. Ekziston një fakt shkencor që në botë nuk ekzistojnë dy snjefra të njëjtë, të gjithë ata dallohen pak nga njëri-tjetri. Dhe sapo e dëgjova këtë, pashë gjithë peshën e kodit të Terraform. Sepse kur kërkohej të kalosh nga një version në një tjetër, Terraform kërkonte ndryshime që thyenin zinxhirin, dmth. kodi nuk ishte më i kompatibil me versionin tjetër. Dhe duhej të bëhej një pull request që përfshinte pothuajse gjysmën e skedarëve në infrastrukturë për të sjellë infrastrukturën në versionin e ardhshëm të Terraform.
Dhe pas që u shfaq një snjefër e tillë, gjithë kodi i Terraform që kishim shndërrohej në një mal të madh dëbore.
Për një zhvillues të jashtëm, i cili është jashtë operacionit, kjo nuk ka shumë rëndësi, sepse ai bëri një pull request, burimi i tij u aktivizua. Dhe mbaroi, pastaj nuk është më në kujdesin e tij. Por për ekipin DevOps, i cili ndjek që gjithçka të jetë në rregull, duhet të bëjnë të gjithë këto ndryshime. Dhe kostoja e këtyre ndryshimeve rritej shumë me çdo snjefër shtesë.
Ka një histori për një student që në një seminar vizaton me krejon dy rrethe të përsosura në tavolinë. Dhe mësuesi habitet se si arriti t'i vizatojë kaq bukur pa përdorur një kompass. Studenti përgjigjet: "Më shumë e thjeshtë, kam kaluar dy vjet në ushtri duke lëvizur një makinë mishi."
Dhe nga ato katër vjet, në të cilat kam marrë pjesë në këtë projekt, ndoshta rreth dy vjet kam punuar me Terraform. Dhe natyrisht, kam disa truke, disa këshilla, se si mund ta thjeshtoj kodin e Terraform, të punoj me të si me një gjuhë programuese dhe të ulin ngarkesën për zhvilluesit që duhet ta mbajnë këtë kod në gjendje aktive.
E para që do të doja të filloja është Symlinks. Terraform ka shumë kod përsëritës. Për shembull, thirrja e ofruesit në pothuajse çdo pikë ku krijojmë një copë infrastrukturë është e njëjtë. Dhe është logjike ta nxjerrim atë në një dosje të veçantë. Dhe kudo ku kërkohet ofruesi, bëni Symlinks për këtë skedar.
P.sh. ju keni një rol të supozuar në production që ju lejon të merrni të drejtat për qasje në një llogari të jashtme Amazon. Duke ndryshuar një skedar, të gjithë skedarët e tjerë në strukturën e burimeve do të kenë të drejtat e kërkuara që Terraform të dijë në cilin segment të Amazon të drejtohet.
Ku nuk funksionojnë Symlinks? Siç e përmenda, në Terraform ka skedarë të shtetit. Dhe ata janë shumë shumë të shkëlqyer. Por problemi është se Terraform inicializon backendin në fazën e parë. Dhe ai nuk mund të përdorë ndonjë variabël në këto parametra, gjithmonë duhet t'i shkruajmë ato në formë teksti.
Si rezultat, kur dikush krijon një burim të ri, ai kopjon një pjesë kode nga dosje të tjera. Dhe ai mund të gabojë me çelësin ose me bucket-in. P.sh., ai krijon një gjë në sandbox dhe pastaj në production. Kështu mund të ndodhë që bucket-i në production të përdoret nga sandbox. Sigurisht, kjo do të zbuloheshin shpejt. Mund të rregullohet ndonjëherë, por megjithatë është humbje kohe dhe në një farë mase burimesh.
Çfarë mund të bëjmë më pas? Para se të filloni të punoni me Terraform, duhen bërë inicializimet e tij. Gjatë procesit të inicializimit, Terraform shkarkon të gjithë pluginat. Ato, në një farë momenti, u ndanë nga një monolit në një arkitekturë më mikroservisore. Dhe gjithmonë duhet të bëni Terraform init që të tërheqë të gjithë modulat, të gjithë pluginat.
Dhe mund të përdorim një skrit shell që, së pari, do të mund të nxjerrë të gjithë variablat. Skedarë shell nuk kanë ndonjë kufizim. Pastaj, rrugët. Nëse gjithmonë përdorim atë rrugë që është në repository si një çelës për skedarin e shtetit, atëherë, për pasojë, gabimi këtu do të përjashtohet.
Nga ku të nxjerrim të dhënat? Skedari JSON. Terraform lejon që infrastruktura të shkruhet jo vetëm në hcl (HashiCorp Configuration Language), por edhe në JSON.
JSON lexohen lehtë nga skrit shell. Për pasojë, mund të vendosim një skedë konfigurimi me bucket. Dhe ta përdorim këtë bucket si në kodin Terraform, ashtu edhe në skritin shell për inicializimin.
Pse është e rëndësishme të keni një bucket për Terraform? Sepse ekziston një gjë si skedarët e shtetit të largët. Që do të thotë, kur krijoj një burim, që t'i them Amazon: "Të lutem, ngri një instance", duhet të specifikoj shumë parametra të detyrueshëm.
Dhe këto identifikues ruhen në një dosje tjetër. Dhe unë mund të them: "Terraform, shko te skedari i shtetit të atij burimi dhe më nxirr këta identifikues". Kështu krijohet një uniformizim midis rajoneve të ndryshme apo ambienteve.
Nuk është gjithmonë e mundur të përdoret skedari i shtetit të largët. P.sh., ju keni krijuar me duar një VPC. Dhe ai kod Terraform që krijon VPC krijon një VPC kaq të ndryshëm, saqë do t'ju duhet shumë kohë për ta përshtatur njëri-tjetrin, kështu që mund të përdorni këtë mënyrë tjetër.
Që do të thotë të krijoni një modul që siç do të krijojë VPC dhe siç do t'ju japë identifikuesit, por në të vërtetë është thjesht një skedë me vlera të koduara, e cila mund të përdoret për të krijuar atë njëjtë instance.
Nuk është gjithmonë e nevojshme të ruani skedarin e shtetit në cloud. P.sh., kur testohet moduli, mund të përdoret inicializimi i backend-it, kur skedari do të ruhen thjesht në disk gjatë momentit të testimit.
Tani pak për testimin. Çfarë mund të testohet në Terraform? Ndoshta shumë, por unë do të flas për këto 4 aspekte.
HashiCorp ka një kuptim se si duhet të formatohet kodi i Terraform. Dhe Terraform fmt ju lejon ta formatoni kodin që ju po e redaktoni në përputhje me këtë besim. Prandaj, testet duhet të verifikojnë patjetër nëse formatimi përputhet me atë që ka lënë HashiCorp, që të mos ketë nevojë të ndryshoni pozitat e braçkave, etj.
E ardhshme – është Terraform validate. Ai bën pak më shumë se sa thjesht verifikimi i sintaksës – si të themi, a janë të gjitha brackat të çiftëzuara. Çfarë është e rëndësishme këtu? Infrastruktura jonë është shumë e gjerë. Ka shumë dosje të ndryshme. Dhe në secilën duhet të ekzekutojë Terraform validate.
Prandaj, për të shpejtuar testimin, ne ekzekutojmë disa procese paralelisht, duke përdorur paralel.
Paraleli është një gjë shumë e bukur, përdoreni.
Por çdo herë që ndodh inicializimi i Terraform, ai shkon te HashiCorp dhe pyet: "Cilat janë versionet më të fundit të pluginave? Dhe ai plugin që është në cache-in tim – a është ai ose jo?". Dhe kjo e ngadalëson çdo hap.
Nëse i tregoni Terraform ku ndodhen pluginat, atëherë Terraform do të thotë: "Ok, ndoshta kjo është më e reja që ekziston. Unë nuk do të shkoj askund, do të filloj menjëherë të verifikoj kodin tuaj Terraform".
Për të mbushur dosjen me pluginet e nevojshme, kemi një kod shumë të thjeshtë Terraform që thjesht duhet të inicializohet. Këtu, sigurisht, duhet të spesifikoni të gjithë ofruesit që ndonjëherë janë pjesë e kodit tuaj, përndryshe Terraform do të thotë: "Nuk e njoh ndonjë ofrues, sepse ai nuk është në cache."
E ardhshmja – është Terraform plan. Siç e përmenda, zhvillimi është ciklik. Ne shkruajmë kod me ndryshime. Dhe pastaj duhet të kuptojmë se cilat ndryshime planifikohen për infrastrukturën.
Dhe kur infrastruktura është shumë e madhe, mund të ndryshoni një modul, të riparoni një ambient testimi ose ndonjë rajon specifik dhe të thyeni ndonjë të afërt. Prandaj, Terraform plan duhet të bëhet për të gjithë infrastrukturën dhe të tregojë cilat ndryshime planifikohen.
Kjo mund të bëhet me mençuri. Ne, për shembull, kemi shkruar një skript në Python që zgjidh varësitë. Dhe në varësi të asaj se çfarë është ndryshuar: moduli Terraform ose thjesht ndonjë komponent specifik, ai bën plane për të gjitha dosjet varësore.
Terraform plan duhet të bëhet me kërkesë. Të paktën, kjo është ajo që bëjmë ne.
Testet, natyrisht, janë të mira të bëhen për çdo ndryshim, për çdo commit, por planet – janë një gjë mjaft e shtrenjtë. Dhe ne në pull request themi: "Të lutem, më dha planet." Aktivizohet një robot. Dhe ai dërgon në komente ose në bashkëngjitje të gjitha planet që priten nga ndryshimet tuaja.
Plani – është një gjë mjaft e shtrenjtë. Ai merr kohë, sepse Terraform shkon në Amazon dhe pyet: "A ekziston ende ky instance? A ka këto parametra të saktë kjo autoscale?". Dhe për ta përshpejtuar këtë, mund të përdorni një parametrin si refresh=false. Kjo do të thotë se Terraform do të nxjerrë nga S3 state. Dhe do të besojë se state do të përputhet saktësisht me atë që ndodhet në Amazon.
Ky Terraform plan kalon shumë më shpejt, por state duhet të përputhet me infrastrukturën tuaj, domethënë, diku, njëherë duhet të aktivizohet Terraform refresh. Terraform refresh bën saktësisht atë që ka për detyrë, që state të përputhet me atë që ndodhet në infrastrukturën reale.
Dhe duhet të flas për sigurinë. Këtë do të duhej ta kisha filluar. Atje ku ju e aktivizoni Terraform, dhe Terraform punon me infrastrukturën tuaj, ka një vulnerabilitet. Domethënë, ju, në thelb, po ekzekutoni kod. Dhe nëse pull request përmban ndonjë kod të dëmshëm, ai mund të ekzekutohet në infrastrukturën që ka tepër shumë akses. Prandaj, ndani kujdes, ku e aktivizoni Terraform plan.
E ardhshmja, për të cilën do të doja të flisja, është testimi i user-data.
Çfarë është user-data? Në Amazon, kur krijojmë një instance, mund të dërgojmë një letër – meta-të dhëna nga instance. Kur instance ndizet, cloud init është gjithmonë i pranishëm në këto instance. Cloud init lexon këtë letër dhe thotë: "Ok, sot unë jam – load balancer". Dhe në përputhje me këto urdhra kryen disa veprime.
Por, fatkeqësisht, kur bëjmë Terraform plan dhe Terraform apply, user-data shfaqet si një grumbull i tillë numrash. Domethënë, ai thjesht ju dërgon një hash. Dhe çdo gjë që mund të shikoni në plan është nëse do të ketë disa ndryshime ose hash do të mbetet i njëjtë.
Dhe nëse këtë nuk e keni parasysh, atëherë në Amazon, në infrastrukturën reale mund të dërgohet ndonjë skedar të dëmtuar tekstual.
Si një mundësi, mund të specifikoni vetëm template dhe të kërkoni në kod: "Të lutem, më shfaq këtë template në ekran." Dhe në përfundim mund të merrni një printim se si do të duken të dhënat tuaja në Amazon.
Një mundësi tjetër – është të përdorni një modul për gjenerimin e user-data. Ju do ta aplikoni këtë modul. Merrni një skedë në disk. E krahasoni atë me referencën. Dhe kështu, nëse ndonjë junior vendos ta ndryshojë pak user-data, testet tuaja do të thonë: "Ok, këtu dhe këtu ka disa ndryshime – kjo është në rregull".
E ardhshmja, për të cilën do të doja të flisja më shumë, është Automate Terraform apply.
Natyrisht, është mjaft e frikshme të bësh Terraform apply në mënyrë automatike, sepse, kush e di, çfarë ndryshimesh kanë ardhur dhe sa shkatërruese mund të jenë ato për infrastrukturën aktive.
Për ambientin e testimit – kjo është gjithçka në rregull. Domethënë, job-i që krijon ambientin e testimit, është ajo që u nevojitet të gjithë zhvilluesve. Dhe shprehja si "unë kam pasur gjithçka të funksionojë" – nuk është një meme qesharake, por një dëshmi se personi ka punuar, ka ngritur stek, ka ekzekutuar disa teste në këtë stek. Dhe është siguruar që gjithçka është në rregull dhe tha: "Ok, ai kod që po lëshoj, është testuar."
Në ambientet e production, sandbox dhe të tjera që kanë rëndësi më të madhe për biznesin, është e mundur të aplikoni pjesërisht disa burime mjaft të sigurta, sepse kjo nuk çon në pasoja fatale. Këtu janë: grupet autoscale, grupet e sigurisë, roles, route53 dhe lista mund të jetë mjaft e gjatë. Por bëni kujdes me atë që ndodh, lexoni raportet për aplikimet automatike.
Atje ku aplikimi është i rrezikshëm ose i frikshëm, për shembull, nëse bëhet fjalë për disa burime me persistent, si bazat e të dhënave, merini raportet për ndonjë ndryshim të papërfunduar në ndonjë pjesë të infrastrukturës. Pastaj, inxhinieri, nën mbikëqyrje, aktivizon punët për të aplikuar ose e bën këtë nga konsola e tij.
Në Amazon ekziston një funksion i quajtur Terminate protection. Ai mund të mbrojë në disa raste nga ndryshime që nuk janë të nevojshme për ju. Kjo do të thotë, Terraform shkon në Amazon dhe thotë: 'Më duhet të vras këtë instance, për të krijuar një tjetër'. Dhe Amazon thotë: 'Më fal, jo sot. Ne kemi vendosur Terminate protection'.
Dhe siç e do kavajën e ëmbël – kjo është optimizimi i kodit. Kur punojmë me kodin Terraform, duhet të kalojmë shumë parametra në modul. Këta parametër janë të nevojshëm për të krijuar ndonjë burim. Kështu, kodi kthehet në lista të mëdha parametrash që duhet të kalojnë nga një modul në tjetrin, sidomos nëse modulat janë të ngjitura.
Dhe kjo është shumë e vështirë për t'u lexuar. Është shumë e vështirë të bësh review. Shpesh ndodh që disa parametra kalojnë në review dhe nuk janë pikërisht ata që nevojiten. Kjo merr kohë dhe para për t'u korrigjuar më vonë.
Prandaj, ju sugjeroj të përdorni një parametr të komplikuar që përfshin një pemë vlerash. Kjo do të thotë që iu nevojitet një dosje, ku janë të shënuara të gjitha vlerat që dëshironi të keni në ndonjë ambient.
Dhe duke thirrur këtë modul, mund të merrni një pemë që gjenerohet në një modul të përbashkët, që funksionin njësoj për tërë infrastrukturën.
Në këtë modul mund të bëni disa llogaritje duke përdorur një veçori të re në Terraform, siç janë locals. Dhe pastaj, me një output mund të jepni ndonjë parametr të komplikuar, që mund të përmbajë hash-e, masa etj.
Në këtë pikë përfundojnë të gjitha zbulimet më të mira që kam. Dhe do të doja të tregoj një histori për Kolumbin. Kur ai kërkonte para për ekspeditën e tij për të zbuluar Indinë (siç mendonte ai atëherë), askush nuk i besonte dhe e konsideronin të pamundur. Atëherë ai tha: 'Bëni që të mos bie mëndafshi'. Të gjithë bankierët, njerëz shumë të pasur dhe ndoshta të mençur, përpiqeshin në ndonjë mënyrë të vendosnin mëndafshin, dhe ai gjithmonë binte. Pastaj Kolumbi mori mëndafshin, e shtyu pak. Pjesa e jashtme iu tkurr dhe mëndafshi mbeti i palëvizur. Ata thanë: 'O, kjo është shumë e thjeshtë!'. Dhe Kolumbi u përgjigj: 'Po, kjo është shumë e thjeshtë. Kur të zbuloj Indinë, të gjithë do ta përdorin këtë rrugë tregtare'.
Dhe ajo që ju tregova tani, ndoshta është mjaft e thjeshtë dhe triviale. Dhe kur e mëson ato dhe fillon t’i përdorësh, është krejtësisht në rregull. Pra, përdoreni. Dhe nëse për ju këto janë gjëra krejt normale, të paktën e dini se si të vendosni mëndafshin që të mos bjerë.
Le të bëjmë një përmbledhje:
- Përpiquni të evitoni dëborat. Sa më pak të ketë dëboras, aq më pak burime do t'ju nevojiten për të bërë ndryshime në tërë infrastrukturën tuaj të madhe.
- Ndryshime të vazhdueshme. Do të thotë, kur ka pasur ndonjë ndryshim në kod, duhet të sjellë sa më shpejt të mundshme infrastrukturën tuaj në përputhje me këto ndryshime. Nuk duhet të ketë situata kur dikush vjen pas dy-tre muajsh për të parë Elasticsearch, bën Terraform plan, dhe atje ka shumë ndryshime që nuk i priste. Dhe harxhon shumë kohë për t'i sjellë përsëri në rregull.
- Testet dhe automatizimi. Sa më shumë të jetë kodi juaj i mbuluar me teste dhe veçori, aq më shumë do të keni besim se po bëni gjithçka në mënyrë të duhur. Dhe dërgimi automatik do ta rrisë besimin tuaj shumëfish.
- Kodi për ambientet testuese dhe ato në production duhet të jetë pothuajse identik. Pothuajse, sepse në fund të fundit production është pak ndryshe dhe gjithsesi do të ketë disa nuanca që do të dalin jashtë kornizës së ambientit testues. Por gjithsesi, në më pak e më shumë mund të sigurohet kjo.
- Dhe nëse keni shumë kod Terraform dhe mbajtja e tij në gjendje të azhurnuar kërkon shumë kohë, kurrë nuk është vonë të bëni refaktorim dhe ta sillni atë në një formë të mirë.
- Infrastrukturë të palëvizshme. Dërgimi i AMI-së sipas një plani.
- Struktura për route53, kur keni shumë të dhëna dhe dëshironi që ato të jenë në një rend të rregullt.
- Kundërvajtja ndaj kufijve të API. Kur Amazon thotë: «Të gjitha, nuk mund të pranoj më kërkesa, lutem prisni». Dhe gjysma e kompanisë pret derisa të mund të aktivizojë infrastrukturën e saj.
- Instancat Spot. Amazon është një aktivitet i shtrenjtë dhe instancat Spot lejojnë kursime të konsiderueshme. Mund të flitet shumë për këtë.
- Siguria dhe rolet IAM.
- Gjetja e burimeve të humbura, kur keni instanca të paqartë në Amazon, ato shpenzojnë para. Edhe nëse një instancë kushton 100-150 dollarë në muaj – për një vit kjo është mbi 1,000. Gjetja e këtyre burimeve është një mundësi fitimi.
- Dhe instancat e rezervuara.
Kjo është gjithçka nga ana ime. Terraform – është shumë e shkëlqyer, përdorni atë. Faleminderit!
Pyetje
Faleminderit për prezantimin! Ju keni skedarin e gjendjes në S3, por si e zgjidhni problemin që disa njerëz mund ta marrin këtë skedar gjendjeje dhe të përpiqen të eklipsojnë atë?
Së pari, ne nuk nxitojmë. Së dyti, ka flamuj që tregojnë se ne po punojmë në një pjesë të caktuar të kodit. Pra, pavarësisht se infrastruktura është shumë e madhe, kjo nuk do të thotë se dikush është duke aplikuar vazhdimisht. Gjatë fazës aktive – kjo ishte një problem, skedari i gjendjes tonë ishte ruajtur në Git. Kjo ishte e rëndësishme, përndryshe dikush mund të krijonte një skedar gjendjeje dhe na duhej ta mbledhim atë manualisht për të vazhduar. Tani ky problem nuk ekziston. Në përgjithësi, Terraform zgjidhi këtë problem. Dhe nëse gjithçka po ndryshon vazhdimisht, atëherë mund të përdorim bllokime që parandalojnë atë që thatë.
A përdorni versionin e hapur apo atë enterprise?
Nuk ka asnjë enterprise, pra, gjithçka që mund 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ë lejon të krijoni një instancë të pazhbeshme. Kjo është gjithashtu e pranishme në Terraform, në blokun Life Second mund të specifikoni ndalimin e ndryshimit ose shkatërrimit.
Kam qenë i kufizuar në kohë. Një vërejtje e mirë.
Dëshiroja të pyesja dy gjëra. Së pari, ju folët për testimin. A keni përdorur ndonjë mjet për testimin? Kam dëgjuar për plugins Test Kitchen. Ndoshta ka diçka tjetër. Dhe doja gjithashtu të pyesja për Vlerat Lokale. Çfarë dallimi kanë ato nga Variablat e Input? Dhe pse nuk mund të parametrizoj diçka vetëm përmes Vlerave Lokale? Kam përpiqur të kuptoj këtë temë, por nuk arrita ta kuptoj.
Mund të flasim më në detaje pas këtij salloni. Mjetet për testim – janë gjithçka nga ne. Nuk ka asgjë të tillë për të testuar. Në përgjithësi, ka mundësi kur testet automatike ngrijnë infrastrukturën diku, kontrollojnë që ajo është në rregull, dhe pastaj gjithçka shkatërrohet me një raport që infrastruktura juaj është ende në formë të mirë. Ne nuk e kemi këtë, sepse steket e testimit ngrihen çdo ditë. Dhe kjo është e mjaftueshme. Dhe nëse diçka fillon të prishë, atëherë ajo do të fillojë të prishë pa ndonjë provë të mëtejshme.
Për Vlerat Lokale, le të vazhdojmë bisedën jashtë sallës.
Përshëndetje! Faleminderit për prezantimin! Shumë informativ. Ju theksonit se keni shumë kod të njëjtë për përshkrimin e infrastrukturës. A keni shqyrtuar ndonjëherë mundësinë e gjenerimit të këtij kodi?
Pyetje e shkëlqyer, faleminderit! Çështja është se, kur ne përdorim infrastrukturën si kod, ne supozojmë se ne shohim kodin dhe kuptojmë se cila infrastrukturë qëndron pas këtij kodi. Nëse kodi gjenerohet, na nevojitet të paraqesim se cili kod do të gjenerohet për të kuptuar se cila infrastrukturë do të jetë aty. Ose ne e gjenerojmë kodin, e dërgojmë dhe, me thelb, rezulton e njëjtë. Prandaj ne zgjodhëm rrugën që e kemi shkruar, dhe këtë e morëm. Plus, gjeneratorët erdhën disa kohë më vonë, kur filluam të bëjmë. Dhe tashmë ishte vonë për ta ndryshuar.
Keni dëgjuar diçka për jsonnet?
Jo.
Shiko, kjo është një gjë e shkëlqyer. Unë shoh një rast konkret ku mund ta aplikoja dhe të gjeneroja strukturën e të dhënave.
Gjeneratorët janë të mirë kur keni, si në një shaka për makinën e rruajtjes. Pra, herën e parë fytyra është ndryshe, por pastaj të gjithë kanë të njëjtën fytyrë. Gjeneratorët funksionojnë shumë mirë. Por fatkeqësisht, fytyrat tona janë pak ndryshe. Kjo është një problem.
Thjesht shiko. Faleminderit!
Emri im është Maksim, unë jam nga Sberbank. Ju folët pak se keni tentuar të sillni Terraform në analogjinë e një gjuhe programuesi. A nuk është më e lehtë të përdorni Ansible?
Këto janë shumë gjëra të ndryshme. Mund të krijosh burime me Ansible, gjithashtu mund të krijosh burime me Puppet në Amazon. Por Terraform është specifikisht i dedikuar.
A keni vetëm Amazon?
Çështja nuk është se kemi vetëm Amazon. Ne kemi pothuajse vetëm Amazon. Por karakteristika kryesore është se Terraform e mban mend. Në Ansible, nëse thoni: «Ngrije 5 instanca për mua», ai do t'i ngrejë, dhe pastaj ju thoni: «Tani më duhen 3». Dhe Terraform do të thotë: «Ok, do të heq 2», ndërsa Ansible do të thotë: «Ok, këtu ka 3». Dhe përfundimisht, do të kemi 8.
Përshëndetje! Faleminderit për prezantimin tuaj! Ishte shumë interesante të dëgjoj për Terraform. Dua të jap një koment të vogël në lidhje me faktin se Terraform, megjithatë, nuk ka një lëshim stabile, prandaj duhet të jeni shumë të kujdesshëm me Terraform.
Një lugë e mirë për drekë. Që do të thotë, nëse keni nevojë për një zgjidhje, ndonjëherë e shtyni atë që nuk është e qëndrueshme, etj., por funksionon dhe na ka ndihmuar.
Kam një pyetje. Përdorni backend të largët, përdorni S3. Pse nuk përdorni backendin zyrtar?
Zyrtar?
Terraform Cloud.
Kur u shfaq?
Kohëzgjatja prej 4 muajsh.
Nëse do të ishte shfaqur 4 vjet më parë, ndoshta do të kisha përgjigjur në pyetjen tuaj.
Aty ka tashmë një funksion të integruar dhe locks, dhe mund të ruani skedarin state. Provoni. Por unë gjithashtu nuk e kam testuar.
Ne po udhëtojmë në një tren të madh, i cili lëviz me një shpejtësi të madhe. Dhe nuk mund thjesht të hiqni disa vagonë.
Folat për flakes, por përse nuk përdorët branch? Pse nuk doli ashtu?
Ne kemi një qasje të tillë, që të gjithë infrastruktura është në një repository. Terraform, Puppet, të gjitha skriptet që kanë lidhje me këtë, janë të gjitha në një repository. Kështu, mundemi të garantojmë që ndryshimet inkrementale janë testuar një pas një. Nëse do të ishte një mori branches, projekti i tillë është praktikisht i pamundur të menaxhohet. Kalojnë gjashtë muaj dhe ato të shkëputen aq shumë sa që është thjesht një dënim. Kjo është ajo nga e cila dëshironim të iknim para refaktorizimit.
Që do të thotë, kjo nuk funksionon?
Kjo në fakt nuk funksionon.
Në branch kam hequr diapazonin e dosjeve. Që do të thotë, nëse e bëni për çdo stack testues, 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 për mjedisin e testit, i cili ishte mjaft fleksibël për t'i përshtatur të gjithëve. Që do të thotë, ne mbajtëm një kod.
Përshëndetje! Emri im është Yura! Faleminderit për prezantimin! Kam një pyetje në lidhje me modulet. Ju thoni se përdorni module. Si e zgjidhni problematikën nëse bëni ndryshime në një modul, të cilat nuk janë të përshtatshme me ndryshimet e dikujt tjetër? A e përkufizoni ndonjëherë versionet e moduleve ose përpiqeni të bëni një gjë perfekte në mënyrë që të përputheni me dy kërkesa?
Kjo është një problem i madh i flakes. Kjo është ajo që ne vuajmë, kur ndonjë ndryshim i pafajshëm mund të prish një pjesë të infrastrukturës. Dhe kjo do të jetë e dukshme vetëm pas një kohe të gjatë.
Që do të thotë, ende nuk po zgjidhet?
Bëni módulo të universale. Shmangni flakes. Dhe gjithçka do të dalë mirë. Pjesa e dytë e prezantimit është se si ta evitoni këtë.
Përshëndetje! Faleminderit për prezantimin! Doja të sqaroj. Ka mbetur një grumbull i madh, për të cilin erdha. Si janë të integruar Puppet dhe shpërndarja e roleve?
User-data.
Që do të thotë, thjesht e nxirrni një skedë dhe sipas saj bëni ndonjë gjë?
User-data është si një shënim, që do të thotë, kur ne bëjmë një klon të imazhit, atje ngrihet një Daemon dhe duke u përpjekur të kuptojë se kush është, lexon shënimin që është një load balancer.
Që do të thotë, është një proces i veçantë që i jepet?
Nuk e kemi shpikur ne. E përdorim.
Përshëndetje! Kam pikërisht një pyetje në lidhje me User-data. Ju thatë se ka probleme, që dikush mund të dërgojë diçka gabim. A ka ndonjë mënyrë për të ruajtur user-data në të njëjtin Git, që gjithmonë të jetë e qartë se për çfarë i referohet User-data?
Ne e gjenerojmë User-data nga template. Që do të thotë, aty hyjnë një sasi e caktuar variabël. Dhe Terraform gjeneron rezultatin përfundimtar. Prandaj, nuk mund ta shihni thjesht template dhe të thoni se çfarë do të dalë, sepse të gjithë problemet lidhen me faktin se zhvilluesi mendon se po dërgon një string në këtë variabël, por aty hyjnë një mori. Dhe ai – bum dhe unë – ajo, ajo, rreshti tjetër, dhe gjithçka shkatërrohet. Nëse është një burim i ri dhe dikush e ngre atë, sheh që diçka nuk funksionon, kjo zgjidhet shpejt. Por nëse kjo është një grup autoscale që përditësohet, atëherë në një moment instancat në grupin autoscale fillojnë të zëvendësohen. Dhe hop, diçka nuk funksionon. Kjo është e pakëndshme.
Pra, duket se zgjidhja e vetme është të testoni?
Po, ju shihni problemin, dhe shtoni hapa testues. Që do të thotë, mund të testoni gjithashtu output-in. Ndoshta, nuk është aq e lehtë, por gjithashtu mund të vendosni disa marka – kontrolloni se User-data është këtu e lidhur fort.
Emri im është Timur. Është shumë mirë që ka prezantime për se si të organizohet saktë Terraform.
Unë as që nuk kam filluar.
Mendoj se në konferencën tjetër, ndoshta, do të ketë. Kam një pyetje të thjeshtë. Pse e keni hardkoduar vlerën në një modul të veçantë, dhe jo përdorni tfvars, që do të thotë, çfarë është më mirë një modul me vlera, sesa tfvars?
Që do të thotë, këtu (slid: Production/environment/settings.tf) duhet të shkruaj: domain = variabla, domain vpcnetwork, variabla vpcnetwork dhe stvars – të nxjerr gjithashtu të njëjtën gjë?
Ne e çfarë bëjmë. Referohemi në modulin setting source, për shembull.
Në thelb, kjo është një tfvars. Tfvars është shumë e përshtatshme në mjedisin e testing. Kam tfvars për instance të mëdha, për ato të vogla. Dhe kam hedhur një skedar në dosje. Dhe kam marrë atë që doja. Kur gdhendim infrastrukturën, duam të mund të shohim dhe të kuptojmë gjithçka menjëherë. Por ndodhi që duhet të shikoja këtu, pastaj të shikoja në tfvars.
Pra, a është e nevojshme që gjithçka të jetë në një vend?
Po, tfvars – është kur keni një kod. Dhe ai përdoret në disa vende të ndryshme me nuanca të ndryshme. Atëherë do ta hedhnit tfvars dhe do të merrnit nuancat tuaja. Dhe ne – kjo është infrastruktura si kod në mënyrë të pastër. E shikon dhe e kupton.
Përshëndetje! A keni hasur situata të tilla kur ofruesi i cloud ndërhyn në atë që keni bërë me Terraform? Për shembull, ne po ndryshojmë metadatat. Aty janë çelësat ssh. Dhe Google vazhdimisht i vendos metadat e tij dhe çelësat e tij atje. Dhe Terraform gjithmonë thotë se ka ndryshime. Pasi të kaloni çdo herë, edhe nëse nuk ka asnjë ndryshim, ai gjithmonë thotë se tani do të përditësojë këtë fushë.
Me çelësat, por – po, një pjesë e infrastrukturës është e prekur nga kjo, dmth. Terraform nuk mund të ndryshojë asgjë. Ne po ashtu nuk mund të ndryshojmë asgjë me duar. Deri tani po e përballojmë këtë.
Domethënë, keni hasur me këtë, por nuk keni gjetur një zgjidhje, ai vazhdon të veprojë vetë?
Fatkeqësisht, po.
Përshëndetje! Unë quhem Starkov Stanislav. Mail.ru Group. Si e zgjidhni problemin me gjenerimin e etiketës në …, si e dërgoni atë brenda? Mendoj se e bëni përmes User — data, për të specifikuar emrin e host-it, për të drejtuar Puppet? Dhe pjesa e dytë e pyetjes. Si e zgjidhni këtë çështje në SG, dmth. kur gjeneroni SG, një qind instance të ngjashme, si t'i emërtoni ato siç duhet?
Ato instance që janë shumë të rëndësishme për ne, ne i emërtojmë bukur. Ato që nuk nevojiten, aty ka një shtesë, që është një grup autoscale. Dhe në teori, kjo mund të mbyllet, dhe të merrni një të re.
Përsa i përket problemit me etiketën, nuk ka një problem të tillë, por ka një detyrë të tillë. Dhe etiketat tona përdoren shumë, sepse infrastruktura është e madhe dhe e shtrenjtë. Dhe duhet të shohim se ku shkojnë paratë, prandaj etiketat lejojnë të shqyrtojmë se çfarë dhe ku shkuan. Dhe, përkatësisht, të gjejmë atë, që ndonjëherë këtu shpenzohen shumë para.
Për çfarë tjetër ishte pyetjes?
Kur SG krijon një qind instance, duhet ndonjëherë të ndahen ata?
Jo, nuk ka nevojë. Çdo instance ka një agjent që njofton se kam një problem. Nëse agjenti njofton, atëherë agjenti e di për të dhe, sa të paktën, adresa e IP ekziston. Atëherë mund të veprohet. Për më tepër, ne përdorim Consul për Discovery, aty ku nuk është Kubernetes. Dhe Consul gjithashtu tregon adresën IP të instances.
Domethënë, orientoheni pikërisht në IP, dhe jo në emrin e hostit?
Nuk mund të orientoheshe sipas emrit të hostit, domethënë, janë shumë. Ka identifikues të instances – AE etj. Ajo mund të gjendet në ndonjë vend, mund ta hidhni në kërkesë.
Përshëndetje! Kuptova se Terraform është një gjë e mirë, e krijuar për cloud.
Jo vetëm.
Ky është pyetja që më intereson. Nëse vendosni të kaloni masivisht në Bare Metal me të gjithë instance tuaj? A do të ketë ndonjë problem? Ose mund të jetë e nevojshme të përdorni produkte të tjera, për shembull, Ansible që u përmend këtu?
Ansible është pak më ndryshe. Domethënë, Ansible funksionon atëherë kur instance është nisur. Ndërsa Terraform funksionon para se të nisë instance. Kalimi në Bare Metal – jo.
Aktualisht jo, por kur vjen biznesi dhe thotë: «Hajde».
Kalimi në një cloud tjetër – po, por këtu ka një përvojë të ndryshme. Duhet të shkruani kodin Terraform në një mënyrë që me sa më pak mundim të kaloni në ndonjë cloud tjetër.
Fillimisht u vendos një detyrë e tillë, që të gjithë infrastruktura jonë të jetë agnostike, domethënë çdo cloud duhet të përshtatet, por në një moment biznesi u dorëzua dhe tha: “Ok, për vitet e ardhshme N ne nuk do të ikim askund, mund të përdorim shërbimet e Amazon.”
Terraform lejon të krijoni punë Front-End, të konfiguroni PagerDuty, data doc etj. Ka shumë funskion të ndryshëm. Ai praktikisht mund të kontrollojë gjithë botën.
Faleminderit për prezantimin! Edhe unë kam katër vjet që punoj me Terraform. Në fazën e kalimit të butë në Terraform, në infrastrukturën me përshkrim deklarativ, kemi hasur situata kur dikush bëri diçka manualisht, ndërsa ti përpiqesh të bësh një plan. Dhe merrje një gabim të caktuar. Si i zgjidhni këto probleme? Si gjeni burimet e humbura, të cilat ishin specifikuar?
Në të shumtën e rasteve me duar dhe sy, nëse shohim diçka të çuditshme në raport, atëherë analizojmë se çfarë ndodh atje, ose thjesht e eliminojmë. Dhe në përgjithësi, kërkesat e tërheqjes janë një praktikë e zakonshme.
Nëse ka një gabim, a bëni rollback? A keni provuar të bëni diçka të tillë?
Jo, kjo është një vendim i njeriut në momentin kur sheh çështjen.
Burimi: habr.com
