Beskrivning av infrastruktur i Terraform för framtiden. Anton Babenko (2018)

Många känner till och använder Terraform i sitt dagliga arbete, men bästa praxis för det har ännu inte tagits fram. Varje team måste uppfinna sina egna tillvägagångssätt och metoder.

Din infrastruktur börjar nästan säkert enkelt: några resurser + några utvecklare. Med tiden växer det åt alla möjliga håll. Hittar du sätt att gruppera resurser i Terraform-moduler, organisera kod i mappar och vad mer som kan gå fel? (kända sista ord)

Tiden går och du känner att din infrastruktur är ditt nya husdjur, men varför? Du är orolig för oförklarliga förändringar i infrastrukturen, du är rädd för att röra infrastrukturen och koden - som ett resultat försenar du ny funktionalitet eller minskar kvaliteten...

Efter tre år av att hantera en samling Terraform-gemenskapsmoduler för AWS på Github och långsiktigt underhåll av Terraform i produktion, är Anton Babenko redo att dela med sig av sin erfarenhet: hur man skriver TF-moduler så att det inte skadar i framtiden.

I slutet av föredraget kommer deltagarna att vara mer bekanta med principer för resurshantering i Terraform, bästa praxis förknippade med moduler i Terraform och några kontinuerliga integrationsprinciper förknippade med infrastrukturhantering.

Varning: Jag noterar att denna rapport är daterad november 2018—2 år har redan gått. Den version av Terraform 0.11 som diskuteras i rapporten stöds inte längre. Under de senaste 2 åren har 2 nya releaser släppts, som innehåller en hel del innovationer, förbättringar och förändringar. Var uppmärksam på detta och kontrollera dokumentationen.

Länkar:

• terraform-gemenskap-moduler + terraform-aws-moduler
• antonbabenko/pre-commit-terraform — autoformatering av kod och dokumentation
• antonbabenko/terrapin — Generator av Terraform-moduler (WIP)
• antonbabenko/modules.tf-lambda — Terraform kodgenerator från visuella diagram (WIP)
• www.terraform-best-practices.com
• medium.com/@anton.babenko (Nya inlägg finns på min personliga hemsida www.antonbabenko.com/)
• @antonbabenko - Twitter, och ett gäng olika Slacks

Jag heter Anton Babenko. Några av er använde förmodligen koden jag skrev. Jag kommer nu att tala om detta med större självförtroende än någonsin, eftersom jag har tillgång till statistik.

Jag arbetar på Terraform och har varit en aktiv deltagare och bidragsgivare till ett stort antal open source-projekt relaterade till Terraform och Amazon sedan 2015.

Sedan dess har jag skrivit tillräckligt med kod för att sätta det på ett intressant sätt. Och jag ska försöka berätta om detta nu.

Jag kommer att prata om krångligheterna och detaljerna i att arbeta med Terraform. Men det är egentligen inte ämnet för HighLoad. Och nu kommer du att förstå varför.

Med tiden började jag skriva Terraform-moduler. Användare skrev frågor, jag skrev om dem. Sedan skrev jag olika verktyg för att formatera koden med en pre-commit hook, etc.

Det var många intressanta projekt. Jag gillar kodgenerering eftersom jag gillar att datorn gör mer och mer arbete för mig och programmeraren, så jag arbetar just nu med en Terraform-kodgenerator från visuella diagram. Kanske har några av er sett dem. Det här är vackra lådor med pilar. Och jag tycker att det är bra om du kan klicka på knappen "Exportera" och få allt som kod.

Jag är från Ukraina. Jag har bott i Norge i många år.

Information för denna rapport har också samlats in från personer som känner till mitt namn och hittar mig på sociala nätverk. Jag har nästan alltid samma smeknamn.

https://github.com/terraform-aws-modules
https://registry.terraform.io/namespaces/terraform-aws-modules

Som jag nämnde är jag den huvudsakliga underhållaren av Terraform AWS-moduler, som är ett av de största arkiven på GitHub där vi är värd för moduler för de vanligaste uppgifterna: VPC, Autoskalning, RDS.

Och det du hörde nu är det mest grundläggande. Om du tvivlar på att du förstår vad Terraform är, då är det bättre att spendera din tid någon annanstans. Det kommer att finnas många facktermer här. Och jag tvekade inte att förklara rapportens nivå som den högsta. Det betyder att jag kan prata med alla möjliga termer utan mycket förklaring.

Terraform dök upp 2014 som ett verktyg som gjorde det möjligt för dig att skriva, planera och hantera infrastruktur som kod. Nyckelbegreppet här är "infrastruktur som kod."

All dokumentation är som sagt inskriven terraform.io. Jag hoppas att de flesta känner till den här sidan och har läst dokumentationen. I så fall är du på rätt plats.

Så här ser en vanlig Terraform-konfigurationsfil ut, där vi först definierar några variabler.

I det här fallet definierar vi "aws_region".

Sedan beskriver vi vilka resurser vi vill skapa.

Vi kör några kommandon, särskilt "terraform init" för att ladda beroenden och leverantörer.

Och vi kör kommandot "terraform applicera" för att kontrollera om den angivna konfigurationen matchar resurserna som vi skapade. Eftersom vi inte har skapat något tidigare uppmanar Terraform oss att skapa dessa resurser.

Vi bekräftar detta. På så sätt skapar vi en hink som kallas sjönagel.

Det finns också flera liknande verktyg. Många av er som använder Amazon känner till AWS CloudFormation eller Google Cloud Deployment Manager eller Azure Resource Manager. Var och en av dem har sin egen implementering av något slag för att hantera resurser inom var och en av dessa offentliga molnleverantörer. Terraform är särskilt användbart eftersom det låter dig hantera över 100 leverantörer. (Fler detaljer här)

Målen som Terraform har strävat efter från första början:

• Terraform ger en enda bild av resurser.
• Låter dig stödja alla moderna plattformar.
• Och Terraform designades från första början som ett verktyg som låter dig ändra infrastruktur på ett säkert och förutsägbart sätt.

2014 lät ordet ”förutsägbar” väldigt ovanligt i sammanhanget.

Terraform är ett universellt verktyg. Om du har ett API kan du kontrollera absolut allt:

• Du kan använda mer än 120 leverantörer för att hantera allt du vill.
• Till exempel kan du använda Terraform för att beskriva åtkomst till GitHub-förråd.
• Du kan till och med skapa och stänga buggar i Jira.
• Du kan hantera New Relic-mätvärden.
• Du kan till och med skapa filer i dropbox om du verkligen vill.

Allt detta uppnås med hjälp av Terraform-leverantörer, som har ett öppet API som kan beskrivas i Go.

Låt oss säga att vi började använda Terraform, läste lite dokumentation på sajten, tittade på lite video och började skriva main.tf, som jag visade på de tidigare bilderna.

Och allt är bra, du har en fil som skapar en VPC.

Om du vill skapa en VPC anger du ungefär dessa 12 rader. Beskriv i vilken region du vill skapa, vilket cidr_block av IP-adresser som ska användas. Det är allt.

Naturligtvis kommer projektet att växa successivt.

Och du kommer att lägga till massor av nya saker där: resurser, datakällor, du kommer att integrera med nya leverantörer, plötsligt vill du använda Terraform för att hantera användare i ditt GitHub-konto, etc. Du kanske vill använda olika DNS-leverantörer, kryssa allt. Terraform gör detta enkelt.

Låt oss titta på följande exempel.

Du lägger gradvis till internet_gateway eftersom du vill att resurser från din VPC ska ha tillgång till internet. Det här är en bra idé.

Resultatet är detta main.tf:

Detta är den övre delen av main.tf.

Detta är den nedre delen av main.tf.

Sedan lägger du till subnät. När du vill lägga till NAT-gateways, rutter, routingtabeller och ett gäng andra subnät kommer du inte att ha 38 linjer, utan ungefär 200-300 linjer.

Det vill säga, din main.tf-fil växer gradvis. Och ganska ofta lägger folk allt i en fil. 10-20 Kb visas i main.tf. Föreställ dig att 10-20 Kb är textinnehåll. Och allt är kopplat till allt. Det här blir så småningom svårt att jobba med. 10-20 Kb är ett bra användarfall, ibland mer. Och folk tycker inte alltid att det här är dåligt.

Som i vanlig programmering, alltså inte infrastruktur som kod, är vi vana vid att använda en massa olika klasser, paket, moduler, grupperingar. Terraform låter dig göra ungefär samma sak.

• Koden växer.
• Beroendet mellan resurserna växer också.

Och vi har ett stort, stort behov. Vi förstår att vi inte kan leva så här längre. Vår kod blir enorm. 10-20 Kb är naturligtvis inte särskilt stort, men vi pratar bara om nätverksstacken, dvs du har bara lagt till nätverksresurser. Vi pratar inte om Application Load Balancer, deployment ES cluster, Kubernetes, etc., där 100 Kb enkelt kan vävas in. Om du skriver ner allt detta kommer du mycket snart att lära dig att Terraform tillhandahåller Terraform-moduler.

Terraform-moduler är en fristående Terraform-konfiguration som hanteras som en grupp. Det är allt du behöver veta om Terraform-moduler. De är inte alls smarta, de tillåter dig inte att göra några komplexa kopplingar beroende på något. Allt detta faller på utvecklarnas axlar. Det vill säga, detta är bara någon slags Terraform-konfiguration som du redan har skrivit. Och du kan helt enkelt kalla det som en grupp.

Så vi försöker förstå hur vi ska optimera våra 10-20-30 Kb kod. Vi inser gradvis att vi behöver använda några moduler.

Den första typen av moduler du stöter på är resursmoduler. De förstår inte vad din infrastruktur handlar om, vad din verksamhet handlar om, var och vilka förutsättningarna är. Det är just dessa moduler som jag tillsammans med open source-communityt administrerar och som vi lägger fram som de allra första byggstenarna för din infrastruktur.

Ett exempel på en resursmodul.

När vi anropar en resursmodul anger vi från vilken väg vi ska ladda dess innehåll.

Vi anger vilken version vi vill ladda ner.

Vi för en massa argument där. Det är allt. Det är allt vi behöver veta när vi använder den här modulen.

Många tror att om de använder den senaste versionen kommer allt att vara stabilt. Men nej. Infrastrukturen måste vara versionerad, vi måste tydligt svara på vilken version den eller den komponenten distribuerades till.

Här är koden som finns i denna modul. Säkerhetsgruppsmodul. Här går rullningen till 640:e raden. Att skapa en säkerhetsgruppresurs i Amazon i alla möjliga konfigurationer är en mycket icke-trivial uppgift. Det räcker inte att bara skapa en säkerhetsgrupp och tala om för den vilka regler som ska skickas till den. Det skulle vara väldigt enkelt. Det finns en miljon olika begränsningar inom Amazon. Till exempel om du använder VPC-slutpunkt, prefixlista, olika API:er och försöker kombinera allt detta med allt annat, så tillåter inte Terraform dig att göra detta. Och Amazon API tillåter inte detta heller. Därför måste vi dölja all denna hemska logik i en modul och ge användarkoden som ser ut precis så här.

Användaren behöver inte veta hur den är tillverkad inuti.

Den andra typen av moduler, som består av resursmoduler, löser redan problem som är mer tillämpliga på din verksamhet. Ofta är detta en plats som är en förlängning för Terraform och sätter några stela värden för taggar, för företagsstandarder. Du kan även lägga till funktionalitet där som Terraform för närvarande inte tillåter dig att använda. Det här är just nu. Nu version 0.11, som är på väg att bli ett minne blott. Men ändå är förprocessorer, jsonnet, cookiecutter och en massa andra saker hjälpmekanismen som måste användas för ett fullfjädrat arbete.

Härnäst ska jag visa några exempel på detta.

Infrastrukturmodulen kallas på exakt samma sätt.

Källan varifrån du ska ladda ner innehållet anges.

Ett gäng värden skickas in och skickas till denna modul.

Därefter, inuti denna modul, anropas ett gäng resursmoduler för att skapa en VPC eller Application Load Balancer, eller för att skapa en säkerhetsgrupp eller för ett Elastic Container Service-kluster.

Det finns två typer av moduler. Detta är viktigt att förstå eftersom det mesta av informationen som jag har grupperat i denna rapport inte är skriven i dokumentationen.

Och dokumentationen i Terraform just nu är ganska problematisk eftersom den bara säger att det finns dessa funktioner, du kan använda dem. Men hon säger inte hur man använder dessa funktioner, varför det är bättre att använda dem. Därför skriver ett väldigt stort antal människor något som de inte kan leva med.

Låt oss ta en titt på hur man skriver dessa moduler härnäst. Sedan får vi se hur man ringer dem och hur man arbetar med koden.

Terraform Registry - https://registry.terraform.io/

Tips #0 är att inte skriva resursmoduler. De flesta av dessa moduler är redan skrivna för dig. De är som sagt öppen källkod, de innehåller ingen av din affärslogik, de har inga hårdkodade värden för IP-adresser, lösenord etc. Modulen är väldigt flexibel. Och den är med största sannolikhet redan skriven. Det finns många moduler för resurser från Amazon. Cirka 650. Och de flesta är av bra kvalitet.

I det här exemplet kom någon till dig och sa: "Jag vill kunna hantera en databas. Skapa en modul så att jag kan skapa en databas." Personen känner inte till implementeringsdetaljerna för varken Amazon eller Terraform. Han säger helt enkelt: "Jag vill hantera MSSQL." Det vill säga, vi menar att den kommer att anropa vår modul, skicka motortypen dit och indikera tidszonen.

Och en person ska inte veta att vi kommer att skapa två olika resurser i den här modulen: en för MSSQL, den andra för allt annat, bara för att du i Terraform 0.11 inte kan ange tidszonsvärden som valfria.

Och vid utgången från denna modul kommer en person helt enkelt att kunna få en adress. Han kommer inte att veta från vilken databas, från vilken resurs vi skapar allt detta internt. Detta är en mycket viktig del av döljande. Och detta gäller inte bara de moduler som är offentliga i öppen källkod, utan även de moduler som du kommer att skriva i dina projekt och team.

Detta är det andra argumentet, vilket är ganska viktigt om du har använt Terraform ett tag. Du har ett arkiv där du lägger alla dina Terraform-moduler för ditt företag. Och det är helt normalt att det här projektet med tiden kommer att växa till en storlek på en eller två megabyte. Det här är okej.

Men problemet är hur Terraform kallar dessa moduler. Till exempel, om du anropar en modul för att skapa varje enskild användare, kommer Terraform först att ladda hela förvaret och sedan navigera till mappen där den specifika modulen finns. På så sätt kommer du att ladda ner en megabyte varje gång. Om du hanterar 100 eller 200 användare kommer du att ladda ner 100 eller 200 megabyte och sedan gå till den mappen. Så naturligtvis vill du inte ladda ner en massa saker varje gång du trycker på "Terraform init".

https://github.com/mbtproject/mbt

Det finns två lösningar på detta problem. Den första är att använda relativa vägar. På så sätt anger du i koden att mappen är lokal (./). Och innan du startar något, gör du en Git-kloning av detta förråd lokalt. Så här gör du det en gång.

Det finns förstås många nackdelar. Du kan till exempel inte använda versionshantering. Och det här är ibland svårt att leva med.

Andra lösningen. Om du har många undermoduler och du redan har någon form av etablerad pipeline, så finns det MBT-projektet, som låter dig samla in många olika paket från ett monolager och ladda upp dem till S3. Detta är ett mycket bra sätt. Således kommer filen iam-user-1.0.0.zip bara att väga 1 Kb, eftersom koden för att skapa denna resurs är mycket liten. Och det kommer att fungera mycket snabbare.

Låt oss prata om vad som inte kan användas i moduler.

Varför är det här dåligt i moduler? Det värsta är att anta användare. Anta att användaren är ett alternativ för leverantörsautentisering som kan användas av olika personer. Till exempel kommer vi alla att tillgodogöra oss rollen. Det innebär att Terraform tar denna roll. Och sedan med den här rollen kommer den att utföra andra åtgärder.

Och det onda är att om Vasya gillar att ansluta till Amazon på ett sätt, till exempel genom att använda standardmiljövariabeln, och Petya gillar att använda sin delade nyckel, som han har på en hemlig plats, då kan du inte ange båda i Terraform. Och för att de inte ska uppleva lidande behöver de inte ange detta block i modulen. Detta måste anges på en högre nivå. Det vill säga vi har en resursmodul, en infrastrukturmodul och en sammansättning ovanpå. Och detta bör anges någonstans högre.

Det andra onda är försörjaren. Här är det onda inte så trivialt, för om du skriver kod och det fungerar för dig, då kanske du tänker att om det fungerar, varför ändra det då.

Det onda är att du inte alltid kontrollerar när den här provisionern kommer att lanseras, för det första. Och för det andra styr du inte vad aws ec2 betyder, d.v.s. pratar vi om Linux eller Windows nu. Så du kan inte skriva något som fungerar likadant på olika operativsystem eller för olika användarfall.

Det vanligaste exemplet, som också anges i den officiella dokumentationen, är att om du skriver aws_instance och anger en massa argument, så är det inget fel med det om du anger provisorn "local-exec" där och kör din ansible- lekbok.

Faktiskt, ja, det är inget fel med det. Men bokstavligen snart kommer du att inse att den här local-exec-grejen inte existerar, till exempel i launch_configuration.

Och när du använder launch_configuration och du vill skapa en autoskalningsgrupp från en instans, då finns det inget koncept för "provisioner" i launch_configuration. Det finns begreppet "användardata".

Därför är en mer universell lösning att använda användardata. Och den kommer att startas antingen på själva instansen, när instansen är påslagen, eller i samma användardata, när den automatiska skalningsgruppen använder denna launch_configuration.

Om du fortfarande vill köra provisionern, eftersom det är en limningskomponent, när en resurs skapas, måste du i det ögonblicket köra din provisioner, ditt kommando. Det finns många sådana situationer.

Och den mest korrekta resursen för detta kallas null_resource. Null_resource är en dummy-resurs som faktiskt aldrig skapas. Det rör ingenting, inget API, ingen automatisk skalning. Men det låter dig styra när du ska köra kommandot. I det här fallet körs kommandot under skapandet.

Länk http://bit.ly/common-traits-in-terraform-modules

Det finns flera tecken. Jag kommer inte att gå in på alla tecken i detalj. Det finns en artikel om detta. Men om du har arbetat med Terraform eller använt andras moduler, har du ofta märkt att många moduler, som det mesta av koden i öppen källkod, är skrivna av människor för deras egna behov. En man skrev det och löste sitt problem. Jag fastnade den i GitHub, låt den leva. Den kommer att leva, men om det inte finns någon dokumentation och exempel där, då kommer ingen att använda den. Och om det inte finns någon funktionalitet som gör att du kan lösa lite mer än sin specifika uppgift, så kommer ingen att använda den heller. Det finns så många sätt att tappa användare.

Om du vill skriva något så att folk ska använda det, rekommenderar jag att du följer dessa skyltar.

De är:

• Dokumentation och exempel.
• Full funktionalitet.
• Rimliga standardinställningar.
• Ren kod.
• Tester.

Tester är en annan situation eftersom de är ganska svåra att skriva. Jag tror mer på dokumentation och exempel.

Så vi tittade på hur man skriver moduler. Det finns två argument. Det första, som är det viktigaste, är att inte skriva om du kan, för ett gäng människor har redan gjort dessa uppgifter före dig. Och för det andra, om du fortfarande bestämmer dig, försök att inte använda leverantörer i moduler och provisioner.

Detta är den grå delen av dokumentationen. Du kanske nu tänker: ”Något är oklart. Inte övertygad." Men vi får se om ett halvår.

Låt oss nu prata om hur man kallar dessa moduler.

Vi förstår att vår kod växer med tiden. Vi har inte längre en fil, vi har redan 20 filer. De finns alla i en mapp. Eller kanske fem mappar. Kanske börjar vi på något sätt dela upp dem efter region, efter vissa komponenter. Då förstår vi att nu har vi några rudiment av synkronisering och orkestrering. Det vill säga, vi måste förstå vad vi ska göra om vi ändrade nätverksresurser, vad vi ska göra med resten av våra resurser, hur vi kan orsaka dessa beroenden osv.

Det finns två ytterligheter. Den första ytterligheten är allt i ett. Vi har en masterfil. För närvarande var detta den officiella bästa praxisen på Terraforms webbplats.

Men nu är det skrivet som utfasadt och borttaget. Med tiden insåg Terraform-gemenskapen att detta var långt ifrån den bästa praxisen, eftersom folk började använda projektet på olika sätt. Och det finns problem. Till exempel när vi listar alla beroenden på ett ställe. Det finns situationer när vi klickar på "Terraform plan" och tills Terraform uppdaterar tillstånden för alla resurser kan mycket tid gå.

Mycket tid är till exempel 5 minuter. För vissa är detta mycket tid. Jag har sett fall där det tog 15 minuter. AWS API ägnade 15 minuter åt att försöka ta reda på vad som hände med tillståndet för varje resurs. Detta är ett mycket stort område.

Och, naturligtvis, kommer ett relaterat problem att dyka upp när du vill ändra något på ett ställe, sedan väntar du 15 minuter och det ger dig en duk av några ändringar. Du spottade, skrev "Ja", och något gick fel. Detta är ett mycket verkligt exempel. Terraform försöker inte skydda dig från problem. Det vill säga, skriv vad du vill. Det kommer att finnas problem - dina problem. Medan Terraform 0.11 inte försöker hjälpa dig på något sätt. Det finns vissa intressanta platser i 0.12 som låter dig säga: "Vasya, du vill verkligen ha det här, kan du komma till sinnes?"

Det andra sättet är att minska detta område, det vill säga samtal från en plats kan vara mindre kopplade från en annan plats.

Det enda problemet är att du behöver skriva mer kod, d.v.s. du behöver beskriva variabler i ett stort antal filer och uppdatera detta. Vissa människor gillar det inte. Detta är normalt för mig. Och vissa människor tänker: "Varför skriver jag det här på olika ställen, jag ska lägga allt på ett ställe." Detta är möjligt, men detta är den andra ytterligheten.

Vem har allt detta boende på ett och samma ställe? En, två, tre personer, det vill säga någon använder den.

Och vem anropar en viss komponent, ett block eller en infrastrukturmodul? Fem till sju personer. Detta är coolt.

Det vanligaste svaret är någonstans i mitten. Om projektet är stort, kommer du ofta att ha en situation där ingen lösning är lämplig och inte allt fungerar där ute, så du hamnar i en blandning. Det är inget fel med detta, så länge du förstår att båda har fördelar.

Om något ändrades i stacken VPC och du ville tillämpa dessa ändringar på EC2, d.v.s. du ville uppdatera den automatiska skalningsgruppen eftersom du hade ett nytt subnät, då kallar jag denna typ av beroendeorkestrering. Det finns några lösningar: vem använder vad?

Jag kan föreslå vilka lösningar som finns. Du kan använda Terraform för att göra magin, eller så kan du använda makefiler för att använda Terraform. Och se om något har förändrats där, du kan starta det här.

Hur gillar du det här beslutet? Är det någon som tror att detta är en cool lösning? Jag ser ett leende, tvivel har tydligen smugit sig in.

Naturligtvis, prova inte detta hemma. Terraform designades aldrig för att köras från Terraform.

Vid en rapport sa de till mig: "Nej, det här kommer inte att fungera." Poängen är att det inte ska fungera. Även om det ser så imponerande ut när du kan starta Terraform från Terraform, och sedan Terraform, bör du inte göra det. Terraform ska alltid starta väldigt lätt.

https://github.com/gruntwork-io/terragrunt/

Om du behöver samtalsorkestrering när något har förändrats på ett ställe, så finns det Terragrunt.

Terragrunt är ett verktyg, ett tillägg till Terraform, som låter dig koordinera och orkestrera samtal till infrastrukturmoduler.

En typisk Terraform-konfigurationsfil ser ut så här.

Du anger vilken specifik modul du vill anropa.

Vilka beroenden har modulen?

Och vilka argument accepterar denna modul. Det är allt som finns att veta om Terragrunt.

Dokumentationen finns där, och det finns 1 700 stjärnor på GitHub. Men i de flesta fall är detta vad du behöver veta. Och detta är väldigt enkelt att implementera i företag som precis har börjat arbeta med Terraform.

Så orkestrering är Terragrunt. Det finns andra alternativ.

Låt oss nu prata om hur man arbetar med koden.

Om du behöver lägga till nya funktioner i din kod är det i de flesta fall enkelt. Du skriver en ny resurs, allt är enkelt.

Om du har någon resurs som du skapat i förväg, till exempel, du lärde dig om Terraform efter att du öppnat ett AWS-konto och vill använda de resurser som du redan har, så skulle det vara lämpligt att utöka din modul på detta sätt, så att det stödjer användningen av befintliga resurser.

Och stödde skapandet av nya resurser med hjälp av blockresursen.

På output returnerar vi alltid output id beroende på vad som användes.

Det andra mycket betydande problemet i Terraform 0.11 är att arbeta med listor.

Svårigheten är att om vi har en sådan lista över användare.

Och när vi skapar dessa användare med hjälp av blockresurs går allt bra. Vi går igenom hela listan och skapar en fil för varje. Allt är bra. Och då ska till exempel user3, som är i mitten, tas bort härifrån, då kommer alla resurser som skapades efter honom att återskapas eftersom indexet kommer att ändras.

Arbeta med listor i en tillståndsfull miljö. Vad är en tillståndsfull miljö? Detta är situationen där ett nytt värde skapas när denna resurs skapas. Till exempel AWS Access Key eller AWS Secret Key, det vill säga när vi skapar en användare får vi en ny Access eller Secret Key. Och varje gång vi tar bort en användare kommer denna användare att ha en ny nyckel. Men detta är inte feng shui, eftersom användaren inte vill vara vän med oss ​​om vi skapar en ny användare åt honom varje gång någon lämnar laget.

Detta är lösningen. Detta är kod skriven i Jsonnet. Jsonnet är ett mallspråk från Google.

Detta kommando låter dig acceptera den här mallen och som utdata returnerar den en json-fil som är gjord enligt din mall.

Mallen ser ut så här.

Terraform låter dig arbeta med både HCL och Json på samma sätt, så om du har förmågan att generera Json, så kan du glida in den i Terraform. Filen med tillägget .tf.json kommer att laddas ned.

Och så jobbar vi med det som vanligt: ​​terraform init, terramorm gäller. Och vi skapar två användare.

Nu är vi inte rädda om någon lämnar laget. Vi kommer bara att redigera json-filen. Vasya Pupkin gick, Petya Pyatochkin blev kvar. Petya Pyatochkin kommer inte att få en ny nyckel.

Att integrera Terraform med andra verktyg är egentligen inte Terraforms jobb. Terraform skapades som en plattform för att skapa resurser och det är allt. Och allt som kommer upp senare är inte Terraforms angelägenhet. Och det finns ingen anledning att väva in den där. Det finns Ansible, som gör allt du behöver.

Men situationer uppstår när vi vill utöka Terraform och anropa något kommando efter att något har slutförts.

Första sättet. Vi skapar en utgång där vi skriver detta kommando.

Och sedan anropar vi det här kommandot från skalets terraform-utgång och anger värdet som vi vill ha. Således exekveras kommandot med alla ersatta värden. Det är väldigt bekvämt.

Andra sättet. Detta är användningen av null_resource beroende på förändringar i vår infrastruktur. Vi kan anropa samma lokala exe så snart som ID för någon resurs ändras.

Naturligtvis är allt detta smidigt på pappret, eftersom Amazon, precis som alla andra offentliga leverantörer, har ett gäng egna kantfodral.

Det vanligaste edge-fallet är att när du öppnar ett AWS-konto spelar det roll vilka regioner du använder; är denna funktion aktiverad där; kanske du öppnade den efter december 2013; kanske använder du standard i VPC etc. Det finns många begränsningar. Och Amazon spred dem genom hela dokumentationen.

Det finns några saker jag rekommenderar att undvika.

För att börja, undvik alla icke-hemliga argument i Terraform-planen eller Terraform CLI. Allt detta kan läggas antingen i en tfvars-fil eller i en miljövariabel.

Men du behöver inte memorera hela detta magiska kommando. Terraform plan – var och iväg. Den första variabeln är var, den andra variabeln är var, den tredje, fjärde. Den viktigaste principen för infrastruktur som kod som jag använder oftast är att jag bara genom att titta på koden ska ha en klar förståelse för vad som är utplacerat där, i vilket tillstånd och med vilka värden. Och så jag behöver inte läsa dokumentationen eller fråga Vasya vilka parametrar han använde för att skapa vårt kluster. Jag behöver bara öppna en fil med tillägget tfvars, som ofta matchar miljön, och titta på allt där.

Använd inte heller målargument för att minska omfattningen. För detta är det mycket lättare att använda små infrastrukturmoduler.

Dessutom finns det inget behov av att begränsa och öka parallelliteten. Om jag har 150 resurser och jag vill öka Amazon-parallellen från standardvärdet 10 till 100, så kommer något troligen att gå fel. Eller så kanske det går bra nu, men när Amazon säger att du ringer för många samtal kommer du att få problem.

Terraform kommer att försöka starta om de flesta av dessa problem, men du kommer att uppnå nästan ingenting. Parallelism=1 är en viktig sak att använda om du stöter på någon bugg i AWS API eller inuti Terraform-leverantören. Och sedan måste du specificera: parallellism=1 och vänta tills Terraform avslutar ett samtal, sedan det andra och sedan det tredje. Han kommer att lansera dem en efter en.

Folk frågar mig ofta, "Varför tror jag att Terraform-arbetsytor är onda?" Jag tror att principen för infrastruktur som kod är att se vilken infrastruktur som har skapats och med vilka värden.

Arbetsytor skapades inte av användare. Detta betyder inte att användare skrev i GitHub-problem att vi inte kan leva utan Terraform-arbetsytor. Nej inte så här. Terraform Enterprise är en kommersiell lösning. Terraform från HashiCorp bestämde att vi behövde arbetsytor, så vi arkiverade det. Jag tycker att det är mycket lättare att lägga det i en separat mapp. Då blir det lite fler filer, men det blir tydligare.

Hur arbetar man med koden? Att arbeta med listor är faktiskt den enda smärtan. Och ta Terraform lättare. Det här är inte det som kommer att göra allt bra för dig. Det finns ingen anledning att skjuta dit allt som står i dokumentationen.

Ämnet för rapporten skrevs "för framtiden". Jag ska prata om detta mycket kort. För framtiden betyder det att 0.12 kommer att släppas snart.

0.12 är massor av nya saker. Om du kommer från vanlig programmering, då missar du alla möjliga dynamiska block, loopar, korrekta och villkorade jämförelseoperationer, där vänster och höger sida inte beräknas samtidigt, utan beroende på situationen. Du saknar det mycket, så 0.12 löser det åt dig.

Men! Om du skriver mindre och enklare, använder färdiga moduler och tredjepartslösningar, behöver du inte vänta och hoppas att 0.12 kommer och fixar allt åt dig.

Tack för rapporten! Du pratade om infrastruktur som kod och sa bokstavligen ett ord om tester. Behövs tester i moduler? Vems ansvar är detta? Behöver jag skriva det själv eller är det modulernas ansvar?

Nästa år kommer att fyllas med rapporter om att vi har bestämt oss för att testa allt. Vad man ska testa är den största frågan. Det finns många beroenden, många restriktioner från olika leverantörer. När du och jag pratar och du säger: "Jag behöver tester", då frågar jag: "Vad ska du testa?" Du säger att du kommer att testa i din region. Då säger jag att det här fungerar inte i min region. Det vill säga, vi kommer inte ens att kunna komma överens om detta. För att inte tala om att det finns många tekniska problem. Det vill säga hur man skriver dessa tester så att de är adekvata.

Jag forskar aktivt om detta ämne, dvs hur man automatiskt genererar tester baserat på infrastrukturen som du skrev. Det vill säga om du skrev den här koden måste jag köra den, baserat på detta kan jag skapa tester.

Terratest är ett av de oftast nämnda biblioteken som låter dig skriva integrationstester för Terraform. Detta är ett av verktygen. Jag föredrar DSL-typen, till exempel rspec.

Anton, tack för rapporten! Jag heter Valery. Låt mig ställa en liten filosofisk fråga. Det finns, villkorligt, provisionering, det finns utplacering. Provisioning skapar min infrastruktur, i driftsättning fyller vi den med något användbart, till exempel servrar, applikationer etc. Och det är i mitt huvud att Terraform är mer för provisionering, och Ansible är mer för distribution, eftersom Ansible också är för fysisk Infrastrukturen låter dig installera nginx, Postgres. Men samtidigt verkar Ansible tillåta provisionering av till exempel Amazon- eller Google-resurser. Men Terraform låter dig också distribuera viss programvara med hjälp av dess moduler. Ur din synvinkel, finns det någon form av gräns som går mellan Terraform och Ansible, var och vad är bättre att använda? Eller, till exempel, tycker du att Ansible redan är skräp, ska du försöka använda Terraform till allt?

Bra fråga, Valery. Jag tror att Terraform inte har förändrats vad gäller syfte sedan 2014. Det skapades för infrastruktur och dog för infrastruktur. Vi hade fortfarande och kommer att ha ett behov av konfigurationshantering Ansible. Utmaningen är att det finns användardata inuti launch_configuration. Och där drar man Ansible etc. Det här är standardskillnaden som jag gillar bäst.

Om vi ​​pratar om i vacker infrastruktur, så finns det verktyg som Packer som samlar in den här bilden. Och sedan använder Terraform datakällan för att hitta den här bilden och uppdatera dess launch_configuration. Det vill säga på detta sätt är pipelinen att vi först drar Tracker, sedan drar Terraform. Och om det byggs upp sker en ny förändring.

Hallå! Tack för rapporten! Jag heter Misha, RBS-företag. Du kan ringa Ansible via provisioner när du skapar en resurs. Ansible har också ett ämne som kallas dynamisk inventering. Och du kan först ringa Terraform och sedan ringa Ansible, som tar resurser från staten och kör det. Vad är bättre?

Människor använder båda med lika stor framgång. Det verkar för mig att dynamisk inventering i Ansible är en bekväm sak, om vi inte pratar om autoskalningsgrupp. För i autoskalningsgruppen har vi redan vår egen verktygslåda, som kallas launch_configuration. I launch_configuration registrerar vi allt som behöver startas när vi skapar en ny resurs. Därför, med Amazon, är det överdrivet att använda dynamisk inventering och läsa Terraform ts-filen. Och om du använder andra verktyg där det inte finns något koncept för "autoskalningsgrupp", till exempel använder du DigitalOcean eller någon annan leverantör där det inte finns någon autoskalningsgrupp, då måste du manuellt dra API:et, hitta IP-adresser, skapa en dynamisk inventeringsfil, och Ansible kommer redan att vandra genom den. Det vill säga, för Amazon finns launch_configuration, och för allt annat finns dynamisk inventering.

Källa: will.com