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

Det verkar som att Terraform-utvecklarna erbjuder ganska bekväma bästa metoder för att arbeta med AWS-infrastrukturen. Bara det finns en nyans. Med tiden ökar antalet miljöer, funktioner visas i varje. Visas nästan en kopia av applikationsstacken i den angränsande regionen. Och Terraform-koden måste noggrant kopieras och redigeras enligt de nya kraven eller för att göra en snöflinga.

Min rapport handlar om mönster i Terraform för att bekämpa kaos och manuell rutin på stora och långa projekt.

videor:

Jag är 40, jag har jobbat med IT i 20 år. Jag har arbetat på Ixtens i 12 år. Vi är engagerade i e-handelsdriven utveckling. Och jag har praktiserat DevOps-övningar i 5 år.

Min berättelse kommer att handla om upplevelsen i ett projekt i ett företag vars namn jag inte kommer att säga, gömmer sig bakom ett sekretessavtal.

Siffrorna på bilden ges för att förstå omfattningen av projektet. Och allt jag ska säga härnäst är relaterat till Amazon.

Jag gick med i detta projekt för 4 år sedan. Och omstruktureringen av infrastrukturen var i full gång, eftersom projektet hade växt. Och de där mönstren som användes, de passar inte längre. Och med tanke på all planerad tillväxt av projektet var det nödvändigt att komma med något nytt.

Tack till Matvey, som berättade igår vad som hände på Dodo Pizza. Detta är vad som hände oss för 4 år sedan.

Utvecklare kom och började göra infrastrukturkod.

De mest uppenbara anledningarna till att detta krävdes var time to market. Det var nödvändigt att se till att DevOps-teamet inte var en flaskhals vid utrullningen. Och bland annat användes Terraform och Puppet på den allra första nivån.

Terraform är ett open source-projekt från HashiCorp. Och för de som inte alls vet vad det är, de kommande bilderna.

Infrastruktur som kod innebär att vi kan beskriva vår infrastruktur och be några robotar att se till att vi får de resurser som vi beskrev.

Till exempel behöver vi en virtuell maskin. Vi kommer att beskriva, lägga till några nödvändiga parametrar.

Efter det kommer vi att konfigurera åtkomst till Amazon i konsolen. Och fråga efter Terraform-plan. Terraform plan kommer att säga: "Ok, för din resurs, vi kan göra dessa saker." Och minst en resurs kommer att läggas till. Och inga förändringar förväntas.

Efter att allt passar dig kan du be Terraform ansöka så skapar Terraform en instans åt dig, och du får en virtuell maskin i ditt moln.

Vidare utvecklas vårt projekt. Vi lägger till några ändringar där. Vi ber om fler instanser, vi lägger till 53 poster.

Och vi upprepar. Planera gärna. Vi ser vilka förändringar som planeras. Tillämpa. Och så växer vår infrastruktur.

Terraform använder något sådant som tillståndsfiler. Det vill säga, den sparar alla ändringar som går till Amazon i en fil, där det för varje resurs som du beskrev finns motsvarande resurser som skapades i Amazon. När man ändrar beskrivningen av en resurs vet Terraform alltså exakt vad som behöver ändras i Amazon.

Dessa tillståndsfiler var ursprungligen bara filer. Och vi lagrade dem i Git, vilket var extremt obekvämt. Ständigt glömde någon att begå förändringar, och det var många konflikter.

Nu är det möjligt att använda backend, det vill säga Terraform anges i vilken hink, med vilken nyckel tillståndsfilen ska sparas. Och Terraform kommer själv att ta hand om den här tillståndsfilen, göra all magin och lägga tillbaka det slutliga 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 låter dig göra en sådan sak som en modul, dvs beskriva samma sak i någon mapp.

Och, till exempel, i testning, ring den här modulen och få samma sak som om vi skulle göra Terraform-applicering i själva modulen. Här är koden för att testa.

För produktion kan vi skicka några ändringar dit, för i tester behöver vi inte stora instanser, i produktion kommer stora instanser att komma till nytta.

Och så ska jag gå tillbaka till projektet. Det var en svår uppgift, infrastrukturen var planerad mycket stor. Och det var nödvändigt att på något sätt placera all kod så att den skulle vara bekväm för alla: för dem som utför underhåll på den här koden och för dem som gör ändringar. Och det var planerat att vilken utvecklare som helst kunde gå och fixa infrastrukturen efter behov för hans del av plattformen.

Detta är ett katalogträd som rekommenderas av HashiCorp om du har ett stort projekt och det är vettigt att dela upp hela infrastrukturen i några små bitar, och beskriva varje del i en separat mapp.

Med ett omfattande resursbibliotek kan du ringa ungefär samma sak i testning och i produktion.

I vårt fall var detta inte helt lämpligt, eftersom teststacken för utvecklare eller för testning behövde fås på något sätt enklare. Och jag ville inte gå igenom mapparna och ansöka i rätt ordning och oroa mig för att basen skulle stiga, och då skulle instansen som använder den här basen stiga. Därför startade all testning från en mapp. Samma moduler kallades dit, men allt gick igenom i en körning.

Terraform tar hand om alla beroenden. Och det skapar alltid resurser i den sekvensen så att du kan få en IP-adress, till exempel från en nyskapad instans, och få denna IP-adress i route53-posten.

Dessutom är plattformen väldigt stor. Och att köra en teststack, även om det är i en timme, även om det är i 8 timmar, är en ganska dyr affär.

Och vi har automatiserat den här verksamheten. Och Jenkins-jobbet lät stacken springa. Det var nödvändigt att lansera en pull-begäran i den med de ändringar som utvecklaren vill testa, ange alla nödvändiga alternativ, komponenter och storlekar. Om han vill ha prestationstestning kan han ta fler instanser. Om han bara behöver kontrollera att någon blankett öppnas kan han börja på minimilönen. Och ange även om ett kluster behövs eller inte, etc.

Och sedan tryckte Jenkins ett skalskript som ändrade koden något i Terraform-mappen. Tog bort onödiga filer, la till nödvändiga filer. Och sedan, med en körning av Terraform applicering, steg stapeln.

Och så fanns det andra steg som jag inte vill gå in på.

På grund av att vi för testning behövde lite fler alternativ än i produktionen, var vi tvungna att göra kopior av modulerna så att vi i dessa kopior kunde lägga till de funktioner som bara behövs vid testning.

Och det hände så att i testning verkar det som att du vill testa de förändringar som så småningom kommer att gå till produktion. Men i själva verket testades en sak, och lite annorlunda användes i produktionen. Och det blev ett litet brott i mönstret att i produktionen tillämpades alla förändringar av driftteamet. Och ibland visade det sig att de förändringarna som var tänkta att gå från testning till produktion, de förblev i en annan version.

Dessutom var det ett sådant problem att en ny tjänst lades till, som skilde sig något från någon befintlig. Och istället för att modifiera en befintlig modul, var du tvungen att göra en kopia av den och lägga till nödvändiga ändringar.

Faktum är att Terraform inte är ett riktigt språk. Detta är en förklaring. Om vi ​​behöver deklarera något, då deklarerar vi det. Och allt fungerar.

Vid något tillfälle, när jag diskuterade en av mina pull-förfrågningar, sa en av mina kollegor att det inte är nödvändigt att producera snöflingor. Jag undrade vad han menade. Det finns ett sådant vetenskapligt faktum att det inte finns två identiska snöflingor i världen, de är alla något, men olika. Och så fort jag hörde detta kände jag omedelbart den fulla vikten av Terraform-koden. För när det krävdes att gå från version till version krävde Terraform ett brytande kedjebyte, d.v.s. koden var inte längre kompatibel med nästa version. Och jag var tvungen att göra en pull-förfrågan, som täckte nästan hälften av filerna i infrastrukturen, för att få infrastrukturen till nästa version av Terraform.

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

För en extern utvecklare som är utanför drift spelar det ingen större roll för honom, eftersom han gjorde en pull-förfrågan, hans resurs startade. Och det är det, det är inte hans angelägenhet. Och DevOps-teamet som ser till att allt är OK måste göra alla dessa ändringar. Och kostnaden för dessa förändringar ökade väldigt, väldigt mycket för varje ytterligare snöflinga.

Det finns en berättelse om hur en student på ett seminarium ritar två perfekta cirklar med krita på en svart tavla. Och läraren är förvånad över hur han lyckades rita så smidigt utan kompass. Eleven svarar: "Det är väldigt enkelt, jag gjorde en köttkvarn i två år i armén."

Och av de fyra år som jag har varit på det här projektet har jag gjort Terraform i ungefär två år. Och självklart har jag några knep, några tips på hur man förenklar Terraform-koden, arbetar med den som ett programmeringsspråk och minskar bördan för utvecklare som måste hålla den här koden uppdaterad.

Det första jag skulle vilja börja med är Symlinks. Terraform har mycket repetitiv kod. Till exempel är det samma sak att ringa en leverantör vid nästan varje punkt där vi skapar en del av infrastrukturen. Och det är logiskt att lägga det i en separat pappa. Och varhelst leverantören krävs för att skapa symboliska länkar till den här filen.

Till exempel använder du anta roll i produktionen, vilket gör att du kan få åtkomsträttigheter till något externt Amazon-konto. Och genom att ändra en fil kommer alla de återstående som finns i resursträdet att ha de nödvändiga rättigheterna så att Terraform vet vilket Amazon-segment som ska komma åt.

Där symlänkar inte fungerar? Terraform har som sagt tillståndsfiler. Och de är väldigt, väldigt coola. Men faktum är att Terraform initierar backend i den allra första. Och han kan inte använda några variabler i dessa parametrar, de måste alltid skrivas i text.

Och som ett resultat, när någon skapar en ny resurs, kopierar han en del av koden från andra mappar. Och han kan göra ett misstag med nyckeln eller med hinken. Till exempel gör han en sandlådesak av en sandlåda och gör den sedan i produktion. Och så kan det visa sig att hinken i produktion kommer att användas från sandlådan. Naturligtvis hittar de det snabbt. Det kommer att gå att fixa detta på något sätt, men det är ändå slöseri med tid och i viss mån resurser.

Vad kan vi göra härnäst? Innan du arbetar med Terraform måste du initiera den. Vid tidpunkten för initieringen laddar Terraform ner alla plugins. Vid något tillfälle bröt de från en monolit till en mer mikrotjänstarkitektur. Och du behöver alltid göra Terraform init så att den drar upp alla moduler, alla plugins.

Och du kan använda ett skalskript, som för det första kan få alla variabler. Shell-skriptet är obegränsat. Och, för det andra, vägen. Om vi ​​alltid använder sökvägen som finns i förvaret som nyckel till tillståndsfilen, kommer därför felet att uteslutas här.

Var får man tag i data? JSON-fil. Terraform låter dig skriva infrastruktur inte bara i hcl (HashiCorp Configuration Language), utan också i JSON.

JSON är lätt att läsa från ett skalskript. Följaktligen kan du lägga en konfigurationsfil med en hink på någon plats. Och använd denna hink både i Terraform-koden och i skalskriptet för initiering.

Varför är det viktigt att ha en Terraform hink? För det finns något sådant som fjärrtillståndsfiler. Det vill säga, när jag skaffar någon resurs, för att säga till Amazon: "Vänligen höj instans", måste jag ange många nödvändiga parametrar.

Och dessa identifierare lagras i någon annan mapp. Och jag kan ta det och säga: "Terraform, snälla kör till tillståndsfilen för just den resursen och skaffa mig dessa identifierare." Och därmed finns det ett slags enande mellan olika regioner eller miljöer.

Det är inte alltid möjligt att använda en fjärrtillståndsfil. Till exempel skapade du en VPC manuellt. Och Terraform-koden som skapar VPC:n skapar en så annorlunda VPC att det tar väldigt lång tid och du måste anpassa den ena till den andra, så du kan använda följande knep.

Det vill säga att göra en modul som så att säga gör VPC och ger dig identifierare, men i själva verket finns 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 tillståndsfilen i molnet. Till exempel, när du testar moduler, kan du använda backend-initiering, när filen kommer att sparas bara på disken vid testtillfället.

Nu lite om att testa. Vad kan testas i Terraform? Förmodligen är mycket möjligt, men jag kommer att prata om dessa 4 saker.

HashiCorp har en förståelse för hur man formaterar Terraform-kod. Och Terraform fmt låter dig formatera koden du redigerar enligt den övertygelsen. Följaktligen måste testerna med nödvändighet kontrollera om formateringen stämmer överens med vad HashiCorp testamenterade, så att du inte behöver ändra placeringen av parenteser etc.

Nästa är Terraform validate. Det gör lite mer än en syntaxkontroll - ala, är alla parenteser parade. Vad är viktigt här? Vi har en väldigt tunn infrastruktur. Den har många olika mappar. Och i varje måste du köra Terraform-validering.

För att påskynda testningen kör vi därför flera processer parallellt med parallellt.

Parallell är en väldigt cool sak, använd den.

Men varje gång Terraform initieras går det till HashiCorp och frågar: "Vilka är de senaste plugins? Och plugin som jag har i cachen - är det den eller inte den? Och det saktade ner för varje steg.

Om Terraform berättar var plugin-programmen finns, kommer Terraform att säga: "OK, det här är förmodligen det färskaste som finns. Jag går ingenstans, jag börjar validera din Terraform-kod direkt."

För att fylla mappen med nödvändiga plugins har vi en väldigt enkel Terraform-kod som bara behöver initieras. Här måste du naturligtvis ange alla leverantörer som på något sätt deltar i din kod, annars kommer Terraform att säga: "Jag känner inte till någon leverantör, eftersom den inte finns i cachen."

Nästa är Terraform-planen. Utvecklingen är som sagt cyklisk. Vi gör kod med ändringar. Och sedan måste du ta reda på vilka förändringar som planeras för infrastrukturen.

Och när infrastrukturen är väldigt, väldigt stor, kan du byta en modul, fixa någon testmiljö eller någon specifik region och bryta någon intilliggande. Därför bör en Terraform-plan göras för hela infrastrukturen och visa vilka förändringar som planeras.

Du kan göra det på ett smart sätt. Till exempel skrev vi ett Python-skript som löser beroenden. Och beroende på vad som har ändrats: en Terraform-modul eller bara en specifik komponent, gör den planer för alla beroende mappar.

Terraformplan ska göras på begäran. Det är åtminstone vad vi gör.

Tester är naturligtvis bra att göra för varje förändring, för varje commit, men planer är ganska dyrt. Och vi säger i pull-förfrågan: "Snälla ge mig planerna." Roboten startar. Och skickar till kommentarer eller för att bifoga alla planer som förväntas av dina ändringar.

Planen är en ganska dyr sak. Det tar tid eftersom Terraform går till Amazon och frågar: "Finns den här instansen fortfarande? Har denna autoskalning exakt samma parametrar?”. Och för att påskynda det kan du använda en parameter som refresh=false. Detta innebär att Terraform kommer att tömma S3-tillståndet. Och kommer att tro att staten exakt kommer att matcha vad som finns i Amazon.

En sådan Terraform-plan är mycket snabbare, men staten måste matcha din infrastruktur, det vill säga någonstans, någon gång måste Terraform-uppdateringen börja. Terraform refresh gör precis det, så att staten matchar det som finns i den verkliga infrastrukturen.

Och jag måste säga om säkerheten. Det var här det borde ha börjat. 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 princip kod. Och om pull-begäran innehåller någon form av skadlig kod, kan den köras på en infrastruktur som har för mycket åtkomst. Var därför försiktig med var du lanserar Terraform-planen.

Nästa sak jag skulle vilja prata om är testning av användardata.

Vad är användardata? I Amazon, när vi skapar en instans kan vi skicka något slags brev från instansen – metadata. När en instans startas är cloud init vanligtvis alltid närvarande på dessa instanser. Cloud init läser detta brev och säger: "OK, idag är jag en lastbalanserare." Och i enlighet med dessa föreskrifter utför han några handlingar.

Men tyvärr, när vi använder Terraform-planen och Terraform tillämpar, ser användardata ut som den här uppslamningen av siffror. Det vill säga, han skickar bara en hash till dig. 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 du inte uppmärksammar detta, kan någon slagen textfil gå till Amazon, till den verkliga infrastrukturen.

Alternativt kan du ange inte hela infrastrukturen under körningen, utan endast mallen. Och säg i koden: "Visa den här mallen åt mig." Och som ett resultat kan du få en utskrift av hur din data kommer att se ut på Amazon.

Ett annat alternativ är att använda en modul för att generera användardata. Du kommer att tillämpa denna modul. Hämta filen på disken. Jämför det med referensen. Och därför, om någon jun bestämmer sig för att fixa lite användardata, kommer dina tester att säga: "OK, det finns några ändringar här och där - det här är normalt."

Nästa sak jag skulle vilja prata om är Automate Terraform application.

Naturligtvis är det skrämmande nog att använda Terraform i automatiskt läge, för vem vet vilka förändringar som har kommit där och hur skadliga de kan vara för en levande infrastruktur.

För en testmiljö är allt bra. Det vill säga ett jobb som skapar en testmiljö är vad alla utvecklare behöver. Och ett sådant uttryck som "allt fungerade för mig" är inte ett roligt meme, utan ett bevis på att en person blev förvirrad, höjde en stack, startade några tester på denna stack. Och han såg till att allt var bra där och sa: "OK, koden som jag släpper har testats."

I produktion, sandlåda och andra miljöer som är mer affärskritiska är det säkert att delvis använda vissa resurser eftersom det inte får någon att dö. Dessa är: autoskala grupper, säkerhetsgrupper, roller, route53 och där kan listan vara ganska stor. Men håll ett öga på vad som händer, läs rapporter om automatiserade applikationer.

Där det är farligt eller läskigt att använda, till exempel om det är några beständiga resurser, från en databas, få då rapporter om att det finns otillämpade ändringar i någon del av infrastrukturen. Och ingenjören är redan övervakad att köra jobb för att ansöka eller göra det från sin konsol.

Amazon har en sådan sak som Terminate-skydd. Och det kan i vissa fall skydda mot ändringar som inte krävs för dig. Så Terraform gick till Amazon och sa "Jag måste döda den här instansen för att göra en till". Och Amazon säger: "Tyvärr, inte idag. Vi har Terminate-skydd."

Och grädden på moset är kodoptimering. När vi arbetar med Terraform-kod måste vi skicka ett mycket stort antal parametrar till modulen. Det är de parametrar som är nödvändiga för att skapa någon form av resurs. Och koden förvandlas till stora listor med parametrar som måste skickas från modul till modul, från modul till modul, speciellt om modulerna är kapslade.

Och det är väldigt svårt att läsa. Det är väldigt svårt att granska detta. Och väldigt ofta visar det sig att vissa parametrar ses över och det är inte riktigt de som behövs. Och det kostar tid och pengar att fixa det senare.

Därför föreslår jag att du använder en sådan sak som en komplex parameter som inkluderar ett visst värdeträd. Det vill säga, du behöver någon form av mapp där du har alla värden som du skulle vilja ha på någon form av miljö.

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

I den här modulen kan du göra några beräkningar med hjälp av en så fräsch funktion i Terraform som lokalbefolkningen. Och sedan i en utgång, utfärda någon form av komplex parameter, som kan inkludera hash, arrayer, etc.

På detta, alla de bästa fynden som jag har avslutat. Och jag skulle vilja berätta en historia om Columbus. När han letade efter pengar för sin expedition för att upptäcka Indien (som han trodde då) var det ingen som trodde på honom och trodde att det var omöjligt. Då sa han: "Se till att ägget inte faller." Alla bankirer, mycket rika och förmodligen smarta människor, försökte lägga ägget på något sätt, och det föll hela tiden. Sedan tog Columbus ägget, tryckte lite på det. Skalet skrynklades och ägget förblev orörligt. De sa: "Åh, det är för lätt!" Och Columbus svarade: "Ja, det är för enkelt. Och när jag öppnar Indien kommer alla att använda den här handelsvägen.”

Och det jag just har berättat för er är förmodligen ganska enkla och triviala saker. Och när du får reda på dem och börjar använda dem är det i sin ordning. Så använd den. Och om det här är ganska normala saker för dig, så vet du åtminstone hur man lägger ett ägg så att det inte faller.

Låt oss sammanfatta:

• Försök att undvika snöflingor. Och ju färre snöflingor, desto färre resurser behöver du för att göra ändringar i hela din stora infrastruktur.
• Ständig förändring. Det vill säga, när vissa ändringar har skett i koden måste du bringa din infrastruktur i linje med dessa ändringar så snart som möjligt. Det borde inte finnas en situation när någon kommer om två eller tre månader för att titta på Elasticsearch, gör en Terraform-plan och det finns många förändringar som han inte förväntade sig. Och det tar mycket tid att få allt i ordning igen.
• Tester och automatisering. Ju mer din kod är täckt med tester och marker, desto mer förtroende har du för att du gör allt rätt. Och automatisk leverans kommer att öka ditt självförtroende många gånger om.
• Koden för test- och produktionsmiljön bör vara nästan densamma. Rent praktiskt, för trots allt är produktionen lite annorlunda och det kommer fortfarande att finnas en del nyanser som kommer att gå bortom testmiljön. Men ändå, plus eller minus det kan tillhandahållas.
• Och om du har mycket Terraform-kod och det tar mycket tid att hålla den här koden uppdaterad, då är det aldrig för sent att omstrukturera och få den i god form.

• oföränderlig infrastruktur. AMI leverans enligt schema.
• Struktur för route53 när du har många poster och vill att de ska vara i en konsekvent ordning.
• Kämpa mot API-hastighetsgränser. Det är när Amazon säger, "Det är allt, jag kan inte acceptera några fler förfrågningar, vänligen vänta." Och hälften av kontoret väntar tills det kan lansera sin infrastruktur.
• upptäcka instanser. Amazon är inget billigt evenemang och platser gör att du kan spara en hel del. Och där kan du berätta en hel rapport om det.
• Säkerhets- och IAM-roller.
• Sök efter förlorade resurser, när du har instanser av okänt ursprung i Amazone äter de pengar. Även om instanser kostar 100-150 USD per månad är det mer än 1 000 USD per år. Att hitta sådana resurser är en lukrativ affär.
• Och reserverade instanser.

Det var allt för mig. Terraform är väldigt cool, använd den. Tack!

frågor

Tack för rapporten! Du har en tillståndsfil i S3, men hur löser du problemet med att flera personer kan ta den här tillståndsfilen och försöka distribuera?

För det första har vi inte bråttom. För det andra finns det flaggor, där vi rapporterar att vi arbetar med någon kod. Det vill säga, trots att infrastrukturen är väldigt stor betyder det inte att någon ständigt använder något. Och när det var en aktiv fas var detta ett problem, vi behöll tillståndsfiler i Git. Detta var viktigt, annars skulle någon göra en tillståndsfil, och vi var tvungna att manuellt samla dem i en hög för att kunna fortsätta vidare. Nu finns det inget sådant problem. I allmänhet löste Terraform detta problem. Och om något ständigt förändras, då kan du använda lås som förhindrar det du sagt.

Använder du öppen källkod eller företag?

Inget företag, det vill säga allt du kan gå och ladda ner gratis.

Jag heter Stanislav. Jag ville göra ett litet tillägg. Du pratade om Amazon-funktionen som låter dig göra en instans oavdödlig. Detta är också i själva Terraform, i Life Second-blocket kan du föreskriva ett förbud mot förändring, eller ett förbud mot förstörelse.

Var tidsbegränsad. Bra poäng.

Jag ville också fråga två saker. Först pratade du om att testa. Har du använt några testverktyg? Jag hörde talas om testkökets plugin. Kanske finns det något annat. Och jag skulle vilja fråga om lokala värderingar. Hur skiljer de sig i princip från indatavariabler? Och varför kan jag inte parametrisera något bara genom lokala värderingar? Jag försökte ta itu med det här ämnet, men på något sätt kom jag inte på det själv.

Vi kan prata mer i detalj bakom den här hallen. Testverktyg är vår kompletta egentillverkade. Det finns inget att testa där. Generellt finns det alternativ när automatiska tester höjer infrastrukturen någonstans, kontrollera att den är OK och sedan förstöra allt med en rapport om att din infrastruktur fortfarande är i bra skick. Det har vi inte eftersom teststackarna går varje dag. Och det räcker. Och om något börjar gå sönder så börjar det gå sönder utan att vi kollar det någon annanstans.

När det gäller lokala värderingar, låt oss fortsätta samtalet utanför publiken.

Hallå! Tack för rapporten! Mycket informativt. Du sa att du har mycket av samma typ av kod för att beskriva infrastrukturen. Har du funderat på att generera den här koden?

Bra fråga, tack! Poängen är att när vi använder infrastruktur som kod, antar vi att vi tittar på koden och förstår vilken typ av infrastruktur som ligger bakom denna kod. Om koden genereras måste vi föreställa oss vilken kod som kommer att genereras för att förstå vilken typ av infrastruktur som kommer att finnas där. Eller så genererar vi koden, begår den och i själva verket får vi samma sak. Därför gick vi som vi skrev, vi fick det. Dessutom dök det upp generatorer lite senare, när vi började tillverka. Och det var för sent att byta.

Har du hört talas om jsonnet?

Nej.

Titta, det här är riktigt coola grejer. Jag ser ett specifikt fall där du kan tillämpa det och generera en datastruktur.

Generatorer är bra när man har dem, som i skämtet om rakmaskinen. Det vill säga första gången är ansiktet annorlunda, men då har alla samma ansikte. Generatorerna är väldigt coola. Men tyvärr är våra ansikten lite annorlunda. Det är problem.

Bara kolla. Tack!

Jag heter Maxim, jag kommer från Sberbank. Du sa lite att du försökte föra Terraform till en analog av ett programmeringsspråk. Är det inte lättare att använda Ansible?

Det här är väldigt olika saker. Ansible kan skapa resurser och Puppet kan skapa resurser i Amazon. Men Terraform är rent ut sagt skärpt.

Har du bara Amazon?

Det är inte så att vi bara har Amazon. Vi har nästan bara Amazon. Men nyckelfunktionen är att Terraform minns. I Ansible, om du säger: "Hämta mig 5 instanser", kommer det att höjas, och sedan säger du: "Och nu behöver jag 3". Och Terraform kommer att säga: "Ok, jag dödar 2", och Ansible kommer att säga: "Ok, här är 3 för dig." Totalt 8.

Hallå! Tack för din rapport! Det var väldigt intressant att höra om Terraform. Jag vill bara göra en liten kommentar om att Terraform fortfarande inte har en stabil release, så var väldigt försiktig med Terraform.

Fin sked till middag. Dvs behöver man en lösning så skjuter man ibland upp det som är instabilt osv, men det fungerar och hjälpte oss.

Frågan är. Du använder fjärrbackend, du använder S 3. Varför använder du inte den officiella backend?

Officiell?

Terraform moln.

När dök han upp?

4 månader sedan.

Om det hade dykt upp för 4 år sedan skulle jag förmodligen ha svarat på din fråga.

Det finns redan en inbyggd funktion och lås, och du kan lagra en tillståndsfil. Försök. Men jag har inte testat heller.

Vi sitter på ett stort tåg som rör sig i hög hastighet. Och du kan inte bara ta och kasta ut några bilar.

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

Vi har ett sådant synsätt att hela infrastrukturen finns i ett förvar. Terraform, Puppet, alla skript som på något sätt relaterar till detta, de finns alla i ett arkiv. På så sätt kan vi säkerställa att inkrementella ändringar testas en efter en. Om det vore ett gäng grenar skulle ett sådant projekt vara nästan omöjligt att underhålla. Sex månader går och de skiljer sig så mycket att det bara är någon form av straff. Det här var vad jag ville fly ifrån innan omfaktorn.

dvs det fungerar inte?

Det fungerar inte alls.

I gren klippte jag ut mappbilden. Det vill säga, om du gör för varje teststack, till exempel, lag A har sin egen pappa, lag B har sin egen pappa, då fungerar inte detta heller. Vi gjorde en enhetlig testmiljökod som var tillräckligt flexibel för att passa alla. Det vill säga vi serverade en kod.

Hallå! Jag heter Yura! Tack för rapporten! Fråga om moduler. Du säger att du använder moduler. Hur löser du problemet om ändringar gjordes i en modul som inte är kompatibla med bytet av en annan person? På något sätt versionera moduler eller försöka få ett underbarn att uppfylla två krav?

Detta är det stora problemet med snöhögen. Det är detta vi lider av när någon ofarlig förändring kan bryta någon del av infrastrukturen. Och det kommer att märkas först efter en lång tid.

Dvs det är inte bestämt än?

Du gör universella moduler. Undvik snöflingor. Och allt kommer att ordna sig. Den andra halvan av rapporten handlar om hur man undviker det.

Hallå! Tack för rapporten! Jag skulle vilja förtydliga. Bakom kulisserna fanns en stor hög, som jag kom för. Hur är Puppet och rollfördelning integrerade?

användardata.

Det vill säga, spottar du bara ut filen och kör på den på något sätt?

Användardata är en anteckning, det vill säga när vi gör en bildklon, då reser sig Daemon där och försöker ta reda på vem han är, läser en anteckning om att han är en lastbalanserare.

Det vill säga är det någon form av separat process som ges bort?

Vi uppfann det inte. Vi använder det.

Hallå! Jag har bara en fråga om User - data. Du sa att det finns problem där, att någon kan skicka något till fel ställe. Finns det något sätt att lagra användardata i samma Git, så att det alltid är tydligt vad User-data syftar på?

Vi genererar användardata från mall. Det vill säga att ett visst antal variabler tar till där. Och Terraform genererar slutresultatet. Därför kan du inte bara titta på mallen och säga vad som händer, eftersom alla problem är relaterade till det faktum att utvecklaren tror att han passerar en rad i denna variabel, och sedan används en array. Och han – pang och jag – så och så, så och så, nästa rad, och allt gick sönder. Om det här är en ny resurs och en person tar upp den, ser att något inte fungerar, så löses detta snabbt. Och om den här autoskalningsgruppen har uppdaterats, börjar instanserna i autoskalningsgruppen någon gång att ersättas. Och klapp, något fungerar inte. Det gör ont.

Det visar sig att den enda lösningen är att testa?

Ja, du ser problemet, du lägger till teststeg där. Det vill säga, output'om kan också testas. Kanske inte så bekvämt, men du kan också sätta några märken - kontrollera att User-data är spikad här.

Jag heter Timur. Det är väldigt häftigt att det finns rapporter om hur man organiserar Terraform på rätt sätt.

Jag började inte ens.

Jag tror att det kanske blir det i nästa konferens. Jag har en enkel fråga. Varför hårdkodar du värdet i en separat modul istället för att använda tfvars, d.v.s. är en modul med värden bättre än tfvars?

Det vill säga, jag borde skriva här (bild: Produktion/miljö/inställningar.tf): domän = variabel, domän vpcnetwork, vpcnetwork variabel och stvars - får du samma sak?

Vi gör precis det. Vi hänvisar till exempel till inställningskällmodulen.

I själva verket är detta en sådan tfvars. Tfvars är väldigt praktiskt i en testmiljö. Jag har tfvar för stora instanser, för små. Och jag slängde en fil i mappen. Och fick som jag ville. När vi såg infrastruktur vill vi kunna se och omedelbart förstå allt. Och så visar det sig att du måste titta här, sedan titta i tfvars.

Det visar sig att allt var på ett ställe?

Ja, tfvars är när du har en kod. Och den används på flera olika ställen med olika nyanser. Då skulle du kasta tfvars och få dina nyanser. Och vi är infrastruktur som kod i sin renaste form. Tittade och förstod.

Hallå! Har du stött på situationer där molnleverantören stör det du har gjort med Terraform? Låt oss säga att vi redigerar metadata. Det finns ssh-nycklar. Och Google skjuter ständigt in sin metadata, sina nycklar där. Och Terraform skriver alltid att det har förändringar. Efter varje körning, även om ingenting förändras, säger han alltid att han kommer att uppdatera det här fältet nu.

Med nycklar, men – ja, en del av infrastrukturen påverkas av något sådant, d.v.s. Terraform kan inte ändra någonting. Vi kan inte ändra något med händerna heller. Så länge vi lever med det.

Det vill säga, du stötte på det här, men kom inte på någonting, hur gör han det och gör det själv?

Tyvärr, ja.

Hallå! Jag heter Stanislav Starkov. Post. sv Grupp. Hur löser man problemet med att generera en tagg på ..., hur skickar man in den? Som jag förstår det, genom Användare - data, för att ange värdnamnet, hetsa Puppet? Och den andra delen av frågan. Hur löser man det här problemet i SG, d.v.s. när man genererar SG, hundra instanser av samma typ, hur namnger man dem korrekt?

De fall som är mycket viktiga för oss kommer vi att namnge dem vackert. De som inte behövs, det finns en postscript att detta är en autoscale-grupp. Och i teorin kan den spikas, och få en ny.

När det gäller problemet med taggen finns det inget sådant problem, men det finns en sådan uppgift. Och vi använder taggar väldigt, väldigt mycket, eftersom infrastrukturen är stor och dyr. Och vi måste titta på vad pengar spenderas på, så taggar låter oss reda ut vad och vart det tog vägen. Och följaktligen är sökandet efter något här mycket pengar som spenderas.

Vad handlade frågan om?

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

Nej, gör inte det. Varje instans har en agent som säger till mig att jag har ett problem. Om agenten rapporterar, då vet agenten om honom och åtminstone hans IP-adress existerar. Du kan redan springa. För det andra använder vi Consul for Discovery, där det inte finns någon Kubernetes. Och Consul visar också instansens IP-adress.

Det vill säga, du riktar in dig på exakt IP:n och inte värdnamnet?

Det är omöjligt att navigera efter värdnamn, det vill säga det finns många av dem. Det finns instansidentifierare - AE, etc. Du kan hitta den någonstans, du kan slänga in den i sökningen.

Hallå! Jag insåg att Terraform är en bra sak, skräddarsydd för molnen.

Inte bara.

Det är frågan som intresserar mig. Om du bestämmer dig för att flytta, säg, till Bare Metal en masse med alla dina instanser? Kommer det bli några problem? Eller måste du fortfarande använda andra produkter, till exempel samma Ansible som nämndes här?

Ansible handlar lite om något annat. Det vill säga, Ansible körs redan när instansen har startat. Och Terraform fungerar innan instansen har startat. Att byta till Bare Metal är det inte.

Inte nu, men affärer kommer och säger: "Kom igen."

Att byta till ett annat moln – ja, men det finns en lite annan funktion här. Du måste skriva Terraform-kod på ett sådant sätt att du kan byta till något annat moln med mindre blodsutgjutelse.

Inledningsvis var uppgiften att hela vår infrastruktur är agnostisk, d.v.s. alla moln ska vara bra, men någon gång gav verksamheten upp och sa: ”OK, under de kommande N åren kommer vi ingenstans, du kan använda tjänster från Amazon".

Terraform låter dig skapa Front-End-jobb, konfigurera PagerDuty, datadokument etc. Det har många svansar. Han kan praktiskt taget kontrollera hela världen.

Tack för rapporten! Jag har också snurrat Terraform i 4 år nu. I skedet av en smidig övergång till Terraform, till infrastruktur, till en deklarativ beskrivning, stod vi inför en situation där någon gjorde något för hand och du försökte göra en plan. Och jag fick ett fel där. Hur hanterar du sådana problem? Hur hittar du de förlorade resurserna som angavs?

Mestadels med händer och ögon, om vi ser något konstigt i rapporten, då analyserar vi vad som händer där, eller så dödar vi det. I allmänhet är pull-förfrågningar en vanlig sak.

Om det finns ett fel, återställer du? Har du testat att göra detta?

Nej, detta är ett beslut av en person i det ögonblick då han ser problemet.

Källa: will.com