Oerskeakele fan Terraform nei CloudFormation - en spyt derfan

It fertsjinwurdigjen fan ynfrastruktuer as koade yn in werhelle tekstformaat is in ienfâldige bêste praktyk foar systemen dy't net hoege te fretten mei mûzen. Dizze praktyk hat in namme - Ynfrastruktuer as koade, en oant no binne d'r twa populêre ark om it te ymplementearjen, benammen yn AWS: Terraform и CloudFormaasje.

Oerskeakele fan Terraform nei CloudFormation - en spyt derfan
Fergelykje ûnderfining mei Terraform en CloudFormation

Foardat komme ta twitch (hy Amazon Jr.) Ik wurke yn ien opstart en brûkt Terraform foar trije jier. Op it nije plak brûkte ik ek Terraform mei alle macht, en doe brocht it bedriuw de oergong nei alles a la Amazon, ynklusyf CloudFormation. Ik haw iverich bêste praktiken ûntwikkele foar beide, en haw beide ark brûkt yn heul komplekse, organisaasjebrede workflows. Letter, nei't ik de gefolgen fan it migrearjen fan Terraform nei CloudFormation yntinsyf weagje, waard ik derfan oertsjûge dat Terraform wierskynlik de bêste kar wie foar de organisaasje.

Terraform Horrible

Beta software

Terraform hat noch net iens ferzje 1.0 frijlitten, wat in goede reden is om it net te brûken. It is in protte feroare sûnt ik it earst sels besocht, mar doe terraform apply faak bruts nei ferskate updates of gewoan nei in pear jier fan gebrûk. Ik soe sizze dat "alles is no oars," mar ... dat is wat elkenien liket te sizzen, nee? D'r binne feroaringen dy't net kompatibel binne mei eardere ferzjes, hoewol se passend binne, en it fielt sels as de syntaksis en abstraksjes fan boarnewinkels no binne wat wy nedich binne. It ynstrumint liket echt better wurden te wêzen, mar... :-0

Oan 'e oare kant hat AWS in goede baan dien mei it behâld fan efterkompatibiliteit. Dit is wierskynlik om't har tsjinsten faak yngeand hifke wurde binnen de organisaasje en allinich dan, omneamd, wurde publisearre. Dus "se besochten hurd" is in understatement. It behâld fan efterútkompatibiliteit mei API's foar in systeem sa fariearre en kompleks as AWS is ongelooflijk lestich. Elkenien dy't iepenbiere API's moast ûnderhâlde dy't sa breed wurde brûkt as se binne, moatte begripe hoe lestich it is om dat safolle jierren te dwaan. Mar it gedrach fan CloudFormation, yn myn ûnthâld, is yn 'e rin fan' e jierren noait feroare.

Moetsje de skonk... it is in kûgel

Sa fier as ik wit, wiskje de boarne bûtensteander CloudFormation-stapel fan jo CF-stapel is net mooglik. Itselde is wier mei Terraform. It lit jo besteande boarnen ymportearje yn jo stapel. De funksje kin sein wurde amazing, mar mei grutte macht komt grutte ferantwurdlikens. Jo moatte gewoan in boarne tafoegje oan 'e stapel, en wylst jo mei jo stapel wurkje, kinne jo dizze boarne net wiskje of feroarje. Op in dei sloech it werom. Op in dei op Twitch ymportearre immen per ongeluk de AWS-befeiligingsgroep fan in oar yn har eigen Terraform-stapel sûnder mis. Ik ynfierde ferskate kommando's en ... de feiligensgroep (tegearre mei ynkommende ferkear) ferdwûn.

Terraform Great

Herstel fan ûnfolsleine steaten

Soms slagget CloudFormation net om folslein oer te gean fan de iene steat nei de oare. Tagelyk sil er besykje werom te gean nei de foarige. It is spitich dat dit net altyd mooglik is. It kin nochal eng wêze om te debuggen wat letter barde - jo witte noait oft CloudFormation bliid wêze sil dat it wurdt hackt - sels gewoan om it te reparearjen. Of it sil mooglik wêze om werom te gean nei de foarige steat, hy wit echt net hoe te bepalen en, standert, hinget oeren te wachtsjen op in wûnder.

Terraform, oan 'e oare kant, hat de neiging om te herstellen fan mislearre oergongen folle sierliker en biedt avansearre ark foar debuggen.

Dúdliker feroarings oan dokumint steat

"Okee, load balancer, jo feroarje. Mar hoe?"

-anxious yngenieur, klear om te drukken op de "akseptearje" knop.

Soms moat ik wat manipulaasjes dwaan mei de loadbalancer yn 'e CloudFormation-stapel, lykas it tafoegjen fan in poartenûmer of it feroarjen fan in befeiligingsgroep. ClouFormation toant feroarings min. Ik, op pinnen en naalden, kontrolearje it yaml-bestân tsien kear dûbel om te soargjen dat ik neat nedich haw wiske en neat oerstallichs tafoege.

Terraform is yn dit ferbân folle transparanter. Soms is er sels te trochsichtich (lês: ferfelend). Gelokkich omfettet de lêste ferzje ferbettere werjefte fan feroaringen, sadat jo no krekt kinne sjen wat der feroaret.

Fleksibiliteit

Skriuw software efterút.

Om it bot te sizzen, is it wichtichste skaaimerk fan lange libbene software de mooglikheid om oan te passen oan feroaring. Skriuw elke software efterút. Ik makke faaks flaters troch in "ienfâldige" tsjinst te nimmen, en dan alles te begjinnen yn in inkele CloudFormation- of Terraform-stapel. En fansels, moannen letter die bliken dat ik hie begrepen alles ferkeard, en de tsjinst wie eins net simpel! En no moat ik op ien of oare manier in grutte stapel yn lytse komponinten brekke. As jo ​​wurkje mei CloudFormation, kin dit allinich dien wurde troch earst de besteande stapel opnij oan te meitsjen, en ik doch dit net mei myn databases. Terraform, oan 'e oare kant, makke it mooglik om te dissectearje de stapel en brekke it yn mear begryplike lytsere dielen.

Modules yn git

It dielen fan Terraform-koade oer meardere stapels is folle makliker dan it dielen fan CloudFormation-koade. Mei Terraform kinne jo jo koade yn in git-repository pleatse en tagong krije mei semantyske ferzjekontrôle. Elkenien mei tagong ta dit repository kin de dielde koade opnij brûke. CloudFormation syn ekwivalint is S3, mar it hat net deselde foardielen, en der is gjin reden wêrom't wy moatte ferlitte git yn it foardiel fan S3 at all.

De organisaasje groeide en de mooglikheid om mienskiplike stapels te dielen berikte in kritysk nivo. Terraform makket dit allegear maklik en natuerlik, wylst CloudFormation jo troch hoepels sil meitsje springe foardat jo sa'n ding kinne wurkje.

Operaasje as koade

"Litte wy it skript meitsje en goed."

-in yngenieur 3 jier foardat de Terraform-fyts útfûn.

As it giet om softwareûntwikkeling, is Go of in Java-programma net allinich koade.

Oerskeakele fan Terraform nei CloudFormation - en spyt derfan
Koade as Koade

D'r is ek de ynfrastruktuer wêrop it wurket.

Oerskeakele fan Terraform nei CloudFormation - en spyt derfan
Ynfrastruktuer as koade

Mar wêr komt se wei? Hoe kinne jo it kontrolearje? Wêr wennet jo koade? Binne ûntwikkelders tagongsrjochten nedich?

Oerskeakele fan Terraform nei CloudFormation - en spyt derfan
Operaasje as Code

In softwareûntwikkelder wêze betsjuttet net allinich it skriuwen fan koade.

AWS is net de ienige: jo brûke wierskynlik oare providers. SignalFx, PagerDuty of Github. Miskien hawwe jo in ynterne Jenkins-tsjinner foar CI / CD of in ynterne Grafana-dashboard foar tafersjoch. Infra as Code wurdt keazen foar ferskate redenen, en elk is like wichtich foar alles yn ferbân mei software.

Doe't ik by Twitch wurke, fersnelden wy tsjinsten binnen Amazon's mingde ynbêde en AWS-systemen. Wy makken en stipe in protte mikrotsjinsten, wêrtroch operasjonele kosten tanommen. De diskusjes wiene sa:

  • Я: Ferdomme, dat is in protte stjoerings om ien mikroservice te oerklokken. Ik sil dit jiskefet moatte brûke om in AWS-akkount te meitsjen (wy gongen nei 2 akkounts op mikroservice), dan dizze foar it ynstellen fan warskôgings, dizze foar in koaderepository, en dizze foar in e-postlist, en dan dizze ...
  • Foarsprong: Litte wy it skriuwe en goed.
  • Я: Okee, mar it skript sels sil feroarje. D'r sil in manier wêze moatte om te kontrolearjen dat al dizze ynboude Amazon-gizmos aktueel binne.
  • Foarsprong: Klinkt goed. En wy sille hjir in skript foar skriuwe.
  • Я: Grut! En it skript sil wierskynlik noch parameters ynstelle moatte. Sil er se akseptearje?
  • Foarsprong: Lit him nimme wêr't er giet!
  • Я: It proses kin feroarje en efterútkompatibiliteit sil ferlern gean. Guon soarte fan semantyske ferzjekontrôle sil nedich wêze.
  • Foarsprong: Geweldich idee!
  • Я: Tools kinne mei de hân wizige wurde, binnen de brûkersynterface. Wy hawwe in manier nedich om dit te kontrolearjen en te reparearjen.

…3 jier letter:

  • Foarsprong: En wy krigen terraform.

De moraal fan it ferhaal is: sels as jo holle boppe hakken yn alles Amazon, jo brûke noch wat net fan AWS, en dizze tsjinsten hawwe in steat dy't in konfiguraasjetaal brûkt om dy steat syngronisearje te hâlden.

CloudFormation lambda vs git modules terraform

lambda is de oplossing fan CloudFormation foar it oanpaste logika-probleem. Mei lambda kinne jo meitsje makro of brûker boarne. Dizze oanpak yntroduseart ekstra kompleksiteiten dy't net oanwêzich binne yn Terraform's semantyske ferzje fan git-modules. Foar my wie it meast driuwende probleem it behearen fan tagongsrjochten foar al dizze brûkerslambda's (en dit binne tsientallen AWS-akkounts). In oar wichtich probleem wie it probleem "wat kaam earst, de hin of it aai?" Dizze funksje sels is ynfrastruktuer en koade, en it hat sels tafersjoch en updates nedich. De lêste spiker yn 'e kiste wie de muoite yn semantysk fernijing lambda koade feroarings; wy moasten ek soargje dat de stack aksjes sûnder in direkte kommando net feroare tusken rinnen.

Ik wit noch dat ik ienris in kanaryske ynset woe meitsje foar de Elastic Beanstalk-omjouwing mei in klassike loadbalancer. It maklikste ding om te dwaan soe wêze om in twadde ynset foar de EB neist de produksjeomjouwing te meitsjen, it in stap fierder te nimmen: it kombinearjen fan de auto-skaaljende kanaryske ynsetgroep mei de ynset LB yn 'e produksjeomjouwing. En sûnt Terraform brûkt ASG beantalk as konklúzje, dit sil 4 ekstra rigels koade yn Terraform fereaskje. Doe't ik frege oft d'r in fergelykbere oplossing wie yn CloudFormation, wiisden se my op in heule git-repository mei in ynsetpipeline en alles, alles om 'e wille fan iets dat earme 4 rigels fan Terraform-koade koe dwaan.

It detektearret drift better

Soargje derfoar dat de realiteit oerienkomt mei ferwachtingen.

Driftdeteksje is in tige krêftige operaasjes as koade funksje omdat it helpt te soargjen dat realiteit oerienkomt ferwachtings. It is beskikber mei sawol CloudFormation as Terraform. Mar doe't de produksjestapel groeide, produsearre sykjen nei drift yn CloudFormation mear en mear falske deteksjes.

Mei Terraform hawwe jo folle mear avansearre lifecycle-haken foar driftdeteksje. Jo ynfiere bygelyks it kommando negearje_feroarings direkt yn de ECS taak definysje as jo wolle negearje feroarings oan in spesifike taak definysje sûnder negearje feroarings oan jo hiele ECS ynset.

CDK en de takomst fan CloudFormation

CloudFormation is lestich te behearjen op grutte, cross-ynfrastruktuer skalen. In protte fan dizze swierrichheden wurde erkend en it ark hat dingen nedich lykas aws-cdk, in ramt foar it definiearjen fan wolkynfrastruktuer yn koade en it útfieren fia AWS CloudFormation. It sil nijsgjirrich wêze om te sjen wat de takomst hat foar aws-cdk, mar it sil it dreech hawwe om te konkurrearjen mei de oare sterke punten fan Terraform; om CloudFormation bywurke te bringen, sille globale feroarings nedich wêze.

Dat Terraform stelt net teloarstelle

Dit is "ynfrastruktuer as koade", en net "as tekst".

Myn earste yndruk fan Terraform wie nochal min. Ik tink dat ik de oanpak gewoan net begrepen. Hast alle yngenieurs sjogge it ûnwillekeurich as in tekstformaat dat omboud wurde moat yn de winske ynfrastruktuer. DO IT NET OP dizze manier.

De truisms fan goede softwareûntwikkeling jilde ek foar Terraform.

Ik haw sjoen dat in protte praktiken oannommen binne om goede koade te meitsjen wurde negearre yn Terraform. Jo hawwe jierren studearre om in goede programmeur te wurden. Jou dizze ûnderfining net op gewoan om't jo mei Terraform wurkje. De truisms fan goede softwareûntwikkeling jilde foar Terraform.

Hoe kin de koade net dokumintearre wurde?

Ik haw enoarme Terraform-stapels sjoen sûnder dokumintaasje. Hoe kinne jo koade yn siden skriuwe - sûnder dokumintaasje? Add dokumintaasje dy't ferklearret dyn code Terraform (klam op it wurd "koade"), wêrom dizze seksje is sa wichtich, en wat jo dogge.

Hoe kinne wy ​​ynsette tsjinsten dy't eartiids ien grutte wichtichste () funksje?

Ik haw sjoen hiel komplekse Terraform stacks presintearre as ien module. Wêrom ynsette wy gjin software op dizze manier? Wêrom spjalte wy grutte funksjes yn lytsere? Deselde antwurden jilde foar Terraform. As jo ​​module is te grut, Jo moatte brekke it del yn lytsere modules.

Brûkt jo bedriuw gjin bibleteken?

Ik haw sjoen hoe't yngenieurs, dy't in nij projekt opspinden mei Terraform, enoarme brokken fan oare projekten dom kopiearje-plakken yn har eigen, en dêrnei mei har tinzen oant it begon te wurkjen. Wolle jo wurkje as dit mei "combat" koade yn jo bedriuw? Wy brûke net allinich bibleteken. Ja, net alles hoecht in biblioteek te wêzen, mar wêr binne wy ​​sûnder dielde bibleteken yn prinsipe?!

Brûke jo gjin PEP8 of gofmt?

De measte talen hawwe in standert, akseptearre opmaakskema. Yn Python is dit PEP8. In Go - gofmt. Terraform hat syn eigen: terraform fmt. Genietsje derfan foar jo sûnens!

Sille jo React brûke sûnder JavaScript te kennen?

Terraform-modules kinne in diel fan 'e komplekse ynfrastruktuer dy't jo meitsje ferienfâldigje, mar dit betsjut net dat jo der hielendal net mei kinne tinken. Wolle jo Terraform korrekt brûke sûnder boarnen te begripen? Jo binne doomed: tiid sil foarby, en do silst nea master Terraform.

Kodearje jo mei singletons as ôfhinklikensynjeksje?

Ofhinklikensynjeksje is in erkende bêste praktyk foar softwareûntwikkeling en wurdt foarkar boppe singletons. Hoe is dit nuttich yn Terraform? Ik haw sjoen Terraform modules dy't ôfhinklik binne op ôfstân steat. Yn stee fan in skriuwen modules dy't ophelje remote steat, skriuw in module dy't nimt parameters. En dan trochjaan dizze parameters oan de module.

Doch jo biblioteken tsien dingen goed of ien ding geweldich?

Biblioteken dy't it bêste wurkje binne dejingen dy't har rjochtsje op ien taak dy't se heul goed dogge. Ynstee fan it skriuwen fan grutte Terraform-modules dy't besykje alles tagelyk te dwaan, bouwe dielen fan har dy't ien ding goed dogge. En kombinearje se dan as nedich.

Hoe meitsje jo wizigingen oan bibleteken sûnder efterkompatibiliteit?

In mienskiplike Terraform-module, lykas in gewoane bibleteek, moat op ien of oare manier wizigingen oan brûkers kommunisearje sûnder efterút kompatibel te wêzen. It is ferfelend as dizze feroarings barre mei biblioteken, en it is like ferfelend as net-efterút-kompatibele feroarings wurde makke oan Terraform-modules. It wurdt oanrikkemandearre om git-tags en semver te brûken by it brûken fan Terraform-modules.

Wurket jo produksjetsjinst op jo laptop of yn in datasintrum?

Hashicorp hat ark lykas terraform wolk om jo terraform te rinnen. Dizze sintralisearre tsjinsten meitsje it maklik te behearjen, kontrolearjen en goedkarre fan terraformwizigingen.

Skriuwst gjin toetsen?

Yngenieurs erkenne dat de koade moat wurde hifke, mar se sels faak ferjitte testen doe't wurkjen mei Terraform. Foar ynfrastruktuer is dit beladen mei ferriedlike mominten. Myn advys is in "test" of "meitsje foarbyld" stacks mei help fan modules dy't kinne wurde ynset korrekt foar testen tidens CI / CD.

Terraform en mikroservices

It libben en dea fan bedriuwen foar mikroservices hinget ôf fan 'e snelheid, ynnovaasje en fersteuring fan nije mikroservice-wurkstacks.

De meast foarkommende negative aspekt ferbûn mei microservice arsjitektuer, en dat kin net wurde eliminearre, is besibbe oan it wurk, net de koade. As jo ​​tinke oan Terraform as gewoan in manier om allinich de ynfrastruktuerkant fan in arsjitektuer foar mikrotsjinsten te automatisearjen, dan misse jo de wiere foardielen fan it systeem. No is it al alles is as koade.

Boarne: www.habr.com

Add a comment