Esitus infrastruktuurist koodina korduvates tekstivormingutes on lihtne parim praktika süsteemidele, millega ei ole vaja jännata. Selle praktika nimi on , ja senini on selle rakendamiseks, eriti AWS-is, kaks populaarset tööriista: ja .
Võrdlen oma kogemust Terraformi ja CloudFormationiga
Enne, kui ma tulin (nimetatud ka ) töötasin ja kasutasin Terraformi umbes kolm aastat. Uues kohas kasutasin ma samuti aktiivselt Terraformi, kuid siis nõudis ettevõte üleminekut täielikult Amazonile, sealhulgas CloudFormationile. Töötasin kõvasti välja parimaid praktikaid mõlema jaoks, kasutades neid kahte tööriista väga keerulistes organisatsioonilistes tööprotsessides. Hiljem, pärast ülemineku mõju hoolikat kaalumist Terraformilt CloudFormationile, jõudsin järeldusele, et Terraform on ilmselt parim valik organisatsioonile.
Terraform On Kohutav
Tarkvara beetaversioon
Terraformi 1.0 versioon pole veel välja antud, mis on kaalukas põhjus, miks seda mitte kasutada. Alates esimesest proovimisest on see palju muutunud, kuid tookord terraform apply purunes see sageli pärast mõningaid uuendusi või lihtsalt paari aasta pärast kasutamist. Ütleksin, et "praegu on kõik teisiti", kuid... nii räägivad kõik, eks? On muudatusi, mis pole ühilduvad varasemate versioonidega, kuigi need on asjakohased, ja isegi on tunne, et süntaks ja ressursside salvestuste abstraktsioonid on nüüd õiged. Tööriist on tundunud tõeliselt parem, kuid… :-0
Teisest küljest on AWS teinud head tööd, toetades ühilduvust varasemate versioonidega. Kõik ilmselt selle tõttu, et nende teenuseid testitakse sageli korralikult organisatsiooni sees ja seejärel ümbernimetamisega avaldatakse. Seega on "teinud head tööd" veel nõrk väljend. Ühilduvuse säilitamine varasemate API versioonidega nii mitmekesises ja keerulises süsteemis nagu AWS on äärmiselt raske. Igaüks, kes on pidanud toetama avalikke API-sid, mida kasutatakse nii laialdaselt, peaks mõistma, kui raske on seda teha nii kaua. Kuid CloudFormationi käitumine ei ole minu mäletamist mööda aastatega kunagi muutunud.
Tere, jalg… see on kuul
Nii palju kui mina tean, pole võimalik kustutada ressursi välise CloudFormationi oma CF-steki kaudu ei ole võimalik. Sarnane olukord on ka Terraformiga. See võimaldab olemasolevaid ressursse oma steki importida. See funktsioon on tõeliselt muljetavaldav, kuid koos suure jõu ja vastutusega tuleb. Tuleb ainult ressurss steki lisada ja nii kaua kui töötad oma stekiga, ei saa seda ressursse kustutada ega muuta. Ükskord juhtus nii. Kord Twitchi saidil importis keegi, ilma halba kavatsedes, kogemata kellegi AWS turvagruppi oma Terraformi steki. Sisestas paar käsku ja... turvagrupp (koos siseneva liiklusega) kadus.
Terraform Suur
Taastereeglid mittetäielikest seisunditest
Mõnikord ei suuda CloudFormation täielikult ühest olekust teise liikuda. Sel juhul püüab ta tagasi naasta eelmisse. Kahjuks ei ole see alati teostatav. Hiljem on tulemuse tõrgete parandamine pisut hirmutav — kunagi ei tea, kas CloudFormation rõõmustab selle üle, et teda rikutakse — isegi kui selle eesmärk on parandamine. Ja ei suuda ta pealegi kindlasti öelda, kas eelmisse olekusse tagasi saamine õnnestub või mitte, ja vaikimisi jääb ta tundide kaupa ootama imet.
Terraform seevastu on pärast ebaõnnestunud üleminekuid taastumisel elegantsem ja pakub laiendatud tõrkeotsingu tööriistu.
Selgemad muudatused dokumendi seisundites
„Olgu, koormuse tasakaalustaja, sa muudad. Aga kuidas?”
— murelik insener, kes on valmis „aktsepteerima” nuppu vajutama.
Mõnikord pean CloudFormationi stekis koormuse tasakaalustajaga teatud manipuleerimisi tegema — näiteks porti numbri lisama või turvagruppi muutma. CloudFormationi muudatused kajastuvad kehvasti. Mina aga, nagu nõeltekste, kontrollin kümme korda YAML-faili, et veenduda, et ei ole midagi vajalikku kustutanud ega liigset lisanud.
Terraform on selles osas palju läbipaistvam. Mõnikord on ta isegi liiga läbipaistev (loe: tüütab). Õnneks sisaldab viimane versioon parendatud muudatuste kuvamist — nüüd on täpselt näha, mis muutub.
Paindlikkus
Kirjutage tarkvara tagurpidi.
Otse rääkides, pikaajalise tarkvara kõige olulisem tunnusjoon on võime kohanduda muutustega. Iga tarkvara tuleks kirjutada tagurpidi. Mina olen kõige sagedamini komistanud selle tõttu, et võtsin „lihtsa” teenuse, kuid hiljem pidin kõik sisse suruma ühte CloudFormation või Terraformi steeki. Ja muidugi, kuude pärast selgus, et ma sain kõik valesti aru ning teenus polnudki tegelikult lihtne! Nüüd pean ma mingil moel suure steegi väiksemateks osadeks jagama. Kui töötada CloudFormationiga, on see võimalik vaid olemasoleva steegi taastamisega, mida mina oma andmebaasidega ei tee. Terraform aga võimaldas steeki kirurgiliselt lahti võtta ja jagada selle arusaadavamateks väiksemateks osadeks.
Git'i moodulid
Koodi jagamine Terraformi vahel paljude stekkide vahel on palju lihtsam kui CloudFormationi koodi jagamine. Terraformiga saab koodi paigutada git-repositooriumisse ja sellele juurdepääsuks kasutada semantilist versioonihaldust. Igaühel, kellel on juurdepääs sellele repositooriumile, on võimalik jagatud koodi taas kasutada. CloudFormationi ekvivalent on S3, kuid sellel ei ole samu eeliseid ja pole ühtegi põhjust, miks me peaksime S3 kasuks git'ist loobuma.
Organisatsioon kasvas ja võimalus jagada ühist steeki saavutas kriitilise taseme. Terraformiga on see kõik lihtne ja loomulik, samas kui CloudFormation sunnib teid hüppama rõngaste kaudu, enne kui saate midagi sarnast toimima.
Operations as code
„Kiri skriptimise ja ongi kõik.”
— insener kolm aastat enne, kui leiutas Terraformi jalgratta.
Kui jutt tuleb tarkvara arendamisest, siis Go või Java programm pole vaid kood.
Code as Code
On ju veel infrastruktuur, mille peal see töötab.
Infrastructure as Code
Aga kuidas see seal on? Kuidas seda jälgida? Kus asub teie kood? Kas arendajatel on vaja ligipääsu luba?
Operations as Code
Tarkvaraarendaja olema ei ole ainult koodi kirjutamine.
Ainult AWS ei piisa: te kasutate kindlasti 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'd valitakse erinevatel põhjustel ja igaühel neist on tarkvaraga seotud asjades sama oluline roll.
Kui ma Twitchis töötasin, kiirusime teenuseid segatud sisseehitatud süsteemide ja AWS Amazoni süsteemide sees. Tootsime ja toetasime mitmeid mikroteenuseid, suurendades opereerimise kulusid. Arutelud käisid umbes sellises võtmes:
- Mina: Issand, liiga palju liikumisi, et ühe mikroteenuse käivitamiseks. Mul tuleb seda jama kasutada, et luua AWS konto (me suundusime 2 kontole) mikroteenus), siis seda - teavituste seadistamiseks, veel seda - koodireposiidi jaoks, ja seda - e-posti aadresside nimekirja jaoks, ja veel seda...
- Juht: Skriptime ja valmis.
- Mina: Noh, aga skript ise muutub. Vajame viisi, kuidas kontrollida, et kõik need Amazoni sisseehitatud asjad oleksid ajakohased.
- Juht: Kõlab hästi. Ja selleks kirjutame skripti.
- Mina: Suurepärane! Ja skriptil on ilmselt veel vaja määrata parameetreid. Kas ta saab neid?
- Juht: Jah, saab küll, kuhu ta ikka kaob!
- Mina: Protsess võib muutuda, tagasisideühilduvus kaob. Vajame mingit semantilist versioonikontrolli.
- Juht: Suurepärane idee!
- Mina: Tööriistu saab muuta käsitsi, kasutajaliidese sees. Meil on vaja viisi, kuidas seda kontrollida ja parandada.
…3 aastat hiljem:
- Juht: Nii saime terraformi.
Muinasjutu moraal on selline: isegi kui oled kõigis Amazonis, kasutad siiski midagi, mis ei ole AWS-ist, ja neil teenustel on olek, mida konfigureerimise keeles kasutatakse selle oleku sünkroonimiseks.
CloudFormation lambda vs git-moodulid terraform
lambda on CloudFormation lahendus kasutajaloogika küsimuse jaoks. Lambda abil saab või . Selline lähenemine toob kaasa täiendavaid keerukusi, mida terraformi git-moodulite semantilises versioonikontrollis pole. Minu kõige pakilisemaks probleemiks oli lubade haldamine kõigi nende kasutajaliidese lambdade jaoks (need on kümned AWS kontod). Teiseks oluliseks mureks oli küsimus 'mis oli enne - kana või muna?': see oli seotud lambda koodiga. See funktsioon on sisustus ja kood, ja see vajab samuti jälgimist ja uuendusi. Viimane nael kirstu oli lambda koodi muutmise semantilise uuendamise raskus; veel tuli tagada, et konteinerite toimingud ei muutuks otsekohe käsu andmiseta käivituste vahel.
Mäletan, et tahtsin luua kanaroti juurutuse Elastic Beanstalki keskkonnas klassikalise koormuse tasakaalustajaga. Kõige lihtsam oleks olnud teha teine juurutus EBs tootmiskeskkonna kõrvale, tehes veel ühe sammu: ühendades automaatselt skaleeritava kanaroti juurutusgrupi tootmiskeskkonna LB juurutusega. Ja kuna Terraform kasutab , siis see nõuab 4 lisaread koodis Terraformis. Kui küsisin, kas CloudFormationis on sarnane lahendus, juhatati mind kogu git-repositooriumi juurde, kus oli juurutamisteenus jne: ja kõik see oli selle nimel, et oleksime võinud teha õnnetud 4 rida koodi Terraformis.
See tuvastab drifi paremini
Veenduge, et reaalsus vastab ootustele.
on väga võimas operatsioonide koodina funktsioon, kuna see aitab veenduda, et reaalsus vastab ootustele. See on saadaval nii CloudFormationis kui ka Terraformis. Kuid stacki kasvu korral andis drifi otsimine CloudFormationis üha rohkem valehäireid.
Terraformiga on teil oluliselt arenenumad elutsükli konksud drifi tuvastamiseks. Näiteks sisestate käsu otse ECS-ülesande määratlemisse, kui soovite ignoreerida muudatusi mõnes konkreetse ülesande määratluses, ignoreerimata samas muudatusi kogu ECSi juurutuses.
CDK ja CloudFormationi tulevik
CloudFormationiga on raske suurtel, infrastruktuuriüleselt laialdastel aladel hallata. Paljusid neist raskustest on tunnustatud ja tööriist vajab selliseid asju nagu , struktuur, et määratleda pilveteenuste infrastruktuur koodina ja edastada see AWS CloudFormationi kaudu. Huvitav on näha, mis ootab aws-cdkt tulevikus, kuid tal on raske konkureerida teiste Terraformi eelistega; CloudFormationi sisenemiseks on vajalikud globaalsed muudatused.
Et Terraform ei pettuks
See on ju "infrastruktuur kui KOOD", mitte "kui tekst".
Minu esialgne mulje Terraformist oli üsna halb. Arvan, et ma lihtsalt ei mõistnud suhtumist. Peaaegu kõik insenerid tajuvad seda esmakordselt tahtmatult kui tekstivormingut, mille tuleb muuta soovitud infrastruktuuriks. EI PEAA NII.
Hea tarkvaraarenduse põhialused kehtivad ka Terraformi kohta
Olen näinud, kuidas paljusid häid koodiloome praktikaid eiratakse Terraformis. Olete aastaid õppinud, et saada heaks programmeerijaks. Ärge loobuge sellest kogemusest lihtsalt seetõttu, et töötate Terraformiga. Heade tarkvaraarenduse põhitõdede reeglid kehtivad ka Terraformi kohta.
Kuidas saaks koodi mitte dokumenteerida?
Olen kohanud tohutuid Terraformi steke täiesti ilma dokumentatsioonita. Kuidas saab kirjutada kode lehekülgedena — täiesti ilma dokumentatsioonita? Lisage dokumentatsioon, kus seletatakse teie koodi Terraformi (siin on rõhk sõnal "kood"), miks see osa on nii oluline ning mida te teete.
Kuidas saab käivitada teenuseid, mis olid kunagi üks suur main() funktsioon?
Olen kohanud väga keerulisi Terraformi steke, mis esitatakse ühtse moodulina. Miks me ei käita tarkvara nii? Miks me jagame suuri funktsioone väiksemateks? Samad vastused kehtivad ka Terraformi puhul. Kui teie moodul on liiga suur — tuleb see jagada väiksemateks mooduliteks.
Kas teie ettevõte ei kasuta raamatukogusid?
Olen näinud, kuidas insenerid, käivitades uut projekti Terraformi abil, likvideerisid tohutuid osi teistest projektidest oma, ja siis nokitsesid neid, kuni need hakkasid töötama. Kas te oma ettevõttes töötaksite nii "tootmiskoodiga"? Me ei kasuta raamatukogusid asjata. Jah, aga kuhu me ilma ühiste raamatukogudeta üldse jõuame?!
Kas te ei kasuta PEP8 või gofmt?
Enamikus keeltes on olemas standardne vastuvõetud vormindamisrežiim. Pythonis on see PEP8. Go puhul — gofmt. Terraformil on oma: terraform fmt. Kasutage seda julgelt!
Kas hakkate Reacti kasutama, teadmata JavaScripti?
Terraformi moodulid võivad lihtsustada teie loodud keerulise infrastruktuuri teatud osa, kuid see ei tähenda, et te ei peaks sellest üldse aru saama. Kas soovite kasutada Terraformi õigesti ilma ressurssidest arusaamata? Olete hukule määratud: aeg kulgeb, kuid te ei õpi kunagi Terraformi.
Kas kirjutate tegelasi, või kasutate sõltuvusi?
Sõltuvuste rakendamine on tunnustatud parim tava tarkvara arendamiseks, mida eelistavad singlitoad. Kuidas see Terraformis kasulik on? Olen kohanud Terraformi mooduleid, mis sõltuvad kaugolekust. Selle asemel, et kirjutada mooduleid, mis tõmbavad kaugolekust, kirjutage moodul, mis võtab parameetreid. Ja seejärel seadke need parameetrid moodulisse.
Kas teie raamatukogud teevad kümmet asja hästi või ühte – suurepäraselt?
Parimad toimivad raamatukogud on keskendunud ühele ülesandele, millega nad hästi toime tulevad. Selle asemel, et kirjutada suuri Terraformi mooduleid, mis püüavad teha kõike korraga, jagage need osadeks, mis teevad midagi ühte hästi. Ja seejärel ühendage need vastavalt vajadusele.
Kuidas te muudate raamatukogusid ilma tagasipöörduva ühilduvuseta?
Üldisele Terraformi moodulile, nagu tavalisele raamatukogule, on vajalik teavitada kasutajaid muudatustest, mis ei ole tagasipöörduva ühilduvusega. Kui selliseid muudatusi tehakse raamatukogudes, on see häiriv, ja sama häiriv on, kui Terraformi moodulites tehakse tagasipöörduva ühilduvuseta muudatusi. Soovitatav on kasutada git siltide ja semver'i rakendamisel Terraformi mooduleid.
Kas teie tooteteenus töötab teie sülearvutis või andmekeskuses?
Hashicorpil on sellised tööriistad nagu teie terraformi käivitamiseks. Need tsentraliseeritud teenused lihtsustavad juhtimist, auditeerimist ja muutuste heakskiitmist terraformis.
Kas te ei kirjuta teste?
Insenerid tunnistavad, et koodi tuleb testida, kuid tihti jätavad nad kontrollid tegemata, töötades Terraformiga. Infrastruktuuri jaoks võivad see tuua kaasa salakavalad hetked. Soovitan "testida" või "luua näidiseid" virnast, kasutades mooduleid, mida saab korralikult juurutada, et kontrollida CI/CD ajal.
Terraform ja mikroteenused
Mikroteenuste ettevõtete elu ja surm sõltuvad kiirusest, uuendamisest ja uute mikroteenuste töö virnade hävitamisest.
Kõige levinum negatiivne aspekt, mis on seotud mikroteenuste arhitektuuridega ja mille eest ei pääse, on seotud tööga, mitte koodiga. Kui võtta Terraform lihtsalt kui viisi, kuidas automaatiseerida ainult mikroteenuste arhitektuuri infrastruktuuri, siis võtate endalt ära selle süsteemi tõelised eelised. Nüüd on juba .
Allikas: habr.com
