Preklopil s Terraform na CloudFormation – in obžaloval

Predstavljanje infrastrukture kot kode v ponovljivem besedilnem formatu je preprosta najboljša praksa za sisteme, ki ne zahtevajo igranja z mišmi. Ta praksa ima ime - Infrastruktura kot zakonik, in do zdaj obstajata dve priljubljeni orodji za njegovo implementacijo, zlasti v AWS: Terraform и Oblikovanje oblaka.

Preklopil s Terraform na CloudFormation – in obžaloval
Primerjava izkušenj s Terraform in CloudFormation

Pred prihodom k Trzanje (Aka Amazon Jr.) Delal sem v enem zagonu in uporabljal Terraform tri leta. Na novem mestu sem na vso moč uporabljal tudi Terraform, nato pa je podjetje potisnilo prehod na vse a la Amazon, vključno z CloudFormation. Pridno sem razvijal najboljše prakse za oba in uporabljal obe orodji v zelo zapletenih potekih dela za celotno organizacijo. Kasneje, po premišljenem tehtanju posledic selitve s Terraform na CloudFormation, sem postal prepričan, da je Terraform verjetno najboljša izbira za organizacijo.

Terraform Horrible

Beta programska oprema

Terraform sploh še ni izdal različice 1.0, kar je dober razlog, da je ne uporabljate. Se je zelo spremenilo, odkar sem ga prvič poskusil sam, ampak takrat terraform apply pogosto pokvaril po več posodobitvah ali preprosto po nekaj letih uporabe. Rekel bi, da je »zdaj vse drugače«, ampak ... zdi se, da to vsi pravijo, kajne? Obstajajo spremembe, ki niso združljive s prejšnjimi različicami, čeprav so primerne, in zdi se celo, da so sintaksa in abstrakcije shramb virov tisto, kar potrebujemo. Zdi se, da je instrument res postal boljši, ampak ... :-0

Po drugi strani pa je AWS opravil dobro delo pri ohranjanju združljivosti za nazaj. Verjetno zato, ker so njihove storitve pogosto temeljito testirane znotraj organizacije in šele nato, preimenovane, objavljene. Torej "trdo so se trudili" je podcenjevanje. Ohranjanje povratne združljivosti z API-ji za tako raznolik in kompleksen sistem, kot je AWS, je neverjetno težko. Vsakdo, ki je moral vzdrževati javne API-je, ki se tako pogosto uporabljajo, bi moral razumeti, kako težko je to početi toliko let. Toda vedenje CloudFormation se po mojem spominu z leti ni nikoli spremenilo.

Spoznaj nogo ... to je krogla

Kolikor vem, izbriši vir outsider Sklad CloudFormation iz vašega sklada CF ni mogoč. Enako velja za Terraform. Omogoča vam uvoz obstoječih virov v vaš sklad. Za funkcijo lahko rečemo, da je neverjetna, vendar z veliko močjo prihaja velika odgovornost. Preprosto morate dodati vir v sklad in medtem ko delate s svojim skladom, tega vira ne morete izbrisati ali spremeniti. Nekega dne se je izjalovilo. Nekega dne na Twitchu je nekdo pomotoma uvozil varnostno skupino AWS nekoga drugega v svoj lasten sklad Terraform, pri čemer ni hotel nobene nesreče. Vnesel sem več ukazov in ... varnostna skupina (skupaj z dohodnim prometom) je izginila.

Terraform Super

Okrevanje iz nepopolnih stanj

Včasih CloudFormation ne uspe popolnoma preiti iz enega stanja v drugo. Ob tem se bo skušal vrniti na prejšnjega. Škoda, da to ni vedno izvedljivo. Odpravljanje napak, ki se je zgodilo pozneje, je lahko precej strašljivo - nikoli ne veš, ali bo CloudFormation vesel, da so vanj vdrli - tudi samo zato, da bi to popravili. Ali se bo mogoče vrniti v prejšnje stanje ali ne, res ne ve, kako ugotoviti in privzeto visi več ur in čaka na čudež.

Terraform pa se nagiba k okrevanju po neuspelih prehodih veliko elegantneje in ponuja napredna orodja za odpravljanje napak.

Jasnejše spremembe stanja dokumenta

»V redu, uravnavalec obremenitve, spreminjaš se. Ampak kako?"

— zaskrbljen inženir, pripravljen pritisniti gumb »sprejmi«.

Včasih moram narediti nekaj manipulacij z izravnalnikom obremenitve v skladu CloudFormation, na primer dodati številko vrat ali spremeniti varnostno skupino. ClouFormation slabo prikazuje spremembe. Na trbah desetkrat dvakrat preverim datoteko yaml, da se prepričam, da nisem izbrisal ničesar potrebnega in dodal ničesar nepotrebnega.

Terraform je v tem pogledu veliko bolj pregleden. Včasih je celo preveč prozoren (beri: nadležen). Na srečo najnovejša različica vključuje izboljšan prikaz sprememb, tako da lahko zdaj natančno vidite, kaj se spreminja.

Prilagodljivost

Pišite programsko opremo nazaj.

Odkrito povedano, najpomembnejša značilnost dolgožive programske opreme je sposobnost prilagajanja spremembam. Napišite katero koli programsko opremo nazaj. Najpogosteje sem naredil napako tako, da sem vzel "preprosto" storitev in nato začel vse strpati v en sam sklad CloudFormation ali Terraform. In seveda, nekaj mesecev kasneje se je izkazalo, da sem vse razumel narobe in storitev pravzaprav ni bila preprosta! In zdaj moram velik sklad nekako razdeliti na majhne komponente. Ko delate s CloudFormation, lahko to storite samo tako, da najprej znova ustvarite obstoječi sklad, tega pa ne počnem s svojimi zbirkami podatkov. Terraform pa je omogočil razkosanje skladovnice in njeno razdelitev na bolj razumljive manjše dele.

Moduli v git

Skupna raba kode Terraform v več nizih je veliko lažja kot skupna raba kode CloudFormation. S Terraformom lahko svojo kodo postavite v repozitorij git in do nje dostopate s semantičnim nadzorom različic. Vsakdo z dostopom do tega repozitorija lahko znova uporabi skupno kodo. Enakovrednik CloudFormation je S3, vendar nima enakih prednosti in ni razloga, zakaj bi morali opustiti git v korist S3.

Organizacija je rasla in zmožnost skupne rabe skladov je dosegla kritično raven. Terraform naredi vse to enostavno in naravno, CloudFormation pa vas bo prisilil, da skočite skozi obroče, preden vam bo uspelo kaj takega delovati.

Operacije kot koda

"Napišimo scenarij in v redu."

— inženir 3 leta pred izumom kolesa Terraform.

Ko gre za razvoj programske opreme, Go ali program Java ni le koda.

Preklopil s Terraform na CloudFormation – in obžaloval
Koda kot koda

Obstaja tudi infrastruktura, na kateri deluje.

Preklopil s Terraform na CloudFormation – in obžaloval
Infrastruktura kot zakonik

Toda od kod je? Kako ga spremljati? Kje živi vaša koda? Ali razvijalci potrebujejo dovoljenje za dostop?

Preklopil s Terraform na CloudFormation – in obžaloval
Operacije kot koda

Biti razvijalec programske opreme ne pomeni samo pisati kodo.

AWS ni edini: verjetno uporabljate druge ponudnike. SignalFx, PagerDuty ali Github. Morda imate notranji strežnik Jenkins za CI/CD ali notranjo nadzorno ploščo Grafana za spremljanje. Infra kot koda je izbrana iz različnih razlogov in vsak je enako pomemben za vse, kar je povezano s programsko opremo.

Ko sem delal pri Twitchu, smo pospeševali storitve znotraj Amazonovih mešanih vgrajenih sistemov in sistemov AWS. Izdelali in podprli smo številne mikrostoritve, kar je povečalo operativne stroške. Razprave so potekale nekako takole:

  • Я: Prekleto, to je veliko potez za overclockanje ene mikrostoritve. To smeti bom moral uporabiti za ustvarjanje računa AWS (šli smo na 2 računa na mikrostoritev), potem ta za nastavitev opozoril, ta za repozitorij kode in ta za e-poštni seznam in potem ta ...
  • Svinec: Napišimo scenarij in v redu.
  • Я: V redu, ampak sam scenarij se bo spremenil. Potrebovali bomo način, da preverimo, ali so vsi ti vgrajeni gizmi Amazon posodobljeni.
  • Svinec: Zveni dobro. In za to bomo napisali scenarij.
  • Я: Super! In skript bo verjetno še vedno moral nastaviti parametre. Jih bo sprejel?
  • Svinec: Naj pelje, kamor gre!
  • Я: Postopek se lahko spremeni in združljivost s prejšnjimi različicami bo izgubljena. Potreben bo nekakšen semantični nadzor različic.
  • Svinec: Odlična ideja!
  • Я: Orodja je mogoče spremeniti ročno, znotraj uporabniškega vmesnika. Potrebovali bomo način, da to preverimo in popravimo.

…3 leta kasneje:

  • Svinec: In dobili smo terraform.

Morala zgodbe je: tudi če ti z glavo v vse Amazon, še vedno uporabljate nekaj, kar ni iz AWS, in te storitve imajo stanje, ki uporablja konfiguracijski jezik, da ohranja to stanje sinhronizirano.

CloudFormation lambda proti modulom git terraform

lambda je rešitev CloudFormation za težavo z logiko po meri. Z lambdo lahko ustvarjanje makrov ali uporabniški vir. Ta pristop uvaja dodatne zapletenosti, ki niso prisotne v Terraformovi semantični različici modulov git. Zame je bila najbolj pereča težava upravljanje dovoljenj za vse te uporabniške lambde (in to je na desetine računov AWS). Drug pomemben problem je bil problem »kaj je bilo prej, kokoš ali jajce?«: bil je povezan z lambda kodo. Ta funkcija je sama po sebi infrastruktura in koda ter sama potrebuje spremljanje in posodobitve. Zadnji žebelj v krsto je bila težava pri semantičnem posodabljanju sprememb lambda kode; prav tako smo morali zagotoviti, da se dejanja sklada brez neposrednega ukaza med zagoni ne spremenijo.

Spomnim se, da sem nekoč želel ustvariti kanarčkovo uvedbo za okolje Elastic Beanstalk s klasičnim izravnalnikom obremenitve. Najpreprostejša stvar bi bila narediti drugo uvedbo za EB poleg produkcijskega okolja, s čimer bi naredili korak naprej: združili skupino za uvedbo Canary s samodejnim skaliranjem in umestitveno LB v produkcijsko okolje. In ker Terraform uporablja ASG beatalk kot zaključek, bo to zahtevalo 4 dodatne vrstice kode v Terraformu. Ko sem vprašal, ali obstaja primerljiva rešitev v CloudFormation, so me opozorili na celotno repozitorij git s cevovodom za uvajanje in vsem, vse zaradi nečesa, kar bi lahko naredile slabe 4 vrstice kode Terraform.

Bolje zazna odnašanje

Prepričajte se, da se resničnost ujema s pričakovanji.

Zaznavanje zanašanja je zelo močna operacija kot funkcija kode, ker pomaga zagotoviti, da se resničnost ujema s pričakovanji. Na voljo je s CloudFormation in Terraform. Ko pa se je proizvodni sklad povečeval, je iskanje zanašanja v CloudFormation povzročilo vedno več lažnih zaznav.

S Terraformom imate veliko bolj napredne kljuke življenjskega cikla za zaznavanje odnašanja. Na primer, vnesete ukaz ignore_changes neposredno v definiciji naloge ECS, če želite prezreti spremembe določene definicije naloge, ne da bi prezrli spremembe vaše celotne uvedbe ECS.

CDK in prihodnost CloudFormation

CloudFormation je težko upravljati na velikih infrastrukturnih lestvicah. Veliko teh težav je prepoznanih in orodje potrebuje stvari, kot so aws-cdk, ogrodje za definiranje infrastrukture oblaka v kodi in njeno izvajanje prek AWS CloudFormation. Zanimivo bo videti, kakšna bo prihodnost za aws-cdk, vendar se bo težko kosal z drugimi prednostmi Terraforma; da bo CloudFormation posodobljen, bodo potrebne globalne spremembe.

Da Terraform ne razočara

To je »infrastruktura kot koda« in ne »kot besedilo«.

Moj prvi vtis o Terraformu je bil precej slab. Mislim, da preprosto nisem razumel pristopa. Skoraj vsi inženirji ga nehote dojemajo kot besedilni format, ki ga je treba pretvoriti v želeno infrastrukturo. NE DELAJTE NA TAKOLI.

Pravila dobrega razvoja programske opreme veljajo tudi za Terraform.

Videl sem veliko praks, sprejetih za ustvarjanje dobre kode, ki jih Terraform ignorira. Leta ste se učili, da bi postali dober programer. Ne opustite te izkušnje samo zato, ker delate s Terraformom. Resnice dobrega razvoja programske opreme veljajo za Terraform.

Kako lahko koda ni dokumentirana?

Videl sem ogromne sklade Terraform brez prav nobene dokumentacije. Kako lahko pišete kodo na straneh - brez prav nobene dokumentacije? Dodajte dokumentacijo, ki pojasnjuje vaše koda Terraform (poudarek na besedi "koda"), zakaj je ta razdelek tako pomemben in kaj počnete.

Kako lahko uvedemo storitve, ki so bile nekoč ena velika main() funkcija?

Videl sem zelo zapletene sklade Terraform, predstavljene kot en sam modul. Zakaj ne uvedemo programske opreme na ta način? Zakaj delimo velike funkcije na manjše? Enaki odgovori veljajo za Terraform. Če je vaš modul prevelik, ga morate razdeliti na manjše module.

Ali vaše podjetje ne uporablja knjižnic?

Videl sem, kako so inženirji, ki so začeli nov projekt z uporabo Terraforma, neumno kopirali ogromne dele iz drugih projektov v svoje in se nato poigravali z njimi, dokler ni začelo delovati. Bi tako delali z »bojno« kodo v vašem podjetju? Ne uporabljamo samo knjižnic. da ni nujno, da je vse knjižnica, kam pa smo načeloma brez deljenih knjižnic?!

Ali ne uporabljaš PEP8 ali gofmt?

Večina jezikov ima standardno, sprejeto shemo oblikovanja. V Pythonu je to PEP8. V Go - gofmt. Terraform ima svoje: terraform fmt. Uživajte za svoje zdravje!

Boste uporabljali React brez poznavanja JavaScripta?

Moduli Terraform lahko poenostavijo del kompleksne infrastrukture, ki jo ustvarite, vendar to ne pomeni, da se z njo sploh ne morete ukvarjati. Želite pravilno uporabljati Terraform brez razumevanja virov? Obsojeni ste: čas bo minil in nikoli ne boste obvladali Terraforma.

Ali kodirate s posameznimi elementi ali z vbrizgavanjem odvisnosti?

Vstavljanje odvisnosti je priznana najboljša praksa za razvoj programske opreme in ima prednost pred posameznimi programi. Kako je to uporabno v Terraformu? Videl sem module Terraform, ki so odvisni od oddaljenega stanja. Namesto pisanja modulov, ki pridobivajo oddaljeno stanje, napišite modul, ki sprejema parametre. In nato posredujte te parametre modulu.

Ali vaše knjižnice delajo dobro deset stvari ali eno dobro?

Knjižnice, ki najbolje delujejo, so tiste, ki se osredotočajo na eno nalogo, ki jo opravljajo zelo dobro. Namesto pisanja velikih modulov Terraform, ki poskušajo narediti vse naenkrat, sestavite njihove dele, ki eno stvar naredijo dobro. In jih nato po potrebi kombinirajte.

Kako naredite spremembe v knjižnicah brez združljivosti za nazaj?

Običajni modul Terraform, tako kot običajna knjižnica, mora nekako sporočiti spremembe uporabnikom, ne da bi bil združljiv za nazaj. Moteče je, ko se te spremembe zgodijo v knjižnicah, in prav tako moteče je, ko se v modulih Terraform naredijo spremembe, ki niso združljive s prejšnjimi različicami. Pri uporabi modulov Terraform je priporočljiva uporaba oznak git in semver.

Ali vaša produkcijska storitev deluje na vašem prenosniku ali v podatkovnem centru?

Hashicorp ima orodja, kot je teraformni oblak za vodenje vaše terraforme. Te centralizirane storitve olajšajo upravljanje, revizijo in odobritev sprememb teraforme.

Ne pišeš testov?

Inženirji se zavedajo, da je treba kodo preizkusiti, a sami pogosto pozabijo na testiranje pri delu s Terraformom. Za infrastrukturo je to polno zahrbtnih trenutkov. Moj nasvet je, da "testirate" ali "ustvarite primere" skladov z uporabo modulov, ki jih je mogoče pravilno namestiti za testiranje med CI/CD.

Terraform in mikrostoritve

Življenje in smrt podjetij za mikrostoritve je odvisno od hitrosti, inovativnosti in motenj novih delovnih nizov mikrostoritev.

Najpogostejši negativni vidik, povezan z arhitekturami mikrostoritev in ki ga ni mogoče odpraviti, je povezan z delom, ne s kodo. Če menite, da je Terraform le način za avtomatizacijo samo infrastrukturne strani arhitekture mikrostoritev, potem zamujate prave prednosti sistema. Zdaj je že vse je kot koda.

Vir: www.habr.com

Dodaj komentar