Paljud tunnevad ja kasutavad Terraformi igapäevases töös, kuid parimad tavad on endiselt välja kujunemata. Igal meeskonnal on oma lähenemisviiside ja meetodite väljamõtlemine.
Teie infrastruktuur algab tõenäoliselt lihtsast: paar ressursi + mõned arendajad. Aja jooksul kasvab see igas suunas. Te leiutate viise, kuidas ressursside jaoks Terraformi mooduleid rühmitada, korraldada koodi kaustadesse, ja mis siin üldse valesti minna ei saa? (tuntud viimased sõnad)
Aeg möödub ja te tunnete, et teie infrastruktuur on nagu teie uus lemmikloom, aga miks? Teid häirivad seletamatud muutused infrastruktuuris, te pelgate infrastruktuurile ja koodile läheneda — tulemuseks on see, et te viivitate uue funktsionaalsuse rakendamisega või halvendate kvaliteeti…
Pärast kolme aastat AWS-i jaoks Terraformi kogukonna moodulite haldamist Githubis ja pikaajalist Terraformi tootmises hoidmist, on Anton Babенко valmis jagama oma kogemusi: kuidas kirjutada TF-mooduleid, et tulevikus ei oleks valu.
Esitluse lõpuks saavad osalejad paremini tuttavaks Terraformi ressursihalduse põhimõtetega, seotud parimate praktikatega moodulite kohta ning mõningate pideva integreerimise põhimõtetega, mis on seotud infrastruktuuri haldamisega.
Käesoleva artikli sisu: Tahan märkida, et see ettekande kuupäev on novembrist 2018 — sellest on möödunud juba 2 aastat. Ettekandes arutatud Terraformi versioon 0.11 ei ole enam toetatud. Viimase kahe aasta jooksul on ilmunud 2 uut versiooni, kus on palju uuendusi, täiustusi ja muudatusi. Palun pöörake sellele tähelepanu ja kontrollige dokumentatsiooni.
Lingid:
- +
- — automaatne koodi ja dokumentatsiooni vormindamine
- — Terraformi moodulite generaator (töös)
- — Terraformi koodi generaator visuaalsetest diagrammidest (töös)
- www.terraform-best-practices.com
- (Uued postitused on minu isiklikul veebilehel www.antonbabenko.com/)
- @antonbabenko — Twitter ja palju erinevaid Slacke
Minu nimi on Anton Babenko. Mõned teist on ilmselt kasutanud koodi, mida ma olen kirjutanud. Olen nüüd sellest rääkides kindlam kui kunagi varem, sest mul on juurdepääs statistikale.
Ma tegelen Terraformiga ja olen aktiivne osaleja ning panustaja paljudele avatud lähtekoodiga projektidele, mis on seotud Terraformi ja Amazoni teenustega alates 2015. aastast.
Umbes sellest ajast olen kirjutanud piisavalt koodi, et esitada see huvitaval viisil. Ja sellest ma püüan nüüd rääkida.
Räägin Terraformi keerukusest ja kasutusspetsiifikast. Kuid tegelikult ei ole see HighLoad'i teema. Ja nüüd te mõistate, miks.
Aja jooksul hakkasin kirjutama Terraformi mooduleid. Kasutajad esitasid küsimusi, ma need ümber kirjutasin. Siis kirjutasin erinevaid utiliite koodi vormindamiseks pre-commit hooki abil jne.
Oli palju huvitavaid projekte. Mulle meeldib tegeleda koodigeneratsiooniga, sest mulle meeldib, et arvuti teeks minu ja programmeerija eest järjest rohkem tööd, mistõttu töötan nüüd Terraformi koodi generaatori kallal visuaalsetest diagrammidest. Võib-olla on mõned teist neid näinud. Need on ilusad kastid nooltega. Ja ma arvan, et on fantastiline, kui saab vajutada nuppu 'Eksport' ja saada see kõik koodina.
Ma olen Ukrainast. Olen elanud Norra jaoks palju aastaid.
Samuti on selle ettekande jaoks teavet kogutud inimestelt, kes tunnevad mu nime ja leiavad mind sotsiaalmeedias. Mul on peaaegu alati sama kasutajanimi.
Nagu ma mainisin, olen ma Terraform AWS moodulite peamine hooldaja, mis on üks suurimaid hoidlaid GitHubis, kus majutame mooduleid kõige levinumate ülesannete jaoks: VPC, Autoscaling, RDS.
Ja see, mida te praegu kuulete, on kõige-kõige alus. Kui te kahtlete, et mõistate, mis on Terraform, on parem veeta aega kuskil mujal. Siin on palju tehnilisi termineid. Ja esitluse taset ei ole ma häbenenud maksimaalseks kuulutada. See tähendab, et ma saan rääkida, kasutades kõiki võimalikke termineid ilma eriliku seletamiseta.
Terraform ilmus 2014. aastal kui utiliit, mis võimaldas kirjutada, kavandada ja hallata infrastruktuuri kui koodi. Siin on võtmekontseptsioon 'infrastruktuur kui kood'.
Kogu dokumentatsioon, nagu ma ütlesin, on kirjutatud . Loodan, et enamik on selle saidiga tuttav ja on dokumentatsiooni läbi lugenud. Kui nii, siis olete õiges kohas.
Nii näeb välja tavaline Terraformi konfiguratsioonifail, kus me esmalt defineerime mõned muutujad.
Antud juhul määratleme 'aws_region'.
Seejärel kirjeldame, milliseid ressursse soovime luua.
Käivitame mõned käsud, sealhulgas 'terraform init', et alla laadida sõltuvused ja pakkujad.
Ja käivitame käsu 'terraform apply', et kontrollida, kas määratud konfiguratsioon vastab loodud ressurssidele. Kuna me ei ole varem midagi loonud, pakub Terraform meile nende ressursside loomist.
Kinnitamos selle. Nii loome bucket'i nimega seasnail.
On ka mitu sarnast utiliiti. Paljud teist, kes kasutavad Amazoni, tunnevad AWS CloudFormation'i või Google Cloud Deployment Manager'i, või Azure Resource Manager'i. Igal neist on oma rakendus ressursside haldamiseks nende avalike pilveteenuste pakkujate seas. Terraform on eriti kasulik, kuna see võimaldab hallata rohkem kui 100 pakkujat. (Rohkem )
Terraformi algseteks eesmärkideks olid:
- Terraform annab ühtse ülevaate ressurssidest.
- See võimaldab toetada kõiki kaasaegseid platvorme.
- Terraform on alguses mõeldud utiliidina, mis võimaldab infrastruktuuri turvaliselt ja etteennustatavalt muuta.
2014. aastal kõlas sõna „etteennustatav” selles kontekstis väga ebatavaliselt.
Terraform on universaalne tööriist. Kui teil on API, siis saate hallata kõike:
- Saate kasutada rohkem kui 120 teenusepakkujat kõike, mis teile meeldib, juhtimiseks.
- Näiteks saate Terraformi kasutada GitHub'i hoidlate ligipääsu seadistamiseks.
- Saate isegi Jira bug'e luua ja sulgeda.
- Saate hallata New Relic'i mõõdikuid.
- Võite isegi Dropboxis faile luua, kui väga soovite.
Kõik see saavutatakse Terraform'i teenusepakkujate abil, kellel on avatud API, mis on kirjutatud Go keeles.
Oletame, et hakkasime Terraformi kasutama, lugesime mõnda dokumentatsiooni saidilt, vaatasime videot ja hakkasime kirjutama main.tf, nagu ma eelmistel slaididel näitasin.
Ja teil on kõik suurepärane, teil on fail, mis loob VPC.
Kui soovite luua VPC, siis määrate umbes need 12 rida. Kirjeldage, millises piirkonnas soovite luua, millist cidr_blocki IP-aadresse kasutada. Ja kõik.
Muidugi, projekt kasvab järk-järgult.
Ja te lisate sinna hulga uusi asju: ressursse, andmeallikaid, te integreerite uusi teenusepakkujad, ühel hetkel soovite kasutada Terraformi, et hallata kasutajaid oma GitHubi kontol jne. Te võite soovida kasutada erinevaid DNS-teenusepakkujaid, ühendada erinevaid asju. Terraform muudab selle lihtsaks.
Vaadakem järgmist näidet.
Te lisate järk-järgult internet_gateway, sest soovite, et teie VPC ressursid pääseksid internetti. See on hea mõte.
Lõpuks näeb main.tf välja selline:
See on main.tf ülemine osa.
See on main.tf alumine osa.
Siis lisate subnet'i. Sel hetkel, kui soovite lisada NAT-gatewayd, marsruute, marsruuditabeleid ja hulga teisi subnet'e, ei ole teil enam 38 rida, vaid umbes 200-300 rida.
See tähendab, et teie main.tf fail kasvab järk-järgult. Ja üsna sageli paneb inimesed kõik ühte faili kokku. main.tf-sse tekib 10-20 Kb. Kujutage ette, et 10-20 Kb on tekstiline sisu. Ja kõik on kõikide asjadega seotud. Sellega muutub järk-järgult keeruliseks tegutseda. 10-20 Kb on hea kasutusjuhtum, mõnikord on rohkem. Ja mitte alati ei arva inimesed, et see on halb.
Nagu tavapärases programmeerimises, st mitte infrastruktuur kui kood, oleme harjunud kasutama hulka erinevaid klasse, pakette, mooduleid ja gruppeerimisi. Terraform võimaldab teha peaaegu sama.
- Kood kasvab.
- Sõltuvused ressursside vahel kasvavad samuti.
Ja meil tekib suur vajadus. Me mõistame, et niimoodi elada ei saa. Meie kood muutub üha mahukamaks. 10-20 Kb ei ole muidugi väga mahukas, kuid räägime ainult võrgustikust, st olete lisanud ainult võrguressursid. Me ei ole veel rääkinud rakenduse koormuse tasandist, ES-klastrist, Kubernetesest jne, kuhu on kergesti võimalik lisada veel 100 Kb. Kui kõik need asjad kirja panna, siis avastate väga kiiresti, et Terraform pakub Terraform-mooduleid.
Terraform-moodulid on ise piisav Terraform-konfiguratsioon, mida haldatakse grupina. See on kõik, mida on vaja teada Terraform-moodulitest. Need ei ole mingit moodi targad, nad ei luba teil teha keerulisi sidumisi sõltuvalt millestki. See jääb arendajate õlgadele. St see on lihtsalt mingi Terraform-konfiguratsioon, mille te juba olete kirjutanud. Ja saate lihtsalt kutsuda seda kui gruppi.
Nii püüame mõista, kuidas optimeerida meie 10-20-30 Kb koodi. Aja jooksul saame selgemaks, et peame kasutama teatud mooduleid.
Esimene moodulite tüüp, millega kokku puutume, on ressursimoodulid. Need ei tea, milline on teie infrastruktuur, milline on teie äri, kus ja millised tingimused on. Just need moodulid, mida ma koos avatud lähtekoodi kogukonnaga haldan, on need, mida me esitleme kõige algsemate ehitusplokkidena teie infrastruktuurile.
Ressursimooduli näide.
Kui kutsume ressursimoodulit, näitame, kust me peame selle sisu laadima.
Näitame, millist versiooni me tahame laadida.
Me edastame sinna hulga argumente. Ja kõik. See on kõik, mida peame teadma, kui kasutame seda moodulit.
Paljud arvavad, et kui kasutada viimast versiooni, siis kõik on stabiilne. Kuid nii ei ole. Infrastruktuur peab olema versiooniga, peame selgelt vastama, millise versiooni kohalolek on seotud selle või toote osaga.
Teie ees on kood, mis asub selle mooduli sees. Moodul security-group. Siin keritakse kuni 640. reale. Security-group ressursi loomine Amazonis erinevates konfiguratsioonides on väga keeruline ülesanne. Lihtsalt security-groupi loomine ja reeglite edastamine ei piisa. See oleks liiga lihtne. Amazonis on miljon erinevat piirangut. Näiteks, kui te kasutate VPC endpointi, prefix listi, erinevaid API-sid ja üritate neid kõik koos siduda, siis Terraform ei luba teil seda teha. Samuti ei luba Amazon API seda. Seetõttu tuleb kogu see keeruline loogika peita moodulisse ja kasutajale esitada kood, mis näeb välja vaid nii.
Kasutajal ei ole vaja teada, kuidas see seestpoolt töötab.
Teine moodulite tüüp, mis koosneb ressursimoodulitest, lahendab juba ülesandeid, mis on teie äri jaoks rohkem rakendatavad. Tihti on see koht, mis on Terraformi laiendus ja seab mingid ranged väärtused silte ja ettevõtte standardeid. Samuti saab sinna lisada funktsioone, mida Terraform praegu ei luba kasutada. See on just praegu. Praegu on versioon 0.11, mis on kohe minevikku jäämas. Kuid siiski on eelprotsessorid, jsonnet, cookiecutter ja kõik muud asjad need abimehanismid, mida tuleb täielikuks tööks kasutada.
Edasi näitan ma mõned näited sellest.
Infrastruktuurimoodulit kutsutakse täpselt sama viisi järgi.
Määratakse allikas, kust sisu laadida.
Edastatakse hulk väärtusi, mis antakse sellele moodulile.
Seejärel kutsutakse selle mooduli sees välja hulk ressursimooduleid VPC, rakenduste koormustasakaalu, turvaroheline grupi või Elastic Container Service'i klasstri loomiseks.
On kaks moodulite tüüpi. On oluline seda mõista, sest enamik teavet, mille ma selles ettekandes kokku kogusin, ei ole dokumentatsioonis kirjas.
Terraformi dokumentatsioon on praegu tõeliselt probleemne, sest see ütleb lihtsalt, et on olemas sellised funktsioonid, mida saate kasutada. Kuid see ei selgita, kuidas neid funktsioone kasutada ja miks on nende kasutamine parem. Seetõttu kirjutab väga suur hulk inimesi midagi, millega hiljem on raske edasi elada.
Vaatame nüüd, kuidas neid mooduleid kirjutada. Siis vaatame, kuidas neid kõnele kutsuda ja kuidas koodiga töötada.
Terraform Registry —
Nõuanne nr 0 – ära kirjuta ressursimooduleid. Enamik neist moodulitest on juba sinu eest kirjutatud. Nagu ma ütlesin, on need avatud lähtekoodiga, nad ei sisalda mingit sinu äriloogikat, nendes pole kõvakooditud väärtusi IP-aadresside, paroolide jne jaoks. Moodul on väga paindlik. Ja see on juba tõenäoliselt kirjutatud. Amazonile mõeldud ressursimooduleid on palju. Umbes 650. Ja enamik neist on hea kvaliteediga.
Antud näite puhul tuli teie juurde keegi ja ütles: «Ma tahan olla võimeline hallata andmebaasi. Loo moodul, et saaksin andmebaasi luua». Inimene ei tea Amazonist ega Terraformist üksikasju. Ta lihtsalt ütleb: «Ma tahan hallata MSSQLi». T. e. me eeldame, et ta kutsub meie mooduli, edastab sinna mootori tüübi, määrab ajavööndi.
Ja inimene ei pea teadma, et selle mooduli sees loome kaks erinevat ressursi: ühe MSSQLi jaoks, teise kõigi ülejäänute jaoks, lihtsalt sellepärast, et Terraform 0.11 ei võimalda määrata ajavööndi väärtusi valikuliselt.
Ja selle mooduli väljundina saab inimene lihtsalt adressi. Ta ei tea, millise andmebaasi, millise ressursiga me kõik selle sees loome. See on väga oluline element peitmise osas. Ja see kehtib mitte ainult nende moodulite kohta, mis on avalikud avatud lähtekoodiga, vaid ka nende moodulite kohta, mida te oma projektides, meeskondades kirjutate.
See on teine argument, mis on üsna oluline, kui olete Terraformi kasutanud mõnda aega. Teil on hoidla, kuhu panete kõik oma Terraformi moodulid oma ettevõtte jaoks. Ja on täiesti normaalne, et selle projekti suurus aegade jooksul kasvab ühe või kahe megabaidi suuruseks. See on okei.
Kuid probleem seisneb selles, kuidas Terraform neid mooduleid kutsub. Näiteks, kui kutsete moodulit iga eraldi kasutaja loomiseks, siis Terraform laadib kõigepealt kogu hoidla ja seejärel läheb kausta, kus asub konkreetne moodul. Seega laadite iga kord ühe megabaidi. Kui haldate 100 või 200 kasutajat, laadite 100 või 200 megabaiti ja siis alles minge sinna kausta. Loomulikult ei soovi te iga kord, kui vajutate "Terraform init", laadida terve hunniku asju.
Probleemi lahendamiseks on kaks võimalust. Esimene on kasutada suhtelisi teid. Nii ütlete koodis, et kaust on lokaalne (./). Enne kui midagi käivitada, teete selle reposi Git clone lokaalselt. Nii et teete seda ainult üks kord.
Muidugi on palju miinuseid. Näiteks ei saa kasutada versioonihaldust. Ja sellega on mõnikord raske elada.
Teine lahendus. Kui teil on palju alammodule ja teil on juba mingisugune väljakujunenud pipeline, siis on olemas projekt MBT, mis võimaldab koguda monorepositoorset erinevaid pakette ja laadida need S3-le. See on väga hea meetod. Nii kaalub fail iam-user-1.0.0.zip vaid 1 Kb, kuna selle ressursi loomise kood on väga väike. Ja see töötab palju kiiremini.
Räägime sellest, mida ei tohi moodulites kasutada.
Miks on moodulites see halb? Kõige hirmutavam asi on assume user. Assume user on autentimise variant, mida erinevad inimesed võivad kasutada pakkujas. Näiteks kõik üritame oletada rolli. See tähendab, et Terraform võtab selle rolli ja seejärel sooritab selle rolliga kõik ülejäänud toimingud.
Kurjus peitub selles, et kui Vasja armastab Amazoniga ühendust võtta ühel viisil, näiteks kasutades vaikimist keskkondade muutujaid, ja Petja armastab kasutada oma jagatud võtit, mis tal on salajases kohas, siis Terraformis ei saa mõlemat kasutada. Et nad ei kannataks, ei peaks seda plokki modulis näitama. See tuleb näidata kõrgemal tasandil. St. meil on ressursimoodul, infrastruktuuri moodul ja kõrgem kompositsioon. Ja kuskil kõrgemal tuleb see määrata.
Teine kurjus peitub provisioneris. Siin ei ole kurjus nii triviaalne, kuna kui kirjutate koodi ja see töötab teie jaoks, võite arvata, et kui see töötab, siis miks peaks seda muutma.
Kurjus seisneb selles, et te ei saa alati kontrollida, millal see provisioner täpselt käivitub, esiteks. Teiseks, te ei saa kontrollida, mida tähendab aws ec2, st me räägime praegu Linuxist või Windowsist. Seega ei saa te kirjutada midagi, mis toimiks võrdselt erinevates operatsioonisüsteemides või erinevate kasutusjuhtumite jaoks.
Kõige levinum näide, mis on muu hulgas esitatud ametlikus dokumentatsioonis, on see, et kui te kirjutate aws_instance ja määrate hulga argumente, ei ole seal midagi halba, kui märkida ka provisioner 'local-exec' ja käivitada oma ansible-playbook.
Tegelikult – jah, seal ei ole midagi halba. Kuid peagi mõistate, et see 'local-exec' ei eksisteeri näiteks launch_configuration'is.
Ja kui kasutate launch_configuration'i ja soovite ühest instance'ist luua autoscaling group'i, siis launch_configuration'is ei ole mõistet 'provisioner'. Seal on mõisted 'user data'.
Seetõttu on universaalsemaks lahenduseks user data kasutamine. See käivitub kas vastavalt konkreetses instance'is, kui instance käivitatakse, või selles samas user data's, kui autoscaling group kasutab seda launch_configuration'it.
Kui siiski on soov käivitada provisioner, kuna see on liitkomponent, kui üks ressurss on loodud ja siis tuleb käivitada oma provisioner'i, oma käsklane. Selliseid olukordi on palju.
Ja kõige õigem ressurss selleks on null_resource. Null_resource on fiktiivne ressurss, mida kunagi tõeliselt ei loodud. See ei puuduta midagi, pole API-d, pole autoscalingut. Kuid see võimaldab reguleerida, millal käivitada käsk. Antud juhul käivitub käsk loomise ajal.
Ling
On mitmeid märke. Ma ei plaani kõigil märkidel väga detailselt peatuda. Selle kohta on artikkel. Kuid kui olete töötanud Terraformiga või kasutanud teiste mooduleid, siis olete sageli märganud, et paljusid mooduleid, nagu ka enamik koodi avatud lähtekoodiga, kirjutavad inimesed oma vajaduste jaoks. Inimene kirjutas selle, lahendas oma probleemi. Panin selle GitHubi, las see seal elab. See elab, kuid kui seal pole mingit dokumentatsiooni ja näiteid, siis ei kasuta keegi seda. Ja kui seal pole funktsionaalsust, mis võimaldab lahendada natuke rohkem kui tema konkreetne probleem, siis ei kasuta keegi ka seda. On väga palju viise, kuidas kasutajaid kaotada.
Kui soovite kirjutada midagi, mida inimesed kasutaksid, siis soovitan järgida neid märke.
Need on:
- Dokumentatsioon ja näited.
- Täielik funktsionaalsus.
- Mõistlikud vaikeväärtused.
- Puhtad kood.
- Testid.
Testid on eraldi teema, kuna nende kirjutamine on üsna keeruline. Ma usun rohkem dokumentatsiooni ja näidendeid.
Oleme vaadanud, kuidas mooduleid kirjutada. On kaks argumenti. Esimene, mis on kõige olulisem, on see, et ära kirjuta, kui sa ei pea, sest paljud inimesed on need ülesanded juba sinu eest ära teinud. Ja teine, kui sa siiski otsustad kirjutada, siis püüa mitte kasutada mooduli ja provisionerite pakkujaid.
See on dokumentatsiooni hall ala. Sa võid praegu mõelda: 'Midagi on segane. Ei veennud.' Kuid vaatame kuue kuu pärast.
Nüüd räägime, kuidas neid mooduleid kutsuda.
Me mõistame, et aja jooksul meie kood suureneb. Meil ei ole enam ühte faili, meil on juba 20 faili. Kõik need asuvad ühes kaustas. Või võib-olla viies kaustas. Võib-olla hakkame me neid jagama piirkondade või komponentide järgi. Siis mõistame, et nüüd peavad tekkima mingid sünniksünnmused, orkestreerimine. See tähendab, et peame aru saama, mida teha, kui me muudame võrguressursse, mida teha ülejäänud sõltuvustega jne.
On kaks äärmust. Esimene äärmus on kõik ühes. Meil on üks meistrifail. Kuni teatud ajani oli see Terraformi veebisaidil ametlik best practice.
Kuid nüüd on see kirjutatud kui deprecated ja eemaldatud. Aja jooksul mõistis Terraformi kogukond, et see ei ole kaugeltki best practice, kuna inimesed hakkavad projekti erinevates vormides kasutama. Ja probleeme tekib. Näiteks, kui me määrame kõik sõltuvused ühte kohta. On olukordi, kus vajutame 'Terraform plan' ja enne kui Terraform värskendab kõigi ressursside seisundeid, võib kuluda palju aega.
Palju aega – näiteks 5 minutit. Kellegi jaoks on see palju aega. Olen näinud juhtumeid, kus see kestis 15 minutit. 15 minutit AWS API püsis, et mõista, mis toimub iga ressursi seisundiga. See on tõeliselt suur ala.
Ja loomulikult tekib seotud probleem, kui soovite midagi ühes kohas muuta, siis ootate 15 minutit, ja see annab teile mingi muutuste loendi. Te viskate käed üles, kirjutate "Yes", ja midagi läheb valesti. See on täiesti reaalselt juhtuv näide. Terraform ei püüa teid probleemidest eemal hoida. Seega, kirjutage, mida soovite. Probleemid - teie probleemid. Enne Terraform 0.11 ei püüdnud see teid kuidagi aidata. Versioonis 0.12 on teatud huvitavad kohad, mis võimaldavad teil öelda: "Vassia, kas sa tõeliselt seda soovid, võib-olla peaksid natuke ümber mõtlema?".
Teine viis on selle ala vähendamine, st saab vähem siduda ühte kohtadest teistesse kohtadesse.
Ainuke probleem on selles, et tuleb kirjutada rohkem koodi, st tuleb määratleda muutujad paljusid faile, seda värskendada. Mõnele ei meeldi see. Minu jaoks on see okei. Aga mõned arvavad: "Miks kirjutada see erinevates kohtades, ma viskan selle kõik ühte kohta kokku." Seda saab ka teha, aga see on teine äärmuses.
Kus see kõik elab ühes kohas? Üks, kaks, kolm inimest, st keegi kasutab.
Kes kutsus üles ühe konkreetse komponendi, ühe ploki või ühe infrastruktuuri mooduli? Ligikaudu viis-seitsme inimese jaoks. See on suurepärane.
Kaim vastus on – kuskil keskel. Kui projekt on suur, on sageli olukord, kus kumbki lahendus ei sobi ja mitte kõik ei toimi, seega tekib segu. Sellest pole midagi halba, peaasi, et mõistate, et mõlemal on oma eelised.
Kui stack VPC-s on midagi muutunud ja soovite neid muudatusi rakendada EC2-s, st soovite uuendada autoscaling gruppi, kuna olete saanud uue subneti, siis nimetaksin ma selliseid sõltuvusi orkestreerimiseks. Kas on olemas mõni lahendus: kuidas keegi seda kasutab?
Ma võin soovitada, millised lahendused on olemas. Võite kasutada Terraform'i, et teha imet, või kasutada make-failide abil Terraform'i. Ja vaadata, kui seal on midagi muutunud, saate siin käivitada.
Kuidas teile selline lahendus meeldib? Kas keegi usub, et see on suurepärane lahendus? Ma näen naeratust, ilmselt on kahtlused sisse hiilinud.
Muidugi, ärge proovige seda kodus. Terraform'i ei ole kunagi loodud käivitamiseks Terraform'ist.
Ühes ettekandes öeldi mulle: „Ei, see ei toimi.” Asjaolu on see, et see ei peagi toimima. Kuigi see näeb välja muljetavaldav, kui sa saad Terraformist käivitada Terraformi, mis käivitab veel Terraformi, siis ära tee nii. Terraform peaks alati käivituma väga lihtsalt.
Kui sul on vajadus kutsuda üles orkestreerimist, kui midagi kuskil muutub, siis on olemas Terragrunt.
Terragrunt on utiliit, Terraformi laiendus, mis võimaldab koordineerida ja orkestreerida infrastruktuuri moodulite üleskutsumist.
Tüüpiline Terraformi konfigureerimisfail näeb välja selline.
Sa märkid, millist konkreetselt moodulit sa soovid kutsuda.
Millised on mooduli sõltuvused.
Ja millised argumendid see moodul vastu võtab. See on kõik, mis on vajalik Terragrunti kohta teada.
Seal on dokumentatsioon, 1 700 tähekaarti GitHubis. Kuid enamikes juhtudel on see see, mida on vaja teada. Ja seda on väga lihtne juurutada ettevõtetes, kes on just hakanud töötama Terraformiga.
Seega on orkestreerimine Terragrunt. Teisi variante on olemas.
Nüüd räägime, kuidas koodiga töötada.
Kui teil on vaja lisada koodi uusi funktsioone, siis enamikul juhtudel on see lihtne. Te kirjutate uue ressursi, siin on kõik lihtne.
Kui teil on mingisugune ressurss, mille olete eelnevalt loonud, näiteks olete Terraformist kuulnud pärast AWS-konto avamist ja soovite kasutada juba olemasolevaid ressursse, siis on mõistlik laiendada oma moodulit selliselt, et see toetaks olemasolevate ressursside kasutamist.
Ja toetaks uute ressursside loomist, kasutades ressursi blokk.
Väljundina tagastame alati väljundi ID olenevalt sellest, mis oli kasutusel.
Teine väga oluline probleem Terraform 0.11-s on töötlus nimekirjadega.
Raskus seisneb selles, et kui meil on selline nimekiri users.
Ja kui me loome neid kasutajaid, kasutades ressursi blokki, siis kõik läheb hästi. Me läheme läbi kogu nimekirja, loome igaühele faili. Kõik on korras. Ja siis, näiteks, kui user3, kes on nimekirja keskel, tuleb siit eemaldada, siis kõik ressursid, mis on loodud pärast teda, loovad end uuesti, kuna indeks muutub.
Töötamine loenditega stateful-keskkonnas. Mis on stateful-keskkond? See on olukord, kus uus väärtus ilmneb selle ressursi loomisel. Näiteks AWS Access Key või AWS Secret Key, st kui me loome kasutaja, saame uue Access või Secret Key. Ja iga kord, kui me kustutame mõne kasutaja, on selle kasutaja jaoks uus võti. Kuid see ei ole hea tava, sest kasutaja ei taha meiega suhelda, kui me peame iga kord looma uue kasutaja, kui keegi rühmast lahkub.
Lahendus on selline. See on kood, mis on kirjutatud Jsonnetis. Jsonnet on Google'i шаблоonide loomise keel.
See käsk võimaldab võtta selle шаблон ja väljundis tagastab see json-faili, mis on tehtud vastavalt teie шаблонile.
Шаблон näeb välja selline.
Terraform võimaldab töötada nii HCL-i kui ka Jsoniga võrdselt, seega kui teil on võimalus genereerida Json, siis võite selle anda Terraformile. Faili laiendusega .tf.json laaditakse edukalt üles.
Ja siis töötame sellega nagu tavaliselt: terraform init, terraform apply. Ja loome kaks kasutajat.
Nüüd ei karda me, kui keegi tiimist lahkub. Me lihtsalt muudame json-faili. Vassja Pupkin lahkus, Petja Pjatoškin jäi. Petja Pjatoškin ei saa uut võtit.
Terraformi integreerimine teiste vahenditega ei ole tegelikult Terraformi ülesanne. Terraform loodi ressursside loomiseks ja ainult selleks. Kõik, mis selle juurde sobib – pole Terraformi mure. Ja seda ei peaks sinna segama. On olemas Ansible, mis teeb kõik vajaliku.
Siiski tekivad olukorrad, kus soovime Terraformi täiendada ja kutsuda mõnda käsku peale mõne tegevuse täitmist.
Esimene meetod. Loome väljundi, kuhu kirjutame selle käsu.
Ja siis kutsume selle käsu välja shellis terraform output, näidates seda väärtust, mida soovime. Nni käivitub käsk kõigi asendatud väärtustega. See on väga mugav.
Teine meetod. See on null_resource kasutamine sõltuvalt meie infrastruktuuri muutustest. Saame kutsuda sama local-exec'i, kohe kui mingi ressursi ID muutub.
Muidugi, see kõik tundub sujuv paberil, kuna Amazon, nagu kõik teised avalikud pakkujad, omab hulganisti oma äärmuslikke olukordi.
Tüüpiline äärmuslik juhtum on see, et kui avate AWS-i konto, on oluline, milliseid piirkondi te kasutate; kas funktsioon on seal lubatud; võib-olla avasite selle pärast 2013. aasta detsembrit; võib-olla kasutate VPC-s vaikeseadeid jne. Piiranguid on palju. Ja Amazon on need dokumentatsiooni hajutanud.
Mõned asjad, mida ma soovitan vältida.
Esiteks vältige kõiki salajaseid argumente Terraformi plaanis või Terraformi CLI-s. Kõik need saab panna kas tfvars-faili või keskkonnamuutujasse.
Aga pole vaja meelde jätta kogu seda maagilist käsku. Terraform plan – var ja edasi. Esimene muutuja – var, teine muutuja – var, kolmas, neljas. Kõige olulisem põhimõte infrastruktuuri kui koodi puhul, mida ma kõige sagedamini kasutan, on see, et vaatamata koodile peaksin ma selgelt mõistma, mis on seal juurutatud, millises seisundis ja milliste väärtustega. Seetõttu ei pea ma lugema dokumentatsiooni või küsima Vasjalt, milliseid parameetreid ta meie klastrite loomiseks kasutas. Mul on piisav, et avada tfvars-fail, mis sageli vastab keskkonnale, ja vaadata kõik seal.
Samuti ei tohiks kasutada target-argumente, et piirata ulatust. Selleks on palju lihtsam kasutada väikeseid infrastruktuuri mooduleid.
Samuti ei tohiks piirata ja suurendada parallelismi. Kui mul on 150 ressurssi ja soovin suurendada Amazonis parallelismi 10-lt, mis on vaikimisi, 100-le, siis tõenäoliselt läheb midagi valesti. Või võib nüüd minna hästi, kuid kui Amazon ütleb, et teete liiga palju päringuid, siis ilmneda probleemid.
Terraform püüab enamikke neist probleemidest uuesti käivitada, kuid te ei saavuta peaaegu midagi. Parallelism=1 on oluline asi, mida tuleb kasutada, kui olete kinni jäänud mõne veaga AWS API-s või Terraformi pakkujas. Ja siis peate määrama: parallelism=1 ja ootama, kuni Terraform lõpetab ühe päringu, siis teise, siis kolmanda. Ta käivitab need järjestikku.
Sageli küsin: "Miks ma arvan, et Terraformi tööruumid on kurjad?" Usun, et infrastruktuuri kui koodi põhimõte seisneb selles, et näha, milline infrastruktuur on loodud ja milliste väärtustega.
Workspaces ei olnud kasutajate algatus. See ei tähenda, et kasutajad oleksid GitHubi probleemides öelnud, et nad ei saa elada ilma Terraform workspaces'ita. Ei, see ei ole nii. Terraform Enterprise on ärilahendus. HashiCorpi Terraform leidis, et meil on vaja workspaces'e, seega tegime selle teoks. Minu arvates oleks seda palju lihtsam eraldi kausta panna. Siis on rohkem faile, kuid see on arusaadavam.
Kuidas koodiga töötada? Põhimõtteliselt, töötamine loenditega on ainus probleem. Ja võtke Terraformi lihtsamalt. See ei ole asi, mis teeb kõik teie eest suurepäraselt. Ärge pange sinna kõike, mis on dokumentatsioonis kirjutatud.
Ettekande teemal oli kirjutatud 'tuleviku jaoks'. Ma räägin sellest väga lühidalt. Tuleviku jaoks – see tähendab, et varsti ilmub välja versioon 0.12.
0.12 on palju uut. Kui olete tulnud tavalise programmeerimise maailmast, siis igatsete igasuguste dünaamiliste blokide, tsüklite ja korrektsete tingimuslike võrdlusoperatsioonide järele, kus vasak ja parem külg ei arvutata samal ajal, vaid sõltuvalt olukorrast. Te igatsete seda väga, seega 0.12 lahendab selle teie jaoks.
Kuid! Kui sa kirjutad vähem ja lihtsamalt, kasutades valmis mooduleid ja kolmandate osapoolte lahendusi, siis ei pea sa ootama ja lootma, et 0.12 tuleb ja kõik sinu eest korda teeb.
Aitäh ettekande eest! Sa rääkisid infrastruktuurist kui koodist ja mainisid teste vaid ühes sõnas. Kas moodulites on testid vajalikud? Kelle vastutus see on? Kas tuleb ise kirjutada või on see moodulite kohustus?
Järgmine aasta tuleb ettekannetest, kus oleme otsustanud kõike testida. Mis on see, mida testida - see on suurim küsimus. On palju sõltuvusi, palju piiranguid erinevatelt teenusepakkujatelt. Kui me sinuga räägime ja sa ütled: "Mul on vaja teste", siis ma küsin: "Mida sa hakkad testima?". Sa ütled, et testid oma regioonis. Siis ma ütlen, et minu regioonis see ei toimi. See tähendab, et me ei saa isegi selles osas kokku leppida. Rääkimata kõigist tehnilistest probleemidest. See tähendab, et kuidas kirjutada neid teste, et need oleksid adekvaatsed.
Uurin seda teemat aktiivselt, st kuidas automatiseeritud testide genereerimist selle infrastruktuuri põhjal, mille sa oled kirjutanud. St kui sa oled kirjutanud selle koodi, pean ma selle käivitama, mille põhjal saan luua testid.
– see on üks kõige sagedamini mainitud teeke, mis võimaldab kirjutada integratsiooniteste Terraformi jaoks. See on üks utiliite. Mulle meeldib rohkem DSL-tüüpi, näiteks rspec.
Anton, aitäh ettekande eest! Minu nimi on Valery. Luba mul esitada natuke filosoofiline küsimus. On olemas tinglikult provisioning ja deployment. Provisioning loob minu infrastruktuuri, deployment aga täidab seda millegi kasuliku, näiteks serverite, rakendustega jne. Minu peas on arusaam, et Terraform on rohkem mõeldud provisioning'uks, samas kui Ansible on rohkem deployment'iks, kuna Ansible võimaldab ka füüsilisele infrastruktuurile nginx'i, Postgres'i paigaldamist. Kuid samas näib, et Ansible'il on ka provisioning'i võimalus, näiteks Amazon või Google'i ressursid. Kuid ka Terraform võimaldab oma moodulite abil mingit tarkvara deploy'da. Kuidas sina seda näed? Kas on mingi piir, mis eristab Terraform'i ja Ansible'i ning millal ja mida on parem kasutada? Või arvad, et Ansible on juba obsolete ja peaksime püüama Terraform'i kasutada kõikehõlmavalt?
Hea küsimus, Valeri. Minu arvates pole Terraform alates 2014. aastast oma eesmärgis muutunud. See on loodud infrastruktuuri jaoks ja sureb infrastruktuuri nimel. Meie vajadus configuration management'i, nagu Ansible, jääb endiselt ja jääb alati. Probleemiks on, et seal on launch_configuration'i sees user data. Ja seal sa käivitad Ansible'i jne. See on see standardne eristus, mis mulle kõige rohkem meeldib.
Kui me räägime kaunilt kujundatud infrastruktuurist, siis on olemas tööriistu nagu Packer, mis loob selle pildi. Ja edasi kasutab Terraform andmeallikat, et seda pilti leida ja oma launch_configuration'i uuendada. See tähendab, et pipeline seisneb selles, et me käivitame esmalt Trackeri, seejärel käivitame Terraform'i. Ja kui toimub build, siis toimub uus muudatus.
Tere! Aitäh ettekande eest! Minu nimi on Misha, ettevõte RBS. Ansible'i saab käivitada provisioner'i kaudu, kui ressursse luuakse. Lisaks on Ansible'il olemas selline funktsioon nagu dünaamiline inventuur. Esiteks saab käivitada Terraform'i, seejärel Ansible'i, mis võtab state'ist ressurssidest ja täidab need. Mis on parem?
Mõlemat kasutatakse inimestele sama edukalt. Minu arvates on Ansible'i dünaamiline inventuur mugav asi, kui me ei räägi autoskalimisgruppidest. Kuna autoskalimisgrupis on meil juba oma tööriist, mida nimetatakse launch_configuration'iks. Me salvestame launch_configuration'isse kõik, mida on vaja käivitada, kui loome uue ressursi. Seega, Amazonis dünaamilise inventuuri kasutamine ja Terraformi ts-faili lugemine tundub mulle üleliigne. Kui aga kasutate teisi vahendeid, kus ei ole mõistet „autoskalimisgrupp”, näiteks kasutate DigitalOceanit või mõnda muud teenusepakkujat, kus autoskalimisgruppi ei ole, peate API-d käsitsi kasutama, leidma IP-aadresse, koostama dünaamilise inventuuri faili ning Ansible liigub selle järgi. See tähendab, et Amazonis on launch_configuration, kuid muude teenuste puhul on dünaamiline inventuur.
Allikas: habr.com
