Predstavljanje infrastrukture kao koda u ponovljivom tekstualnom formatu najbolja je praksa za sustave koju nije potrebno dodatno objašnjavati. Ova praksa poznata je pod nazivom , a za njeno ostvarivanje, posebno u AWS-u, postoje dva popularna alata: i .
Uspoređujem iskustva s Terraformom i CloudFormationom
Prije nego što sam došao u (poznat i kao ) radio sam i tri godine koristio Terraform. Na novom mjestu također sam aktivno koristio Terraform, a zatim je tvrtka odlučila preći na sve a la Amazon, uključujući CloudFormation. Temeljito sam razvijao najbolje prakse i za jedan i za drugi alat, te ih koristio u vrlo složenim radnim procesima širom organizacije. Kasnije, nakon pažljivog razmatranja posljedica prelaska s Terrform na CloudFormation, uvjerio sam se da je Terraform, vjerovatno, najbolji izbor za organizaciju.
Terraform Užasno
Beta verzija softvera
Terraform još uvijek nema verziju 1.0, i to je veliki razlog za ne korištenje. Otada kada sam ga prvi put probao, jako se promijenio, ali tada je terraform apply često bio pokvaren nakon nekoliko ažuriranja ili jednostavno nakon par godina eksploatacije. Rekao bih da je "sada sve drukčije", ali... tako svi govore, zar ne? Ima promjena koje nisu kompatibilne s prethodnim verzijama, iako su opravdane, a čak se stječe dojam da je sintaksa i apstrakcije spremišta resursa sada ono što treba. Alat se zapravo čini boljim, ali... :-0
S druge strane, AWS se dobro potrudio održavajući kompatibilnost s prethodnim verzijama. Vjerojatno je to zato što se njihove usluge često dobro testiraju unutar organizacije i tek nakon toga, preimenuju, objavljuju. Tako da je "dobro su se potrudili" još blaga izjava. Održavanje kompatibilnosti s prethodnim verzijama API-ja za tako raznoliku i složenu sustav kao što je AWS nevjerojatno je teško. Svakome tko je ikada pokušavao održavati javne API-je koji se koriste tako široko, mora biti jasno koliko je teško to raditi kroz sve te godine. A ponašanje CloudFormacija se, koliko se sjećam, nijednom nije promijenilo s godinama.
Poznaj nogu... to je metak
Koliko ja znam, ukloniti resurs stranog Uvođenje resursa u CloudFormation stog iz svog CF stoga nije moguće. Slično tome, Terraform omogućava uvoz postojećih resursa u svoj stog. Funkcija je, moglo bi se reći, zapanjujuća, ali s velikom snagom dolazi i velika odgovornost. Jednom kada se resurs uvede u stog, dok radiš sa svojim stogom, taj resurs ne možeš obrisati ili promeniti. Jednom nas je to koštalo. Na Twitch sajtu, neko, ne misleći ništa loše, slučajno je uveo nečiju AWS sigurnosnu grupu u svoj vlastiti Terraform stog. Unio je nekoliko komandi i... sigurnosna grupa (zajedno s dolaznim prometom) nestala je.
Terraform Veliki
Obnova iz nedovršenih stanja
Ponekad CloudFormation ne može u potpunosti preći iz jednog stanja u drugo. Pritom će se truditi da se vrati na prethodno. Nažalost, to nije uvek izvodljivo. Teško je kasnije debagovati ono što se dogodilo — nikada ne znaš hoće li CloudFormation biti sretan zbog svojih 'hakiranja' — čak i ako radiš na popravci. A hoće li se moći vratiti na prethodno stanje, ne zna dobro i po defaultu uzima časima čekajući čudo.
Terraform, s druge strane, sklone je da se obnavlja nakon neuspelih prelaza na mnogo elegantniji način i nudi proširene alate za debagovanje.
Jasnije promene u stanjima dokumenta
„U redu, ravnotežni uređaju, ti se menjaš. Ali kako?”
— zabrinuti inženjer, spreman pritisnuti dugme „prihvati”.
Ponekad moram napraviti neke manipulacije s ravnotežnim uređajem u CloudFormation stogu — na primer, dodati broj porta ili promeniti sigurnosnu grupu. CloudFormation slabo prikazuje promene. Ja, kao na iglama, prekontroliram yaml datoteku deset puta, da budem siguran da nisam nešto važno obrisao, a suvišno dodao.
Terraform je u tom smislu mnogo transparentniji. Ponekad čak i previše transparentan (pročitaj: dodaje nervozu). Na sreću, u najnoviju verziju su uključili poboljšano prikazivanje promena — sada se tačno vidi šta se menja.
Fleksibilnost
Pišite softver obrnutim redosledom.
Govoreći otvoreno, najvažnija karakteristika dugovječnog softvera je sposobnost prilagodbe promjenama. Svaki softver treba pisati od kraja. Najčešće sam se spotaknuo na tome što sam uzeo "jednostavni" servis, a potom se suočavao s problemom integriranja svega u jedinstveni CloudFormation ili Terraform stog. Naravno, nakon nekoliko mjeseci, otkrilo se da ništa nisam shvatio kako treba i da servis zapravo nije jednostavan! Tako da sam morao nekako raspodijeliti veliki stog na manje dijelove. Kada radite s CloudFormation, to je moguće samo ponovnim stvaranjem postojećeg stoga, što ja, sa svojim bazama podataka, ne radim. Terraform, s druge strane, omogućuje razdvajanje stoga i dijeljenje na razumljivije, manje dijelove.
Moduli u git
Dijeliti Terraform kod među brojnim stogovima puno je lakše nego kod CloudFormation. S Terraformom možete staviti kod u git repozitorij i pristupati mu koristeći semantičko upravljanje verzijama. Svako tko ima pristup tom repozitoriju može ponovno koristiti zajednički kod. Ekvivalent CloudFormation-a je S3, ali on nema iste prednosti i nema razloga da se uopće odreknete gita u korist S3.
Organizacija je rasla i sposobnost dijeljenja zajedničkih stogova dostigla je kritičnu razinu. S Terraformom to dolazi lako i prirodno, dok vas CloudFormation tjera da preskočite kroz obruče prije nego što dobijete nešto slično.
Operacije kao kod
„Napišimo skriptu i gotovo.“
- inženjer tri godine prije nego što je izumio Terraform.
Kada je riječ o razvoju softvera, Go ili Java program nije samo kod.
Kod kao kod
Tu je i infrastruktura na kojoj to radi.
Infrastructure as Code
Ali odakle ona dolazi? Kako je pratiti? Gdje je vaš kod? Trebaju li programeri dozvolu za pristup?
Operacije kao kod
Biti softverski programer ne znači samo pisati kod.
Nije samo AWS: vjerojatno koristite usluge drugih davatelja. SignalFx, PagerDuty ili Github. Možda imate vlastiti Jenkins server za CI/CD ili unutarnju Grafana kontrolnu ploču za praćenje. Infra kao kod bira se iz raznih razloga, a svaki je jednako važan za sve vezano uz softver.
Kada sam radio u Twitchu, ubrzavali smo usluge unutar miješanih ugrađenih sustava i AWS Amazon sustava. Štamparili smo i održavali brojne mikroservise, povećavajući operativne troškove. Rasprave su obično bile ovakvog tipa:
- Ja: Čekaj, to je previše koraka za pokretanje jednog mikroservisa. Trebat će mi ova stvar da otvorim AWS račun (prijelazili smo na 2 računa na mikroservis), zatim ovo — za postavljanje obavijesti, još ovo — za repozitorij koda, i ovo — za popis email adresa, pa još ovo…
- Kontakt: Skriptirat ćemo i gotovo.
- Ja: U redu, ali sam skript će se promijeniti. Trebat će način da provjerimo jesu li sve te ugrađene stvari Amazona u ažuriranom stanju.
- Kontakt: Zvuči dobro. I za to ćemo napisati skript.
- Ja: Odlično! A sigurno će trebati i parametre. Hoće li ih primiti?
- Kontakt: Hoće, kamo bi otišao!
- Ja: Proces se može promijeniti, izgubit će se unatrag kompatibilnost. Bit će potreban neki semantički kontrola verzija.
- Kontakt: Sjajna ideja!
- Ja: Alate možemo mijenjati ručno, unutar korisničkog sučelja. Trebat će nam način da to provjeravamo i ispravljamo.
…3 godine kasnije:
- Kontakt: I uspjeli smo napraviti terraform.
Moral priče je da čak i ako ste do ušiju u svemu od Amazona, i dalje koristite nešto što nije od AWS-a, a ti servisi imaju stanje koje koristi jezik za konfiguraciju kako bi to stanje sinkronizirali.
CloudFormation lambda vs git-moduli terraform
lambda je CloudFormation rješenje za pitanje korisničke logike. Pomoću lambda možete ili . Ovaj pristup predstavlja dodatne složenosti koje nemamo u semantičkom kontroli verzija git modula u Terraformu. Za mene je najhitniji problem postao upravljanje dozvolama za sve te korisničke lambda (a to su deseci AWS računa). Drugi važan problem bila je dilema: što je prvotno bilo — kokoš ili jaje?: bila je povezana s kodom lambda. Ova funkcija sama po sebi je infrastruktura i kod, i trebaju joj monitoring i ažuriranja. Posljednji čavao u lijes bio je problem semantičkog ažuriranja izmjena koda lambda; također je trebalo osigurati da se akcije stoga ne mijenjaju između pokretanja bez izravne naredbe.
Sjećam se da sam jednom poželio stvoriti kanarinski deployment za Elastic Beanstalk s klasičnim ravnotežom opterećenja. Najlakše bi bilo napraviti drugo raspoređivanje za EB pored proizvodnog okruženja, poduzimajući još jedan korak: spoji automatski skalabilnu grupu kanarinskog rasporeda s LB rasporedom u proizvodno okruženje. A budući da Terraform koristi , to zahtijeva 4 dodatne linije koda u Terraformu. Kada sam pitao postoji li usporedivo rješenje u CloudFormationu, pokazali su mi cijeli repozitorij u gitu s sustavom raspoređivanja i ostalim: i sve to — zbog onih jadnih 4 linije koda u Terraformu.
Bolje otkriva drift
Provjerite jesu li stvarnost i očekivanja usklađeni.
— vrlo moćna funkcija operations as code, jer pomaže osigurati da stvarnost odgovara očekivanjima. Dostupna je i s CloudFormationom i s Terraformom. No, kako se radna okruženja povećavaju, otkrivanje drifta u CloudFormationu davalo je sve više lažnih upozorenja.
S Terraformom imate mnogo naprednije lifecycle hookove za otkrivanje drifta. Na primjer, unosite naredbu direktno u definiciji ECS zadatka, ako želite ignorirati promjene u definiciji određenog zadatka, ne zanemarujući pri tome promjene u cijelom ECS rasporedu.
CDK i budućnost CloudFormationa
CloudFormation je teško upravljati na velikim, međuinfrastrukturnim razmjerima. Mnogi od ovih problema su prepoznati, a alat treba stvari poput , struktura za definiranje cloud infrastrukture u kodu i njezino izvođenje kroz AWS CloudFormation. Bit će zanimljivo vidjeti što čeka aws-cdk u budućnosti, ali će mu biti teško natjecati se s drugim prednostima Terraform-a; bit će potrebne globalne promjene da bi CloudFormation postao konkurentan.
Da Terraform ne razočara
To je ‘infrastruktura kao KOD’, a ne ‘kao tekst’.
Moj prvi dojam o Terraformu bio je prilično loš. Mislim da jednostavno nisam razumio pristup. Gotovo svi inženjeri prvotno ga nesvjesno doživljavaju kao tekstualni format koji treba pretvoriti u željenu infrastrukturu. NE TREBA TAKO.
Osnovne istine dobre razvoja softvera primjenjuju se i na Terraform.
Vidjela sam kako mnoge prakse za pisanje dobrog koda bivaju ignorirane u Terraformu. Godinama ste učili da postanete dobar programer. Ne odričite se tog iskustva samo zato što radite s Terraformom. Istinite tvrdnje dobre softverske izvedbe primjenjuju se i na Terraform.
Kako možete kodirati i ne dokumentirati?
Naišla sam na ogromne Terraform stackove potpuno bez dokumentacije. Kako možete pisati kod na stranicama — potpuno bez dokumentacije? Dodajte dokumentaciju koja objašnjava vaš kod Terraform (naglasak ovdje na riječi 'kod'), zašto je ovaj odjeljak tako važan i što radite.
Kako možete implementirati usluge koje su nekada bile jedna velika funkcija main()?
Naišla sam na vrlo složene Terraform stackove predstavljene kao jedan modul. Zašto softver ne izvodimo na taj način? Zašto razbiti velike funkcije na manje? Isti razlozi vrijede i za Terraform. Ako je vaš modul prevelik — trebate ga podijeliti na manje module.
Zar vaša tvrtka ne koristi knjižnice?
Vidjela sam kako inženjeri, pokrećući novi projekt pomoću Terraforma, jednostavno kopiraju i lijepe velike dijelove iz drugih projekata u svoje vlastite, a zatim ih uređuju dok ne počnu raditi. Da li biste vi u svojoj tvrtki radili tako s 'produkcijskim' kodom? Ne koristimo knjižnice bez razloga. Da, ali gdje bismo bili bez zajedničkih knjižnica uopće?!
Zar ne koristite PEP8 ili gofmt?
U većini jezika postoji standardna prihvaćena shema formatiranja. U Pythonu je to PEP8. U Gou — gofmt. Terraform ima svoju: terraform fmt. Koristite slobodno!
Hoćete li koristiti React, a da ne znate JavaScript?
Terraform moduli mogu pojednostaviti neki dio složene infrastrukture koju gradite, ali to ne znači da se o njoj uopće ne morate razumjeti. Želite li ispravno koristiti Terraform bez razumijevanja resursa? Odrubljujete: vrijeme će prolaziti, a vi nikada nećete savladati Terraform.
Pisnete li singleton-e ili uvodite zavisnosti?
Uvođenje zavisnosti je priznata najbolja praksa za razvoj softvera, koju preferiraju singltoni. Kako će to koristiti u Terraformu? Susretao sam Terraform module koji zavise od udaljenog stanja. Umesto da pišete module koji izvlače iz udaljenog stanja, napišite modul koji prima parametre. A zatim prenesite te parametre u modul.
Vaše biblioteke rade deset stvari dobro ili jednu — odlično?
Najbolje funkcionišu biblioteke fokusirane na jednu zadatak koju izvode odlično. Umesto da pišete velike Terraform module koji pokušavaju da rade sve odjednom, sastavite ih od delova koji dobro obavljaju nešto jedno. A zatim ih kombinujte kako treba.
Kako vršite promene u bibliotekama bez unazadne kompatibilnosti?
Opštem Terraform modu, kao i običnoj biblioteci, potrebno je nekako obavestiti korisnike o promenama bez unazadne kompatibilnosti. Kada se dogode takve promene u bibliotekama, to iritira, a isto tako iritira kada se promene bez unazadne kompatibilnosti vrše u Terraform modulima. Preporučuje se korišćenje git tagova i semver prilikom korišćenja Terraform modula.
Da li je vaš proizvodni servis pokrenut na laptopu ili u data centru?
Hashicorp ima alate poput za pokretanje vašeg terraforma. Ove centralizovane usluge olakšavaju upravljanje, reviziju i odobravanje promena terraforma.
Zar ne pišete testove?
Inženjeri priznaju da kodeks treba testirati, ali često zapostavljaju provere dok rade sa Terraformom. Za infrastrukturu to može imati ozbiljne posledice. Savetujem da "testirate" ili "pravite primere" steka koristeći module koje možete ispravno deploy-ovati za proveru tokom CI/CD.
Terraform i mikroservisi
Život i smrt kompanija koje se oslanjaju na mikroservise zavise od brzine, ažuriranja i uništavanja novih mikroserviskih radnih stekova.
Najčešći negativni aspekt povezan sa mikroservisnim arhitekturama, koji se ne može izbeći, vezan je za rad, a ne za kod. Ako percipirate Terraform samo kao način automatizacije infrastrukturnog dela mikroservisne arhitekture, lišavate se pravih prednosti ovog sistema. Sada već .
Izvor: habr.com
