Het lijkt erop dat Terraform-ontwikkelaars redelijk handige best practices bieden voor het werken met de AWS-infrastructuur. Er is slechts een nuance. Na verloop van tijd neemt het aantal omgevingen toe, elk met zijn eigen kenmerken. Een bijna kopie van de applicatiestapel verschijnt in de aangrenzende regio. En de Terraform-code moet zorgvuldig worden gekopieerd en aangepast aan de nieuwe eisen of tot een sneeuwvlok worden gemaakt.
Mijn rapport over patronen in Terraform om chaos en handmatige routine bij grote en langdurige projecten tegen te gaan.
Video:
Ik ben 40, ik zit al 20 jaar in de IT. Ik werk al 12 jaar bij Ixtens. Wij houden ons bezig met e-commerce-gedreven ontwikkeling. En ik oefen al 5 jaar DevOps-praktijken.
Mijn verhaal gaat over mijn ervaring in een project bij een bedrijf waarvan ik de naam niet zal zeggen, dat zich verschuilt achter een geheimhoudingsovereenkomst.
De cijfers op de dia zijn aangegeven om de omvang van het project te begrijpen. En alles wat ik hierna ga zeggen, heeft betrekking op Amazon.
Ik ben 4 jaar geleden bij dit project gekomen. En de herinrichting van de infrastructuur was in volle gang omdat het project was gegroeid. En de patronen die gebruikt werden waren niet meer geschikt. En gezien alle geplande groei van het project was het nodig om met iets nieuws te komen.
Met dank aan Matvey, die ons gisteren vertelde wat er bij Dodo Pizza was gebeurd. Dit is wat hier 4 jaar geleden gebeurde.
Ontwikkelaars kwamen en begonnen infrastructuurcode te maken.
De meest voor de hand liggende reden waarom dit nodig was, was de time-to-market. Het was noodzakelijk om ervoor te zorgen dat het DevOps-team geen knelpunt vormde tijdens de uitrol. En op het allereerste niveau werden onder meer Terraform en Puppet gebruikt.
Terraform is een open source-project van HashiCorp. En voor degenen die niet eens weten wat dit is, de volgende dia's.
Infrastructuur als code betekent dat we onze infrastructuur kunnen beschrijven en een aantal robots kunnen vragen ervoor te zorgen dat we de bronnen ontvangen die we hebben beschreven.
We hebben bijvoorbeeld een virtuele machine nodig. We zullen verschillende vereiste parameters beschrijven en toevoegen.
Hierna zullen we de toegang tot Amazon in de console configureren. En we zullen om het Terraform-plan vragen. Terraform-plan zal zeggen: "Oké, we kunnen deze dingen voor je hulpbron doen." En er zal minstens één hulpbron worden toegevoegd. En er worden geen veranderingen verwacht.
Als u tevreden bent met alles, kunt u Terraform vragen een aanvraag in te dienen. Terraform maakt dan een instance voor u aan en u ontvangt een virtuele machine in uw cloud.
Verder ontwikkelt ons project zich. We voegen daar enkele wijzigingen aan toe. We vragen om meer exemplaren, we voegen 53 vermeldingen toe.
En wij herhalen. Plan alsjeblieft. We zien welke veranderingen er gepland zijn. Wij solliciteren. En zo groeit onze infrastructuur.
Terraform gebruikt zogenaamde statusbestanden. Dat wil zeggen dat alle wijzigingen die naar Amazon gaan, worden opgeslagen in een bestand waarin voor elke bron die u hebt beschreven, overeenkomstige bronnen zijn die in Amazon zijn gemaakt. Wanneer de beschrijving van een hulpmiddel verandert, weet Terraform dus precies wat er in Amazon moet worden gewijzigd.
Deze statusbestanden waren oorspronkelijk alleen maar bestanden. En we hebben ze opgeslagen in Git, wat buitengewoon lastig was. Iemand vergat altijd veranderingen door te voeren en er ontstonden veel conflicten.
Nu is het mogelijk om de backend te gebruiken, d.w.z. dat Terraform specificeert in welke bucket en met welke sleutel het statusbestand moet worden opgeslagen. En Terraform zelf zal ervoor zorgen dat dit statusbestand wordt verkregen, alle magie wordt gedaan en het eindresultaat terugkomt.
Onze infrastructuur groeit. Hier is onze code. En nu willen we niet alleen een virtuele machine maken, we willen een testomgeving hebben.
Met Terraform kunt u zoiets als een module maken, dat wil zeggen hetzelfde in een bepaalde map beschrijven.
En roep bijvoorbeeld tijdens het testen deze module aan en krijg hetzelfde alsof we Terraform in de module zelf hadden toegepast. Om te testen zal er deze code zijn.
Voor productie kunnen we daar enkele wijzigingen naartoe sturen, omdat we bij het testen geen grote exemplaren nodig hebben; in productie zijn grote exemplaren alleen maar nuttig.
En dan keer ik terug naar het project. Het was een moeilijke opgave, de geplande infrastructuur was erg groot. En het was nodig om alle code op de een of andere manier zo te plaatsen dat het voor iedereen handig zou zijn: zowel voor degenen die onderhoud aan deze code uitvoeren als voor degenen die wijzigingen aanbrengen. En het was de bedoeling dat elke ontwikkelaar de infrastructuur voor zijn deel van het platform zou kunnen repareren als dat nodig was.
Dit is een directorystructuur die door HashiCorp zelf wordt aanbevolen als je een groot project hebt en het zinvol is om de hele infrastructuur in enkele kleine stukjes te verdelen, en elk onderdeel in een aparte map te beschrijven.
Met een uitgebreide bibliotheek met bronnen kunt u ongeveer hetzelfde aanroepen tijdens het testen en tijdens de productie.
In ons geval was dit niet helemaal geschikt, omdat de teststack voor ontwikkelaars of voor testen op de een of andere manier eenvoudiger moest worden verkregen. Maar ik wilde niet door de mappen gaan en ze in de vereiste volgorde toepassen, en me zorgen maken dat de database zou stijgen, en dat vervolgens de instantie die deze database gebruikt, zou stijgen. Daarom zijn alle tests vanuit één map gestart. Daar werden dezelfde modules genoemd, maar alles werd in één run gedaan.
Terraform zorgt voor alle afhankelijkheden. En het creëert altijd bronnen in de juiste volgorde, zodat u bijvoorbeeld een IP-adres kunt verkrijgen van een nieuw aangemaakt exemplaar, en dit IP-adres in het route53-record kunt krijgen.
Bovendien is het platform erg groot. En het lanceren van een teststack, al is het maar voor een uur, al is het maar voor 8 uur, is een behoorlijk dure onderneming.
En we hebben deze zaak geautomatiseerd. En dankzij Jenkins baan konden we de stapel runnen. Daarin was het nodig om een pull-verzoek te lanceren met de wijzigingen die de ontwikkelaar wil testen, en alle noodzakelijke opties, componenten en dimensies te specificeren. Als hij prestatietests wil, kan hij meer exemplaren nemen. Als hij alleen maar wil controleren of er een formulier wordt geopend, kan hij beginnen met het minimumloon. En geef ook aan of een cluster nodig is of niet etc.
En toen pushte Jenkins een shellscript, waardoor de code in de Terraform-map enigszins werd gewijzigd. Ik heb onnodige bestanden verwijderd en noodzakelijke bestanden toegevoegd. En toen werd de stapel met één run van Terraform verhoogd.
En dan waren er nog andere stappen waar ik niet op wil ingaan.
Omdat we voor het testen iets meer opties nodig hadden dan bij de productie, moesten we kopieën van de modules maken, zodat we in deze kopieën de functies konden toevoegen die alleen nodig waren voor het testen.
En het gebeurde zo dat ik tijdens het testen eigenlijk die veranderingen wil testen die uiteindelijk in productie zullen gaan. Maar in feite werd één ding getest en bij de productie werd een iets ander gebruikt. En er was een kleine breuk in het patroon dat in de productie alle wijzigingen door het operatieteam werden toegepast. En soms bleek dat de veranderingen die van testen naar productie moesten gaan, in een andere versie bleven.
Bovendien was er zo'n probleem dat er een nieuwe dienst werd toegevoegd, die enigszins verschilde van een reeds bestaande dienst. En in plaats van een bestaande module aan te passen, moesten we er een kopie van maken en de nodige wijzigingen aanbrengen.
In wezen is Terraform geen echte taal. Dit is een verklaring. Als we iets moeten aangeven, dan geven we dat aan. En het werkt allemaal.
Op een gegeven moment, toen een van mijn pull-requests werd besproken, zei een van mijn collega's dat het niet nodig was om sneeuwvlokken te maken. Ik vroeg me af wat hij bedoelde. Er is een wetenschappelijk feit dat er geen twee identieke sneeuwvlokken in de wereld zijn, ze zijn allemaal enigszins verschillend. En zodra ik dit hoorde, voelde ik meteen het volle gewicht van de Terraform-code. Want toen het nodig was om van versie naar versie te gaan, vereiste Terraform het doorbreken van ketenwijzigingen, dat wil zeggen dat de code niet langer compatibel was met de volgende versie. En we moesten een pull-request doen, die bijna de helft van de bestanden in de infrastructuur besloeg, om de infrastructuur naar de volgende versie van Terraform te brengen.
En nadat zo'n sneeuwvlok verscheen, werd alle Terraform-code die we hadden omgezet in een grote, grote stapel sneeuw.
Voor een externe ontwikkelaar die buiten de operatie staat, maakt dit hem niet zoveel uit, omdat hij een pull-verzoek heeft gedaan, zijn resource is gestart. En dat is alles, het is niet meer zijn zorg. En het DevOps-team, dat ervoor zorgt dat alles in orde is, moet al deze veranderingen doorvoeren. En de kosten van deze veranderingen stegen heel erg met elke extra sneeuwvlok.
Er is een verhaal over hoe een student op een seminar twee perfecte cirkels tekent met krijt op het bord. En de leraar is verrast hoe hij zonder kompas zo soepel kon tekenen. De student antwoordt: “Heel simpel, ik heb twee jaar in het leger gezeten en aan een vleesmolen gedraaid.”
En van de vier jaar dat ik bij dit project betrokken ben, doe ik ongeveer twee jaar Terraform. En natuurlijk heb ik een paar trucjes, wat advies over hoe je de Terraform-code kunt vereenvoudigen, ermee kunt werken als een programmeertaal en de last kunt verminderen voor ontwikkelaars die deze code up-to-date moeten houden.
Het eerste waar ik mee wil beginnen zijn Symlinks. Terraform heeft veel repetitieve code. Zo is de oproep naar de provider op vrijwel elk punt waar we een stukje infrastructuur aanleggen hetzelfde. En het is logisch om het in een aparte map te plaatsen. En overal waar de provider verplicht is om Symlinks naar dit bestand te maken.
In de productie gebruik je bijvoorbeeld de rol aannemen, waarmee je toegangsrechten kunt krijgen tot een extern Amazon-account. En nadat één bestand is gewijzigd, hebben alle resterende bestanden in de bronboom de vereiste rechten, zodat Terraform weet tot welk Amazon-segment toegang moet worden verkregen.
Waar falen Symlinks? Zoals ik al zei, heeft Terraform staatsbestanden. En ze zijn heel, heel cool. Maar het punt is dat Terraform in de allereerste plaats de backend initialiseert. En hij kan geen variabelen in deze parameters gebruiken; ze moeten altijd in tekst worden geschreven.
En als gevolg daarvan kopieert iemand, wanneer hij een nieuwe bron maakt, een deel van de code uit andere mappen. En hij kan een fout maken met de sleutel of met de emmer. Hij maakt bijvoorbeeld een sandbox-ding van de sandbox en maakt het vervolgens in productie. En zo kan het blijken dat de emmer in productie vanuit de zandbak wordt gebruikt. Natuurlijk zullen ze het snel vinden. Het zal mogelijk zijn om dit op de een of andere manier op te lossen, maar het is niettemin een verspilling van tijd en, tot op zekere hoogte, van middelen.
Wat kunnen we nu doen? Voordat u met Terraform gaat werken, moet u het initialiseren. Bij de initialisatie downloadt Terraform alle plug-ins. Op een gegeven moment splitsten ze zich van een monoliet naar een meer microservice-architectuur. En je moet altijd Terraform init uitvoeren, zodat alle modules en plug-ins worden opgehaald.
En u kunt een shellscript gebruiken, dat ten eerste alle variabelen kan ophalen. Het shellscript is op geen enkele manier beperkt. En ten tweede de paden. Als we altijd het pad in de repository gebruiken als de sleutel tot het statusbestand, dan wordt de fout hier dienovereenkomstig geëlimineerd.
Waar kan ik de gegevens verkrijgen? JSON-bestand. Met Terraform kunt u infrastructuur niet alleen in hcl (HashiCorp Configuration Language) schrijven, maar ook in JSON.
JSON is eenvoudig te lezen vanuit een shellscript. Dienovereenkomstig kunt u het configuratiebestand met bucket ergens plaatsen. En gebruik deze bucket zowel in de Terraform-code als in het shell-script voor initialisatie.
Waarom is het belangrijk om een emmer te hebben voor Terraform? Omdat er zoiets bestaat als externe statusbestanden. Dat wil zeggen, wanneer ik een bron verzamel om Amazon te vertellen: "Verhoog de instantie alstublieft", moet ik een groot aantal vereiste parameters specificeren.
En deze identificatiegegevens worden in een andere map opgeslagen. En ik kan gaan zeggen: "Terraform, ga alsjeblieft naar het statusbestand van diezelfde bron en geef me deze identificatiegegevens." En zo ontstaat er een zekere eenwording tussen verschillende regio’s of omgevingen.
Het is niet altijd mogelijk om een extern statusbestand te gebruiken. U hebt bijvoorbeeld met de hand een VPC aangemaakt. En de Terraform-code die de VPC aanmaakt, creëert zulke verschillende VPC's dat het heel lang duurt en je de een op de ander moet aanpassen, dus je kunt de volgende truc gebruiken.
Dat wil zeggen: maak een module die een VPC lijkt te maken en je als het ware identifiers geeft, maar in feite is er gewoon een bestand met hardgecodeerde waarden die gebruikt kunnen worden om dezelfde instantie te maken.
Het is niet altijd nodig om het statusbestand in de cloud op te slaan. Bij het testen van modules kunt u bijvoorbeeld backend-initialisatie gebruiken, waarbij het bestand tijdens het testen eenvoudigweg op schijf wordt opgeslagen.
Nu iets over testen. Wat kun je testen in Terraform? Waarschijnlijk is er veel mogelijk, maar ik zal het over deze 4 dingen hebben.
HashiCorp begrijpt hoe Terraform-code moet worden opgemaakt. En met Terraform fmt kunt u de code die u bewerkt volgens deze overtuiging formatteren. Dienovereenkomstig moeten tests noodzakelijkerwijs controleren of de opmaak overeenkomt met wat HashiCorp heeft nagelaten, zodat het niet nodig is om de locatie van haakjes enz. Te wijzigen.
De volgende is Terraform valideren. Het doet weinig meer dan de syntaxis controleren - helaas, of alle haakjes gepaard zijn. Wat is hier belangrijk? Onze infrastructuur is zeer uitgebreid. Er zitten veel verschillende papa's in. En in elk moet je Terraform validate uitvoeren.
Om het testen te versnellen, voeren we daarom meerdere processen parallel uit.
Parallel is een heel cool ding, gebruik het.
Maar elke keer dat Terraform initialiseert, gaat het naar HashiCorp en vraagt: “Wat zijn de nieuwste plug-inversies? En de plug-in die ik in de cache heb – is dit de juiste of de verkeerde?” En dit vertraagde bij elke stap.
Als je Terraform vertelt waar de plug-ins staan, zegt Terraform: “Oké, dit is waarschijnlijk het nieuwste wat er is. Ik ga nergens heen, ik begin onmiddellijk met het valideren van uw Terraform-code.
Om de map met de benodigde plug-ins te vullen, hebben we een heel eenvoudige Terraform-code die alleen maar geïnitialiseerd hoeft te worden. Hier moet je natuurlijk alle providers opgeven die op de een of andere manier aan je code deelnemen, anders zegt Terraform: "Ik ken een bepaalde provider niet omdat deze niet in de cache staat."
Het volgende is het Terraform-plan. Zoals ik al zei, is de ontwikkeling cyclisch. Wij brengen wijzigingen aan in de code. En dan moet je weten welke veranderingen er gepland zijn voor de infrastructuur.
En als de infrastructuur heel erg groot is, kun je één module wijzigen, een testomgeving of een specifieke regio repareren en een aangrenzende module kapot maken. Daarom moet het Terraform-plan voor de gehele infrastructuur worden gemaakt en laten zien welke veranderingen gepland zijn.
Je kunt dit slim doen. We hebben bijvoorbeeld een Python-script geschreven dat afhankelijkheden oplost. En afhankelijk van wat er veranderd is: een Terraform-module of gewoon een specifiek onderdeel, maakt het plannen voor alle afhankelijke mappen.
Op verzoek moeten terraformplannen worden gemaakt. Dat is tenminste wat wij doen.
Natuurlijk is het goed om tests uit te voeren voor elke wijziging, voor elke commit, maar plannen zijn behoorlijk duur. En in een pull-request zeggen we: “Geef mij alstublieft de plannen.” De robot start. En stuurt opmerkingen in of voegt alle plannen toe die van uw wijzigingen worden verwacht.
Een plan is een behoorlijk duur ding. Het kost tijd omdat Terraform naar Amazon gaat en vraagt: “Bestaat deze instantie nog steeds? Heeft deze automatische schaalverdeling exact dezelfde parameters?” En om dit te versnellen, kunt u een parameter gebruiken zoals refresh=false. Dit betekent dat Terraform de status van S3 zal downloaden. En het zal geloven dat de staat precies zal overeenkomen met wat er in Amazon staat.
Zo'n Terraform-plan gaat veel sneller, maar de staat moet overeenkomen met uw infrastructuur, d.w.z. ergens, ooit moet de Terraform-vernieuwing beginnen. Terraform Refresh doet precies dat: de status komt overeen met wat zich in de daadwerkelijke infrastructuur bevindt.
En we moeten over veiligheid praten. Hier moesten we beginnen. Waar u Terraform draait en Terraform op uw infrastructuur draait, is er een kwetsbaarheid. Dat wil zeggen dat u in wezen de code uitvoert. En als de pull-request een of andere vorm van kwaadaardige code bevat, kan deze worden uitgevoerd op een infrastructuur die te veel toegang heeft. Wees dus voorzichtig waar u het Terraform-plan uitvoert.
Het volgende waar ik het over wil hebben is het testen van gebruikersgegevens.
Wat zijn gebruikersgegevens? Wanneer we in Amazon een exemplaar maken, kunnen we een bepaalde brief met het exemplaar sturen: metagegevens. Wanneer de instance start, is cloud init meestal altijd aanwezig op deze instances. Cloud init leest deze brief en zegt: “Ok, vandaag ben ik de load balancer.” En in overeenstemming met deze verbonden voert hij enkele handelingen uit.
Maar helaas, als we het Terraform-plan en Terraform toepassen, lijken gebruikersgegevens op dit soort brij van cijfers. Dat wil zeggen, hij stuurt je gewoon de hash. En het enige waar je in het plan naar kunt kijken is of er iets verandert of dat de hasj hetzelfde blijft.
En als je hier geen aandacht aan besteedt, kan er een kapot tekstbestand op Amazon terechtkomen, op de echte infrastructuur.
Als alternatief kunt u bij de uitvoering niet de gehele infrastructuur opgeven, maar alleen de sjabloon. En zeg in de code: "Geef deze sjabloon weer op mijn scherm." En als resultaat kunt u een afdruk krijgen van hoe uw gegevens er op Amazon uit zullen zien.
Een andere optie is het gebruik van een module om gebruikersgegevens te genereren. Je gaat deze module toepassen. U ontvangt het bestand op schijf. Vergelijk het met de referentie. En dus, als iemand besluit de gebruikersgegevens een beetje te corrigeren, zullen je tests zeggen: "Oké, er zijn hier en daar wat veranderingen - dit is normaal."
Het volgende waar ik het over zou willen hebben is de toepassing Automate Terraform.
Het is natuurlijk best eng om Terraform in de automatische modus toe te passen, want wie weet welke veranderingen daar zijn doorgevoerd en hoe destructief ze kunnen zijn voor de levende infrastructuur.
Voor een testomgeving is dit allemaal normaal. Dat wil zeggen: een baan die een testomgeving creëert, is wat alle ontwikkelaars nodig hebben. En een uitdrukking als “alles werkte voor mij” is geen grappige meme, maar een bewijs dat iemand in de war raakte, een stapel ophaalde en een aantal tests op deze stapel uitvoerde. En hij zorgde ervoor dat alles daar in orde was en zei: “Oké, de code die ik vrijgeef is getest.”
In productie-, sandbox- en andere omgevingen die bedrijfskritischer zijn, kun je sommige bronnen gedeeltelijk vrij veilig gebruiken, omdat dit niet tot gevolg heeft dat er iemand doodgaat. Dit zijn: groepen voor automatisch schalen, beveiligingsgroepen, rollen, route53, en de lijst daar kan behoorlijk groot zijn. Maar houd in de gaten wat er speelt, lees de geautomatiseerde sollicitatierapporten.
Als het gevaarlijk of beangstigend is om dit toe te passen, bijvoorbeeld als het om persistente bronnen uit een database gaat, ontvang dan rapporten dat er in een bepaald deel van de infrastructuur niet-toegepaste wijzigingen zijn. En de engineer gaat, onder begeleiding, aan de slag om te solliciteren of doet dat vanaf zijn console.
Amazon heeft zoiets als Bescherming beëindigen. En het kan in sommige gevallen bescherming bieden tegen wijzigingen die voor u niet nodig zijn. Dat wil zeggen, Terraform ging naar Amazon en zei: "Ik moet deze instantie beëindigen om er nog een te maken." En Amazon zegt: “Sorry, niet vandaag. We hebben Terminate-bescherming."
En de kers op de taart is code-optimalisatie. Wanneer we met Terraform-code werken, moeten we een zeer groot aantal parameters aan de module doorgeven. Dit zijn de parameters die nodig zijn om een soort hulpbron te creëren. En de code verandert in grote lijsten met parameters die moeten worden doorgegeven van module naar module, van module naar module, vooral als de modules genest zijn.
En het is heel moeilijk om te lezen. Het is heel moeilijk om dit te beoordelen. En heel vaak blijkt dat sommige parameters worden herzien en dat ze niet precies zijn wat nodig is. En dit kost tijd en geld om later te repareren.
Daarom stel ik voor dat u zoiets als een complexe parameter gebruikt die een bepaalde boom met waarden omvat. Dat wil zeggen, je hebt een soort map nodig waarin je alle waarden hebt die je in een bepaalde omgeving zou willen hebben.
En door deze module aan te roepen, kunt u een boom krijgen die in één gemeenschappelijke module wordt gegenereerd, dat wil zeggen in een gemeenschappelijke module die hetzelfde werkt voor de hele infrastructuur.
In deze module kunt u enkele berekeningen uitvoeren met behulp van een recente functie in Terraform als locals. En geef dan, met één uitvoer, een complexe parameter op, die array-hashes kan bevatten, enz.
Dit is waar de beste vondsten die ik heb gedaan, zijn geëindigd. En ik wil graag een verhaal vertellen over Columbus. Toen hij geld zocht voor zijn expeditie om India te ontdekken (zoals hij toen dacht), geloofde niemand hem en dachten ze dat het onmogelijk was. Toen zei hij: “Zorg ervoor dat het ei niet valt.” Alle bankiers, zeer rijke en waarschijnlijk slimme mensen, probeerden op de een of andere manier het ei te plaatsen, maar het bleef vallen. Toen pakte Columbus het ei en drukte er een beetje op. De schaal verfrommelde en het ei bleef roerloos liggen. Ze zeiden: "Oh, dat is te gemakkelijk!" En Columbus antwoordde: “Ja, het is te simpel. En als ik India open, zal iedereen deze handelsroute gebruiken."
En wat ik je net vertelde zijn waarschijnlijk vrij simpele en triviale dingen. En als je er meer over leert en ze gaat gebruiken, is dat aan de orde. Profiteer dus. En als dit volkomen normale dingen voor je zijn, dan weet je tenminste hoe je het ei zo moet plaatsen dat het niet valt.
Laten we het samenvatten:
- Probeer sneeuwvlokken te vermijden. En hoe minder sneeuwvlokken, hoe minder middelen u nodig heeft om wijzigingen door te voeren in uw grote infrastructuur.
- Voortdurende veranderingen. Dat wil zeggen dat wanneer er wijzigingen optreden in de code, u uw infrastructuur zo snel mogelijk aan deze wijzigingen moet aanpassen. Er mag zich geen situatie voordoen waarin iemand twee of drie maanden later naar Elasticsearch komt kijken, een Terraform-plan maakt en er een heleboel veranderingen zijn die hij niet had verwacht. En het kost veel tijd om alles weer op orde te krijgen.
- Testen en automatisering. Hoe meer je code bedekt is met tests en features, hoe meer vertrouwen je hebt dat je alles correct doet. En automatische bezorging zal uw vertrouwen vele malen vergroten.
- De code voor de test- en productieomgeving moet vrijwel hetzelfde zijn. Praktisch omdat de productie nog steeds een beetje anders is en er nog steeds enkele nuances zullen zijn die verder gaan dan de testomgeving. Maar toch, plus of min, dit kan worden gegarandeerd.
- En als je veel Terraform-code hebt en het veel tijd kost om deze code up-to-date te houden, dan is het nooit te laat om deze opnieuw te bewerken en in goede staat te krijgen.
- Onveranderlijke infrastructuur. AMI-bezorging op schema.
- Structuur voor route53 als u veel vermeldingen heeft en u wilt dat deze in een consistente volgorde staan.
- Het bestrijden van API-snelheidslimieten. Dit is het moment waarop Amazon zegt: "Dat is het, ik kan geen verzoeken meer accepteren, even geduld alstublieft." En de helft van het kantoor wacht totdat het zijn infrastructuur kan lanceren.
- Instanties spotten. Amazon is geen goedkoop evenement en met spots kun je flink besparen. En daar kun je er een heel verslag over vertellen.
- Beveiligings- en IAM-rollen.
- Op zoek naar verloren hulpbronnen, als je exemplaren van onbekende oorsprong in Amazone hebt, eten ze geld. Zelfs als instances €100-150 per maand kosten, is dat meer dan €1 per jaar. Het vinden van dergelijke hulpbronnen is een winstgevende onderneming.
- En gereserveerde exemplaren.
Dat is alles voor mij. Terraform is erg cool, je gebruikt het. Bedankt!
vragen
Bedankt voor het rapport! Je statusbestand bevindt zich in S3, maar hoe los je het probleem op dat meerdere mensen dit statusbestand kunnen nemen en proberen uit te breiden?
Allereerst hebben we geen haast. Ten tweede zijn er vlaggen, waarin we melden dat we aan een stukje code werken. Dat wil zeggen, ondanks het feit dat de infrastructuur erg groot is, betekent dit niet dat iemand constant iets gebruikt. En toen er een actieve fase was, was dit een probleem; we sloegen statusbestanden op in Git. Dit was belangrijk, anders zou iemand een staatsdossier maken en moesten we ze handmatig samenstellen om alles door te laten gaan. Nu is er geen dergelijk probleem. Over het algemeen heeft Terraform dit probleem opgelost. En als er voortdurend iets verandert, kun je sloten gebruiken die voorkomen wat je zei.
Gebruik je open source of enterprise?
Geen onderneming, dat wil zeggen alles wat u gratis kunt downloaden.
Mijn naam is Stanislav. Ik wilde een kleine toevoeging doen. U had het over een Amazon-functie waarmee u een exemplaar niet-killable kunt maken. Dit zit ook in Terraform zelf; in het Life Second-blok kun je een verbod op wijzigingen of een verbod op vernietiging opgeven.
De tijd was beperkt. Goed punt.
Ik wilde ook twee dingen vragen. Ten eerste had u het over testen. Heb je testtools gebruikt? Ik hoorde over de Test Kitchen-plug-in. Misschien is er nog iets. En ik zou ook graag vragen willen stellen over lokale waarden. Hoe verschillen ze fundamenteel van invoervariabelen? En waarom kan ik iets niet alleen parametriseren via Lokale Waarden? Ik heb geprobeerd dit onderwerp te achterhalen, maar op de een of andere manier kwam ik er zelf niet uit.
Buiten deze kamer kunnen we gedetailleerder praten. Onze testtools zijn volledig zelfgemaakt. Er is niets om te testen. Over het algemeen zijn er mogelijkheden wanneer geautomatiseerde tests ergens infrastructuur oppikken, controleren of deze in orde is en vervolgens alles vernietigen met een melding dat uw infrastructuur nog in goede staat is. We hebben dit niet omdat er elke dag teststacks worden uitgevoerd. En dat is genoeg. En als er iets kapot gaat, zal het ook kapot gaan zonder dat we het ergens anders hebben gecontroleerd.
Wat betreft Lokale Waarden: laten we het gesprek buiten de kamer voortzetten.
Hallo! Bedankt voor het rapport! Erg informatief. U zei dat u veel van hetzelfde type code heeft om de infrastructuur te beschrijven. Heeft u overwogen deze code te genereren?
Goede vraag, bedankt! Het punt is dat wanneer we infrastructuur als code gebruiken, we ervan uitgaan dat we naar de code kijken en begrijpen welke infrastructuur achter die code schuilgaat. Als er code wordt gegenereerd, moeten we ons voorstellen welke code er wordt gegenereerd om te begrijpen wat voor soort infrastructuur er zal zijn. Ofwel genereren we code, committen we deze, en in wezen gebeurt hetzelfde. Dus we volgden het pad dat we schreven, we snapten het. Plus-generatoren verschenen iets later toen we ze begonnen te maken. En het was al te laat om te veranderen.
Heb je iets gehoord over jsonnet?
Nee.
Kijk, dit is een heel cool ding. Ik zie een specifiek geval waarin je het kunt toepassen en een datastructuur kunt genereren.
Generatoren zijn goed als je ze hebt, zoals in de grap over een scheermachine. Dat wil zeggen, de eerste keer is het gezicht anders, maar dan heeft iedereen hetzelfde gezicht. De generatoren werken zeer goed. Maar helaas zijn onze gezichten iets anders. Dit is het probleem.
Kijk gewoon. Bedankt!
Mijn naam is Maxim, ik kom uit Sberbank. U vertelde iets over hoe u Terraform probeerde om te zetten in het equivalent van een programmeertaal. Is het niet eenvoudiger om Ansible te gebruiken?
Dit zijn heel verschillende dingen. Je kunt bronnen maken in Ansible en Puppet kan bronnen maken in Amazon. Maar Terraform is meteen geslepen.
Heb je alleen Amazon?
Het is niet zo dat we alleen Amazon hebben. We hebben bijna alleen Amazon. Maar het belangrijkste kenmerk is dat Terraform het onthoudt. Als je in Ansible zegt: "Geef me vijf instanties", dan gaat het omhoog, en dan zeg je: "En nu heb ik er drie nodig." En Terraform zal zeggen: "Oké, ik vermoord er twee", en Ansible zal zeggen: "Oké, hier zijn er drie voor jou." Totaal 5.
Hallo! Bedankt voor je rapport! Het was erg interessant om over Terraform te horen. Ik wil meteen een kleine opmerking maken over het feit dat Terraform nog steeds geen stabiele release heeft, dus wees voorzichtig met Terraform.
Een goede lepel voor het avondeten. Dat wil zeggen, als je een oplossing nodig hebt, dan stel je soms uit wat onstabiel is, etc., maar het werkt en het heeft ons geholpen.
De vraag is deze. Je gebruikt Remote backend, je gebruikt S 3. Waarom gebruik je niet de officiële backend?
Officieel?
Terraform-wolk.
Wanneer verscheen hij?
4 maanden geleden.
Als het 4 jaar geleden was verschenen, had ik waarschijnlijk je vraag beantwoord.
Er is al een ingebouwde functie en vergrendeling, en u kunt een statusbestand opslaan. Probeer het eens. Maar ik heb het ook niet getest.
We reizen met een grote trein die met hoge snelheid beweegt. En je kunt niet zomaar een paar auto’s meenemen en weggooien.
Je had het over sneeuwvlokken, waarom heb je geen tak gebruikt? Waarom lukte het niet zo?
Onze aanpak is dat de gehele infrastructuur zich in één repository bevindt. Terraform, Puppet, alle scripts die hier op de een of andere manier mee verband houden, ze bevinden zich allemaal in één repository. Op deze manier kunnen we ervoor zorgen dat incrementele wijzigingen één voor één worden getest. Als het een stel takken zou zijn, zou zo'n project bijna onmogelijk te onderhouden zijn. Zes maanden gaan voorbij, en ze lopen zo uiteen dat het gewoon een soort straf is. Dit is waar ik aan wilde ontsnappen voordat ik ging refactoren.
Dus het werkt niet?
Dit werkt helemaal niet.
In tak heb ik de mapschuif uitgeknipt. Dat wil zeggen, als je het voor elke teststack doet, bijvoorbeeld team A heeft een eigen map, team B heeft een eigen map, dan werkt dit ook niet. We hebben een uniforme testomgevingscode gemaakt die flexibel genoeg was voor iedereen. Dat wil zeggen, we hebben één code geserveerd.
Hallo! Mijn naam is Yura! Bedankt voor het rapport! Vraagje over modules. Je zegt dat je modules gebruikt. Hoe los je het probleem op als er in de ene module wijzigingen zijn aangebracht die niet compatibel zijn met de wijziging van iemand anders? Ben je op de een of andere manier bezig met het versiebeheer van de modules of probeer je een wonderwaffle te maken die aan twee vereisten voldoet?
Dit is een groot sneeuwstapelprobleem. Dit is waar we last van hebben als een onschadelijke verandering een deel van de infrastructuur kapot kan maken. En dit zal pas na enige tijd merkbaar zijn.
Dat wil zeggen: het is nog niet opgelost?
Je maakt universele modules. Vermijd sneeuwvlokken. En alles zal lukken. De tweede helft van het rapport gaat over hoe u dit kunt voorkomen.
Hallo! Bedankt voor het rapport! Ik wil dit graag verduidelijken. Achter de schermen lag een grote stapel waar ik voor kwam. Hoe zijn poppen- en rolverdeling geïntegreerd?
Gebruikersgegevens.
Dat wil zeggen, je spuugt het bestand gewoon uit en voert het op de een of andere manier uit?
Gebruikersgegevens zijn een notitie, dat wil zeggen dat wanneer we een kloon van de afbeelding maken, Daemon daar opstaat en, in een poging erachter te komen wie hij is, de notitie leest dat hij een load balancer is.
Dat wil zeggen: is dit een soort afzonderlijk proces dat wordt weggegeven?
Wij hebben het niet uitgevonden. Wij gebruiken het.
Hallo! Ik heb een vraag over Gebruikersgegevens. U zei dat daar problemen zijn, dat iemand iets naar de verkeerde plaats zou kunnen sturen. Is er een manier om gebruikersgegevens in dezelfde Git op te slaan, zodat het altijd duidelijk is waar gebruikersgegevens naar verwijzen?
We genereren gebruikersgegevens op basis van een sjabloon. Dat wil zeggen dat daar een bepaald aantal variabelen wordt gebruikt. En Terraform genereert het eindresultaat. Daarom kun je niet alleen naar de sjabloon kijken en zeggen wat er zal gebeuren, omdat alle problemen verband houden met het feit dat de ontwikkelaar denkt dat hij een string in deze variabele doorgeeft, maar daar wordt een array gebruikt. En hij - bam en ik - zo-en-zo, zo-en-zo, de volgende regel, en alles brak. Als dit een nieuwe hulpbron is en iemand deze oppakt en ziet dat iets niet werkt, dan is het snel opgelost. En als deze groep voor automatisch schalen wordt bijgewerkt, worden op een gegeven moment de exemplaren in de groep voor automatisch schalen vervangen. En boem, er werkt iets niet. Het doet pijn.
Het blijkt dat testen de enige oplossing is?
Ja, je ziet het probleem, je voegt daar teststappen toe. Dat wil zeggen dat de output ook kan worden getest. Misschien is het niet zo handig, maar je kunt ook wat markeringen zetten - controleer of de gebruikersgegevens hier zijn vastgelegd.
Mijn naam is Timoer. Het is heel gaaf dat er rapporten zijn over hoe je Terraform goed kunt organiseren.
Ik ben nog niet eens begonnen.
Ik denk dat dat er misschien op de volgende conferentie wel zal zijn. Ik heb een simpele vraag. Waarom codeer je de waarde in een aparte module in plaats van tfvars te gebruiken, d.w.z. waarom is een module met waarden beter dan tfvars?
Dat wil zeggen, moet ik hier schrijven (dia: Production/environment/settings.tf): domein = variabel, domein vpcnetwork, variabel vpcnetwork en stvars – kan ik hetzelfde krijgen?
Dat is precies wat wij doen. We verwijzen bijvoorbeeld naar de instellingsbronmodule.
In wezen zijn dit zulke tfvars. Tfvars is erg handig in een testomgeving. Ik heb tfvars voor grote exemplaren, voor kleine. En ik gooide één bestand in de map. En ik kreeg wat ik wilde. Wanneer we in de infrastructuur snijden, willen we dat het mogelijk is om alles te bekijken en meteen te begrijpen. En dus blijkt dat je hier moet kijken en dan naar tfvars moet kijken.
Is het mogelijk om alles op één plek te hebben?
Ja, tfvars is wanneer je één code hebt. En het wordt op verschillende plaatsen met verschillende nuances gebruikt. Dan zou je tfvars gooien en je nuances krijgen. En wij zijn infrastructuur als code in zijn puurste vorm. Ik keek en begreep het.
Hallo! Bent u situaties tegengekomen waarin de cloudprovider zich bemoeit met wat u van Terraform hebt gemaakt? Laten we zeggen dat we de metagegevens bewerken. Er zijn ssh-sleutels. En Google plaatst daar voortdurend zijn metadata en sleutels. En Terraform schrijft altijd dat er veranderingen zijn. Na elke run, zelfs als er niets verandert, zegt hij altijd dat hij dit veld nu zal bijwerken.
Met sleutels, maar ja, een deel van de infrastructuur wordt hierdoor beïnvloed, dat wil zeggen dat Terraform niets kan veranderen. Ook met onze handen kunnen we niets veranderen. Wij zullen er voorlopig mee moeten leven.
Dat wil zeggen, je bent zoiets tegengekomen, maar je hebt niets bedacht, hoe doet hij dat en doet hij het zelf?
Helaas, ja.
Hallo! Mijn naam is Starkov Stanislav. Mail. ru Groep. Hoe los je het probleem op van het genereren van een tag op..., hoe geef je deze door naar binnen? Zoals ik het begrijp, kun je via Gebruiker - gegevens de hostnaam opgeven, Puppet inschakelen? En het tweede deel van de vraag. Hoe los je dit probleem op in SG, dat wil zeggen: als je SG genereert, honderden instanties van hetzelfde type, wat is dan de juiste naam ervoor?
Die voorbeelden die voor ons heel belangrijk zijn, benoemen we mooi. Voor degenen die niet nodig zijn, is er een opmerking dat dit een groep voor automatisch schalen is. En in theorie kun je het vastspijkeren en een nieuwe krijgen.
Wat het probleem met de tag betreft: zo'n probleem bestaat niet, maar er is wel zo'n taak. En we maken heel veel gebruik van tags, omdat de infrastructuur groot en duur is. En we moeten kijken waar het geld naartoe gaat, zodat we met tags kunnen opsplitsen wat waar naartoe is gegaan. En dienovereenkomstig wordt hier gezocht naar iets dat veel geld betekent.
Waar ging de vraag verder over?
Als SG honderden exemplaren maakt, moeten ze dan op de een of andere manier van elkaar worden onderscheiden?
Nee, niet doen. Bij elke instantie is er een agent die meldt dat ik een probleem heb. Als een agent zich meldt, is de agent op de hoogte van hem en bestaat op zijn minst zijn IP-adres. Je kunt al weglopen. Ten tweede gebruiken we Consul voor Discovery, waar Kubernetes dat niet is. En Consul toont ook het IP-adres van de instantie.
Dat wil zeggen: richt u zich specifiek op IP, en niet op de hostnaam?
Het is onmogelijk om op hostnaam te navigeren, d.w.z. er zijn er veel. Er zijn instantie-ID's - AE, enz. Je kunt het ergens vinden, je kunt het in de zoekopdracht gooien.
Hallo! Ik besefte dat Terraform een goede zaak is, op maat gemaakt voor de wolken.
Niet alleen.
Dit is precies de vraag die mij interesseert. Als je besluit om massaal met al je instances over te stappen naar bijvoorbeeld Bare Metal? Zullen er problemen zijn? Of moet je toch andere producten gebruiken, bijvoorbeeld dezelfde Ansible die hier werd genoemd?
Ansible gaat over iets anders. Dat wil zeggen dat Ansible al werkt wanneer de instantie is gestart. En Terraform werkt voordat de instance start. Overstappen naar Bare Metal - nee.
Niet nu, maar de zakenwereld zal komen en zeggen: “Kom op.”
Overschakelen naar een andere cloud – ja, maar er is hier een iets andere truc. Je moet Terraform-code zo schrijven dat je met minder moeite naar een andere cloud kunt overstappen.
Aanvankelijk was de taak gesteld dat onze hele infrastructuur agnostisch zou zijn, dat wil zeggen dat elke cloud geschikt zou moeten zijn, maar op een gegeven moment gaf het bedrijf het op en zei: “Oké, de komende N jaar gaan we nergens heen, we kunnen diensten gebruiken van Amazon"
Met Terraform kunt u Front-End-taken maken, PagerDuty, datadoc configureren, enz. Het heeft veel staarten. Hij kan praktisch de hele wereld beheersen.
Bedankt voor het rapport! Ik gebruik Terraform ook al 4 jaar. In de fase van een soepele overgang naar Terraform, naar infrastructuur, naar een declaratieve beschrijving, werden we geconfronteerd met een situatie waarin iemand iets met de hand deed en je een plan probeerde te maken. En daar kreeg ik een of andere fout. Hoe ga je om met zulke problemen? Hoe vind je verloren bronnen die zijn vermeld?
Als we iets vreemds in het rapport zien, analyseren we vooral met onze handen en ogen wat daar gebeurt, of doden we gewoon. Over het algemeen zijn pull-aanvragen gebruikelijk.
Als er een fout optreedt, gaat u dan terug? Heb je dit geprobeerd?
Nee, dit is de beslissing van een persoon op het moment dat hij een probleem ziet.
Bron: www.habr.com