Duket se zhvilluesit e Terraform ofrojnë praktikat më të mira mjaft të përshtatshme për të punuar me infrastrukturën AWS. Por ka një nuancë. Me kalimin e kohës, numri i ambienteve rritet, me secilin duke pasur veçoritë e veta. P nearly një kopje e piles së aplikacioneve në një region fqinj. Dhe kodi i Terraform-it duhet të kopjohet me kujdes dhe të redaktohet sipas kërkesave të reja ose të bëhet një ‘snowflake’.
Referati im për modelet në Terraform për të luftuar kaosin dhe rutinën manuale në projekte të mëdha dhe të gjata.
Video:
Jam 40 vjeç, kam 20 vjet në IT. Kam punuar 12 vjet në kompaninë Ixtens. Ne merremi me zhvillimin e drejtuar nga ecommerce. Dhe 5 vjet praktikoj praktikat DevOps.
Historia ime do të jetë për përvojën në një projekt në një kompani, emrin e së cilës nuk do ta përmend, duke u mbështetur në marrëveshjen e moszbulimit.
Numrat në slajd janë të treguar për të kuptuar shkallën e projektit. Dhe gjithçka që do të them më pas lidhet me Amazon.
U bashkova me këtë projekt 4 vjet më parë. Dhe në kulmin e tij po kalonte një ristrukturim të infrastrukturës, sepse projekti ishte rritur. Dhe ato modele që ishin përdorur nuk ishin më të përshtatshme. Dhe me të gjithë rritjen e planifikuar të projektit, duhej të mendonim diçka të re.
Faleminderit Matvej, i cili dje tregoi se çfarë ka ndodhur në Dodo Pizza. Kjo është ajo që ndodhi me ne 4 vjet më parë.
Ekipi i zhvilluesve erdhi dhe filloi të bënte kodin e infrastrukturës.
Momentet më të obvious, përse ishte e nevojshme, ishin për shkak të kohës për treg. Duhej të siguroja që ekipi DevOps të mos ishte pika e ngushtë gjatë zhvendosjes. Dhe përveç të gjitha, në nivelin e parë 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ë që ne mund ta përshkruajmë infrastrukturën tonë dhe t'u kërkojmë disa robote të bëjnë që të marrim burimet që kemi përshkruar.
Për shembull, na nevojitet makina virtuale. Ne do ta përshkruajmë, do të shtojmë disa parametra të detyrueshëm.
Pas kësaj, në konsolë do të konfigurojmë qasjen në Amazon. Dhe do t'i kërkojmë Terraform plan. Terraform plan do të thotë: "Ok, për burimin tuaj mund të bëjmë këto gjëra". Dhe, si të paktën, një burim do të shtohet. Dhe nuk pritet asnjë ndryshim.
Pasi gjithçka ju përshtatet, mund t'i kërkoni Terraform apply dhe Terraform do t'ju krijojë një instance, dhe do të merrni një makinë virtuale në re tuaj.
Më tej, projekti ynë po zhvillohet. Ne po shtojmë disa ndryshime atje. Kërkojmë më shumë instance, po shtojmë një regjistër 53.
Dhe e përsërisim. Kërkojmë planin. Shohim cilat ndryshime janë planifikuar. I aplikojmë. Dhe kështu infrastruktura jonë rritet.
Terraform përdor diçka si skedarë state. Pra, të gjitha ndryshimet që shkojnë në Amazon, ai i ruan në një skedar, ku për çdo burim që keni përshkruar, ekzistojnë burimet përkatëse që janë krijuar në Amazon. Kështu, kur ndryshoni përshkrimin e ndonjë burimi, Terraform e di saktësisht se çfarë duhet të ndryshohet në Amazon.
Këta skedarë state fillimisht ishin thjesht skedarë. Dhe ne i ruanim në Git, që ishte jashtëzakonisht e parëndësishme. Vazhdimisht dikush harronte të komitonte ndryshimet, duke shkaktuar shumë konflikte.
Tani ka mundësinë për të përdorur një backend, pra Terraform tregohet në cilin bucket, sipas çelësit duhet të ruajë skedarin state. Dhe Terraform do të kujdeset vetë për të nxjerrë këtë skedar state, për të bërë gjithë magjinë dhe për ta vendosur përsëri rezultatin përfundimtar.
Infrastruktura jonë po rritet. Këtu është kodi ynë. Dhe tani nuk duam thjesht të krijojmë një makinë virtuale, duam të kemi një mjedis testimi.
Terraform lejon të bëjmë një gjë të tillë si modul, pra ta përshkruajmë 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ç do të bënim duke ekzekutuar Terraform apply brenda modulit. Për testim do të ketë një kod të tillë.
Për prodhim ne mund të dërgojmë disa ndryshime atje, sepse në testim nuk na duhen instance të mëdha, në prodhim instance të mëdha do të ishin të dobishme.
Dhe më pas do të kthehem përsëri në projekt. Ishte një detyrë e vështirë, infrastruktura ishte planifikuar shumë e madhe. Dhe duhej të vendosej ndonjëherë e gjithë kodi, që të ishte e përshtatshme për të gjithë: për ata që bëjnë mirëmbajtjen e këtij kodi, dhe për ata që bëjnë ndryshime. Ishte planifikuar që çdo zhvillues mund të shkojë dhe të rregullojë infrastrukturën siç është e nevojshme për pjesën e tij të platformës.
Ky është një pemë katalogësh, 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 çdo pjesë të përshkruhet në një dosje të veçantë.
Duke pasur një bibliotekë të gjerë burimesh, në testim dhe në prodhim mund të thërrasim për rreth të njëjtën gjë.
Në rastin tonë, kjo nuk ishte plotësisht e përshtatshme, sepse testi i stack-ut për zhvilluesit ose për testim duhej të ishte më i thjeshtë për t'u marrë. Nuk doja të shkoja nëpër dosje dhe të aplikoja në një rend të caktuar, duke u shqetësuar nëse baza do ngrihej dhe pastaj do ngrihej instanca që përdor këtë bazë. Prandaj, të gjitha testet filluan nga një dosje e vetme. Atje u thirrën të njëjtat module, por e gjitha u kalua në një shtesë.
Terraform merret me të gjitha varësitë. Dhe gjithmonë krijon burimet në rendin që lejon marrjen e një adrese IP, për shembull, nga instanca e sapo krijuar, dhe merr këtë adresë IP në regjistrimin route53.
Për më tepër, platforma është shumë e madhe. Dhe nisja e stack-ut të testit, edhe nëse është për një orë, edhe nëse për 8 orë – është një proces mjaft i kushtueshëm.
Dhe ne e automatizuam këtë proces. Dhe punësimi i Jenkins mundësonte nisjen e stack-ut. Duhej të nisnim kërkesën për tërheqje me ndryshimet që zhvilluesi dëshironte të testonte, duke treguar të gjitha opsionet e nevojshme, komponentët, si dhe dimensionet. Nëse ai dëshiron testim të performancës, mund të marrë më shumë instance. Nëse thjesht dëshiron të kontrollojë që një formular hapet, mund të fillojë me minimumet. Gjithashtu, duhej të tregonte nëse duhej një klaster ose jo, etj.
Dhe pastaj Jenkins e shtypte skriptin e shell-it, i cili modifikonte pak kodin në dosjen Terraform. Hiqte skedarët e panevojshëm, shtonte skedarët e nevojshëm. Dhe pastaj, me një kalim, Terraform apply ngrihej stack-u.
Pas kësaj vinin hapat e tjerë, në të cilat nuk dëshiroj të thellohem.
Për shkak se për testim na duhej pak më shumë mundësi sesa në prodhim, na duhej të bënim kopje të moduleve, në mënyrë që në këto kopje të mund të shtonim ato karakteristika që janë të nevojshme vetëm për testim.
Dhe kështu ndodhi që në testim duket se dëshirohej të testoheshin ato ndryshime që përfundimisht do shkonin në prodhim. Por në të vërtetë, një gjë u testua, ndërsa në prodhim aplikohej diçka tjetër. Dhe kishte një mungesë të vogël të marrëdhënies, që në prodhim të gjitha ndryshimet aplikohej nga ekipi operativ. Dhe ndonjë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 të tillë se një shërbim i ri ishte shtuar, që dallohej pak nga ndonjë shërbim 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, atëherë ne e deklarojmë. Dhe gjithçka funksionon.
Në një moment, kur ishte duke u diskutuar një nga kërkesat e mia për bashkimin, një nga kolegët tha se nuk duhet të prodhohen flokë. Unë u interesova se çfarë donte të thoshte ai. Ekziston një fakt shkencor, se në botë nuk ekzistojnë dy flokë të njëjtë, të gjithë ata dallohet pak. Dhe sa herë që e dëgjova këtë, ndjeva menjëherë tërë peshën e kodit Terraform. Sepse kur ishte e nevojshme të kalonit nga një version në një tjetër, Terraform kërkonte ndryshime të rëndësishme, domethënë kodi nuk ishte më i përputhshëm me versionin tjetër. Dhe duhej bërë një kërkesë për bashkimin, e cila mb covering almost half of the files in the infrastructure to bring the infrastructure to the next version of Terraform.
Dhe pas shfaqjes së këtij floku, tërë kodi Terraform që kishim shndërrohej në një grumbull të madh floku.
Për një zhvillues të jashtëm, i cili është jashtë operacionit, kjo nuk ka shumë rëndësi, sepse ai bëri një kërkesë për bashkimin, burimi i tij u ndez. Dhe kjo është, më tej nuk është brengosja e tij. Por, ekipi DevOps, i cili ndjek që gjithçka të jetë në rregull, duhet të bëjë të gjitha këto ndryshime. Dhe kostoja e këtyre ndryshimeve rritej shumë me çdo copë të إضافuar.
Ka një histori për një student që në seminar pikturon me leckë në bord dy rreth të përsosur. Dhe profesori habitet se si ia doli kaq mirë pa kompast. Studenti përgjigjet: “Shumë thjesht, kam rrotulluar një makinë mishi për dy vjet në ushtri.”
Dhe nga ato katër vjet, në të cilat kam marrë pjesë në këtë projekt, rreth dy vjet kam punuar me Terraform. Dhe, sigurisht, kam disa truke, disa këshilla, se si mund ta thjeshtoj kodin Terraform, ta përdor si një gjuhë programuese dhe të ulem ngarkesën për zhvilluesit, të cilët duhet ta mbajnë këtë kod në gjendje të përditësuar.
E para, çka dëshiroj të filloj, janë Symlinks. Terraform ka shumë kode të përsëritura. Për shembull, thirrja e ofruesit është praktikisht në çdo pikë ku ne krijojmë një copë infrastrukture, e njëjtë. Dhe është logjike ta nxjerrim në një dosje të veçantë. E në çdo vend ku kërkohet ofruesi, të krijojmë Symlinks për këtë skedar.
Për shembull, në prodhim keni një rol të supozuar, që ju lejon të fitoni të drejta për ndonjë llogari të jashtme në Amazon. Dhe duke ndryshuar një skedar, të gjitha skedarët e tjerë në pemën e burimeve do të kenë të drejtat e nevojshme, që Terraform të dijë në cilin segment të Amazon-it të drejtohet.
Ku nuk funksionojnë Symlinks? Siç e thashë, në Terraform ka skedarë state. Dhe ata janë shumë, shumë të shkëlqyer. Por problemi është se Terraform inicializon backend-in në të parin. Dhe ai nuk mund të përdorë në këto parametra ndonjë variabël, gjithmonë duhet t'i shkruani ato në tekst.
Si rezultat, kur dikush krijon një burim të ri, ai kopjon një pjesë të kodit nga dosje të tjera. Dhe mund të gabojë me çelësin ose me bucket-in. Për shembull, ai nga sandbox bën diçka nga sandbox, dhe pastaj e bën në prodhim. Dhe kështu mund të ndodhi që bucket-i në prodhim të përdoret nga sandbox. Sigurisht, kjo do të zbuloheshin shpejt. Mund të rregullohet ndonjëherë, por megjithatë kjo është një humbje kohe dhe në një farë mënyre burimesh.
Çfarë mund të bëjmë më tej? Para se të punojmë me Terraform, duhet ta inicializojmë atë. Në momentin e inicializimit, Terraform shkarkon të gjitha plugin-et. Ato në një moment u ndanë nga monoliti në një arkitekturë më mikrosherbimesh. Dhe gjithmonë duhet të bëni Terraform init, që të tërheqë të gjithë modulët, të gjitha plugin-et.
Dhe mund të përdorni një skrypt shell, i cili, në radhë të parë, mund të nxjerrë të gjitha variablat. Skripti shell nuk ka kufizime. Dhe, në radhë të dytë, rrugët. Nëse ne gjithmonë përdorim atë rrugë, e cila është në depo si çelësi për skedarin e state-it, atëherë, sipas rrethanave, gabimi këtu do të përjashtohet.
Nga ku mund të merret të dhëna? Skedari JSON. Terraform lejon regjistrimin e infrastrukturës jo vetëm në hcl (HashiCorp Configuration Language), por gjithashtu në JSON.
JSON lehtësisht lexon nga skripti shell. Prandaj, mund të vendosni diku skedarin e konfigurimit me bucket. Dhe të përdorni këtë bucket si në kodin Terraform, ashtu edhe në skriptin shell për inicializim.
Përse është e rëndësishme të kesh një bucket për Terraform? Sepse ekziston diçka si skedarët remote state. Pra, kur ngrej një burim, duhet t'i tregoj Amazon-it: "Të lutem, ngre instance", dhe duhet të listoj shumë parametra të detyrueshëm.
Dhe këto identifikues ruhen në një folder tjetër. Dhe unë mund të them: "Terraform, shko të lutem në skedarin state të atij burimi dhe më nxirr këta identifikues." Kështu, krijohet një formë unifikimi midis rajoneve të ndryshme ose mjediseve.
Nuk është gjithmonë e mundur të përdorësh një skedar remote state. Për shembull, nëse e ke krijuar manualisht një VPC. Dhe kodi Terraform që krijon VPC-në është kaq i ndryshëm që do të duhet ta përshtasësh për një kohë të gjatë, kështu që mund të përdorim një truk tjetër.
Pra, të krijosh një modul që siç do krijonte një VPC dhe do të të jepte identifikuesit, ndërsa në të vërtetë ka një skedë me vlera të koduara që mund të përdoren për të krijuar të njëjtin instance.
Nuk është gjithmonë e nevojshme të ruhet një skedar state në cloud. Për shembull, kur testohen modulët, mund të përdoret inicializimi i backend-it, ku skedari do të ruhet thjesht në disk gjatë testimit.
Tani pak për testimin. Çfarë mund të testohet në Terraform? Sigurisht, shumë gjëra mund të testohet, por unë do të flas për këto 4 elemente.
HashiCorp ka një kuptim se si duhet të formatohet kodi Terraform. Dhe Terraform fmt të lejon të formatosh kodin që po redakton në përputhje me këtë besim. Prandaj, testet duhet patjetër të kontrollojnë nëse formati përputhet me atë që ka lënë HashiCorp, për të mos pasur nevojë të ndryshosh vendosjen e thonjëve etj.
Tjetra është Terraform validate. Ai bën pak më shumë se kontrolli i sintaksës - si, a janë të gjitha thonjëzat çift. Çfarë është e rëndësishme këtu? Infrastruktura jonë është shumë e zmadhuar. Ka shumë foldere të ndryshme. Dhe në çdo një prej tyre duhet të ekzekutojmë Terraform validate.
Pra, për të përshpejtuar testimin, ne ekzekutojmë disa procese paralelisht, duke përdorur paralelizmin.
Paralelizmi është një gjë shumë e shkëlqyer, përdoreni.
Por çdo herë që ndodh inicializimi i Terraform, ai shkon te HashiCorp dhe pyet: "Cilat janë versionet më të fundit të pluginëve? Dhe ai plugin që kam në cache – është ai apo jo?". Dhe kjo në çdo hap krijon një ngadalësim.
Nëse i jepet Terraformit vendndodhja e pluginëve, ai do të thotë: "Ok, ndoshta kjo është më e freskët që ka. Nuk do të shkoj askund, do të filloj menjëherë të validioj kodin tuaj Terraform."
Për ta mbushur dosjen me pluginët e nevojshëm, kemi një kod shumë të thjeshtë Terraform që duhet thjesht të inicializohet. Këtu, sigurisht, duhet të tregojmë të gjithë ofruesit që janë përfshirë në kodin tuaj, përndryshe Terraform do të thotë: "Nuk e di ndonjë ofrues, sepse ai nuk është në cache."
E nesërmja është Terraform plan. Siç e thashë, zhvillimi është ciklik. Ne bëjmë kod me ndryshime. Dhe më pas duhet të kuptojmë se cilat ndryshime planifikohen për infrastrukturën.
Dhe kur infrastruktura është shumë- shumë e madhe, mund të ndryshosh një modul, të rregullosh një ambient testi ose ndonjë rajon konkret dhe të thysh ndonjë të afërt. Prandaj, plani i Terraform duhet të bëhet për të gjithë infrastrukturën dhe të tregojë cilat ndryshime planifikohen.
Këtë mund ta bësh në mënyrë inteligjente. Ne, për shembull, kemi shkruar një skript në Python që zgjidh varësitë. Dhe në varësi të asaj që është ndryshuar: moduli Terraform ose thjesht ndonjë komponent konkret, ai bën plane për të gjitha dosjet e varura.
Plani i Terraform duhet të bëhet me kërkesë. Të paktën, kjo është ajo që bëjmë ne.
Testet, natyrisht, janë të mira për çdo ndryshim, për çdo komit, por planet – janë një gjë mjaft e kushtueshme. Dhe në pull request themi: "Të lutem, më jep planet." Aktivizohet një robot. Dhe ai dërgon në komente ose në attach 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 ky autoscale të njëjtat parametra?". Dhe për ta përshpejtuar këtë, mund të përdorim një parametrë si refresh=false. Kjo do të thotë se Terraform do të shkarkojë nga S3 state. Dhe do të besojë se state do të përputhet saktësisht me atë që gjendet në Amazon.
Ky Terraform plan kalon ndjeshëm më shpejt, por state duhet të përputhet me infrastrukturën tuaj, dmth. diku, dikur duhet të aktivizohet Terraform refresh. Terraform refresh bën atë që duhet për të siguruar që state përputhet me atë që është në infrastrukturën reale.
Dhe duhet të flasim për sigurinë. Këtu duhej të fillonim. Atje ku ju aktivizoni Terraform, dhe Terraform punon me infrastrukturën tuaj, ka një vulnerabilitet. Domethënë, 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 shumë akses. Prandaj, jini të kujdesshëm ku e aktivizoni Terraform plan.
E next që 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 nga instance - meta-të dhëna. Kur instance starton, zakonisht 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 zakone kryen disa veprime.
Por, fatkeqësisht, kur bëjmë Terraform plan dhe Terraform apply, user-data duket si një grumbull me numra. Domethënë, ai thjesht ju dërgon një hash. Dhe e gjithë ajo që mund të shihni në plan është nëse do të ketë ndonjë ndryshim ose hash do të mbetet i njëjtë.
Dhe nëse nuk i kushtoni vëmendje, atëherë në Amazon, në infrastrukturën reale, mund të shkojë ndonjë skedar i ndotur tekstual.
Si një opsion, mund të tregoni gjatë ekzekutimit jo të gjithë infrastrukturën, por vetëm template-in. Dhe në kod, të thoni: "Ju lutem, më tregoni këtë template". Dhe në fund mund të merrni një printim se si do të duken të dhënat tuaja në Amazon.
Një opsion tjetër është të përdorni një modul për gjenerimin e user-data. Do ta përdorni këtë modul. Merrni një skedar në disk. E krahasoni atë me referencën. Dhe në këtë mënyrë, nëse ndonjë junior vendos të përmirësojë pak user-data, testet tuaja do të thonë: "Ok, këtu dhe këtu ka disa ndryshime – kjo është në rregull".
E next që do të doja të flisja është Automate Terraform apply.
Sigurisht, është mjaft frikëshme të bësh Terraform apply në mënyrë automatike, sepse, kush e di se çfarë ndryshimesh janë bërë dhe sa shkatërruese mund të jenë për infrastrukturën e gjallë.
Për një mjedis testimi – kjo është gjëja e duhur. Do të thotë, puna që krijon një mjedis testimi është ajo që i nevojitet të gjithë zhvilluesve. Dhe një shprehje si "më punoi gjithçka" – nuk është një meme qesharake, por një provë që personi u angazhua, ngriti stakun, ekzekutoi disa teste mbi këtë stak. Dhe u siguruar që gjithçka ishte në rregull dhe tha: "Ok, kodi që po lë shoë është testuar."
Në prodhim, sandbox dhe ambiente të tjera, të cilat janë më të rëndësishme për biznesin, mund të aplikohet pjesërisht disa resurse mjaft të sigurta, sepse kjo nuk çon në ndonjë pasojë fatale. Këto janë: grupet autoscale, grupet e sigurisë, rolet, route53 dhe lista mund të jetë mjaft e madhe. Por monitoroni atë që ndodh, lexoni raportet mbi aplikimet automatike.
Aty ku aplikimi është i rrezikshëm ose frikshëm, për shembull, nëse janë disa resurse me persistent, me baza të dhënash, merrni raportet për atë që ka disa ndryshime të paplikuar në një pjesë të infrastrukturës. Dhe inxhinieri nën mbikëqyrje ekzekuton punët për të aplikuar ose e bën këtë nga konsola e tij.
Në Amazon ka një funksion që quhet Mbrojtja nga përfundimi. Dhe ajo mund të mbrojë në disa raste nga ndryshime të paautorizuara për ju. Do të thotë, Terraform shkoi në Amazon dhe thotë: "Më nevojitet të vras këtë instance, për të krijuar një tjetër." Dhe Amazon thotë: "Më fal, jo sot. Kemi vendosur Mbrojtjen nga përfundimi."
Dhe kokrra mbi tortë – është optimizimi i kodit. Kur punojmë me kodin e Terraform, duhet të kalojmë në modul një numër të madh parametrash. Këto janë parametrat që nevojiten për të krijuar një burim të caktuar. Dhe kodi shndërrohet në lista të mëdha parametrash që duhet të kalohen nga moduli në modul, nga moduli në modul, sidomos nëse modulet janë të ngulitura.
Kjo është shumë e vështirë për t'u lexuar. Është shumë e vështirë për të bërë një rishikim. Dhe shpesh ndodh që disa parametra kalojnë rishikimin dhe nuk janë plotësisht ato që nevojiten. Dhe kjo kushton kohë dhe para për t'u korrigjuar më pas.
Prandaj, ju rekomandoj të përdorni një funksion të tillë si parametri kompleks, i cili përfshin një pemë vlerash. Do të thotë, ju nevojitet një dosje, ku janë përshkruar të gjitha vlerat, të cilat dëshironi të keni në një ambient të caktuar.
Dhe duke thirrur këtë modul, mund të merrni një pemë që gjenerohet në një modul të përbashkët, pra 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 llogarira, duke përdorur një veçori të re në Terraform, siç janë locals. Dhe më pas me një output mund të ofroni një parametër të komplikuar, i cili mund të përfshijë hash, arrays, etj.
Kjo që kam përshkruar deri tani, është ndoshta gjëra mjaft të thjeshta dhe triviale. Dhe kur i njihni dhe filloni t'i përdorni, kjo është e natyrshme. Pra, përdorini. Dhe nëse për ju këto janë gjëra krejt normale, atëherë të paktën e dini se si të vendosni një vezë që të mos bjerë.
Le të përmblidhim:
Përpiquni të shmangni flokët e borës. Dhe sa më pak flokë bore të ketë, aq më pak burime do t'ju nevojiten për të bërë disa ndryshime në tërë infrastrukturën tuaj të madhe.
- Ndryshime të vazhdueshme. Pra, kur ka ndodhur ndonjë ndryshim në kod, duhet sa më shpejt të përshtatni infrastrukturën tuaj me këto ndryshime. Nuk duhet të ndodhë që dikush pas dy-tre muajsh të vijë të shikojë Elasticsearch, të bëjë një Terraform plan, dhe të ketë shumë ndryshime që nuk i priste. Dhe ndyshimi i shumë gjërave merr shumë kohë për t'u vënë përsëri në rregull.
- Testet dhe automatizimi. Sa më shumë që kodi juaj të jetë i mbuluar me teste dhe veçori, aq më shumë besim keni se po e bëni gjithçka siç duhet. Dhe dorëzimi automatik do të rrisë shumëfish besimin tuaj.
- Testet dhe automatizimi. Sa më shumë që kodi juaj të jetë i mbuluar me teste dhe veçori, aq më shumë besim keni se po e bëni gjithçka siç duhet. Dorëzimi automatik do të rrisë shumëfish besimin tuaj.
- Kodi për ambientet e testimit dhe prodhimit duhet të jenë praktikisht të njëjtë. Praktikisht, sepse prodhimi është pak ndryshe dhe gjithsesi do të ketë ndonjë nuancë që do të dalë jashtë ambicieve të testimit. Por megjithatë, plus-minus mund ta sigurojmë këtë.
- Dhe nëse keni shumë Kodi Terraform dhe për mbajtjen e këtij kodi në gjendje aktuale kërkohet shumë kohë, kurrë nuk është vonë të bëni refaktorizimin dhe ta sillni në një formë të mirë.
- Infrastruktura e palëvizshme. Dorëzimi i AMI-së sipas një programi.
- Struktura për route53, kur keni shumë regjistra dhe dëshironi që ata të jenë në një rend të rregullt.
- Lufta me kufijtë e normave të API. Kjo është kur Amazon thotë: "Të gjitha, nuk mund të pranoj më kërkesa, ju lutem prisni". Dhe gjysma e kompanisë pret derisa të jetë në gjendje të nisë infrastrukturën e saj.
- Instancat Spot. Amazon – një aktivitet jo i lirë dhe spots lejojnë të kurseni mjaft. Edhe mund të flitet për këtë me një raport të plotë.
- Siguria dhe rolet IAM.
- Kërkimi i resurseve të humbura, kur keni instancat me origjinë të paqartë në Amazon, ato konsumojnë para. Edhe nëse një instancë kushton 100-150 dollarë në muaj – për një vit kjo është më shumë se 1,000. Kërkimi i këtyre resurseve është një biznes i dobishëm.
- Dhe instancat e rezervuara.
Këtë kam për sot. Terraform – është shumë e shkëlqyer, përdoreni. Faleminderit!
Pyetje
Faleminderit për raportin! Ju keni skedarin e state në S3, por si e zgjidhni problemin që disa persona mund ta marrin këtë skedar të state dhe të përpiqen të zbatojnë?
Së pari, ne nuk nxitohemi. Së dyti, ka flag-e, në të cilën njoftojmë se po punojmë mbi ndonjë segment kodi. Kështu, përkundër faktit që infrastruktura është shumë e madhe, kjo nuk do të thotë që gjithmonë dikush po aplikon ndonjë qëndrim. Dhe kur kishte një fazë aktive – kjo ishte një problem; skedarët tanë të state ishin ruajtur në Git. Kjo ishte e rëndësishme, ndryshe dikush do të bënte një skedar të state, dhe na duhej të mbledhim ato manualisht që gjithçka të vazhdonte. Tani një problem të tillë nuk ka. Megjithatë, Terraform ka zgjidhur këtë çështje. Dhe nëse diçka ndryshon vazhdimisht, mund të përdoren locks, që parandalojnë atë që ju thatë.
A përdorni versionin e hapur apo enterprise?
Asnjë enterprise, pra, gjithçka që mund të shkoni dhe ta shkarkoni falas.
Më quajnë Stanislav. Doja të bëja një shtesë të vogël. Ju folët për veçorinë e Amazon-it që lejon të krijoni instanca të pathyeshme. Kjo është e pranishme edhe në Terraform vetë, në bllokun Life Second mund të shkruani një ndalim të ndryshimit, ose një ndalim të shkatërrimit.
Ishte i kufizuar në kohë. Një vërejtje e mirë.
Po dëshiroja të pyesja dy gjëra. Së pari, ju folët për testimin. A keni përdorur ndonjë mjet për testim? Kam dëgjuar për plugin-in Test Kitchen. Ndoshta ka diçka tjetër. Dhe do doja të pyesja gjithashtu për Vlerat Lokale. Si i dallohen ato në thelb nga Variablat e Input? Dhe pse nuk mund të parametrizoj diçka vetëm përmes Vlerave Lokale? Kam përpjekur të kuptoj këtë temë, por nuk kam pasur fat.
Mund të flasim më në hollësi pas këtij dhome. Mjetet për testim – për ne janë krejtësisht të bërë nga vetja. Nuk ka asgjë që mund të testohet aty. Në përgjithësi, ka mundësi kur testet automatike ngrejnë infrastrukturën diku, kontrollojnë që ajo është mirë, dhe pastaj e shkatërrojnë me një raport që infrastruktura juaj është ende në formë të mirë. Ne nuk kemi këtë, sepse stekat provuese ngrihen çdo ditë. Dhe kjo është e mjaftueshme. Nëse diçka fillon të prishet, do të fillojë të prishet pa ne që e kontrollojmë më parë diku tjetër.
Përsa i përket Vlerave Lokale, le të vazhdojmë bisedën pas sallës.
Përshëndetje! Faleminderit për leksionin! Ishte shumë informues. Ju folët se keni shumë kod njëlloj 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 përdorim infrastrukturën si kod, ne supozojmë se po shohim kodin dhe kuptojmë se cila infrastrukturë qëndron pas këtij Kodi. Nëse kodi gjenerohet, atëherë na nevojitet të imagjinojmë se cili kod do të gjenerohet për të kuptuar se cila infrastrukturë do të jetë atje. Ose ne gjenerojmë kodin, e angazhojmë dhe, në thelb, rezulton e njëjta gjë. Prandaj ne e ndoqëm rrugën siç shkruajti, këtë e morëm. Përveç kësaj, gjeneratorët u shfaqën disa më vonë, kur ne filluam ta bënim. Dhe tashmë ishte vonë për të ndërruar.
A keni dëgjuar ndonjëherë për jsonnet?
Jo.
Shiko, kjo është një gjë shumë e shkëlqyer. Unë shoh një rast të qartë ku mund ta aplikojmë dhe të gjenerojmë strukturën e të dhënave.
Generatorët janë të mira, siç thotë një anekdotë për makinën e rruajtjes. Domethënë, herën e parë fytyra është e ndryshme, por më vonë të gjithëve fytyra është e njëjtë. Generatorët janë shumë të mirë. Por ne, fatkeqësisht, kemi fytyra paksa të ndryshme. Kjo është një problem.
Thjesht shiko. Faleminderit!
Më quajnë Maksim, unë jam nga Sberbank. Ju keni folur pak për përpjekjen për të sjellë Terraformin në një analogji me gjuhën e programimit. A nuk është më e lehtë të përdorni Ansible?
Këto janë shumë gjëra të ndryshme. Mund të krijosh burime me Ansible, dhe mund të krijosh burime me Puppet në Amazon. Por Terraform është krijuar pikërisht për këtë.
A keni vetëm Amazon?
Nuk është se kemi vetëm Amazon. Çdo gjë është pothuajse vetëm Amazon. Por karakteristika kryesore është se Terraform mban në mend. Në Ansible, nëse thua: "Më ngri 5 instance", ai do t'i ngrejë, dhe më pas ti thua: "Tani më duhen 3". Dhe Terraform do të thotë: "Ok, do të heq 2", ndërsa Ansible do të thotë: "Ok, ja 3". Pra, gjithsej 8.
Përshëndetje! Faleminderit për referatin tuaj! Ishte shumë interesante të dëgjoja për Terraform. Menjëherë dua të jap një koment të vogël në lidhje me faktin se Terraform për fat të keq nuk ka një version stabil, kështu që duhet të keni shumë kujdes kur e përdorni Terraform.
Një lugë është e mirë në drekë. Domethënë, nëse keni nevojë për një zgjidhje, ndonjëherë e shtyni atë që është e paqëndrueshme etj., por ajo punon dhe na ka ndihmuar.
Kam një pyetje. Po përdorni Remote backend, po përdorni S3. Pse nuk e përdorni backendin zyrtar?
Zyrtar?
Terraform Cloud.
Kur u shfaq ai?
Para rreth 4 muajve.
Nëse do të kishte dalë 4 vjet më parë, ndoshta do të kisha përgjigjur pyetjes suaj.
Atje ka funksione të ndërtuara si locks dhe mund të ruash skedarin e state-it. Provoni. Por unë gjithashtu nuk e kam testuar.
Ne udhëtojmë me një tren të madh, që lëviz me një shpejtësi të madhe. Dhe nuk mund të heqësh thjesht disa vagona.
Dhe ju thatë diçka për borën, pse nuk e përdorët branch-in? Pse nuk ia dolët të bëni kështu?
Ne kemi një qasje të tillë, që e gjithë infrastruktura është në një depo. Terraform, Puppet, të gjitha skenaret që kanë të bëjnë me këtë, janë të gjitha në një depo. Kështu mund të garantojmë se ndryshimet inkrementale janë testuar një pas një. Nëse do të ishte një mori branch-e, një projekt i tillë është praktikisht i pamundur për t'u mbajtur. Kalojnë gjashtë muaj dhe ata shkëputen aq shumë saqë është thjesht një ndëshkim. Kjo është ajo nga e cila doja të ikja para ristrukturimit.
Domethënë, nuk funksionon?
Kjo nuk funksionon fare.
Në branch kam hequr sliden e dosjeve. Do të thotë, nëse bëjmë një dosje për çdo grup testimi, për shembull, për ekipin A – ka një dosje të vetën, për ekipin B një dosje tjetër, atëherë kjo gjithashtu nuk funksionon. Krijuam një kod të unifikuar për mjedisin e testimeve, i cili ishte mjaft fleksibël për t'iu përshtatur të gjithëve. Do të thotë, e shërbenim një kod.
Përshëndetje! Emri im është Jura! Faleminderit për prezantimin! Kam një pyetje rreth moduleve. Ju thoni se përdorni module. Si e zgjidhni problemin nëse në një modul bëni ndryshime që nuk janë të pajtueshme me ndryshimet e dikujt tjetër? E bëni ndonjë versionim të moduleve apo përpiqeni të bëni një zgjidhje për të përmbushur dy kërkesa?
Kjo është një problem i madh dhe i komplikuar. Kjo është ajo çka ne vuajmë kur një ndryshim i dukshëm mund të prishë një pjesë të infrastrukturës. Dhe kjo do të ndjehet vetëm pas një periudhe të gjatë.
Do të thotë, ende nuk po zgjidhet?
Ju krijoni module universale. Shmangni copat e bardha. Dhe çdo gjë do të funksionojë. Pjesa e dytë e prezantimit është për atë se si ta evitoni këtë.
Përshëndetje! Faleminderit për prezantimin! Doja të sqaroj. Pas mbrapa është një grumbull i madh, për të cilin kam ardhur. Si janë integruar Puppet dhe ndarja e roleve?
User-data.
Do të thotë, thjesht nxirrni një file dhe sipas tij siç do të veproni?
User-data – është një shënim, do të thotë, kur bëjmë një klon të imazhit, atëherë ngrihet një Daemon që përpiqet të kuptojë kush është dhe lexon shënimin se është load balancer.
Do të thotë, është një proces i veçantë, që jepet?
Ne nuk e shpikëm atë. Ne po e përdorim.
Përshëndetje! Kam një pyetje rreth User-data. Ju thatë se aty ka probleme, që dikush mund të dërgojë diçka në mënyrë të gabuar. A ka ndonjë mënyrë për të ruajtur user-data në të njëjtin Git, që gjithmonë të jetë e qartë për çfarë referohet User-data?
Ne generojmë User-data nga template. Kjo do të thotë se në të përfshihen disa variabla. Dhe Terraform gjeneron rezultatin përfundimtar. Prandaj, nuk mund të shikoni thjesht në template dhe të thoni se çfarë do të dalë, sepse të gjitha problemet lidhen me faktin se zhvilluesi mendon se po dërgon një varg në këtë variabël, ndërsa aty mbërrin një array. Dhe befas, ja ku jemi – ajo që ndodhi, rreshti tjetër, dhe gjithçka dështoi. Nëse është një burim i ri dhe personi e ngre atë, sheh se diçka nuk funksionon, atëherë kjo zgjidhet shpejt. Por nëse kjo është një grup autoscale që u përditësua, atëherë në një moment instancat në grupin autoscale fillojnë të ndërrhen. Dhe befas, diçka nuk funksionon. Kjo është e mërzitshme.
Pra, e vetmja zgjidhje është të testoni?
Po, ju e shihni problemin, i shtoni hapa testimi. Kjo do të thotë se edhe output-i mund të testohet. Ndoshta, nuk është aq e rehatshme, por gjithashtu mund të vendosni disa shenja – kontrolloni se çfarë User-data është këtu e lidhur fort.
Më quajnë Timur. Është shumë mirë që ka prezantime se si të organizoni saktë Terraform.
As nuk kam filluar.
Mendoj se në konferencën e ardhshme ndoshta do të ketë. Kam një pyetje të thjeshtë. Pse e hardcodoni vlerën në një modul të veçantë, dhe jo përdorni tfvars, pra, çfarë është më mirë modul me vlera sesa tfvars?
Pra, këtu (slajdi: Production/environment/settings.tf) duhet të shkruaj: domain = variabla, domain vpcnetwork, variabla vpcnetwork dhe stvars – të nxjerr gjithashtu të njëjtën gjë?
Ne bëjmë gjithashtu kështu. Referojmë në burimin e modulit të cilësisë, për shembull.
Në thelb, kjo është një lloj tfvars. Tfvars është shumë i përshtatshëm në mjedisin e testimit. Kam tfvars për instanca të mëdha, për të vogla. Dhe një skedar e hedh në dosje. Dhe kam marrë atë që doja. Kur ne ndërtojmë infrastrukturën, duam që të jetë e mundur të shikosh dhe të kuptosh menjëherë gjithçka. Por kështu del që duhet të shohim këtu, më pas të shohim në tfvars.
Pra, do të thotë që të gjitha të jenë 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 t'i jepnit tfvars dhe do të merrnit nuancat tuaja. Ndërsa ne jemi – kjo është infrastruktura si kod në formën më të pastër. E shikove dhe e kuptove.
Përshëndetje! Keni përjetuar ndonjëherë situata kur ofruesi i cloud-it ndërhyn në atë që keni bërë me Terraform? Supozoni se ne po modifikojmë metadatat. Aty janë çelësat ssh. Dhe Google vazhdimisht i fut metadatat e tij, çelësat e tij. Dhe Terraform gjithmonë thotë se ka ndryshime. Pas çdo ekzekutimi, edhe nëse nuk ka asnjë ndryshim, ai gjithmonë thotë se do ta azhurnoje këtë fushë.
Me çelësat, por – po, një pjesë e infrastrukturës është e prekur nga një gjë e tillë, domethënë Terraform nuk mund të ndryshojë asgjë. Ne gjithashtu nuk mund të bëjmë asnjë ndryshim me dorë. Deri tani jetojmë me këtë.
Domethënë, ju e keni hasur këtë, por nuk keni gjetur asnjë zgjidhje, ai bën si bën dhe vazhdon e bën 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? Kam kuptuar, përmes User — data, për të specifikuar emrin e host-it, ta drejtoni Puppet? Dhe pjesa e dytë e pyetjes. Si e zgjidhni këtë çështje në SG, domethënë kur gjeneroni SG, njëqind instanca të ngjashme, si t'i quani ato saktësisht?
Instancat që janë shumë të rëndësishme për ne, ne i emërtojmë bukur. Ato që nuk na nevojiten, atje ka një shënim që është grup autoscale. Dhe në parim, kjo mund të hiqet, dhe të merret një e re.
Sa i përket problemit me etiketën, nuk ekziston një problem, por ka një detyrë të tillë. Dhe etiketat tona përdoren shumë, sepse infrastruktura është e madhe dhe e shtrenjtë. Dhe na duhen për të parë se ku shkojnë paratë, prandaj etiketat na lejojnë të shohim se çfarë dhe ku është shpenzuar. Dhe, për pasojë, të gjejmë atë që shpenzohet shumë para.
Çfarë tjetër ishte pyetja?
Kur SG krijon njëqind instanca, a duhet t'i dalloni ato ndonjëherë?
Jo, nuk ka nevojë. Në çdo instancë ka një agjent, i cili raporton se kam një problem. Nëse agjenti raporton, agjenti e di për të dhe, të paktën, adresa e tij IP ekziston. Mund të shkoni. 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ë instancës.
Domethënë, ju orientoheni pikërisht në IP, dhe jo në emrin e host-it?
Nuk është e mundur të orientohesh me emrin e host-it, domethënë, ato janë shumë të shumta. Ka identifikues instancash – AE etj. Mund ta gjeni diku, mund ta kërkoni.
Përshëndetje! E kuptova që Terraform është një gjë e mirë, e përshtatur për cloud.
Jo vetëm.
Ky kyç e pikëllojë mua. Po, nëse vendosni të kaloni masivisht në Bare Metal me të gjithë instancat tuaja? A do të ketë ndonjë problem? Apo ndoshta do të duhet të përdorni produkte të tjera, si Ansible, që u përmend këtu?
Ansible merret pak ndryshe. Do të thotë, Ansible funksionon vetëm pasi instanca të ketë nisur. Ndërsa Terraform funksionon para se të nisë instanca. Kalimi në Bare Metal – jo.
Tani nuk ka, por kur të vijë biznesi dhe të thotë: «Le të fillojmë».
Kalimi në një cloud tjetër – po, por këtu është një tjetër çështje. Duhet të shkruani kodin Terraform kështu që të kaloni në ndonjë cloud tjetër pa shumë vështirësi.
Fillimisht kishte një objektiv të tillë, që të gjithë infrastruktura jonë të ishte agnostike, do të thotë, çdo cloud duhet të ishte i përshtatshëm, por në një moment biznesi u dorëzua dhe tha: «Mirë, për vitet e ardhshme N, nuk do të largohemi, mund të përdorim shërbimet e Amazon».
Terraform lejon krijimin e jobs në Front-End, konfigurimin e PagerDuty, dokumentacionit të të dhënave etj. Ka shumë funksione. Praktikisht mund të kontrollojë të gjithë botën.
Faleminderit për prezantimin! Edhe unë po punoj me Terraform për 4 vjet. Në fazën e kalimit të butë në Terraform, në infrastrukturë, në përshkrimin deklarativ, përballeshim me situata ku dikush bëntë diçka me dorë, ndërsa ti përpiqeshe të bënte një plan. Dhe merrje ndonjë gabim atje. Si i zgjidhni këto probleme? Si i gjeni burimet e humbura që ishin të përfshirë?
Kryesisht me dorë dhe sy, nëse shohim diçka të çuditshme në raport, analizojmë se çfarë ndodh aty, ose thjesht e anulojmë. Në fakt, kërkesat e tërheqjes janë një gjë e zakonshme.
Nëse ka një gabim, a bëni rollback? E keni provuar ta bëni këtë?
Jo, ajo është një vendim i njeriut në momentin kur sheh problemin.
Burimi: habr.com
