Tundub, et Terraformi arendajad pakuvad AWS-i infrastruktuuri haldamiseks piisavalt mugavaid parimaid praktikaid. Kuid on üks nüanss. Aja jooksul suureneb keskkondade arv, igas neist on omad eripärad. Peaaegu on muutunud rakenduste virn kopeerimiseks naaberriigis. Ja Terraformi kood tuleb ettevaatlikult kopeerida ja kohandada vastavalt uutele nõudmistele või teha lumeflokk.
Minu esitus on Terraformi mustrite kohta, et võidelda kaosetunne ja käsitsi rutiiniga suurtes ja pikaajalistes projektides.
Video:
Olen 40 aastat vana, 20 aastat IT valdkonnas. 12 aastat töötan ettevõttes Ixtens. Me tegeleme e-kaubanduse arendamisega. Viis aastat olen praktiseerinud DevOpsi praktikaid.
Minu jutt käsitleb kogemust projektis ettevõttes, mille nime ma ei ütle, lähtudes konfidentsiaalsuslepingust.
Slaidil olevad numbrid on esitatud, et mõista projekti ulatust. Ja kõik, mida ma edaspidi ütlen, on seotud Amazoniga.
Liitusin selle projektiga neli aastat tagasi. Ja kõige viljakamal hetkel toimus infrastruktuuri refaktoreerimine, kuna projekt kasvas. Ja neid mustreid, mida kasutati, ei olnud enam sobivad. Arvestades kogu planeeritud projekti kasvu, tuli midagi uut välja mõelda.
Aitäh Matveile, kes rääkis eile, mis Dodo Pizzas juhtus. See on see, mis meil juhtus 4 aastat tagasi.
Tulid arendajad ja hakkasid tegema infrastruktuurikoodi.
Kõige ilmsemad põhjused, miks see oli vajalik, olid time to market. Pidi olema nii, et DevOps meeskond ei oleks pudelikael väljalaskmisel. Ja lisaks kõigele muule kasutati esimesel tasemel Terraformi ja Puppetit.
Terraform on HashiCorpi open source projekt. Ja neile, kes üldse ei tea, mis see on, järgnevad mõned slaidid.
Infrastruktuur kui kood tähendab, et saame oma infrastruktuuri kirjeldada ja paluda mõnel robotil teha nii, et saaksime need ressursid, mida oleme kirjeldanud.
Näiteks, meil on vaja virtuaalne masin. Me kirjeldame, lisame mõned kohustuslikud parameetrid.
Pärast seda seadistame konsoolis juurdepääsu Amazonile. Ja palume Terraformil plaane teha. Terraform plan ütleb: "Okei, teie ressursi jaoks saame teha selliseid asju." Ja vähemalt üks ressurss lisatakse. Ja muudatusi ei ole oodata.
Kui kõik on teie jaoks sobiv, saate küsida Terraform apply, ja Terraform loob teile instantsi ning saate oma virtuaalse masina oma pilves.
Edasi arendame meie projekti. Lisame sinna teatud muudatusi. Küsime rohkem instante, lisame 53 kirje.
Ja kordame. Küsime plaani. Näeme, milliseid muudatusi kavandatakse. Rakendame. Nii kasvab meie infrastruktuur.
Terraform kasutab sellist asja nagu state-failid. See tähendab, et kõik muudatused, mis tehakse Amazonis, salvestatakse failis, kus iga kirjelduse jaoks, mida olete esitanud, on vastavad ressursid, mis on Amazonis loodud. Nii teab Terraform täpselt, mida muuta, kui ükski ressurss muutub.
Need state-failid olid algselt lihtsalt failid. Ja me hoidsime neid Git'is, mis oli äärmiselt ebamugav. Alati unustas keegi muudatusi commitida ja palju konflikte tekkis.
Nüüd on võimalik kasutada tagastamist, st Terraform'ile öeldakse, millisesse bucket'isse ja missuguse võtme alla state-fail salvestada. Ja Terraform hoolitseb ise sellest, et see state-fail välja võtta, kogu maagia teha ja tagasi panna lõpliku tulemuse.
Meie infrastruktuur kasvab. Siin on meie kood. Me ei soovi enam lihtsalt virtuaalmasinat luua, vaid soovime luua testkeskkonna.
Terraform võimaldab luua selliseid mooduleid, st kirjeldada samu komponente mingis kaustas.
Näiteks testimisel saab kutsuda selle mooduli ja saada sama tulemuse, nagu oleksime käivitanud Terraformi rakenduse moodulis. Testimiseks saab selline kood olema.
Tootmises saame saata sinna mingeid muudatusi, sest testimisel ei vaja me suuri instance, tootmises aga on suured instance vajalikud.
Ja siis naasen tagasi projekti. Ülesanne oli keeruline; infrastruktuur oli planeeritud väga suureks. Kõik kood oli kuidagi organiseerida nii, et see oleks mugav kõigile: nii neile, kes tegelevad selle koodi hooldamisega, kui ka neile, kes muudatusi teevad. Planeeritud oli, et iga arendaja saab minna ja kohandada infrastruktuuri vastavalt sellele, mis on vajalik tema osa platvormist.
See on kaustade puu, mida soovitab HashiCorp, kui teil on suur projekt ja on mõistlik jagada kogu infrastruktuur väiksemateks osadeks ning kirjeldada iga osa eraldi kaustas.
Ulatuslikud ressurside raamatukogud võimaldavad testimisel ja tootmises kutsuda ligikaudu sama.
Meie puhul see ei sobinud, kuna arendajate või testimiseks mõeldud testimine pidi olema lihtsam. Oli ebamugav jalutada kaustades ja rakendada asju õiges järjekorras ning muretseda, et aluseks tõuseb, ja seejärel tõuseb instants, mis seda baasi kasutab. Seetõttu käivitati kogu testimine ühest kaustast. Seal kutsuti välja samad moodulid, kuid kõik toimus ühe jooksuga.
Terraform hoolitseb kõigi sõltuvuste eest. Ja loob alati ressursse sellises järjekorras, et saaks näiteks värskelt loodud instantsilt IP-aadressi ja lisada selle IP-aadressi Route53 kirja.
Lisaks sellele on platvorm väga suur. Ja testimisstacki käivitamine, isegi kui ainult üheks tunniks, isegi kui kaheks tunniks — see on üsna kulukas ettevõtmine.
Ja me automatiseerisime selle. Jenkinsi töö võimaldas käivitada steki. Seal pidi käivitama pull request'i koos muudatustega, mida arendaja soovib testida, määrama kõik vajalikud valikud, komponendid ja suurused. Kui ta soovib teha jõudlustesti, saab ta võtta rohkem instantsse. Kui tal on vaja lihtsalt kontrollida, et mõni vorm avaneb, siis sai ta alustada minimaalsetest seadistustest. Samuti sai määrata, kas klaster on vajalik või mitte jne.
Siis surus Jenkins shell-skripti, mis modifitseeris koodi Terraformi kaustas natuke. Eemaldas vajalikud failid, lisas vajalikud failid. Ja siis ühe käivitusega Terraform apply tõstis steki üles.
Edasi liikudes järgnesid muud sammud, millesse ma ei soovi süveneda.
Kuna testimiseks vajasime natuke rohkem valikuid kui tootmises, pidime tegema koopiad moodulitest, et neis koopiates saaksime lisada need funktsioonid, mis on vajalikud ainult testimisel.
Nii juhtus, et testimise käigus tahame tavaliselt katsetada neid muudatusi, mis lõpuks jõuavad tootmisse. Kuid tegelikult testiti ühte ja tootmisse rakendati natuke teist. See põhjustas väikese mõttekao, et tootmises rakendati kõik muudatused operatsioonide meeskonna poolt. Ja mõnikord juhtus, et need muudatused, mis pidid testimisest tootmisse minema, jäid hoopis teise versiooni.
Lisaks oli probleemiks see, et lisandus uus teenus, mis erines veidi juba olemasolevast. Ja selle asemel, et olemasolevat moodulit muuta, tuli teha selle koopia ja lisada vajalikud muudatused.
Sisuliselt on Terraform mitte tegelik keel, vaid deklaratsioon. Kui me peame midagi deklareerima, siis me deklareerime selle. Ja kõik see töötab.
Ühel hetkel, kui arutati üht minu pull request'i, ütles üks kolleeg, et ei tohiks luua liialt palju lumehelbeid. Mind huvitas, mida ta selle all mõtles. On olemas teaduslik fakt, et maailmas ei ole kaht ühesugust lumehelbekest, kõik need on natuke erinevad. Ja kui ma seda kuulsin, tajusin kohe Terraform'i koodi raskust. Sest kui tuli minna versioonilt versioonile, nõudis Terraform katkestamise ahelate muutmist, st kood ei olnud enam järgmise versiooniga ühilduv. Ja pidin tegema pull request'i, mis hõlmas peaaegu poole infrastruktuuri failidest, et tuua infrastruktuur järgmise Terraform'i versioonini.
Ja pärast seda, kui selline lumehelbekene tekkis, muutus kogu meie Terraform'i kood suureks lumekuhjaks.
Välimise arendaja jaoks, kes ei ole operatsioonide sesioonis, pole sel suurt tähtsust, kuna ta tegi pull request'i, tema ressurss käivitati. Ja kõik, edasi pole see tema mure. Aga DevOps'i meeskonnale, kes hoolitseb selle eest, et kõik oleks korras, tuleb teha need kõik muudatused. Ja nende muudatuste maksumus suurenes iga lisalumehelbe korral.
On see selline lugu, kuidas üliõpilane seminaril joonistab kriidiga tahvlile kaks ideaalset ringi. Ja õpetaja imestab, kuidas tal õnnestus nii ühtlaselt ilma kompassita joonistada. Üliõpilane vastab: «Väga lihtne, ma keerutasin kaks aastat armees hakklihamasinat.»
Nendest neljast aastast, mil ma selles projektis osalen, olen umbes kaks aastat tegelenud Terraformiga. Ja muidugi on mul mõned nipid, mõned soovitused, kuidas Terraformi koodi lihtsustada, töötada sellega nagu programmeerimiskeelega ja vähendada koormust arendajatele, kes peavad seda koodi ajakohasena hoidma.
Esimene asi, millega soovin alustada, on Symlinkid. Terraformil on palju korduvat koodi. Näiteks pakkuja kutsumine on praktiliselt igas punktis, kus me loome tükikese infrastruktuurist, sama. Seega on mõistlik see eraldi kausta välja võtta. Ja igal pool, kus on vaja pakkujat, luua sellele failile Symlinkid.
Näiteks, kui teil on production'is assume role, mis võimaldab teil pääseda ligi välisele Amazon-kontole. Ja muutes üht faili, omavad kõik ülejäänud, mis asuvad ressursside puus, vajalikke õigusi, et Terraform teaksite, millisele Amazon-segmendile ligi pääseda.
Kus Symlinks ei tööta? Nagu öeldud, on Terraformil state-failid. Ja need on väga-väga ägedad. Kuid asi on selles, et Terraform inizialiseerib backend'i esimeses järjekorras. Ja ta ei saa kasutada nende parameetrites mingeid muutujaid, need peavad alati olema kirjutatud tekstina.
Ja lõppkokkuvõttes, kui keegi loob uue ressursi, kopeerib ta osa koodist teistest kaustadest. Ja ta võib eksida võtme või bucket'i osas. Näiteks, kui ta teeb sandbox'st sandbox-asja ja seejärel teeb production'is. Ja niiviisi võib osutuda, et production'is kasutatakse bucket'it sandbox'ist. Loomulikult leitakse see kiiresti. Seda saab kuidagi parandada, kuid siiski aega kaotatakse ja mingil määral ressursse.
Mida me saame edasi teha? Enne Terraformiga töötamist tuleb see initsialiseerida. Initsialiseerimise hetkel laadib Terraform kõik pluginaid alla. Need on mingil hetkel monoliitsetest teenustest muutunud rohkem mikroteenuste arhitektuuriks. Ja alati tuleb teha Terraform init, et see tõmbaks kõik moodulid ja pluginad alla.
Võib kasutada shell-skripti, mis kõigepealt suudab välja tuua kõik muutujad. Shell-skripti ei piirata millegagi. Ja teiseks, teed. Kui me kasutame alati seda teed, mis on hoidlas, kui võtme state-faili jaoks, siis eksimise võimalus on välistatud.
Kust saada andmeid? JSON-failist. Terraform võimaldab salvestada infrastruktuuri mitte ainult hcl (HashiCorp Configuration Language) formaadis, vaid ka JSON-is.
JSON loetakse shell-skriptist lihtsalt. Seega võib mingisse kohta panna konfigureerimisfaili koos bucket'iga. Ja kasutada seda bucketit nii Terraformi koodis kui ka shell-skriptis initsialiseerimiseks.
Miks on oluline, et Terraformil oleks bucket? Sest on selline asi nagu remote state-failid. Tähendades, kui ma käitan mõnda ressurssi, pean ma Amazoni ütlemiseks: 'Palun tõsta instance üles', märkima väga palju kohustuslikke parameetreid.
Ja need tuvastajad salvestatakse kuskile teise kausta. Ja ma võin öelda: „Terraform, palun mine ja too mulle selle ressursi state-failist need tuvastajad.” Nii tekib mingisugune ühtsus erinevate piirkondade või keskkondade vahel.
Ei ole alati võimalik kasutada kaug-state-faili. Näiteks, kui olete käsitsi loonud VPC. Ja see Terraformi kood, mis loob VPC, loob nii erineva VPC, et teil kulub kaua aega ja peate üht teise kohandama, seetõttu saab kasutada järgmist nipi.
St. teha moodul, mis justkui loob VPC ja annab teile tuvastajad, aga tegelikult on lihtsalt fail, millel on kõvakooditud väärtused, mida saab kasutada sama instance'i loomisel.
Ei ole alati vajalik salvestada state-faili pilves. Näiteks, kui testitakse mooduleid, saab kasutada backend'i initsialiseerimist, kus fail salvestatakse lihtsalt kettale testimise ajaks.
Nüüd räägime natuke testimisest. Mida saab Terraformis testida? Tõenäoliselt on palju, aga ma räägin just nendest neljast asjast.
HashiCorp'il on arusaam, kuidas Terraformi koodi vormindada. Terraform fmt võimaldab teil vormindada koodi, mida te redigeerite, vastavalt sellele arusaamale. Seega peavad testid alati kontrollima, kas vormindamine vastab HashiCorpi loodud standarditele, et ei peaks muutma sulgude asukohta jne.
Järgmine samm on Terraform validate. See teeb veidi rohkem kui lihtsalt süntaksi kontrollimise - see kontrollib, kas kõik sulud on paaris. Mis on siin oluline? Meie infrastruktuur on väga keeruline. Seal on väga palju erinevaid kaustasid. Ja igas neist tuleb käivitada Terraform validate.
Seega, et testimist kiirendada, käivitame korraga mitmeid protsesse, kasutades paralleelsust.
Paralleelsus on tõeliselt äge asi, kasutage seda.
Kuid iga kord, kui toimub Terraformi algatamine, läheb see HashiCorpi ja küsib: „Millised on viimased pluginade versioonid? Ja see plugin, mis mul on vahemälus - kas see on õige või vale?“. Ja see andis iga sammu juures oma viivituse.
Kui Terraform annab juhiseid, kus lisandmoodulid asuvad, ütleb Terraform: "Okei, arvatavasti on see kõige värskem, mis on. Ma ei hakka kuhugi minema, vaid alustame otse teie Terraform-koodi valideerimisega."
Selleks, et kaust vajalikest lisandmoodulitest täita, on meil väga lihtne Terraform-kood, mille lihtsalt tuleb initsialiseerida. Siin tuleb kindlasti märkida kõik teenusepakkujad, kes osalevad teie koodis, muidu ütleb Terraform: "Ma ei tunne ühtegi teenusepakkujat, kuna seda ei ole vahemälus."
Järgmine on Terraform plaan. Nagu öeldud, on arendus tsükliline. Loome koodi muudatustega. Seejärel peab selguma, millised muudatused infrastruktuuri plaanitakse.
Ja kui infrastruktuur on väga, väga suur, võib ühe mooduli muutmine, mingi testkeskkonna parandamine või konkreetse regiooni muutmine kahjustada mõnda naabermoodulit. Seetõttu peaks Terraform plaan olema koostatud kogu infrastruktuuri jaoks ja näitama, millised muudatused on plaanis.
Seda saab teha nutikalt. Me näiteks kirjutasime Pythonis skripti, mis lahendab sõltuvused. Ja sõltuvalt sellest, mis täpselt muutunud on: Terraformi moodul või lihtsalt mõni konkreetselt komponent, koostab see plaanid kõigi sõltuvate kaustade jaoks.
Terraformi plaanid peaksid olema toodetud nõudmisel. vähemalt, nii me teeme.
Testid, muidugi, on igas muutuses ja igas commit'is head, kuid plaanid – see on piisavalt kulukas asi. Ja me pull request'is ütleme: „Palun, anna mulle plaanid”. Robot käivitub ja saadab kommentaaridesse või lisanditena kõik plaanid, mis on seotud teie muudatustega.
Plaan on piisavalt kulukas. See võtab aega, kuna Terraform läheb Amazonisse ja küsib: „Kas see instants on ikka olemas? Ja kas selle autoscale'i parameetrid on tõesti sellised?”. Aja säästmiseks saab kasutada sellist parameetrit nagu refresh=false. See tähendab, et Terraform laadib S3-st oleku andmed. Ja usub, et olek vastab täpselt sellele, mis Amazonis on.
Selline Terraformi plaan kulgeb palju kiiremini, kuid state peab vastama teie infrastruktuurile, st kuskil ja kunagi peab Terraform refresh käivituma. Terraform refresh teeb just seda, et state vastaks sellele, mis on reaalses infrastruktuuris.
Ja tuleb rääkida turvalisusest. Sellega oleks tulnud alustada. Seal, kus te käitate Terraformi ja Terraform töötab teie infrastruktuuriga, on olemas haavatavus. St te, põhimõtteliselt, täidate koodi. Ja kui pull request sisaldab mingit pahatahtlikku koodi, võib see käivituda infrastruktuuris, millel on liiga palju ligipääsu. Seega olge ettevaatlik, kus te Terraformi plaani käitate.
Järgmine, millest sooviksin rääkida, on user-data testimine.
Mis on user-data? Amazonis, kui loome instance’i, saame instance’ilt saata mingi kirja – meta-andmed. Kui instance käivitub, on tavaliselt cloud init alati nende instance’ide juures. Cloud init loeb seda kirja ja ütleb: "Okei, täna olen ma load balancer." Ja nende andmete alusel sooritab ta teatud tegevusi.
Kahjuks, kui me teeme Terraform plaani ja Terraform rakendust, näeb user-data välja nagu selline numbrite puder. Teisisõnu, see saadab teile lihtsalt hash'i. Ja kõik, mida saate plaanis vaadata, on see, kas mõned muudatused on või hash jääb samaks.
Ja kui sellele mitte tähelepanu pöörata, võib Amazonis, reaalses infrastruktuuris, minna mingisugune rikutud tekstifail.
Ühe võimalusena saab täitmise käigus näidata mitte kogu infrastruktuuri, vaid ainult template'i. Ja koodis saate öelda: "Palun, näita mulle seda template'i." Nii et lõpuks saate välja printida, millised teie andmed Amazonis välja näevad.
Teine võimalus on kasutada moodulit user-data genereerimiseks. Te rakendate selle mooduli. Saate faili kettale. Võrdlete seda lähtefailiga. Ja nii, kui mõni algaja otsustab user-data veidi muuta, ütlevad teie testid: "Ok, siin ja siin on mingid muudatused – see on normaalne."
Järgmiseks, millest ma rääkida tahan, on Automate Terraform rakendus.
Muidugi on hirmutav Terraformi rakendamine automaatselt, sest kes teab, millised muudatused on tehtud ja kui kahjulikud need võivad olla elavale infrastruktuurile.
Testkeskkonna jaoks on see kõik täiesti normaalne. See tähendab, et töö, mis loob testkeskkonna, on see, mida kõik arendajad vajavad. Ja selline väljend nagu „mul töötas kõik” ei ole naljakas meem, vaid tõestus sellest, et inimene on vaeva näinud, käivitanud virna, jooksutanud sellel mingi teste. Ja veendunud, et kõik on korras ning öelnud: „Ok, see kood, mille ma välja annan, on testitud.”
Tootmises, liivakastis ja teistes keskkondades, mis on ettevõtte jaoks olulisemad, võib osaliselt rakendada mõned ressursid piisavalt turvaliselt, kuna see ei põhjusta, et keegi surma saab. Need on: autoscale-grupid, turvagrupid, rollid, Route53 ja seal võib olla piisavalt pikk nimekiri. Kuid jälgige, mis toimub, lugege automatiseeritud rakendamise aruandeid.
Kohas, kus rakendamine on ohtlik või hirmutav, näiteks kui tegemist on püsivate ressursidega, andmebaasidega, siis saate aruandeid selle kohta, et mõnes infrastruktuuri osas on rakendamata muudatused. Ja insener käivitab jälgimise all tööd, et neid rakendada või teeb seda oma konsoolist.
Amazonis on selline asi nagu Terminate protection. See võib mõnel juhul kaitsta teid soovimatute muudatuste eest. St. Terraform läheb Amazonisse ja ütleb: "Mul on vaja see instants kustutada, et teha teine kindel instants." Amazon aga vastab: "Sorry, ei täna. Meil on Terminate protection sisse lülitatud."
Ja koogitükk – see on koodi optimeerimine. Kui töötame Terraform-koodiga, peame moodulisse edastama väga suure hulga parameetreid. Need parameetrid on vajalikud, et luua mõni ressurss. Ja kood muutub suurteks parameetrite loenditeks, mida tuleb edastada moodulist moodulisse, eriti kui moodulid on pesastatud.
Ja see on väga raske lugeda. Seda on väga raske üle vaadata. Ja tihti juhtub, et mõned parameetrid läbivad ülevaatamise, kuid nad ei ole just need, mis vajalikud. Ja see maksab aega ja raha, et hiljem parandada.
Seetõttu soovitan teil kasutada sellist asja nagu keeruline parameeter, mis sisaldab mingit väärtuste puu. St. on vaja mingit kausta, kus on loetletud kõik väärtused, mida sooviksite mingis keskkonnas omada.
Ja kutsudes seda moodulit, saab genereerida puu, mis luuakse ühes üldises moodulis, st. üldises moodulis, mis töötab ühtlaselt kogu infrastruktuuris.
Selles moodulis saab teha teatud arvutusi, kasutades sellist uut funktsiooni Terraformis nagu locals. Ja siis ühe väljundiga anda välja mingi keeruline parameeter, mis võib sisaldada hash'e, massiive jne.
Siin on kõik parimad leidud, mis mul on. Tahaksin rääkida loo Kolumbusest. Kui ta otsis raha oma ekspeditsioonile, et avastada Indiat (nagu ta arvas), ei uskunud keegi temasse ega pidanud seda võimalikuks. Siis ütles ta: "Tehke nii, et muna ei kukuks." Kõik pangandajad, väga rikkad ja tõenäoliselt arukad inimesed, proovisid muna kuidagi püstise hoida, kuid see kukkus pidevalt. Siis võttis Kolumbus muna, surus sellele veidi. Koor vajus sisse ja muna jäi liikumatuks. Nemad ütlesid: "Oh, see on liiga lihtne!". Ja Kolumbus vastas: "Jah, see on liiga lihtne. Ja kui ma avastan India, hakkavad kõik seda kaubateed kasutama."
Ja see, mis ma teile just rääkisin, on tõenäoliselt piisavalt lihtsad ja triviaalne asjad. Ja kui sa neist kuulema saad ja hakkad neid kasutama, on see igati normaalne. Nii et kasutage neid. Ja kui need on teie jaoks täiesti tavalised asjad, siis vähemalt teate, kuidas muna paigal hoida, et see ei kukuks.
Kokkuvõtteks:
- Püüdke lumepalle vältida. Ja mida vähem lumepalle, seda vähem ressursse on teil vaja, et teha muudatusi kogu teie suurel infrastruktuuril.
- Püsivad muudatused. See tähendab, et kui koodis on toimunud muudatusi, tuleb võimalikult kiiresti viia teie infrastruktuur vastavusse nende muudatustega. Ei peaks olema olukorda, kus keegi tuleb kaks-kolm kuud hiljem vaatama Elasticsearchi, teeb Terraform plaani ja seal on palju muudatusi, mida ta ei oodanud. See võtab palju aega, et kõik uuesti korda seada.
- Testid ja automatiseerimine. Mida rohkem on teie kood kaetud testide ja funktsioonidega, seda kindlamad olete, et teete kõike õigesti. Automaatne edastamine suurendab teie enesekindlust mitu korda.
- Testimise ja tootmisümbritsioonide kood peab olema praktiliselt sama. Praktiliselt, sest tootmine on ikkagi natuke erinev ja seal on ikkagi mõned nüansid, mis jäävad testimisest välja. Kuid siiski, pluss-miinus saab seda tagada.
- Ja kui teil on väga palju Terraform-koodi ja selle koodi ajakohasena hoidmiseks kulub palju aega, pole kunagi liiga hilja refaktoreerida ja see heasse vormi tuua.
- Muudatusteta infrastruktuur. AMI tarnimine graafiku järgi.
- Struktuur route53 jaoks, kui teil on palju kirjeid ja soovite, et need oleksid korrektses järjestuses.
- API määrangute piirangute ületamine. See on siis, kui Amazon ütleb: "Kõik, piisab, ma ei saa enam päringuid vastu võtta, palun oodake." Ja pool kontorist ootab, kuni nad saavad oma infrastruktuuri käivitada.
- Spot instance'id. Amazon ei ole odav lahendus ja spot'id aitavad palju säästa. Sel teemal võiks esitleda terve ettekande.
- Turvalisus ja IAM rollid.
- Kadunud ressursside otsimine, kui Amazonis on arusaamatute päritoluga instance'id, mis söövad raha. Isegi kui instance maksab 100-150 dollarit kuus – aastas on see üle 1000. Selliste ressursside leidmine on kasumlik äri.
- Ja reserveeritud instance'id.
Sellega ongi kõik. Terraform on väga äge, kasutage seda. Aitäh!
Küsimused
Aitäh ettekande eest! Teil on state-fail S3-s, kuid kuidas te lahendate probleemi, et mitu inimest saavad selle state-faili ja püüavad kasutusele võtta?
Esiteks, me ei kiirusta. Teiseks, meil on flags, millega teavitame, et töötame mingis koodijupil. See tähendab, et kuigi infrastruktuur on väga suur, ei tähenda see, et keegi pidevalt midagi rakendab. Ja kui aktiivne faas oli – oli see probleem, meil olid state-failid Git'is. See oli oluline, muidu keegi teeks state-faili ja pidime need käsitsi kokku koguma, et kõik jätkuks. Praegu sellist probleemi ei ole. Üldiselt lahendas Terraform selle ülesande. Ja kui pidevalt midagi muutub, siis saab kasutada lukke, mis takistavad seda, mida te ütlesite.
Kasutate te avatud versiooni või ettevõtte versiooni?
Mitte mingit ettevõtte versiooni, st kõik, mida saab tasuta alla laadida.
Minu nimi on Stanislav. Soovisin teha väikese täienduse. Te rääkisite Amazon'i funktsioonist, mis võimaldab luua mittehävitatavat instantsi. See on olemas ka Terraformis, Life Second bloki sees saab märkida muudatuste või hävitamise tõkestamise.
Aeg oli piiratud. Hea märkamine.
Soovisin veel küsida kahte asja. Esiteks rääkisite testimisest. Kas olete kasutanud mingeid teste teenuseid? Olen kuulnud Test Kitchen pluginast. Võib-olla on veel midagi. Ja tahaksin veel küsida Local Values kohta. Kuidas need põhimõtteliselt erinevad Input Variables'ist? Ja miks ma ei saa midagi ainult Local Values kaudu parameteriseerida? Olen proovinud selle teema kallal töötada, kuid ei ole sellega päris selgeks saanud.
Saame sellest ruumist põhjalikumalt rääkida. Testimisriistade osas on meil täiesti omavalmistatud lahendused. Seal ei ole midagi sellist, mida saaks testida. Kuid üldiselt on võimalusi, kus automaatsed testid loovad infrastruktuuri kusagil, kontrollivad, et see oleks korras, ja siis kõik hävitatakse koos raportiga, et teie infrastruktuur on endiselt heas seisukorras. Meil seda ei ole, sest testimine toimub igapäevaselt. Ja see piisab. Ja kui midagi hakkab katki minema, siis see hakkab katki minema, ilma et me peaksime seda kuskil veel kontrollima.
Local Values'i osas jätkame vestlust ruumis.
Tere! Aitäh ettekande eest! See oli väga informatiivne. Sa ütlesid, et teil on väga palju sarnast koodi infrastruktuuri kirjeldamiseks. Kas te ei ole kaalunud koodi genereerimise võimalust?
Suurepärane küsimus, aitäh! Asi on selles, et kui me kasutame infrastruktuuri kui koodi, eeldame, et vaatame koodi ja mõistame, milline infrastruktuur selle koodi taga seisab. Kui kood genereeritakse, peame ette kujutama, milline kood genereeritakse, et mõista, milline infrastruktuur seal on. Kas genereerime koodi, paneme selle edasi ja esimese mõttega saame samu tulemusi. Seetõttu läksime teed, nagu oleme kirjutanud, ja said, mida said. Pluss genereerijad tulid mõned aega hiljem, kui olime alustanud. Ja oli juba liiga hilja seda muuta.
Kas oled kuulnud jsonnetist?
Ei.
Vaata, see on tõeliselt äge asi. Ma näen konkreetset kasutusjuhtu, kus seda saab rakendada ja andmestruktuure genereerida.
Generaatorid on head, kui sul on nagu anekdootis habemeajamismasinast. Ehk siis esmakordselt on näod erinevad, kuid hiljem on kõigil näod ühesugused. Generaatorid on tõeliselt head. Kuid meil on kahjuks näod veidi erinevad. See on probleem.
Lihtsalt vaata. Aitäh!
Minu nimi on Maksim, ma olen Sberbankist. Te rääkisite veidi sellest, et üritasite Terraformit programmeerimiskeele analoogiks tuua. Kas poleks lihtsam kasutada Ansible'i?
Need on väga erinevad asjad. Ka Ansible'i abil saab luua ressursse ja Puppetiga saab ressursse Amazonis luua. Kuid Terraform on sellele spetsialiseerunud.
Kas teil on ainult Amazon?
Küsimus ei ole selles, et meil on ainult Amazon. Meil on peaaegu ainult Amazon. Kuid võtmeküsimus on selles, et Terraform mäletab. Ansible'iga, kui ütled: „Tõsta mulle 5 instantsi”, siis ta tõstab need üles, aga pärast ütled: „Nüüd on mul vaja 3”. Terraform ütleb: „Okei, tapen 2”, aga Ansible ütleb: „Okei, siin on 3”. Kokku 8.
Tere! Aitäh teie ettekande eest! Oli väga huvitav kuulda Terraformist. Tahaksin kohe anda väikse kommentaari selle kohta, et Terraformil ei ole siiski stabiilset versiooni, seega suhelge Terraformiga väga ettevaatlikult.
Hea lusikas supi jaoks. Ehkki, kui vajate lahendust, siis mõnikord lükkate edasi ebastabiilse jne, kuid see töötab ja on meile abiks olnud.
Küsimus on selline. Kas te kasutate Remote backend'i, kasutate S3-d. Miks te ei kasuta ametlikku backend'i?
Ametlik?
Terraform Cloud.
Millal see ilmus?
Neli kuud tagasi.
Kui ta oleks ilmunud neli aastat tagasi, oleksin ma ilmselt teie küsimusele vastanud.
Seal on juba sisse ehitatud funktsioon, mis võimaldab kasutada lukke ja hoida olekufaili. Proovige. Kuid ma ei ole seda ka testinud.
Reisime suures rongis, mis liigub suure kiirusel. Ja ei saa lihtsalt võtta ja visata ära mitut vagunit.
Te rääkisite lumehelvestest, aga miks te ei kasutanud haru? Miks ei õnnestunud nii teha?
Meie lähenemine on selline, et kogu infrastruktuur on ühes hoidlas. Terraform, Puppet, kõik skriptid, mis isegi mingil viisil selle juurde kuuluvad, on kõik ühes hoidlas. Nii saame tagada, et järkjärgulised muudatused on üksteise järel testitud. Kui see oleks hulk harusid, oleks sellist projekti praktiliselt võimatu hooldada. Aastad möödub ja need tõukuvad nii kaugele, et see on nagu karistus. See on see, millest tahaks enne refaktooringut põgeneda.
See tähendab, et see ei tööta?
See ei tööta üldse.
Branchis lõikasin kaustade slaidi. See tähendab, et kui teha iga testplexi jaoks, näiteks A meeskonna jaoks — neil on oma kaust, B meeskonna jaoks oma kaust, siis see ei toimi ka. Me tegime ühtse testkeskkonna koodi, mis oli piisavalt paindlik, et sobida kõigile. See tähendab, et me hooldasime ühtset koodi.
Tere! Minu nimi on Jura! Aitäh ettekande eest! Küsimus moodulite kohta. Te ütlete, et kasutate mooduleid. Kuidas te lahendate probleemi, kui ühes moodulis tehti muudatusi, mis ei ühildu kellegi teise muudatustega? Kas te versioonite mooduleid või üritate kuidagi heilida, et vastata kahele nõudmisele?
See on suure lume kuhja probleem. See on see, millega me kannatame, kui mingi süütu muudatus võib rikku teatud infrastruktur. Ja seda märgatakse ainult pärast pikka aega.
Kas see tähendab, et praegu ei ole lahendust?
Teete universaalsed moodulid. Vältige lumehelbeid. Ja kõik läheb korda. Ettekanne teine pool räägib, kuidas seda vältida.
Tere! Aitäh ettekande eest! Sooviksin täpsustada. Küll on palju jäänud, mille pärast ma tulin. Kuidas on integreeritud Puppet ja rollide jaotamine?
Kasutaja andmed.
T. e. lihtsalt viskate faili välja ja siis töötlete seda kuidagi?
Kasutaja andmed – see on märk, st kui me teeme pildi klooni, siis käivitub Daemon, kes püüab välja selgitada, kes ta on, ja loeb märkuse, et ta on koormustasakaalustaja.
T. e. see on mingi eraldi protsess, mis antakse edasi?
Me ei leiutanud seda. Me kasutame seda.
Tere! Mul on just küsimus kasutaja andmete kohta. Te ütlesite, et seal on probleeme, et keegi võib midagi valesti edastada. Kas on mingit võimalust salvestada kasutaja andmed samasse Git'i, et oleks alati aru saada, millele kasutaja andmed viitavad?
User-data genereeritakse šablonist. See tähendab, et seal on mingi hulk muutujaid. Ja Terraform genereerib lõpptulemuse. Seetõttu ei saa lihtsalt vaadata šabloni ja öelda, mis tuleb, sest kõik probleemid on seotud sellega, et arendaja arvab, et ta edastab selles muutuja sees rea, aga seal tuleb massiiv. Ja tal on - hopp, kes see on, kes see on, järgmine rida, ja kõik on katki. Kui see on uus ressurss ja inimene tõstab selle üles, näeb, et midagi ei tööta, siis see lahendatakse kiiresti. Aga kui see on autoscale-grupp, mis on uuendatud, siis mingi hetk hakkavad autoscale-grupi instantsid asuma üksteise asemele. Ja hop, midagi ei tööta. See on tõeliselt kahju.
Kas selgub, et ainus lahendus on testimine?
Jah, te näete probleemi, te lisate sinna testimissteppe. See tähendab, et ka väljundiga saab testida. Võib-olla ei ole see nii mugav, aga ka siia saab mingid sildid panna - kontrollige, et User-data on siin naelutatud.
Minu nimi on Timur. On väga lahe, et on ettekandeid sellest, kuidas korralikult Terraformit korraldada.
Ma pole isegi alustanud.
Ma arvan, et järgmises konverentsis võib-olla tuleb see teema üles. Mul on lihtne küsimus. Miks te kodeerite väärtuse eraldi moodulis, mitte ei kasuta tfvars, st mis on nende väärtuste mooduli eelised võrreldes tfvars-iga?
St. kas ma pean siin (slaid: Production/environment/settings.tf) kirjutama: domain = variable, domain vpcnetwork, variable vpcnetwork ja samaväärset stvars – et saada sama tulemuse?
Me ju teeme täpselt nii. Viitame seadistuse allikale, näiteks.
Sisuliselt on see nagu tfvars. Tfvars on väga mugav testimisümbruses. Mul on tfvars suurte ja väikeste instances jaoks. Ja ma panin ühe faili kausta. Ja sain just seda, mida tahtsin. Kui me infrastruktuuri ehitame, soovime, et oleks võimalik kõike korraga näha ja aru saada. Nüüd aga peab vaatama siia, siis jälle tfvars-i.
Tuleb lihtsalt, et kõik oleks ühes kohas?
Jah, tfvars on siis, kui teil on üks kood. Ja seda kasutatakse mitmes erinevas kohas, kus on eri nüansid. Siis te paneksite tfvars ja saaksite oma nüansid. Aga meie - see on infrastruktuur kui puhas kood. Vaata ja saa aru.
Tere! Olete silmitsi seisnud olukordadega, kus pilvuteenuse pakkuja sekkub sellesse, mida olete Terraformiga teinud? Oletame, et me redigeerime metaandmeid. Seal on ssh-võtmed. Ja Google pidevalt põhistab sinna oma metaandmeid, oma võtmeid. Ja Terraform ütleb alati, et tal on muudatusi. Pärast iga jooksu, isegi kui midagi ei muutu, ütleb ta alati, et ta kavatseb seda välja värskendada.
Võtmetega, kuid – jah, osa infrastruktuurist on sellise probleemiga mõjutatud, st Terraform ei saa midagi muuta. Me ei saa ka käega midagi muuta. Elame hetkel sellega.
St, olete sellise probleemiga silmitsi seisnud, kuid pole midagi välja mõelnud, ta lihtsalt teeb ja teeb ise?
Kahjuks, jah.
Tere! Minu nimi on Starkov Stanislav. Mail.ru Group. Kuidas te lahendate probleemi sildi genereerimisega ..., kuidas te selle sisse edastate? Ma saan aru, et kasutate User — data, et määrata hosti nimi, rakendate Puppetit? Ja teine osa küsimusest. Kuidas te lahendate selle küsimuse SG-s, st kui genereerite SG-d, sadu ühesuguseid instantsi, kuidas neid õigesti nimetada?
Needless instances are named nicely, while those that aren't necessary have the label indicating they are an autoscale group. In theory, these can be terminated to create a new one.
Regarding the tag issue, there isn’t a problem per se, but rather a task. Our tags are extensively used because the infrastructure is large and costly. We need to track where the money goes, so tags help us untangle what expenditure is attributed to which aspect, allowing us to identify areas with high costs.
What was the other question about?
When SG creates a hundred instances, how do we differentiate them?
No, it's not necessary. Each instance has an agent that reports issues. If the agent indicates a problem, it knows about it, and at the very least, its IP address exists. That's already enough to act. Additionally, we use Consul for Discovery in places where Kubernetes isn’t applicable, which also shows the IP address of the instance.
So, you are indeed focusing on the IP rather than the host name?
It's impossible to rely on the host name because there are too many. There are instance identifiers like AE, etc. You can locate it somewhere or input it in the search.
Tere! Ma sain aru, et Terraform on suurepärane asi, mida on kohandatud pilvetehnoloogiate jaoks.
Mitte ainult.
See küsimus huvitab mind. Kui näiteks otsustate massiliselt üle minna Bare Metal'ile koos kõigi oma instantsidega, kas tekib probleeme? Või on vaja kasutada teisi tooteid, näiteks eelnevalt mainitud Ansible'd?
Ansible tegeleb veidi teistsuguste asjadega. Tähendab, Ansible töötab siis, kui instants on juba käivitatud. Terraform töötab enne, kui instants käivitatakse. Bare Metal'ile üleminek – ei.
Praegu ei, aga äri tuleb ja ütleb: "Teeme seda."
Teisele pilve teenusele üleminek – jah, aga siin on veidi teine asi. Peab kirjutama Terraform'i koodi selliselt, et teisele pilve teenusele üleminek oleks lihtsam.
Alguses seati eesmärgiks, et kogu meie infrastruktuur oleks agnostiline, st sobiks igasugustele pilvedele, kuid mingil hetkel andis äri alla ja ütles: "Okei, lähiaastatel me ei lähe kuhugi, võime kasutada Amazon'i teenuseid."
Terraform võimaldab luua Front-End töid, konfigureerida PagerDuty't, data doc'i jne. Tal on väga palju funktsioone. Ta suudab praktiliselt kontrollida kogu maailma.
Aitäh ettekande eest! Olen juba nelja aasta jooksul Terraformiga tegelenud. Terraformile, infrastruktuurile ja deklaratiivsele kirjeldusele ülemineku etapis sattusime olukorda, kus keegi tegi midagi käsitsi, samal ajal kui sa proovisid teha plaani. Ja said seal mingi vea. Kuidas te selliseid probleeme lahendate? Kuidas leiate kadunud ressursid, mis olid märgitud?
Peamiselt käsitsi ja visuaalselt, kui näeme aruandes midagi kahtlast, analüüsime, mis seal toimub, või lihtsalt kõrvaldame selle. Üldiselt on koodi tõmbamised tavaline asi.
Kui esineb viga, teete te rollbacki? Kas olete proovinud sellist lahendust?
Ei, see on inimese otsus hetkel, kui ta näeb probleemi.
Allikas: habr.com
