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 -
Primerjava izkušenj s Terraform in CloudFormation
Pred prihodom k
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.
Koda kot koda
Obstaja tudi infrastruktura, na kateri deluje.
Infrastruktura kot zakonik
Toda od kod je? Kako ga spremljati? Kje živi vaša koda? Ali razvijalci potrebujejo dovoljenje za dostop?
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
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
Bolje zazna odnašanje
Prepričajte se, da se resničnost ujema s pričakovanji.
S Terraformom imate veliko bolj napredne kljuke življenjskega cikla za zaznavanje odnašanja. Na primer, vnesete ukaz
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
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
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
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
Vir: www.habr.com