Tundub, et Terraformi arendajad pakuvad piisavalt mugavaid parimaid praktikaid AWS-infrastruktuuriga töötamiseks. Ainult et on nüanss. Aja jooksul suureneb keskkondade arv, igas neist on omad eripärad. Peaaegu koopia rakenduste virnast naaberriigis. Ja Terraformi kood tuleb ettevaatlikult kopeerida ja muuta vastavalt uutele nõudmistele või luua lumehelves.
Minu ettekande teema on mustrid Terraformis, et võidelda kaose ja käsitsi rutiiniga suurtes ja pikaajalistes projektides.
Video:
Mul on 40 aastat, olen IT-s olnud 20 aastat. 12 aastat töötan ettevõttes Ixtens. Me tegeleme ecommerce-driven-development'iga. Ja 5 aastat praktiseerin DevOps-praktikaid.
Minu jutt tuleb olema kogemusest projektis ettevõttes, mille nime ma ei nimeta, kuna olen allkirjastanud mitteavaldamise kokkuleppe.
Numbrid slaidil on esitatud selleks, et mõista projekti ulatust. Ja kõik, mida ma edaspidi räägin, on seotud Amazoniga.
Liitusin selle projektiga 4 aastat tagasi. Ja sama ajal toimus infrastruktuuri refaktoreerimine, kuna projekt oli kasvanud. Ja need mustrid, mida kasutati, polnud enam sobivad. Arvestades kogu projekti planeeritud kasvu, pidi midagi uut välja mõtlema.
Aitäh Matveile, kes rääkis eile, mis Dodo Pitsas toimus. See on see, mis meil 4 aastat tagasi juhtus.
Tulid arendajad ja hakkasid kirjutama infrastruktuuri koodi.
Kõige ilmsed põhjused, miks see vajalik oli, olid turule toomise aeg. Pidi olema nii, et DevOps meeskond ei olnud kitsas koht väljalaskmisel. Ja lisaks kõigele muule kasutati esimesel tasemel Terraformi ja Puppetit.
Terraform on HashiCorpi avatud lähtekoodiga projekt. Ja nende jaoks, kes üldse ei tea, mis see on, järgmised slaidid.
Infrastruktuur kui kood tähendab, et saame oma infrastruktuuri kirjeldada ja paluda mingitel robotitel luua need ressursid, mida oleme kirjeldanud.
Näiteks vajame virtuiaalmasin. Me kirjeldame, lisame mõned kohustuslikud parameetrid.
Pärast seda seadistame konsoolis juurdepääsu Amazonile. Ja palume Terraformil plaani. Terraform plan ütleb: "Olen, teie ressursile saame teha järgmised asjad". Ja vähemalt üks ressurss lisatakse. Ja mingeid muutusi ei oodata.
Kui kõik sobib, saate paluda Terraformil rakendada ja Terraform loob teile instantsi, ja saate oma pilves virtuaalse masina.
Edasi läheb meie projekt edasi. Me lisame sinna muudatusi. Me palume rohkem instantsi, lisame 53 kirje.
Ja kordame. Palume plaani. Näeme, millised muudatused on planeeritud. Rakendame. Nii kasvab meie infrastruktuur.
Terraform kasutab sellist asja nagu olekufailid. See tähendab, et kõik muudatused, mis lähevad Amazonisse, salvestatakse faili, kus iga ressurssi, mille olete kirjeldanud, vastavad ressursid, mis on Amazonis loodud. Nii teab Terraform täpselt, mida muuta Amazonis, kui ressursi kirjeldust muudetakse.
Need olekufailid olid algselt lihtsalt failid. Ja me hoidsime neid Git'is, mis oli äärmiselt ebamugav. Alati, kui keegi unustas muudatused komiteerida, tekkis palju konflikte.
Nüüd on võimalik kasutada backend'i, see tähendab, et Terraform'ile tehakse ettepanek, millisesse bucket'isse ja mille võtme alla tuleb olekufail salvestada. Ja Terraform hoolitseb selle eest, et tuua see olekufail, teha kogu maagia ja panna lõpuks tulemus tagasi.
Meie infrastruktuur kasvab. Siin on meie kood. Ja me ei soovi enam lihtsalt virtuaalmasinat luua, me tahame, et oleks testimine keskkond.
Terraform võimaldab luua sellise asja nagu moodul, see tähendab, et sama asja saab kirjeldada mingis kaustas.
Ja näiteks testimisel kutsuda seda moodulit ja saada sama, nagu oleksime käitunud Terraform apply moodulis enda sees. Testimiseks oleks selline kood.
Tootmises võime saata sinna teatud muudatusi, sest testimisel ei ole meil suuri instantsse vaja, tootmises on suured instantsid just vajalikud.
Ja edasi tagasi projekti. Oli keeruline ülesanne, infrastruktuur kavandati väga suureks. Ja oli vajalik kuidagi paigutada kogu kood, et see oleks mugav kõigile: nii neile, kes hoolitsevad selle koodi eest, kui ka neile, kes muudatusi teevad. Ja kavandati, et iga arendaja võiks minna ja muuta infrastruktuuri nii, nagu on vajalik tema platvormi osa jaoks.
See on kataloogipuu, mida soovitab HashiCorp ise, kui teil on suur projekt ja on mõistlik jagada kogu infrastruktuur väiksemateks tükkideks ning iga tükk kirjeldada eraldi kaustas.
Olles laia ressursside raamatukoguga, saab testimisel ja tootmises kutsuda umbes sama asja.
Meie puhul ei sobinud see päris nii, kuna arendajatele või testimiseks mõeldud testihunnikud pidid olema kergemini kättesaadavad. Ei tahtnud ju ringi kaevata kaustades ja rakendada õigetes järjestustes ning muretseda selle pärast, et andmebaas käivitub ja siis käivitub selle andmebaasi kasutav instants. Seetõttu käivitati kogu testimine ühest kaustast. Seal kutsuti välja samad moodulid, kuid kõik toimus ühe käigu jooksul.
Terraform hoolitseb kõigi sõltuvuste eest. Ja loob alati ressursid sellises järjekorras, et näiteks värskelt loodud instantsilt oleks võimalik saada IP-aadress ja see IP-aadress saada route53 kirja.
Lisaks sellele on platvorm väga suur. Ja testihunniku käivitamine, isegi kui vaid üheks tunniks, isegi kui 8 tunniks – see on üsna kulukas.
Ja me automatiseerisime selle protsessi. Jenkins'i töö võimaldas hunniku käivitada. Seal pidi käivitama pull request'i koos muudatustega, mida arendaja soovis testida, määrama kõik vajalikud valikud, komponendid ja ka suurused. Kui ta soovis sooritustestimist, siis ta võis kasutada rohkem instante. Kui ta lihtsalt soovis kontrollida, kas mõni vorm avaneb, siis võis ta käivitada väikestes kogustes. Samuti sai määrata, kas klaster on vajalik või mitte jne.
Ja seejärel tõukas Jenkins shell-skripti, mis veidi muutis koodi Terraform kaustas. Eemaldati mittevajalikud failid, lisati vajalikud failid. Ja seejärel ühe käigutusega Terraform apply käivitus hunnik.
Ja siis järgnesid muud sammud, millesse ma ei taha süveneda.
Kuna testimiseks vajasime veidi rohkem valikuid kui tootmises, pidime moodulite koopiaid tegema, et neis koopiaides oleks võimalik lisada funktsioone, mis on vajalikud ainult testimiseks.
Nii juhtus, et testimisel sooviti testida neid muudatusi, mis lõpuks lähevad tootmisse. Kuid tegelikult testiti üht, samas kui tootmises rakendati pisut muud. Ja tekkis väikene lõhe olukorras, et tootmises rakendati kõik muudatused opereerimise meeskonna poolt. Ja mõnikord juhtus nii, et need muudatused, mis pidid testimisest tootmisse minema, jäid teise versiooni.
Sellega seondub veel probleem, et lisandus uus teenus, mis erines veidi mõnest juba olemas olevast. Ja selle asemel, et olemasolevat moodulit kohandada, tuli teha selle koopia ja lisada vajalikud muudatused.
Sisuliselt ei ole Terraform tõeline keel. See on deklaratsioon. Kui meil on midagi deklareerimiseks vaja, siis me deklareerime selle. Ja kõik see töötab.
Ühel hetkel, kui arutati ühte minu pull-requesti, ütles üks kolleeg, et ei peaks lund tootma. Huvitav, mida ta silmas pidas. On olemas teaduslik fakt, et maailmas ei ole kaks identset lumevalget, nad kõik erinevad veidi. Ja kui ma seda kuulsin, tundsin ma kohe kogu Terraform-koodi raskust. Sest kui tuli minna versioonilt versioonile, nõudis Terraform breaking chain muutusi, st. kood ei olnud uue versiooniga enam ühilduv. Ja tuli teha pull-request, mis katab peaaegu poole infrastruktuuri failidest, et viia infrastruktuur järgmise Terraform versioonini.
Ja pärast seda, kui selline lumi tekkis, muutus kogu meie Terraform-kood suureks lumemäeks.
Välist arendaja jaoks, kes ei ole operatsioonis, ei ole sellega suurt tähtsust, sest ta tegi pull-requesti, tema ressurss käivitus. Ja kõik, edaspidi ei ole see tema mure. Kui aga DevOps meeskonnale, kes jälgib, et kõik oleks OK, tuleb teha kõik need muudatused. Ja nende muudatuste hind tõusis iga täiendava lumehelbega väga-väga palju.
On olemas lugu sellest, kuidas üliõpilane seminari ajal kannab kriidiga tahvlile kaks ideaalset ringi. Ja õpetaja imestab, kuidas tal õnnestus ilma kompassita nii ühtlaselt joonistada. Üliõpilane vastab: "Väga lihtsalt, ma keerutasin kaks aastat armees lihaveskit."
Ja nendest neljast aastast, mil ma olen selles projektis osalenud, olen ma umbes kaks aastat tegelenud Terraformiga. Ja muidugi on mul mõned nipid, mõned nõuanded, kuidas Terraform-koodi lihtsustada, sellega nagu programmeerimiskeelega töötada ja vähendada koormust arendajatele, kes peavad seda koodi ajakohasena hoidma.
Esimene asi, millega soovin alustada, on Symlinks. Terraformil on palju korduvat koodi. Näiteks kasutatakse pakkujat praktiliselt igas kohas, kus me loome infrastruktuuri osa, sama. Ja on mõistlik viia see eraldi kausta. Ja igal pool, kus pakkujat on vaja, luua Symlinks sellele failile.
Näiteks, kui teil on tootmises kasutada assume role, mis võimaldab teil saada juurdepääsu mingile välishaava Amazon-kontole. Ja muutes ühte faili, saavad kõik ülejäänud, mis on ressursipuus, vajalikud õigused, et Terraform teaks, millise Amazon-segmendi poole pöörduda.
Kus Symlinks ei tööta? Nagu öeldud, on Terraformil state-failid. Ja need on väga-väga ägedad. Kuid probleem on selles, et Terraform initsialiseerib backend esimesena. Ja ta ei saa nende parameetrites kasutada mingeid muutujaid, need tuleb alati kirjutada tekstina.
Ja tulemuseks on see, et 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 sandboxist sandbox-asi ja siis loob tootmises. Ja võib juhtuda, et tootmise bucket'i kasutatakse sandboxist. Muidugi, seda leitakse kiiresti. See saab kuidagi parandatud, kuid sellegipoolest on see ajakaotus ja teatud määral ressursside kaotus.
Mida me saame edasi teha? Enne Terraformiga töötamist tuleb see initsialiseerida. Initsialiseerimise hetkel laadib Terraform alla kõik pluginad. Need on mingil hetkel monoliidist lagunenud mikroteenuste arhitektuuriks. Ja alati on vajalik teha Terraform init, et see laaks kõik moodulid, kõik pluginad.
Ja saab kasutada shell-skripti, mis, esiteks, suudab hankida kõik muutujad. Shell-skript ei ole millegiga piiratud. Ja teiseks, teed. Kui me alati kasutame seda teed, mis on hoidlas state-faili võtmena, siis vastavalt on see viga välistatud.
Kust andmeid hankida? JSON-failist. Terraform võimaldab salvestada infrastruktuuri mitte ainult hcl (HashiCorp Configuration Language) vormingus, vaid ka JSON-is.
JSON on shell-skripti kaudu kergesti loetav. Seega saab mingisse kohta paigutada konfigureerimisfaili bucketiga. Ja kasutada seda bucketit nii Terraform-koodis kui ka shell-skripti initsialiseerimiseks.
Miks on oluline omada bucketit Terraformi jaoks? Sellepärast, et on olemas selline asi nagu remote state-failid. See tähendab, et kui ma tõstan mingit ressurssi, pean ma Amazonile ütlema: "Palun tõsta instance", mille jaoks pean ma määrama väga palju kohustuslikke parameetreid.
Ja need tuvastajad salvestatakse kuhugi teise kausta. Ja ma võin öelda: "Terraform, mine palun sealolevale state-failile ja tõsta mulle need tuvastajad üles." Nii tekib teatud ühtsus erinevate piirkondade või keskkondade vahel.
Kauget state-faili ei saa alati kasutada. Näiteks, kui olete käsitsi loonud VPC. Ja see Terraformi kood, mis loob VPC, loob nii erineva VPC, et selle kohandamine on väga aeganõudev ja keeruline, seetõttu võib kasutada järgmist nippi.
Ehkki luua moodul, mis justkui loob VPC ja siiski annab teile tuvastajad, kuid tegelikult on lihtsalt fail, kus on kõvad väärtused, mida saab kasutada sama instance'i loomisel.
Ei ole alati vajalik salvestada state-faili pilve. Näiteks, kui testitakse mooduleid, võib kasutada backendi initsialiseerimist, kus fail salvestatakse testimise ajal lihtsalt kettale.
Nüüd räägime veidi testimisest. Mida saab Terraformis testida? Tõenäoliselt palju, kuid ma räägin nendest neljast asjast.
HashiCorpil on arusaam, kuidas tuleks Terraformi koodi vormindada. Ja Terraform fmt võimaldab teil vormindada teie redigeeritavat koodi vastavalt nende reeglitele. Seega peavad testid tingimata kontrollima, kas vormindamine vastab HashiCorpi pärandile, et ei peaks kohtade vahetama ja nii edasi.
Järgmine on Terraform validate. See teeb veidi enam kui ainult süntaksikontroll – kontrollib näiteks, kas kõik sulud on paarisarvud. Mis on siin oluline? Meie infrastruktuur on väga laialdane. Seal on palju erinevaid kaustu. Ja igaühes tuleb käivitada Terraform validate.
Seetõttu, et testimist kiirendada, käivitame mitu protsessi samaaegselt, kasutades paralleelsust.
Paralleelsus on väga lahe asi, kasutage seda.
Aga iga kord, kui Terraformi initsialiseerimine toimub, läheb ta HashiCorpi ja küsib: „Millised on viimased pluginaversioonid? Ja see plugin, mis mul on cache'is - kas see on õige või vale?“. Ja see aeglustab iga sammu.
Kui Terraformile öelda, kus pluginad asuvad, siis ütleb Terraform: „Kuna see on tõenäoliselt kõige värskem, ei lähe ma kuhugi ning hakkan kohe teie Terraform-koodi valideerima.“
Selleks, et täita kaust vajalike pluginatega, on meil väga lihtne Terraformi kood, mis tuleb lihtsalt initsialiseerida. Siin tuleb muidugi luetleda kõik pakkujad, kes teie koodis osalevad, vastasel juhul ütleb Terraform: „Ma ei tunne seda pakkujat, sest teda pole cache'is.“
Järgmine on Terraformi plaan. Nagu öeldud, on arendus tsükliline. Me teeme koodi muutustega ning pärast seda on vaja välja selgitada, millised muudatused on infrastruktuuri planeeritud.
Ja kui infrastruktuur on väga-äga suur, võib üks moodul muudetud olla, testimiskeskkond parandatud või konkreetne piirkond kahjustatud ning see võib rikkuda mõnda naabruses asuvat. Seetõttu peab Terraformi plaan olema kogu infrastruktuuri jaoks ja näitama, millised muudatused on planeeritud.
Seda saab teha nutikalt. Näiteks oleme kirjutanud Pythonis skripti, mis lahendab sõltuvused. Ja sõltuvalt sellest, mis on muutunud: Terraformi moodul või lihtsalt mõni konkreetne komponent, loob ta plaanid kõigi sõltuvate kaustade jaoks.
Terraformi plaane tuleks teha nõudmisel. Vähemalt on see see, mida meie teeme.
Testid on loomulikult head teha iga muutuse ja iga commit'i jaoks, kuid plaanid on piisavalt kulukad. Ja me pull requestis ütleme: „Palun anna mulle plaanid“. Käivitub robot, kes saadab kommentaaridesse või manusesse kõik plaanid, mis on planeeritud teie muudatustest.
Plaan on üsna kulukas asi. See võtab aega, sest Terraform läheb Amazonisse ja küsib: „Kas see instance on ikka olemas? Kas selle autoscale'i parameetrid on täpselt sellised?“. Ja selle kiirusestamiseks võib kasutada parameetrit refresh=false. See tähendab, et Terraform tõmbab S3-st staatuse. Ja usub, et olek vastab täpselt sellele, mis on Amazonis.
Selline Terraformi plaan kulgeb palju kiiremini, kuid olek peab vastama teie infrastruktuurile, st kuskil, kunagi peab olema käivitatud Terraform refresh. Terraform refresh teeb täpselt seda, et olek vastaks sellele, mis on reaalsetes infrastruktuurides.
Ja tuleb rääkida turvalisusest. Sellega oleks tulnud alustada. Seal, kus te käivitate Terraformi ja Terraform töötab teie infrastruktuuriga, on oht. St, te tõeliselt täidate koodi. Ja kui pull request sisaldab mingit pahatahtlikku koodi, siis see võib käivituda infrastruktuuris, millel on liiga palju ligipääsu. Seetõttu olge ettevaatlik, kus te käivitate Terraformi plaani.
Järgmisena, millest ma tahaksin rääkida, on user-data testimine.
Mis on user-data? Amazonis, kui me loome instantsi, saame instantsilt saata mingi kirja – metaandmed. Kui instants käivitatakse, siis tavaliselt on cloud init alati nende instantside peal. Cloud init loeb seda kirja ja ütleb: „Okei, täna olen ma load balancer”. Ja nende lubaduste kohaselt sooritatakse mingeid toiminguid.
Kahjuks, kui me teeme Terraformi plaani ja Terraformi aplikaatsiooni, paistab user-data välja nagu selline arvu segu. St see lihtsalt saadab teile hash'i. Ja kõik, mida saate plaanis vaadata, on kas mõni muutus toimub või hash jääb täpselt samaks.
Ja kui sellele ei pöörata tähelepanu, võib Amazonisse, reaalsetesse infrastruktuuridesse, minna mingi rikutud tekstifail.
Alternatiivina saate käivitamisel märgata mitte kogu infrastruktuuri, vaid ainult template'i. Ja koodis öelda: „Palun, näita mulle seda template'i”. Ja lõpuks saate väljatrüki, milline teie andmed Amazonis välja näevad.
Teine variant on kasutada moodulit user-data genereerimiseks. Te rakendate selle mooduli. Saate faili kettale. Võrdlete seda referentsfailiga. Ja niimoodi, kui mõni algaja otsustab veidi user-data parandada, ütlevad teie testid: „Okei, siin ja siin on mingid muutused – see on normaalne”.
Järgmisena, millest ma tahaksin rääkida, on Automatiseeritud Terraform aplikaatsioon.
Muidugi on Terraformi aplikaatsiooni automaatne käivitamine üsna hirmuäratav, sest kes teab, millised seal muudatused on ja kui laastavad need võivad olla elavale infrastruktuurile.
Testkeskkonna jaoks on see kõik 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õend sellest, et inimene on vaeva näinud, seadistanud steki, käivitanud stekil mõningad testid. Ja veendunud, et seal on kõik korras ja öelnud: "Okei, see kood, mille ma välja annan, on testitud."
Tootmis-, liivakasti ja teistes keskkondades, mis on ettevõtte jaoks olulisemad, võib osaliselt rakendada mõningaid ressursse piisavalt ohutult, sest see ei too endaga kaasa, et keegi sureb. Need on: autoscale-grupid, turvagrupid, rollid, route53 ja seal võib olla piisavalt suur nimekiri. Kuid jälgige, mis toimub, lugege automaatsete rakenduste aruandeid.
Seal, kus rakendamine on ohtlik või hirmus, näiteks kui tegemist on mõningate püsivate ressurssidega, andmebaasidega, siis saage aruandeid selle kohta, et teatud sektoris infrastruktuuris on rakendamata muudatused. Ja insener, olles järelevalve all, käivitab tööd, et rakendada need või teeb seda oma konsoolist.
Amazonis on selline asi nagu Terminate protection. See võib teatud juhtudel kaitsta teid soovimatute muudatuste eest. See tähendab, et Terraform läheb Amazoni ja ütleb: "Mul on vaja see instants tappa, et teha teine." Aga Amazon ütleb: "Kahjuks ei täna. Meil on aktiveeritud Terminate protection."
Ja tordi kirss – see on koodi optimeerimine. Kui me töötame Terraform-koodiga, peame moduulile edastama väga suure hulga parameetreid. Need on need parameetrid, mis on vajalikud mingite ressursside loomiseks. Ja kood muutub suurteks parameetrite loenditeks, mida tuleb edastada ühest modulist teise, eriti kui moodulid on pesastatud.
Ja see on väga keeruliselt loetav. Selle üle on väga keeruline teha ülevaatust. Ja väga tihti juhtub, et mõned parameetrid saavad ülevaatusest läbi, kuid need pole 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 teatud väärtuste puu. See tähendab, et on vajalik mingi kaust, kus on loetletud kõik väärtused, mida sooviksite mingisuguses keskkonnas omada.
Ja kutsudes seda moodulit, saab luua puu, mis genereeritakse ühes üldises moodulis, st üldises moodulis, mis töötab ühtviisi kogu infrastruktuuri jaoks.
Selles moodulis on võimalik teostada kalkulatsioone, kasutades sellist värsket omadust Terraformis nagu locals. Ja siis üks output’iga anda mingisugune keeruline parameeter, mis võib sisaldada häshe, massiive jne.
Sellega on kõik parimad leidud, mis mul on, otsa saanud. Ja tahaksin rääkida lugu Kolumbusest. Kui ta otsis raha oma ekspeditsioonile, et avastada Indiat (nagu ta tol ajal arvas), ei uskunud keegi temasse ja arvasid, et see on võimatu. Siis ütles ta: "Tehke nii, et muna ei kukuks." Kõik pangandusmehed, väga rikaste ja tõenäoliselt nutikate inimestena, üritasid mingil moel muna püsti seada, kuid see kukkus pidevalt. Siis võttis Kolumbus muna, vajutas sellele natuke. Koor pressiti kokku ja muna jäi liikumatuks. Nad ütlesid: "Oh, see on liiga lihtne!". Ja Kolumbus vastas: "Jah, see on liiga lihtne. Ja kui ma avastan India, siis kõik hakkavad seda kaubateed kasutama."
Ja see, mida ma teile praegu rääkisin, on tõenäoliselt piisavalt lihtsad ja triviaalset asjaolud. Ja kui sa neist kuulete ja hakkate neid kasutama, on see täiesti normaalne. Nii et kasutage. Ja kui need asjad on teie jaoks täiesti normaalsed, siis vähemalt teate, kuidas muna püsti seada, et see ei kukuks.
Teeme kokkuvõtte:
- Püüdke vältida lumesid. Ja mida vähem lumesid, seda vähem ressursse vajate, et teha mingeid muudatusi kogu teie suurtes infrastruktuurides.
- Pidevad muudatused. St. kui koodis on toimunud muudatusi, tuleb teie infrastruktuur viia võimalikult kiiresti vastavusse nende muudatustega. Ei tohi juhtuda, et keegi tuleb kahe-kolme kuu pärast vaatama Elasticsearchi, teeb Terraform plaani ja seal on kuhjaga muudatusi, mida ta ei oodanud. Ja kulub väga palju aega, et kõik tagasi korda saada.
- Testid ja automatiseerimine. Mida rohkem on teie kood kaetud testidega ja funktsioonidega, seda rohkem on teil kindel tunne, et teete kõik õigesti. Ja automaatne tarnimine suurendab teie usaldust mitmekordselt.
- Testi- ja tootmisringkonna kood peab olema praktiliselt identne. Praktiliselt, kuna tootmine on siiski veidi erinev ja seal on ikka mingid nüansid, mis ületavad testimisringkonna piirid. Sellegipoolest on plusspoolel see, et seda on võimalik tagada.
- Ja kui teil on väga palju Terraform-koodi ja selle koodi ajakohasena hoidmine nõuab väga palju aega, siis pole kunagi liiga hilja refaktooringut teha ja see heasse vormi viia.
- Muudetav infrastruktuur. AMI tarnimine ajakava järgi.
- Struktuur route53 jaoks, kui teil on väga palju kirjeid ja soovite, et need oleksid korralikus järjekorras.
- API määrangupiiride ületamine. See on siis, kui Amazon ütleb: "Kõik, kõik, ma ei saa rohkem päringuid võtta, palun oodake." Ja pool ettevõttest ootab, kuni nad saavad oma infrastruktuuri käivitada.
- Spot instantsid. Amazon ei ole odav ettevõtmine ja spotsid võimaldavad palju säästa. Ja sellest võiks rääkida terve ettekande.
- Turvalisus ja IAM rollid.
- Kaotatud ressursside leidmine, kui Amazones on ebamugava päritoluga instantsid, mis söövad raha. Isegi kui instants maksab 100-150 dollarit kuus – aastas on see rohkem kui 1 000. Selliste ressursside leidmine on kasumlik äri.
- Ja reserveeritud instantsid.
Siinkohal on mul kõik. Terraform on väga äge, kasutage seda. Aitäh!
Küsimused
Aitäh ettekande eest! Teil on state-fail S3-s, aga kuidas te lahendate probleemi, et mitu inimest võivad seda state-faili võtta ja proovida seda taasluua?
Esiteks, me ei kiirusta. Teiseks, meil on lipud, millega me teatame, et töötame mõne koodiosa kallal. St kuigi infrastruktuur on väga suur, ei tähenda see, et keegi pidevalt midagi rakendab. Ja kui aktiivne faas oli – oli see probleem, meil oli state-failid Git-is. See oli oluline, vastasel juhul keegi teeb state-faili ja pidime neid käsitsi kokku koguma, et kõik edasi kulgeks. Praegu sellist probleemi ei ole. Aga üldiselt lahendas Terraform selle ülesande. Ja kui pidevalt midagi muutub, siis saad kasutada lukke, mis takistavad seda, mida te ütlesite.
Kasutate avatud versiooni või ettevõtte versiooni?
Mingit ettevõtte versiooni ei ole, 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 muuta instance'i hävitamatuks. See on olemas ka Terraform'is, Life Second plokis saab määrata muutmise keelu või hävitamise keelu.
Aeg oli piiratud. Hea märkamine.
Soovisin veel kahte asja küsida. Esiteks, te rääkisite testimisest. Kas olete kasutanud mingeid tööriistu testimiseks? Olen kuulnud Test Kitchen'i pluginast. Võib-olla on veel midagi. Ja soovin küsida Local Values kohta. Kuidas need üldiselt erinevad Input Variables from? Miks ma ei saa parametrizeerida midagi ainult Local Values kaudu? Olen proovinud seda teemat mõista, kuid ei ole väga aru saanud.
Saame sellest saalist täpsemalt rääkida. Testimise tööriistad – need on meil täielik omavalmistus. Seal ei ole midagi sellist, millega testida. Tegelikult on võimalusi, kus automaatsed testid üles tõstavad infrastruktuuri kuskil, kontrollivad, et see on korras, ja siis kõik hävitavad aruannete koostamisega, et teie infrastruktuur on endiselt heas seisus. Meil seda ei ole, kuna testimissteigid käivituvad iga päev. Ja sellest piisab. Ja kui midagi hakkab katki minema, siis see hakkab katki minema ilma, et me veel kuskil seda kontrollime.
Local Values'i osas jätkame vestlust saalist väljas.
Tere! Aitäh ettekande eest! Väga hariv. Rääkisite, et teil on palju sarnast koodi infrastruktuuri kirjeldamiseks. Kas olete kaalunud selle koodi genereerimise võimalust?
Suurepärane küsimus, aitäh! Tegelikult, kui kasutame infrastruktuuri kui koodi, eeldame, et vaatame koodi ja mõistame, mis infrastruktuur selle koodi taga on. Kui kood genereeritakse, peame ette kujutama, milline kood genereeritakse, et mõista, mis infrastruktuur seal on. Kas me genereerime koodi, kommidime selle ja põhimõtteliselt saame sama asja. Seetõttu läksime teed, mida me kirjutasime, saime selle. Pluss generaatorid tulid mõni aeg hiljem, kui me hakkasime tegema. Ja oli juba hilja seda muuta.
Kas olete jsonnet'ist midagi kuulnud?
Ei.
Vaata, see on väga äge asi. Näen konkreetset kasutusjuhtu, kus seda saab rakendada ja andmestruktuuri genereerida.
Generaatoreid on hea kasutada, kui teil on nagu anekdoot ühekordsest raseerimisaparaadist. Ehkki esmakordselt võib nägu erineda, on hiljem kõigil sama nägu. Generaatoreid on väga tore kasutada. Kuid meil on kahjuks näod natuke erinevad. See on probleem.
Vaata lihtsalt. Aitäh!
Minu nimi on Maksim, olen Sberbankist. Te rääkisite veidi sellest, et üritasite Terraformi tuua programmeerimiskeele analooge. Kas ei oleks lihtsam kasutada Ansible'i?
Need on väga erinevad asjad. Sa saad Ansible'iga ressursse luua ja Puppetiga on võimalik ressursse Amazonis luua. Kuid Terraform on selleks otstarbeks spetsiaalselt loodud.
Kas teil on ainult Amazon?
Probleem ei ole selles, et meil on ainult Amazon. Meil on peaaegu ainult Amazon. Kuid peamine omadus on see, et Terraform mäletab. Ansible'iga, kui sa ütled: „Tõsta mulle 5 instances“, siis ta tõstab need üles, aga siis ütled: „Nüüd tahan 3“. Terraform ütleb: „Okei, 2 lükkan välja“, aga Ansible ütleb: „Okei, siin sul on 3“. Kokku on seega 8.
Tere! Aitäh teie ettekande eest! Oli väga huvitav kuulda Terraformist. Tahan kohe anda väikese kommentaari seoses sellega, et Terraformil tõepoolest puudub stabiilne versioon, seega suhelge Terraformiga suure ettevaatlikkusega.
Hea lusikas on lõunasöögiks. Ehk kui sul on lahendus vajalik, siis mõnikord lükkad edasi selle, mis ei ole stabiilne jne, kuid see töötab ja aitas meid.
Küsimus on selline. Kas te kasutate Remote backend'i, kasutate S3. Miks te ametlikku backend'i ei kasuta?
Ametlik?
Terraform Cloud.
Kuidas see tekkis?
Neli kuud tagasi.
Kui see oleks ilmunud 4 aastat tagasi, siis ilmselt oleksin ma teie küsimusele vastanud.
Seal on juba sisseehitatud funktsioon ja lukud, samuti saab salvestada state-faili. Proovige. Kuid ma ka ei ole seda testinud.
Me sõidame suurel rongil, mis liigub suure kiirusiga. Ja ei saa lihtsalt võtta ja visata mõned vagunid välja.
Te rääkisite lumehelbeist, aga miks te ei kasutanud branch'i? Miks see ei õnnestunud?
Meie lähenemine on selline, et kogu infrastruktuur on ühes hoidlas. Terraform, Puppet, kõik skriptid, mis kuidagi sellega seonduvad, on kõik ühes hoidlas. Nii saame garanteerida, et järkjärgulisi muudatusi testitakse ükshaaval. Kui see oleks hunnik branche, oleks sellist projekti praktiliselt võimatu hooldada. Aastaga nad lahknevad nii palju, et see on lihtsalt karistus. See on see, millest tahaks enne refaktoreerimist eemale pääseda.
Ehk see ei toimi?
See ei tööta üldse.
Branchis lõikasin ma kausta slaidi. St, kui teha iga teststaki jaoks näiteks A meeskonnale oma kaust ja B meeskonnale oma kaust, siis see ei tööta ka. Me tegime ühtse testkeskkonna koodi, mis oli piisavalt paindlik, et sobida kõigile. St, me haldasime ühte koodi.
Tere! Minu nimi on Jüri! Aitäh ettekande eest! Küsimus moodulite kohta. Te ütlete, et kasutate mooduleid. Kuidas te lahendate olukorra, kui ühte moodulit on muudetud nii, et see ei ühildu kellegi teise muudatustega? Kas versioonite mooduleid või proovite tuua midagi, et vastata kahele nõudmisele?
See on suur lumehange. See on see, millest me kannatame, kui mõni ohutu muudatus võib rikkuda mingi osa infrastruktuurist. Ja see on märgatav alles pikema aja pärast.
St, seni ei ole see kuidagi lahendatud?
Teete universaalseid mooduleid. Vältige lumehelbeid. Ja kõik õnnestub. Ettekanne teine pool räägib sellest, kuidas seda vältida.
Tere! Aitäh ettekande eest! Tahaksin täpsustada. Varjatud jäi suur hulk, millepärast ma tulin. Kuidas on integreeritud Puppet ja rollide jaotamine?
User-data.
St, lihtsalt viskate faili välja ja kuidagi teete seda järgi?
User-data on märkmed, st, kui me teeme klooni pildist, siis tõuseb Daemon ja üritab aru saada, kes ta on, loeb märkmeid, et ta on koormuse tasakaalustaja.
St, see on mingi eraldi protsess, mis antakse edasi?
Me ei loonud seda. Me kasutame seda.
Tere! Mul on just küsimus User-data kohta. Te ütlesite, et seal on probleeme, et keegi võib midagi valesti edastada. Kas on mingi viis user-data salvestamiseks samas Git'is, et oleks alati selge, millele user-data viitab?
Meie User-data genereeritakse template'ist. See tähendab, et sinna kasutatakse teatud hulk muutujaid. Ja Terraform genereerib lõpptulemuse. Seetõttu ei saa lihtsalt vaadata template'it ja öelda, mis välja tuleb, sest kõik probleemid on seotud sellega, et arendaja arvab, et ta edastab selle muutuja kaudu stringi, samas kui seal tuleb välja massiiv. Ja siis – ups ja mina – see, see, järgmine rida ja kõik läheb katki. Kui see on uus ressurss ja inimene tõstab selle üles, näeb ta, et midagi ei tööta, siis see lahendatakse kiiresti. Aga kui see on autoscale-grupp, mis on uuendatud, siis mingil hetkel hakkavad autoscale-grupi instantsid vahetuma. Ja ups, midagi ei tööta. See on kurb.
Kas ainus lahendus on testimine?
Jah, te näete probleemi, lisate sinna testimise etapid. See tähendab, et output'i saab samuti testida. Võib-olla ei ole see nii mugav, aga saab ka mingid sildid panna – kontrollige, et User-data on siin naeltega kinni.
Minu nimi on Timur. On väga tore, et on ettekandeid selle kohta, kuidas õigesti Terraform'i organiseerida.
Ma pole isegi veel alustanud.
Ma arvan, et järgmine konverents on võimalik. Mul on lihtne küsimus. Miks te kõvakoodite väärtuse eraldi moodulis, mitte ei kasuta tfvars'i, st mis on mooduli väärtustes parem kui tfvars?
Kuidas oleks, kui ma siin (slaid: Production/environment/settings.tf) kirjutaksin: domain = muutuja, domain vpcnetwork, muutuja vpcnetwork ja stvars – saada välja sama?
Me teeme tõesti samamoodi. Viitame näiteks mooduli setting source'ile.
Põhimõtteliselt on see selline tfvars. Tfvars on testimise keskkonnas väga mugav. Mul on tfvars suuremate instantside jaoks, väikeste jaoks. Ja ma viskasin ühe faili kausta. Ja sain selle, mida tahtsin. Kui me lõikame infrastruktuuri, tahame, et oleks võimalik vaadata ja kohe kõik aru saada. Nii aga on, et pean vaatama siia, siis vaatama tfvars'i.
Kas see tähendab, et kõik oleks ühes kohas?
Jah, tfvars on siis, kui teil on üks kood. Ja see kasutatakse mitmes erinevas kohas erinevate nüanssidega. Siis viskaksite tfvars'i ja saaksite oma nüansid. Ja meie – see on infrastruktuur nagu kood puhtaima vormis. Vaatad ja mõistad.
Tere! Kas olete sattunud olukordadesse, kus pilveteenuse pakkuja sekkub sellesse, mida olete teinud Terraformiga? Oletame, et me redigeerime metadata. Seal on ssh-võtmed. Ja Google pidevalt lisab sinna oma metadata, oma võtmeid. Ja Terraform kirjutab alati, et tal on muudatusi. Iga kord, isegi kui midagi ei muutu, ütleb ta alati, et ta kavatseb seda vahetust värskendada.
Võtmetega, jah, osa infrastruktuurist on sellesse asja haavatud, st Terraform ei saa midagi muuta. Me ei saa ka käega midagi muuta. Elame sellega.
St olete selle olukorraga silmitsi seisnud, aga ei ole midagi välja mõelnud, ta teeb ja teeb ise?
Kahjuks, jah.
Tere! Minu nimi on Starkov Stanislav. Mail.ru Group. Kuidas lahendate probleemi sildi genereerimisel ... kuidas te selle edastate? Ma saan aru, et läbi User—data, et näidata host-nime, suunata Puppet? Ja teine küsimuse osa. Kuidas te seda küsimust lahendate SG-s, st kui genereerite SG-d, sada sarnast instantsi, kuidas neid õigesti nimetada?
Need instantsid, mis on meile väga olulised, me nimetanud ilusasti. Need, mis pole vajalikud, seal on märk, et see on autoscale-grupp. Ja ideeliselt on võimalik see lõpetada ja saada uus.
Sildi probleemide osas pole sellist probleemi, aga on selline ülesanne. Ja sildid on meil väga-väga tugevalt kasutusel, sest infrastruktuur on suur ja kallis. Ja me peame vaatama, kuhu raha läheb, seega sildid võimaldavad jälgida, mis ja kuhu on läinud. Ja vastavalt sellele otsida, et kuski kulutatakse liiga palju raha.
Mille kohta oli veel küsimus?
Kui SG loob sada instantsi, tuleb neid kuidagi eristada?
Ei, ei ole vaja. Igal instantsil on agent, kes teatab, et mul on probleem. Kui agent teatab, siis agent teab temast ja vähemalt tema IP-aadress eksisteerib. Juba saab minna. Teiseks, meil on kasutusel Consul Discovery jaoks, seal, kus ei ole Kubernetes. Ja Consul näitab samuti instantsi IP-aadressi.
St te orienteerute just IP-le, mitte host-nimele?
Ei ole võimalik orienteeruda host-nimele, neid on väga palju. On instantsi identifikaatorid – AE jne. Selle võib kuskil leida, selle võib otsingusse panna.
Tere! Ma sain aru, et Terraform on hea asi, mis on kohandatud pilvede jaoks.
Mitte ainult.
Just this question interests me. If you decide to switch en masse to Bare Metal with all your instances, will there be any problems? Or will you still have to use other products, like the Ansible mentioned here?
Ansible is a bit different. That is, Ansible operates once the instance has started. Terraform works before the instance starts. Switching to Bare Metal is not.
Not right now, but a business will come and say: 'Let's do it'.
Switching to another cloud is possible, but there’s a slightly different aspect here. You need to write Terraform code in such a way that transitioning to another cloud can be done with minimal effort.
Initially, we set the goal that our entire infrastructure should be agnostic, meaning that any cloud should work, but at some point, the business gave in and said: 'Okay, for the next N years we won't go anywhere, we can use services from Amazon.'
Terraform allows you to create Front-End jobs, configure PagerDuty, data docs, etc. It has a lot of capabilities. It can practically control the entire ecosystem.
Thank you for the presentation! I’ve also been working with Terraform for 4 years. During the gradual transition to Terraform, to infrastructure, to declarative descriptions, we encountered situations where someone was doing something manually, and you were trying to create a plan. And you encountered some kind of error. How do you resolve these issues? How do you find the lost resources that were indicated?
Mostly by hand and eye; if we see something strange in the report, we analyze what is happening there, or just delete it. Overall, pull requests are a common practice.
If there is an error, do you perform a rollback? Have you tried doing that?
No, that's a human decision in the moment when he sees a problem.
Allikas: habr.com
