Dit wil voorkom asof die Terraform-ontwikkelaars redelik gerieflike beste praktyke bied om met die AWS-infrastruktuur te werk. Net daar is 'n nuanse. Met verloop van tyd neem die aantal omgewings toe, kenmerke verskyn in elkeen. Verskyn amper 'n kopie van die aansoekstapel in die naburige streek. En die Terraform-kode moet noukeurig gekopieer en geredigeer word volgens die nuwe vereistes of om 'n sneeuvlok te maak.
My verslag handel oor patrone in Terraform om chaos en handroetine op groot en lang projekte te bekamp.
Video:
Ek is 40, ek is al 20 jaar in IT. Ek werk al 12 jaar by Ixtens. Ons is besig met e-handelsgedrewe ontwikkeling. En ek oefen al 5 jaar lank DevOps-praktyke.
My storie sal handel oor die ervaring in 'n projek in 'n maatskappy wie se naam ek nie sal sê nie, wegkruip agter 'n nie-openbaarmakingsooreenkoms.
Die nommers op die skyfie word gegee om die omvang van die projek te verstaan. En alles wat ek volgende gaan sê, hou verband met Amazon.
Ek het 4 jaar gelede by hierdie projek aangesluit. En die herfaktorering van infrastruktuur was in volle swang, want die projek het gegroei. En daardie patrone wat gebruik is, hulle pas nie meer nie. En gegewe al die beplande groei van die projek, was dit nodig om met iets nuuts vorendag te kom.
Dankie aan Matvey, wat ons gister vertel het wat by Dodo Pizza gebeur het. Dit is wat 4 jaar gelede met ons gebeur het.
Ontwikkelaars het gekom en begin om infrastruktuurkode te maak.
Die mees voor die hand liggende redes waarom dit nodig was, was tyd om te bemark. Dit was nodig om seker te maak dat die DevOps-span nie 'n bottelnek was tydens die uitrol nie. En onder andere is Terraform en Puppet op die heel eerste vlak gebruik.
Terraform is 'n oopbronprojek van HashiCorp. En vir die wat glad nie weet wat dit is nie, die volgende paar skyfies.
Infrastruktuur as kode beteken dat ons ons infrastruktuur kan beskryf en sommige robotte kan vra om seker te maak dat ons die hulpbronne kry wat ons beskryf het.
Ons benodig byvoorbeeld 'n virtuele masjien. Ons sal beskryf, voeg 'n paar vereiste parameters by.
Daarna sal ons toegang tot Amazon in die konsole konfigureer. En vra vir Terraform-plan. Terraform plan sal sê: "Ok, vir jou hulpbron, ons kan hierdie dinge doen." En ten minste een hulpbron sal bygevoeg word. En geen veranderinge word verwag nie.
Nadat alles jou pas, kan jy Terraform vra aansoek doen en Terraform sal 'n instansie vir jou skep, en jy sal 'n virtuele masjien in jou wolk kry.
Verder ontwikkel ons projek. Ons voeg 'n paar veranderinge daar by. Ons vra vir meer gevalle, ons voeg 53 inskrywings by.
En ons herhaal. Beplan asseblief. Ons sien watter veranderinge beplan word. Doen aansoek. En so groei ons infrastruktuur.
Terraform gebruik so iets soos staatlêers. Dit wil sê, dit stoor al die veranderinge wat na Amazon gaan in 'n lêer, waar daar vir elke hulpbron wat jy beskryf, ooreenstemmende hulpbronne is wat in Amazon geskep is. Dus, wanneer die beskrywing van 'n hulpbron verander word, weet Terraform presies wat in Amazon verander moet word.
Hierdie staatslêers was oorspronklik net lêers. En ons het hulle in Git gestoor, wat uiters ongerieflik was. Iemand het gedurig vergeet om veranderinge te pleeg, en daar was baie konflikte.
Nou is dit moontlik om die backend te gebruik, dit wil sê Terraform word aangedui in watter emmer, deur watter sleutel die toestandlêer gestoor moet word. En Terraform sal self sorg vir die kry van hierdie toestandlêer, al die towerkrag doen en die finale resultaat terugsit.
Ons infrastruktuur groei. Hier is ons kode. En nou wil ons nie net 'n virtuele masjien skep nie, ons wil 'n toetsomgewing hê.
Terraform laat jou toe om so iets soos 'n module te maak, dit wil sê dieselfde ding in een of ander gids te beskryf.
En, byvoorbeeld, in toetsing, bel hierdie module en kry dieselfde ding asof ons Terraform-toepassing in die module self doen. Hier is die kode vir toetsing.
Vir produksie kan ons 'n paar veranderinge daarheen stuur, want in toetsing het ons nie groot gevalle nodig nie, in produksie sal groot gevalle handig te pas kom.
En dan gaan ek terug na die projek. Dit was 'n moeilike taak, die infrastruktuur was baie groot beplan. En dit was nodig om op een of ander manier al die kode te plaas sodat dit vir almal gerieflik sou wees: vir diegene wat onderhoud op hierdie kode uitvoer, en vir diegene wat veranderinge aanbring. En daar is beplan dat enige ontwikkelaar die infrastruktuur kan gaan regmaak soos nodig vir sy deel van die platform.
Dit is 'n gidsboom wat deur HashiCorp aanbeveel word as jy 'n groot projek het en dit maak sin om die hele infrastruktuur in 'n paar klein stukkies te verdeel, en elke stuk in 'n aparte gids te beskryf.
Met 'n uitgebreide hulpbronbiblioteek, kan jy omtrent dieselfde ding bel in toetsing en in produksie.
In ons geval was dit nie heeltemal geskik nie, want die toetsstapel vir ontwikkelaars of vir toetsing moes op een of ander manier eenvoudiger verkry word. En ek wou nie deur die dopgehou gaan en in die regte volgorde aansoek doen nie, en bekommerd wees dat die basis sou styg, en dan sou die instansie wat hierdie basis gebruik, styg. Daarom is alle toetse vanaf een gids geloods. Dieselfde modules is daar genoem, maar alles het in een lopie deurgegaan.
Terraform sorg vir alle afhanklikhede. En dit skep altyd hulpbronne in daardie volgorde sodat jy 'n IP-adres kan kry, byvoorbeeld van 'n varsgeskepte instansie, en hierdie IP-adres in die roete53-inskrywing kan kry.
Boonop is die platform baie groot. En om 'n toetsstapel te bestuur, al is dit vir 'n uur, al is dit vir 8 uur, is nogal 'n duur besigheid.
En ons het hierdie besigheid geoutomatiseer. En die Jenkins-werk het die stapel toegelaat om te hardloop. Dit was nodig om 'n trekversoek daarin te begin met die veranderinge wat die ontwikkelaar wil toets, spesifiseer al die nodige opsies, komponente en groottes. As hy prestasietoetsing wil hê, kan hy meer gevalle neem. As hy net moet kyk dat een of ander vorm oopmaak, kan hy by die minimum loon begin. En dui ook aan of 'n cluster nodig is of nie, ens.
En toe stoot Jenkins 'n dopskrif wat die kode in die Terraform-lêergids effens verander het. Onnodige lêers verwyder, die nodige lêers bygevoeg. En dan, met een lopie Terraform-toediening, het die stapel gestyg.
En dan was daar ander stappe waarop ek nie wil ingaan nie.
As gevolg van die feit dat ons 'n bietjie meer opsies as in produksie nodig gehad het, moes ons kopieë van die modules maak sodat ons in hierdie kopieë daardie kenmerke kon byvoeg wat slegs in toetsing benodig word.
En dit het so gebeur dat dit in toetsing lyk asof jy daardie veranderinge wil toets wat uiteindelik na produksie sal gaan. Maar in werklikheid is een ding getoets, en 'n bietjie anders is in produksie gebruik. En daar was 'n klein breuk in die patroon dat in produksie alle veranderinge deur die bedryfspan toegepas is. En soms het dit geblyk dat daardie veranderinge wat veronderstel was om van toetsing na produksie te gaan, hulle in 'n ander weergawe gebly het.
Daarbenewens was daar so 'n probleem dat 'n nuwe diens bygevoeg is, wat effens anders was as 'n bestaande een. En in plaas daarvan om 'n bestaande module te wysig, moes jy 'n kopie daarvan maak en die nodige veranderinge byvoeg.
Om die waarheid te sê, Terraform is nie 'n regte taal nie. Dit is 'n verklaring. As ons iets moet verklaar, dan verklaar ons dit. En dit werk alles.
Op 'n stadium, toe een van my trekversoeke bespreek is, het een van my kollegas gesê dat dit nie nodig is om sneeuvlokkies te produseer nie. Ek het gewonder wat hy bedoel. Daar is so 'n wetenskaplike feit dat daar in die wêreld nie twee identiese sneeuvlokkies is nie, hulle is almal effens, maar verskillend. En sodra ek dit gehoor het, het ek dadelik die volle gewig van die Terraform-kode gevoel. Want toe dit nodig was om van weergawe na weergawe te beweeg, het Terraform 'n breekkettingverandering vereis, dit wil sê die kode was nie meer versoenbaar met die volgende weergawe nie. En ek moes 'n trekversoek doen, wat amper die helfte van die lêers in die infrastruktuur dek, om die infrastruktuur na die volgende weergawe van Terraform te bring.
En nadat so 'n sneeuvlok verskyn het, het al die Terraform-kode wat ons in 'n groot, groot hoop sneeu verander het.
Vir 'n eksterne ontwikkelaar wat buite werking is, maak dit nie veel vir hom saak nie, want hy het 'n trekversoek gemaak, sy hulpbron het begin. En dit is dit, dit is nie sy bekommernis nie. En die DevOps-span wat seker maak dat alles in orde is, moet al hierdie veranderinge aanbring. En die koste van hierdie veranderinge het baie, baie toegeneem met elke bykomende sneeuvlok.
Daar is 'n storie oor hoe 'n student by 'n seminaar twee perfekte sirkels met kryt op 'n swartbord teken. En die onderwyser is verbaas hoe hy dit reggekry het om so glad sonder 'n kompas te teken. Die student antwoord: “Dis baie eenvoudig, ek het vir twee jaar in die weermag ’n vleismeul verander.”
En uit die vier jaar wat ek aan hierdie projek is, doen ek al vir ongeveer twee jaar Terraform. En natuurlik het ek 'n paar truuks, 'n paar wenke oor hoe om die Terraform-kode te vereenvoudig, daarmee te werk soos 'n programmeertaal en die las op ontwikkelaars te verminder wat hierdie kode op datum moet hou.
Die eerste ding waarmee ek wil begin is Simlinks. Terraform het baie herhalende kode. Byvoorbeeld, om 'n verskaffer te bel by byna elke punt waar ons 'n stuk infrastruktuur skep, is dieselfde. En dit is logies om dit in 'n aparte pappa te sit. En waar ook al van die verskaffer vereis word om Simlinks na hierdie lêer te maak.
Byvoorbeeld, jy gebruik aanneemrol in produksie, wat jou toelaat om toegangsregte tot een of ander eksterne Amazon-rekening te kry. En deur een lêer te verander, sal al die oorblywendes wat in die hulpbronboom is, die vereiste regte hê sodat Terraform weet watter Amazon-segment om toegang te verkry.
Waar simlinks nie werk nie? Soos ek gesê het, Terraform het staatslêers. En hulle is baie, baie cool. Maar die feit is dat Terraform die agterkant in die heel eerste een inisialiseer. En hy kan geen veranderlikes in hierdie parameters gebruik nie, hulle moet altyd in teks geskryf word.
En as gevolg daarvan, wanneer iemand 'n nuwe hulpbron maak, kopieer hy 'n deel van die kode uit ander dopgehou. En hy kan 'n fout maak met die sleutel of met die emmer. Hy maak byvoorbeeld 'n sandbox-ding uit 'n sandbox, en maak dit dan in produksie. En so kan dit blyk dat die emmer in produksie uit die sandbak gebruik sal word. Natuurlik sal hulle dit vinnig vind. Dit sal moontlik wees om dit op een of ander manier reg te stel, maar dit is nietemin 'n mors van tyd en tot 'n mate van hulpbronne.
Wat kan ons volgende doen? Voordat u met Terraform werk, moet u dit inisialiseer. Ten tyde van inisialisering laai Terraform alle inproppe af. Op 'n stadium het hulle van 'n monoliet na 'n meer mikrodiensargitektuur gebreek. En jy moet altyd Terraform init doen sodat dit al die modules, al die inproppe optrek.
En jy kan 'n dopskrif gebruik, wat eerstens al die veranderlikes kan kry. Shell script is onbeperk. En, tweedens, die manier. As ons altyd die pad wat in die bewaarplek is as die sleutel tot die staatlêer gebruik, sal die fout dienooreenkomstig hier uitgesluit word.
Waar om data te kry? JSON-lêer. Terraform laat jou toe om infrastruktuur nie net in hcl (HashiCorp Configuration Language) te skryf nie, maar ook in JSON.
JSON is maklik om vanaf 'n dopskrif te lees. Gevolglik kan u op 'n plek 'n konfigurasielêer met 'n emmer plaas. En gebruik hierdie emmer beide in die Terraform-kode en in die dopskrif vir inisialisering.
Hoekom is dit belangrik om 'n Terraform-emmer te hê? Want daar is so iets soos afgeleë staat lêers. Dit wil sê, wanneer ek 'n hulpbron insamel, om Amazon te vertel: "Verhoog asseblief instansie", moet ek baie vereiste parameters spesifiseer.
En hierdie identifiseerders word in 'n ander gids gestoor. En ek kan dit vat en sê: "Terraform, hardloop asseblief na die staatslêer van daardie einste hulpbron en kry vir my hierdie identifiseerders." En dus is daar 'n soort eenwording tussen verskillende streke of omgewings.
Dit is nie altyd moontlik om 'n afgeleë toestandlêer te gebruik nie. Byvoorbeeld, jy het met die hand 'n VPC geskep. En die Terraform-kode wat die VPC skep, skep so 'n ander VPC dat dit baie lank neem en jy moet die een by die ander aanpas, sodat jy die volgende truuk kan gebruik.
Dit wil sê om 'n module te maak wat as 't ware VPC maak en vir jou identifiseerders gee, maar in werklikheid is daar net 'n lêer met hardgekodeerde waardes wat gebruik kan word om dieselfde instansie te skep.
Dit is nie altyd nodig om die staatlêer in die wolk te stoor nie. Byvoorbeeld, wanneer u modules toets, kan u backend-inisialisering gebruik, wanneer die lêer net op die skyf gestoor sal word ten tyde van die toets.
Nou 'n bietjie oor toetsing. Wat kan in Terraform getoets word? Waarskynlik, baie is moontlik, maar ek sal oor hierdie 4 dinge praat.
HashiCorp het 'n begrip van hoe om Terraform-kode te formateer. En Terraform fmt laat jou die kode wat jy wysig volgens daardie oortuiging formateer. Gevolglik moet die toetse noodwendig kyk of die formatering ooreenstem met wat HashiCorp bemaak het, sodat jy nie die ligging van hakies, ens hoef te verander nie.
Die volgende een is Terraform validate. Dit doen 'n bietjie meer as 'n sintakskontrole - ala, is al die hakies saam. Wat is hier belangrik? Ons het 'n baie dun infrastruktuur. Dit het baie verskillende dopgehou. En in elkeen moet jy Terraform validate laat loop.
Gevolglik, om toetsing te bespoedig, voer ons verskeie prosesse parallel deur gebruik te maak van parallel.
Parallel is 'n baie oulike ding, gebruik dit.
Maar elke keer as Terraform geïnisialiseer word, gaan dit na HashiCorp en vra: "Wat is die nuutste inproppe? En die inprop wat ek in die kas het - is dit die een of nie die een nie? En dit het by elke tree stadiger geword.
As Terraform jou vertel waar die inproppe is, sal Terraform sê: “OK, dit is waarskynlik die varsste ding wat daar is. Ek sal nêrens heen gaan nie, ek sal dadelik jou Terraform-kode begin bekragtig."
Om die gids met die nodige inproppe te vul, het ons 'n baie eenvoudige Terraform-kode wat net geïnisialiseer moet word. Hier moet jy natuurlik al die verskaffers spesifiseer wat op een of ander manier aan jou kode deelneem, anders sal Terraform sê: "Ek ken geen verskaffer nie, want dit is nie in die kas nie."
Die volgende een is die Terraform-plan. Soos ek gesê het, ontwikkeling is siklies. Ons maak kode met veranderinge. En dan moet jy uitvind watter veranderinge vir die infrastruktuur beplan word.
En wanneer die infrastruktuur baie, baie groot is, kan jy een module verander, een of ander toetsomgewing of een of ander spesifieke streek regmaak en een of ander naburige een breek. Daarom moet 'n Terraform-plan vir die hele infrastruktuur gemaak word en wys watter veranderinge beplan word.
Jy kan dit op die slim manier doen. Ons het byvoorbeeld 'n Python-skrip geskryf wat afhanklikhede oplos. En afhangende van wat verander is: 'n Terraform-module of net 'n spesifieke komponent, maak dit planne vir alle afhanklike dopgehou.
Terraformplan moet op versoek gedoen word. Dit is ten minste wat ons doen.
Toetse is natuurlik goed om te doen vir elke verandering, vir elke verbintenis, maar planne is nogal 'n duur ding. En ons sê in die trekversoek: "Gee my asseblief die planne." Die robot begin. En stuur na die kommentaar of om al die planne wat van jou veranderinge verwag word aan te heg.
Die plan is 'n taamlik duur ding. Dit neem tyd, want Terraform gaan na Amazon en vra: "Bestaan hierdie geval nog? Het hierdie outoskaal presies dieselfde parameters?”. En om dit te bespoedig, kan jy 'n parameter soos refresh=false gebruik. Dit beteken dat Terraform die S3-staat sal afblaas. En sal glo dat die staat presies sal ooreenstem met wat in Amazon is.
So 'n Terraform-plan is baie vinniger, maar die staat moet by jou infrastruktuur pas, dit wil sê, iewers moet Terraform-verversing een of ander tyd begin. Terraform refresh doen presies dit, sodat die staat ooreenstem met wat in die werklike infrastruktuur is.
En ek moet sê oor veiligheid. Dit is waar dit moes begin het. Waar jy Terraform bestuur en Terraform met jou infrastruktuur werk, is daar 'n kwesbaarheid. Dit wil sê, jy voer in wese kode uit. En as die trekversoek 'n soort kwaadwillige kode bevat, kan dit uitgevoer word op 'n infrastruktuur wat te veel toegang het. Wees dus versigtig waar u Terraform-plan begin.
Die volgende ding waaroor ek wil praat, is gebruikersdatatoetsing.
Wat is gebruikersdata? In Amazon, wanneer ons 'n instansie skep, kan ons 'n soort brief vanaf die instansie stuur - metadata. Wanneer 'n instansie begin word, is cloud init gewoonlik altyd teenwoordig op daardie instansies. Cloud init lees hierdie brief en sê: "OK, vandag is ek 'n lasbalanseerder." En in ooreenstemming met hierdie voorskrifte voer hy 'n paar handelinge uit.
Maar ongelukkig, wanneer ons Terraform-plan doen en Terraform toepas, lyk gebruikersdata soos hierdie klomp getalle. Dit wil sê, hy stuur net vir jou 'n hash. En al wat jy in die plan kan sien, is of daar enige veranderinge sal wees of die hash dieselfde sal bly.
En as jy nie hieraan aandag gee nie, kan een of ander geklopte tekslêer na Amazon gaan, na die regte infrastruktuur.
Alternatiewelik kan u nie die hele infrastruktuur tydens uitvoering spesifiseer nie, maar slegs die sjabloon. En in die kode, sê: "Vertoon asseblief hierdie sjabloon vir my." En gevolglik kan jy 'n drukstuk kry van hoe jou data op Amazon sal lyk.
Nog 'n opsie is om 'n module te gebruik om gebruikersdata te genereer. Jy sal hierdie module toepas. Kry die lêer op skyf. Vergelyk dit met die verwysing. En dus, as een of ander Junie besluit om 'n bietjie gebruikersdata reg te stel, dan sal jou toetse sê: "OK, daar is 'n paar veranderinge hier en daar - dit is normaal."
Die volgende ding waaroor ek wil praat, is Automate Terraform application.
Dit is natuurlik skrikwekkend genoeg om Terraform in outomatiese modus toe te pas, want wie weet watter veranderinge daar gekom het en hoe nadelig dit vir 'n lewende infrastruktuur kan wees.
Vir 'n toetsomgewing is dit alles goed. Dit wil sê, 'n werk wat 'n toetsomgewing skep, is wat alle ontwikkelaars nodig het. En so 'n uitdrukking soos "alles het vir my gewerk" is nie 'n snaakse meme nie, maar 'n bewys dat 'n persoon verward geraak het, 'n stapel opgetel het, 'n paar toetse op hierdie stapel geloods het. En hy het seker gemaak dat alles reg is daar en gesê: "OK, die kode wat ek vrystel, is getoets."
In produksie-, sandbox- en ander omgewings wat meer sake-kritiek is, is dit veilig om sommige hulpbronne gedeeltelik te gebruik omdat dit nie veroorsaak dat iemand sterf nie. Dit is: outoskaalgroepe, sekuriteitsgroepe, rolle, route53 en daar kan die lys redelik groot wees. Maar hou 'n ogie oor wat aangaan, lees verslae van outomatiese toepassings.
Waar dit gevaarlik of skrikwekkend is om te gebruik, byvoorbeeld, as dit 'n paar aanhoudende hulpbronne is, vanaf 'n databasis, kry dan verslae dat daar ontoegepaste veranderinge in een of ander stuk infrastruktuur is. En die ingenieur is reeds onder toesig om werk te doen om aansoek te doen of om dit vanaf sy konsole te doen.
Amazon het iets soos Terminate-beskerming. En dit kan in sommige gevalle beskerm teen veranderinge wat nie vir jou nodig is nie. So Terraform het na Amazon gegaan en gesê: "Ek moet hierdie instansie doodmaak om nog een te maak". En Amazon sê: “Jammer, nie vandag nie. Ons het Terminate-beskerming.”
En die kersie op die koek is kode-optimalisering. Wanneer ons met Terraform-kode werk, moet ons 'n baie groot aantal parameters aan die module deurgee. Dit is die parameters wat nodig is om 'n soort hulpbron te skep. En die kode verander in groot lyste parameters wat van module tot module, van module tot module deurgegee moet word, veral as die modules geneste is.
En dit is baie moeilik om te lees. Dit is baie moeilik om dit te hersien. En baie dikwels blyk dit dat sommige parameters hersien word en dit is nie heeltemal die een wat nodig is nie. En dit kos tyd en geld om dit later reg te maak.
Daarom stel ek voor dat jy so iets gebruik as 'n komplekse parameter wat 'n sekere boom van waardes insluit. Dit wil sê, jy het 'n soort gids nodig waar jy al die waardes het wat jy graag in 'n soort omgewing wil hê.
En deur hierdie module te roep, kan jy 'n boom kry wat in een gemeenskaplike module gegenereer word, dit wil sê in 'n gemeenskaplike module wat dieselfde vir die hele infrastruktuur werk.
In hierdie module kan jy 'n paar berekeninge doen deur so 'n vars kenmerk in Terraform as plaaslike inwoners te gebruik. En gee dan in een uitvoer 'n soort komplekse parameter uit, wat hashes, skikkings, ens.
Op hierdie, al die beste bevindings wat ek geëindig het. En ek wil graag 'n storie oor Columbus vertel. Toe hy geld gesoek het vir sy ekspedisie om Indië te ontdek (soos hy toe gedink het), het niemand hom geglo en geglo dat dit onmoontlik is nie. Toe sê hy: "Maak seker dat die eier nie val nie." Al die bankiers, baie ryk en waarskynlik slim mense, het probeer om die eier op een of ander manier te sit, en dit het heeltyd geval. Toe vat Columbus die eier, druk dit 'n bietjie. Die dop het opgefrommel en die eier het roerloos gebly. Hulle het gesê: "O, dit is te maklik!" En Columbus het geantwoord: “Ja, dit is te eenvoudig. En wanneer ek Indië oopmaak, sal almal hierdie handelsroete gebruik.”
En wat ek nou net vir jou gesê het, is waarskynlik redelik eenvoudige en onbenullige dinge. En wanneer jy van hulle uitvind en hulle begin gebruik, is dit in die volgorde van dinge. Gebruik dit dus. En as dit vir jou redelik normale dinge is, dan weet jy ten minste hoe om 'n eier te sit sodat dit nie val nie.
Kom ons vat dit op:
- Probeer sneeuvlokkies vermy. En hoe minder sneeuvlokkies, hoe minder hulpbronne sal jy nodig hê om enige veranderinge aan jou hele groot infrastruktuur aan te bring.
- Konstante verandering. Dit wil sê, wanneer sommige veranderinge in die kode plaasgevind het, moet jy jou infrastruktuur so gou as moontlik in lyn bring met hierdie veranderinge. Daar behoort nie 'n situasie te wees wanneer iemand oor twee of drie maande na Elasticsearch kom kyk, 'n Terraform-plan maak, en daar is baie veranderinge wat hy nie verwag het nie. En dit neem baie tyd om alles weer in orde te bring.
- Toetse en outomatisering. Hoe meer kode jy met toetse en kenmerke bedek het, hoe meer vertroue het jy dat jy alles reg doen. En outomatiese aflewering sal jou selfvertroue baie keer verhoog.
- Die kode vir die toets- en produksie-omgewings behoort amper dieselfde te wees. Prakties, want produksie is immers 'n bietjie anders en daar sal steeds 'n paar nuanses wees wat verder gaan as die toetsomgewing. Maar nietemin, plus of minus dit kan verskaf word.
- En as jy baie Terraform-kode het en dit neem baie tyd om hierdie kode op datum te hou, dan is dit nooit te laat om dit te herfaktoreer en in goeie vorm te bring nie.
- onveranderlike infrastruktuur. AMI aflewering op skedule.
- Struktuur vir roete53 wanneer jy baie inskrywings het en wil hê hulle moet in 'n konsekwente volgorde wees.
- Veg teen API-koerslimiete. Dit is wanneer Amazon sê: "Dit is dit, ek kan nie meer versoeke aanvaar nie, wag asseblief." En die helfte van die kantoor wag totdat dit sy infrastruktuur kan bekendstel.
- gevalle raaksien. Amazon is nie 'n goedkoop geleentheid nie en plekke laat jou toe om nogal baie te bespaar. En daar kan jy 'n hele berig daaroor vertel.
- Sekuriteit en IAM rolle.
- Soek verlore hulpbronne, wanneer jy gevalle van onbekende oorsprong in Amazone het, eet hulle geld. Selfs as gevalle $100-150 per maand kos, is dit meer as $1 000 per jaar. Om sulke hulpbronne te vind is 'n winsgewende besigheid.
- En gereserveerde gevalle.
Dis al vir my. Terraform is baie cool, gebruik dit. Dankie!
vrae
Dankie vir die verslag! Jy het 'n staatlêer in S3, maar hoe los jy die probleem op dat verskeie mense hierdie toestandlêer kan neem en probeer ontplooi?
Eerstens is ons nie haastig nie. Tweedens is daar vlae waarin ons rapporteer dat ons besig is met een of ander stukkie kode. Dit wil sê, ten spyte van die feit dat die infrastruktuur baie groot is, beteken dit nie dat iemand voortdurend iets gebruik nie. En toe daar 'n aktiewe fase was, was dit 'n probleem, ons het staatlêers in Git gehou. Dit was belangrik, anders sou iemand 'n staatslêer maak, en ons moes dit handmatig in 'n hoop versamel om verder te gaan. Nou is daar nie so 'n probleem nie. Oor die algemeen het Terraform hierdie probleem opgelos. En as iets voortdurend verander, dan kan jy slotte gebruik wat verhoed wat jy gesê het.
Gebruik jy oopbron of onderneming?
Geen onderneming nie, dit wil sê alles wat jy gratis kan gaan aflaai.
My naam is Stanislav. Ek wou 'n klein byvoeging maak. Jy het gepraat oor die Amazon-funksie wat jou toelaat om 'n instansie ondodbaar te maak. Dit is ook in Terraform self, in die Life Second-blok kan jy 'n verbod op verandering voorskryf, of 'n verbod op vernietiging.
Was beperk in tyd. Goeie punt.
Ek wou ook twee dinge vra. Eerstens het jy oor toetsing gepraat. Het jy enige toetsinstrumente gebruik? Ek het gehoor van die Test Kitchen-inprop. Miskien is daar iets anders. En ek wil graag vra oor Plaaslike Waardes. Hoe verskil hulle basies van insetveranderlikes? En hoekom kan ek iets nie net deur Plaaslike Waardes parametriseer nie? Ek het probeer om hierdie onderwerp te hanteer, maar op een of ander manier het ek dit nie self uitgepluis nie.
Ons kan in meer besonderhede agter hierdie saal praat. Toetsgereedskap is ons volledige selfgemaakte. Daar is niks om te toets nie. Oor die algemeen is daar opsies wanneer outomatiese toetse die infrastruktuur iewers verhoog, kyk of dit in orde is, en dan alles vernietig met 'n verslag dat jou infrastruktuur nog in goeie toestand is. Ons het dit nie, want die toetsstapels loop elke dag. En dit is genoeg. En as iets begin breek, dan sal dit begin breek sonder dat ons dit iewers anders nagaan.
Wat plaaslike waardes betref, kom ons gaan voort met die gesprek buite die gehoor.
Hallo! Dankie vir die verslag! Baie insiggewend. Jy het gesê dat jy baie van dieselfde tipe kode het om die infrastruktuur te beskryf. Het jy dit oorweeg om hierdie kode te genereer?
Goeie vraag, dankie! Die punt is dat wanneer ons infrastruktuur as kode gebruik, ons aanvaar dat ons na die kode kyk en verstaan watter soort infrastruktuur agter hierdie kode skuil. As die kode gegenereer word, moet ons ons voorstel watter kode gegenereer sal word om te verstaan watter soort infrastruktuur daar sal wees. Of ons genereer die kode, pleeg dit en in werklikheid kry ons dieselfde ding. Daarom het ons gegaan soos ons geskryf het, ons het dit gekry. Boonop het kragopwekkers 'n bietjie later verskyn, toe ons begin maak het. En dit was te laat om te verander.
Het jy al van jsonnet gehoor?
Nee
Kyk, dit is regtig oulike goed. Ek sien 'n spesifieke geval waar jy dit kan toepas en 'n datastruktuur kan genereer.
Kragopwekkers is goed as jy dit het, soos in die grap oor die skeermasjien. Dit wil sê, die eerste keer is die gesig anders, maar dan het almal dieselfde gesig. Die kragopwekkers is baie cool. Maar, ongelukkig is ons gesigte 'n bietjie anders. Dit is 'n probleem.
Kyk net. Dankie!
My naam is Maxim, ek is van Sberbank. Jy het 'n bietjie gesê dat jy Terraform na 'n analoog van 'n programmeertaal probeer bring het. Is dit nie makliker om Ansible te gebruik nie?
Dit is baie verskillende dinge. Ansible kan hulpbronne skep, en Puppet kan hulpbronne in Amazon skep. Maar Terraform is heeltemal verskerp.
Het jy net Amazon?
Dit is nie dat ons net Amazon het nie. Ons het amper net Amazon. Maar die belangrikste kenmerk is dat Terraform onthou. In Ansible, as jy sê: "Tel my 5 gevalle op", dan sal dit verhoog, en dan sê jy: "En nou het ek 3 nodig". En Terraform sal sê: "Ok, ek sal 2 doodmaak", en Ansible sal sê: "Ok, hier is 3 vir jou." Totaal 8.
Hallo! Dankie vir jou verslag! Dit was baie interessant om van Terraform te hoor. Ek wil net 'n klein opmerking maak oor die feit dat Terraform steeds nie 'n stabiele vrystelling het nie, so wees baie versigtig met Terraform.
Lekker lepel vir aandete. Dit wil sê as jy 'n oplossing nodig het, dan stel jy soms uit wat onstabiel is, ens., maar dit werk en het ons gehelp.
Die vraag is. Jy gebruik die Remote backend, jy gebruik S 3. Hoekom gebruik jy nie die amptelike backend nie?
Amptelik?
Terraform Wolk.
Wanneer het hy verskyn?
4 maande gelede.
As dit 4 jaar gelede verskyn het, dan sou ek waarskynlik jou vraag beantwoord het.
Daar is reeds 'n ingeboude funksie en slotte, en jy kan 'n staatlêer stoor. Probeer dit. Maar ek het ook nie getoets nie.
Ons is op 'n groot trein wat teen hoë spoed beweeg. En jy kan nie net 'n paar karre vat en uitgooi nie.
Jy het van sneeuvlokkies gepraat, hoekom het jy nie tak gebruik nie? Hoekom het dit nie so uitgewerk nie?
Ons het so 'n benadering dat die hele infrastruktuur in een bewaarplek is. Terraform, Puppet, al die skrifte wat op een of ander manier hiermee verband hou, hulle is almal in een bewaarplek. Op hierdie manier kan ons verseker dat inkrementele veranderinge een vir een getoets word. As dit 'n klomp takke was, sou so 'n projek byna onmoontlik wees om in stand te hou. Ses maande gaan verby, en hulle verskil so dat dit net 'n soort straf is. Dit is waarvan ek wou weghardloop voordat ek herfaktoreer.
dit wil sê dit werk nie?
Dit werk glad nie.
In tak sny ek die vouerskyfie uit. Dit wil sê, as jy byvoorbeeld vir elke toetsstapel doen, span A het sy eie pappa, span B het sy eie pappa, dan werk dit ook nie. Ons het 'n verenigde toetsomgewingskode gemaak wat buigsaam genoeg was om almal te pas. Dit wil sê, ons het een kode bedien.
Hallo! My naam is Yura! Dankie vir die verslag! Vraag oor modules. Jy sê jy gebruik modules. Hoe los jy die probleem op as veranderinge in een module aangebring is wat nie versoenbaar is met die verandering van 'n ander persoon nie? Op een of ander manier weergawes van modules of probeer om 'n wonderkind te bring om aan twee vereistes te voldoen?
Dit is die groot sneeuhoopprobleem. Dit is waaraan ons ly wanneer een of ander onskadelike verandering 'n deel van die infrastruktuur kan breek. En dit sal eers na 'n lang tyd merkbaar wees.
Dit wil sê, daar is nog nie besluit nie?
Jy maak universele modules. Vermy sneeuvlokkies. En alles sal regkom. Die tweede helfte van die verslag gaan oor hoe om dit te vermy.
Hallo! Dankie vir die verslag! Ek wil graag verduidelik. Agter die skerms was daar 'n groot hoop, waarvoor ek gekom het. Hoe word marionet- en rolverspreiding geïntegreer?
gebruiker-data.
Dit wil sê, spoeg jy net die lêer uit en voer dit op een of ander manier uit?
Gebruikersdata is 'n nota, dit wil sê wanneer ons 'n beeldkloon maak, dan staan Daemon daar op en probeer uitvind wie hy is, lees 'n nota dat hy 'n lasbalanseerder is.
Dit wil sê, is dit 'n soort aparte proses wat weggegee word?
Ons het dit nie uitgevind nie. Ons gebruik dit.
Hallo! Ek het net 'n vraag oor Gebruiker - data. Jy het gesê daar is probleme daar, dat iemand dalk iets na die verkeerde plek toe stuur. Is daar 'n manier om gebruiker - data in dieselfde Git te stoor, sodat dit altyd duidelik is waarna Gebruiker-data verwys?
Ons genereer gebruikersdata vanaf sjabloon. Dit wil sê, 'n sekere aantal veranderlikes ressorteer daar. En Terraform genereer die finale resultaat. Daarom kan jy nie net na die sjabloon kyk en sê wat gebeur nie, want al die probleme hou verband met die feit dat die ontwikkelaar dink dat hy 'n string in hierdie veranderlike deurgee, en dan word 'n skikking gebruik. En hy - bang en ek - so-en-so, so-en-so, die volgende reël, en alles het gebreek. As dit 'n nuwe hulpbron is en 'n persoon verhoog dit, sien dat iets nie werk nie, dan is dit vinnig opgelos. En as hierdie outoskaalgroep opgedateer is, begin die gevalle in die outoskaalgroep op 'n sekere stadium vervang word. En klap, iets werk nie. Dit maak seer.
Dit blyk dat die enigste oplossing is om te toets?
Ja, jy sien die probleem, jy voeg toetsstappe daar by. Dit wil sê, uitset kan ook getoets word. Miskien nie so gerieflik nie, maar jy kan ook 'n paar merkies plaas - maak seker dat User-data hier vasgespyker is.
My naam is Timur. Dit is baie gaaf dat daar verslae is oor hoe om Terraform behoorlik te organiseer.
Ek het nie eers begin nie.
Ek dink dat in die volgende konferensie, miskien sal daar wees. Ek het 'n eenvoudige vraag. Hoekom hardkodeer jy die waarde in 'n aparte module eerder as om tfvars te gebruik, dit wil sê is 'n module met waardes beter as tfvars?
Dit wil sê, ek moet hier skryf (skyfie: Produksie/omgewing/settings.tf): domein = veranderlike, domein vpcnetwork, vpcnetwork veranderlike en stvars - kry dieselfde ding?
Ons doen presies dit. Ons verwys byvoorbeeld na die instellingsbronmodule.
Eintlik is dit so 'n tfvars. Tfvars is baie handig in 'n toetsomgewing. Ek het tfvars vir groot gevalle, vir kleins. En ek het een lêer in die gids gegooi. En gekry wat ek wou hê. Toe ons infrastruktuur gesien het, wil ons alles kan sien en dadelik verstaan. En so blyk dit dat jy hier moet kyk, dan in tfvars kyk.
Dit blyk dat alles op een plek was?
Ja, tfvars is wanneer jy een kode het. En dit word op verskillende plekke met verskillende nuanses gebruik. Dan sou jy tfvars gooi en jou nuanses kry. En ons is infrastruktuur as kode in sy suiwerste vorm. Gekyk en verstaan.
Hallo! Het jy al situasies teëgekom waar die wolkverskaffer inmeng met wat jy met Terraform gedoen het? Kom ons sê ons wysig die meta-data. Daar is ssh-sleutels. En Google gooi voortdurend sy metadata, sy sleutels daar. En Terraform skryf altyd dat dit veranderinge het. Na elke lopie, al verander niks, sê hy altyd dat hy hierdie veld nou sal opdateer.
Met sleutels, maar - ja, 'n deel van die infrastruktuur word deur so iets geraak, maw Terraform kan niks verander nie. Ons kan ook niks met ons hande verander nie. Solank ons daarmee saamleef.
Dit wil sê, jy het hierop afgekom, maar by niks uitgekom nie, hoe doen hy dit en doen dit self?
Ongelukkig ja.
Hallo! My naam is Stanislav Starkov. Pos. en Groep. Hoe los jy die probleem op met die generering van 'n merker op ..., hoe gee jy dit binne? Soos ek dit verstaan, deur Gebruiker - data, om die gasheernaam te spesifiseer, aanhits Puppet? En die tweede deel van die vraag. Hoe los jy hierdie probleem op in SG, dit wil sê wanneer jy SG genereer, honderd gevalle van dieselfde tipe, hoe om hulle korrek te benoem?
Daardie gevalle wat vir ons baie belangrik is, ons sal hulle mooi noem. Diegene wat nie nodig is nie, daar is 'n naskrif dat dit 'n outoskaalgroep is. En in teorie kan dit vasgespyker word, en 'n nuwe een kry.
Wat die probleem met die merker betref, is daar nie so 'n probleem nie, maar daar is so 'n taak. En ons gebruik etikette baie, baie swaar, want die infrastruktuur is groot en duur. En ons moet kyk waaraan geld bestee word, so etikette laat ons toe om uit te sorteer wat en waarheen dit gegaan het. En dienooreenkomstig is die soeke na iets hier baie geld wat spandeer word.
Waaroor was die vraag anders?
Wanneer SG honderd gevalle skep, moet hulle op een of ander manier onderskei word?
Nee, moenie. Elke geval het 'n agent wat vir my sê dat ek 'n probleem het. As die agent rapporteer, dan weet die agent van hom en, ten minste, sy IP-adres bestaan. Jy kan reeds hardloop. Tweedens gebruik ons Consul for Discovery, waar daar geen Kubernetes is nie. En Consul wys ook die IP-adres van die instansie.
Dit wil sê, jy teiken presies die IP, en nie die gasheernaam nie?
Dit is onmoontlik om volgens gasheernaam te navigeer, dit wil sê daar is baie van hulle. Daar is instansie identifiseerders - AE, ens. Jy kan dit iewers vind, jy kan dit in die soektog gooi.
Hallo! Ek het besef dat Terraform 'n goeie ding is, aangepas vir die wolke.
Nie net.
Dit is die vraag wat my interesseer. As jy besluit om, sê maar, massaal na Bare Metal te skuif met al jou gevalle? Sal daar enige probleme wees? Of moet jy nog ander produkte gebruik, byvoorbeeld dieselfde Ansible wat hier genoem is?
Ansible gaan 'n bietjie oor iets anders. Dit wil sê, Ansible loop reeds wanneer instansie begin het. En Terraform werk voordat die instansie begin het. Om oor te skakel na Bare Metal is nie.
Nie nou nie, maar besigheid sal kom en sê: "Komaan."
Skakel oor na 'n ander wolk - ja, maar hier is 'n effens ander kenmerk. Jy moet Terraform-kode op so 'n manier skryf dat jy met minder bloedvergieting na 'n ander wolk kan oorskakel.
Aanvanklik was die taak dat ons hele infrastruktuur agnosties is, dit wil sê enige wolk behoort reg te wees, maar op 'n stadium het die besigheid opgegee en gesê: "OK, in die volgende N jaar gaan ons nêrens heen nie, jy kan dienste gebruik van Amazon".
Terraform laat jou toe om Front-End-take te skep, PagerDuty op te stel, datadokumente, ens. Dit het baie sterte. Hy kan feitlik die hele wêreld beheer.
Dankie vir die verslag! Ek spin ook al vir 4 jaar Terraform. In die stadium van 'n gladde oorgang na Terraform, na infrastruktuur, na 'n verklarende beskrywing, het ons gekonfronteer met 'n situasie waar iemand iets met die hand doen, en jy probeer 'n plan maak. En ek het 'n fout daar. Hoe hanteer jy sulke probleme? Hoe vind jy die verlore hulpbronne wat aangedui is?
Meestal met ons hande en oë, as ons iets vreemds in die berig sien, dan ontleed ons wat daar gebeur, of ons maak dit net dood. Oor die algemeen is trekversoeke 'n algemene ding.
As daar 'n fout is, rol jy terug? Het jy dit probeer doen?
Nee, dit is 'n besluit van 'n persoon op die oomblik wanneer hy die probleem sien.
Bron: will.com