Reprezentácia infraštruktúry ako kódu v opakovateľnom textovom formáte je jednoduchým osvedčeným postupom pre systémy, ktoré nevyžadujú hranie sa s myšami. Táto prax má názov - a zatiaľ existujú dva populárne nástroje na jeho implementáciu, najmä v AWS: и .
Porovnanie skúseností s Terraform a CloudFormation
Pred príchodom do (Aka ) Pracoval som a používali Terraform tri roky. Na novom mieste som s vypätím všetkých síl využíval aj Terraform a následne firma presadila prechod na všetko a la Amazon, vrátane CloudFormation. Usilovne som vyvinul osvedčené postupy pre oba a oba nástroje som použil vo veľmi zložitých pracovných postupoch v rámci celej organizácie. Neskôr, po premyslenom zvážení dôsledkov migrácie z Terraformu na CloudFormation, som sa presvedčil, že Terraform je pre organizáciu pravdepodobne najlepšou voľbou.
Terraform Hrozný
Beta softvér
Terraform ešte ani nevydal verziu 1.0, čo je dobrý dôvod, prečo ju nepoužívať. Odkedy som to prvýkrát vyskúšal sám, veľa sa zmenilo, ale potom terraform apply často sa pokazil po niekoľkých aktualizáciách alebo jednoducho po niekoľkých rokoch používania. Povedal by som, že „teraz je všetko inak“, ale... to je to, čo zrejme hovorí každý, nie? Existujú zmeny, ktoré nie sú kompatibilné s predchádzajúcimi verziami, hoci sú vhodné, a dokonca sa zdá, že syntax a abstrakcie skladov zdrojov sú teraz to, čo potrebujeme. Zdá sa, že nástroj sa naozaj zlepšil, ale... :-0
Na druhej strane AWS odviedol dobrú prácu pri udržiavaní spätnej kompatibility. Je to pravdepodobne preto, že ich služby sú často dôkladne testované v rámci organizácie a až potom sú premenované zverejnené. Takže „veľmi sa snažili“ je slabé slovo. Udržiavanie spätnej kompatibility s API pre systém tak rozmanitý a zložitý ako AWS je neuveriteľne ťažké. Každý, kto musel udržiavať verejné API, ktoré sa používajú tak široko, ako sú, by mal pochopiť, aké ťažké je to robiť toľko rokov. Ale správanie CloudFormation, v mojej pamäti, sa za tie roky nikdy nezmenilo.
Zoznámte sa s nohou... je to guľka
Pokiaľ viem, vymažte zdroj outsider Zásobník CloudFormation z vášho zásobníka CF nie je možný. To isté platí pre Terraform. Umožňuje vám importovať existujúce zdroje do vášho zásobníka. Dá sa povedať, že funkcia je úžasná, no s veľkou silou prichádza aj veľká zodpovednosť. Stačí pridať zdroj do zásobníka a počas práce so zásobníkom nemôžete tento prostriedok odstrániť ani zmeniť. Jedného dňa sa to zvrtlo. Jedného dňa na Twitchi niekto omylom importoval bezpečnostnú skupinu AWS niekoho iného do ich vlastného zásobníka Terraform, pričom sa nestal žiadnym neplechom. Zadal som niekoľko príkazov a... bezpečnostná skupina (spolu s prichádzajúcou premávkou) zmizla.
Terraform Skvelé
Zotavenie z neúplných stavov
CloudFormation niekedy nedokáže úplne prejsť z jedného stavu do druhého. Zároveň sa pokúsi vrátiť k predchádzajúcemu. Škoda, že to nie je vždy možné. Odladiť to, čo sa stalo neskôr, môže byť dosť desivé – nikdy neviete, či bude CloudFormation rád, že je hacknutý – aj keď to len opravíte. Či bude alebo nebude možné vrátiť sa do predchádzajúceho stavu, naozaj nevie určiť a štandardne visí celé hodiny a čaká na zázrak.
Na druhej strane Terraform má tendenciu zotavovať sa z neúspešných prechodov oveľa elegantnejšie a ponúka pokročilé nástroje na ladenie.
Jasnejšie zmeny stavu dokumentu
"Dobre, vyrovnávač zaťaženia, meníš sa." Ale ako?"
—nepokojný inžinier pripravený stlačiť tlačidlo „prijať“.
Niekedy potrebujem vykonať nejaké manipulácie s vyrovnávačom zaťaženia v zásobníku CloudFormation, ako je pridanie čísla portu alebo zmena skupiny zabezpečenia. ClouFormation zobrazuje zmeny zle. Ja na špendlíkoch desaťkrát dvakrát skontrolujem yaml súbor, aby som sa uistil, že som nevymazal nič potrebné a nepridal nič zbytočné.
Terraform je v tomto smere oveľa transparentnejší. Niekedy je až príliš priehľadný (čítaj: nudný). Našťastie posledná verzia obsahuje vylepšené zobrazenie zmien, takže teraz presne vidíte, čo sa mení.
flexibilita
Napíšte softvér spätne.
Aby sme to povedali na rovinu, najdôležitejšou vlastnosťou softvéru s dlhou životnosťou je schopnosť prispôsobiť sa zmenám. Napíšte akýkoľvek softvér spätne. Najčastejšie som robil chyby tým, že som si vzal „jednoduchú“ službu a potom som začal všetko vtesnať do jedného zásobníka CloudFormation alebo Terraform. A samozrejme, o mesiace neskôr sa ukázalo, že som všetko pochopil zle a služba v skutočnosti nebola jednoduchá! A teraz potrebujem nejakým spôsobom rozdeliť veľký zásobník na malé komponenty. Keď pracujete s CloudFormation, dá sa to urobiť len tak, že najprv znova vytvoríte existujúci zásobník a ja to nerobím so svojimi databázami. Terraform na druhej strane umožnil rozkúskovať stoh a rozložiť ho na zrozumiteľnejšie menšie časti.
Moduly v git
Zdieľanie kódu Terraform vo viacerých zásobníkoch je oveľa jednoduchšie ako zdieľanie kódu CloudFormation. S Terraformom môžete umiestniť svoj kód do úložiska git a získať k nemu prístup pomocou sémantického riadenia verzií. Ktokoľvek s prístupom k tomuto úložisku môže znova použiť zdieľaný kód. Ekvivalentom CloudFormation je S3, ale nemá rovnaké výhody a nie je dôvod, prečo by sme mali opustiť git v prospech S3.
Organizácia rástla a schopnosť zdieľať spoločné zásobníky dosiahla kritickú úroveň. Vďaka Terraform je to všetko jednoduché a prirodzené, zatiaľ čo CloudFormation vás prinúti skákať cez obruče skôr, ako sa vám niečo také podarí.
Operácie ako kód
"Napíšme to a dobre."
—inžinier 3 roky pred vynájdením bicykla Terraform.
Pokiaľ ide o vývoj softvéru, Go alebo Java program nie je len kód.
Kód ako kód
Je tam aj infraštruktúra, na ktorej to funguje.
Infraštruktúra ako kód
Ale odkiaľ je? Ako to sledovať? Kde sa nachádza váš kód? Potrebujú vývojári povolenie na prístup?
Operácie ako kód
Byť vývojárom softvéru neznamená len písať kód.
AWS nie je jediný: pravdepodobne používate iných poskytovateľov. SignalFx, PagerDuty alebo Github. Možno máte interný server Jenkins pre CI/CD alebo interný dashboard Grafana na monitorovanie. Infra ako kód sa vyberá z rôznych dôvodov a každý z nich je rovnako dôležitý pre všetko, čo súvisí so softvérom.
Keď som pracoval v Twitchi, zrýchlili sme služby v rámci zmiešaných vstavaných a AWS systémov Amazonu. Vychrlili a podporili sme mnohé mikroslužby, čím sme zvýšili prevádzkové náklady. Diskusie prebiehali asi takto:
- Я: Sakra, to je veľa gest na pretaktovanie jednej mikroslužby. Budem musieť použiť tento odpad na vytvorenie účtu AWS (prešli sme na 2 účty mikroservis), potom toto na nastavenie upozornení, toto na úložisko kódov a toto na zoznam e-mailov a potom toto...
- Viesť: Poďme to napísať a dobre.
- Я: Dobre, ale zmení sa samotný scenár. Budeme potrebovať spôsob, ako skontrolovať, či sú všetky tieto vstavané veci z Amazonu aktuálne.
- Viesť: Znie to dobre. A napíšeme na to scenár.
- Я: Skvelé! A skript bude pravdepodobne musieť ešte nastaviť parametre. Prijme ich?
- Viesť: Nech ide, kam ide!
- Я: Proces sa môže zmeniť a spätná kompatibilita sa stratí. Bude potrebný určitý druh sémantickej kontroly verzií.
- Viesť: Výborný nápad!
- Я: Nástroje je možné zmeniť manuálne v používateľskom rozhraní. Potrebujeme spôsob, ako to skontrolovať a opraviť.
…o 3 roky neskôr:
- Viesť: A máme terraform.
Morálka príbehu je: aj keď vy bezhlavo vo všetkom Amazone, stále používate niečo, čo nie je od AWS, a tieto služby majú stav, ktorý používa konfiguračný jazyk na udržanie tohto stavu v synchronizácii.
CloudFormation lambda vs git moduly terraform
lambda je riešenie problému vlastnej logiky od CloudFormation. S lambdou môžete alebo . Tento prístup prináša ďalšie zložitosti, ktoré nie sú prítomné v sémantickom verzovaní modulov git Terraform. Najpálčivejším problémom pre mňa bola správa povolení pre všetky tieto používateľské lambdy (a to sú desiatky účtov AWS). Ďalším dôležitým problémom bol problém „čo bolo skôr, kura alebo vajce?“: súvisel s kódom lambda. Táto funkcia sama o sebe je infraštruktúra a kód a samotná potrebuje monitorovanie a aktualizácie. Posledným klincom do rakvy bol problém sémanticky aktualizovať zmeny kódu lambda; museli sme tiež zabezpečiť, aby sa akcie zásobníka bez priameho príkazu medzi jednotlivými behmi nezmenili.
Pamätám si, ako som raz chcel vytvoriť kanárske nasadenie pre prostredie Elastic Beanstalk s klasickým load balancerom. Najjednoduchšie by bolo urobiť druhé nasadenie pre EB vedľa produkčného prostredia, čím by sme sa posunuli o krok ďalej: skombinovaním skupiny nasadenia s automatickým škálovaním a nasadením LB do produkčného prostredia. A keďže Terraform používa , bude to vyžadovať 4 ďalšie riadky kódu v Terraforme. Keď som sa spýtal, či existuje porovnateľné riešenie v CloudFormation, poukázali ma na celé úložisko git s potrubím nasadenia a všetkým, všetko kvôli niečomu, čo by mohli urobiť úbohé 4 riadky kódu Terraform.
Lepšie detekuje drift
Uistite sa, že realita zodpovedá očakávaniam.
je veľmi výkonná operácia ako funkcia kódu, pretože pomáha zabezpečiť, aby realita zodpovedala očakávaniam. Je k dispozícii s CloudFormation a Terraform. Ale ako produkčný zásobník rástol, hľadanie driftu v CloudFormation produkovalo stále viac a viac falošných detekcií.
S Terraform máte oveľa pokročilejšie háky životného cyklu na detekciu posunu. Napríklad zadáte príkaz priamo v definícii úlohy ECS, ak chcete ignorovať zmeny v definícii konkrétnej úlohy bez toho, aby ste ignorovali zmeny v celom vašom nasadení ECS.
CDK a budúcnosť CloudFormation
CloudFormation je ťažké spravovať vo veľkých mierkach naprieč infraštruktúrou. Mnohé z týchto ťažkostí sú rozpoznané a nástroj potrebuje veci ako , rámec na definovanie cloudovej infraštruktúry v kóde a jej spustenie prostredníctvom AWS CloudFormation. Bude zaujímavé vidieť, čo prinesie budúcnosť aws-cdk, ale bude mať ťažké konkurovať ostatným silným stránkam Terraformu; na aktualizáciu CloudFormation budú potrebné globálne zmeny.
Aby Terraform nesklamal
Toto je „infraštruktúra ako kód“ a nie „ako text“.
Môj prvý dojem z Terraform bol dosť zlý. Myslím, že som len nepochopil prístup. Takmer všetci inžinieri ho mimovoľne vnímajú ako textový formát, ktorý je potrebné previesť na požadovanú infraštruktúru. NEROBTE TO TAKTO.
Zásady dobrého vývoja softvéru platia aj pre Terraform.
Videl som veľa praktík prijatých na vytvorenie dobrého kódu, ktoré boli v Terraforme ignorované. Roky ste študovali, aby ste sa stali dobrým programátorom. Nevzdávajte sa tejto skúsenosti len preto, že pracujete s Terraformom. Pre Terraform platia zásady dobrého vývoja softvéru.
Ako nie je možné zdokumentovať kód?
Videl som obrovské hromádky Terraformu s absolútne žiadnou dokumentáciou. Ako môžete napísať kód na stránky - úplne bez dokumentácie? Pridajte dokumentáciu, ktorá vysvetľuje vaše kód Terraform (dôraz na slovo „kód“), prečo je táto sekcia taká dôležitá a čo robíte.
Ako môžeme nasadiť služby, ktoré boli kedysi jednou veľkou funkciou main()?
Videl som veľmi zložité zásobníky Terraform prezentované ako jeden modul. Prečo nenasadíme softvér týmto spôsobom? Prečo delíme veľké funkcie na menšie? Rovnaké odpovede platia aj pre Terraform. Ak je váš modul príliš veľký, musíte ho rozdeliť na menšie moduly.
Nevyužíva vaša spoločnosť knižnice?
Videl som, ako inžinieri, ktorí vytvorili nový projekt pomocou Terraformu, hlúpo skopírovali obrovské kusy z iných projektov do svojich vlastných a potom sa s nimi hrali, kým to nezačalo fungovať. Pracovali by ste takto s „bojovým“ kódom vo vašej firme? Nepoužívame len knižnice. Áno, ale kde sme v zásade bez zdieľaných knižníc?!
Nepoužívaš PEP8 alebo gofmt?
Väčšina jazykov má štandardnú akceptovanú schému formátovania. V Pythone je to PEP8. V Go - gofmt. Terraform má svoje vlastné: terraform fmt. Užite si to pre svoje zdravie!
Budete používať React bez znalosti JavaScriptu?
Moduly Terraform môžu zjednodušiť niektoré časti komplexnej infraštruktúry, ktorú vytvoríte, ale to neznamená, že sa s tým nemôžete vôbec pohrať. Chcete správne používať Terraform bez toho, aby ste rozumeli zdrojom? Ste odsúdení na zánik: čas uplynie a nikdy nezvládnete Terraform.
Kódujete singletony alebo injekciu závislosti?
Injekcia závislosti je uznávaným osvedčeným postupom pre vývoj softvéru a uprednostňuje sa pred singletonmi. Ako je to užitočné v Terraforme? Videl som moduly Terraform, ktoré závisia od vzdialeného stavu. Namiesto zapisovania modulov, ktoré získavajú vzdialený stav, napíšte modul, ktorý preberá parametre. A potom odovzdajte tieto parametre modulu.
Robia vaše knižnice desať vecí dobre alebo jednu skvelú?
Najlepšie fungujú knižnice, ktoré sa zameriavajú na jednu úlohu, ktorú robia veľmi dobre. Namiesto písania veľkých modulov Terraform, ktoré sa snažia robiť všetko naraz, postavte z nich časti, ktoré robia jednu vec dobre. A potom ich podľa potreby kombinujte.
Ako vykonáte zmeny v knižniciach bez spätnej kompatibility?
Bežný modul Terraform, ako bežná knižnica, potrebuje nejakým spôsobom komunikovať zmeny s používateľmi bez toho, aby bol spätne kompatibilný. Je nepríjemné, keď sa tieto zmeny dejú v knižniciach, a rovnako nepríjemné je, keď sa v moduloch Terraform vykonajú zmeny, ktoré nie sú spätne kompatibilné. Pri používaní modulov Terraform sa odporúča používať značky git a semver.
Funguje vaša produkčná služba na vašom notebooku alebo v dátovom centre?
Hashicorp má nástroje ako spustiť svoj terraform. Tieto centralizované služby uľahčujú správu, audit a schvaľovanie zmien v terraforme.
Nepíšeš testy?
Inžinieri uznávajú, že kód treba testovať, no sami na testovanie pri práci s Terraformom často zabúdajú. Pre infraštruktúru je to plné zradných momentov. Moja rada je „testovať“ alebo „vytvárať vzorové“ zásobníky pomocou modulov, ktoré možno správne nasadiť na testovanie počas CI/CD.
Terraform a mikroslužby
Život a smrť spoločností poskytujúcich mikroslužby závisí od rýchlosti, inovácie a narušenia nových pracovných skupín mikroslužieb.
Najbežnejší negatívny aspekt spojený s architektúrami mikroslužieb, ktorý nemožno odstrániť, súvisí s prácou, nie s kódom. Ak si myslíte, že Terraform je len spôsob, ako automatizovať iba infraštruktúrnu stránku architektúry mikroslužieb, potom prichádzate o skutočné výhody systému. Teraz už je .
Zdroj: hab.com