Að tákna innviði sem kóða á endurteknu textasniði er einföld bestu venjur fyrir kerfi sem þurfa ekki að fikta við mýs. Þessi æfing hefur nafn - , og hingað til eru tvö vinsæl verkfæri til að útfæra það, sérstaklega í AWS: и .
Samanburður á reynslu við Terraform og CloudFormation
Áður en komið er til (Aka ) Ég vann og notaði Terraform í þrjú ár. Á nýja staðnum notaði ég líka Terraform af fullum krafti og síðan ýtti fyrirtækið á umskipti yfir í allt sem er a la Amazon, þar á meðal CloudFormation. Ég hef þróað af kostgæfni bestu starfsvenjur fyrir báðar og hef notað bæði verkfærin í mjög flóknum verkflæði um allt skipulag. Seinna, eftir að hafa ígrundað áhrif þess að flytja frá Terraform til CloudFormation, sannfærðist ég um að Terraform væri líklega besti kosturinn fyrir stofnunina.
Terraform Hræðilegt
Beta hugbúnaður
Terraform hefur ekki einu sinni gefið út útgáfu 1.0 ennþá, sem er góð ástæða til að nota hana ekki. Það hefur breyst mikið síðan ég prófaði það fyrst sjálfur, en þá terraform apply bilaði oft eftir nokkrar uppfærslur eða einfaldlega eftir nokkurra ára notkun. Ég myndi segja að "allt er öðruvísi núna," en ... það er það sem allir virðast segja, ekki satt? Það eru breytingar sem eru ósamrýmanlegar fyrri útgáfum, þó þær séu viðeigandi, og það líður jafnvel eins og setningafræði og útdráttur auðlindabúða sé núna það sem við þurfum. Hljóðfærið virðist í raun hafa orðið betra, en... :-0
Aftur á móti hefur AWS unnið gott starf við að viðhalda afturábakssamhæfi. Þetta er líklega vegna þess að þjónusta þeirra er oft ítarlega prófuð innan stofnunarinnar og aðeins þá, endurnefnd, er birt. Svo „þeir reyndu mikið“ er vanmetið. Það er ótrúlega erfitt að viðhalda afturábakssamhæfi við API fyrir eins fjölbreytt og flókið kerfi og AWS. Allir sem hafa þurft að viðhalda opinberum API sem eru notuð eins mikið og þau eru ættu að skilja hversu erfitt það er að gera það í svo mörg ár. En hegðun CloudFormation, í minni mínu, hefur aldrei breyst í gegnum árin.
Hittu fótinn... þetta er byssukúla
Eftir því sem ég best veit skaltu eyða auðlindinni utanaðkomandi CloudFormation stafla úr CF stafla þínum er ekki möguleg. Það sama á við um Terraform. Það gerir þér kleift að flytja núverandi auðlindir inn í stafla þinn. Segja má að aðgerðin sé mögnuð en miklum krafti fylgir mikil ábyrgð. Þú þarft bara að bæta tilföngum við staflan, og á meðan þú ert að vinna með stafla þinn geturðu ekki eytt eða breytt þessu tilfangi. Einn daginn kom það til baka. Einn daginn á Twitch flutti einhver óvart AWS öryggishóp einhvers annars inn í sinn eigin Terraform stafla án þess að vera með nein skaða. Ég setti inn nokkrar skipanir og... öryggishópurinn (ásamt umferð sem kom inn) hvarf.
Terraform Frábært
Bati frá ófullnægjandi ríkjum
Stundum tekst CloudFormation ekki að skipta algjörlega úr einu ástandi í annað. Á sama tíma mun hann reyna að snúa aftur til fyrri. Það er leitt að þetta er ekki alltaf framkvæmanlegt. Það getur verið frekar skelfilegt að kemba það sem gerðist seinna - þú veist aldrei hvort CloudFormation verði ánægð með að það sé verið að hakka það - jafnvel bara til að laga það. Hvort það verður hægt að fara aftur í fyrra ástand eða ekki, hann veit í raun ekki hvernig á að ákvarða og, sjálfgefið, hangir tímunum saman og bíður eftir kraftaverki.
Terraform, aftur á móti, hefur tilhneigingu til að jafna sig eftir misheppnaðar umskipti mun þokkafyllri og býður upp á háþróað kembiforrit.
Skýrari breytingar á ástandi skjala
„Allt í lagi, álagsjafnari, þú ert að breytast. En hvernig?"
— áhyggjufullur verkfræðingur, tilbúinn að ýta á „samþykkja“ hnappinn.
Stundum þarf ég að gera nokkrar aðgerðir með hleðslujafnara í CloudFormation stafla, svo sem að bæta við gáttarnúmeri eða breyta öryggishópi. ClouFormation sýnir breytingar illa. Ég, á prjónum og nálum, tékka á yaml skránni tíu sinnum til að ganga úr skugga um að ég hafi ekki eytt neinu sem þarf og ekki bætt við neinu óþarfa.
Terraform er mun gagnsærra hvað þetta varðar. Stundum er hann jafnvel of gegnsær (lesist: leiðinlegur). Sem betur fer inniheldur nýjasta útgáfan betri birtingu á breytingum þannig að þú getur nú séð nákvæmlega hvað er að breytast.
Sveigjanleiki
Skrifaðu hugbúnað aftur á bak.
Það er skemmst frá því að segja að mikilvægasti eiginleiki langlífs hugbúnaðar er hæfileikinn til að laga sig að breytingum. Skrifaðu hvaða hugbúnað sem er aftur á bak. Oftast gerði ég mistök með því að taka „einfalda“ þjónustu og byrja síðan að troða öllu í einn CloudFormation eða Terraform stafla. Og auðvitað, mánuðum seinna, kom í ljós að ég hafði skilið allt vitlaust og þjónustan var reyndar ekki einföld! Og nú þarf ég einhvern veginn að brjóta stóran stafla í litla hluti. Þegar þú vinnur með CloudFormation er þetta aðeins hægt að gera með því að endurskapa núverandi stafla fyrst og ég geri þetta ekki með gagnagrunnana mína. Terraform gerði hins vegar kleift að kryfja staflann og brjóta hann niður í skiljanlegri smærri hluta.
Einingar í git
Að deila Terraform kóða yfir marga stafla er miklu auðveldara en að deila CloudFormation kóða. Með Terraform geturðu sett kóðann þinn í git geymslu og fengið aðgang að honum með merkingarfræðilegri útgáfustýringu. Allir sem hafa aðgang að þessari geymslu geta endurnýtt sameiginlega kóðann. Ígildi CloudFormation er S3, en það hefur ekki sömu kosti og það er engin ástæða fyrir því að við ættum að yfirgefa git í þágu S3.
Samtökin stækkuðu og hæfileikinn til að deila sameiginlegum stafla náði mikilvægu stigi. Terraform gerir þetta allt auðvelt og eðlilegt, en CloudFormation mun láta þig hoppa í gegnum hringi áður en þú getur fengið eitthvað eins og þetta að virka.
Aðgerðir sem kóða
"Við skulum skrifa það og allt í lagi."
— verkfræðingur 3 árum áður en hann fann upp Terraform hjólið.
Þegar kemur að hugbúnaðarþróun er Go eða Java forrit ekki bara kóði.
Kóði sem kóða
Það eru líka innviðirnir sem það vinnur á.
Innviðir sem kóða
En hvaðan er hún? Hvernig á að fylgjast með því? Hvar býr kóðinn þinn? Þurfa verktaki aðgangsheimild?
Aðgerðir sem kóða
Að vera hugbúnaðarframleiðandi þýðir ekki bara að skrifa kóða.
AWS er ekki sá eini: þú notar líklega aðra þjónustuaðila. SignalFx, PagerDuty eða Github. Kannski ertu með innri Jenkins netþjón fyrir CI/CD eða innra Grafana mælaborð til að fylgjast með. Infra as Code er valinn af mismunandi ástæðum og hver og einn er jafn mikilvægur fyrir allt sem tengist hugbúnaði.
Þegar ég vann hjá Twitch hröðuðum við þjónustu inni í blönduðu innbyggðu og AWS kerfum Amazon. Við studdum og studdum margar örþjónustur, sem jók rekstrarkostnað. Umræðurnar fóru einhvern veginn svona:
- Я: Fjandinn, þetta er mikið af bendingum til að yfirklukka eina örþjónustu. Ég verð að nota þetta sorp til að búa til AWS reikning (við fórum á 2 reikninga á örþjónustu), svo þessi til að setja upp viðvaranir, þessi fyrir kóðageymslu, og þessi fyrir tölvupóstlista, og svo þessi...
- Blý: Við skulum skrifa það og allt í lagi.
- Я: Allt í lagi, en handritið sjálft mun breytast. Við þurfum leið til að athuga hvort allir þessir innbyggðu Amazon gizmos séu uppfærðir.
- Blý: Hljómar vel. Og við munum skrifa handrit að þessu.
- Я: Frábært! Og handritið mun líklega enn þurfa að stilla breytur. Mun hann samþykkja þau?
- Blý: Leyfðu honum að fara þangað sem hann fer!
- Я: Ferlið gæti breyst og afturábak eindrægni glatast. Einhvers konar merkingarfræðilega útgáfustýringu verður krafist.
- Blý: Frábær hugmynd!
- Я: Verkfæri er hægt að breyta handvirkt, inni í notendaviðmótinu. Við þurfum leið til að athuga og laga þetta.
…3 árum síðar:
- Blý: Og við fengum terraform.
Siðferði sögunnar er: jafnvel þótt þú yfir höfuð í öllu Amazon, þú ert enn að nota eitthvað sem er ekki frá AWS og þessar þjónustur hafa ástand sem notar stillingartungumál til að halda því ástandi í samstillingu.
CloudFormation lambda vs git einingar terraform
lambda er lausn CloudFormation á sérsniðnu rökfræðimálinu. Með lambda geturðu eða . Þessi nálgun kynnir fleiri margbreytileika sem eru ekki til staðar í merkingarfræðilegri útgáfu Terraform á git einingum. Fyrir mig var brýnasta vandamálið að stjórna heimildum fyrir allar þessar notendalambda (og þetta eru heilmikið af AWS reikningum). Annað mikilvægt vandamál var „hvað kom á undan, hænan eða eggið?“ vandamálið: það var tengt lambdakóða. Þessi aðgerð sjálf er innviði og kóði, og hún þarf sjálf að fylgjast með og uppfæra. Síðasti naglinn í kistuna var erfiðleikinn við að uppfæra merkingarlega breytingar á lambda kóða; við þurftum líka að ganga úr skugga um að staflaaðgerðirnar án beinrar skipunar breyttust ekki á milli keyra.
Ég man að einu sinni langaði mig að búa til kanarídreifingu fyrir Elastic Beanstalk umhverfið með klassískum hleðslujafnara. Auðveldast væri að gera aðra dreifingu fyrir EB við hliðina á framleiðsluumhverfinu, taka það skrefinu lengra: sameina sjálfvirka mælikvarða kanarídreifingarhópsins með dreifingunni LB inn í framleiðsluumhverfið. Og þar sem Terraform notar , þetta mun krefjast 4 auka línur af kóða í Terraform. Þegar ég spurði hvort það væri til sambærileg lausn í CloudFormation, bentu þeir mér á heila git geymslu með dreifingarpípu og öllu, allt í þágu eitthvað sem lélegar 4 línur af Terraform kóða gætu gert.
Það greinir rek betur
Gakktu úr skugga um að raunveruleikinn standist væntingar.
er mjög öflugur aðgerð sem kóða eiginleiki vegna þess að hann hjálpar til við að tryggja að raunveruleikinn standist væntingar. Það er fáanlegt með bæði CloudFormation og Terraform. En eftir því sem framleiðslustaflan stækkaði, leiddi leit að reki í CloudFormation til fleiri og fleiri rangra uppgötvunar.
Með Terraform ertu með miklu fullkomnari líftíma króka til að greina rek. Til dæmis, þú slærð inn skipunina beint í ECS verkefnaskilgreiningunni ef þú vilt hunsa breytingar á tiltekinni verkskilgreiningu án þess að hunsa breytingar á allri ECS uppsetningunni þinni.
CDK og framtíð CloudFormation
CloudFormation er erfitt að stjórna á stórum mælikvarða þvert á innviði. Margir af þessum erfiðleikum eru viðurkenndir og tólið þarf hluti eins og , ramma til að skilgreina skýjainnviði í kóða og keyra hann í gegnum AWS CloudFormation. Það verður áhugavert að sjá hvað framtíðin ber í skauti sér fyrir aws-cdk, en það mun eiga erfitt með að keppa við aðra styrkleika Terraform; til að uppfæra CloudFormation verða alþjóðlegar breytingar nauðsynlegar.
Svo að Terraform veldur ekki vonbrigðum
Þetta er „innviði sem kóða“ en ekki „sem texti“.
Fyrsta sýn mín á Terraform var frekar slæm. Ég held að ég hafi bara ekki skilið nálgunina. Næstum allir verkfræðingar skynja það ósjálfrátt sem textasnið sem þarf að breyta í viðkomandi innviði. EKKI GERA ÞAÐ SVONA.
Sannleikur góðrar hugbúnaðarþróunar á einnig við um Terraform.
Ég hef séð margar aðferðir sem notaðar eru til að búa til góðan kóða sem eru hunsaðar í Terraform. Þú hefur lært í mörg ár til að verða góður forritari. Ekki gefast upp á þessari reynslu bara vegna þess að þú ert að vinna með Terraform. Sannleikur góðrar hugbúnaðarþróunar á við um Terraform.
Hvernig er ekki hægt að skjalfesta kóðann?
Ég hef séð risastóra Terraform stafla með nákvæmlega engum skjölum. Hvernig er hægt að skrifa kóða á síður - með nákvæmlega engum skjölum? Bættu við skjölum sem útskýra þitt kóða Terraform (áhersla á orðið "kóði"), hvers vegna þessi hluti er svo mikilvægur og hvað þú gerir.
Hvernig getum við dreift þjónustu sem einu sinni var ein stór aðal() aðgerð?
Ég hef séð mjög flókna Terraform stafla kynnta sem eina einingu. Af hverju sendum við ekki hugbúnað á þennan hátt? Af hverju skiptum við stórum aðgerðum í smærri? Sömu svör eiga við um Terraform. Ef einingin þín er of stór þarftu að skipta henni niður í smærri einingar.
Notar fyrirtækið þitt ekki bókasöfn?
Ég hef séð hvernig verkfræðingar, sem spunnu upp nýtt verkefni með Terraform, kóperuðu stóra bita úr öðrum verkefnum heimskulega inn í sín eigin og föndruðu síðan með þá þar til það byrjaði að virka. Myndir þú vinna svona með „bardaga“ kóða í fyrirtækinu þínu? Við notum ekki bara bókasöfn. Já, en hvar erum við án sameiginlegra bókasöfna í grundvallaratriðum?!
Ertu ekki að nota PEP8 eða gofmt?
Flest tungumál eru með staðlað, viðurkennt sniðkerfi. Í Python er þetta PEP8. Í Go - gofmt. Terraform hefur sitt eigið: terraform fmt. Njóttu þess fyrir heilsuna þína!
Munt þú nota React án þess að kunna JavaScript?
Terraform einingar geta einfaldað hluta af flóknum innviðum sem þú býrð til, en þetta þýðir ekki að þú getir alls ekki fiktað við það. Viltu nota Terraform rétt án þess að skilja auðlindir? Þú ert dæmdur: tíminn mun líða og þú munt aldrei ná tökum á Terraform.
Ertu að kóða með einhleypingum eða fíkniefnasprautu?
Dependency injection er viðurkennd besta starfsvenjan fyrir hugbúnaðarþróun og er valin fram yfir einhleypa. Hvernig er þetta gagnlegt í Terraform? Ég hef séð Terraform einingar sem eru háðar ytra ástandi. Í stað þess að skrifa einingar sem sækja fjarlægt ástand skaltu skrifa einingar sem tekur færibreytur. Og sendu síðan þessar breytur til einingarinnar.
Gera bókasöfnin þín tíu hluti vel eða eitt frábært?
Bókasöfn sem virka best eru þau sem einbeita sér að einu verkefni sem þau vinna mjög vel. Í stað þess að skrifa stórar Terraform einingar sem reyna að gera allt í einu skaltu byggja hluta þeirra sem gera eitt vel. Og sameina þá eftir þörfum.
Hvernig gerir þú breytingar á bókasöfnum án afturábaks eindrægni?
Algeng Terraform eining, eins og venjulegt bókasafn, þarf einhvern veginn að miðla breytingum til notenda án þess að vera afturábak samhæft. Það er pirrandi þegar þessar breytingar gerast á bókasöfnum og það er alveg jafn pirrandi þegar breytingar sem ekki eru afturábak samhæfðar eru gerðar í Terraform einingum. Mælt er með því að nota git tags og semver þegar Terraform einingar eru notaðar.
Er framleiðsluþjónustan þín í gangi á fartölvunni þinni eða í gagnaveri?
Hashicorp hefur verkfæri eins og að keyra terraformið þitt. Þessar miðlægu þjónustur gera það auðvelt að stjórna, endurskoða og samþykkja terraform breytingar.
Skrifarðu ekki próf?
Verkfræðingar gera sér grein fyrir því að það þarf að prófa kóðann, en sjálfir gleyma þeir oft prófunum þegar þeir vinna með Terraform. Fyrir innviði, þetta er fullt af svikulum augnablikum. Ráð mitt er að „prófa“ eða „búa til dæmi“ stafla með því að nota einingar sem hægt er að nota rétt til að prófa meðan á CI/CD stendur.
Terraform og örþjónustur
Líf og dauði örþjónustufyrirtækja er háð hraða, nýsköpun og truflun á nýjum örþjónustuverkstæðum.
Algengasta neikvæða þátturinn sem tengist örþjónustuarkitektúr, og sem ekki er hægt að útrýma, tengist verkinu, ekki kóðanum. Ef þú hugsar um Terraform sem bara leið til að gera sjálfvirkan aðeins innviðahlið smáþjónustuarkitektúrs, þá ertu að missa af hinum raunverulega ávinningi kerfisins. Nú er það nú þegar .
Heimild: www.habr.com