Infrastruktuuri esitamine koodina korratavas tekstivormingus on lihtne parim tava süsteemide jaoks, mis ei vaja hiirtega askeldamist. Sellel praktikal on nimi - , ja siiani on selle rakendamiseks kaks populaarset tööriista, eriti AWS-is: и .
Terraformi ja CloudFormationiga kogemuste võrdlemine
Enne tulekut (Teise nimega ) Ma töötasin ja kasutas Terraformi kolm aastat. Uues kohas kasutasin ka täie jõuga Terraformi ja siis lükkas ettevõte ülemineku kõigele a la Amazon, sealhulgas CloudFormationile. Olen mõlema jaoks usinalt parimaid tavasid välja töötanud ja kasutanud mõlemat tööriista väga keerulistes, kogu organisatsiooni hõlmavates töövoogudes. Hiljem, kui kaalusin põhjalikult Terraformilt CloudFormationile ülemineku tagajärgi, veendusin, et Terraform on tõenäoliselt organisatsiooni jaoks parim valik.
Terraform jube
Beetatarkvara
Terraform pole veel isegi versiooni 1.0 välja andnud, mis on hea põhjus seda mitte kasutada. See on palju muutunud pärast seda, kui ma seda esimest korda ise proovisin, kuid siis terraform apply sageli lagunes pärast mitut värskendust või lihtsalt pärast paariaastast kasutamist. Ma ütleksin, et "praegu on kõik teisiti", aga... tundub, et kõik ütlevad seda, kas pole? On muudatusi, mis ei ühildu eelmiste versioonidega, kuigi need on asjakohased, ja tundub isegi, et ressursisalvede süntaks ja abstraktsioonid on nüüd see, mida vajame. Tundub, et pill on tõesti paremaks läinud, aga... :-0
Teisest küljest on AWS teinud tagasiühilduvuse säilitamisel head tööd. Tõenäoliselt on see tingitud sellest, et nende teenuseid testitakse sageli organisatsiooni sees põhjalikult ja alles seejärel avaldatakse need ümbernimetatuna. Nii et "nad püüdsid kõvasti" on alahinnang. API-dega tagasiühilduvuse säilitamine nii mitmekesise ja keerulise süsteemi jaoks nagu AWS on uskumatult keeruline. Igaüks, kes on pidanud haldama avalikke API-sid, mida kasutatakse nii laialdaselt kui nad on, peaksid mõistma, kui keeruline on seda nii palju aastaid teha. Kuid minu meelest pole CloudFormationi käitumine aastate jooksul kunagi muutunud.
Kohtu jalaga... see on kuul
Minu teada kustutage ressurss autsaider CloudFormationi virn teie CF-virust pole võimalik. Sama lugu on Terraformiga. See võimaldab teil olemasolevaid ressursse oma virna importida. Funktsiooni kohta võib öelda, et see on hämmastav, kuid suure võimsusega kaasneb suur vastutus. Peate lihtsalt virnale lisama ressursi ja virnaga töötades ei saa te seda ressurssi kustutada ega muuta. Ühel päeval andis see tagasilöögi. Ühel päeval Twitchis importis keegi kogemata kellegi teise AWS-i turvarühma enda Terraformi virna, ilma et ta ei teinud pahandusi. Sisestasin mitu käsku ja... turvagrupp (koos sissetuleva liiklusega) kadus.
Terraform Suurepärane
Taastumine mittetäielikest seisunditest
Mõnikord ei õnnestu CloudFormationil ühest olekust teise täielikult üle minna. Samal ajal püüab ta naasta eelmise juurde. Kahju, et see pole alati teostatav. Hiljem juhtunu silumine võib olla üsna hirmutav – kunagi ei tea, kas CloudFormation on rahul, et sellesse häkitakse – isegi selle parandamiseks. Kas eelmisse olekusse on võimalik naasta või mitte, ta tõesti ei tea, kuidas seda kindlaks teha ja vaikimisi ripub tundide kaupa, oodates imet.
Terraform seevastu kipub ebaõnnestunud üleminekutest palju elegantsemalt taastuma ja pakub täiustatud silumistööriistu.
Selgemad muudatused dokumendi olekus
„Olgu, koormuse tasakaalustaja, sa muutud. Aga kuidas?"
— murelik insener, valmis vajutama nuppu „Nõustun”.
Mõnikord pean CloudFormationi virnas koormuse tasakaalustajaga mõningaid manipuleerimisi tegema, näiteks lisama pordi numbri või muutma turvarühma. ClouFormation kuvab muudatusi halvasti. Ma kontrollin yamli faili kümme korda üle ja veendun, et ma pole midagi vajalikku kustutanud ega midagi ebavajalikku lisanud.
Terraform on selles osas palju läbipaistvam. Vahel on ta isegi liiga läbipaistev (loe: igav). Õnneks sisaldab uusim versioon täiustatud muudatuste kuvamist, et saaksite nüüd täpselt näha, mis muutub.
Paindlikkus
Kirjutage tarkvara tagurpidi.
Otse öeldes on pikaealise tarkvara kõige olulisem omadus võime kohaneda muutustega. Kirjutage mis tahes tarkvara tagurpidi. Enamasti tegin vigu, võttes kasutusele “lihtsa” teenuse ja hakates seejärel kõike ühte CloudFormationi või Terraformi virna toppima. Ja muidugi, kuid hiljem selgus, et olin kõigest valesti aru saanud ja teenus polnud tegelikult lihtne! Ja nüüd pean suure virna kuidagi väikesteks komponentideks jagama. Kui töötate teenusega CloudFormation, saab seda teha ainult olemasoleva virna uuesti loomisega ja ma ei tee seda oma andmebaasidega. Terraform seevastu võimaldas virna lahata ja arusaadavamaks väiksemateks osadeks tükeldada.
Moodulid gitis
Terraformi koodi jagamine mitme virna vahel on palju lihtsam kui CloudFormationi koodi jagamine. Terraformi abil saate oma koodi panna git-hoidlasse ja sellele juurde pääseda semantilise versioonikontrolli abil. Igaüks, kellel on juurdepääs sellele hoidlale, saab jagatud koodi uuesti kasutada. CloudFormationi vaste on S3, kuid sellel pole samu eeliseid ja pole põhjust, miks peaksime gitist S3 kasuks loobuma.
Organisatsioon kasvas ja ühiste stäkkide jagamise võimalus jõudis kriitilise piirini. Terraform muudab selle kõik lihtsaks ja loomulikuks, samas kui CloudFormation paneb teid hüppama enne, kui saate midagi sellist tööle saada.
Toimingud koodina
"Skriptime selle ja olgu."
—insener 3 aastat enne jalgratta Terraform leiutamist.
Mis puutub tarkvaraarendusse, siis Go või Java programm ei ole lihtsalt kood.
Kood koodina
Seal on ka infrastruktuur, millel see töötab.
Infrastruktuur koodina
Aga kust ta pärit on? Kuidas seda jälgida? Kus teie kood elab? Kas arendajad vajavad juurdepääsuluba?
Toimingud koodina
Tarkvaraarendajaks olemine ei tähenda ainult koodi kirjutamist.
AWS pole ainus: tõenäoliselt kasutate teisi pakkujaid. SignalFx, PagerDuty või Github. Võib-olla on teil jälgimiseks sisemine Jenkinsi server CI/CD jaoks või sisemine Grafana armatuurlaud. Infra kui kood valitakse erinevatel põhjustel ja igaüks on võrdselt oluline kõige tarkvaraga seonduva jaoks.
Kui ma Twitchis töötasin, kiirendasime teenuseid Amazoni segatud manustatud ja AWS-süsteemides. Lõpetasime ja toetasime paljusid mikroteenuseid, suurendades sellega tegevuskulusid. Arutelud läksid umbes nii:
- Я: Kurat, see on palju žeste ühe mikroteenuse kiirendamiseks. Pean seda prügi kasutama AWS-i konto loomiseks (me kasutasime 2 kontot mikroteenus), siis see hoiatuste seadistamiseks, see koodihoidla jaoks ja see meililoendi jaoks ja siis see...
- Plii: Skriptime selle ja olgu.
- Я: Olgu, aga skript ise muutub. Vajame viisi, kuidas kontrollida, kas kõik need sisseehitatud Amazoni vidinad on ajakohased.
- Plii: Kõlab hästi. Ja me kirjutame selle jaoks stsenaariumi.
- Я: Suurepärane! Ja tõenäoliselt peab skript ikkagi parameetrid määrama. Kas ta aktsepteerib neid?
- Plii: Las ta võtab, kuhu läheb!
- Я: protsess võib muutuda ja tagasiühilduvus kaob. Vaja on mingit semantilist versioonikontrolli.
- Plii: Suurepärane mõte!
- Я: Tööriistu saab muuta käsitsi, kasutajaliidese sees. Vajame viisi selle kontrollimiseks ja parandamiseks.
…3 aastat hiljem:
- Plii: Ja me saime terraformi.
Loo moraal on: isegi kui sa ülepeakaela kõiges Amazon, kasutate endiselt midagi, mis ei kuulu AWS-i, ja nendel teenustel on olek, mis kasutab selle oleku sünkroonimiseks konfiguratsioonikeelt.
CloudFormation lambda vs git moodulid terraform
lambda on CloudFormationi lahendus kohandatud loogikaprobleemile. Lambdaga saab või . See lähenemisviis toob kaasa täiendavaid keerukusi, mida Terraformi git-moodulite semantilises versioonis ei esine. Minu jaoks oli kõige pakilisem probleem kõigi nende kasutaja lambdade (ja need on kümned AWS-i kontod) õiguste haldamine. Teine oluline probleem oli "mis oli enne, kas kana või muna?" probleem: see oli seotud lambda koodiga. See funktsioon ise on infrastruktuur ja kood ning see ise vajab jälgimist ja värskendamist. Viimane nael kirstu oli lambda koodi muudatuste semantilise värskendamise raskus; Samuti pidime veenduma, et virna toimingud ilma otsese käsuta ei muutuks käikude vahel.
Mäletan, et kunagi tahtsin luua klassikalise koormuse tasakaalustajaga Elastic Beanstalk keskkonna jaoks Canary juurutuse. Lihtsaim oleks teha EB jaoks teine juurutamine tootmiskeskkonna kõrval, astudes sellega sammu edasi: kombineerides automaatse skaleerimise kanaari juurutusrühma juurutamise LB-ga tootmiskeskkonda. Ja kuna Terraform kasutab , nõuab see Terraformis 4 lisakoodi rida. Kui küsisin, kas CloudFormationis on võrreldavat lahendust, osutasid nad mulle tervele git-hoidlale koos juurutuskonveieri ja kõige muuga, kõike selle nimel, et vaesed 4 rida Terraformi koodi saaks teha.
See tuvastab triivi paremini
Veenduge, et tegelikkus vastab ootustele.
on koodina väga võimas operatsioonide funktsioon, kuna see aitab tagada, et tegelikkus vastab ootustele. See on saadaval nii CloudFormationi kui ka Terraformiga. Kuid tootmisvirna kasvades andis CloudFormationis triivi otsimine üha rohkem valetuvastusi.
Terraformiga on teil triivi tuvastamiseks palju täiustatud elutsükli konksud. Näiteks sisestate käsu otse ECS-i ülesande määratluses, kui soovite eirata konkreetse ülesande definitsiooni muudatusi, ignoreerimata muudatusi kogu teie ECS-i juurutuses.
CDK ja CloudFormationi tulevik
CloudFormationi on raske hallata suurtes, infrastruktuuriüleses mastaabis. Paljud neist raskustest on tunnistatud ja tööriist vajab selliseid asju , raamistik pilveinfrastruktuuri koodis määratlemiseks ja selle käitamiseks AWS CloudFormationi kaudu. Huvitav on näha, mida aws-cdk tulevik toob, kuid sellel on raske konkureerida Terraformi teiste tugevate külgedega; CloudFormationi ajakohastamiseks on vaja globaalseid muudatusi.
Et Terraform pettumust ei valmistaks
See on "infrastruktuur kui kood", mitte "tekst".
Minu esimene mulje Terraformist oli üsna halb. Ma arvan, et ma lihtsalt ei saanud lähenemisest aru. Peaaegu kõik insenerid tajuvad seda tahtmatult tekstivorminguna, mis tuleb teisendada soovitud infrastruktuuriks. ÄRA TEE SEDA NII.
Hea tarkvaraarenduse tõepõhimõtted kehtivad ka Terraformi puhul.
Olen näinud paljusid hea koodi loomise tavasid, mida Terraformis ignoreeritakse. Olete aastaid õppinud, et saada heaks programmeerijaks. Ärge loobuge sellest kogemusest lihtsalt sellepärast, et töötate Terraformiga. Hea tarkvaraarenduse tõepõhimõtted kehtivad Terraformi puhul.
Kuidas saab koodi mitte dokumenteerida?
Olen näinud tohutuid Terraformi virnasid, millel puudub igasugune dokumentatsioon. Kuidas saab lehtedele koodi kirjutada – ilma igasuguse dokumentatsioonita? Lisage dokumentatsioon, mis selgitab teie kood Terraform (rõhk sõnal "kood"), miks see jaotis nii oluline on ja mida te teete.
Kuidas saame juurutada teenuseid, mis olid kunagi üks suur põhifunktsioon?
Olen näinud väga keerulisi Terraformi virnasid, mis on esitatud ühe moodulina. Miks me ei juuruta tarkvara sel viisil? Miks jagame suured funktsioonid väiksemateks? Samad vastused kehtivad Terraformi kohta. Kui teie moodul on liiga suur, peate selle jaotama väiksemateks mooduliteks.
Kas teie ettevõte ei kasuta raamatukogusid?
Olen näinud, kuidas insenerid, kes lõid Terraformi abil uut projekti, kopeerisid rumalalt teistest projektidest tohutuid tükke enda omadesse ja seejärel nuputasid neid, kuni see tööle hakkas. Kas töötaksite oma ettevõttes võitluskoodiga niimoodi? Me ei kasuta ainult raamatukogusid. Jah, aga kus me oleme ilma ühisraamatukogudeta põhimõtteliselt?!
Kas sa ei kasuta PEP8 või gofmt?
Enamikul keeltel on standardne aktsepteeritud vormindusskeem. Pythonis on see PEP8. In Go - gofmt. Terraformil on oma: terraform fmt. Nautige seda oma tervise nimel!
Kas kasutate Reacti JavaScripti teadmata?
Terraformi moodulid võivad lihtsustada mõnda osa teie loodud keerulisest infrastruktuurist, kuid see ei tähenda, et te ei saaks sellega üldse tegeleda. Kas soovite Terraformi õigesti kasutada, ilma ressursse mõistmata? Olete hukule määratud: aeg möödub ja te ei saa kunagi Terraformi valda.
Kas kodeerite üksikute või sõltuvussüstidega?
Sõltuvussüst on tarkvaraarenduse tunnustatud parim tava ja seda eelistatakse üksikutele. Kuidas see Terraformis kasulik on? Olen näinud Terraformi mooduleid, mis sõltuvad kaugolekust. Selle asemel, et kirjutada mooduleid, mis toovad kaugoleku, kirjutage moodul, mis võtab parameetreid. Ja seejärel edastage need parameetrid moodulile.
Kas teie raamatukogud teevad kümmet asja hästi või ühte asja suurepäraselt?
Kõige paremini töötavad need raamatukogud, mis keskenduvad ühele ülesandele, millega nad väga hästi hakkama saavad. Selle asemel, et kirjutada suuri Terraformi mooduleid, mis üritavad kõike korraga teha, ehitage nendest osad, mis teevad ühte asja hästi. Ja seejärel ühendage need vastavalt vajadusele.
Kuidas teha raamatukogudes muudatusi ilma tagasiühilduvuseta?
Tavaline Terraformi moodul, nagu tavaline raamatukogu, peab kasutajaid muudatustest kuidagi teavitama, ilma et see oleks tagasiühilduv. See on tüütu, kui need muudatused toimuvad teekides, ja sama häiriv on see, kui Terraformi moodulites tehakse tagasiühilduvaid muudatusi. Terraformi moodulite kasutamisel on soovitatav kasutada git tags ja semver.
Kas teie tootmisteenus töötab teie sülearvutis või andmekeskuses?
Hashicorpil on sellised tööriistad nagu oma terraformi käivitamiseks. Need tsentraliseeritud teenused muudavad terraformi muudatuste haldamise, auditeerimise ja kinnitamise lihtsaks.
Kas sa teste ei kirjuta?
Insenerid mõistavad, et koodi tuleb testida, kuid nad ise unustavad sageli Terraformiga töötades testimise. Infrastruktuuri jaoks on see täis reetlikke hetki. Minu nõuanne on "testida" või "luua näidispakke", kasutades mooduleid, mida saab CI/CD ajal testimiseks õigesti juurutada.
Terraform ja mikroteenused
Mikroteenuste ettevõtete elu ja surm sõltuvad uute mikroteenuste tööpinkide kiirusest, innovatsioonist ja häiretest.
Kõige tavalisem mikroteenuste arhitektuuridega seotud negatiivne aspekt, mida ei saa kõrvaldada, on seotud tööga, mitte koodiga. Kui arvate, et Terraform on lihtsalt viis mikroteenuste arhitektuuri infrastruktuuri poole automatiseerimiseks, siis jääte ilma süsteemi tegelikest eelistest. Nüüd see juba on .
Allikas: www.habr.com