Mönster i Terraform för att bekämpa kaos och manuell rutin. Maxim Kostrykin (Ixtens)

Det verkar som att Terraform-utvecklare erbjuder ganska användbara bästa metoder för att arbeta med AWS-infrastruktur. Men det finns en liten detalj. Med tiden ökar antalet miljöer och varje har sina egna särdrag. En nästan exakt kopia av applikationsstegen dyker upp i grannregionen. Terraform-koden måste kopieras och redigeras noggrant enligt de nya kraven eller så måste man skapa en snöflinga.

Min presentation handlar om mönster i Terraform för att motverka kaos och manuella rutiner i stora och långvariga projekt.

Video:

Jag är 40 år och har arbetat inom IT i 20 år. Jag har jobbat på Ixtens i 12 år. Vi sysslar med e-commerce-driven development. Och de senaste 5 åren har jag tillämpat DevOps-praktiker.

Mitt berättande kommer att handla om erfarenheter från ett projekt på ett företag vars namn jag inte kommer att avslöja på grund av ett sekretessavtal.

Siffrorna på bilden är angivna för att förstå projektets omfattning. Och allt jag kommer att säga härnäst är relaterat till Amazon.

Jag gick med i det här projektet för 4 år sedan. Och mitt under den pågående omstruktureringen av infrastrukturen, eftersom projektet hade vuxit. De mönster som användes passade inte längre. Med tanke på den planerade tillväxten av projektet behövde vi tänka på något nytt.

Tack till Matvej som igår berättade om vad som hände på Dodo Pizza. Det är det som hände hos oss för 4 år sedan.

Utvecklarna kom in och började skapa infrastrukturen koden.

De mest uppenbara anledningarna till varför detta krävdes var behovet av snabbare time to market. Det var viktigt att DevOps-teamet inte skulle vara flaskhalsen vid lanseringen. För övrigt användes Terraform och Puppet redan på den allra första nivån.

Terraform är ett open source-projekt från HashiCorp. För dem som inte har någon aning om vad detta är, följer de kommande bilderna.

Infrastruktur som kod betyder att vi kan beskriva vår infrastruktur och be några robotar att skapa de resurser som vi har beskrivit.

Till exempel, vi behöver virtuell maskin. Vi kommer att beskriva det, lägga till ett par obligatoriska parametrar.

Därefter ställer vi in åtkomst till Amazon i konsolen. Och vi ber Terraform göra en plan. Terraform-planen kommer att säga: "Okej, för din resurs kan vi göra följande." Och minst en resurs kommer att läggas till. Och inga förändringar förväntas.

När du är nöjd kan du be Terraform att tillämpa och Terraform kommer att skapa en instans åt dig, och du får en virtuell maskin i din moln.

Vidare utvecklas vårt projekt. Vi lägger till vissa förändringar. Vi ber om fler instanser, vi lägger till 53 poster.

Och vi upprepar. Vi ber om en plan. Vi ser vilka förändringar som planeras. Vi tillämpar. På så sätt växer vår infrastruktur.

Terraform använder något som kallas state-filer. Det vill säga, alla förändringar som skickas till Amazon sparas i en fil där varje resurs du har beskrev har motsvarande resurser som skapats i Amazon. På så sätt vet Terraform exakt vad som behöver ändras i Amazon när en beskrivning av en resurs ändras.

Dessa state-filer var ursprungligen bara filer. Och vi lagrade dem i Git, vilket var extremt besvärligt. Någon glömde alltid att göra en commit av förändringar, vilket ledde till många konflikter.

Nu finns det en möjlighet att använda en backend, det vill säga Terraform anger i vilken bucket och med vilken nyckel state-filen ska sparas. Och Terraform tar hand om att hämta denna state-fil, göra all magi och lägga tillbaka det slutgiltiga resultatet.

Vår infrastruktur växer. Här är vår kod. Och nu vill vi inte bara skapa en virtuell maskin, vi vill ha en testmiljö.

Terraform gör det möjligt att skapa något som kallas en modul, det vill säga beskriva samma sak i en specifik mapp.

Och till exempel i testningen kalla på denna modul och få samma resultat som om vi hade utfört Terraform apply i själva modulen. För testningen kommer koden att se ut så här.

För produktion kan vi skicka vissa förändringar dit, eftersom vi inte behöver stora instanser i testningen, medan stora instanser i produktion är precis vad som behövs.

Och framöver kommer jag att återvända till projektet. Det var en komplex uppgift, infrastrukturen planerades att vara mycket stor. Det var nödvändigt att organisera all kod så att den var bekväm för alla: både för dem som utför underhåll av denna kod och för dem som gör förändringar. Det var planerat att varje utvecklare skulle kunna gå in och justera infrastrukturen efter behov för sin del av plattformen.

Detta är katalogträdet som rekommenderas av HashiCorp självt, om du har ett stort projekt och det är meningsfullt att dela upp hela infrastrukturen i mindre delar, och beskriva varje del i en separat mapp.

Med ett omfattande bibliotek av resurser kan man i testningen och produktionen kalla på ungefär samma.

I vårt fall passade det inte riktigt, eftersom teststacken för utvecklare eller för testning behövde fås på ett enklare sätt. Att gå igenom mappar och använda dem i rätt ordning, samt oroa sig för att databasen skulle starta, för att sedan starta instansen som använder denna databas, ville vi inte. Därför kördes all testning från en och samma mapp. Där anropades samma moduler, men allt genomfördes på en gång.

Terraform tar hand om alla beroenden. Och skapar alltid resurser i den ordning som gör att man kan få IP-adressen, till exempel, från den nyskapade instansen, och få den IP-adressen i en route53-post.

Dessutom är plattformen väldigt stor. Och att köra teststacken, även om det bara är för en timme eller åtta timmar, är en ganska kostsam affär.

Vi automatiserade detta. Jenkins-jobbet gjorde det möjligt att köra stacken. Man behövde starta en pull request med de ändringar som utvecklaren ville testa, ange alla nödvändiga alternativ, komponenter samt storlekar. Om han ville utföra prestandatestning, kunde han ta fler instanser. Om han bara behövde kontrollera att ett formulär öppnas, kunde han köra det på minimala inställningar. Man kunde också ange om en kluster behövdes eller inte, och så vidare.

Och sedan pushade Jenkins ett shell-skript som lite modifierade koden i Terraform-mappen. Det tog bort onödiga filer, lade till nödvändiga filer. Och sedan, med ett enda körning, startade Terraform apply stacken.

Och därefter följde andra steg, som jag inte vill gå djupare in på.

Eftersom vi behövde lite fler alternativ för testningen än i produktion, var vi tvungna att göra kopior av modulerna för att kunna lägga till de funktioner som endast behövdes i testningen.

Och så blev det så att i testningen ville man liksom testa de ändringar som skulle gå till produktion. Men i verkligheten testades en sak, medan något annat tillämpades i produktion. Det fanns en liten klyfta, eftersom alla ändringar i produktion tillämpades av driftteamet. Och ibland hände det att de ändringar som skulle gå från testningen till produktion förblev i en annan version.

Utöver detta fanns det ett problem där en ny tjänst lades till, som skilde sig något från en redan befintlig. Istället för att modifiera den existerande modulen fick man göra en kopia av den och lägga till nödvändiga ändringar.

I grund och botten är Terraform inte ett riktigt språk. Det är en deklaration. Om vi behöver deklarera något, så gör vi det. Och allt detta fungerar.

Vid ett tillfälle, när en av mina pull requests diskuterades, sa en kollega att vi inte behövde skapa snöflingor. Jag blev nyfiken på vad han menade. Det finns en vetenskaplig fakta som säger att det inte finns två identiska snöflingor i världen, de skiljer sig alla lite grann. Så snart jag hörde detta kände jag vikten av Terraform-koden. För när det krävdes att gå från en version till en annan, krävde Terraform en breaking chain-ändring, det vill säga att koden inte längre var kompatibel med den nästa versionen. Och man behövde göra en pull request som täckte nästan hälften av filerna i infrastrukturen för att föra infrastrukturen till nästa version av Terraform.

Och efter att en sådan snöflinga dök upp, förvandlades all Terraform-kod vi hade till en stor, stor hög med snö.

För en extern utvecklare, som inte är en del av driften, spelar det inte så stor roll, eftersom han gjorde en pull request och hans resurs startade. Och allt, sedan är det inte hans bekymmer. Men för DevOps-teamet, som ser till att allt är okej, krävs det att man gör alla dessa ändringar. Kostnaden för dessa ändringar ökade mycket med varje ytterligare snöflinga.

Det finns en historia om en student på ett seminarium som ritade två perfekta cirklar med krita på tavlan. Läraren blev förvånad över hur han lyckades rita dem så jämnt utan passare. Studenten svarade: "Mycket enkelt, jag snurrade en köttkvarn i två år i armén."

Och av de fyra år som jag har deltagit i detta projekt har jag på cirka två år sysslat med Terraform. Och självklart har jag några knep, några tips på hur man kan förenkla Terraform-koden, arbeta med den som ett programmeringsspråk och minska belastningen på utvecklarna som måste hålla denna kod uppdaterad.

Det första jag skulle vilja börja med är Symlinks. Terraform har mycket upprepande kod. Till exempel, anropet av leverantören sker praktiskt taget vid varje punkt där vi skapar en del av infrastrukturen, det är alltid detsamma. Därför är det logiskt att flytta det till en separat mapp. Och där det krävs av leverantören, skapa Symlinks till den här filen.

Till exempel, i produktion använder ni en assume role som tillåter er att få åtkomst till ett externt Amazon-konto. Om ni ändrar en fil, kommer alla andra som finns i resursstrukturen att ha de nödvändiga rättigheterna för att Terraform ska veta vilket Amazon-segment det ska ansluta till.

Var fungerar inte Symlinks? Som sagt, i Terraform finns det state-filer. Och de är verkligen, verkligen bra. Men grejen är att Terraform initierar backend i den allra första fasen. Och det kan inte använda några variabler i dessa parametrar, de måste alltid skrivas som text.

Och som resultat, när någon skapar en ny resurs, kopierar de en del av koden från andra mappar. Och de kan göra ett misstag med nyckeln eller med bucket. Till exempel, de gör en sandbox-pryl från sandbox, men sen gör de en i produktionen. Och det kan hända att bucket i produktionen kommer att användas från sandbox. Självklart kommer det att upptäckas snabbt. Det kan åtgärdas på något sätt, men det är ändå en förlust av tid och på ett sätt resurser.

Vad kan vi göra härnäst? Innan vi arbetar med Terraform måste vi initiera det. Vid initieringen laddar Terraform ner alla plugins. Vid något tillfälle bröts de från en monolitisk arkitektur till en mer mikrotjänstarkitektur. Och det är alltid nödvändigt att köra Terraform init för att hämta alla moduler och alla plugins.

Och vi kan använda ett shell-script som, för det första, kan hämta alla variabler. Shell-scriptet är inte begränsat. För det andra, sökvägar. Om vi alltid använder den sökväg som finns i repositoryt som nyckel till state-filen, så är därför risken för fel eliminerad.

Varifrån får vi data? JSON-fil. Terraform tillåter att skriva infrastrukturen inte bara i hcl (HashiCorp Configuration Language), utan även i JSON.

JSON är lätt att läsa från shell-scriptet. Därför kan vi placera en konfigurationsfil med bucket på något ställe. Och använda denna bucket både i Terraform-koden och i shell-scriptet för initiering.

Varför är det viktigt att ha en bucket för Terraform? För att det finns något som kallas remote state-filer. Det vill säga, när jag skapar en resurs måste jag, för att säga till Amazon: "Skapa gärna en instans", ange många obligatoriska parametrar.

Och dessa identifierare lagras i en annan mapp. Jag kan säga: "Terraform, gå snälla till state-filen för den aktuella resursen och hämta dessa identifierare åt mig." På så sätt blir det en slags enhetlighet mellan olika regioner eller miljöer.

Det är inte alltid möjligt att använda en fjärrstate-fil. Till exempel, om du har skapat en VPC manuellt. Och den Terraform-kod som skapar VPC:n skapar en så pass olik VPC att det tar lång tid och krävs många justeringar för att få det att fungera, därför kan man använda följande lösning.

Det vill säga att göra en modul som på något sätt skapar en VPC och ger dig identifierarna, men i själva verket är det bara en fil med hårdkodade värden som kan användas för att skapa samma instans.

Det är inte alltid nödvändigt att spara state-filen i molnet. Till exempel när moduler testas kan man använda backend-initialisering, där filen sparas bara på disken under testningen.

Lite om testning nu. Vad kan man testa i Terraform? Förmodligen mycket, men jag kommer att prata om dessa 4 saker.

HashiCorp har en viss förståelse för hur Terraform-koden ska formateras. Terraform fmt låter dig formatera koden du redigerar enligt denna standard. Därför måste testerna absolut verifiera om formateringen stämmer överens med vad HashiCorp har föreskrivit, så att du inte behöver ändra placeringen av parenteser osv.

Nästa är Terraform validate. Det gör lite mer än bara syntaktisk kontroll – typ, är alla parenteser parvisa. Vad är viktigt här? Vår infrastruktur är ganska omfattande. Det finns många olika mappar, och i varje måste Terraform validate köras.

För att påskynda testningen kör vi flera processer parallellt.

Parallell är en riktigt bra grej, använd den.

Men varje gång Terraform initieras går den till HashiCorp och frågar: "Vilka är de senaste versionerna av pluggarna? Och den plugin jag har i cache - är den aktuell eller inte?". Och detta innebär en försening vid varje steg.

Om man talar om för Terraform var pluggarna finns, säger Terraform: "Okej, det här är antagligen den senaste versionen. Jag behöver inte gå någonstans, jag börjar direkt validera din Terraform-kod."

För att fylla mappen med nödvändiga pluggar har vi en mycket enkel Terraform-kod som bara behöver initieras. Här måste man självklart ange alla leverantörer som på något sätt är involverade i din kod, annars säger Terraform: "Jag känner inte till någon leverantör eftersom den inte finns i cachen."

Nästa steg är Terraform plan. Som nämnt, utveckling är cyklisk. Vi gör kod med ändringar. Och sedan måste vi ta reda på vilka ändringar som planeras på infrastrukturen.

Och när infrastrukturen är väldigt, väldigt stor, kan man ändra en modul, fixa en testmiljö eller en specifik region och bryta något närliggande. Därför bör Terraform plan göras för hela infrastrukturen och visa vilka ändringar som är planerade.

Detta kan göras smart. Vi har till exempel skrivit ett script på Python som löser beroenden. Beroende på vad som har ändrats: Terraform-modulen eller bara en specifik komponent, gör det planer för alla beroende mappar.

Terraform plan bör göras på begäran. Åtminstone är det vad vi gör.

Tester är självklart bra att göra för varje förändring, för varje commit, men planer är ganska kostsamma. Och i pull request säger vi: "Vänligen ge mig planer". En robot sätts igång. Och den skickar i kommentarer eller som bifogade filer alla planer som förväntas från dina ändringar.

Planen är en ganska kostsam process. Den tar tid eftersom Terraform går till Amazon och frågar: "Finns denna instans fortfarande? Har denna autoskalexakt dessa parametrar?". Och för att snabba på processen kan man använda parametern refresh=false. Det innebär att Terraform kommer att hämta state från S3. Och kommer att tro att state exakt motsvarar det som finns i Amazon.

En sådan Terraform-plan går mycket snabbare, men tillståndet måste motsvara din infrastruktur, dvs. någonstans, någon gång måste Terraform refresh köras. Terraform refresh gör just det, så att tillståndet stämmer överens med vad som finns i den verkliga infrastrukturen.

Och det är viktigt att nämna säkerhet. Det är här man borde börja. Där du kör Terraform, och Terraform arbetar med din infrastruktur, finns det en sårbarhet. Det vill säga, du kör i grunden kod. Och om pull requesten innehåller någon skadlig kod, kan den köras på en infrastruktur som har för mycket åtkomst. Så var försiktig med var du kör Terraform-planen.

Nästa sak jag vill prata om är testning av user-data.

Vad är user-data? I Amazon, när vi skapar en instans, kan vi skicka något slags meddelande med instansen – metadata. När instansen startas finns vanligtvis cloud init alltid på dessa instanser. Cloud init läser detta meddelande och säger: "Okej, idag är jag - load balancer". Och i enlighet med dessa instruktioner utför det vissa åtgärder.

Men tyvärr, när vi gör Terraform-plan och Terraform-tillämpning, ser user-data ut som en sorts gröt av siffror. Det vill säga, det skickar bara en hash. Och allt du kan se i planen är om det kommer att ske några förändringar eller om hashen förblir densamma.

Och om man inte uppmärksammar detta kan ett skadat textdokument hamna på Amazon, på den verkliga infrastrukturen.

Som ett alternativ kan man ange inte hela infrastrukturen vid körning, utan endast mallen. Och i koden säga: "Var snäll och skriv ut denna mall för mig". Och slutligen kan man få en utskrift av hur dina data kommer att se ut på Amazon.

Ett annat alternativ är att använda en modul för att generera user-data. Du tillämpar denna modul. Får en fil på disken. Jämför den med referensen. Och på så sätt, om någon junior beslutar sig för att justera user-data lite, kommer dina tester att säga: "Okej, här och här är några förändringar – det är okej".

Nästa sak jag vill prata om är att automatisera Terraform-tillämpning.

Självklart är det ganska skrämmande att göra Terraform-tillämpning automatiskt, för vem vet vilka ändringar som kommit och hur förödande de kan vara för den levande infrastrukturen.

För testmiljön – är detta helt okej. Det vill säga, jobben som skapar testmiljön är något som alla utvecklare behöver. Och ett uttryck som "jag har allt fungerande" är inte ett skämt, utan ett bevis på att personen har brytt sig, har satt upp stacken, kört tester på denna stack och har säkerställt att allt är okej och sagt: "Okej, den koden jag släpper har testats."

I produktion, sandbox och andra miljöer som är viktigare för affären kan man delvis tillämpa vissa resurser ganska säkert, eftersom det inte leder till att någon dör. Det handlar om: autoscale-grupper, säkerhetsgrupper, roller, route53 och där listan kan bli ganska stor. Men håll ett öga på vad som händer och läs rapporter om automatiska tillämpningar.

Där det är farligt eller läskigt att tillämpa, till exempel om det handlar om resurser med persistent, med databaser, ska ni få rapporter om att det finns oanvända ändringar i något stycke av infrastrukturen. Ingenjören får sedan genom övervakning starta jobs för att tillämpa eller gör det från sin konsol.

I Amazon finns det något som kallas Terminate protection. Och det kan skydda er i vissa fall från oönskade ändringar. Det vill säga, Terraform går till Amazon och säger: "Jag behöver döda denna instans för att skapa en annan." Men Amazon svarar: "Tyvärr, inte idag. Vi har Terminate protection aktiverat."

Och grädden på moset – är kodoptimering. När vi arbetar med Terraform-kod måste vi överföra ett mycket stort antal parametrar till modulen. Det är de parametrar som behövs för att skapa en viss resurs. Och koden blir till stora listor av parametrar som måste överföras från modul till modul, särskilt om modulerna är inbäddade.

Och det är mycket svårt att läsa. Det är mycket svårt att göra granskning. Och det händer ofta att vissa parametrar går igenom granskningen och de är inte helt de som behövs. Och det kostar tid och pengar att åtgärda det senare.

Därför föreslår jag att ni använder något som kallas komplex parameter som inkluderar en slags träddiagram av värden. Det vill säga, ni behöver en mapp där ni anger alla värden som ni skulle vilja ha på någon miljö.

Och genom att anropa denna modul kan man få ett träd som genereras i en gemensam modul, det vill säga i en gemensam modul som fungerar lika för hela infrastrukturen.

I denna modul kan du göra vissa beräkningar, med hjälp av en ny funktion i Terraform som kallas locals. Och sedan kan du genom en output ge något komplext parameter som kan inkludera hash, arrayer och så vidare.

Det är allt för de bästa insikterna jag har. Jag skulle också vilja berätta en historia om Columbus. När han sökte pengar för sin expedition för att upptäcka Indien (som han då trodde), trodde ingen på honom och de ansåg det vara omöjligt. Då sa han: "Få ägget att inte ramla." Alla bankirer, mycket rika och förmodligen smarta människor, försökte på något sätt ställa ägget upp, men det föll hela tiden. Då tog Columbus ägget, tryckte lite på det. Det sprack och ägget stod still. De sa: "Åh, det här är för enkelt!". Och Columbus svarade: "Ja, det är för enkelt. Och när jag upptäcker Indien, kommer alla att använda denna handelsväg."

Det jag just berättade för er är nog tillräckligt enkla och triviala saker. Och när du lär dig om dem och börjar använda dem är det helt okej. Så använd dem. Och om dessa är helt normala för dig, så vet du åtminstone hur man ställer ägget så att det inte ramlar.

Låt oss sammanfatta:

• Försök att undvika snöflingor. Ju färre snöflingor, desto mindre resurser behöver du för att göra några förändringar i hela din stora infrastruktur.
• Kontinuerliga förändringar. Det vill säga när det har skett förändringar i koden, bör du så snabbt som möjligt föra din infrastruktur i linje med dessa förändringar. Det ska inte finnas situationer där någon kommer om två eller tre månader för att kolla på Elasticsearch, gör Terraform plan, och det finns en massa förändringar som de inte förväntade sig. Och det tar väldigt mycket tid att få allt tillbaka i ordning.
• Tester och automatisering. Ju mer din kod är täckt av tester och funktioner, desto mer är du säker på att du gör allt rätt. Och automatisk leverans ökar din säkerhet flera gånger.
• Koden för test- och produktionsmiljöer bör vara praktiskt taget identiska. Praktiskt taget, eftersom produktion ändå är lite annorlunda och det alltid kommer att finnas några nyanser som går utanför testmiljön. Men ändå kan detta säkerställas med plus-minus.
• Och om ni har väldigt mycket Terraform-kod och det krävs mycket tid för att hålla denna kod aktuell, så är det aldrig för sent att göra refactoring och få den i ett bra skick.

• Immutable infrastructure. Leverans av AMI enligt schema.
• Struktur för route53, när ni har många poster och vill att de ska vara i ordnad ordning.
• Kamp mot API rate limits. Det är när Amazon säger: "Alla, jag kan inte ta emot fler förfrågningar, vänligen vänta." Och halva företaget väntar tills de kan starta sin infrastruktur.
• Spotinstanser. Amazon är inte billigt och spots gör det möjligt att spara ganska mycket. Man kan hålla ett helt föredrag om detta.
• Säkerhet och IAM roller.
• Sökning efter förlorade resurser, när ni har instanser i Amazon av okänt ursprung, de kostar pengar. Även om en instans kostar 100-150 dollar i månaden – per år blir det över 1 000. Att hitta sådana resurser är en lönsam uppgift.
• Och reserverade instanser.

Det är allt för mig. Terraform är riktigt fantastiskt, använd det. Tack!

Frågor

Tack för föredraget! Er state-fil ligger i S3, hur hanterar ni problemet med att flera personer kan ta den state-filen och försöka göra en deployment?

För det första, vi har ingen brådska. För det andra, vi har flaggor där vi meddelar att vi arbetar med en viss del av koden. Det vill säga, trots att infrastrukturen är mycket stor, betyder det inte att någon ständigt tillämpar något. Under den aktiva fasen var det ett problem, våra state-filer lagrades i Git. Det var viktigt, annars skapade någon en state-fil och vi fick manuellt samla dem för att allt skulle fortsätta. Denna problematik finns inte längre. Faktum är att Terraform har löst denna uppgift. Och om något ständigt förändras kan man använda lås som förhindrar det du nämnde.

Använder ni den öppna versionen eller enterprise?

Ingen enterprise, det vill säga allt som kan hämtas gratis.

Jag heter Stanislav. Jag ville göra en liten tillägg. Ni berättade om en funktion från Amazon som gör att instansen blir oförstörbar. Det finns även i Terraform, där man i blocket Life Second kan skriva en förbud mot ändringar, eller ett förbud mot förstörelse.

Jag hade begränsad tid. Bra observation.

Jag ville också fråga om två saker. För det första, ni berättade om tester. Har ni använt några verktyg för testning? Jag har hört talas om pluginet Test Kitchen. Finns det något annat? Och jag skulle också vilja fråga om Local Values. Hur skiljer de sig i grund och botten från Input Variables? Och varför kan jag inte parametrera något enbart genom Local Values? Jag har försökt förstå detta ämne, men jag har inte riktigt lyckats.

Vi kan prata mer detaljerat om detta efter rummet. Testverktygen är helt egenutvecklade. Det finns inget särskilt där för att genomföra tester. Generellt finns det alternativ där automatiserade tester skapar infrastruktur någonstans, kontrollerar att den är okej, och sedan tar bort allt med en rapport som visar att er infrastruktur fortfarande är i bra form. Vi har inte det, eftersom teststaplar körs varje dag. Och det är tillräckligt. Om något börjar gå fel så kommer det att börja falla sönder utan att vi behöver kontrollera det någon annanstans.

Vad gäller Local Values, låt oss fortsätta samtalet efter rummet.

Hej! Tack för presentationen! Mycket lärorikt. Du nämnde att ni har mycket enhetlig kod för att beskriva infrastrukturen. Har ni övervägt att generera denna kod?

Bra fråga, tack! Saken är den att när vi använder infrastruktur som kod, antar vi att vi tittar på koden och förstår vilken infrastruktur som ligger bakom den. Om koden genereras, behöver vi föreställa oss vilken kod som kommer att genereras för att förstå vilken infrastruktur som kommer att finnas där. Antingen genererar vi koden, commitar den, och i praktiken får vi samma sak. Därför gick vi den väg vi har skrivit, det fick vi ut. Plus att generatorer kom något senare, när vi började med detta. Och det var för sent att ändra.

Har du hört något om jsonnet?

Nej.

Kolla, det är en riktigt häftig grej. Jag ser ett specifikt fall där det kan tillämpas och generera datastruktur.

Generatorer är bra, när man har det som i skämtet om rakhyveln. Det vill säga, första gången ser ansiktena olika ut, men sen har alla samma ansikte. Generatorer fungerar väldigt bra. Men tyvärr har vi lite olika ansikten. Det är ett problem.

Bara titta. Tack!

Jag heter Maxim, jag kommer från Sberbank. Du berättade lite om att du försökte göra Terraform till en motsvarighet till ett programmeringsspråk. Är det inte enklare att använda Ansible?

Det är väldigt olika saker. Man kan både skapa resurser med Ansible och Puppet i Amazon. Men Terraform är verkligen anpassat för det.

Har ni bara Amazon?

Det handlar inte om att vi bara har Amazon. Vi har nästan bara Amazon. Men den nyckelfunktion som Terraform har är att det kommer ihåg. I Ansible, om man säger: "Starta 5 instanser", så startar den dem, och sen säger du: "Nu behöver jag 3." Och Terraform säger: "Okej, jag tar bort 2", medan Ansible säger: "Okej, här är 3." Totalt blir det 8.

Hej! Tack för din presentation! Det var mycket intressant att höra om Terraform. Jag vill genast ge en liten kommentar angående att Terraform trots allt inte har en stabil release, så var försiktig med Terraform.

En sked är bra till lunchen. Det vill säga, om du behöver en lösning så skjuter du ibland upp det som är instabilt och så vidare, men det fungerar och det har hjälpt oss.

Jag har en fråga. Ni använder en remote backend, ni använder S3. Varför använder ni inte den officiella backend?

Officiell?

Terraform Cloud.

När kom den?

För cirka 4 månader sedan.

Om den hade kommit för 4 år sedan, så skulle jag troligen ha svarat på din fråga.

Där finns redan en inbyggd funktion och lås, och man kan lagra state-filen. Testa det. Men jag har inte testat det heller.

Vi åker i ett stort tåg som rör sig i hög hastighet. Man kan inte bara ta och kasta ut några vagnar.

Du pratade om snöflingor, varför använde du inte branch? Varför gick det inte att göra så?

Vi har den inställningen att hela infrastrukturen finns i ett repositorium. Terraform, Puppet, alla skript som på något sätt är relaterade till detta, de ligger alla i ett repositorium. På så sätt kan vi garantera att inkrementella ändringar testas en i taget. Om det hade varit en massa branches så skulle ett sådant projekt vara praktiskt taget omöjligt att underhålla. Det går sex månader och de skiljer sig så mycket att det blir ett rent straff. Det är det som jag ville fly ifrån innan refaktoreringen.

Det vill säga, det fungerar inte?

Det här fungerar överhuvudtaget inte.

I branch har jag tagit bort slide-mappen. Det vill säga, om man gör en mapp för varje teststack, till exempel, team A – de har sin egen mapp, team B har sin egen mapp, så fungerar inte det heller. Vi har gjort en enhetlig kod för testmiljön som var tillräckligt flexibel för att passa alla. Det vill säga, vi underhöll en kod.

Hej! Jag heter Jura! Tack för presentationen! Jag har en fråga om moduler. Ni säger att ni använder moduler. Hur hanterar ni situationen om någon gör ändringar i en modul som inte är kompatibla med någon annans ändringar? Versionerar ni moduler eller försöker ni få dem att passa båda kraven?

Det här är ett problem med en stor snöskala. Det är något vi lider av när en till synes ofarlig ändring kan bryta en del av infrastrukturen. Och det kommer bara att märkas efter en viss tid.

Det vill säga, är det fortfarande olöst?

Ni gör universella moduler. Undvik snöflingor. Och allt kommer att fungera. Den andra delen av presentationen handlar om hur man undviker det.

Hej! Tack för presentationen! Jag skulle vilja klargöra en sak. Bakom kulisserna finns en stor hög, som jag kom hit för. Hur är Puppet och rollutdelning integrerade?

User-data.

Det vill säga, spottar ni bara ut en fil och utför på något sätt enligt den?

User-data är en anteckning, det vill säga, när vi skapar en klon av en bild, så startar en daemon och försöker förstå vem den är, läser anteckningen att den är en load balancer.

Det vill säga, är det en separat process som överlämnas?

Vi uppfann inte det. Vi använder det.

Hej! Jag har precis en fråga om User-data. Ni nämnde att det finns problem, att någon kan skicka något felaktigt. Finns det något sätt att lagra user-data i samma Git, så att det alltid är klart vad som refereras av User-data?

Vi genererar User-data från template. Det vill säga, det kommer in ett antal variabler. Och Terraform genererar det slutgiltiga resultatet. Därför kan man inte bara titta på template och säga vad som kommer att hända, eftersom alla problem beror på att utvecklaren tror att han skickar en sträng i den här variabeln, men istället kommer en array. Och så har han - plötsligt och jag - den, den, nästa rad, och allt kraschar. Om det är en ny resurs och någon bygger upp den, ser att något inte fungerar, så kan det snabbt lösas. Men om det är en autoskalningsgrupp som har uppdaterats, då kan instanserna i autoskalningsgruppen börja bytas ut. Och plötsligt fungerar inte något. Det är frustrerande.

Så det enda lösningen är att testa?

Ja, du ser problemet, du lägger till teststeg. Det vill säga, output kan också testas. Kanske inte så bekvämt, men du kan också sätta vissa markörer - kontrollera att User-data är ordentligt fäst här.

Jag heter Timur. Det är väldigt bra att det finns föreläsningar om hur man organiserar Terraform korrekt.

Jag har inte ens börjat.

Jag tror att det kommer att vara på nästa konferens. Jag har en enkel fråga. Varför hårdkodifierar ni värdet i en separat modul, istället för att använda tfvars, det vill säga, vad gör en modul med värden bättre än tfvars?

Det vill säga, jag här (bild: Production/environment/settings.tf) ska skriva: domain = variabel, domain vpcnetwork, variabel vpcnetwork och stvars – hämta samma sak?

Vi gör precis så. Vi refererar till modulens inställningskälla, till exempel.

I princip är det en tfvars. Tfvars är mycket praktiska i testmiljöer. Jag har tfvars för stora instanser, för små. Och jag la en fil i mappen. Och fick det jag ville ha. När vi bygger infrastruktur vill vi kunna se och genast förstå allt. Men det blir så att man måste titta här, sedan titta på tfvars.

Så allt ska vara på ett ställe?

Ja, tfvars är när ni har en kod. Och den används på flera olika ställen med olika nyanser. Då skulle ni ha skickat tfvars och fått era nyanser. Och vi – det är infrastruktur som kod i sin renaste form. Tittade och förstod.

Hej! Har du råkat ut för situationer där molnleverantören blandar sig i det du gjort med Terraform? Anta att vi ändrar metadata. Det finns ssh-nycklar där. Och Google lägger ständigt in sina egna metadatanoteringar och nycklar. Och Terraform säger alltid att det finns förändringar. Efter varje körning, även om ingenting har förändrats, säger det alltid att det ska uppdatera det fältet.

Med nycklarna, men – ja, en del av infrastrukturen påverkas av detta, alltså kan Terraform inte ändra någonting. Vi kan inte ändra någonting manuellt heller. Vi lever med detta.

Alltså har ni stött på detta, men har inte hittat någon lösning, det kör på och på av sig själv?

Tyvärr, ja.

Hej! Jag heter Starkov Stanislav. Mail.ru Group. Hur löser ni problemet med att generera taggen på ..., hur överför ni den inuti? Jag förstår det som att ni använder User-data för att ange hostnamn, och styr Puppet? Och den andra delen av frågan. Hur hanterar ni denna fråga i SG, alltså när ni genererar SG, hundra identiska instanser, hur namnger ni dem korrekt?

De instanser som är mycket viktiga för oss namnger vi vackert. De som inte behövs får en tilläggsnamn som indikerar att det är en autoscale-grupp. Och i teorin kan de tas bort för att skapa en ny.

När det gäller problematiken med taggar så är det inte ett problem utan ett behov. Och vi använder taggar väldigt, väldigt mycket eftersom infrastrukturen är stor och dyr. Vi behöver se vart pengarna går, så taggarna gör att vi kan spåra vad och vart våra kostnader går. Och i sin tur hjälper det oss att leta efter var för mycket pengar spenderas.

Vad var frågan om igen?

När SG skapar hundra instanser, behöver de särskiljas på något sätt?

Nej, det behövs inte. Varje instans har en agent som rapporterar om problem. Om agenten rapporterar så vet agenten om det och åtminstone finns IP-adressen. Redan nu kan man kolla upp. För det andra använder vi Consul för Discovery, där vi inte har Kubernetes. Och Consul visar också IP-adressen för instansen.

Alltså, ni orienterar er efter IP, inte hostnamn?

Det är omöjligt att orientera sig efter hostnamn, det finns för många. Det finns instansidentifierare – AE m.fl. Man kan hitta den någonstans, kan slänga in den i sökningen.

Hej! Jag förstår att Terraform är en bra grej, anpassad för moln.

Inte bara.

Denna fråga intresserar mig. Om du bestämmer dig för att flytta, låt oss säga, till Bare Metal massivt med alla dina instanser? Kommer det inte att uppstå några problem? Eller måste man ändå använda andra produkter, som den nämnda Ansible?

Ansible handlar lite om något annat. Det vill säga, Ansible fungerar när instansen har startat. Terraform fungerar innan instansen har startat. Övergången till Bare Metal – nej.

Just nu nej, men företaget kan komma och säga: "Vi gör det".

Övergång till en annan molnleverantör – ja, men här är det en annan grej. Man måste skriva Terraform-kod på ett sätt så att man kan byta till något annat moln med mindre arbete.

I början var målet att vår infrastruktur skulle vara agnostisk, det vill säga att vilket moln som helst skulle fungera, men vid något tillfälle gav företaget upp och sa: "Okej, under de kommande N åren kommer vi inte att flytta någonstans, vi kan använda tjänster från Amazon".

Terraform gör det möjligt att skapa Front-End-jobb, konfigurera PagerDuty, data-dokument etc. Det har många olika funktioner. Det kan praktiskt taget kontrollera hela världen.

Tack för presentationen! Jag har också arbetat med Terraform i fyra år. Under den gradvisa övergången till Terraform, till infrastrukturen, till deklarativ beskrivning, stötte vi på situationer där någon gjorde saker manuellt, och du försökte skapa en plan. Och fick ett fel. Hur hanterar ni sådana problem? Hur hittar ni de förlorade resurser som har angetts?

Främst manuellt och visuellt, om vi ser något konstigt i rapporten, analyserar vi vad som pågår, eller så tar vi helt enkelt bort det. Det är faktiskt vanligt med pull requests.

Om det finns ett fel, gör ni en rollback? Har ni försökt med det?

Nej, det är en människas beslut i stunden när han ser ett problem.

Källa: habr.com