Predstavljanje infrastrukture kao koda u ponovljivom tekstualnom formatu jednostavna je najbolja praksa za sustave koji ne zahtijevaju petljanje s miševima. Ova praksa ima ime - , a do sada postoje dva popularna alata za njegovu implementaciju, posebno u AWS-u: и .
Usporedba iskustva s Terraformom i CloudFormationom
Prije dolaska k sebi (Aka ) Radio sam i koristio Terraform tri godine. Na novom mjestu sam također svim silama koristio Terraform, a onda je tvrtka pogurala prijelaz na sve a la Amazon, uključujući CloudFormation. Marljivo sam razvio najbolje prakse za oba i koristio sam oba alata u vrlo složenim tijekovima rada za cijelu organizaciju. Kasnije, nakon pažljivog vaganja implikacija prelaska s Terraforma na CloudFormation, postao sam uvjeren da je Terraform vjerojatno najbolji izbor za organizaciju.
Terraform Užasno
Beta softver
Terraform još nije ni izdao verziju 1.0, što je dobar razlog da je ne koristite. Dosta se promijenio otkako sam ga prvi put sam probao, ali tada terraform apply često se pokvario nakon nekoliko ažuriranja ili jednostavno nakon nekoliko godina korištenja. Rekao bih da je "sada sve drugačije", ali... čini se da to svi govore, zar ne? Postoje promjene koje nisu kompatibilne s prethodnim verzijama, iako su prikladne, a čak se čini da su sintaksa i apstrakcije spremišta resursa sada ono što nam treba. Čini se da je instrument stvarno postao bolji, ali... :-0
S druge strane, AWS je napravio dobar posao održavajući kompatibilnost sa prethodnim verzijama. To je vjerojatno zato što se njihove usluge često temeljito testiraju unutar organizacije i tek onda, preimenovane, objavljuju. Dakle, "mnogo su se trudili" je podcjenjivanje. Održavanje povratne kompatibilnosti s API-jima za tako raznolik i složen sustav kao što je AWS nevjerojatno je teško. Svatko tko je morao održavati javne API-je koji se tako široko koriste trebao bi shvatiti koliko je to teško činiti toliko godina. Ali ponašanje CloudFormationa, koliko se ja sjećam, nikada se nije promijenilo tijekom godina.
Upoznaj nogu... to je metak
Koliko ja znam, izbriši resurs autsajder CloudFormation stog iz vašeg CF stoga nije moguć. Isto je i s Terraformom. Omogućuje vam uvoz postojećih resursa u vaš stog. Može se reći da je funkcija nevjerojatna, ali s velikom snagom dolazi i velika odgovornost. Vi samo trebate dodati resurs u stog, a dok radite sa svojim stogom, ne možete izbrisati ili promijeniti ovaj resurs. Jednog dana to se izjalovilo. Jednog dana na Twitchu, netko je slučajno uvezao tuđu AWS sigurnosnu grupu u vlastiti Terraform stog, a da pritom nije napravio nikakvu nepodopštinu. Unio sam nekoliko naredbi i... sigurnosna grupa (zajedno s dolaznim prometom) je nestala.
Terraform Sjajno
Oporavak od nepotpunih stanja
Ponekad CloudFormation ne uspije u potpunosti prijeći iz jednog stanja u drugo. Pritom će se pokušati vratiti na prijašnje. Šteta je što to nije uvijek izvedivo. Može biti prilično zastrašujuće otklanjati pogreške u onome što se dogodilo kasnije - nikad ne znate hoće li CloudFormation biti sretan što je hakiran - čak i samo da to popravi. Hoće li se moći vratiti u prethodno stanje ili ne, on stvarno ne zna kako odrediti i, standardno, visi satima čekajući čudo.
Terraform se, s druge strane, nastoji oporaviti od neuspjelih prijelaza mnogo gracioznije i nudi napredne alate za otklanjanje pogrešaka.
Jasnije promjene stanja dokumenta
“U redu, balanser opterećenja, mijenjaš se. Ali kako?"
— zabrinuti inženjer, spreman pritisnuti tipku "prihvati".
Ponekad moram napraviti neke manipulacije s balanserom opterećenja u CloudFormation stogu, kao što je dodavanje broja porta ili promjena sigurnosne grupe. ClouFormation loše prikazuje promjene. Ja, na iglicama i iglama, deset puta provjeravam yaml datoteku kako bih bio siguran da nisam izbrisao ništa potrebno i dodao ništa nepotrebno.
Terraform je mnogo transparentniji u tom pogledu. Ponekad je čak i previše proziran (čitaj: dosadan). Srećom, najnovija verzija uključuje poboljšani prikaz promjena tako da sada možete točno vidjeti što se mijenja.
savitljivost
Pišite softver unatrag.
Iskreno rečeno, najvažnija karakteristika dugovječnog softvera je sposobnost prilagodbe promjenama. Napišite bilo koji softver unatrag. Najčešće sam griješio uzimajući "jednostavnu" uslugu, a zatim sve trpajući u jedan CloudFormation ili Terraform stog. I naravno, mjesecima kasnije pokazalo se da sam sve krivo shvatio, a usluga zapravo nije bila jednostavna! A sada moram nekako razbiti veliki hrp na male komponente. Kada radite s CloudFormationom, to se može učiniti samo tako da prvo ponovno stvorite postojeći stog, a ja to ne radim sa svojim bazama podataka. Terraform je, s druge strane, omogućio raščlanjivanje hrpe i rastavljanje na razumljivije manje dijelove.
Moduli u git-u
Dijeljenje Terraform koda na više hrpa puno je lakše od dijeljenja CloudFormation koda. Uz Terraform, možete staviti svoj kod u git repozitorij i pristupiti mu pomoću semantičke kontrole verzija. Svatko s pristupom ovom repozitoriju može ponovno koristiti zajednički kod. CloudFormationov ekvivalent je S3, ali nema iste prednosti i nema razloga zašto bismo uopće trebali napustiti git u korist S3.
Organizacija je rasla i sposobnost dijeljenja zajedničkih hrpa dosegla je kritičnu razinu. Terraform čini sve ovo lakim i prirodnim, dok će vas CloudFormation natjerati da preskočite niz obruča prije nego što ovo počnete raditi.
Operacije kao kod
"Napišimo scenarij i u redu."
— inženjer 3 godine prije izuma bicikla Terraform.
Kada je riječ o razvoju softvera, Go ili Java program nije samo kod.
Kod kao kod
Tu je i infrastruktura na kojoj radi.
Infrastruktura kao kod
Ali odakle je ona? Kako to pratiti? Gdje živi vaš kod? Trebaju li programeri dopuštenje za pristup?
Operacije kao kod
Biti programer ne znači samo pisati kod.
AWS nije jedini: vjerojatno koristite druge pružatelje. SignalFx, PagerDuty ili Github. Možda imate interni Jenkins poslužitelj za CI/CD ili internu Grafana nadzornu ploču za nadzor. Infra kao kod odabran je iz različitih razloga, a svaki je jednako važan za sve što je povezano sa softverom.
Kad sam radio u Twitchu, ubrzali smo usluge unutar Amazonovih mješovitih ugrađenih i AWS sustava. Izradili smo i podržali mnoge mikroservise, povećavajući operativne troškove. Rasprave su tekle otprilike ovako:
- Я: Prokletstvo, to je puno gesti za overclockanje jednog mikroservisa. Morat ću upotrijebiti ovo smeće za kreiranje AWS računa (išli smo na 2 računa na mikroservis), zatim ovaj za postavljanje upozorenja, ovaj za skladište koda, i ovaj za popis e-pošte, pa ovaj...
- voditi: Napišimo scenarij i u redu.
- Я: Dobro, ali sam scenarij će se promijeniti. Trebat će nam način da provjerimo jesu li svi ovi ugrađeni Amazonovi alati ažurni.
- voditi: Zvuči dobro. I za ovo ćemo napisati scenarij.
- Я: Sjajno! A skripta će vjerojatno još trebati postaviti parametre. Hoće li ih prihvatiti?
- voditi: Neka nosi kuda ide!
- Я: Proces se može promijeniti i izgubit će se kompatibilnost s prethodnim verzijama. Bit će potrebna neka vrsta kontrole semantičke verzije.
- voditi: Odlična ideja!
- Я: Alati se mogu mijenjati ručno, unutar korisničkog sučelja. Trebat će nam način da to provjerimo i popravimo.
…3 godine kasnije:
- voditi: I dobili smo terraform.
Pouka priče je: čak i ako ti preko ušiju u svemu Amazonu, još uvijek koristite nešto što nije iz AWS-a, a te usluge imaju stanje koje koristi konfiguracijski jezik za održavanje sinkronizacije tog stanja.
CloudFormation lambda vs git moduli terraform
lambda je CloudFormationovo rješenje za problem prilagođene logike. S lambdom možete ili . Ovaj pristup uvodi dodatne složenosti koje nisu prisutne u Terraformovoj semantičkoj verziji git modula. Za mene je najhitniji problem bilo upravljanje dopuštenjima za sve te korisničke lambde (a to su deseci AWS računa). Drugi važan problem bio je problem "što je bilo prije, kokoš ili jaje?": bio je povezan s lambda kodom. Sama ova funkcija je infrastruktura i kod, i sama treba nadgledanje i ažuriranje. Posljednji čavao u lijes bila je poteškoća u semantičkom ažuriranju promjena lambda koda; također smo morali paziti da se akcije stogova bez izravne naredbe ne mijenjaju između pokretanja.
Sjećam se da sam jednom želio stvoriti implementaciju kanarinca za okruženje Elastic Beanstalk s klasičnim balanserom opterećenja. Najjednostavnije bi bilo napraviti drugu implementaciju za EB pored proizvodnog okruženja, ići korak dalje: kombinirajući auto-skalirajuću grupu za implementaciju canary s implementacijom LB u proizvodnom okruženju. A budući da Terraform koristi , to će zahtijevati 4 dodatna retka koda u Terraformu. Kad sam pitao postoji li usporedivo rješenje u CloudFormationu, ukazali su mi na cijelo git spremište s cjevovodom za implementaciju i svime, a sve u svrhu nečega što jadna 4 retka Terraform koda mogu učiniti.
Bolje detektira pomicanje
Pobrinite se da stvarnost odgovara očekivanjima.
je vrlo moćna operacija kao značajka koda jer pomaže osigurati da stvarnost odgovara očekivanjima. Dostupan je s CloudFormation i Terraform. Ali kako je proizvodni stog rastao, traženje drifta u CloudFormationu proizvodilo je sve više lažnih detekcija.
S Terraformom imate mnogo naprednije kuke životnog ciklusa za detekciju zanošenja. Na primjer, unesete naredbu izravno u definiciji ECS zadatka ako želite ignorirati promjene specifične definicije zadatka bez ignoriranja promjena cijele ECS implementacije.
CDK i budućnost CloudFormationa
CloudFormationom je teško upravljati na velikim razinama među infrastrukturama. Mnoge od ovih poteškoća su prepoznate i alat treba stvari poput , okvir za definiranje infrastrukture oblaka u kodu i njegovo pokretanje kroz AWS CloudFormation. Bit će zanimljivo vidjeti što budućnost nosi za aws-cdk, ali teško će se natjecati s ostalim snagama Terraforma; da bi se CloudFormation ažurirao, bit će potrebne globalne promjene.
Tako da Terraform ne razočara
Ovo je “infrastruktura kao kod”, a ne “kao tekst”.
Moj prvi dojam o Terraformu je bio prilično loš. Mislim da jednostavno nisam razumio pristup. Gotovo svi inženjeri ga nehotice percipiraju kao tekstualni format koji treba pretvoriti u željenu infrastrukturu. NE RADITE TO NA OVAJ NAČIN.
Istine dobrog razvoja softvera također se odnose na Terraform.
Vidio sam da se mnoge prakse usvojene za stvaranje dobrog koda ignoriraju u Terraformu. Godinama ste učili kako biste postali dobar programer. Nemojte se odreći ovog iskustva samo zato što radite s Terraformom. Istine dobrog razvoja softvera odnose se na Terraform.
Kako kod ne može biti dokumentiran?
Vidio sam ogromne hrpe Terraforma bez ikakve dokumentacije. Kako možete pisati kod na stranicama - bez ikakve dokumentacije? Dodajte dokumentaciju koja objašnjava vaše šifra Terraform (naglasak na riječi "kod"), zašto je ovaj odjeljak toliko važan i što radite.
Kako možemo implementirati usluge koje su nekad bile jedna velika main() funkcija?
Vidio sam vrlo složene Terraform hrpe predstavljene kao jedan modul. Zašto ne implementiramo softver na ovaj način? Zašto velike funkcije dijelimo na manje? Isti odgovori vrijede i za Terraform. Ako je vaš modul prevelik, trebate ga rastaviti na manje module.
Zar vaša tvrtka ne koristi knjižnice?
Vidio sam kako su inženjeri, razvijajući novi projekt pomoću Terraforma, glupo kopirali ogromne komade iz drugih projekata u svoje, a zatim petljali s njima dok nije počelo funkcionirati. Biste li ovako radili s "borbenim" kodom u svojoj tvrtki? Ne koristimo se samo knjižnicama. Da, ali gdje smo bez dijeljenih knjižnica u principu?!
Zar ne koristiš PEP8 ili gofmt?
Većina jezika ima standardnu, prihvaćenu shemu oblikovanja. U Pythonu ovo je PEP8. U Go - gofmt. Terraform ima svoje: terraform fmt. Koristite na zdravlje!
Hoćete li koristiti React bez poznavanja JavaScripta?
Terraform moduli mogu pojednostaviti neke dijelove složene infrastrukture koju stvorite, ali to ne znači da se s tim uopće ne možete petljati. Želite ispravno koristiti Terraform bez razumijevanja resursa? Osuđeni ste: vrijeme će proći, a vi nikada nećete ovladati Terraformom.
Kodirate li s singletonima ili ubrizgavanjem ovisnosti?
Dependency injection je priznata najbolja praksa za razvoj softvera i preferira se u odnosu na singletons. Kako je to korisno u Terraformu? Vidio sam Terraform module koji ovise o udaljenom stanju. Umjesto pisanja modula koji dohvaćaju udaljeno stanje, napišite modul koji uzima parametre. Zatim proslijedite ove parametre modulu.
Rade li vaše knjižnice deset stvari dobro ili jednu stvar odlično?
Knjižnice koje rade najbolje su one koje se fokusiraju na jedan zadatak koji vrlo dobro obavljaju. Umjesto pisanja velikih Terraform modula koji pokušavaju učiniti sve odjednom, sastavite njihove dijelove koji rade jednu stvar dobro. A onda ih po potrebi kombinirati.
Kako napraviti promjene u bibliotekama bez kompatibilnosti sa starijim verzijama?
Uobičajeni Terraform modul, poput obične knjižnice, treba na neki način komunicirati promjene korisnicima, a da ne bude kompatibilan unazad. Neugodno je kada se te promjene dogode u bibliotekama, a jednako je neugodno kada se promjene koje nisu kompatibilne sa prethodnim verzijama naprave u Terraform modulima. Preporučljivo je koristiti oznake git i semver kada koristite Terraform module.
Radi li vaša proizvodna usluga na vašem prijenosnom računalu ili u podatkovnom centru?
Hashicorp ima alate poput pokrenuti svoju terraformu. Ove centralizirane usluge olakšavaju upravljanje, reviziju i odobravanje promjena terraforme.
Zar ne pišeš testove?
Inženjeri prepoznaju da kod treba testirati, ali oni sami često zaborave na testiranje kada rade s Terraformom. Za infrastrukturu, ovo je prepuno opasnih trenutaka. Moj savjet je da "testirate" ili "stvorite primjere" skupova koristeći module koji se mogu pravilno implementirati za testiranje tijekom CI/CD-a.
Terraform i mikroservisi
Život i smrt mikroservisnih tvrtki ovisi o brzini, inovativnosti i poremećaju novih mikroservisnih radnih nizova.
Najčešći negativni aspekt povezan s mikroservisnim arhitekturama, a koji se ne može eliminirati, vezan je uz rad, a ne kod. Ako o Terraformu razmišljate samo kao o načinu automatizacije samo infrastrukturne strane arhitekture mikroservisa, tada propuštate istinske prednosti sustava. Sada već jeste .
Izvor: www.habr.com