Läksin Terraformilt CloudFormationile — ja kahetsen seda.

Infrastruktuuri esitamine koodina korduvates tekstivormingutes on parim tava süsteemide jaoks, millega ei pea vaeva nägema. Selle praktika nimeks on Infrastruktuur kui kood, ja seni on selle rakendamiseks, eriti AWS-is, kaks populaarset tööriista: Terraform ja CloudFormation.

Võrdlen oma kogemusi Terraformi ja CloudFormationiga

Enne kui tulin Twitch (samuti Amazon Jr.) töötasin ühes idufirmas ja kolm aastat kasutasin Terraformi. Uues kohas kasutasin samuti Terraformi, kuid siis sai ettevõte läbiviidud üle kõik a'la Amazonisse, sealhulgas CloudFormationi. Töötasin kõvasti parimate praktikate väljatöötamise nimel mõlemal, ja kasutasin mõlemat tööriista väga keerulistes protsessides organisatsiooni mastaabis. Hiljem, kaaludes mõjusid üleminekust Terraformilt CloudFormationile, olin ma veendunud, et Terraform on tõenäoliselt parim valik organisatsiooni jaoks.

Terraform Kohutav

Beta versioon

Terraformil pole veel isegi versiooni 1.0, ja see on tugev põhjus seda mitte kasutada. Alates hetkest, kui ma esimese korda seda proovisin, on see palju muutunud, kuid sel ajal terraform apply saged korduvalt katkenud pärast mitmeid uuendusi või lihtsalt paar aastat kasutamist. Ma ütleksin, et "nüüd on kõik teisiti", aga... nii räägivad ju kõik, eks? On muudatusi, mis ei ühti varasemate versioonidega, kuid need on vajalikud, ja isegi tunne on nagu sünteesis ja ressursside abstraktsioonides on nüüd asi paika pandud. Tööriist tundub tõesti paremaks muutunud, aga... :-0

Teiselt poolt on AWS tublisti vaeva näinud, et säilitada ühilduvus varasemate versioonidega. Kõik ilmselt seetõttu, et nende teenuseid testitakse sageli korralikult organisatsiooni sees ja alles siis, kui nad on need ümber nimetanud, avaldatakse. Nii et 'hästi on vaeva nähtud' on veel pehme ütlemine. Ühilduvuse säilitamine varasemate versioonidega API jaoks nii mitme variandi ja keerulise süsteemi, nagu AWS, puhul on uskumatult keeruline. Igaüks, kellel on tulnud säilitada avalikku API-d, mida kasutatakse sama laialdaselt, peaks mõistma, kui raske on seda teha nii kaua. Aga CloudFormationi käitumine ei ole minu mäletamise järgi mitte kordagi aastate jooksul muutunud.

Tutvu, jalg... see on kuuli

Nii palju kui ma tean, on ressursi eemaldamine võõras CloudFormationi stack'ist ei ole võimalik oma CF stack'i. Samuti on asjad samamoodi Terraformiga. See võimaldab olemasolevaid ressursse oma stack'i importida. Üks funktsioon, mida võib öelda, et on hämmastav, kuid suurt jõudu toob endaga kaasa ka suur vastutus. Alles jääb ainult salvestada ressursi stack'i ja samal ajal, kui töötad oma stack'iga, ei saa seda ressurssi kustutada ega muuta. Üks kord tuli see kätte. Kord Twitchi lehe peal keegi, mitte midagi halba mõeldes, importis kogemata kellegi AWS turvagruppi oma Terraformi stack'i. Sisestas mitu käsku ja… turvagrupp (koos sissetuleva liiklusega) kadus.

Terraform Suur

Taastamine puudulikest olekutest

Mõnikord ei saa CloudFormation täielikult ühelt olekult teisele üle minna. Sel juhul püüab ta naasta eelmisest. Kahju, et see ei ole alati võimalik. Hiljem on see, mis saadakse, hirmutav — kunagi ei tea, kas CloudFormation on õnnelik, et teda hackitakse — olgu see parandamiseks. Ja kas on võimalik tagasi minna eelnevale olekule, ei oska ta korralikult määratleda ning vaikimisi ripub ta tunde, oodates imet.

Terraform on seevastu, et taastuda ebaõnnestunud üleminekest elegantselt ning pakub laiemat tõrkeotsingu tööriistade komplekti.

Selgemad muudatused dokumendi staatustes

„Okei, koormuse tasakaalustaja, sa muutud. Kuidas?”

—murelik insener, kes on valmis nupule „aktsepteeri” vajutama.

Mõnikord pean ma CloudFormationi virnas koormuse tasakaalustajaga mõned manipulatsioonid tegema — näiteks lisama pordinumbri või muutma turgruppe. CloudFormationi muudatused on nõrgalt kajastatud. Olen nagu nõeltele, kontrollin kümme korda yaml-faili, et veenduda, et ma ei ole midagi vajalikku ära kustutanud ega midagi liigset lisanud.

Terraform on siin palju läbipaistvam. Mõnikord on ta isegi liiga läbipaistev (loe: tüütu). Õnneks on viimasest versioonist kaasatud parendatud muudatuste kuvamine — nüüd on selge, mis muutub.

Paindlikkus

Kirjutage tarkvara tagurpidi.

Otse öeldes on pikaealise tarkvara kõige olulisem eripära selle kohanemisvõime muutustega. Kirjutage igasugune tarkvara tagurpidi. Minu kogemus näitab, et olen sageli eksinud, valides 'lihtsa' teenuse ja seejärel püüdnud seda kuidagi mahutada ühte CloudFormation'i või Terraform'i kuhja. Ja muidugi, pärast kuude möödumist selgus, et ma pole kõik õigesti mõistnud ja teenus ei olnudki tegelikult lihtne! Nüüd on mul vaja mõnel viisil suur kuhja väikesteks osadeks jagada. CloudFormation'i puhul on see võimalik vaid siis, kui eelnevalt taaskonserveerite olemasoleva kuhja ning seda ma oma andmebaasidega ei tee. Terraform seevastu võimaldas kuhja lahata ja jagada seda arusaadavamateks väiksemateks osadeks.

Modulid git'is

Terraform'i koodi jagamine mitme kuhjaga on palju lihtsam kui CloudFormation'i koodi jagamine. Terraform'i abil saab koodi paigutada git'i repositoriumisse ja sellele viidata, kasutades semantilist versioonikontrolli. Igaühel, kellel on juurdepääs sellele repositoriumile, on võimalik jagatud koodi uuesti kasutada. CloudFormation'i ekvivalent on S3, kuid sellel ei ole samu eeliseid ja pole mingit põhjust, miks peaksime git'ist loobuma S3 kasuks.

Organisatsioon kasvas ja võime jagada ühiseid tehnoloogiaid jõudis kriitilisse tasemesse. Terraformiga on see kõik lihtne ja loomulik, samas kui CloudFormation paneb teid hüppama läbi rinngate, enne kui midagi sarnast tööle hakkab.

Operations as code

"Kripteerime ja ongi kõik."

— insener kolm aastat enne, kui ta Terraformi jalgratta leiutas.

Kui jutt on tarkvaraarendusest, ei ole Go või Java programm lihtsalt kood.

Code as Code

Siin on veel infrastruktuur, mille peal see töötab.

Infrastruktuur kui kood

Aga kust see seal on? Kuidas seda jälgida? Kus elab teie kood? Kas arendajatel on juurdepääsu lubamine vajalik?

Operations as Code

Olles tarkvaraarendaja, ei tähenda see lihtsalt koodi kirjutamist.

Ainult AWS ei piira: te kasutate tõenäoliselt ka teiste teenusepakkujate teenuseid. SignalFx, PagerDuty või GitHub. Võib-olla on teil CI/CD jaoks sisemine Jenkins server või sisemine Grafana juhtpaneel jälgimiseks. Infra as Code valitakse erinevatel põhjustel, ja igaühel on sama tähtsus tarkvaraga seotud asjade jaoks.

Kui ma töötasin Twitchis, kiirendasime teenuseid segatud integreeritud süsteemides ja AWS Amazon’i süsteemides. Me lõime ja säilitasime hulgaliselt mikroteenuseid, suurendades opereerimiskulusid. Vestlused käisid umbes sellises vaimus:

• Mina: Oh, liiga palju liigutusi ühe mikroteenuse käivitamiseks. Mul on vaja selle asja kaudu AWS kontot luua (me liikusime kahe konto suunas mikroteenus), seejärel selle kaudu häirete seadistamiseks, veel selle kaudu koodirepositooriumiks, ja selle kaudu e-posti aadresside nimekirja, ja veel selle…
• Juht: Skripteerime ja olgu.
• Mina: Hea küll, aga skript peab muutuma. Vaja on viisi, kuidas kontrollida, et kõik need Amazon’i integreeritud asjad on ajakohases seisundis.
• Juht: Tundub hea. Ja selle jaoks kirjutame skripti.
• Mina: Suurepärane! Kas skript vajab tõenäoliselt veel parameetreid? Kas ta võtab need vastu?
• Juht: Jah, võtab, kuhu ta sellest escaping läheb!
• Mina: Protsess võib muutuda, tagasiside ühilduvus võib kaduda. Vaja on mingit semantilist versioonikontrolli.
• Juht: Suurepärane idee!
• Mina: Tööriistad saab muuta käsitsi kasutajaliideses. Me vajame viisi, kuidas seda kontrollida ja parandada.

…3 aastat hiljem:

• Juht: Ja meil on terraform.

Muinasjutu moraal on selline: isegi kui oled kuni kõrvad amazon’likus maailmas,, kasutad sa ikkagi midagi, mis ei ole AWS-i toode, ja nendel teenustel on olek, mis kasutab keelt selle oleku sünkroniseerimiseks.

CloudFormation lambda vs git-moduulid terraform

lambda on CloudFormation lahendus kasutaja loogika probleemile. Lambda abil on võimalik luua makrosid või kasutajaressurssi. Selline lähenemine toob kaasa täiendavaid keerukusi, mida pole Terraformi git'i moodulite semantilise versioonihalduse puhul. Minu jaoks on kõige aktuaalsem probleem olnud nende kasutaja lambda-de õiguste haldamine (neid on kümneid AWS-i kontosid). Teiseks oluliseks küsimuseks kujunes «mis oli enne — kana või muna?»: see oli seotud lambda koodiga. See funktsioon on infrastruktuur ja kood, ning vajab samuti jälgimist ja uuendusi. Viimaseks mõõgaks on saanud koodi lambda semantilise uuendamise raskus; samuti pidi olema tagatud, et stacki toimingud ei muutuks käivituste vahel ilma otsese käsuta.

Mäletan, kuidas mul tekkis soov luua kanarialennukeid Elastic Beanstalk keskkonna jaoks klassikalise koormuse tasakaalustajaga. Lihtsaim oleks olnud teha teine juurutamine EB kõrval tootmiskeskkonna jaoks, tehes veel ühe sammu: ühendades automaatselt skaleeritava kanarideploy grupi tasuta juurutamisega tootmiskeskkonna koormuse tasakaalustaja. Ja kuna Terraform kasutab ASG-beantalk kui väljund, see nõuab Terraformis 4 lisarealise koodi kirjutamist. Kui ma küsisin, kas CloudFormationis on sarnane lahendus, viidati mulle tervele git-repositooriumile, mis sisaldab juurutuskanalit ja muud: ja kõik see, et teha õnnetud 4 rida Terraformi koodi.

Ta tuvastab paremini triivi.

Veenduge, et tegelikkus vastab ootustele.

Triivi tuvastamine — väga võimas operations as code funktsioon, kuna see aitab veenduda, et tegelikkus vastab ootustele. See on saadaval nii CloudFormationis kui ka Terraformis. Kuid töölaudade suurenedes annab CloudFormation triivi otsimisel järjest rohkem valepositiive.

Terraformiga on teil palju täiustatud elutsükli harju triivi tuvastamiseks. Näiteks sisestate käsu ignore_changes otse ECS-i ülesande määratlusesse, kui soovite ignoreerida muudatusi konkreetse ülesande määratluses, jättes samas tähelepanuta muudatused kogu ECS-i juurutuses.

CDK ja CloudFormatsiooni tulevik

CloudFormationi haldamine suurtes, infrastruktuuridevaheline ulatus on keeruline. Paljusid neist raskustest on tunnustatud ja tööriist vajab selliseid asju nagu aws-cdk, struktuur pilveinfrastruktuuri määratlemiseks koodis ja selle rakendamiseks AWS CloudFormationis. Huvitav on vaadata, mis ootab aws-cdk tulevikus, kuid tal on keeruline konkureerida Terraformi teiste eelistega; CloudFormationi tõukamiseks on vaja globaalseid muudatusi.

Et Terraform ei pettuks

See on ju 'infrastruktuur kui KOOD', mitte 'kui tekst'.

Minu esimene mulje Terraformist oli üsna halb. Arvan, et ma lihtsalt ei saanud lähenemisest aru. Peaaegu kõik insenerid tajuvad seda esialgu tahtmatult teksti formaatena, mille tuleb muuta soovitud infrastruktuuriks. SELLEKS EI TOHI KUNAGI NII OLLA.

Koodiarenduse head tavad kehtivad ka Terraformi kohta

Olen näinud, kuidas paljusid tavasid, mida kasutatakse hea koodi loomisel, ignoteeritakse Terraformis. Olete aastate jooksul õppinud, et saada heaks programmeerijaks. Ärge loobuge sellest kogemusest lihtsalt seetõttu, et töötate Terraformiga. Koodiarenduse head tavad kehtivad ka Terraformi kohta.

Kuidas saab koodi ja mitte dokumenteerida?

Mulle on ette tulnud hiiglaslikke Terraform steke, millel ei ole mingit dokumentatsiooni. Kuidas on võimalik kirjutada koode lehekülgedena — täiesti ilma dokumentatsioonita? Lisage dokumentatsioon, mis selgitab teie kood Terraform (rõhk sõnal "kood"), miks on see jaotis nii oluline ja mida teete.

Kuidas on võimalik arendada teenuseid, mis olid kunagi üks suur main() funktsioon?

Olen kohanud väga keerulisi Terraform steke, mis on esitatud ühtse moodulina. Miks me ei arenda tarkvara nii? Miks me jagame suuri funktsioone väiksemateks? Need samad vastused kehtivad ka Terraformi puhul. Kui moodul on liiga suur, tuleb see jagada väiksemateks mooduliteks.

Kas teie ettevõte ei kasuta raamatukogusid?

Olen näinud, kuidas insenerid, arendades uut projekti Terraformi abil, kopeerisid suurtes kogustes koodi teistest projektidest oma töödesse ning siis nokkisid neid, kuni need hakkasid toimima. Kas teie ettevõttes töötaksite selliselt "tootmis" koodiga? Me ei kasuta raamatukogusid lihtsalt niisama. Jah, mitte kõik ei pea olema raamatukogu, aga kuhu me ilma üldiste raamatukogudeta üldse jääme?!

Kas te ei kasuta PEP8 või gofmt?

Enamikus keeltes on standardne vastuvõetud vormindus. Pythonis on see PEP8. Go puhul on see gofmt. Terraformil on oma: terraform fmt. Kasutage vabalt!

Kas hakkate Reacti kasutama, teadmata JavaScripti?

Terraformi moodulid võivad lihtsustada teatud osa teie loodud keerulisest infrastruktuurist, kuid see ei tähenda, et te ei peaks sellest üldse aru saama. Kas soovite kasutada Terraformi õigesti ilma ressurssidest arusaamiseta? Olete hukule määratud: aeg möödub, aga te ei õpigi Terraformi selgeks.

Kas kodeerite singletoone või rakendate sõltuvusi?

Sõltuvuste rakendamine on tunnustatud parim praktika tarkvaraarenduses, mida eelistatakse singletoonide puhul. Kuidas see Terraformis kasuks tuleb? Olen kohanud Terraformi mooduleid, mis sõltuvad kaugest olekust. Selle asemel, et kirjutada mooduleid, mis võetakse kaugest olekust, kirjutage moodul, mis võtab parameetreid. Ja seejärel edastage need parameetrid moodulisse.

Kas teie raamatukogud teevad kümmet asja hästi või ühte — suurepäraselt?

Parimad raamatukogud töötavad tõhusalt ühel konkreetsel ülesandel. Selle asemel, et kirjutada suuri Terraform mooduleid, mis üritavad teha kõike korraga, koostage komponendid, mis teevad midagi üksikuna hästi. Seejärel saate neid vajaduse järgi omavahel kombineerida.

Kuidas te muudate raamatukogusid ilma tagasipöördumise ühilduvust säilitamata?

Üldine Terraform moodul, nagu ka tavaline raamatukogu, peab leidma viisi, kuidas kasutajatele teatada tagasipöördumise ühilduvuse muutustest. Kui raamatukogudes toimuvad sellised muutused, on see häiriv, ja sama häiriv on, kui Terraform moodulites tehakse muutusi, mis ei ole ühilduvad. Soovitav on kasutada git siltide ja semver'i rakendamist Terraform moodulite puhul.

Kas teie tooteteenus töötab sülearvutis või andmekeskuses?

Hashicorp'il on sellised tööriistad nagu terraform cloud , et käivitada teie terraform. Need tsentraliseeritud teenused lihtsustavad terraformi haldamist, auditit ja muudatuste kinnitamist.

Kas te siis tõesti ei kirjuta teste?

Insenerid tunnistavad, et koodi tuleb testida, kuid sageli unustavad nad ise kontrollida, töötades Terraformi abil. Infrastruktuuri jaoks on see salakaval. Soovitan "testida" või "luua näiteid" steke, kasutades mooduleid, mida saab õigesti juurutada kontrollimiseks CI/CD ajal.

Terraform ja mikroteenused

Mikroteenusettevõtete elu ja surm sõltub kiirusest, uuendamisest ja uute mikroteenuste töösteekide hävitamisest.

Kõige levinum negatiivne aspekt, mis on seotud mikroteenuse arhitektuuridega ja millest ei saa lahti, puudutab tööd, mitte koodi. Kui vaadata Terraformi ainult kui viisi automatiseerida ainult mikroteenuse arhitektuuri infrastruktuuri külge, siis jätate end ilma tõelistest süsteemi eelistest. Praegu on juba kõik — kui kood.

Allikas: habr.com