Përfaqësimi i infrastrukturës si kod në një format teksti të përsëritshëm është një praktikë e thjeshtë më e mirë për sistemet që nuk kërkojnë ngacmim me minj. Kjo praktikë ka një emër - , dhe deri më tani ka dy mjete të njohura për ta zbatuar atë, veçanërisht në AWS: и .
Krahasimi i përvojës me Terraform dhe CloudFormation
Para se të vinte në (Aka ) Unë punova dhe përdori Terraform për tre vjet. Në vendin e ri, unë përdora gjithashtu Terraform me gjithë fuqinë time, dhe më pas kompania shtyu kalimin në gjithçka a la Amazon, përfshirë CloudFormation. Unë kam zhvilluar me zell praktikat më të mira për të dyja, dhe i kam përdorur të dyja mjetet në flukse pune shumë komplekse, në mbarë organizatën. Më vonë, pasi peshova me mend implikimet e migrimit nga Terraform në CloudFormation, u binda se Terraform ishte ndoshta zgjidhja më e mirë për organizatën.
Terraform i tmerrshëm
Softuer beta
Terraform nuk e ka lëshuar ende versionin 1.0, gjë që është një arsye e mirë për të mos e përdorur atë. Ka ndryshuar shumë që kur e kam provuar për herë të parë vetë, por atëherë terraform apply shpesh prishej pas disa përditësimeve ose thjesht pas disa vitesh përdorimi. Unë do të thosha se "çdo gjë është ndryshe tani", por... këtë duket se thonë të gjithë, apo jo? Ka ndryshime që janë të papajtueshme me versionet e mëparshme, megjithëse janë të përshtatshme, dhe madje duket sikur sintaksa dhe abstraksionet e dyqaneve të burimeve janë tani ato që na duhen. Instrumenti duket se është bërë vërtet më i mirë, por... :-0
Nga ana tjetër, AWS ka bërë një punë të mirë duke ruajtur përputhshmërinë e prapambetur. Kjo është ndoshta sepse shërbimet e tyre shpesh testohen tërësisht brenda organizatës dhe vetëm atëherë, riemërohen, publikohen. Pra, "ata u përpoqën shumë" është një nënvlerësim. Ruajtja e përputhshmërisë së prapambetur me API-të për një sistem kaq të larmishëm dhe kompleks sa AWS është tepër i vështirë. Kushdo që i është dashur të mbajë API publike që përdoren aq gjerësisht sa janë, duhet të kuptojë se sa e vështirë është ta bësh këtë për kaq shumë vite. Por sjellja e CloudFormation, në kujtesën time, nuk ka ndryshuar kurrë gjatë viteve.
Takoni këmbën... është plumb
Me sa di unë, fshini burimin i huaj Skema e CloudFormation nga grumbulli juaj CF nuk është i mundur. E njëjta gjë është e vërtetë me Terraform. Kjo ju lejon të importoni burimet ekzistuese në pirgun tuaj. Funksioni mund të thuhet se është i mahnitshëm, por me fuqi të madhe vjen përgjegjësi e madhe. Thjesht duhet të shtoni një burim në pirg, dhe ndërsa jeni duke punuar me pirgun tuaj, nuk mund ta fshini ose ndryshoni këtë burim. Një ditë rezultoi mbrapsht. Një ditë në Twitch, dikush importoi aksidentalisht grupin e sigurisë AWS të dikujt tjetër në pirgun e tyre Terraform, duke mos pasur asnjë të keqe. Hyra në disa komanda dhe... grupi i sigurisë (së bashku me trafikun në hyrje) u zhduk.
Terraform i madh
Rimëkëmbja nga gjendjet jo të plota
Ndonjëherë CloudFormation nuk arrin të kalojë plotësisht nga një gjendje në tjetrën. Në të njëjtën kohë, ai do të përpiqet të kthehet në atë të mëparshme. Është për të ardhur keq që kjo nuk është gjithmonë e realizueshme. Mund të jetë mjaft e frikshme të korrigjoni gabimet e asaj që ndodhi më vonë - kurrë nuk e dini nëse CloudFormation do të jetë i lumtur që po hakohet - edhe thjesht për ta rregulluar atë. Nëse do të jetë apo jo e mundur të kthehet në gjendjen e mëparshme, ai me të vërtetë nuk e di se si ta përcaktojë dhe, si parazgjedhje, varet për orë të tëra duke pritur për një mrekulli.
Terraform, nga ana tjetër, tenton të rikuperohet nga tranzicionet e dështuara shumë më bukur dhe ofron mjete të avancuara korrigjimi.
Ndryshime më të qarta në gjendjen e dokumentit
“Dakord, balancues i ngarkesës, ju po ndryshoni. Por si?"
- inxhinier i shqetësuar, gati për të shtypur butonin "pranoj".
Ndonjëherë më duhet të bëj disa manipulime me balancuesin e ngarkesës në pirgun e CloudFormation, të tilla si shtimi i një numri porti ose ndryshimi i një grupi sigurie. ClouFormation shfaq ndryshime të dobëta. Unë, në kunjat dhe gjilpërat, kontrolloj dy herë skedarin yaml dhjetë herë për t'u siguruar që nuk kam fshirë asgjë të nevojshme dhe nuk kam shtuar asgjë të panevojshme.
Terraform është shumë më transparent në këtë drejtim. Ndonjëherë ai është edhe shumë transparent (lexo: i bezdisshëm). Për fat të mirë, versioni i fundit përfshin shfaqjen e përmirësuar të ndryshimeve në mënyrë që tani të mund të shihni saktësisht se çfarë po ndryshon.
Lakueshmëri
Shkruani softuerin mbrapsht.
E thënë troç, karakteristika më e rëndësishme e softuerit jetëgjatë është aftësia për t'iu përshtatur ndryshimeve. Shkruani çdo softuer mbrapsht. Më shpesh kam bërë gabime duke marrë një shërbim "të thjeshtë" dhe më pas kam filluar të grumbulloj gjithçka në një pirg të vetëm CloudFormation ose Terraform. Dhe sigurisht, muaj më vonë u zbulua se e kisha kuptuar gjithçka gabim, dhe shërbimi në fakt nuk ishte i thjeshtë! Dhe tani më duhet të thyej disi një pirg të madh në komponentë të vegjël. Kur punoni me CloudFormation, kjo mund të bëhet vetëm duke rikrijuar fillimisht pirgun ekzistues, dhe unë nuk e bëj këtë me bazat e të dhënave të mia. Terraform, nga ana tjetër, bëri të mundur zbërthimin e pirgut dhe zbërthimin e tij në pjesë më të vogla më të kuptueshme.
Modulet në git
Ndarja e kodit Terraform nëpër pirgje të shumta është shumë më e lehtë sesa ndarja e kodit CloudFormation. Me Terraform, ju mund ta vendosni kodin tuaj në një depo git dhe ta përdorni atë duke përdorur kontrollin semantik të versionit. Kushdo që ka qasje në këtë depo mund të ripërdorë kodin e përbashkët. Ekuivalenti i CloudFormation është S3, por nuk ka të njëjtat përfitime dhe nuk ka asnjë arsye pse ne duhet ta braktisim fare git-in në favor të S3.
Organizata u rrit dhe aftësia për të ndarë grupe të përbashkëta arriti një nivel kritik. Terraform e bën këtë të lehtë dhe të natyrshme, ndërsa CloudFormation do t'ju bëjë të hidheni nëpër rrathë përpara se të arrini të funksiononi diçka të tillë.
Operacionet si kod
"Le ta shkruajmë atë dhe në rregull."
- një inxhinier 3 vjet përpara se të shpikte biçikletën Terraform.
Kur bëhet fjalë për zhvillimin e softuerit, Go ose një program Java nuk është thjesht kod.
Kodi si Kod
Ekziston edhe infrastruktura në të cilën punon.
Infrastruktura si Kod
Por nga është ajo? Si ta monitoroni atë? Ku jeton kodi juaj? A kanë nevojë zhvilluesit leje aksesi?
Operacionet si kod
Të jesh një zhvillues softuerësh nuk do të thotë vetëm të shkruash kod.
AWS nuk është i vetmi: ndoshta përdorni ofrues të tjerë. SignalFx, PagerDuty ose Github. Ndoshta keni një server të brendshëm Jenkins për CI/CD ose një panel të brendshëm të Grafana për monitorim. Infra as Code zgjidhet për arsye të ndryshme dhe secili është po aq i rëndësishëm për gjithçka që lidhet me softuerin.
Kur punoja në Twitch, ne përshpejtuam shërbimet brenda sistemeve të përziera të integruara dhe AWS të Amazon. Ne krijuam dhe mbështetëm shumë mikroshërbime, duke rritur kostot operative. Diskutimet shkuan kështu:
- Я: Dreqin, këto janë shumë gjeste për të mbingarkuar një mikroshërbim. Do të më duhet të përdor këto mbeturina për të krijuar një llogari AWS (ne shkuam në 2 llogari mikroservice), më pas ky për konfigurimin e sinjalizimeve, ky për një depo kodesh dhe ky për një listë emaili dhe më pas ky...
- Plumbi: Le ta skriptojmë dhe në rregull.
- Я: Mirë, por vetë skenari do të ndryshojë. Do të na duhet një mënyrë për të kontrolluar nëse të gjitha këto gizmo të integruara të Amazon janë të përditësuara.
- Plumbi: Tingëllon mirë. Dhe ne do të shkruajmë një skenar për këtë.
- Я: E shkëlqyeshme! Dhe skenari ndoshta do të ketë ende nevojë për të vendosur parametra. A do t'i pranojë?
- Plumbi: Le të marrë ku shkon!
- Я: Procesi mund të ndryshojë dhe përputhshmëria e prapambetur do të humbasë. Do të kërkohet një lloj kontrolli semantik i versionit.
- Plumbi: Ide e mirë!
- Я: Mjetet mund të ndryshohen manualisht, brenda ndërfaqes së përdoruesit. Do të na duhet një mënyrë për ta kontrolluar dhe rregulluar këtë.
…3 vjet më vonë:
- Plumbi: Dhe ne morëm terraform.
Morali i tregimit është: edhe nëse ju kokë e këmbë në çdo gjë Amazon, ju jeni ende duke përdorur diçka jo nga AWS dhe këto shërbime kanë një gjendje që përdor një gjuhë konfigurimi për ta mbajtur atë gjendje të sinkronizuar.
Modulet CloudFormation lambda vs git në terren
lambda është zgjidhja e CloudFormation për çështjen e logjikës së personalizuar. Me lambda mundeni ose . Kjo qasje paraqet kompleksitete shtesë që nuk janë të pranishme në versionin semantik të moduleve git nga Terraform. Për mua, problemi më urgjent ishte menaxhimi i lejeve për të gjitha këto lambda të përdoruesve (dhe këto janë dhjetëra llogari AWS). Një problem tjetër i rëndësishëm ishte problemi “çfarë erdhi e para, pula apo veza?”: lidhej me kodin lambda. Ky funksion në vetvete është infrastrukturë dhe kod, dhe ai vetë ka nevojë për monitorim dhe përditësime. Gozhda e fundit në arkivol ishte vështirësia në përditësimin semantik të ndryshimeve të kodit lambda; ne gjithashtu duhej të sigurohenim që veprimet e stackit pa një komandë të drejtpërdrejtë të mos ndryshonin ndërmjet ekzekutimeve.
Mbaj mend që një herë doja të krijoja një vendosje kanarine për mjedisin Elastic Beanstalk me një balancues klasik të ngarkesës. Gjëja më e lehtë për të bërë do të ishte të bësh një vendosje të dytë për EB pranë mjedisit të prodhimit, duke e çuar një hap më tej: duke kombinuar grupin e vendosjes së kanarinëve me shkallëzim automatik me vendosjen LB në mjedisin e prodhimit. Dhe meqenëse Terraform përdor , kjo do të kërkojë 4 rreshta shtesë kodi në Terraform. Kur pyeta nëse kishte një zgjidhje të krahasueshme në CloudFormation, ata më drejtuan një depo të tërë git me një tubacion vendosjeje dhe gjithçka, të gjitha për hir të diçkaje që mund të bënin 4 rreshta të dobët të kodit Terraform.
Ai e dallon më mirë lëvizjen
Sigurohuni që realiteti të përputhet me pritjet.
është një funksion shumë i fuqishëm si funksion kodi, sepse ndihmon në sigurimin që realiteti të përputhet me pritshmëritë. Është i disponueshëm si me CloudFormation ashtu edhe me Terraform. Por ndërsa grupi i prodhimit u rrit, kërkimi për drift në CloudFormation prodhoi gjithnjë e më shumë zbulime të rreme.
Me Terraform ju keni grepa shumë më të avancuara të ciklit jetësor për zbulimin e lëvizjes. Për shembull, ju futni komandën drejtpërdrejt në përkufizimin e detyrës ECS nëse dëshironi të injoroni ndryshimet në një përkufizim specifik të detyrës pa injoruar ndryshimet në të gjithë vendosjen tuaj ECS.
CDK dhe e ardhmja e CloudFormation
CloudFormation është i vështirë për t'u menaxhuar në shkallë të gjerë, ndër-infrastrukturore. Shumë nga këto vështirësi njihen dhe mjeti ka nevojë për gjëra të tilla si , një kornizë për përcaktimin e infrastrukturës cloud në kod dhe drejtimin e saj përmes AWS CloudFormation. Do të jetë interesante të shihet se çfarë do të sjellë e ardhmja për aws-cdk, por do ta ketë të vështirë të konkurrojë me pikat e tjera të forta të Terraform; për të përditësuar CloudFormation, do të kërkohen ndryshime globale.
Që Terraform të mos zhgënjejë
Kjo është "infrastruktura si kod" dhe jo "si tekst".
Përshtypja ime e parë për Terraform ishte mjaft e keqe. Unë mendoj se thjesht nuk e kuptova qasjen. Pothuajse të gjithë inxhinierët e perceptojnë në mënyrë të pavullnetshme atë si një format teksti që duhet të shndërrohet në infrastrukturën e dëshiruar. MOS BËJ NË KËTË MËNYRË.
Truizmat e zhvillimit të mirë të softuerit vlejnë edhe për Terraform.
Unë kam parë shumë praktika të miratuara për të krijuar kod të mirë duke u injoruar në Terraform. Ju keni studiuar për vite për t'u bërë një programues i mirë. Mos hiqni dorë nga kjo përvojë vetëm sepse jeni duke punuar me Terraform. Truizmat e zhvillimit të mirë të softuerit vlejnë për Terraform.
Si mund të mos dokumentohet kodi?
Unë kam parë pirgje të mëdha Terraform pa absolutisht asnjë dokumentacion. Si mund të shkruani kodin në faqe - pa absolutisht asnjë dokumentacion? Shtoni dokumentacion që shpjegon tuajin kod Terraform (theksi në fjalën "kod"), pse ky seksion është kaq i rëndësishëm dhe çfarë bëni.
Si mund të vendosim shërbime që dikur ishin një funksion i madh kryesor ()?
Unë kam parë rafte shumë komplekse Terraform të paraqitura si një modul i vetëm. Pse nuk e vendosim softuerin në këtë mënyrë? Pse i ndajmë funksionet e mëdha në më të vogla? Të njëjtat përgjigje vlejnë për Terraform. Nëse moduli juaj është shumë i madh, duhet ta ndani në module më të vogla.
A nuk i përdor kompania juaj biblioteka?
Unë kam parë se si inxhinierët, duke krijuar një projekt të ri duke përdorur Terraform, kopjuan në mënyrë budallaqe copa të mëdha nga projekte të tjera në të tyret, dhe më pas i ngatërruan ato derisa filloi të funksiononte. A do të punonit kështu me kodin "luftarak" në kompaninë tuaj? Ne nuk përdorim vetëm bibliotekat. Po, po ku jemi pa biblioteka të përbashkëta në parim?!
Nuk po përdorni PEP8 ose gofmt?
Shumica e gjuhëve kanë një skemë standarde, të pranuar të formatimit. Në Python ky është PEP8. Në Go - gofmt. Terraform ka të vetat: terraform fmt. Shijojeni për shëndetin tuaj!
A do të përdorni React pa e ditur JavaScript?
Modulet Terraform mund të thjeshtojnë një pjesë të infrastrukturës komplekse që krijoni, por kjo nuk do të thotë se nuk mund të ndërhyni fare me të. Dëshironi të përdorni Terraform saktë pa kuptuar burimet? Jeni të dënuar: koha do të kalojë dhe nuk do ta zotëroni kurrë Terraformin.
A po kodoni me injeksione të vetme ose varësie?
Injeksioni i varësisë është një praktikë më e mirë e njohur për zhvillimin e softuerit dhe preferohet mbi ato të vetme. Si është e dobishme kjo në Terraform? Unë kam parë module Terraform që varen nga gjendja e largët. Në vend që të shkruani module që rifitojnë gjendjen e largët, shkruani një modul që merr parametra. Dhe pastaj kaloni këto parametra në modul.
A bëjnë bibliotekat tuaja dhjetë gjëra mirë apo një gjë të shkëlqyer?
Bibliotekat që funksionojnë më mirë janë ato që fokusohen në një detyrë që e bëjnë shumë mirë. Në vend që të shkruani module të mëdha Terraform që përpiqen të bëjnë gjithçka menjëherë, ndërtoni pjesë të tyre që bëjnë një gjë mirë. Dhe më pas bashkojini sipas nevojës.
Si mund të bëni ndryshime në biblioteka pa përputhshmëri të prapambetur?
Një modul i zakonshëm Terraform, si një bibliotekë e rregullt, duhet t'u komunikojë disi ndryshimet përdoruesve pa qenë të përputhshëm me të kaluarën. Është e bezdisshme kur këto ndryshime ndodhin në biblioteka, dhe është po aq e bezdisshme kur bëhen ndryshime të papajtueshme me prapavijën në modulet Terraform. Rekomandohet përdorimi i etiketave git dhe semver kur përdorni modulet Terraform.
A funksionon shërbimi juaj i prodhimit në laptopin tuaj ose në një qendër të dhënash?
Hashicorp ka mjete si për të drejtuar terraformën tuaj. Këto shërbime të centralizuara e bëjnë të lehtë menaxhimin, auditimin dhe miratimin e ndryshimeve në terren.
Nuk shkruani teste?
Inxhinierët e kuptojnë se kodi duhet të testohet, por ata vetë shpesh harrojnë testimin kur punojnë me Terraform. Për infrastrukturën, kjo është e mbushur me momente të pabesë. Këshilla ime është të "testoni" ose "krijoni shembull" rafte duke përdorur module që mund të vendosen saktë për testim gjatë CI/CD.
Terraform dhe mikroshërbime
Jeta dhe vdekja e kompanive të mikroshërbimeve varet nga shpejtësia, inovacioni dhe ndërprerja e grupeve të reja të punës me mikroshërbime.
Aspekti negativ më i zakonshëm që lidhet me arkitekturat e mikroshërbimeve, dhe që nuk mund të eliminohet, lidhet me punën, jo me kodin. Nëse mendoni për Terraformin si thjesht një mënyrë për të automatizuar vetëm anën e infrastrukturës së arkitekturës së mikroshërbimeve, atëherë po humbisni përfitimet e vërteta të sistemit. Tani është tashmë .
Burimi: www.habr.com