Veel mensen kennen en gebruiken Terraform in hun dagelijkse werk, maar er zijn nog geen best practices hiervoor gevormd. Elk team moet zijn eigen benaderingen en methoden bedenken.
Uw infrastructuur begint vrijwel zeker eenvoudig: een paar bronnen + een paar ontwikkelaars. Na verloop van tijd groeit het in allerlei richtingen. Vindt u manieren om bronnen in Terraform-modules te groeperen, code in mappen te ordenen en wat kan er nog meer misgaan? (beroemde laatste woorden)
De tijd verstrijkt en je hebt het gevoel dat je infrastructuur je nieuwe huisdier is, maar waarom? Je maakt je zorgen over onverklaarbare veranderingen in de infrastructuur, je bent bang om de infrastructuur en code aan te raken - met als gevolg dat je nieuwe functionaliteit uitstelt of de kwaliteit vermindert...
Na drie jaar beheer van een verzameling Terraform-communitymodules voor AWS op Github en langdurig onderhoud van Terraform in productie, is Anton Babenko klaar om zijn ervaring te delen: hoe je TF-modules schrijft zodat dit in de toekomst geen pijn doet.
Aan het einde van de lezing zullen de deelnemers meer vertrouwd zijn met de principes van resource management in Terraform, best practices geassocieerd met modules in Terraform, en enkele principes van continue integratie geassocieerd met infrastructuurbeheer.
Disclaimer: Ik merk op dat dit rapport dateert van november 2018; er zijn al twee jaar verstreken. De versie van Terraform 2 die in het rapport wordt besproken, wordt niet langer ondersteund. De afgelopen 0.11 jaar zijn er 2 nieuwe releases uitgebracht, die veel vernieuwingen, verbeteringen en veranderingen bevatten. Let hierop en controleer de documentatie.
referenties:
- +
- - automatische opmaakcode en documentatie
- — generator van Terraform-modules (WIP)
- — Terraform-codegenerator uit visuele diagrammen (WIP)
- www.terraform-best-practices.com
- (Nieuwe berichten staan op mijn persoonlijke website www.antonbabenko.com/)
- @antonbabenko - Twitter en een heleboel verschillende Slacks
Mijn naam is Anton Babenko. Sommigen van jullie hebben waarschijnlijk de code gebruikt die ik heb geschreven. Ik zal hier nu met meer vertrouwen dan ooit over spreken, omdat ik toegang heb tot statistieken.
Ik werk aan Terraform en ben sinds 2015 actief deelnemer en bijdrager aan een groot aantal open source-projecten gerelateerd aan Terraform en Amazon.
Sindsdien heb ik genoeg code geschreven om het op een interessante manier over te brengen. En ik zal proberen je hier nu over te vertellen.
Ik zal het hebben over de fijne kneepjes en details van het werken met Terraform. Maar dat is niet echt het onderwerp van HighLoad. En nu zul je begrijpen waarom.
Na verloop van tijd begon ik Terraform-modules te schrijven. Gebruikers schreven vragen, ik herschreef ze. Vervolgens schreef ik verschillende hulpprogramma's om de code te formatteren met behulp van een pre-commit hook, enz.
Er waren veel interessante projecten. Ik hou van het genereren van code omdat ik het leuk vind dat de computer steeds meer werk voor mij en de programmeur doet, dus werk ik momenteel aan een Terraform-codegenerator op basis van visuele diagrammen. Misschien hebben sommigen van jullie ze gezien. Dit zijn prachtige doosjes met pijlen. En ik denk dat het geweldig is als je op de knop ‘Exporteren’ kunt klikken en alles als code kunt krijgen.
Ik kom uit Oekraine. Ik heb vele jaren in Noorwegen gewoond.
Ook is informatie voor dit rapport verzameld van mensen die mijn naam kennen en mij vinden op sociale netwerken. Ik heb bijna altijd dezelfde bijnaam.
Zoals ik al zei, ben ik de hoofdonderhouder van Terraform AWS-modules, een van de grootste repositories op GitHub waar we modules hosten voor de meest voorkomende taken: VPC, Autoscaling, RDS.
En wat je nu hebt gehoord is het meest fundamentele. Als je twijfelt of je begrijpt wat Terraform is, kun je je tijd beter ergens anders doorbrengen. Er zullen hier veel technische termen voorkomen. En ik aarzelde niet om het niveau van het rapport als het hoogste te bestempelen. Dit betekent dat ik zonder veel uitleg alle mogelijke termen kan gebruiken.
Terraform verscheen in 2014 als een hulpprogramma waarmee je infrastructuur als code kon schrijven, plannen en beheren. Het sleutelconcept hier is ‘infrastructuur als code’.
Alle documentatie is, zoals ik al zei, geschreven . Ik hoop dat de meeste mensen deze site kennen en de documentatie hebben gelezen. Als dat zo is, dan bent u op de juiste plek.
Zo ziet een normaal Terraform-configuratiebestand eruit, waarin we eerst enkele variabelen definiëren.
In dit geval definiëren we "aws_region".
Vervolgens beschrijven we welke hulpbronnen we willen creëren.
We voeren enkele opdrachten uit, in het bijzonder “terraform init” om afhankelijkheden en providers te laden.
En we voeren de opdracht “terraform apply” uit om te controleren of de opgegeven configuratie overeenkomt met de bronnen die we hebben gemaakt. Omdat we nog niet eerder iets hebben gemaakt, vraagt Terraform ons om deze bronnen te maken.
Wij bevestigen dit. Zo creëren we een emmer genaamd zeeslak.
Er zijn ook verschillende soortgelijke hulpprogramma's. Velen van jullie die Amazon gebruiken, kennen AWS CloudFormation of Google Cloud Deployment Manager of Azure Resource Manager. Elk van hen heeft zijn eigen implementatie voor het beheren van bronnen binnen elk van deze publieke cloudproviders. Terraform is vooral handig omdat u hiermee meer dan 100 providers kunt beheren. (Meer details )
De doelen die Terraform vanaf het begin nastreeft:
- Terraform biedt één overzicht van bronnen.
- Hiermee kunt u alle moderne platforms ondersteunen.
- En Terraform is vanaf het begin ontworpen als een hulpprogramma waarmee u de infrastructuur veilig en voorspelbaar kunt wijzigen.
In 2014 klonk het woord ‘voorspelbaar’ in deze context heel ongebruikelijk.
Terraform is een universeel hulpprogramma. Als je een API hebt, kun je absoluut alles controleren:
- U kunt gebruik maken van ruim 120 providers om alles te beheren wat u maar wilt.
- U kunt Terraform bijvoorbeeld gebruiken om de toegang tot GitHub-opslagplaatsen te beschrijven.
- Je kunt zelfs bugs aanmaken en sluiten in Jira.
- U kunt New Relic-statistieken beheren.
- Je kunt zelfs bestanden in Dropbox maken als je dat echt wilt.
Dit alles wordt bereikt met behulp van Terraform-providers, die een open API hebben die in Go kan worden beschreven.
Laten we zeggen dat we Terraform zijn gaan gebruiken, wat documentatie op de site hebben gelezen, een video hebben bekeken en main.tf zijn gaan schrijven, zoals ik op de vorige dia's heb laten zien.
En alles is geweldig, je hebt een bestand dat een VPC aanmaakt.
Als je een VPC wilt aanmaken, dan geef je ongeveer deze 12 regels op. Beschrijf in welke regio u wilt maken en welk cidr_block van IP-adressen u wilt gebruiken. Dat is alles.
Uiteraard zal het project geleidelijk groeien.
En je voegt daar een heleboel nieuwe dingen aan toe: bronnen, gegevensbronnen, je integreert met nieuwe providers, plotseling wil je Terraform gebruiken om gebruikers in je GitHub-account te beheren, enz. Misschien wil je andere gebruiken DNS-providers, kruis alles. Terraform maakt dit eenvoudig.
Laten we naar het volgende voorbeeld kijken.
Je voegt geleidelijk internet_gateway toe omdat je wilt dat bronnen van je VPC internettoegang hebben. Dit is een goed idee.
Het resultaat is deze main.tf:
Dit is het bovenste gedeelte van main.tf.
Dit is het onderste gedeelte van main.tf.
Vervolgens voegt u subnet toe. Tegen de tijd dat u NAT-gateways, routes, routeringstabellen en een heleboel andere subnetten wilt toevoegen, heeft u geen 38 lijnen, maar ongeveer 200-300 lijnen.
Dat wil zeggen, uw main.tf-bestand groeit geleidelijk. En heel vaak stoppen mensen alles in één bestand. 10-20 Kb verschijnt in main.tf. Stel je voor dat 10-20 Kb tekstinhoud is. En alles is met alles verbonden. Het wordt langzamerhand lastig om hiermee te werken. 10-20 Kb is een goede gebruikerscase, soms meer. En mensen denken niet altijd dat dit slecht is.
Net als bij regulier programmeren, dat wil zeggen niet bij infrastructuur als code, zijn we gewend een aantal verschillende klassen, pakketten, modules en groeperingen te gebruiken. Met Terraform kunt u vrijwel hetzelfde doen.
- De code groeit.
- Ook de afhankelijkheden tussen hulpbronnen worden groter.
En we hebben een grote, grote behoefte. We begrijpen dat we niet langer zo kunnen leven. Onze code wordt immens. 10-20 Kb is natuurlijk niet erg groot, maar we hebben het alleen over de netwerkstack, dat wil zeggen dat je alleen netwerkbronnen hebt toegevoegd. We hebben het niet over Application Load Balancer, deployment ES-cluster, Kubernetes, etc., waar gemakkelijk 100 Kb in kan worden geweven. Als u dit allemaal opschrijft, komt u er al snel achter dat Terraform Terraform-modules aanbiedt.
Terraform-modules zijn een op zichzelf staande Terraform-configuratie die als groep wordt beheerd. Dat is alles wat u moet weten over Terraform-modules. Ze zijn helemaal niet slim, ze laten je niet toe om complexe verbindingen te maken, afhankelijk van iets. Dit valt allemaal op de schouders van de ontwikkelaars. Dat wil zeggen, dit is slechts een soort Terraform-configuratie die u al hebt geschreven. En je kunt het gewoon als een groep noemen.
We proberen dus te begrijpen hoe we onze 10-20-30 Kb aan code gaan optimaliseren. Langzaamaan realiseren we ons dat we een aantal modules moeten gebruiken.
Het eerste type modules dat je tegenkomt zijn resourcemodules. Ze begrijpen niet waar uw infrastructuur over gaat, waar uw bedrijf over gaat, waar en wat de voorwaarden zijn. Dit zijn precies de modules die ik, samen met de open source community, beheer en die wij naar voren schuiven als de allereerste bouwstenen voor uw infrastructuur.
Een voorbeeld van een resourcemodule.
Wanneer we een resourcemodule aanroepen, specificeren we vanaf welk pad we de inhoud ervan moeten laden.
Wij geven aan welke versie wij willen downloaden.
We passeren daar een aantal argumenten. Dat is alles. Dat is alles wat we moeten weten als we deze module gebruiken.
Veel mensen denken dat alles stabiel zal zijn als ze de nieuwste versie gebruiken. Maar nee. Er moet een versie van de infrastructuur zijn; we moeten duidelijk antwoorden op welke versie dit of dat onderdeel is geïmplementeerd.
Hier is de code die zich in deze module bevindt. Beveiligingsgroepmodule. Hier gaat de scroll naar de 640e regel. Het creëren van een beveiligingsbron in Amazon in elke mogelijke configuratie is een zeer niet-triviale taak. Het is niet voldoende om eenvoudigweg een beveiligingsgroep aan te maken en deze te vertellen welke regels eraan moeten worden doorgegeven. Het zou heel eenvoudig zijn. Er zijn een miljoen verschillende beperkingen binnen Amazon. Als u bijvoorbeeld gebruikt VPC-eindpunt, prefixlijst, verschillende API's en dit alles met al het andere probeert te combineren, dan staat Terraform je dit niet toe. En de Amazon API staat dit ook niet toe. Daarom moeten we al deze vreselijke logica in een module verbergen en de gebruikerscode geven die er precies zo uitziet.
De gebruiker hoeft niet te weten hoe het van binnen wordt gemaakt.
Het tweede type modules, dat bestaat uit resourcemodules, lost al problemen op die meer van toepassing zijn op uw bedrijf. Vaak is dit een plek die een verlengstuk is voor Terraform en een aantal rigide waarden stelt voor tags, voor bedrijfsstandaarden. U kunt daar ook functionaliteit toevoegen die u momenteel niet van Terraform kunt gebruiken. Dit is nu. Nu versie 0.11, die op het punt staat tot het verleden te behoren. Maar toch zijn preprocessors, jsonnet, cookiecutter en een heleboel andere dingen het hulpmechanisme dat moet worden gebruikt voor volwaardig werk.
Hierna zal ik hiervan enkele voorbeelden laten zien.
De infrastructuurmodule wordt op precies dezelfde manier aangeroepen.
De bron waar u de inhoud kunt downloaden, wordt aangegeven.
Een aantal waarden worden doorgegeven en doorgegeven aan deze module.
Vervolgens worden binnen deze module een aantal resourcemodules aangeroepen om een VPC of Application Load Balancer te maken, of om een beveiligingsgroep te maken of voor een Elastic Container Service-cluster.
Er zijn twee soorten modules. Dit is belangrijk om te begrijpen, omdat de meeste informatie die ik in dit rapport heb gegroepeerd, niet in de documentatie staat.
En de documentatie in Terraform is op dit moment behoorlijk problematisch, omdat er alleen maar staat dat er deze functies zijn en dat je ze kunt gebruiken. Maar ze zegt niet hoe ze deze functies moet gebruiken, waarom het beter is om ze te gebruiken. Daarom schrijft een zeer groot aantal mensen iets waar ze niet mee kunnen leven.
Laten we nu eens kijken hoe we deze modules kunnen schrijven. Dan kijken we hoe we ze kunnen bellen en hoe we met de code kunnen werken.
Terraform-register -
Tip #0 is om geen bronmodules te schrijven. De meeste van deze modules zijn al voor u geschreven. Zoals ik al zei, ze zijn open source, ze bevatten geen enkele bedrijfslogica, ze hebben geen hardgecodeerde waarden voor IP-adressen, wachtwoorden, enz. De module is zeer flexibel. En waarschijnlijk is het al geschreven. Er zijn veel modules voor bronnen van Amazon. Ongeveer 650. En de meeste zijn van goede kwaliteit.
In dit voorbeeld kwam iemand naar je toe en zei: 'Ik wil een database kunnen beheren. Maak een module zodat ik een database kan maken." De persoon kent de implementatiedetails van Amazon of Terraform niet. Hij zegt simpelweg: "Ik wil MSSQL beheren." Dat wil zeggen, we bedoelen dat het onze module zal aanroepen, daar het motortype zal doorgeven en de tijdzone zal aangeven.
En een persoon moet niet weten dat we binnen deze module twee verschillende bronnen zullen creëren: één voor MSSQL, de tweede voor al het andere, alleen omdat je in Terraform 0.11 geen tijdzonewaarden als optioneel kunt opgeven.
En bij de uitgang van deze module kan een persoon eenvoudig een adres ontvangen. Hij zal niet weten uit welke database, uit welke bron we dit allemaal intern creëren. Dit is een zeer belangrijk element van verhulling. En dit geldt niet alleen voor de modules die openbaar zijn in open source, maar ook voor de modules die u binnen uw projecten en teams gaat schrijven.
Dit is het tweede argument, dat erg belangrijk is als je Terraform al een tijdje gebruikt. U beschikt over een repository waarin u al uw Terraform-modules voor uw bedrijf plaatst. En het is heel normaal dat dit project na verloop van tijd zal uitgroeien tot een grootte van één of twee megabytes. Dit is goed.
Maar het probleem is hoe Terraform deze modules noemt. Als u bijvoorbeeld een module aanroept om elke individuele gebruiker aan te maken, laadt Terraform eerst de volledige repository en navigeert vervolgens naar de map waar die specifieke module zich bevindt. Zo download je elke keer één megabyte. Als u 100 of 200 gebruikers beheert, downloadt u 100 of 200 megabytes en gaat u vervolgens naar die map. Je wilt dus natuurlijk niet elke keer dat je op "Terraform init" klikt een heleboel dingen downloaden.
Er zijn twee oplossingen voor dit probleem. De eerste is het gebruik van relatieve paden. Zo geef je in de code aan dat de map lokaal is (./). En voordat je iets start, maak je lokaal een Git-kloon van deze repository. Zo doe je het een keer.
Er zijn natuurlijk veel nadelen. U kunt bijvoorbeeld geen versiebeheer gebruiken. En dit is soms lastig om mee te leven.
Tweede oplossing. Als je veel submodules hebt en al een soort pijplijn hebt, dan is er het MBT-project, waarmee je veel verschillende pakketten uit een monorepository kunt verzamelen en deze naar S3 kunt uploaden. Dit is een heel goede manier. Het iam-user-1.0.0.zip-bestand weegt dus slechts 1 Kb, omdat de code om deze bron te maken erg klein is. En het zal veel sneller werken.
Laten we het hebben over wat niet in modules kan worden gebruikt.
Waarom is dit kwaad in modules? Het ergste is om van de gebruiker uit te gaan. Stel dat gebruiker een authenticatieoptie van een provider is die door verschillende mensen kan worden gebruikt. We zullen bijvoorbeeld allemaal de rol assimileren. Dit betekent dat Terraform deze rol op zich gaat nemen. En dan zal het met deze rol andere acties uitvoeren.
En het slechte is dat als Vasya graag op één manier verbinding maakt met Amazon, bijvoorbeeld met behulp van de standaard omgevingsvariabele, en Petya graag zijn gedeelde sleutel gebruikt, die hij op een geheime plek heeft, je niet beide kunt opgeven in Terraform. En zodat zij geen lijden ervaren, is het niet nodig om dit blok in de module aan te geven. Dit moet op een hoger niveau worden aangegeven. Dat wil zeggen, we hebben een resourcemodule, een infrastructuurmodule en een compositie erbovenop. En dit zou ergens hoger aangegeven moeten worden.
Het tweede kwaad is de proviand. Hier is het kwaad niet zo triviaal, want als je code schrijft en het werkt voor jou, dan denk je misschien: als het werkt, waarom zou je het dan veranderen?
Het kwaad is dat je niet altijd controle hebt over wanneer deze provisioner in de eerste plaats wordt gelanceerd. En ten tweede heb je geen controle over wat aws ec2 betekent, d.w.z. hebben we het nu over Linux of Windows. Je kunt dus niet iets schrijven dat hetzelfde werkt op verschillende besturingssystemen of voor verschillende gebruikersscenario's.
Het meest voorkomende voorbeeld, dat ook wordt aangegeven in de officiële documentatie, is dat als je aws_instance schrijft en een aantal argumenten opgeeft, er niets mis mee is als je daar de provisioner “local-exec” specificeert en je ansible- speelboek.
Sterker nog, daar is niets mis mee. Maar je zult letterlijk snel beseffen dat dit local-exec-ding bijvoorbeeld niet bestaat in launch_configuration.
En wanneer u launch_configuration gebruikt en u een autoscaling-groep wilt maken op basis van één exemplaar, dan is er in launch_configuration geen concept van "provisioner". Er is het concept van “gebruikersgegevens”.
Daarom is een meer universele oplossing het gebruik van gebruikersgegevens. En het zal worden gelanceerd op de instantie zelf, wanneer de instantie wordt ingeschakeld, of in dezelfde gebruikersgegevens, wanneer de autoscaling-groep deze launch_configuration gebruikt.
Als u de provisioner nog steeds wilt uitvoeren, omdat het een lijmcomponent is, moet u bij het maken van een resource op dat moment uw provisioner, uw opdracht, uitvoeren. Er zijn veel van dergelijke situaties.
En de meest correcte bron hiervoor heet null_resource. Null_resource is een dummy-resource die nooit daadwerkelijk is gemaakt. Het raakt niets, geen API, geen automatische schaling. Maar u kunt hiermee bepalen wanneer u de opdracht moet uitvoeren. In dit geval wordt de opdracht uitgevoerd tijdens het maken.
Link
Er zijn verschillende tekenen. Ik zal niet in detail op alle signalen ingaan. Er is een artikel hierover. Maar als je met Terraform hebt gewerkt of modules van anderen hebt gebruikt, dan heb je vaak gemerkt dat veel modules, zoals de meeste code in open source, door mensen voor hun eigen behoeften zijn geschreven. Een man schreef het en loste zijn probleem op. Ik heb het in GitHub geplakt, laat het leven. Het zal blijven bestaan, maar als er geen documentatie en voorbeelden zijn, zal niemand het gebruiken. En als er geen functionaliteit is waarmee u iets meer kunt oplossen dan de specifieke taak, dan zal niemand deze ook gebruiken. Er zijn zoveel manieren om gebruikers te verliezen.
Als je iets wilt schrijven zodat mensen het zullen gebruiken, dan raad ik aan deze borden te volgen.
Is Dit:
- Documentatie en voorbeelden.
- Volledige functionaliteit.
- Redelijke standaardwaarden.
- Schone code.
- Tests.
Tests zijn een andere situatie omdat ze behoorlijk moeilijk zijn om te schrijven. Ik geloof meer in documentatie en voorbeelden.
We hebben dus gekeken hoe we modules konden schrijven. Er zijn twee argumenten. De eerste, die het belangrijkste is, is om niet te schrijven als je kunt, omdat een aantal mensen deze taken al voor je hebben gedaan. En ten tweede, als u nog steeds besluit, probeer dan geen providers te gebruiken in modules en provisioners.
Dit is het grijze deel van de documentatie. Misschien denk je nu: “Er is iets onduidelijk. Niet overtuigd." Maar we zullen het over zes maanden zien.
Laten we het nu hebben over hoe we deze modules kunnen aanroepen.
We begrijpen dat onze code in de loop van de tijd groeit. We hebben niet langer één bestand, we hebben al 20 bestanden. Ze staan allemaal in één map. Of misschien in vijf mappen. Misschien beginnen we ze op de een of andere manier op te splitsen per regio, volgens bepaalde componenten. Dan begrijpen we dat we nu enkele beginselen van synchronisatie en orkestratie hebben. Dat wil zeggen dat we moeten begrijpen wat we moeten doen als we netwerkbronnen veranderen, wat we moeten doen met de rest van onze bronnen, hoe we deze afhankelijkheden kunnen veroorzaken, enz.
Er zijn twee uitersten. Het eerste uiterste is alles in één. We hebben één hoofdbestand. Voorlopig was dit de officiële best practice op de website van Terraform.
Maar nu wordt het geschreven als verouderd en verwijderd. Na verloop van tijd realiseerde de Terraform-gemeenschap zich dat dit verre van de beste praktijk was, omdat mensen het project op verschillende manieren begonnen te gebruiken. En er zijn problemen. Bijvoorbeeld wanneer we alle afhankelijkheden op één plek opsommen. Er zijn situaties waarin we op “Terraform-plan” klikken en totdat Terraform de status van alle bronnen bijwerkt, kan er veel tijd verstrijken.
Veel tijd is bijvoorbeeld 5 minuten. Voor sommigen is dit veel tijd. Ik heb gevallen gezien waarbij het 15 minuten duurde. De AWS API heeft 15 minuten besteed aan het uitzoeken wat er gebeurde met de status van elke bron. Dit is een heel groot gebied.
En natuurlijk zal er een gerelateerd probleem verschijnen als je iets op één plek wilt veranderen, dan wacht je 15 minuten, en je krijgt een canvas van enkele wijzigingen. Je spuugde, schreef “Ja”, en er ging iets mis. Dit is een heel reëel voorbeeld. Terraform probeert u niet tegen problemen te beschermen. Dat wil zeggen, schrijf wat je wilt. Er zullen problemen zijn - jouw problemen. Hoewel Terraform 0.11 u op geen enkele manier probeert te helpen. Er zijn bepaalde interessante plaatsen in 0.12 waar je kunt zeggen: "Vasya, je wilt dit echt, kun je tot bezinning komen?"
De tweede manier is om dit gebied te verkleinen, dat wil zeggen dat oproepen vanaf de ene plaats minder verbonden kunnen zijn vanaf een andere plaats.
Het enige probleem is dat je meer code moet schrijven, dat wil zeggen dat je variabelen in een groot aantal bestanden moet beschrijven en deze moet bijwerken. Sommige mensen vinden het niet leuk. Dit is normaal voor mij. En sommige mensen denken: “Waarom schrijf ik dit op verschillende plekken, ik zet het allemaal op één plek.” Dit is mogelijk, maar dit is het tweede uiterste.
Wie heeft dit allemaal op één plek? Eén, twee, drie mensen, dat wil zeggen: iemand gebruikt het.
En wie noemt één bepaald onderdeel, één blok of één infrastructuurmodule? Vijf tot zeven personen. Dit is cool.
Het meest voorkomende antwoord ligt ergens in het midden. Als het project groot is, dan heb je vaak een situatie waarin geen enkele oplossing geschikt is en niet alles lukt, waardoor je een mengsel krijgt. Daar is niets mis mee, zolang je maar begrijpt dat beide voordelen hebben.
Als er iets veranderde in de stack-VPC en je wilde deze wijzigingen toepassen op EC2, d.w.z. je wilde de autoscaling-groep bijwerken omdat je een nieuw subnet had, dan noem ik dit soort afhankelijkheidsorkestratie. Er zijn enkele oplossingen: wie gebruikt wat?
Ik kan voorstellen welke oplossingen er zijn. Je kunt Terraform gebruiken om de magie te doen, of je kunt makefiles gebruiken om Terraform te gebruiken. En kijk of daar iets is veranderd, je kunt het hier lanceren.
Wat vind jij van deze beslissing? Gelooft iemand dat dit een coole oplossing is? Ik zie een glimlach, blijkbaar zijn er twijfels geslopen.
Probeer dit natuurlijk niet thuis. Terraform is nooit ontworpen om vanuit Terraform te worden uitgevoerd.
Bij één melding zeiden ze tegen mij: “Nee, dit gaat niet werken.” Het punt is dat het niet zou moeten werken. Hoewel het er zo indrukwekkend uitziet als je Terraform vanuit Terraform kunt starten, en vervolgens Terraform, moet je dat niet doen. Terraform zou altijd heel gemakkelijk moeten starten.
Als je oproeporkestratie nodig hebt als er op één plek iets is veranderd, dan is er Terragrunt.
Terragrunt is een hulpprogramma, een add-on voor Terraform, waarmee u oproepen naar infrastructuurmodules kunt coördineren en orkestreren.
Een typisch Terraform-configuratiebestand ziet er als volgt uit.
U geeft aan welke specifieke module u wilt oproepen.
Welke afhankelijkheden heeft de module?
En welke argumenten accepteert deze module. Dat is alles wat er te weten valt over Terragrunt.
De documentatie is aanwezig en er staan 1 sterren op GitHub. Maar in de meeste gevallen is dit wat u moet weten. En dit is heel eenvoudig te implementeren in bedrijven die net met Terraform beginnen te werken.
Orkestratie is dus Terragrunt. Er zijn andere opties.
Laten we het nu hebben over hoe we met de code kunnen werken.
Als u nieuwe functies aan uw code moet toevoegen, is dit in de meeste gevallen eenvoudig. U schrijft een nieuwe bron, alles is eenvoudig.
Als u bijvoorbeeld een bron heeft die u van tevoren hebt gemaakt, over Terraform hebt geleerd nadat u een AWS-account hebt geopend en de bronnen wilt gebruiken die u al heeft, dan zou het passend zijn om uw module op deze manier uit te breiden, zodat het ondersteunt het gebruik van bestaande hulpbronnen.
En ondersteunde de creatie van nieuwe bronnen met behulp van de blokbron.
Bij uitvoer retourneren we altijd de uitvoer-ID, afhankelijk van wat er is gebruikt.
Het tweede zeer belangrijke probleem in Terraform 0.11 is het werken met lijsten.
De moeilijkheid is dat als we zo'n lijst met gebruikers hebben.
En wanneer we deze gebruikers aanmaken met behulp van blokbronnen, gaat alles goed. We doorlopen de hele lijst en maken voor elk een bestand. Alles is in orde. En dan zou bijvoorbeeld gebruiker3, die in het midden zit, hier verwijderd moeten worden, dan zullen alle bronnen die na hem zijn gemaakt opnieuw worden gemaakt omdat de index zal veranderen.
Werken met lijsten in een stateful omgeving. Wat is een stateful omgeving? Dit is de situatie waarin een nieuwe waarde wordt gecreëerd wanneer deze hulpbron wordt gecreëerd. Bijvoorbeeld AWS Access Key of AWS Secret Key, d.w.z. wanneer we een gebruiker aanmaken, ontvangen we een nieuwe toegangs- of geheime sleutel. En elke keer dat we een gebruiker verwijderen, krijgt deze gebruiker een nieuwe sleutel. Maar dit is geen feng shui, omdat de gebruiker geen vrienden met ons wil zijn als we elke keer dat iemand het team verlaat een nieuwe gebruiker voor hem aanmaken.
Dit is de oplossing. Dit is code geschreven in Jsonnet. Jsonnet is een sjabloontaal van Google.
Met deze opdracht kunt u deze sjabloon accepteren en als uitvoer een json-bestand retourneren dat is gemaakt volgens uw sjabloon.
Het sjabloon ziet er als volgt uit.
Met Terraform kunt u op dezelfde manier met zowel HCL als Json werken, dus als u de mogelijkheid heeft om Json te genereren, kunt u deze in Terraform plaatsen. Het bestand met de extensie .tf.json wordt succesvol gedownload.
En dan werken we er zoals gewoonlijk mee: terraform init, terramorm apply. En we creëren twee gebruikers.
Nu zijn we niet bang als iemand het team verlaat. We bewerken gewoon het json-bestand. Vasya Pupkin vertrok, Petya Pyatochkin bleef. Petya Pyatochkin krijgt geen nieuwe sleutel.
Het integreren van Terraform met andere tools is niet echt de taak van Terraform. Terraform is gemaakt als een platform voor het creëren van bronnen en dat is alles. En alles wat later ter sprake komt, is niet de zorg van Terraform. En het is niet nodig om het daarin te weven. Er is Ansible, dat alles doet wat je nodig hebt.
Maar er doen zich situaties voor wanneer we Terraform willen uitbreiden en een commando willen aanroepen nadat iets is voltooid.
Eerste manier. We creëren een uitvoer waarin we deze opdracht schrijven.
En dan roepen we deze opdracht aan vanuit de shell-terraform-uitvoer en specificeren we de gewenste waarde. De opdracht wordt dus uitgevoerd met alle gesubstitueerde waarden. Het is zeer comfortabel.
Tweede manier. Dit is het gebruik van null_resource, afhankelijk van veranderingen in onze infrastructuur. We kunnen dezelfde local-exe aanroepen zodra de ID van een bepaalde bron verandert.
Op papier is dit uiteraard allemaal soepel, omdat Amazon, net als alle andere publieke aanbieders, een aantal eigen randgevallen heeft.
Het meest voorkomende randgeval is dat wanneer u een AWS-account opent, het uitmaakt welke regio's u gebruikt; is deze functie daar ingeschakeld; misschien heb je het na december 2013 geopend; misschien gebruik je standaard in VPC enz. Er zijn veel beperkingen. En Amazon verspreidde ze door de documentatie.
Er zijn een paar dingen die ik aanraad om te vermijden.
Vermijd om te beginnen alle niet-geheime argumenten binnen het Terraform-plan of Terraform CLI. Dit alles kan in een tfvars-bestand of in een omgevingsvariabele worden geplaatst.
Maar je hoeft dit hele magische commando niet uit je hoofd te leren. Terraformplan – var en daar gaan we. De eerste variabele is var, de tweede variabele is var, de derde, vierde. Het belangrijkste principe van infrastructuur als code dat ik het vaakst gebruik, is dat ik, alleen al door naar de code te kijken, een duidelijk begrip moet hebben van wat daar wordt ingezet, in welke staat en met welke waarden. En dus hoef ik de documentatie niet te lezen of Vasya te vragen welke parameters hij heeft gebruikt om ons cluster te maken. Ik hoef alleen maar een bestand te openen met de tfvars-extensie, die vaak overeenkomt met de omgeving, en alles daar te bekijken.
Gebruik ook geen doelargumenten om het bereik te verkleinen. Hiervoor is het veel eenvoudiger om kleine infrastructuurmodules te gebruiken.
Ook is het niet nodig om de parallelliteit te beperken en te vergroten. Als ik 150 bronnen heb en ik wil het Amazon-parallellisme verhogen van de standaard 10 naar 100, dan zal er hoogstwaarschijnlijk iets misgaan. Of misschien gaat het nu goed, maar als Amazon zegt dat je te veel belt, kom je in de problemen.
Terraform zal proberen de meeste van deze problemen opnieuw op te starten, maar u zult vrijwel niets bereiken. Parallellisme=1 is een belangrijk ding om te gebruiken als je een bug tegenkomt in de AWS API of in de Terraform-provider. En dan moet je specificeren: parallellisme=1 en wachten tot Terraform één oproep beëindigt, dan de tweede en dan de derde. Hij zal ze één voor één lanceren.
Mensen vragen mij vaak: "Waarom denk ik dat Terraform-werkruimten slecht zijn?" Ik geloof dat het principe van infrastructuur als code is om te zien welke infrastructuur is gecreëerd en met welke waarden.
Werkruimten zijn niet door gebruikers gemaakt. Dit betekent niet dat gebruikers in GitHub-problemen hebben geschreven dat we niet zonder Terraform-werkruimten kunnen leven. Nee niet zo. Terraform Enterprise is een commerciële oplossing. Terraform van HashiCorp besloot dat we werkruimtes nodig hadden, dus hebben we het opgeborgen. Ik vind het veel gemakkelijker om het in een aparte map te plaatsen. Dan zullen er iets meer bestanden zijn, maar het zal duidelijker zijn.
Hoe te werken met de code? Eigenlijk is het werken met lijsten de enige pijn. En neem Terraform gemakkelijker. Dit is niet het ding dat alles geweldig voor je zal doen. Het is niet nodig om alles wat in de documentatie staat daar te plaatsen.
Het onderwerp van het rapport was geschreven ‘voor de toekomst’. Ik zal hier heel kort over praten. Voor de toekomst betekent dit dat binnenkort 0.12 uitkomt.
0.12 is een heleboel nieuwe dingen. Als je uit het reguliere programmeren komt, mis je allerlei dynamische blokken, loops, correcte en voorwaardelijke vergelijkingsbewerkingen, waarbij de linker- en rechterkant niet tegelijkertijd worden berekend, maar afhankelijk van de situatie. Je mist het erg, dus 0.12 lost het voor je op.
Maar! Als u steeds eenvoudiger schrijft, met behulp van kant-en-klare modules en oplossingen van derden, hoeft u niet te wachten en te hopen dat 0.12 komt en alles voor u oplost.
Bedankt voor het rapport! Je sprak over infrastructuur als code en zei letterlijk één woord over tests. Zijn tests in modules nodig? Wiens verantwoordelijkheid is dit? Moet ik het zelf schrijven of is dat de verantwoordelijkheid van de modules?
Het komende jaar zal gevuld zijn met berichten dat we besloten hebben alles te testen. Wat je moet testen is de grootste vraag. Er zijn veel afhankelijkheden, veel beperkingen van verschillende providers. Als jij en ik aan het praten zijn en je zegt: “Ik heb tests nodig”, dan vraag ik: “Wat ga je testen?” U zegt dat u in uw regio gaat testen. Dan zeg ik dat dit in mijn regio niet werkt. Dat wil zeggen: we zullen het hier niet eens over eens kunnen worden. Om nog maar te zwijgen van het feit dat er veel technische problemen zijn. Dat wil zeggen, hoe u deze tests zo schrijft dat ze adequaat zijn.
Ik doe actief onderzoek naar dit onderwerp, namelijk hoe je automatisch tests kunt genereren op basis van de infrastructuur die je hebt geschreven. Dat wil zeggen, als je deze code hebt geschreven, dan moet ik deze uitvoeren, op basis hiervan kan ik tests maken.
is een van de meest genoemde bibliotheken waarmee u integratietests voor Terraform kunt schrijven. Dit is een van de hulpprogramma's. Ik geef de voorkeur aan het DSL-type, bijvoorbeeld rspec.
Anton, bedankt voor het verslag! Mijn naam is Valery. Laat mij een kleine filosofische vraag stellen. Er is voorwaardelijk sprake van bevoorrading en inzet. Provisioning creëert mijn infrastructuur, tijdens de implementatie vullen we deze met iets nuttigs, bijvoorbeeld servers, applicaties, enz. En het zit in mijn hoofd dat Terraform meer voor provisioning is, en Ansible meer voor implementatie, omdat Ansible ook voor fysiek is. Hiermee kunt u nginx, Postgres installeren. Maar tegelijkertijd lijkt Ansible de levering van bijvoorbeeld Amazon- of Google-bronnen toe te staan. Maar met Terraform kunt u ook bepaalde software implementeren met behulp van de modules. Is er vanuit jouw oogpunt een soort grens tussen Terraform en Ansible, waar en wat is beter te gebruiken? Of denk je bijvoorbeeld dat Ansible al rotzooi is, je moet Terraform voor alles proberen te gebruiken?
Goede vraag, Valery. Ik ben van mening dat Terraform qua doel sinds 2014 niet is veranderd. Het werd gemaakt voor de infrastructuur en stierf voor de infrastructuur. We hadden en zullen nog steeds behoefte hebben aan configuratiebeheer Ansible. De uitdaging is dat er gebruikersgegevens in launch_configuration zitten. En daar trek je Ansible, enz. Dit is het standaardonderscheid dat ik het leukst vind.
Als we het hebben over een prachtige infrastructuur, dan zijn er hulpprogramma's zoals Packer die deze afbeelding verzamelen. En vervolgens gebruikt Terraform de gegevensbron om deze afbeelding te vinden en de launch_configuration ervan bij te werken. Dat wil zeggen, op deze manier is de pijplijn dat we eerst Tracker en vervolgens Terraform trekken. En als er opbouw plaatsvindt, vindt er een nieuwe verandering plaats.
Hallo! Bedankt voor het rapport! Mijn naam is Misha, RBS-bedrijf. U kunt Ansible via provisioner aanroepen wanneer u een resource maakt. Ansible heeft ook een onderwerp genaamd dynamische inventaris. En je kunt eerst Terraform aanroepen en vervolgens Ansible aanroepen, die middelen van de staat zal afnemen en deze zal uitvoeren. Wat is beter?
Mensen gebruiken beide met evenveel succes. Het lijkt mij dat dynamische inventarisatie in Ansible handig is, als we het niet hebben over autoscaling-groepen. Omdat we in de autoscaling-groep al onze eigen toolkit hebben, die launch_configuration heet. In launch_configuration leggen we alles vast wat gelanceerd moet worden wanneer we een nieuwe resource aanmaken. Daarom is het gebruik van dynamische inventarisatie en het lezen van het Terraform ts-bestand bij Amazon naar mijn mening overdreven. En als u andere tools gebruikt waarbij er geen concept van “automatische schalingsgroep” bestaat, u gebruikt bijvoorbeeld DigitalOcean of een andere provider waar er geen automatische schalingsgroep is, dan zult u daar handmatig de API moeten ophalen, IP-adressen moeten vinden, een dynamisch inventarisbestand, en Ansible zal er al doorheen dwalen. Dat wil zeggen, voor Amazon is er launch_configuration, en voor al het andere is er dynamische inventaris.
Bron: www.habr.com