Det ser ut til at Terraform-utviklere tilbyr ganske praktiske beste praksiser for å jobbe med AWS-infrastruktur. Det er bare en nyanse. Over tid øker antallet miljøer, hver med sine egne funksjoner. En nesten kopi av applikasjonsstabelen vises i naboregionen. Og Terraform-koden må kopieres og redigeres nøye i henhold til de nye kravene eller gjøres til et snøfnugg.
Min rapport om mønstre i Terraform for å bekjempe kaos og manuell rutine på store og lange prosjekter.
Video:
Jeg er 40, jeg har jobbet i IT i 20 år. Jeg har jobbet for Ixtens i 12 år. Vi er engasjert i e-handelsdrevet utvikling. Og jeg har praktisert DevOps-praksis i 5 år.
Min historie vil handle om min erfaring i et prosjekt i et selskap som jeg ikke vil si navnet på, gjemt bak en taushetserklæring.
Tallene på lysbildet er angitt for å forstå omfanget av prosjektet. Og alt jeg vil si neste er relatert til Amazon.
Jeg ble med i dette prosjektet for 4 år siden. Og omstruktureringen av infrastrukturen var i full gang fordi prosjektet hadde vokst. Og mønstrene som ble brukt var ikke lenger egnet. Og gitt all den planlagte veksten av prosjektet, var det nødvendig å finne på noe nytt.
Takk til Matvey, som i går fortalte oss hva som skjedde på Dodo Pizza. Dette er hva som skjedde her for 4 år siden.
Utviklere kom og begynte å lage infrastrukturkode.
De mest åpenbare årsakene til at dette var påkrevd var time to market. Det var nødvendig å sikre at DevOps-teamet ikke var en flaskehals under utrullingen. Og blant annet ble Terraform og Puppet brukt på aller første nivå.
Terraform er et åpen kildekode-prosjekt fra HashiCorp. Og for de som ikke engang vet hva dette er, de neste lysbildene.
Infrastruktur som kode betyr at vi kan beskrive infrastrukturen vår og be noen roboter sørge for at vi får ressursene som vi beskrev.
For eksempel trenger vi en virtuell maskin. Vi vil beskrive og legge til flere nødvendige parametere.
Etter dette vil vi konfigurere tilgang til Amazon i konsollen. Og vi vil be om Terraform-plan. Terraform-planen vil si: "Ok, vi kan gjøre disse tingene for ressursen din." Og minst én ressurs vil bli lagt til. Og det forventes ingen endringer.
Når du er fornøyd med alt, kan du be Terraform om å søke og Terraform vil lage en instans for deg, og du vil motta en virtuell maskin i skyen din.
Prosjektet vårt utvikler seg videre. Vi legger til noen endringer der. Vi ber om flere tilfeller, vi legger til 53 oppføringer.
Og vi gjentar. Vennligst planlegg. Vi ser hvilke endringer som er planlagt. Vi søker. Og det er slik vår infrastruktur vokser.
Terraform bruker noe som kalles tilstandsfiler. Det vil si at alle endringer som går til Amazon lagres i en fil hvor det for hver ressurs du beskrev, er tilsvarende ressurser som ble opprettet i Amazon. Dermed, når beskrivelsen av en ressurs endres, vet Terraform nøyaktig hva som må endres i Amazon.
Disse tilstandsfilene var opprinnelig bare filer. Og vi lagret dem i Git, noe som var ekstremt upraktisk. Noen glemte alltid å forplikte seg til endringer, og mange konflikter oppsto.
Nå er det mulig å bruke backend, dvs. Terraform er spesifisert i hvilken bøtte og med hvilken nøkkel tilstandsfilen skal lagres. Og Terraform vil selv ta seg av å få denne tilstandsfilen, gjøre all magien og legge tilbake det endelige resultatet.
Infrastrukturen vår vokser. Her er koden vår. Og nå vil vi ikke bare lage en virtuell maskin, vi vil ha et testmiljø.
Terraform lar deg lage noe som en modul, det vil si beskrive det samme i en mappe.
Og, for eksempel, i testing, kall denne modulen og få det samme som om vi hadde utført Terraform application i selve modulen. For testing vil det være denne koden.
For produksjon kan vi sende noen endringer dit, fordi i testing trenger vi ikke store forekomster; i produksjon er store forekomster bare nyttige.
Og så kommer jeg tilbake til prosjektet. Det var en vanskelig oppgave, den planlagte infrastrukturen var veldig stor. Og det var nødvendig å på en eller annen måte plassere all koden slik at den ville være praktisk for alle: både for de som utfører vedlikehold på denne koden og for de som gjør endringer. Og det var planlagt at enhver utvikler kunne gå og fikse infrastrukturen etter behov for sin del av plattformen.
Dette er et katalogtre som anbefales av HashiCorp selv hvis du har et stort prosjekt og det er fornuftig å dele opp hele infrastrukturen i noen små biter, og beskrive hver del i en egen mappe.
Med et omfattende bibliotek med ressurser, kan du kalle omtrent det samme i testing og i produksjon.
I vårt tilfelle var dette ikke helt egnet, fordi teststabelen for utviklere eller for testing måtte skaffes på en eller annen måte enklere. Men jeg ønsket ikke å gå gjennom mappene og bruke dem i den nødvendige rekkefølgen, og bekymre meg for at databasen ville stige, og så ville forekomsten som bruker denne databasen stige. Derfor ble all testing startet fra én mappe. De samme modulene ble kalt der, men alt ble gjort i ett løp.
Terraform tar seg av alle avhengighetene. Og den lager alltid ressurser i sekvensen slik at du kan få en IP-adresse, for eksempel fra en nyopprettet instans, og få denne IP-adressen i route53-posten.
I tillegg er plattformen veldig stor. Og å lansere en teststabel, selv om det er i en time, selv om det er i 8 timer, er ganske dyrt.
Og vi automatiserte denne saken. Og Jenkins jobb tillot oss å kjøre stabelen. I den var det nødvendig å starte en pull-forespørsel med endringene som utvikleren vil teste, spesifisere alle nødvendige alternativer, komponenter og dimensjoner. Hvis han vil ha ytelsestesting, kan han ta flere tilfeller. Hvis han bare trenger å sjekke at et skjema åpner seg, kan han begynne med minstelønn. Og angi også om en klynge er nødvendig eller ikke, etc.
Og så presset Jenkins et shell-script, som endret koden litt i Terraform-mappen. Jeg fjernet unødvendige filer og la til nødvendige filer. Og så med en kjøring med Terraform-påføring ble stabelen hevet.
Og så var det andre trinn jeg ikke vil gå inn på.
På grunn av det faktum at vi for testing trengte litt flere alternativer enn i produksjon, måtte vi lage kopier av modulene slik at vi i disse kopiene kunne legge til de funksjonene som bare var nødvendig for testing.
Og det har seg slik at i testing vil jeg på en måte teste de endringene som til slutt vil gå i produksjon. Men faktisk ble en ting testet, og en litt annen ble brukt i produksjonen. Og det var et lite brudd i mønsteret at i produksjonen ble alle endringer tatt i bruk av driftsteamet. Og noen ganger viste det seg at de endringene som skulle gå fra testing til produksjon forble i en annen versjon.
I tillegg var det et slikt problem at en ny tjeneste ble lagt til, som var litt forskjellig fra noen allerede eksisterende. Og i stedet for å endre en eksisterende modul, måtte vi lage en kopi av den og legge til de nødvendige endringene.
I hovedsak er ikke Terraform et ekte språk. Dette er en erklæring. Hvis vi trenger å erklære noe, så erklærer vi det. Og det hele fungerer.
På et tidspunkt, da en av mine pull-forespørsler ble diskutert, sa en av mine kolleger at det ikke var nødvendig å lage snøfnugg. Jeg lurte på hva han mente. Det er et vitenskapelig faktum at det ikke er to identiske snøfnugg i verden, de er alle litt forskjellige. Og så snart jeg hørte dette, kjente jeg umiddelbart hele vekten av Terraform-koden. For når det var nødvendig å gå fra versjon til versjon, krevde Terraform å bryte kjedeendringer, det vil si at koden ikke lenger var kompatibel med neste versjon. Og vi måtte lage en pull-forespørsel, som dekket nesten halvparten av filene i infrastrukturen, for å bringe infrastrukturen til neste versjon av Terraform.
Og etter at et slikt snøfnugg dukket opp, ble all Terraform-koden som vi hadde gjort om til en stor, stor haug med snø.
For en ekstern utvikler som er utenfor driften, betyr ikke dette mye for ham, fordi han kom med en pull-forespørsel, ressursen hans startet. Og det er alt, det er ikke hans bekymring lenger. Og DevOps-teamet, som sørger for at alt er OK, er pålagt å gjøre alle disse endringene. Og kostnadene for disse endringene økte veldig, veldig mye med hvert ekstra snøfnugg.
Det er en historie om hvordan en student på et seminar tegner to perfekte sirkler med kritt på tavlen. Og læreren er overrasket over hvordan han klarte å tegne så greit uten kompass. Studenten svarer: "Veldig enkelt, jeg brukte to år i hæren på å snu en kjøttkvern."
Og av de fire årene jeg har vært involvert i dette prosjektet, har jeg holdt på med Terraform i omtrent to år. Og selvfølgelig har jeg noen triks, noen råd om hvordan man kan forenkle Terraform-koden, jobbe med den som et programmeringsspråk og redusere byrden for utviklere som må holde denne koden oppdatert.
Det første jeg vil begynne med er Symlinks. Terraform har mye repeterende kode. For eksempel er samtalen til leverandøren på nesten hvert punkt der vi oppretter en del av infrastrukturen den samme. Og det er logisk å legge det i en egen mappe. Og uansett hvor leverandøren er pålagt å lage symbolkoblinger til denne filen.
For eksempel, i produksjon bruker du anta rolle, som lar deg få tilgangsrettigheter til en ekstern Amazon-konto. Og etter å ha endret én fil, vil alle de gjenværende i ressurstreet ha de nødvendige rettighetene slik at Terraform vet hvilket Amazon-segment de skal ha tilgang til.
Hvor mislykkes Symlinks? Terraform har som sagt statsfiler. Og de er veldig, veldig kule. Men saken er at Terraform initialiserer backend i første omgang. Og han kan ikke bruke noen variabler i disse parameterne, de må alltid skrives i tekst.
Og som et resultat, når noen lager en ny ressurs, kopierer han noe av koden fra andre mapper. Og han kan gjøre en feil med nøkkelen eller med bøtta. For eksempel lager han en sandkasseting av sandkasse, og lager den så i produksjon. Og slik kan det vise seg at bøtta i produksjon skal brukes fra sandkassen. Selvfølgelig vil de finne det raskt. Det vil være mulig å fikse dette på en eller annen måte, men likevel er det bortkastet tid og til dels ressurser.
Hva kan vi gjøre videre? Før du arbeider med Terraform, må du initialisere den. Ved initialisering laster Terraform ned alle plugins. På et tidspunkt delte de seg fra en monolitt til en mer mikrotjenestearkitektur. Og du må alltid gjøre Terraform init slik at den trekker opp alle modulene, alle pluginene.
Og du kan bruke et skallskript, som for det første kan få alle variablene. Shell-skriptet er ikke begrenset på noen måte. Og for det andre stiene. Hvis vi alltid bruker banen som er i depotet som nøkkelen til tilstandsfilen, vil følgelig feilen her bli eliminert.
Hvor kan jeg få dataene? JSON-fil. Terraform lar deg skrive infrastruktur ikke bare i hcl (HashiCorp Configuration Language), men også i JSON.
JSON er lett å lese fra et shell-skript. Følgelig kan du legge konfigurasjonsfilen med bøtte et sted. Og bruk denne bøtten både i Terraform-koden og i shell-skriptet for initialisering.
Hvorfor er det viktig å ha en bøtte til Terraform? Fordi det er noe slikt som eksterne tilstandsfiler. Det vil si, når jeg henter en ressurs, for å fortelle Amazon: "Vennligst hev forekomst," må jeg spesifisere mange nødvendige parametere.
Og disse identifikatorene er lagret i en annen mappe. Og jeg kan gå og si: "Terraform, vær så snill å løp til delstatsfilen til akkurat den ressursen og skaff meg disse identifikatorene." Og dermed oppstår en viss enhet mellom ulike regioner eller miljøer.
Det er ikke alltid mulig å bruke en ekstern tilstandsfil. For eksempel opprettet du en VPC for hånd. Og Terraform-koden som lager VPC-en lager så forskjellige VPC-er at det vil ta veldig lang tid og du må justere den ene til den andre, så du kan bruke følgende triks.
Det vil si, lag en modul som ser ut til å lage en VPC og, som det var, gir deg identifikatorer, men faktisk er det ganske enkelt en fil med hardkodede verdier som kan brukes til å lage den samme forekomsten.
Det er ikke alltid nødvendig å lagre tilstandsfilen i skyen. For eksempel, når du tester moduler, kan du bruke backend-initialisering, hvor filen rett og slett blir lagret på disk ved testtidspunktet.
Nå litt om testing. Hva kan du teste i Terraform? Sannsynligvis er mye mulig, men jeg skal snakke om disse 4 tingene.
HashiCorp har forståelse for hvordan Terraform-kode skal formateres. Og Terraform fmt lar deg formatere koden du redigerer i henhold til denne troen. Følgelig må tester nødvendigvis sjekke om formateringen samsvarer med det HashiCorp testamenterte, slik at det ikke er behov for å endre plassering av parentes osv.
Den neste er Terraform-validering. Det gjør lite mer enn å sjekke syntaksen - ala, om alle parenteser er sammenkoblet. Hva er viktig her? Infrastrukturen vår er svært omfattende. Det er mange forskjellige pappaer i den. Og i hver må du kjøre Terraform-validering.
Følgelig, for å øke hastigheten på testingen, kjører vi flere prosesser parallelt ved å bruke parallell.
Parallell er en veldig kul ting, bruk den.
Men hver gang Terraform initialiserer, går den til HashiCorp og spør: "Hva er de nyeste plugin-versjonene? Og plugin-modulen som jeg har i cachen – er den riktig eller feil?» Og dette avtok for hvert trinn.
Hvis du forteller Terraform hvor pluginene er, vil Terraform si: «Ok, dette er sannsynligvis det siste som er der. Jeg vil ikke gå noe sted, jeg vil umiddelbart begynne å validere Terraform-koden din."
For å fylle mappen med nødvendige plugins har vi en veldig enkel Terraform-kode som bare må initialiseres. Her må du selvfølgelig spesifisere alle leverandørene som på en eller annen måte deltar i koden din, ellers vil Terraform si: "Jeg kjenner ikke en bestemt leverandør fordi den ikke er i hurtigbufferen."
Neste er Terraform-planen. Utviklingen er som sagt syklisk. Vi gjør endringer i koden. Og så må du finne ut hvilke endringer som er planlagt for infrastrukturen.
Og når infrastrukturen er veldig, veldig stor, kan du endre én modul, fikse et testmiljø eller en bestemt region og bryte en nabo. Derfor bør Terraform-planen lages for hele infrastrukturen og vise hvilke endringer som planlegges.
Du kan gjøre dette smart. For eksempel skrev vi et Python-skript som løser avhengigheter. Og avhengig av hva som ble endret: en Terraform-modul eller bare en spesifikk komponent, legger den planer for alle avhengige mapper.
Terraformplaner skal lages på forespørsel. Det er i hvert fall det vi gjør.
Selvfølgelig er det bra å gjøre tester for hver endring, for hver forpliktelse, men planer er ganske dyrt. Og i en pull-forespørsel sier vi: "Vær så snill å gi meg planene." Roboten starter. Og sender inn kommentarer eller legger ved alle planene som forventes av endringene dine.
En plan er en ganske dyr ting. Det tar tid fordi Terraform går til Amazon og spør: «Eksisterer denne forekomsten fortsatt? Har denne autoskaleringen nøyaktig de samme parameterne?» Og for å få fart på dette, kan du bruke en parameter som refresh=false. Dette betyr at Terraform vil laste ned status fra S3. Og den vil tro at staten vil matche nøyaktig det som er i Amazon.
En slik Terraform-plan går mye raskere, men staten må samsvare med din infrastruktur, det vil si et sted, en gang må Terraform-oppdateringen starte. Terraform refresh gjør akkurat det: tilstand samsvarer med det som er i den faktiske infrastrukturen.
Og vi må snakke om sikkerhet. Det var her vi måtte begynne. Der du kjører Terraform og Terraform kjører på infrastrukturen din, er det en sårbarhet. Det vil si at du i hovedsak utfører koden. Og hvis pull-forespørselen inneholder en slags ondsinnet kode, kan den kjøres på en infrastruktur som har for mye tilgang. Så vær forsiktig hvor du kjører Terraform-planen.
Det neste jeg vil snakke om er testing av brukerdata.
Hva er brukerdata? I Amazon, når vi oppretter en instans, kan vi sende et bestemt brev med instansen – metadata. Når forekomsten starter, er vanligvis cloud init alltid til stede på disse forekomstene. Cloud init leser dette brevet og sier: «Ok, i dag er jeg lastbalanseren.» Og i samsvar med disse paktene utfører han noen handlinger.
Men, dessverre, når vi får Terraform-plan og Terraform til å gjelde, ser brukerdata ut som denne typen tall. Det vil si at han rett og slett sender deg hasjen. Og alt du kan se på i planen er om det blir noen endringer eller om hasjen forblir den samme.
Og hvis du ikke legger merke til dette, kan en ødelagt tekstfil ende opp på Amazon, på den virkelige infrastrukturen.
Alternativt, når du kjører, kan du spesifisere ikke hele infrastrukturen, men bare malen. Og i koden si: "Vennligst vis denne malen på skjermen min." Og som et resultat kan du få en utskrift av hvordan dataene dine vil se ut på Amazon.
Et annet alternativ er å bruke en modul til å generere brukerdata. Du skal bruke denne modulen. Du mottar filen på disk. Sammenlign det med referansen. Og dermed, hvis en fyr bestemmer seg for å korrigere brukerdataene litt, vil testene dine si: "OK, det er noen endringer her og der - dette er normalt."
Det neste jeg vil snakke om er Automate Terraform application.
Selvfølgelig er det ganske skummelt å bruke Terraform i automatisk modus, for hvem vet hvilke endringer som har kommet der og hvor ødeleggende de kan være for den levende infrastrukturen.
For et testmiljø er alt dette normalt. Det vil si at en jobb som skaper et testmiljø er det alle utviklere trenger. Og et uttrykk som "alt fungerte for meg" er ikke et morsomt meme, men et bevis på at en person ble forvirret, hevet en stabel og kjørte noen tester på denne stabelen. Og han sørget for at alt var bra der og sa: «Ok, koden jeg gir ut er testet.»
I produksjon, sandkasse og andre miljøer som er mer forretningskritiske, kan du delvis bruke noen ressurser ganske trygt fordi det ikke fører til at noen dør. Disse er: autoskaleringsgrupper, sikkerhetsgrupper, roller, route53, og listen der kan være ganske stor. Men hold øye med hva som skjer, les de automatiserte søknadsrapportene.
Der det er farlig eller skummelt å søke, for eksempel hvis dette er noen vedvarende ressurser fra en database, så motta rapporter om at det er ubrukte endringer i en del av infrastrukturen. Og ingeniøren, under tilsyn, starter jobber for å søke eller gjør det fra konsollen sin.
Amazon har noe slikt som Terminate-beskyttelse. Og det kan i noen tilfeller beskytte mot endringer som ikke er nødvendige for deg. Det vil si, Terraform gikk til Amazon og sa: "Jeg må drepe denne instansen for å lage en til." Og Amazon sier: «Beklager, ikke i dag. Vi har Terminate-beskyttelse."
Og prikken over i-en er kodeoptimalisering. Når vi jobber med Terraform-kode, må vi sende et veldig stort antall parametere til modulen. Dette er parametrene som er nødvendige for å skape en slags ressurs. Og koden blir til store lister over parametere som må sendes fra modul til modul, fra modul til modul, spesielt hvis modulene er nestet.
Og det er veldig vanskelig å lese. Det er veldig vanskelig å anmelde dette. Og veldig ofte viser det seg at noen parametere gjennomgår en vurdering, og de er ikke akkurat det som trengs. Og dette koster tid og penger å fikse senere.
Derfor foreslår jeg at du bruker noe slikt som en kompleks parameter som inkluderer et visst tre med verdier. Det vil si at du trenger en slags mappe hvor du har alle verdiene du vil ha i et eller annet miljø.
Og ved å kalle denne modulen kan du få et tre som er generert i én felles modul, altså i en felles modul som fungerer likt for hele infrastrukturen.
I denne modulen kan du gjøre noen beregninger ved å bruke en så fersk funksjon i Terraform som lokalbefolkningen. Og så, med én utgang, gi en kompleks parameter, som kan inkludere array-hasher, etc.
Det er her alle de beste funnene jeg har endt. Og jeg vil gjerne fortelle en historie om Columbus. Da han lette etter penger til ekspedisjonen for å oppdage India (som han trodde da), var det ingen som trodde på ham, og de trodde det var umulig. Så sa han: "Pass på at egget ikke faller." Alle bankfolk, veldig rike og sannsynligvis smarte mennesker, prøvde på en eller annen måte å plassere egget, og det fortsatte å falle. Så tok Columbus egget og presset det litt. Skallet krøllet sammen og egget forble urørlig. De sa: "Å, det er for lett!" Og Columbus svarte: "Ja, det er for enkelt. Og når jeg åpner India, vil alle bruke denne handelsruten."
Og det jeg nettopp fortalte deg er sannsynligvis ganske enkle og trivielle ting. Og når du lærer om dem og begynner å bruke dem, er det i rekkefølgen av tingene. Så dra nytte. Og hvis dette er helt normale ting for deg, så vet du i hvert fall hvordan du skal plassere egget slik at det ikke faller.
La oss oppsummere:
- Prøv å unngå snøfnugg. Og jo færre snøfnugg, desto færre ressurser trenger du for å gjøre endringer i hele den store infrastrukturen.
- Stadige endringer. Det vil si at når noen endringer skjer i koden, må du bringe infrastrukturen din i samsvar med disse endringene så raskt som mulig. Det burde ikke være en situasjon der noen kommer for å se på Elasticsearch to eller tre måneder senere, lager en Terraform-plan, og det er en haug med endringer han ikke forventet. Og det tar mye tid å sette alt i orden igjen.
- Tester og automatisering. Jo mer koden din er dekket med tester og funksjoner, jo mer tillit har du til at du gjør alt riktig. Og automatisk levering vil øke din selvtillit mange ganger.
- Koden for test- og produksjonsmiljøene skal være nesten den samme. Rent praktisk fordi produksjonen fortsatt er litt annerledes og det vil fortsatt være noen nyanser som vil gå utover testmiljøet. Men ikke desto mindre, pluss eller minus, kan dette sikres.
- Og hvis du har mye Terraform-kode og det tar mye tid å holde denne koden oppdatert, er det aldri for sent å refaktorere og få den i god form.
- Uforanderlig infrastruktur. AMI-levering etter planen.
- Struktur for rute53 når du har mange oppføringer og du vil at de skal være i konsekvent rekkefølge.
- Bekjempelse av API-hastighetsgrenser. Dette er når Amazon sier: "Det er det, jeg kan ikke godta flere forespørsler, vennligst vent." Og halvparten av kontoret venter til det kan lansere sin infrastruktur.
- Spot forekomster. Amazon er ikke et billig arrangement, og spots lar deg spare ganske mye. Og der kan du fortelle en hel rapport om det.
- Sikkerhet og IAM-roller.
- Søker etter tapte ressurser, når du har tilfeller av ukjent opprinnelse i Amazone, spiser de penger. Selv om tilfeller koster $100-150 per måned, er det mer enn $1 per år. Å finne slike ressurser er en lønnsom virksomhet.
- Og reserverte tilfeller.
Det var alt for meg. Terraform er veldig kult, du bruker det. Takk skal du ha!
spørsmål
Takk for rapporten! Tilstandsfilen din er i S3, men hvordan løser du problemet med at flere personer kan ta denne tilstandsfilen og prøve å utvide?
For det første har vi ikke hastverk. For det andre er det flagg, der vi rapporterer at vi jobber med en del kode. Det vil si at til tross for at infrastrukturen er veldig stor, betyr ikke dette at noen stadig bruker noe. Og når det var en aktiv fase, var dette et problem; vi lagret tilstandsfiler i Git. Dette var viktig, ellers ville noen laget en tilstandsmappe, og vi måtte manuelt sette dem sammen for at alt skulle fortsette. Nå er det ikke noe slikt problem. Generelt løste Terraform dette problemet. Og hvis noe stadig endrer seg, så kan du bruke låser, som forhindrer det du sa.
Bruker du åpen kildekode eller bedrift?
Ingen bedrift, det vil si alt du kan gå og laste ned gratis.
Jeg heter Stanislav. Jeg ville lage et lite tillegg. Du snakket om en Amazon-funksjon som lar deg gjøre en instans udødelig. Dette er også i selve Terraform; i Life Second-blokken kan du spesifisere et forbud mot endringer eller et forbud mot ødeleggelse.
Tiden var begrenset. Godt poeng.
Jeg ville også spørre om to ting. For det første snakket du om testing. Brukte du noen testverktøy? Jeg hørte om Test Kitchen-plugin. Kanskje det er noe mer. Og jeg vil også spørre om lokale verdier. Hvordan er de fundamentalt forskjellige fra inngangsvariabler? Og hvorfor kan jeg ikke parameterisere noe bare gjennom lokale verdier? Jeg prøvde å finne ut av dette emnet, men på en eller annen måte klarte jeg ikke å finne ut av det selv.
Vi kan snakke mer detaljert utenfor dette rommet. Våre testverktøy er helt selvlagde. Det er ingenting å teste der. Generelt er det alternativer når automatiserte tester plukker opp infrastruktur et sted, sjekker at det er OK, og deretter ødelegger alt med en rapport om at infrastrukturen din fortsatt er i god form. Vi har ikke dette fordi teststabler kjøres hver dag. Og det er nok. Og hvis noe begynner å gå i stykker, vil det begynne å gå i stykker uten at vi sjekker det et annet sted.
Angående lokale verdier, la oss fortsette samtalen utenfor rommet.
Hallo! Takk for rapporten! Veldig informativ. Du sa at du har mye av samme type kode for å beskrive infrastrukturen. Har du vurdert å generere denne koden?
Flott spørsmål, takk! Poenget er at når vi bruker infrastruktur som kode, antar vi at vi ser på koden og forstår hvilken infrastruktur som ligger bak den koden. Hvis kode genereres, må vi forestille oss hvilken kode som vil bli generert for å forstå hva slags infrastruktur som vil være der. Enten genererer vi kode, begår den, og i hovedsak skjer det samme. Så vi fulgte stien vi skrev, vi fikk den. Plussgeneratorer dukket opp litt senere da vi begynte å lage dem. Og det var allerede for sent å endre.
Har du hørt noe om jsonnet?
Nei.
Se, dette er en veldig kul ting. Jeg ser et spesifikt tilfelle der du kan bruke det og generere en datastruktur.
Generatorer er gode når du har dem, som i vitsen om en barbermaskin. Det vil si at første gang er ansiktet annerledes, men da har alle det samme ansiktet. Generatorene fungerer veldig bra. Men dessverre er ansiktene våre litt annerledes. Dette er et problem.
Bare se. Takk skal du ha!
Mitt navn er Maxim, jeg er fra Sberbank. Du snakket litt om hvordan du prøvde å bringe Terraform til det som tilsvarer et programmeringsspråk. Er det ikke enklere å bruke Ansible?
Dette er veldig forskjellige ting. Du kan lage ressurser i Ansible, og Puppet kan lage ressurser i Amazon. Men Terraform er rett og slett skjerpet.
Har du bare Amazon?
Det er ikke det at vi bare har Amazon. Vi har nesten bare Amazon. Men nøkkelfunksjonen er at Terraform husker. I Ansible, hvis du sier: "Gi meg 5 tilfeller," så vil det øke, og så sier du: "Og nå trenger jeg 3." Og Terraform vil si: "Ok, jeg dreper 2," og Ansible vil si: "Ok, her er 3 til deg." Totalt 8.
Hallo! Takk for rapporten! Det var veldig interessant å høre om Terraform. Jeg vil umiddelbart komme med en liten kommentar om at Terraform fortsatt ikke har en stabil utgivelse, så behandle Terraform med stor forsiktighet.
En god skje til middag. Det vil si at hvis man trenger en løsning, så utsetter man av og til det som er ustabilt osv, men det funker og det hjalp oss.
Spørsmålet er dette. Du bruker Remote backend, du bruker S 3. Hvorfor bruker du ikke den offisielle backend?
Offisielt?
Terraform Cloud.
Når dukket han opp?
For ca 4 måneder siden.
Hvis det hadde dukket opp for 4 år siden, ville jeg sannsynligvis ha svart på spørsmålet ditt.
Det er allerede en innebygd funksjon og låser, og du kan lagre en tilstandsfil. Gi det et forsøk. Men jeg har ikke testet det heller.
Vi reiser på et stort tog som kjører i høy hastighet. Og du kan ikke bare ta noen få biler og kaste dem.
Du snakket om snøfnugg, hvorfor brukte du ikke gren? Hvorfor gikk det ikke sånn?
Vår tilnærming er at hele infrastrukturen er i ett depot. Terraform, Puppet, alle skriptene som på en eller annen måte er relatert til dette, de er alle i ett depot. På denne måten kan vi sikre at inkrementelle endringer testes etter hverandre. Hvis det var en haug med grener, ville et slikt prosjekt være nesten umulig å opprettholde. Seks måneder går, og de divergerer så mye at det bare er en slags straff. Det var dette jeg ønsket å unnslippe før jeg refaktorerte.
Så det går ikke?
Dette fungerer ikke i det hele tatt.
I gren klippet jeg ut mappesliden. Det vil si at hvis du gjør det for hver teststabel, for eksempel lag A har sin egen mappe, team B har sin egen mappe, så fungerer ikke dette heller. Vi laget en enhetlig testmiljøkode som var fleksibel nok til å passe alle. Det vil si at vi serverte én kode.
Hallo! Jeg heter Yura! Takk for rapporten! Spørsmål om moduler. Du sier at du bruker moduler. Hvordan løser du problemet hvis det er gjort endringer i en modul som ikke er kompatible med en annen persons endring? Versjonerer du modulene på en eller annen måte eller prøver å ta med en wunderwaffle for å oppfylle to krav?
Dette er et stort snøhaugproblem. Det er dette vi lider av når en eller annen ufarlig endring kan ødelegge en del av infrastrukturen. Og dette vil merkes først etter lang tid.
Det vil si at det ikke er løst ennå?
Du lager universelle moduler. Unngå snøfnugg. Og alt vil ordne seg. Andre halvdel av rapporten handler om hvordan man unngår dette.
Hallo! Takk for rapporten! Jeg vil gjerne presisere. Bak kulissene var det en stor haug som jeg kom for. Hvordan er Puppet og rollefordeling integrert?
Brukerdata.
Det vil si at du bare spytter ut filen og utfører den på en eller annen måte?
Brukerdata er et notat, det vil si at når vi lager en kloning av bildet, reiser Daemon seg der og prøver å finne ut hvem han er, og leser notatet om at han er en lastbalanserer.
Det vil si, er dette en slags egen prosess som gis bort?
Vi fant det ikke opp. Vi bruker det.
Hallo! Jeg har bare et spørsmål om Bruker - data. Du sa at det er problemer der, at noen kan sende noe til feil sted. Er det noen måte å lagre brukerdata på i samme Git, slik at det alltid er klart hva brukerdata refererer til?
Vi genererer brukerdata fra mal. Det vil si at det brukes et visst antall variabler der. Og Terraform genererer det endelige resultatet. Derfor kan du ikke bare se på malen og si hva som vil skje, fordi alle problemene er relatert til det faktum at utvikleren tror at han sender en streng i denne variabelen, men en matrise brukes der. Og han - bam og jeg - så-og-så, så-og-så, neste linje, og alt gikk i stykker. Hvis dette er en ny ressurs og en person tar den opp og ser at noe ikke fungerer, så løses det raskt. Og hvis denne autoskaleringsgruppen oppdateres, begynner på et tidspunkt forekomstene i autoskaleringsgruppen å bli erstattet. Og puss, noe fungerer ikke. Det gjør vondt.
Det viser seg at den eneste løsningen er å teste?
Ja, du ser problemet, du legger til testtrinn der. Det vil si at utgang også kan testes. Kanskje det ikke er så praktisk, men du kan også sette noen merker - sjekk at brukerdata er spikret her.
Jeg heter Timur. Det er veldig kult at det er rapporter om hvordan man kan organisere Terraform på riktig måte.
Jeg har ikke engang begynt.
Jeg tror at det kanskje blir det på neste konferanse. Jeg har et enkelt spørsmål. Hvorfor hardkoder du verdien i en separat modul i stedet for å bruke tfvars, dvs. hvorfor er en modul med verdier bedre enn tfvars?
Det vil si, skal jeg skrive her (lysbilde: Produksjon/miljø/settings.tf): domene = variabel, domene vpcnetwork, variabel vpcnetwork og stvars – kan jeg få det samme?
Det er akkurat det vi gjør. Vi refererer for eksempel til innstillingskildemodulen.
I hovedsak er dette slike tfvars. Tfvars er veldig praktisk i et testmiljø. Jeg har tfvars for store forekomster, for små. Og jeg kastet en fil inn i mappen. Og jeg fikk det jeg ville. Når vi kutter infrastruktur ønsker vi at det skal være mulig å se på og umiddelbart forstå alt. Og så viser det seg at du må se her, så se på tfvars.
Er det mulig å ha alt på ett sted?
Ja, tfvars er når du har én kode. Og den brukes flere forskjellige steder med forskjellige nyanser. Da ville du kastet tfvars og fått nyansene dine. Og vi er infrastruktur som kode i sin reneste form. Jeg så og forsto.
Hallo! Har du vært borti situasjoner der skyleverandøren forstyrrer det du har laget Terraform? La oss si at vi redigerer metadataene. Det er ssh-nøkler. Og Google legger hele tiden sine metadata og nøkler der. Og Terraform skriver alltid at den har endringer. Etter hvert løp, selv om ingenting endres, sier han alltid at han vil oppdatere dette feltet nå.
Med nøkler, men - ja, en del av infrastrukturen påvirkes av noe slikt, dvs. Terraform kan ikke endre noe. Vi kan heller ikke endre noe med hendene. Så lenge vi lever med det.
Det vil si at du har støtt på noe slikt, men ikke kommet på noe, hvordan gjør han det og gjør det selv?
Dessverre ja.
Hallo! Mitt navn er Starkov Stanislav. Post. ru Gruppe. Hvordan løser du problemet med å generere en tag på..., hvordan sender du den inn? Slik jeg forstår det, gjennom Bruker - data for å spesifisere vertsnavnet, sette Puppet på? Og den andre delen av spørsmålet. Hvordan løser du dette problemet i SG, dvs. når du genererer SG, hundrevis av forekomster av samme type, hva er det riktige navnet på dem?
De tilfellene som er veldig viktige for oss, nevner vi dem vakkert. De som ikke er nødvendige, det er en merknad om at dette er en autoskaleringsgruppe. Og i teorien kan du spikre det fast og få en ny.
Når det gjelder problemet med taggen, er det ikke noe slikt problem, men det er en slik oppgave. Og vi bruker tagger veldig, veldig tungt, fordi infrastrukturen er stor og dyr. Og vi må se på hvor pengene går, så tags lar oss bryte ned hva som gikk hvor. Og følgelig brukes søket etter noe som betyr mye penger her.
Hva dreide spørsmålet seg ellers om?
Når SG oppretter hundrevis av forekomster, trenger de å skilles på en eller annen måte?
Nei, ikke gjør det. På hver forekomst er det en agent som rapporterer at jeg har et problem. Hvis en agent rapporterer, vet agenten om ham, og i det minste eksisterer hans IP-adresse. Du kan allerede rømme. For det andre bruker vi Consul for Discovery, der Kubernetes ikke er det. Og Consul viser også IP-adressen til forekomsten.
Det vil si, fokuserer du spesifikt på IP, og ikke på vertsnavn?
Det er umulig å navigere etter vertsnavn, det vil si at det er mange av dem. Det er forekomstidentifikatorer - AE osv. Du kan finne det et sted, du kan kaste det inn i søket.
Hallo! Jeg innså at Terraform er en god ting, skreddersydd for skyene.
Ikke bare.
Det er nettopp dette spørsmålet som interesserer meg. Hvis du bestemmer deg for å flytte, for eksempel, til Bare Metal i massevis med alle forekomstene dine? Vil det være noen problemer? Eller må du fortsatt bruke andre produkter, for eksempel samme Ansible som ble nevnt her?
Ansible handler litt om noe annet. Det vil si at Ansible fungerer allerede når forekomsten har startet. Og Terraform fungerer før forekomsten starter. Bytter til Bare Metal - nei.
Ikke nå, men virksomheten vil komme og si: "Kom igjen."
Bytte til en annen sky – ja, men det er et litt annet triks her. Du må skrive Terraform-kode på en slik måte at du kan bytte til en annen sky med mindre innsats.
Opprinnelig var oppgaven satt til at hele infrastrukturen vår var agnostisk, det vil si at enhver sky skulle passe, men på et tidspunkt ga virksomheten opp og sa: «Ok, i de neste N årene vil vi ikke gå noe sted, vi kan bruke tjenester fra Amazon "
Terraform lar deg lage Front-End-jobber, konfigurere PagerDuty, data doc, etc. Den har mange haler. Han kan praktisk talt kontrollere hele verden.
Takk for rapporten! Jeg har også brukt Terraform i 4 år nå. På stadiet av en jevn overgang til Terraform, til infrastruktur, til en deklarativ beskrivelse, ble vi møtt med en situasjon der noen gjorde noe for hånd, og du prøvde å lage en plan. Og jeg fikk en slags feil der. Hvordan takler du slike problemer? Hvordan finner du tapte ressurser som er oppført?
Hovedsakelig med våre hender og øyne, hvis vi ser noe merkelig i rapporten, så analyserer vi hva som skjer der, eller vi dreper rett og slett. Generelt er pull-forespørsler en vanlig ting.
Hvis det er en feil, ruller du tilbake? Har du prøvd å gjøre dette?
Nei, dette er en persons avgjørelse i det øyeblikket han ser et problem.
Kilde: www.habr.com