Het lijkt erop dat Terraform-ontwikkelaars behoorlijk handige best practices bieden voor het werken met AWS-infrastructuur. Er is echter een kanttekening. Na verloop van tijd neemt het aantal omgevingen toe, en elk heeft zijn eigen kenmerken. Er verschijnt bijna een kopie van de applicatiestack in een naburig gebied. En de Terraform-code moet zorgvuldig worden gekopieerd en bewerkt volgens de nieuwe eisen, of een sneeuwvlok worden gemaakt.
Mijn presentatie gaat over patronen in Terraform om chaos en handmatige routine aan te pakken in grote en langdurige projecten.
Video:
Ik ben 40, ik werk 20 jaar in de IT. Al 12 jaar werk ik bij Ixtens. We zijn gespecialiseerd in e-commerce-gedreven ontwikkeling. En ik pas al 5 jaar DevOps-praktijken toe.
Mijn verhaal gaat over de ervaring in een project bij een bedrijf waarvan ik de naam niet zal noemen, in verband met een geheimhoudingscontract.
De cijfers op de dia zijn bedoeld om de omvang van het project te begrijpen. En alles wat ik verder zal zeggen, is gerelateerd aan Amazon.
Ik ben 4 jaar geleden bij dit project gekomen. En halverwege vond de refactoring van de infrastructuur plaats, omdat het project was gegroeid. En de patronen die werden gebruikt, waren al niet meer geschikt. Gezien de geplande groei van het project, moest er iets nieuws worden bedacht.
Dank aan Matvey, die gisteren vertelde wat er bij Dodo Pizza gebeurde. Dit is wat er 4 jaar geleden bij ons gebeurde.
De ontwikkelaars kwamen en begonnen infrastructurele code te maken.
De meest voor de hand liggende redenen waarom dit nodig was, waren de time-to-market. Het moest zo zijn dat het DevOps-team geen bottleneck was bij de uitrol. En bovenal werden Terraform en Puppet in het eerste niveau gebruikt.
Terraform is een open source project van HashiCorp. En voor degenen die geen idee hebben wat het is, de volgende paar dia's.
Infrastructuur als code betekent dat we onze infrastructuur kunnen beschrijven en robots kunnen vragen om de resources te creëren die we hebben beschreven.
Bijvoorbeeld, we hebben een virtuele machine. We beschrijven dit en voegen een paar verplichte parameters toe.
Daarna stellen we toegang tot Amazon in de console in. En we vragen Terraform om een plan. Terraform plan zegt: 'Oké, voor uw resource kunnen we dit soort dingen doen'. En, minimaal, één resource zal worden toegevoegd. En er worden geen wijzigingen verwacht.
Nadat u tevreden bent, kunt u Terraform apply vragen en Terraform creëert een instance voor u, en u ontvangt een virtuele machine in uw cloud.
Vervolgens ontwikkelt ons project zich verder. We voegen daar veranderingen aan toe. We vragen om meer instances en voegen 53 records toe.
En we herhalen. We vragen om een plan. We zien welke veranderingen gepland zijn. We passen toe. Op deze manier groeit onze infrastructuur.
Terraform gebruikt iets dat state-bestanden wordt genoemd. Dat wil zeggen, alle veranderingen die naar Amazon gaan, worden opgeslagen in een bestand waarin voor elke resource die je hebt beschreven, de bijbehorende resources zijn die in Amazon zijn gemaakt. Hierdoor weet Terraform precies wat er moet worden aangepast in Amazon bij wijziging van de beschrijving van een resource.
Deze state-bestanden waren oorspronkelijk gewoon bestanden. En we slaagden ze in Git op, wat zeer onhandig was. Iemand vergat constant om de wijzigingen te committen, wat leidde tot veel conflicten.
Nu is er de mogelijkheid om een backend te gebruiken, dat wil zeggen, je geeft aan Terraform in welke bucket en onder welke sleutel het state-bestand moet worden opgeslagen. Terraform zorgt er zelf voor dat het dit state-bestand ophaalt, de magie doet en het eindresultaat terugplaatst.
Onze infrastructuur groeit. Dit is onze code. En we willen nu niet gewoon een virtuele machine maken, we willen een testomgeving hebben.
Terraform maakt het mogelijk om iets te doen zoals een module, dat wil zeggen, hetzelfde in een bepaalde map te beschrijven.
En bijvoorbeeld, in de testomgeving deze module aanroepen en hetzelfde verkrijgen alsof we Terraform apply in de module zelf uitvoerden. Voor het testen zou deze code eruitzien.
Voor productie kunnen we daar enige veranderingen naartoe sturen, omdat we in de testomgeving geen grote instances nodig hebben, terwijl grote instances in productie juist nuttig zijn.
En daarna keer ik terug naar het project. Er was een complexe taak, de infrastructuur werd als zeer groot gepland. We moesten de hele code zodanig organiseren dat deze handig was voor iedereen: zowel voor degenen die het onderhoud van deze code uitvoeren als voor degenen die wijzigingen aanbrengen. Het was de bedoeling dat elke ontwikkelaar de infrastructuur kon aanpassen zoals nodig voor zijn deel van het platform.
Dit is de aanbevolen mappenstructuur door HashiCorp als je een groot project hebt en het zinvol is om de hele infrastructuur in kleine stukjes te verdelen, en elk stukje in een aparte map te beschrijven.
Met een uitgebreide bibliotheek van resources kunnen we in de testomgeving en in productie ongeveer hetzelfde aanroepen.
In ons geval was dit niet helemaal geschikt, omdat de teststack voor ontwikkelaars of voor testen op een eenvoudigere manier moest worden verkregen. Het was niet prettig om door mappen te navigeren en deze in de juiste volgorde toe te passen, en je zorgen te maken dat de database opstartte en dan de instantie die deze database gebruikte opstartte. Daarom werd alle testing vanuit één map uitgevoerd. Daar werden dezelfde modules aangeroepen, maar alles gebeurde in één keer.
Terraform beheert alle afhankelijkheden. Het creëert altijd bronnen in de juiste volgorde, zodat je bijvoorbeeld een IP-adres kunt krijgen van een net aangemaakte instantie, en dit IP-adres in een route53-record kunt verkrijgen.
Bovendien is het platform erg groot. Het opstarten van een teststack, zelfs al is het maar voor een uur of acht, is een behoorlijk dure aangelegenheid.
We hebben dit proces automatisch gemaakt. De Jenkins-job stelde ons in staat om de stack te starten. Je moest een pull request indienen met de wijzigingen die de ontwikkelaar wilde testen, alle benodigde opties, componenten en ook de groottes opgeven. Als hij performance testing wil, kan hij meer instanties gebruiken. Als hij gewoon wil controleren of een formulier opent, kan hij starten met de minimale configuratie. Ook moest hij opgeven of een cluster nodig was of niet, enzovoort.
Daarna duwde Jenkins een shell-script dat de code in de Terraform-map iets wijzigde. Het verwijderde onnodige bestanden en voegde de benodigde bestanden toe. En daarna werd de stack met één draai van Terraform apply opgestart.
Daarna volgden andere stappen waar ik niet verder op in wil gaan.
Omdat we voor testing iets meer opties nodig hadden dan in producties, moesten we kopieën van modules maken, zodat we in deze kopieën de functies konden toevoegen die alleen voor testing nodig waren.
En zo kwam het dat we in testing de veranderingen wilden testten die uiteindelijk naar productie zouden gaan. Maar in werkelijkheid werd één ding getest en werd iets anders in productie toegepast. En er was een kleine discrepantie doordat alle wijzigingen in productie werden doorgevoerd door het operationele team. Soms bleek dat de wijzigingen die van testing naar productie moesten gaan, in een andere versie bleven.
Daarnaast was er het probleem dat er een nieuwe service werd toegevoegd die iets verschilde van een bestaande. In plaats van de bestaande module te modificeren, moesten we een kopie maken en de nodige wijzigingen aanbrengen.
Eigenlijk is Terraform geen echte programmeertaal. Het is een declaratie. Als we iets moeten declareren, dan doen we dat. En dat werkt gewoon.
Op een gegeven moment, tijdens de bespreking van een van mijn pull requests, zei een collega dat we geen sneeuwvlokken moesten creëren. Ik was benieuwd wat hij daarmee bedoelde. Er is een wetenschappelijk feit dat er geen twee identieke sneeuwvlokken in de wereld bestaan; ze verschillen altijd een beetje. En zodra ik dat hoorde, voelde ik meteen de zwaarte van de Terraform-code. Want wanneer er een versieupgraden was, vereiste Terraform breaking chain wijzigingen, dat wil zeggen dat de code niet meer compatibel was met de volgende versie. En het was noodzakelijk om een pull request te doen dat bijna de helft van de bestanden in de infrastructuur bedekte om de infrastructuur naar de volgende versie van Terraform te brengen.
En nadat zo'n sneeuwvlok was ontstaan, veranderde alle Terraform-code die we hadden in een grote, grote hoop sneeuw.
Voor een externe ontwikkelaar, die buiten de operationele kring staat, maakt het niet veel uit, omdat hij een pull request heeft gedaan en zijn resource is gestart. En dat is het, verder is het niet zijn zorg. Maar voor het DevOps-team, dat ervoor zorgt dat alles in orde is, moeten al deze wijzigingen worden aangebracht. En de kosten van deze wijzigingen stegen enorm met elke extra sneeuwvlok.
Er is een verhaal over een student die op een seminar met krijt op het bord twee perfecte cirkels tekent. De docent vraagt zich verbijsterd af hoe hij dat zonder passer zo precies kon doen. De student antwoordt: "Heel simpel, ik heb twee jaar het vlees aan een vleesmolens draaide in het leger."
En van die vier jaar dat ik aan dit project deelneem, ben ik ongeveer twee jaar bezig met Terraform. En natuurlijk heb ik enkele trucs, enkele tips om de Terraform-code te vereenvoudigen, om ermee te werken als met een programmeertaal en om de belasting op ontwikkelaars die deze code up-to-date moeten houden te verminderen.
Het eerste waar ik mee wil beginnen, zijn Symlinks. Terraform heeft veel herhalende code. Bijvoorbeeld, de aanroep van de provider komt praktisch op elk punt waar we een stukje infrastructuur aanmaken, hetzelfde voor. Het is logisch om dit in een aparte map te plaatsen. En overal waar de provider nodig is, maak symlinks naar dit bestand.
Bijvoorbeeld, als je in productie een assume role gebruikt, waarmee je toegang kunt krijgen tot een externe Amazon-account. En door één bestand te wijzigen, zullen alle andere in de resourceboom de vereiste rechten hebben, zodat Terraform weet naar welk Amazon-segment hij moet verwijzen.
Waar werken Symlinks niet? Zoals ik al zei, zijn er state-bestanden in Terraform. En ze zijn echt heel goed. Maar het probleem is dat Terraform de backend bij de allereerste initialisatie opstart. En hij kan in deze parameters geen variabelen gebruiken; die moeten altijd in platte tekst worden geschreven.
Als resultaat, wanneer iemand een nieuwe resource aanmaakt, kopieert hij een deel van de code uit andere mappen. En hij kan zich vergissen met de sleutel of met de bucket. Bijvoorbeeld, hij maakt van sandbox iets in sandbox, en dan in productie. En zo kan het gebeuren dat de bucket in productie uit sandbox wordt gebruikt. Natuurlijk zullen ze dit snel opmerken. Het kan op een of andere manier worden gecorrigeerd, maar desondanks is het een verspilling van tijd en in enige mate van middelen.
Wat kunnen we verder doen? Voordat we met Terraform gaan werken, moet het worden geïnitialiseerd. Op het moment van initialisatie downloadt Terraform alle plugins. Op een gegeven moment zijn ze uit een monoliet opgebroken in een meer microservices-architectuur. En je moet altijd Terraform init uitvoeren, zodat het alle modules en plugins opslaat.
En je kunt een shell-script gebruiken dat, ten eerste, alle variabelen kan ophalen. Een shell-script is nergens aan gebonden. En, ten tweede, paden. Als we altijd het pad gebruiken dat in de repository staat als sleutel naar het state-bestand, is de kans op een fout hierin uitgesloten.
Waar haal je de gegevens vandaan? JSON-bestand. Terraform staat toe om infrastructuur niet alleen in hcl (HashiCorp Configuration Language) te registreren, maar ook in JSON.
JSON is eenvoudig te lezen vanuit een shell-script. Dus je kunt een configuratiebestand met de bucket op een bepaalde plek plaatsen. En deze bucket gebruiken in zowel de Terraform-code als in het shell-script voor initialisatie.
Waarom is het belangrijk om een bucket voor Terraform te hebben? Omdat er zoiets bestaat als remote state-bestanden. Dat betekent dat wanneer ik een bepaalde resource opzet, ik om Amazon te zeggen: 'Zet alsjeblieft de instance op', veel verplichte parameters moet opgeven.
En die identificatoren worden in een andere map opgeslagen. En ik kan zeggen: 'Terraform, ga alsjeblieft naar het state-bestand van die resource en haal die identificatoren voor me op.' Zo ontstaat er een zekere uniformiteit tussen verschillende regio's of omgevingen.
Het is niet altijd mogelijk om een remote state-bestand te gebruiken. Bijvoorbeeld, als je handmatig een VPC hebt aangemaakt. En de Terraform-code die een VPC aanmaakt, maakt een VPC die zo verschillend is dat je heel veel moeite moet doen om het op elkaar af te stemmen, daarom kun je de volgende truc gebruiken.
Dat wil zeggen, maak een module die een VPC aanmaakt en je de identificatoren geeft, terwijl er in werkelijkheid gewoon een bestand is met hardcoded waarden die je kunt gebruiken om dezelfde instance aan te maken.
Het is niet altijd nodig om het state-bestand in de cloud op te slaan. Bijvoorbeeld, wanneer modules worden getest, kan je backend-initialisatie gebruiken, waarbij het bestand gewoon op de schijf wordt opgeslagen tijdens het testen.
Laten we nu kort iets zeggen over testen. Wat kan je in Terraform testen? Misschien is er veel te testen, maar ik zal het hebben over deze vier dingen.
HashiCorp heeft een idee over hoe Terraform-code moet worden opgemaakt. Terraform fmt laat je de code die je bewerkt opmaken volgens deze richtlijn. De tests moeten dus controleren of de opmaak voldoet aan wat HashiCorp heeft voorgeschreven, zodat je niet de plaatsing van haakjes e.d. hoeft te veranderen.
De volgende is Terraform validate. Het doet iets meer dan alleen de syntaxis controleren - zoals of alle haakjes paren zijn. Wat hier belangrijk is? Onze infrastructuur is erg uitgebreid. Er zijn veel verschillende mappen en in elke moet Terraform validate worden uitgevoerd.
Om het testen te versnellen, voeren we meerdere processen parallel uit, gebruik makend van parallel.
Parallel is een geweldige functie, maak er gebruik van.
Maar elke keer dat Terraform wordt geïnitialiseerd, gaat het naar HashiCorp en vraagt: "Wat zijn de nieuwste versies van de plugins? En is de plugin die ik in de cache heb, de juiste of niet?". Dit zorgt bij elke stap voor vertraging.
Als je Terraform zou vertellen waar de plugins zijn, dan zou Terraform zeggen: "Oké, dit is waarschijnlijk het meest recente dat er is. Ik ga nergens heen, ik begin meteen met het valideren van je Terraform-code."
Om de juiste plugins in de map te krijgen, hebben we heel eenvoudige Terraform-code nodig die je gewoon moet initialiseren. Hier moet je natuurlijk alle providers opgeven die op de een of andere manier betrokken zijn bij je code, anders zegt Terraform: "Ik ken geen provider omdat deze niet in de cache zit."
Het volgende is Terraform plan. Zoals ik al zei, is ontwikkeling cyclisch. We maken code met wijzigingen. En vervolgens moeten we weten welke wijzigingen voor de infrastructuur zijn gepland.
Wanneer de infrastructuur heel groot is, kun je één module wijzigen, een testomgeving repareren of een specifieke regio aanpassen en tegelijkertijd iets kapotmaken in de buurt. Daarom moet Terraform plan voor de hele infrastructuur worden uitgevoerd en laten zien welke wijzigingen zijn gepland.
Dit kan op een slimme manier worden gedaan. Wij hebben bijvoorbeeld een script in Python geschreven dat afhankelijkheden oplost. Afhankelijk van wat er is gewijzigd: de Terraform-module of gewoon een specifiek component, maakt het plannen voor alle afhankelijke mappen.
Terraform plan moet op aanvraag worden uitgevoerd. Tenminste, dat is wat wij doen.
Tests zijn natuurlijk goed om bij elke wijziging en elke commit te doen, maar plannen zijn een behoorlijk dure aangelegenheid. En in de pull request zeggen we: "Alsjeblieft, geef me de plannen." Een robot wordt gestart. En deze stuurt in de opmerkingen of als bijlage alle plannen die worden vermoed voor je wijzigingen.
Een plan is redelijk kostbaar. Het kost tijd omdat Terraform naar Amazon gaat en vraagt: "Bestaat deze instance nog? Heeft deze autoscale precies dezelfde parameters?". En om dit te versnellen, kun je een parameter gebruiken zoals refresh=false. Dit betekent dat Terraform de state uit S3 haalt. En het zal geloven dat de state exact overeenkomt met wat er in Amazon is.
Dit Terraform-plan verloopt veel sneller, maar de status moet overeenkomen met uw infrastructuur, dat wil zeggen, er moet op een gegeven moment een Terraform-refresh worden uitgevoerd. Terraform-refresh doet precies dat, zodat de status overeenkomt met wat zich in de echte infrastructuur bevindt.
En we moeten het hebben over veiligheid. Hier hadden we eigenlijk mee moeten beginnen. Daar waar u Terraform draait en Terraform werkt met uw infrastructuur, is er een kwetsbaarheid. Dat wil zeggen, u voert in wezen code uit. En als de pull request schadelijke code bevat, kan deze worden uitgevoerd op de infrastructuur die te veel toegang heeft. Wees dus voorzichtig waar u Terraform-plan uitvoert.
Het volgende waar ik het over wil hebben, is het testen van user-data.
Wat is user-data? In Amazon, wanneer we een instantie maken, kunnen we iets versturen vanuit de instantie - metadata. Wanneer de instantie wordt opgestart, is cloud init meestal altijd aanwezig op deze instanties. Cloud init leest deze gegevens en zegt: 'Oké, vandaag ben ik een load balancer.' En op basis van deze instructies verricht het bepaalde acties.
Helaas, wanneer we Terraform-plan en Terraform-apply uitvoeren, ziet de user-data eruit als een rommelige keten van cijfers. Dat wil zeggen, het stuurt u gewoon een hash. En alles wat u in het plan kunt bekijken, is of er veranderingen zullen zijn of dat de hash hetzelfde blijft.
Als u hier geen aandacht aan besteedt, kan er op Amazon een beschadigd tekstbestand naar de echte infrastructuur worden verzonden.
Een optie is om bij het uitvoeren niet de gehele infrastructuur aan te geven, maar alleen de template. En in de code te zeggen: 'Geef me deze template alsjeblieft weer.' Zo kunt u afdrukken hoe uw gegevens op Amazon eruit zullen zien.
Een andere optie is om een module te gebruiken voor het genereren van user-data. U past deze module toe. U krijgt een bestand op de schijf. U vergelijkt het met een referentie. Op deze manier, als een junior besluit om user-data een beetje aan te passen, zullen uw tests zeggen: 'Oké, hier en hier zijn wat veranderingen - dat is normaal.'
Het volgende waar ik het over wil hebben, is het automatiseren van Terraform apply.
Natuurlijk is het behoorlijk eng om Terraform apply automatisch uit te voeren, want wie weet welke wijzigingen zijn binnengekomen en hoe destructief ze kunnen zijn voor de live infrastructuur.
Voor een testomgeving is dit allemaal goed. Dat wil zeggen, de job die de testomgeving creëert, is wat alle ontwikkelaars nodig hebben. En zo'n uitspraak als "ik had alles werkend" is geen grappige meme, maar een bewijs dat iemand zich heeft ingespannen, de stack heeft opgezet en daar een paar tests op heeft uitgevoerd. En hij heeft zich ervan overtuigd dat alles in orde is en zei: "Oké, de code die ik vrijgeef is getest."
In productie-, sandbox- en andere omgevingen die belangrijker zijn voor het bedrijf, kunnen sommige bronnen gedeeltelijk veilig worden toegepast, omdat dit niet leidt tot iemand die sterft. Dit zijn: autoscale-groepen, beveiligingsgroepen, rollen, route53 en de lijst kan behoorlijk groot zijn. Maar blijf letten op wat er gebeurt, lees de rapporten over automatische toepassingen.
Waar het gevaarlijk of eng is om toe te passen, bijvoorbeeld als het gaat om persistent resources of databases, krijg dan rapporten over onbenutte wijzigingen in een bepaald deel van de infrastructuur. En de engineer start onder toezicht jobs om deze toe te passen of doet dit vanaf zijn console.
Bij Amazon is er zoiets als Terminate protection. En het kan in sommige gevallen beschermen tegen ongewenste wijzigingen voor jou. Dat wil zeggen, Terraform gaat naar Amazon en zegt: "Ik moet deze instance beëindigen om een andere te maken." En Amazon zegt: "Sorry, niet vandaag. We hebben Terminate protection ingesteld."
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 resource te creëren. En de code verandert in grote lijsten van parameters die van module naar module moeten worden doorgegeven, vooral als het om geneste modules gaat.
En dit is erg moeilijk leesbaar. Het is erg moeilijk om review te doen. En vaak gebeurt het dat sommige parameters de review doorlopen, maar niet helemaal degene zijn die nodig zijn. Dit kost tijd en geld om later te corrigeren.
Daarom raad ik je aan om zoiets als een complexe parameter te gebruiken, die een boomstructuur van waarden bevat. Dat wil zeggen, je hebt een map nodig waarin alle waarden zijn vermeld die je op een bepaalde omgeving zou willen hebben.
Door dit module aan te roepen, kun je de boom krijgen die wordt gegenereerd in één gemeenschappelijk module, dat wil zeggen, in een gemeenschappelijk module die op dezelfde manier werkt voor de hele infrastructuur.
In dit module kun je bepaalde berekeningen maken, gebruikmakend van een nieuwe functie in Terraform, genaamd locals. En dan kun je met één output een complexe parameter genereren, die hashes, arrays, enz. kan bevatten.
Dit is waar al mijn beste bevindingen eindigen. Ik wil graag een verhaal vertellen over Columbus. Toen hij geld zocht voor zijn expeditie om India te ontdekken (zoals hij dacht), geloofde niemand erin en werd het als onmogelijk beschouwd. 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 zetten, maar het viel steeds. Toen nam Columbus het ei, drukte er een beetje op. De schaal vervormde en het ei bleef stil liggen. Ze zeiden: "Oh, dat is te eenvoudig!". En Columbus antwoordde: "Ja, dat is te eenvoudig. En wanneer ik India ontdek, zullen iedereen deze handelsroute gebruiken."
Wat ik je nu heb verteld, zijn waarschijnlijk vrij eenvoudige en triviale dingen. En wanneer je erachter komt en begint te gebruiken, is dat heel normaal. Dus maak er gebruik van. En als dit voor jou volkomen normale dingen zijn, dan weet je in ieder geval hoe je het ei moet zetten zodat het niet valt.
Laten we de balans opmaken:
- Probeer sneeuwvlokken te vermijden. Hoe minder sneeuwvlokken er zijn, hoe minder middelen je nodig hebt om wijzigingen in je grote infrastructuur aan te brengen.
- Voortdurende veranderingen. Dat wil zeggen, wanneer er wijzigingen in de code zijn, moet je zo snel mogelijk je infrastructuur in overeenstemming brengen met deze wijzigingen. Er mag geen situatie zijn waarin iemand na twee of drie maanden terugkomt om Elasticsearch te bekijken, een Terraform plan doet, en daar een hoop wijzigingen ziet die hij niet verwachtte. Dit kost veel tijd om alles weer op orde te krijgen.
- Tests en automatisering. Hoe meer je code is gedekt door tests en functies, des te meer vertrouwen je hebt dat je alles goed doet. Automatische levering zal je vertrouwen enorm vergroten.
- De code voor test- en productieomgevingen moet praktisch identiek zijn. Praktisch, omdat productie toch iets anders is en er altijd nuances zullen zijn die buiten de testomgeving vallen. Toch kan dit min of meer worden gegarandeerd.
- En als je veel Terraform-code hebt en het veel tijd kost om deze code up-to-date te houden, is het nooit te laat om refactoring te doen en het in goede staat te brengen.
- Immutable infrastructuur. Levering van AMI volgens schema.
- Structuur voor route53, wanneer je heel veel records hebt en je wilt dat ze in een consistente volgorde staan.
- Strijd tegen API rate limits. Dat is wanneer Amazon zegt: "Ik kan geen verzoeken meer aannemen, alsjeblieft wachten". En de helft van het bedrijf wacht tot ze hun infrastructuur kan starten.
- Spot instances. Amazon is geen goedkope aangelegenheid en spots bieden aanzienlijke besparingen. Je kunt daar een hele presentatie over geven.
- Beveiliging en IAM-rollen.
- Zoeken naar verloren middelen, wanneer je onbekende instances in Amazon hebt die geld kosten. Zelfs als een instance 100-150 dollar per maand kost, is dat meer dan 1.000 dollar per jaar. Het vinden van dergelijke bronnen is lucratief.
- En gereserveerde instances.
Dat was alles van mijn kant. Terraform is geweldig, gebruik het. Dank je!
Vragen
Dank je voor de presentatie! Je state-file ligt in S3, hoe los je het probleem op dat meerdere mensen deze state-file kunnen nemen en proberen uit te rollen?
Ten eerste, we haasten ons niet. Ten tweede zijn er vlaggen waarin we aangeven dat we aan een bepaald deel van de code werken. Dat wil zeggen, hoewel de infrastructuur heel groot is, betekent het niet dat er constant iemand iets toepast. En toen we in de actieve fase waren, was dat een probleem, omdat onze state-bestanden in Git werden opgeslagen. Dat was belangrijk, anders zou iemand de state-file aanmaken en moesten we ze handmatig verzamelen zodat alles verder kon gaan. Dat probleem is er nu niet meer. Over het algemeen heeft Terraform deze taak opgelost. En als er constant iets verandert, kun je locks gebruiken die voorkomen wat je hebt gezegd.
Gebruik je de open versie of enterprise?
Geen enterprise, dat wil zeggen, alles wat je kunt downloaden is gratis.
Mijn naam is Stanislav. Ik wilde een kleine aanvulling doen. Jullie hebben het gehad over een functie van Amazon waarmee je een instance onverwoestbaar kunt maken. Dit is ook mogelijk in Terraform zelf; in de Life Second-block kun je een wijzigingsverbod of een vernietigingsverbod instellen.
Ik was beperkt in tijd. Goede opmerking.
Ik wilde nog twee dingen vragen. Ten eerste, jullie hebben het gehad over testen. Hebben jullie bepaalde tools voor testen gebruikt? Ik heb gehoord over de Test Kitchen-plugin. Misschien is er nog iets anders. En ik zou ook graag willen vragen over Local Values. Wat is hun verschil met Input Variables? En waarom kan ik niet iets parametriseren alleen via Local Values? Ik probeerde deze kwestie te begrijpen, maar ik kwam er zelf niet uit.
We kunnen daar uitgebreider over praten na deze sessie. De testtools die we hebben, zijn volledig zelfgemaakt. Er is niets bijzonders om te testen. Maar er zijn wel opties waarbij automatische tests infrastructuur opzetten, controleren of alles in orde is, en vervolgens alles vernietigen met een rapport waarin staat dat jullie infrastructuur nog steeds in goede staat is. We hebben dit niet, omdat teststacks elke dag worden opgestart. Dat is voldoende. En als er iets begint te breken, dan breekt het vanzelf, zonder dat we dat ergens anders hoeven te controleren.
Wat betreft Local Values, laten we dat gesprek voortzetten na deze sessie.
Hallo! Bedankt voor de presentatie! Erg informatief. Je zei dat jullie veel vergelijkbare code hebben voor het beschrijven van infrastructuur. Hebben jullie overwogen om deze code te genereren?
Geweldige vraag, bedankt! Het gaat erom dat wanneer we infrastructuur als code gebruiken, we aannemen dat we de code bekijken en begrijpen welke infrastructuur er achter die code schuilgaat. Als de code wordt gegenereerd, moeten we ons voorstellen welke code zal worden gegenereerd om te begrijpen welke infrastructuur daar zal zijn. Of we genereren de code, committen deze en het komt in wezen op hetzelfde neer. Daarom hebben we de weg gevolgd die we hebben geschreven. Bovendien kwamen de generators iets later, toen we al begonnen waren. En het was te laat om te veranderen.
Heb je iets gehoord over jsonnet?
Nee.
Kijk, dit is een geweldig ding. Ik zie een specifieke casus waar we dit kunnen toepassen en gegevensstructuren kunnen genereren.
Generators zijn goed, net als in de grap over scheermachines. De eerste keer zijn de gezichten verschillend, maar daarna heeft iedereen hetzelfde gezicht. Generators zijn erg populair. Maar helaas zijn onze gezichten iets anders. Dat is een probleem.
Kijk gewoon. Dank je!
Mijn naam is Maxim, ik kom van Sberbank. Je vertelde iets over het proberen van Terraform als een alternatief voor programmeertalen. Is het niet eenvoudiger om Ansible te gebruiken?
Het zijn heel verschillende dingen. Je kunt ook met Ansible resources maken, en met Puppet kun je ook resources in Amazon maken. Maar Terraform is echt op dat doel gericht.
Hebben jullie alleen Amazon?
Het gaat niet alleen om dat we alleen Amazon hebben. We hebben bijna alleen Amazon. Maar de belangrijkste functie is dat Terraform onthoudt. In Ansible, als je zegt: 'Maak 5 instances aan', dan maakt het ze aan, en daarna zeg je: 'Ik heb nu 3 nodig'. Terraform zal zeggen: 'Oké, ik verwijder er 2', terwijl Ansible zal zeggen: 'Oké, hier heb je 3'. Totaal 8.
Hallo! Bedankt voor je presentatie! Het was erg interessant om over Terraform te horen. Ik wil meteen een kleine opmerking maken dat Terraform eigenlijk geen stabiele release heeft, dus ben voorzichtig met Terraform.
De lepel is goed voor de lunch. Als je een oplossing nodig hebt, stel je soms het instabiele uit, enzovoort, maar het werkt en heeft ons geholpen.
Ik heb een vraag. Jullie gebruiken Remote backend, jullie gebruiken S3. Waarom gebruiken jullie de officiële backend niet?
Officiële?
Terraform Cloud.
Wanneer is het verschenen?
Ongeveer 4 maanden geleden.
Als het 4 jaar geleden was verschenen, dan had ik waarschijnlijk je vraag kunnen beantwoorden.
Daar is al een ingebouwde functie voor, zowel locks als de mogelijkheid om state-files op te slaan. Probeer het. Maar ik heb het ook niet getest.
We rijden in een grote trein die met hoge snelheid rijdt. Je kunt niet zomaar een paar wagons eruit gooien.
Je sprak over snowflakes, maar waarom heb je geen branch gebruikt? Waarom werkte dat niet?
Wij hebben de aanpak dat alle infrastructuur in één repository zit. Terraform, Puppet, alle scripts die daar enigszins mee te maken hebben, zitten allemaal in één repository. Zo kunnen we garanderen dat incrementele wijzigingen één voor één zijn getest. Als het een hoop branches was, zou zo'n project praktisch onmogelijk te onderhouden zijn. Na 6 maanden zijn ze zo uit elkaar gegroeid dat het gewoon een straf is. Dat is wat ik wilde vermijden tot de refactoring.
Dus het werkt niet?
Dit werkt totaal niet.
In de branch heb ik de dia's uit de map gehaald. Dat wil zeggen, als we voor elke teststack een map maken, bijvoorbeeld team A heeft zijn eigen map, team B heeft zijn eigen map, dan werkt het ook niet. We hebben een gestandaardiseerde code voor de testomgeving gemaakt, die flexibel genoeg was om voor iedereen te werken. Dat wil zeggen, we hebben één code onderhouden.
Hallo! Mijn naam is Jura! Bedankt voor de presentatie! Een vraag over modules. U zegt dat u modules gebruikt. Hoe gaat u om met veranderingen in één module die niet compatibel zijn met die van iemand anders? Versiebeheerden jullie de modules of probeert u een wonderoplossing te vinden om aan beide eisen te voldoen?
Dit is het probleem van de grote sneeuwbal. Dit is wat we ervaren wanneer een ogenschijnlijk onschuldig verandering een deel van de infrastructuur kan breken. En dit zal pas na een lange tijd zichtbaar zijn.
Dat wil zeggen, er is momenteel geen oplossing?
Maak universele modules. Vermijd sneeuwvlokken. Dan komt alles goed. Het tweede deel van de presentatie gaat over hoe dit te voorkomen.
Hallo! Bedankt voor de presentatie! Ik wil iets verduidelijken. Er is een grote hoop achter de schermen, waarvoor ik ben gekomen. Hoe zijn Puppet en roltoewijzing geïntegreerd?
User-data.
Dat wil zeggen, je spuugt gewoon het bestand uit en voert het op een of andere manier uit?
User-data is een nota, dat wil zeggen dat wanneer we een kloon van het beeld maken, er een Daemon opstart die, terwijl hij probeert te begrijpen wie hij is, de nota leest dat hij een load balancer is.
Dat wil zeggen, dit is een apart proces dat wordt toegewezen?
Wij hebben het niet uitgevonden. Wij gebruiken het.
Hallo! Ik heb juist een vraag over User-data. U zei dat er problemen zijn, dat iemand per ongeluk iets verkeerd kan doorgeven. Is er een manier om user-data op dezelfde manier in Git op te slaan, zodat altijd duidelijk is waarnaar User-data verwijst?
We generate User-data from the template. That is, a certain number of variables come in there. And Terraform generates the final result. Therefore, you can't just look at the template and say what will happen, because all the problems are related to the fact that the developer thinks they are passing a string in this variable, but an array comes in instead. And suddenly, something breaks. If it's a new resource and the person is launching it, they see that something isn't working, and this can be resolved quickly. But if it's an autoscale group that has been updated, at some point, instances in the autoscale group start replacing each other. And bam, something isn't working. It's frustrating.
So, the only solution is to test?
Yes, you see the problem, you add test steps there. That is, you can also test with output. It may not be as convenient, but you can still put some markers – check that User-data is nailed down here.
My name is Timur. It's really cool that there are talks about how to properly organize Terraform.
I haven't even started.
I think that maybe there will be something at the next conference. I have a simple question. Why do you hard-code values in a separate module and not use tfvars? That is, what's better about the module with values compared to tfvars?
So, do I need to write here (slide: Production/environment/settings.tf): domain = variable, domain vpcnetwork, variable vpcnetwork and stvars – to extract the same?
We do exactly that. We refer to the module setting source, for example.
Essentially, it's that tfvars. Tfvars is very convenient in a testing environment. I have tfvars for large instances, for small ones. And I just throw one file into a folder. And I get what I wanted. When we build infrastructure, we want to be able to look at it and understand everything right away. Otherwise, you end up having to look here, and then look at tfvars.
So, to have everything in one place?
Yes, tfvars is when you have one code. And it is used in several different places with different nuances. Then you would throw in tfvars and get your nuances. And we – this is infrastructure as code in its purest form. Looked at it and understood.
Hallo! Bent u ooit in situaties gekomen waarin de cloudprovider zich bemoeit met wat u met Terraform hebt gedaan? Stel dat we metadata aanpassen. Daar zijn ssh-sleutels. En Google blijft zijn metadata en sleutels erin duwen. En Terraform blijft altijd zeggen dat er wijzigingen zijn. Na elke run, zelfs als er niets verandert, zegt hij altijd dat hij dit veld zal bijwerken.
Met sleutels, maar ja, een deel van de infrastructuur is aangetast door zoiets, dat wil zeggen, Terraform kan er niets aan veranderen. We kunnen het ook handmatig niet aanpassen. We leven voorlopig met dit probleem.
Dat wil zeggen, u bent zoiets tegengekomen, maar u hebt er niets op gevonden, hij blijft gewoon doorgaan?
Helaas, ja.
Hallo! Mijn naam is Stanislav Starkov. Mail. ru Group. Hoe lost u het probleem op met het genereren van de tag op ..., hoe geeft u deze door? Ik begrijp dat dit via User — data gaat, om de hostnaam op te geven, Puppet eraan te koppelen? En het tweede deel van de vraag. Hoe pakt u deze kwestie aan in SG, dus wanneer u SG genereert, honderden soortgelijke instances, hoe benoemt u ze correct?
De instances die voor ons heel belangrijk zijn, noemen we mooi. De niet-essentiële krijgen een toevoeging dat het een autoscale-groep is. En in principe kan dit worden verwijderd om een nieuwe te verkrijgen.
Wat betreft het probleem met de tag, dat is geen probleem, maar eerder een taak. En tags worden heel veel gebruikt omdat de infrastructuur groot en kostbaar is. We moeten bekijken waar het geld naartoe gaat, daarom helpen tags ons te begrijpen wat en waar het geld naartoe gaat. En, dienovereenkomstig, het zoeken naar waar veel geld wordt uitgegeven.
Waar ging de vraag nog over?
Wanneer SG honderd instances aanmaakt, moeten ze op de een of andere manier van elkaar te onderscheiden zijn?
Nee, dat hoeft niet. Op elke instance is er een agent die meldt dat hij een probleem heeft. Als de agent meldt, weet hij ook over deze instantie en, in ieder geval, bestaat het IP-adres. Dan kan je al aan de slag. Ten tweede, we gebruiken Consul voor Discovery, waar het niet Kubernetes is. En Consul toont ook het IP-adres van de instantie.
Dat wil zeggen, u baseert zich precies op IP en niet op de hostnaam?
Het is onmogelijk om naar de hostnaam te verwijzen, er zijn er te veel. Er zijn instance-identificaties – AE, enzovoort. Deze kunnen ergens worden gevonden, soms kan je het in de zoekmachine ingeven.
Hallo! Ik begrijp dat Terraform een goed systeem is, ontworpen voor de cloud.
Niet alleen.
Dit is precies de vraag die mij interesseert. Als jullie besluiten om massaal over te stappen naar Bare Metal met al jullie instances, zijn er dan geen problemen? Of moeten we toch andere producten gebruiken, zoals Ansible, dat hier eerder genoemd werd?
Ansible is iets anders. Ansible werkt pas nadat de instance is opgestart. Terraform werkt vóórdat de instance is opgestart. De overstap naar Bare Metal – dat is het niet.
Nu niet, maar er komt een bedrijf en zegt: ‘Laten we het doen.’
De overstap naar een andere cloud – ja, maar hier is het net iets anders. Je moet Terraform-code schrijven zodat de overstap naar een andere cloud met minder moeite kan gebeuren.
Oorspronkelijk was de taak zo gesteld dat onze hele infrastructuur agnostisch was, d.w.z. dat elke cloud geschikt moest zijn, maar op een gegeven moment gaf het bedrijf zich over en zei: ‘Oké, voor de komende N jaren gaan we nergens naartoe, laten we diensten van Amazon gebruiken.’
Terraform maakt het mogelijk om Front-End jobs te creëren, PagerDuty te configureren, data doc, enzovoorts. Het heeft veel mogelijkheden. Het kan praktisch de hele wereld beheren.
Bedankt voor de presentatie! Ik werk ook al 4 jaar met Terraform. Tijdens de geleidelijke overgang naar Terraform, naar infrastructuur, naar declaratieve beschrijvingen, kwamen we situaties tegen waarin iemand iets handmatig deed, terwijl jij een plan probeerde te maken. En je kreeg een foutmelding. Hoe pakken jullie zulke problemen aan? Hoe vinden jullie verloren middelen die aangegeven waren?
Hoofdzakelijk met de hand en met onze ogen. Als we iets vreemds in het rapport zien, analyseren we wat er aan de hand is, of we verwijderen het gewoon. Over het algemeen zijn pull requests de gewoonste zaak van de wereld.
Als er een fout is, maken jullie dan een rollback? Hebben jullie dat geprobeerd?
Nee, dat is de beslissing van de persoon op dat moment, als hij het probleem ziet.
Bron: habr.com
