Prešao sa Terraforma na CloudFormation - i požalio

Predstavljanje infrastrukture kao koda u ponovljivom tekstualnom formatu je jednostavna najbolja praksa za sisteme koji ne zahtijevaju petljanje s miševima. Ova praksa ima ime - Infrastruktura kao kod, a do sada postoje dva popularna alata za implementaciju, posebno u AWS: Terraform и CloudFormation.

Prešao sa Terraforma na CloudFormation - i požalio
Poređenje iskustva sa Terraformom i CloudFormationom

Prije nego što dođem Twitch (aka Amazon Jr.) Radio sam u jednom startupu i koristio Terraform tri godine. Na novom mjestu sam također koristio Terraform svom snagom, a onda je kompanija pogurala prelazak na sve a la Amazon, uključujući i CloudFormation. Marljivo sam razvijao najbolje prakse za oba, i koristio sam oba alata u veoma složenim radnim tokovima širom organizacije. Kasnije, nakon što sam pažljivo odmjerio implikacije migracije sa Terraforma na CloudFormation, postao sam uvjeren da je Terraform vjerovatno najbolji izbor za organizaciju.

Terraform Horrible

Beta softver

Terraform još nije objavio ni verziju 1.0, što je dobar razlog da je ne koristite. Mnogo se promijenio otkako sam ga prvi put isprobao, ali tada terraform apply često se pokvari nakon nekoliko ažuriranja ili jednostavno nakon nekoliko godina korištenja. Rekao bih da je „sada sve drugačije“, ali... izgleda da svi tako kažu, zar ne? Postoje promjene koje nisu kompatibilne sa prethodnim verzijama, iako su prikladne, a čak se čini da su sintaksa i apstrakcije skladišta resursa sada ono što nam treba. Čini se da je instrument zaista postao bolji, ali... :-0

S druge strane, AWS je napravio dobar posao održavajući kompatibilnost unatrag. To je vjerovatno zato što se njihove usluge često temeljito testiraju unutar organizacije i tek onda, preimenovane, objavljuju. Dakle, „potrudili su se” je potcenjivanje. Održavanje kompatibilnosti unatrag sa API-jima za sistem tako raznolik i složen kao što je AWS je neverovatno teško. Svako ko je morao održavati javne API-je koji se koriste toliko široko, trebao bi shvatiti koliko je teško to učiniti toliko godina. Ali ponašanje CloudFormation-a, u mom sećanju, nikada se nije promenilo tokom godina.

Upoznajte nogu... to je metak

Koliko ja znam, obrišite resurs autsajder CloudFormation stack iz vašeg CF steka nije moguć. Isto je i sa Terraformom. Omogućava vam da uvezete postojeće resurse u svoj stog. Može se reći da je funkcija nevjerovatna, ali uz veliku snagu dolazi i velika odgovornost. Vi samo trebate dodati resurs u stog, a dok radite sa svojim stekom, ne možete izbrisati ili promijeniti ovaj resurs. Jednog dana se to izjalovilo. Jednog dana na Twitchu, neko je slučajno uvezao nečiju tuđu AWS sigurnosnu grupu u svoj Terraform stack, a da nije bio spreman za bilo kakve nestašluke. Uneo sam nekoliko komandi i... bezbednosna grupa (zajedno sa dolaznim saobraćajem) je nestala.

Terraform Great

Oporavak od nepotpunih stanja

Ponekad CloudFormation ne uspijeva u potpunosti preći iz jednog stanja u drugo. Istovremeno će pokušati da se vrati na prethodni. Šteta što to nije uvijek izvodljivo. Može biti prilično zastrašujuće otklanjati greške u onome što se dogodilo kasnije - nikad ne znate da li će CloudFormation biti sretan što je hakovan - čak i samo da to popravi. Hoće li se moći vratiti u prethodno stanje ili ne, on zaista ne zna kako da odredi i, po defaultu, satima visi čekajući čudo.

Terraform, s druge strane, ima tendenciju da se oporavi od neuspjelih prijelaza mnogo gracioznije i nudi napredne alate za otklanjanje grešaka.

Jasnije promjene stanja dokumenta

“U redu, balansator opterećenja, mijenjaš se. Ali kako?"

— zabrinuti inženjer, spreman da pritisne dugme „prihvati“.

Ponekad moram da izvršim neke manipulacije sa balansatorom opterećenja u CloudFormation stogu, kao što je dodavanje broja porta ili promena bezbednosne grupe. ClouFormation loše prikazuje promjene. Ja, na iglama, dvaput provjeravam yaml datoteku deset puta da se uvjerim da nisam obrisao ništa potrebno i da nisam dodao ništa nepotrebno.

Terraform je mnogo transparentniji u tom pogledu. Ponekad je čak i previše transparentan (čitaj: dosadan). Srećom, najnovija verzija uključuje poboljšani prikaz promjena tako da sada možete vidjeti što se točno mijenja.

Fleksibilnost

Pisanje softvera unatrag.

Iskreno rečeno, najvažnija karakteristika dugovječnog softvera je sposobnost prilagođavanja promjenama. Napišite bilo koji softver unatrag. Najčešće sam pravio greške tako što sam uzeo „jednostavnu“ uslugu, a zatim počeo da trpam sve u jedan CloudFormation ili Terraform stack. I naravno, mjesecima kasnije se pokazalo da sam sve pogrešno shvatio, a usluga zapravo nije bila jednostavna! A sada moram nekako da razbijem veliki stog na male komponente. Kada radite s CloudFormationom, to se može učiniti samo tako da se prvo kreira postojeći stog, a ja to ne radim sa svojim bazama podataka. Terraform je, s druge strane, omogućio da se gomila secira i razbije na razumljivije manje dijelove.

Moduli u git-u

Dijeljenje Terraform koda na više stekova je mnogo lakše nego dijeljenje CloudFormation koda. Sa Terraformom, možete staviti svoj kod u git spremište i pristupiti mu pomoću semantičke kontrole verzija. Svako ko ima pristup ovom spremištu može ponovo koristiti zajednički kod. Ekvivalent CloudFormation-a je S3, ali on 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 stekova dostigla je kritičan nivo. Terraform sve ovo čini lakim i prirodnim, dok će vas CloudFormation natjerati da skačete kroz obruče prije nego što nešto poput ovoga počnete raditi.

Operacije kao kod

"Hajde da to skriptiramo i u redu."

—inženjer 3 godine pre nego što je izumeo Terraform bicikl.

Kada je u pitanju razvoj softvera, Go ili Java program nije samo kod.

Prešao sa Terraforma na CloudFormation - i požalio
Šifra kao kod

Tu je i infrastruktura na kojoj radi.

Prešao sa Terraforma na CloudFormation - i požalio
Infrastruktura kao kod

Ali odakle je ona? Kako to pratiti? Gdje živi vaš kod? Da li je programerima potrebna dozvola za pristup?

Prešao sa Terraforma na CloudFormation - i požalio
Operacije kao kod

Biti programer softvera ne znači samo pisati kod.

AWS nije jedini: vjerovatno koristite druge provajdere. SignalFx, PagerDuty ili Github. Možda imate interni Jenkins server za CI/CD ili internu Grafana kontrolnu tablu za nadgledanje. Infra as Code se bira iz različitih razloga, a svaki je podjednako važan za sve što se tiče softvera.

Kada sam radio u Twitchu, ubrzali smo usluge unutar Amazonovih mješovitih ugrađenih i AWS sistema. Izradili smo i podržali mnoge mikroservise, povećavajući operativne troškove. Diskusije su tekle otprilike ovako:

  • Я: Prokletstvo, to je puno gestova za overklokiranje jedne mikroservise. Morat ću iskoristiti ovo smeće za kreiranje AWS naloga (prešli smo na 2 računa mikroservis), zatim ovo za postavljanje upozorenja, ovo za spremište kodova, a ovo za listu e-pošte, pa ovo...
  • Olovo: Hajde da skriptiramo i ok.
  • Я: U redu, ali sam scenario će se promijeniti. Trebat će nam način da provjerimo jesu li svi ovi ugrađeni Amazon gizmoovi ažurirani.
  • Olovo: Zvuči dobro. I za ovo ćemo napisati scenario.
  • Я: Odlično! A skripta će vjerovatno i dalje morati postaviti parametre. Hoće li ih prihvatiti?
  • Olovo: Neka nosi kuda ide!
  • Я: Proces se može promijeniti i kompatibilnost unatrag će biti izgubljena. Neka vrsta semantičke kontrole verzija će biti potrebna.
  • Olovo: Odlicna ideja!
  • Я: Alati se mogu mijenjati ručno, unutar korisničkog interfejsa. Trebat će nam način da ovo provjerimo i popravimo.

…3 godine kasnije:

  • Olovo: I dobili smo teraformu.

Moral priče je: čak i ako ti bezglavo u svemu Amazon, još uvijek koristite nešto što nije iz AWS-a, a ove usluge imaju stanje koje koristi konfiguracijski jezik da bi to stanje bilo sinhronizirano.

CloudFormation lambda vs git moduli terraform

lambda je CloudFormation-ovo rješenje za problem prilagođene logike. Sa lambdom možete kreirati makroe ili korisnički resurs. Ovaj pristup uvodi dodatne složenosti koje nisu prisutne u Terraformovoj semantičkoj verziji git modula. Za mene je najhitniji problem bilo upravljanje dozvolama za sve ove korisničke lambda (a to su desetine AWS naloga). Još jedan važan problem bio je „šta je bilo prvo, kokoška ili jaje: bio je povezan sa lambda kodom“. Ova funkcija je sama po sebi infrastruktura i kod, a njoj je potrebno praćenje i ažuriranje. Poslednji ekser u kovčeg bila je poteškoća u semantičkom ažuriranju promena lambda koda; također smo morali osigurati da se akcije steka bez direktne komande ne mijenjaju između pokretanja.

Sjećam se da sam jednom htio kreirati kanarinac za okruženje Elastic Beanstalk s klasičnim balansatorom opterećenja. Najlakše bi bilo napraviti drugu implementaciju za EB pored proizvodnog okruženja, i to korak dalje: kombinujući grupu za primenu kanarinca sa automatskim skaliranjem sa implementacijom LB u proizvodno okruženje. I pošto Terraform koristi ASG beantalk kao zaključak, ovo će zahtijevati 4 dodatne linije koda u Terraformu. Kada sam pitao da li postoji uporedivo rešenje u CloudFormation-u, ukazali su mi na čitavo git spremište sa cevovodom za implementaciju i sve, sve zarad nečega što jadna 4 reda Terraform koda mogu da urade.

Bolje detektuje drift

Uvjerite se da stvarnost odgovara očekivanjima.

Detekcija drifta je vrlo moćna operacija kao karakteristika koda jer pomaže osigurati da stvarnost odgovara očekivanjima. Dostupan je i sa CloudFormation i Terraform. Ali kako je proizvodni skup rastao, potraga za pomakom u CloudFormation-u proizvodila je sve više i više lažnih detekcija.

Sa Terraformom imate mnogo naprednije kuke životnog ciklusa za detekciju zanošenja. Na primjer, unesete naredbu ignore_changes direktno u definiciji ECS zadatka ako želite zanemariti promjene određene definicije zadatka bez zanemarivanja promjena u cijeloj ECS implementaciji.

CDK i budućnost CloudFormation-a

CloudFormation je teško upravljati na velikim, međuinfrastrukturnim skalama. Mnoge od ovih poteškoća su prepoznate i alatu su potrebne stvari kao što su aws-cdk, okvir za definisanje infrastrukture oblaka u kodu i njegovo pokretanje kroz AWS CloudFormation. Biće zanimljivo videti šta budućnost nosi za aws-cdk, ali će mu biti teško da se takmiči sa drugim prednostima 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 utisak o Terraformu bio je prilično loš. Mislim da jednostavno nisam razumio pristup. Gotovo svi inženjeri nehotice ga doživljavaju kao tekstualni format koji treba pretvoriti u željenu infrastrukturu. NEMOJTE TO RADITI OVAKO.

Istina o dobrom razvoju softvera važe i za Terraform.

Video sam mnoge prakse usvojene za kreiranje dobrog koda koje se ignorišu u Terraformu. Godinama ste učili da postanete dobar programer. Nemojte odustati od ovog iskustva samo zato što radite sa Terraformom. Istina o dobrom razvoju softvera odnosi se na Terraform.

Kako se kod ne može dokumentirati?

Vidio sam ogromne Terraform hrpe bez apsolutno nikakve dokumentacije. Kako možete napisati kod na stranicama - bez apsolutno nikakve dokumentacije? Dodajte dokumentaciju koja objašnjava vaše kod Terraform (naglasak na riječi "šifra"), zašto je ovaj odjeljak toliko važan i šta radite.

Kako možemo implementirati usluge koje su nekada bile jedna velika main() funkcija?

Video sam veoma složene Terraform stekove predstavljene kao jedan modul. Zašto softver ne implementiramo na ovaj način? Zašto dijelimo velike funkcije na manje? Isti odgovori vrijede i za Terraform. Ako je vaš modul prevelik, morate ga razbiti na manje module.

Zar vaša kompanija ne koristi biblioteke?

Vidio sam kako su inženjeri, koji su pokretali novi projekat koristeći Terraform, glupo kopirali ogromne komade drugih projekata u svoje, a zatim petljali s njima dok nije proradio. Da li biste radili ovako sa "borbenim" kodom u vašoj kompaniji? Mi ne koristimo samo biblioteke. da, ne mora sve biti biblioteka, ali gdje smo bez zajedničkih biblioteka u principu?!

Zar ne koristite PEP8 ili gofmt?

Većina jezika ima standardnu, prihvaćenu shemu oblikovanja. U Pythonu je to PEP8. U Go - gofmt. Terraform ima svoje: terraform fmt. Uživajte za svoje zdravlje!

Hoćete li koristiti React bez poznavanja JavaScripta?

Terraform moduli mogu pojednostaviti neki dio složene infrastrukture koju kreirate, ali to ne znači da se uopće ne možete petljati s tim. Želite pravilno koristiti Terraform bez razumijevanja resursa? Vi ste osuđeni na propast: vrijeme će proći, a vi nikada nećete ovladati Terraformom.

Da li kodirate sa singletonima ili injekcijom zavisnosti?

Injekcija zavisnosti je priznata najbolja praksa za razvoj softvera i preferira se nad singletonima. Kako je ovo korisno u Terraformu? Vidio sam Terraform module koji zavise od udaljenog stanja. Umjesto pisanja modula koji dohvaćaju udaljeno stanje, napišite modul koji uzima parametre. A zatim proslijedite ove parametre modulu.

Da li vaše biblioteke rade deset stvari dobro ili jednu stvar sjajnu?

Biblioteke koje najbolje rade su one koje se fokusiraju na jedan zadatak koji vrlo dobro obavljaju. Umjesto da pišete velike Terraform module koji pokušavaju učiniti sve odjednom, napravite njihove dijelove koji rade jednu stvar dobro. A onda ih kombinujte po potrebi.

Kako unosite promjene u biblioteke bez kompatibilnosti unatrag?

Uobičajeni modul Terraform, poput obične biblioteke, treba na neki način komunicirati promjene korisnicima bez kompatibilnosti unatrag. Nervirajuće je kada se ove promjene dešavaju u bibliotekama, a jednako je neugodno kada se u Terraform modulima naprave promjene koje nisu kompatibilne s prethodnim. Preporučljivo je koristiti git tagove i semver kada koristite Terraform module.

Da li vaša proizvodna usluga radi na vašem laptopu ili u data centru?

Hashicorp ima alate poput terraform cloud da pokrenete svoju terraformu. Ove centralizirane usluge olakšavaju upravljanje, reviziju i odobravanje promjena terraforma.

Zar ne pišeš testove?

Inženjeri prepoznaju da kod treba biti testiran, ali sami često zaborave na testiranje kada rade sa Terraformom. Za infrastrukturu, ovo je ispunjeno izdajničkim trenucima. Moj savjet je da “testirate” ili “napravite primjer” stekova koristeći module koji se mogu ispravno postaviti za testiranje tokom CI/CD-a.

Terraform i mikroservis

Život i smrt mikroservisnih kompanija zavise od brzine, inovacije i prekida rada novih mikroservisa.

Najčešći negativni aspekt povezan sa mikroservisnim arhitekturama, a koji se ne može eliminisati, odnosi se na rad, a ne na kod. Ako smatrate da je Terraform samo način da se automatizuje samo infrastrukturna strana arhitekture mikroservisa, onda propuštate prave prednosti sistema. Sad je već sve je kao kod.

izvor: www.habr.com

Dodajte komentar