Paraqitja e infrastrukturës si kod në një format tekstual të ripërsëritshëm është një praktikë e thjeshtë më e mirë për sistemet, me të cilën nuk është nevoja të lodhesh. Kjo praktikë ka marrë emrin — , dhe deri më tani për realizimin e saj, veçanërisht në AWS, ka dy mjete të njohura: dhe .
Po e krahasoni përvojën time me Terraform dhe CloudFormation
Para se të vija në (në të njëjtën kohë ) kam punuar dhe për tre vjet kam përdorur Terraform. Në vendin e ri unë gjithashtu e kam përdorur Terraform, pastaj kompania e kaloi në një formë të gjitha për AWS, duke përfshirë CloudFormation. Unë kam punuar me përkushtim për të zhvilluar praktikat më të mira për të dy, dhe të dy mjetet i kam përdorur në procese të punës tepër të komplikuara në shkallë organizative. Më vonë, pas një vlerësimi të kujdesshëm të pasojave të kalimit nga Terraform në CloudFormation, kam konstatruar se Terraform, ndoshta, është zgjedhja më e mirë për organizatën.
Terraform Është i tmerrshëm
Versioni Beta i Software-it
Terraform ende nuk ka lëshuar versionin 1.0, dhe kjo është një arsye e fortë për të mos e përdorur. Që nga koha kur e kam provuar për herë të parë, ka ndryshuar shumë, por atëherë terraform apply shpesh prisheshin pas disa përditësimesh ose thjesht pas dy vjetëve të përdorimit. Do të thosha se "tani gjithçka është ndryshuar", por... kështu flasin të gjithë, apo jo? Ekzistojnë ndryshime që nuk janë të pajtueshme me versionet e mëparshme, megjithatë ato janë të justifikuara, dhe madje ka një ndjenjë se sintaksa dhe abstraksionet e depozitave të burimeve tani janë aty ku duhet. Mjeti duket si të ketë vërtet përmirësuar, por... :-0
Nga ana tjetër, AWS ka bërë një punë të mirë për të ruajtur pajtueshmërinë me versionet e mëparshme. Të gjithë ndoshta, sepse shërbimet e tyre zakonisht testohen mirë brenda organizatës dhe vetëm pastaj, pasi i ribemë, publikohen. Prandaj "bënë një punë të mirë" është ndoshta e thënë pak. Ruajtja e pajtueshmërisë me versionet e mëparshme të API-ve për një sistem kaq të shumëanshëm dhe të komplikuar si AWS, është jashtëzakonisht e vështirë. Çdo kush që ka pasur përvojë në mbajtjen e API-ve publikë, të përdorura gjithashtu gjerësisht, duhet të kuptojë sa e vështirë është kjo për shumë vite. Por, deri tani, sjellja e CloudFormation nuk ka ndryshuar asnjëherë për vite me radhë.
Këshillo, këmbë... kjo është një plumb
Sa di unë, të fshish një burim të jashtëm Nuk është e mundur të eksportoni një grup CloudFormation nga steka juaj CF. Rreth kësaj situate janë gjërat me Terraform. Ai lejon importimin e burimeve ekzistuese në stekë. Funksioni është, mund të thuhet, mbresëlënës, por me forcë të madhe vjen edhe një përgjegjësi e madhe. Sa herë që e futni një burim në stek, ndërkohë që punoni me stekun tuaj, nuk mund ta fshini ose ta ndryshoni atë burim. Një herë, kjo ndodhi. Ndodhi që në faqen e Twitch dikush, pa ndonjë qëllim të keq, përfundoi duke importuar grupin e sigurisë së dikujt në stekun e tij Terraform. Fut disa komanda dhe... grupi i sigurisë (në bashkëpunim me trafikun e hyrës) u zhduk.
Terraform i Madh
Ribashkimi nga gjendjet e paplota
Ndonjëherë CloudFormation nuk mund të kalojë plotësisht nga një gjendje në një tjetër. Në këtë rast, ai do të përpiqet të rikthehet në gjendjen e mëparshme. E trishtueshme, kjo nuk është gjithmonë e mundur. Të riparosh atë që rezulton, ndonjëherë është frikësuese - nuk dihet se si do ta pranojë CloudFormation që e ndjekin - ndonëse për të përmirësuar. Nëse do të jetë e mundur të ktheheni në gjendjen e mëparshme, ai nuk di ta përcaktojë mirë dhe për default mund të presë për orë të tëra për një mrekulli.
Terraform, përkundrazi, është më i aftë të rikuperohet pas kalimeve të dështuara dhe ofron një grup të përmirësuar mjetesh debugimi.
Ndryshime më të qarta në gjendjet e dokumentit
"Mirë, balancuesi i ngarkesës, po ndryshon. Por si?"
- inxhinier i shqetësuar, i gatshëm të shtypë butonin "prano".
Ndonjëherë kam nevojë të bëj disa manipulime me balancuesin e ngarkesës në stekun CloudFormation - për shembull, të shtoj numrin e portit ose të ndryshoj grupin e sigurisë. ClouFormation ndryshimet i tregon dobët. Ndërsa unë, si në thikë, po e kontrolloj skedarin yaml nga dhjetë herë për të siguruar që asgjë e nevojshme nuk e kam fshirë, e as që kam shtuar diçka të tepërt.
Terraform në këtë drejtim është shumë më transparent. Ndonjëherë është madje shumë transparent (lexo: i bezdisshëm). Për fat të mirë, në versionin më të fundit u përfshi një përmirësim i paraqitjes së ndryshimeve - tani shihet saktësisht se çfarë po ndryshon.
Fleksibiliteti
Shkruani softuer nga e kundërta.
Të themi drejtpërdrejt, karakteristika më e rëndësishme e një software-i që zgjat është aftësia për t'u adapatuar me ndryshimet. Çdo software shkruaje nga fundi. Më së shpeshti kam dështuar në atë që merrja një shërbim "të thjeshtë", dhe pastaj filloja ta ngjeshja atë në një grumbull CloudFormation ose Terraform. Dhe natyrisht, disa muaj më vonë shfaqej se e kisha kuptuar gjithçka gabim, dhe shërbimi nuk ishte aspak i thjeshtë! Dhe më duhej që në një mënyrë të ndaja grumbullin e madh në pjesë më të vogla. Kur punon me CloudFormation, e gjithë kjo është e mundur vetëm duke rikrijuar grumbullin ekzistues, dhe unë, me bazat e mia të të dhënave, nuk e bëj këtë. Terraform më lejon të ndajem grumbullin dhe ta ndaj atë në pjesë më të vogla dhe më të kuptueshme.
Modulet në git
Të ndash kodin e Terraform-it midis grumbujve të shumtë është ndjeshëm më e lehtë se sa me kodin e CloudFormation. Me Terraform mund të vendosësh kodin në një depo git dhe të aksesosh atë duke përdorur kontrollin semantik të versioneve. Çdo kush që ka akses në këtë depo mund ta ripërdorë kodin e zakonshëm. Ekuivalenti në CloudFormation është S3, por nuk ka të njëjtin avantazh dhe nuk ka asnjë arsye për të cilën duhet të heqim dorë nga git në favor të S3.
Organizata po rritej dhe aftësia për të ndarë grumbujt e përbashkët arriti një nivel kritik. Me Terraform, gjithçka është e lehtë dhe natyrale, ndërsa CloudFormation do t'ju nxiste të luanit me disa rrethana përpara se të arrini në një rezultat të ngjashëm.
Operacione si kod
"Ta shkruajmë dhe mjaft".
— inxhinier tre vjet përpara se të shpikë biçikletën Terraform.
Kur është fjala për zhvillimin e softuerit, Go ose një program në Java nuk janë thjesht kod.
Kode si Kod
Megjithatë, ekziston edhe infrastrukturen në të cilën funksionon ajo.
Infrastruktura si Kod
Por nga e di ajo atje? Si ta monitorosh? Ku qëndron kodi yt? A kanë nevojë zhvilluesit për leje për akses?
Operacione si Kod
Të jesh zhvillues i softuerit nuk është thjesht një punë kodimi.
Nuk është vetëm AWS: sigurisht që ju po përdorni shërbimet e ofruesve të tjerë. SignalFx, PagerDuty ose Github. Ndoshta keni një server të brendshëm Jenkins për CI/CD ose një panel të brendshëm kontrolli Grafana për monitorim. Infra si Kod zgjidhet për arsye të ndryshme, dhe çdo arsye është po aq e rëndësishme për çdo gjë që lidhet me softuerin.
Kur kam punuar në Twitch, ne shpejtuam shërbimet brenda sistemeve të përziera dhe sistemeve AWS të Amazon. Ne krijuam dhe mbështetëm një numër të madh mikroshërbimesh, duke rritur kostot operative. Diskutimet zhvilloheshin në këtë mënyrë:
- Unë: O, ka shumë lëvizje për të ngritur një mikroshërbim. Do të duhet të përdor këtë gjë për të krijuar një llogari AWS (ne po shkonim drejt 2 llogarive në mikroshërbim), pastaj këtë — për të konfiguruar njoftimet, pastaj këtë — për depozitën e kodit, dhe këtë — për listën e adresave të emailit, dhe pastaj këtë...
- Shefi: Do shkruajmë një skript dhe mbaroi.
- Unë: Ok, por vetë skripti do të ndryshojë. Do të na duhet një mënyrë për të verifikuar që të gjitha ato gjërat e përfshira nga amazon janë në një gjendje të përditësuar.
- Shefi: Dëgjohet mirë. Do ta shkruajmë këtë skript.
- Unë: Shkëlqyer! Në skript ndoshta do t'i duhet të caktojë parametra. A do t'i pranojë ata?
- Shefi: Po, do t'i pranojë, ku të shkojë tjetër!
- Unë: Procesi mund të ndryshojë, dhe mund të humbasë kompaktibilitetin prapa. Do të na duhen ndonjë lloj kontrolli semantik të versioneve.
- Shefi: Ide e shkëlqyer!
- Unë: Mjetet mund të ndryshohen manualisht, brenda ndërfaqes së përdoruesit. Do të na duhet një mënyrë për ta verifikuar dhe korrigjuar këtë.
…3 vjet më vonë:
- Shefi: Dhe na doli terraform.
Moraliteti i kësaj tregon se edhe nëse je i zhytur deri në thellësi në çdo gjë amazon, do të përdorësh gjithmonë diçka që nuk është nga AWS, dhe këta shërbime kanë një gjendje që përdor një gjuhë për konfigurim për të sinkronizuar këtë gjendje.
CloudFormation lambda përballë moduleve git të terraform
lambda është zgjidhja e CloudFormation për çështjen e logjikës së përdoruesit. Me anë të lambda-s mund të ose . Ky qasje sjell vështirësi shtesë, të cilat nuk ekzistojnë në kontrollin semantik të versioneve të moduleve git në Terraform. Problemi më urgjent për mua u bë menaxhimi i lejeve për të gjitha këto lambda të përdoruesve (dhe kjo përfshin dhjetëra llogari AWS). Një tjetër problem i rëndësishëm ishte çështja e "çfarë erdhi më parë — pula apo veza?": kjo ishte e lidhur me kodin e lambda. Kjo funskion — infrastruktura dhe kodi, dhe ajo gjithashtu ka nevojë për monitorim dhe përditësime. Çështja e fundit që na solli probleme ishte vështirësia në përditësimin semantik të ndryshimeve në kodin e lambda; gjithashtu duhej të bëhej që veprimet e grumbullit të mos ndryshonin midis ekzekutimeve pa një komandë direkte.
E kujtoj se një herë më erdhi në mendje dëshira për të krijuar një deploy kanarinë për mjedisin Elastic Beanstalk me një balancues klasike të ngarkesës. Më lehtë do të ishte të bëja një deploy të dytë për EB pranë mjedisit prodhues, duke bërë një hap tjetër: duke bashkuar automatikisht grupin e shkallëzueshëm të deploy-it kanarinë me LB-në e deploy-it në mjedisin prodhues. Dhe pasi Terraform përdor , do të kërkojë 4 rreshta shtesë kodi në Terraform. Kur u interesova nëse kishte një zgjidhje të krahasueshme në CloudFormation, më treguan për një tërë depo në git me një tub të deploy-it dhe gjëra të tjera: dhe e gjitha kjo — për të arritur ato 4 rreshta të mjerë të kodit Terraform.
Ai e zbulo më mirë driftin
Sigurohuni që realiteti të përputhet me pritjet.
— është një funksion shumë i fuqishëm i operacioneve si kod, sepse ndihmon të sigurohemi që realiteti përputhet me pritjet. Ai është i disponueshëm si me CloudFormation ashtu edhe me Terraform. Por, me rritjen e grumbullit të punës, kërkimi i driftit në CloudFormation jepte gjithnjë e më shumë gjetje të gabuara.
Me Terraform keni hak të shkallëzueshëm shumë më të avancuar për zbulimin e driftit. Për shembull, vendosni komandën drejt në përkufizimin e detyrës ECS, nëse dëshironi të injoroni ndryshimet në përkufizimin e një detyre të veçantë, pa e injoruar ndryshimin në të gjithë deploy-in ECS.
CDK dhe e ardhmja e CloudFormation
CloudFormation është e vështirë të menaxhohet në shkallë të mëdha, ndërmjet infrastrukturave. Shumë nga këto vështirësi janë pranuar, dhe mjeti ka nevojë për gjëra si , një strukturë për të përcaktuar infrastrukturën cloud në kod dhe për ta kaluar atë përmes AWS CloudFormation. Do të ishte interesante të shikoja se çfarë e pret aws-cdk në të ardhmen, por do t'i jetë e vështirë të konkurojë me avantazhet e tjera të Terraform-it; për të bërë CloudFormation në lartësi, do të kërkohen ndryshime globale.
Për të mos zhgënjyer Terraform-in
Kjo është «infrastruktura si KOD», jo «si tekst».
Impresioni im i parë për Terraform-in ishte mjaft negativ. Mendoj se thjesht nuk e kuptova qasjen. Pothuajse të gjithë inxhinierët fillestar e percepitojnë atë si një format tekstual, të cilin duhet ta kthejnë në infrastrukturën e dëshiruar. NUK DUHET TË BËHET KESHTU.
Parimet e mira të zhvillimit të softuerit vlejnë edhe për Terraform
Kam kam janë praktikat e shumta që janë pranuar për krijimin e kodit të mirë, dhe ato injorohen në Terraform. Ju keni studiuar për vite me radhë për të qenë një programues i mirë. Mos e braktisni atë përvojë vetëm sepse po punoni me Terraform. Të vërtetat e mira të zhvillimit të softuerit vlejnë po ashtu për Terraform.
Si mund të kodosh dhe të mos dokumentosh?
Këmba e mëdha e Terraformit ka ardhur në formën e plotë pa asnjë dokumentacion. Si mund të shkruash kod me faqe të tëra — krejt pa asnjë dokumentacion? Shtoni dokumentacionin që shpjegon që kod Terraform (theksi këtu është në fjalën "kod"), pse ky seksion është aq i rëndësishëm, dhe çfarë po bëni.
Si mund të implementoni shërbime që dikur ishin një funksion i vetëm, main()?
Kam hasur steke shumë të ndërlikuara Terraform, të paraqitura si një modul i vetëm. Pse nuk e zhvillojmë softuerin kështu? Pse i ndajmë funksionet e mëdha në më të vogla? Të njëjtat përgjigje vlejnë dhe për Terraform. Nëse moduli është shumë i madh — duhet ta ndani në modulet më të vogla.
A nuk përdor kompania juaj biblioteka?
Kam parë inxhinierë, ndërsa zhvillonin një projekt të ri me Terraform, thjesht që kopjojnë dhe ngjisin copa të mëdha nga projekte të tjera në të tyret, dhe pastaj i rregullojnë deri sa të fillojnë të funksionojnë. A do të punonit kështu me kodin "live" në kompaninë tuaj? Ne nuk përdorim biblioteka pa arsye. Po, por ku do të ishim pa biblioteka të përbashkëta në parim?!
A nuk përdorni PEP8 ose gofmt?
Në shumicën e gjuhëve, ekziston një skemë standarde e pranuar e formatimit. Në Python është PEP8. Në Go — gofmt. Terraform ka të vetin: terraform fmt. Përdorni me shëndet!
A do të filloni të përdorni React pa e ditur JavaScript-in?
Modulet e Terraform mund të thjeshtojnë një pjesë të infrastrukturës së ndërlikuar që po krijoni, por kjo nuk do të thotë që mund të mos e kuptoni fare. A doni të përdorni Terraform saktësisht pa kuptuar burimet? Jeni dënuar: koha do të kalojë dhe ju nuk do ta mësoni kurrë Terraform.
A po krijoni singleton-e, apo po implementoni varësi?
Implementimi i varësive është një praktikë e njohur si më e mira për zhvillimin e softuerit, e preferuar nga singletonët. Si do ta ndihmojë kjo në Terraform? Kam hasur në module Terraform që varen nga gjendja e largët. Në vend që të shkruani module që nxjerrin nga gjendja e largët, shkruani një modul që pranon parametra. Pastaj kaloni këta parametra në modul.
Bibliotekat tuaja bëjnë dhjetë gjëra mirë apo një — shkëlqyeshëm?
Bibliotekat punojnë më së miri kur përqendrohen në një detyrë, të cilën e kryejnë me shkëlqim. Në vend që të krijoni module të mëdha Terraform që përpiqen të bëjnë gjithçka menjëherë, ndërroni ato në pjesë që bëjnë mirë diçka të vetme. Pastaj kombinojini ashtu siç duhet.
Si bëni ndryshime në bibliotekat pa përputhshmëri prapa?
Një modul i përgjithshëm Terraform, siç është një bibliotekë e zakonshme, duhet të informojë ndonjëherë përdoruesit për ndryshimet pa përputhshmëri prapa. Kur ndodhin ndryshime të tilla në biblioteka, kjo është e bezdisshme, ashtu siç është bezdisëse kur ndodhin ndryshime pa përputhshmëri prapa në modulet Terraform. Rekomandohet që të aplikoni git tags dhe semver kur përdorni modulet Terraform.
Shërbimi prodhues është i ndezur në laptopin tuaj apo në qendër të të dhënave?
Hashicorp ka mjete të tilla si për të drejtuar terraform tuaj. Këto shërbime të centralizuara lehtësojnë menaxhimin, audituar dhe miratimin e ndryshimeve të terraform.
A nuk shkruani teste?
Inxhinierët pranojnë se kodi duhet të testohet, por shpesh neglizhojnë verifikimet kur punojnë me Terraform. Kjo është e rrezikshme për infrastrukturën. Unë rekomandoj "testimin" ose "krijimin e shembujve" të stack-ëve duke përdorur modula, të cilat mund të deploy-ohen saktë për t'u verifikuar gjatë CI/CD.
Terraform dhe mikroshërbimet
Jeta dhe vdekja e kompanive të mikroshërbimeve varet nga shpejtësia, rinovimi dhe shkatërrimi i stack-ëve të rinj të mikroshërbimeve.
Momenti më i zakonshëm negativ që lidhet me arkitekturat e mikroshërbimeve dhe nga i cili nuk mund të shpëtohet, lidhet me punën, jo me kodin. Nëse e perceptoni Terraform-in vetëm si një mënyrë për të automatizuar anën infrastrukturore të arkitekturës së mikroshërbimeve, atëherë po e privoni veten nga avantazhet e vërteta të këtij sistemi. Tani është .
Burimi: habr.com
