Baie mense ken en gebruik Terraform in hul daaglikse werk, maar daar is steeds geen beste praktyke daarvoor nie. Elke span moet sy eie benaderings en metodes uitdink.
Jou infrastruktuur begin byna seker eenvoudig: 'n paar hulpbronne + 'n paar ontwikkelaars. Met verloop van tyd groei dit in alle rigtings. Vind jy maniere om hulpbronne in Terraform-modules te groepeer, kode in dopgehou te organiseer, en wat anders kan moontlik verkeerd gaan? (bekende laaste woorde)
Tyd gaan verby en jy voel dat jou infrastruktuur jou nuwe troeteldier is, maar hoekom? Jy is bekommerd oor onverklaarbare veranderinge in die infrastruktuur, jy is bang om die infrastruktuur en kode aan te raak - gevolglik vertraag jy nuwe funksionaliteit of verminder kwaliteit ...
Na drie jaar se bestuur van 'n versameling Terraform-gemeenskapsmodules vir AWS op Github en langtermyn-onderhoud van Terraform in produksie, is Anton Babenko gereed om sy ervaring te deel: hoe om TF-modules te skryf sodat dit nie in die toekoms seermaak nie.
Aan die einde van die praatjie sal deelnemers meer vertroud wees met Terraform-hulpbronbestuurbeginsels, Terraform-moduleverwante beste praktyke en sommige infrastruktuurbestuurverwante deurlopende integrasiebeginsels.
Vrywaring: Ek neem kennis dat hierdie verslag gedateer is November 2018 - 2 jaar is verby. Die weergawe van Terraform 0.11 wat in die verslag oorweeg word, word nie meer ondersteun nie. Oor die afgelope 2 jaar is 2 nuwe vrystellings vrygestel, waarin baie innovasies, verbeterings en veranderinge verskyn het. Gee asseblief aandag hieraan en kontroleer die dokumentasie.
verwysings:
- +
- - outoformatering van kode en dokumentasie
- - genereerder van Terraform-modules (WIP)
- - Terraform-kodegenerator vanaf visuele diagramme (WIP)
- www.terraform-best-practices.com
- (Nuwe plasings is op die persoonlike webwerf www.antonbabenko.com/)
- @antonbabenko - Twitter, en 'n klomp verskillende Slacks
My naam is Anton Babenko. Sommige van julle het seker die kode gebruik wat ek geskryf het. Ek sal nou met meer selfvertroue as ooit hieroor praat, want ek het toegang tot statistieke.
Ek is betrokke by Terraform en was sedert 2015 'n aktiewe bydraer en bydraer tot 'n groot aantal oopbronprojekte wat met Terraform en Amazon verband hou.
Sedertdien het ek genoeg kode geskryf om dit interessant te maak. En ek sal probeer om nou hieroor te praat.
Ek sal praat oor die ingewikkeldhede en besonderhede van die werk met Terraform. Maar in werklikheid is dit nie 'n onderwerp vir HighLoad nie. En nou sal jy verstaan hoekom.
Met verloop van tyd het ek Terraform-modules begin skryf. Gebruikers het vrae geskryf, ek het dit herskryf. Toe het ek verskeie kodeformateringshulpmiddels geskryf met pre-commit-hakies, ens.
Daar was baie interessante projekte. Ek hou daarvan om kodegenerering te doen, want ek hou daarvan dat die rekenaar meer en meer werk vir my en die programmeerder doen, so ek werk tans aan 'n Terraform-kodegenerator vanaf visuele diagramme. Miskien het sommige van julle hulle gesien. Dit is pragtige bokse met pyle. En ek dink dit is wonderlik as jy op die "Uitvoer"-knoppie kan klik en dit alles as kode kan kry.
Ek is van die Oekraïne. Ek woon al baie jare in Noorweë.
Die inligting vir hierdie verslag is ook ingesamel van mense wat my naam ken en my op sosiale netwerke vind. Ek het amper altyd dieselfde bynaam.
Soos ek genoem het, is ek die hoofonderhouer van Terraform AWS-modules, wat een van die grootste GitHub-bewaarplekke is waar ons modules aanbied vir die mees algemene take: VPC, Autoscaling, RDS.
En wat jy nou gehoor het, is die mees basiese. As jy twyfel of jy verstaan wat Terraform is, dan is dit beter om jou tyd iewers anders deur te bring. Daar sal baie tegniese terme hier wees. En ek het nie geskroom om die vlak van die verslag as die hoogste te verklaar nie. Dit beteken dat ek kan praat deur al die moontlike terme te gebruik sonder veel verduideliking.
Terraform het in 2014 verskyn as 'n hulpprogram waarmee u infrastruktuur as kode kon skryf, beplan en bestuur. Die sleutelkonsep hier is "infrastruktuur as kode".
Alle dokumentasie, soos ek gesê het, is in geskryf . Ek hoop die meeste mense weet van hierdie webwerf en het die dokumentasie gelees. Indien wel, dan is jy op die regte plek.
Dit is hoe 'n gewone Terraform-konfigurasielêer lyk, waar ons eers 'n paar veranderlikes definieer.
In hierdie geval definieer ons "aws_region".
Dan beskryf ons watter hulpbronne ons wil skep.
Ons voer 'n paar opdragte uit, veral "terraform init" om afhanklikhede, verskaffers te laai.
En ons voer die "terraform application"-opdrag uit om te kyk of die gespesifiseerde konfigurasie ooreenstem met die hulpbronne wat ons geskep het. Aangesien ons nog niks voorheen geskep het nie, stel Terraform voor dat ons hierdie hulpbronne skep.
Ons bevestig dit. Dit is hoe ons 'n emmer skep genaamd seenael.
Daar is ook verskeie soortgelyke nutsprogramme. Baie van julle wat Amazon gebruik, ken AWS CloudFormation of Google Cloud Deployment Manager of Azure Resource Manager. Elkeen van hulle het 'n soort implementering vir die bestuur van hulpbronne binne elk van hierdie openbare wolkverskaffers. Terraform is veral nuttig omdat dit jou toelaat om meer as 100 verskaffers te bestuur. (Meer )
Die doelwitte wat Terraform van die begin af nagestreef het:
- Terraform gee jou 'n enkele siening van hulpbronne.
- Laat jou toe om alle moderne platforms te ondersteun.
- En Terraform is van die begin af ontwerp as 'n hulpprogram waarmee u die infrastruktuur veilig en voorspelbaar kan verander.
In 2014 het die woord “voorspelbaar” baie ongewoon in hierdie konteks geklink.
Terraform is 'n universele hulpmiddel. As jy 'n API het, kan jy absoluut alles beheer:
- Jy kan meer as 120 verskaffers gebruik om alles te bestuur wat jou hart begeer.
- U kan byvoorbeeld Terraform gebruik om toegang tot GitHub-bewaarplekke te beskryf.
- Jy kan selfs foute in Jira skep en toemaak.
- Jy kan New Relic-statistieke bestuur.
- Jy kan selfs lêers in dropbox skep as jy regtig wil.
Dit word alles bereik met behulp van Terraform-verskaffers, wat 'n oop API het wat in Go beskryf kan word.
Kom ons sê ons het Terraform begin gebruik, dokumentasie op die webwerf gelees, video gekyk, main.tf begin skryf, soos ek op die vorige skyfies gewys het.
En alles is cool met jou, jy het 'n lêer wat 'n VPC skep.
As jy 'n VPC wil skep, spesifiseer jy ongeveer hierdie 12 reëls. Beskryf in watter streek jy wil skep, watter cidr_block van IP-adresse om te gebruik. En dit is dit.
Natuurlik sal die projek geleidelik groei.
En jy sal 'n klomp nuwe goed daar byvoeg: hulpbronne, databronne, jy sal met nuwe verskaffers integreer, ewe skielik sal jy Terraform wil gebruik om gebruikers in jou GitHub-rekening te bestuur, ens. wil verskillende DNS-verskaffers gebruik, kruis alles. Terraform maak dit maklik.
Beskou die volgende voorbeeld.
Jy voeg geleidelik internet_gateway by omdat jy wil hê dat hulpbronne van jou VPC toegang tot die internet moet hê. Dit is 'n goeie idee.
Die resultaat is hierdie main.tf:
Dit is die top van main.tf.
Dit is die onderste deel van main.tf.
Dan voeg jy subnet by. Teen die tyd dat jy NAT-poorte, roetes, roeteringstabelle en 'n klomp ander subnette wil byvoeg, sal jy nie 38 lyne hê nie, maar ongeveer 200-300 lyne.
Dit wil sê, jou hoof.tf-lêer groei geleidelik. En dikwels plaas mense alles in een lêer. 10-20 Kb verskyn in main.tf. Stel jou voor dat 10-20 Kb teksinhoud is. En alles is aan alles verbind. Dit word al hoe moeiliker om mee te werk. 10-20 Kb is 'n goeie gebruikersgeval, soms meer. En mense dink nie altyd dis sleg nie.
Soos in konvensionele programmering, dit wil sê nie infrastruktuur as kode nie, is ons gewoond daaraan om 'n klomp verskillende klasse, pakkette, modules, groeperings te gebruik. Terraform laat jou toe om dieselfde te doen.
- Die kode groei.
- Hulpbronafhanklikheid neem ook toe.
En ons het 'n groot, groot behoefte. Ons verstaan dat ons nie meer so kan lewe nie. By ons word die kode enorm. 10-20 Kb is natuurlik nie baie groot nie, maar ons praat net van die netwerkstapel, dit wil sê jy het net netwerkbronne bygevoeg. Ons praat nie van Application Load Balancer, ontplooiing ES cluster, Kubernetes, ens., waar 100 Kb steeds maklik geweef kan word nie. As jy dit alles skryf, sal jy baie gou uitvind dat Terraform Terraform-modules verskaf.
Terraform-modules is selfstandige Terraform-konfigurasies wat as 'n groep bestuur word. Dit is al wat jy moet weet oor Terraform-modules. Hulle is glad nie slim nie, hulle laat jou nie toe om enige komplekse verbindings te maak afhangende van iets nie. Dit val alles op die skouers van die ontwikkelaars. Dit wil sê, dit is net 'n soort Terraform-konfigurasie wat jy reeds geskryf het. En jy kan dit net as 'n groep noem.
Ons probeer dus uitvind hoe ons ons 10-20-30 Kb kode gaan optimaliseer. Ons verstaan geleidelik dat ons sommige modules moet gebruik.
Die eerste tipe modules wat teëgekom word, is hulpbronmodules. Hulle verstaan nie waaroor jou infrastruktuur gaan, waaroor jou besigheid gaan, waar en watter toestande nie. Dit is presies die modules wat ek saam met die oopbrongemeenskap administreer, en wat ons as die heel aanvanklike boustene vir jou infrastruktuur voorhou.
'n Voorbeeld van 'n hulpbronmodule.
Wanneer ons 'n hulpbronmodule oproep, spesifiseer ons vanaf watter pad ons die inhoud daarvan moet laai.
Ons spesifiseer watter weergawe ons wil aflaai.
Ons gee 'n klomp argumente daar deur. En dit is al. Dit is al wat ons moet weet wanneer ons hierdie module gebruik.
Baie mense dink dat as jy die nuutste weergawe gebruik, alles stabiel sal wees. Maar nee. Die infrastruktuur moet versier word, ons moet duidelik antwoord watter weergawe hierdie of daardie komponent ontplooi is.
Hier is die kode wat binne hierdie module is. sekuriteitsgroep module. Hier gaan die boekrol op na die 640ste reël. Die skep van 'n hulpbronsekuriteitskroep in Amazon in allerhande konfigurasies is 'n baie nie-triviale taak. Dit is nie genoeg om net 'n sekuriteitsgroep te skep en vir hom te sê watter reëls om daaraan deur te gee nie. Dit sou baie maklik wees. Binne Amazon is daar 'n miljoen verskillende beperkings. Byvoorbeeld, as jy gebruik VPC-eindpunt, voorvoegsellys, verskeie API's en probeer om dit alles met alles te kruis, dan laat Terraform jou nie toe om dit te doen nie. En die Amazon API laat dit ook nie toe nie. Daarom moet ons al hierdie verskriklike logika in 'n module wegsteek en die gebruiker 'n kode gee wat net so lyk.
Die gebruiker hoef nie te weet hoe dit binne gedoen word nie.
Die tweede tipe modules, wat uit hulpbronmodules bestaan, los reeds take op wat meer van toepassing is op jou besigheid. Dikwels is dit 'n plek wat 'n uitbreiding vir Terraform is en 'n paar harde waardes stel vir etikette, vir maatskappystandaarde. Jy kan ook funksionaliteit daar byvoeg wat Terraform jou nie tans toelaat om te gebruik nie. Dis nou reg. Nou weergawe 0.11, wat op die punt staan om iets van die verlede te word. Maar tog is voorverwerkers, jsonnet, koekiesnyer en 'n klomp ander dinge die hulpmeganisme wat vir volwaardige werk gebruik moet word.
Vervolgens sal ek 'n paar voorbeelde hiervan wys.
Die infrastruktuurmodule word op presies dieselfde manier genoem.
Spesifiseer die bron van waar om die inhoud af te laai.
'n Klomp waardes word geslaag, wat na hierdie module oorgedra word.
Verder, binne hierdie module, word 'n klomp hulpbronmodules geroep om 'n VPC of Application Load Balancer te skep, of om 'n sekuriteitsgroep of 'n Elastic Container Service-groepering te skep.
Daar is twee tipes modules. Dit is belangrik om te verstaan, want die meeste van die inligting wat ek in hierdie verslag gegroepeer het, is nie in die dokumentasie geskryf nie.
En die dokumentasie in Terraform op die oomblik is nogal problematies, want dit sê net dat daar sulke kenmerke is, jy kan dit gebruik. Maar sy sê nie hoe om hierdie kenmerke te gebruik nie, hoekom dit beter is om dit te gebruik. Daarom skryf 'n baie groot aantal mense iets waarmee jy later nie kan saamleef nie.
Kom ons kyk hoe om hierdie modules volgende te skryf. Dan sal ons sien hoe om hulle te bel en hoe om met die kode te werk.
Terraform-register -
Wenk #0 is om nie hulpbronmodules te skryf nie. Die meeste van hierdie modules is reeds vir jou geskryf. Soos ek gesê het, hulle is oopbron, hulle bevat nie enige van jou besigheidslogika nie, hulle het nie hardgekodeerde waardes vir IP-adresse, wagwoorde, ens. Die module is baie buigsaam. En dis seker reeds geskryf. Daar is baie modules vir hulpbronne van Amazon. Sowat 650. En die meeste van hulle is van goeie gehalte.
In hierdie voorbeeld kom iemand na jou toe en sê: "Ek wil die databasis kan bestuur. Skep 'n module sodat ek 'n databasis kan skep." Die persoon ken nie die implementeringsbesonderhede van Amazon of Terraform nie. Dit sê net "Ek wil MSSQL bestuur". Dit wil sê, ons bedoel dat dit ons module sal oproep, die enjintipe daar sal slaag en die tydsone sal aandui.
En 'n persoon moet nie weet dat ons twee verskillende hulpbronne binne hierdie module sal skep nie: een vir MSSQL, die tweede vir alles anders, net omdat jy in Terraform 0.11 nie tydsonewaardes as opsioneel kan spesifiseer nie.
En by die uitvoer van hierdie module sal 'n persoon eenvoudig die adres kan ontvang. Hy sal nie weet uit watter databasis, uit watter hulpbron ons dit alles binne skep nie. Dit is 'n baie belangrike element van wegkruip. En dit is nie net van toepassing op daardie modules wat publiek in oopbron is nie, maar ook vir daardie modules wat jy binne jou projekte, spanne sal skryf.
Dit is die tweede argument, wat redelik belangrik is as jy Terraform al 'n rukkie gebruik het. Jy het 'n bewaarplek waar jy al jou Terraform-modules vir jou maatskappy stoor. En dit is heel normaal dat hierdie projek met verloop van tyd tot 'n grootte van een of twee megagrepe sal groei. Dit is goed.
Maar die probleem is hoe Terraform hierdie modules noem. Byvoorbeeld, as jy 'n module oproep om elke individuele gebruiker te skep, sal Terraform eers die hele repository aflaai, en dan na die gids gaan waar hierdie spesifieke module geleë is. Op hierdie manier sal jy elke keer een megagreep aflaai. As jy 100 of 200 gebruikers bestuur, sal jy 100 of 200 megagrepe aflaai en dan na daardie gids gaan. So, natuurlik, jy wil nie 'n klomp goed laai elke keer as jy "Terraform init" druk nie.
Daar is twee oplossings vir hierdie probleem. Die eerste is om relatiewe paaie te gebruik. Dit is hoe jy in die kode spesifiseer dat die gids plaaslik is (./). En voordat jy enigiets hardloop, doen jy 'n Git-kloon van daardie bewaarplek plaaslik. So jy doen dit een keer.
Daar is natuurlik 'n klomp nadele. Byvoorbeeld, dat jy nie weergawe kan gebruik nie. En soms is dit moeilik om daarmee saam te leef.
Tweede oplossing. As jy baie submodules het en jy het reeds 'n soort geïnstalleerde pyplyn, dan is daar 'n MBT-projek waarmee jy baie verskillende pakkette van 'n monorepository kan versamel en dit na S3 kan oplaai. Dit is 'n baie goeie manier. Dus, die iam-user-1.0.0.zip-lêer sal slegs 1 Kb wees, want die kode vir die skep van hierdie hulpbron is baie klein. En dit sal baie vinniger werk.
Kom ons praat oor wat nie in modules gebruik kan word nie.
Hoekom is dit sleg in modules? Die engste ding is om 'n gebruiker te aanvaar. Gestel gebruiker is 'n verifikasie opsie vir 'n verskaffer wat deur verskillende mense gebruik kan word. Ons sal byvoorbeeld almal 'n rol aanneem. Dit beteken dat Terraform hierdie rol sal aanneem. En dan met hierdie rol sal ander aksies uitvoer.
En die kwaad is dat as Vasya daarvan hou om op een manier met Amazon te koppel, byvoorbeeld deur 'n veranderlike omgewing by verstek te gebruik, en Petya hou daarvan om sy gedeelde sleutel te gebruik, wat hy op 'n geheime plek het, dan kan albei nie in Terraform gespesifiseer word nie. . En sodat hulle nie lyding kan ervaar nie, moet hierdie blok nie in die module gespesifiseer word nie. Dit moet op die boonste vlak aangedui word. Dit wil sê, ons het 'n hulpbronmodule, 'n infrastruktuurmodule en 'n samestelling bo-op. En iewers hoër moet dit aangedui word.
Die tweede euwel is die voorsiener. Die boosheid hier is nie so triviaal nie, want as jy kode skryf en dit werk vir jou, dan dink jy dalk dat as dit werk, hoekom dit dan verander.
Die kwaad lê daarin dat jy nie altyd hierdie voorsiener beheer wanneer dit spesifiek bekendgestel sal word nie, eerstens. En tweedens, jy beheer nie wat aws ec2 beteken nie, maw ons praat nou van Linux of van Windows. U kan dus nie iets skryf wat dieselfde sal werk op verskillende bedryfstelsels of vir verskillende gebruikersgevalle nie.
Die mees algemene voorbeeld, wat ook in die amptelike dokumentasie aangedui word, is dat as jy aws_instance skryf, 'n klomp argumente spesifiseer, dan is daar niks fout daarmee as jy ook die voorsiener "local-exec" daar spesifiseer en jou ansible laat loop -speelboek.
Eintlik, ja, daar is niks fout daarmee nie. Maar letterlik gou sal jy agterkom dat hierdie local-exec ding nie bestaan nie, byvoorbeeld in launch_configuration.
En wanneer jy launch_configuration gebruik, en jy wil 'n outoskaalgroep vanaf een instansie skep, dan is daar geen konsep van "provisioner" in launch_configuration nie. Daar is die konsep van "gebruikersdata".
Daarom is 'n meer universele oplossing om gebruikersdata te gebruik. En dit sal óf op die instansie self geloods word, wanneer die instansie geaktiveer is, óf in dieselfde gebruikerdata, wanneer die outoskaalgroep hierdie launch_configuration sal gebruik.
As daar nietemin 'n begeerte is om 'n voorsiener te begin, omdat dit 'n gomkomponent is, wanneer een hulpbron geskep word en op hierdie oomblik moet jy jou voorsiener, jou span, begin. Daar is baie sulke situasies.
En die mees korrekte hulpbron hiervoor word null_resource genoem. Null_resource is 'n skynhulpbron wat nooit werklik geskep word nie. Dit raak aan niks, geen API, geen outoskaal nie. Maar dit laat jou toe om te beheer wanneer om die opdrag uit te voer. In hierdie geval word die opdrag uitgevoer tydens skeppingstyd.
Link
Daar is verskeie tekens. Ek gaan nie in detail in op al die kenmerke nie. Daar is 'n artikel daaroor. Maar as jy met Terraform gewerk het of ander mense se modules gebruik het, dan het jy dikwels opgemerk dat baie modules, soos meeste van die kode in oopbron, deur mense vir hul eie behoeftes geskryf is. Die man het dit geskryf, sy probleem opgelos. Ek het dit op GitHub gemaak, laat dit lewe. Dit sal leef, maar as daar geen dokumentasie en voorbeelde is nie, dan sal niemand dit gebruik nie. En as daar geen funksionaliteit is wat jou toelaat om 'n bietjie meer as sy spesifieke taak op te los nie, dan sal niemand dit ook gebruik nie. Daar is soveel maniere om gebruikers te verloor.
As jy iets wil skryf vir mense om te gebruik, beveel ek aan om hierdie tekens te volg.
Dit is:
- Dokumentasie en voorbeelde.
- Volle funksionaliteit.
- Redelike verstek.
- Skoon kode.
- Toetse.
Toetse is 'n aparte situasie omdat dit redelik moeilik is om te skryf. Ek glo meer in dokumentasie en in voorbeelde.
Ons het dus gesien hoe om modules te skryf. Daar is twee argumente. Eerstens, en die belangrikste, moenie skryf as jy kan nie, want 'n klomp mense het al hierdie take voor jou gedoen. En die tweede, as jy nog steeds besluit, probeer dan om nie verskaffers in modules en voorsiener te gebruik nie.
Dit is die grys deel van die dokumentasie. Nou dink jy dalk: “Iets is nie duidelik nie. Nie oortuig nie.” Maar ons sal oor ses maande sien.
Kom ons praat nou oor hoe om hierdie modules te noem.
Ons verstaan dat ons kode mettertyd groei. Ons het nie meer een lêer nie, ons het reeds 20 lêers. Almal van hulle is in een gids. Of dalk vyf dopgehou. Miskien begin ons hulle op een of ander manier volgens streek, volgens sommige komponente afbreek. Dan verstaan ons dat ons nou 'n paar beginsels van sinchronisasie het, orkestrasie moet ontstaan. Dit wil sê, ons moet verstaan wat om te doen as ons netwerkhulpbronne verander het, wat om met die res van ons hulpbronne te doen, hoe om hierdie afhanklikhede te noem, ens.
Daar is twee uiterstes. Die eerste uiterste is alles in een. Ons het een meesterlêer. Vir eers was dit die amptelike beste praktyk op die Terraform-webwerf.
Maar nou word dit geskryf as afgekeur en verwyder. Mettertyd het die Terraform-gemeenskap besef dat dit ver van die beste praktyk is, want mense begin die projek op verskillende maniere gebruik. En daar is probleme. Byvoorbeeld, wanneer ons alle afhanklikhede op een plek spesifiseer. Daar is situasies wanneer ons op "Terraform plan" klik en dit kan baie tyd neem vir Terraform om die toestande van alle hulpbronne op te dateer.
Baie tyd is byvoorbeeld 5 minute. Vir sommige is dit baie tyd. Ek het gevalle gesien waar dit 15 minute geneem het. 15 minute AWS API het gedraai om te verstaan wat met die toestand van elke hulpbron gebeur. Dit is 'n baie groot area.
En natuurlik sal 'n verwante probleem verskyn wanneer jy iets op een plek wil verander, dan wag jy 15 minute, en dit gee jou 'n doek van 'n paar veranderinge. Jy het gespoeg, "Ja" geskryf, en iets het verkeerd geloop. Dit is 'n baie werklike voorbeeld. Terraform probeer nie om jou van probleme te isoleer nie. Dit wil sê, skryf wat jy wil. Daar sal probleme wees - jou probleme. Terwyl Terraform 0.11 jou op geen manier probeer help nie. Daar is sekere interessante plekke in 0.12 wat jou toelaat om te sê: "Vasya, wil jy dit regtig hê, kan jy van plan verander?".
Die tweede manier is om hierdie area te verminder, dit wil sê, oproepe van een plek vanaf 'n ander plek kan minder verbind word.
Die enigste probleem is dat jy meer kode moet skryf, dit wil sê jy moet veranderlikes in 'n groot aantal lêers beskryf, dit moet opdateer. Iemand hou nie daarvan nie. Vir my is dit normaal. En sommige mense dink: "Hoekom skryf dit op verskillende plekke, ek sal dit alles op een plek zakolbas." Dit is moontlik en so, maar dit is die tweede uiterste.
Wie het dit alles op een plek? Een, twee, drie mense, dit wil sê iemand gebruik.
En wie noem een spesifieke komponent, een blok of een infrastruktuurmodule? Vyf tot sewe mense. Dit is gaaf.
Die mees algemene antwoord is iewers in die middel. As die projek groot is, sal jy dikwels 'n situasie hê waar nie een van die oplossings geskik is nie en nie alles daar uitwerk nie, so jy eindig met 'n mengsel. Daar is niks fout hiermee nie, solank jy verstaan dat daar 'n voordeel aan albei is.
As iets in die stapel VPC verander het en jy wil hierdie EC2 veranderinge toepas, dit wil sê jy wil die outoskaalgroep opdateer omdat jy 'n nuwe subnet het, dan noem ek hierdie soort afhanklikheidsorkestrasie. Daar is 'n paar oplossings: wie gebruik wat?
Ek kan voorstel wat oplossings is. Jy kan Terraform gebruik om die towerkrag te doen, of jy kan make-lêers gebruik om Terraform te gebruik. En kyk, as iets daar verander het, kan jy dit hier laat loop.
Hoe hou jy van hierdie besluit? Glo iemand dat dit 'n oulike oplossing is? Ek sien 'n glimlag, ek sien twyfel het ingesluip.
Moet dit natuurlik nie tuis herhaal nie. Terraform is nooit ontwerp om van binne Terraform af te hardloop nie.
By een verslag is vir my gesê: "Nee, dit sal nie werk nie." Die ding is, dit behoort nie te werk nie. Alhoewel dit so indrukwekkend lyk as jy Terraform vanaf Terraform kan begin, en daar is ook Terraform, maar jy hoef dit nie te doen nie. Terraform moet altyd baie eenvoudig begin.
As jy oproepe moet orkestreer wanneer iets op een plek verander het, dan is daar Terragrunt.
Terragrunt is 'n hulpprogram, dit is 'n byvoeging tot Terraform, wat jou toelaat om oproepe na infrastruktuurmodules te koördineer en te orkestreer.
'n Tipiese Terraform-konfigurasielêer lyk so.
Jy spesifiseer watter spesifieke module jy wil oproep.
Watter module het afhanklikhede.
En watter argumente hierdie module aanvaar. Dit is al wat daar is om te weet oor Terragrunt.
Die dokumentasie is daar, 1 700 sterre op GitHub is ook daar. Maar in die meeste gevalle is dit wat jy moet weet. En dit is baie maklik om te implementeer in maatskappye wat pas met Terraform begin werk het.
So orkestrasie is Terragrunt. Daar is ander opsies.
Kom ons praat nou oor hoe om met die kode te werk.
As jy 'n behoefte het om nuwe kenmerke by die kode te voeg, is dit in die meeste gevalle maklik. Jy skryf 'n nuwe hulpbron, alles is eenvoudig hier.
As jy een of ander hulpbron het wat jy vooraf geskep het, byvoorbeeld, jy het van Terraform uitgevind nadat jy 'n AWS-rekening oopgemaak het en die hulpbronne wil gebruik wat jy reeds het, dan sal dit gepas wees om jou module op hierdie manier uit te brei. dat dit die gebruik van bestaande hulpbronne ondersteun.
En ondersteun die skepping van nuwe hulpbronne met behulp van die blokhulpbron.
By uitset gee ons altyd 'n uitvoer-ID terug, afhangend van wat gebruik is.
Die tweede baie belangrike probleem in Terraform 0.11 is om met lyste te werk.
Die moeilikheid lê in die feit dat as ons so 'n lys van gebruikers het.
En wanneer ons hierdie gebruikers skep met behulp van die blokhulpbron, gaan alles goed. Ons gaan deur die hele lys, skep 'n lêer vir elkeen. Alles is reg. En dan, byvoorbeeld, user3, wat in die middel is, moet van hier verwyder word, dan sal al die hulpbronne wat daarna geskep is, hulle herskep word, want die indeks sal verander.
Werk met lyste in 'n statige omgewing. Wat is 'n statige omgewing? Dit is die situasie waar 'n nuwe waarde voorkom wanneer die hulpbron geskep word. Byvoorbeeld, AWS-toegangsleutel of AWS-geheime sleutel, dit wil sê wanneer ons 'n gebruiker skep, ontvang ons 'n nuwe toegangs- of geheime sleutel. En elke keer as ons 'n gebruiker uitvee, sal daardie gebruiker 'n nuwe sleutel hê. Maar dit is nie feng shui nie, want die gebruiker sal nie vriende met ons wil wees as ons 'n nuwe gebruiker vir hom skep elke keer as iemand die span verlaat nie.
Die oplossing is dit. Dit is kode geskryf in Jsonnet. Jsonnet is 'n sjabloontaal van Google.
Hierdie opdrag laat jou toe om hierdie sjabloon te aanvaar en by die uitvoer gee dit 'n json-lêer terug wat volgens jou sjabloon gemaak is.
Die sjabloon lyk so.
Terraform laat jou toe om op dieselfde manier met beide HCL en Json te werk, so as jy die vermoë het om Json te genereer, kan jy dit in Terraform inskuif. Die .tf.json-lêer sal suksesvol opgelaai word.
En dan werk ons soos gewoonlik daarmee: terraform init, terramorm toepas. En ons skep twee gebruikers.
Nou is ons nie bang as iemand die span verlaat nie. Ons sal net die json-lêer wysig. Vasya Pupkin het vertrek, Petya Pyatochkin het gebly. Petya Pyatochkin sal nie 'n nuwe sleutel ontvang nie.
Die integrasie van Terraform met ander gereedskap is nie in werklikheid Terraform se werk nie. Terraform is geskep as 'n platform vir hulpbronskepping en dit is dit. En alles wat daarna kom, is nie Terraform se bekommernis nie. En jy hoef dit nie daar te sit nie. Daar is Ansible, wat alles doen wat nodig is.
Maar daar is situasies wanneer ons Terraform wil aanvul en 'n opdrag wil oproep nadat iets voltooi is.
Eerste manier. Ons skep uitset waar ons hierdie opdrag skryf.
En dan noem ons hierdie opdrag vanaf dop terraform-uitvoer en spesifiseer hierdie waarde wat ons wil hê. Dus, die opdrag word uitgevoer met al die vervang waardes. Dit is baie gemaklik.
Die tweede manier. Dit is die gebruik van null_resource afhangende van veranderinge in ons infrastruktuur. Ons kan dieselfde plaaslike uitvoerende beampte bel sodra die ID van sommige hulpbron verander.
Natuurlik is dit alles glad op papier, want Amazon, soos alle ander openbare verskaffers, het 'n klomp van sy eie randsake.
Die mees algemene randgevalle is dat wanneer jy 'n AWS-rekening oopmaak, dit saak maak watter streke jy gebruik; of hierdie kenmerk daar ingesluit is; dalk het jy dit ná Desember 2013 oopgemaak; miskien gebruik jy verstek in VPC ens. Daar is baie beperkings. En Amazon het hulle oor die hele dokumentasie gestrooi.
Daar is 'n paar dinge wat ek aanbeveel om te vermy.
Om mee te begin, vermy alle nie-geheime argumente binne die Terraform-plan of Terraform CLI. Dit alles kan óf by 'n tfvars-lêer óf by 'n omgewingsveranderlike gevoeg word.
Maar jy hoef nie hierdie hele magiese opdrag te memoriseer nie. Terraform plan - var en weg ons gaan. Die eerste veranderlike is var, die tweede veranderlike is var, die derde, vierde. Die belangrikste infrastruktuur-as-kode-beginsel wat ek die meeste gebruik, is dat ek net deur na die kode te kyk, perfek moet kan verstaan wat daar ontplooi word, in watter toestand en met watter waardes. En daarom hoef ek nie die dokumentasie te lees of vir Vasya te vra oor watter parameters hy gebruik het om ons groep te skep nie. Dit is vir my genoeg om 'n lêer oop te maak met die tfvars-uitbreiding, wat dikwels by die omgewing pas, en alles daar te sien.
Moet ook nie teikenargumente gebruik om die omvang te verklein nie. Dit is baie makliker om klein infrastruktuurmodules hiervoor te gebruik.
Moet ook nie parallelisme beperk en verhoog nie. As ek 150 hulpbronne het en Amazon se parallelisme van 10, wat die verstek is, na 100 wil verhoog, sal iets waarskynlik verkeerd gaan. Of dit gaan dalk nou goed, maar wanneer Amazon sê jy maak te veel oproepe, is jy in die moeilikheid.
Terraform sal probeer om die meeste van hierdie probleme te herbegin, maar jy sal amper niks bereik nie. Parallelisme=1 is 'n belangrike ding om te gebruik as jy oor 'n fout in die AWS API of binne die Terraform-verskaffer struikel. En dan moet jy spesifiseer: parallelisme=1 en wag totdat Terraform een oproep voltooi, dan die tweede, dan die derde. Hy sal hulle een vir een lanseer.
Mense vra my dikwels: "Hoekom dink ek is Terraform-werkruimtes boos?". Ek glo die beginsel van infrastruktuur as kode is om te sien watter infrastruktuur geskep is en met watter waardes.
Werkspasies is nie deur gebruikers geskep nie. Dit beteken nie dat gebruikers in GitHub-kwessies geskryf het dat hulle nie sonder Terraform-werkruimtes kan leef nie. Nee nie so nie. Terraform Enterprise is 'n kommersiële oplossing. Terraform van HashiCorp het besluit dat ons werkspasies nodig het, so ons sal dit neerlê. Ek vind dit baie makliker om dit in 'n aparte gids te plaas. Dan sal daar 'n bietjie meer lêers wees, maar dit sal duideliker wees.
Hoe om met kode te werk? Trouens, werk met lyste is die enigste pyn. En neem Terraform makliker. Dit is nie die soort ding wat jou wonderlik sal laat voel nie. Dit is nie nodig om alles wat in die dokumentasie geskryf is, daar te skuif nie.
Die onderwerp van die verslag is geskryf "vir die toekoms". Ek sal dit baie kortliks sê. Vir die toekoms beteken dit dat 0.12 binnekort vrygestel sal word.
0.12 is 'n klomp nuwe goed. As jy van gewone programmering kom, mis jy allerhande dinamiese blokke, lusse, gereelde en voorwaardelike vergelykingsoperasies, waar die linker- en regterdele nie gelyktydig bereken word nie, maar afhangende van die situasie. Jy mis dit baie, so 0.12 sal dit vir jou oplos.
Maar! As jy minder en makliker skryf, met behulp van klaargemaakte modules, derdeparty-oplossings, dan hoef jy nie te wag en te hoop dat 0.12 sal kom en alles vir jou regmaak nie.
Dankie vir die verslag! Jy het oor infrastruktuur as kode gepraat en letterlik een woord oor toetse gesê. Is eenheidstoetse nodig? Wie se verantwoordelikheid is dit? Moet ek dit self skryf of is dit die verantwoordelikheid van die modules?
Volgende jaar sal gebombardeer word met berigte dat ons besluit het om alles te toets. Wat om te toets is die grootste vraag. Daar is baie afhanklikhede, baie beperkings van verskillende verskaffers. Wanneer ek en jy gesels en jy sê: “Ek het toetse nodig”, dan vra ek: “Wat sal jy toets?”. Jy sê dat jy in jou streek sal toets. Dan sê ek in my streek werk dit nie. Dit wil sê, ons kan nie eers met jou hieroor saamstem nie. Om nie te praat dat daar baie tegniese probleme is nie. Dit wil sê hoe om hierdie toetse te skryf sodat hulle voldoende is.
Ek ondersoek hierdie onderwerp aktief, dit wil sê hoe om toetse outomaties te genereer gebaseer op die infrastruktuur wat jy geskryf het. Dit wil sê, as jy hierdie kode geskryf het, moet ek dit laat loop, op grond hiervan kan ek toetse skep.
- dit is een van die biblioteke wat die meeste genoem word waarmee u integrasietoetse vir Terraform kan skryf. Dit is een van die nutsdienste. Ek verkies 'n DSL-tipe soos rspec.
Anton, dankie vir die verslag! My naam is Valery. Laat ek jou 'n bietjie filosofiese vraag vra. Daar is, voorwaardelik, voorsiening, daar is ontplooiing. Voorsiening skep my infrastruktuur, in ontplooiing vul ons dit met iets nuttigs, byvoorbeeld bedieners, toepassings, ens. En dit sit in my kop dat Terraform meer is vir voorsiening, en Ansible is meer vir ontplooiing, want Ansible is ook op die fisiese infrastruktuur laat jou toe om nginx, Postgres te installeer. Maar terselfdertyd lyk dit of Ansible jou toelaat om byvoorbeeld Amazon- of Google-hulpbronne te voorsien. Maar Terraform laat jou ook toe om sekere sagteware met behulp van sy modules te ontplooi. Vanuit jou oogpunt, is daar enige grens tussen Terraform en Ansible, waar en wat is beter om te gebruik? Of dink jy byvoorbeeld dat Ansible reeds rommel is, moet jy Terraform vir alles probeer gebruik?
Goeie vraag, Valery. Ek glo dat Terraform nie verander het in terme van doel sedert 2014 nie. Dit is gebou vir infrastruktuur en het gesterf vir infrastruktuur. Ons het steeds die konfigurasiebestuur van Ansible gehad en sal dit nodig hê. Die uitdaging is dat daar gebruikersdata binne launch_configuration is. En daar trek jy Ansible, ens. Dit is die standaardafbakening waarvan ek die meeste hou.
As ons van pragtige infrastruktuur praat, dan is daar nutsdienste soos Packer wat hierdie beeld bou. En dan gebruik Terraform die databron om hierdie prent te vind en sy launch_configuration op te dateer. Dit wil sê, op hierdie manier bestaan die pyplyn in die feit dat ons eers Tracker trek, dan Terraform trek. En as daar 'n gebou was, dan vind 'n nuwe verandering plaas.
Hallo! Dankie vir die verslag! My naam is Misha, RBS-maatskappy. Jy kan Ansible deur 'n voorsiener bel wanneer jy 'n hulpbron skep. En ook in Ansible is daar so 'n onderwerp soos dinamiese inventaris. En jy kan eers Terraform bel, en dan Ansible bel, wat hulpbronne van die staat sal neem en dit sal uitvoer. Wat is beter?
En dit en dat mense met identiese sukses gebruik. Dit lyk vir my dat dinamiese voorraad in Ansible 'n gerieflike ding is, as ons nie van 'n outoskaalgroep praat nie. Want in die outoskaalgroep het ons reeds ons eie toolkit genaamd launch_configuration. Ons skryf in launch_configuration alles wat geloods moet word wanneer ons 'n nuwe hulpbron skep. So met Amazon wat dinamiese voorraad gebruik en die Terraform ts-lêer lees, is dit na my mening oordrewe. En as jy ander gereedskap gebruik waar daar geen konsep van "outoskaalgroep" is nie, jy gebruik byvoorbeeld DigitalOcean of 'n ander verskaffer waar daar geen outoskaalgroep is nie, dan sal jy daar die API-handvatsels moet trek, IP-adresse vind, skep 'n dinamiese voorraadlêer, en Ansible sal reeds daarin rondswerf. Dit wil sê, vir Amazon is daar launch_configuration, en vir al die ander is daar dinamiese voorraad.
Bron: will.com