Det ser ud til, at Terraform-udviklerne tilbyder ganske praktisk bedste praksis for at arbejde med AWS-infrastrukturen. Kun der er en nuance. Over tid stiger antallet af miljøer, funktioner vises i hver. Vises næsten en kopi af ansøgningsstakken i naboregionen. Og Terraform-koden skal omhyggeligt kopieres og redigeres i henhold til de nye krav eller for at lave et snefnug.
Min rapport handler om mønstre i Terraform til at bekæmpe kaos og manuel rutine på store og lange projekter.
Video:
Jeg er 40, jeg har været i IT i 20 år. Jeg har arbejdet hos Ixtens i 12 år. Vi er engageret i e-handelsdrevet udvikling. Og jeg har praktiseret DevOps-praksis i 5 år.
Min historie vil handle om oplevelsen i et projekt i en virksomhed, hvis navn jeg ikke vil sige, der gemmer sig bag en tavshedspligt.
Tallene på sliden er givet for at forstå projektets omfang. Og alt, hvad jeg vil sige næste gang, er relateret til Amazon.
Jeg deltog i dette projekt for 4 år siden. Og omstruktureringen af infrastrukturen var i fuld gang, for projektet var vokset. Og de mønstre, der blev brugt, de passer ikke længere. Og givet al den planlagte vækst i projektet, var det nødvendigt at finde på noget nyt.
Tak til Matvey, som fortalte os i går, hvad der skete på Dodo Pizza. Dette er, hvad der skete for os for 4 år siden.
Udviklere kom og begyndte at lave infrastrukturkode.
De mest åbenlyse grunde til, at dette var påkrævet, var time to market. Det var nødvendigt at sikre sig, at DevOps-teamet ikke var en flaskehals ved udrulningen. Og blandt andet blev Terraform og Puppet brugt på allerførste niveau.
Terraform er et open source-projekt fra HashiCorp. Og for dem, der slet ikke ved, hvad det er, de næste par slides.
Infrastruktur som kode betyder, at vi kan beskrive vores infrastruktur og bede nogle robotter om at sikre, at vi får de ressourcer, som vi beskrev.
For eksempel har vi brug for en virtuel maskine. Vi vil beskrive, tilføje et par nødvendige parametre.
Derefter konfigurerer vi adgang til Amazon i konsollen. Og spørg efter Terraform-planen. Terraform plan vil sige: "Ok, for din ressource, vi kan gøre disse ting." Og mindst én ressource vil blive tilføjet. Og der forventes ingen ændringer.
Når alt passer dig, kan du bede Terraform ansøge, og Terraform vil oprette en instans til dig, og du får en virtuel maskine i din sky.
Yderligere udvikler vores projekt sig. Vi tilføjer nogle ændringer der. Vi beder om flere tilfælde, vi tilføjer 53 poster.
Og vi gentager. Planlæg venligst. Vi ser, hvilke ændringer der er planlagt. Ansøge. Og så vokser vores infrastruktur.
Terraform bruger sådan noget som tilstandsfiler. Det vil sige, at den gemmer alle de ændringer, der går til Amazon, i en fil, hvor der for hver ressource, du beskrev, er tilsvarende ressourcer, som er oprettet i Amazon. Når man ændrer beskrivelsen af en ressource, ved Terraform således præcis, hvad der skal ændres i Amazon.
Disse tilstandsfiler var oprindeligt kun filer. Og vi opbevarede dem i Git, hvilket var ekstremt ubelejligt. Konstant nogen glemte at begå ændringer, og der var mange konflikter.
Nu er det muligt at bruge backend, dvs. Terraform er angivet i hvilken bucket, med hvilken nøgle tilstandsfilen skal gemmes. Og Terraform vil selv sørge for at få denne tilstandsfil, gøre alt det magiske og lægge det endelige resultat tilbage.
Vores infrastruktur vokser. Her er vores kode. Og nu vil vi ikke bare lave en virtuel maskine, vi vil have et testmiljø.
Terraform giver dig mulighed for at lave sådan noget som et modul, dvs. beskrive det samme i en eller anden mappe.
Og for eksempel i test, ring til dette modul og få det samme, som hvis vi lavede Terraform-applicering i selve modulet. Her er koden til test.
Til produktion kan vi sende nogle ændringer dertil, for i test har vi ikke brug for store instanser, i produktion vil store instanser være nyttige.
Og så vender jeg tilbage til projektet. Det var en vanskelig opgave, infrastrukturen var planlagt meget stor. Og det var nødvendigt på en eller anden måde at placere al koden, så den ville være praktisk for alle: for dem, der udfører vedligeholdelse på denne kode, og for dem, der foretager ændringer. Og det var planlagt, at enhver udvikler kunne gå og reparere infrastrukturen efter behov for sin del af platformen.
Dette er et mappetræ, som anbefales af HashiCorp, hvis du har et stort projekt, og det giver mening at dele hele infrastrukturen op i nogle små stykker, og beskrive hvert stykke i en separat mappe.
Med et omfattende ressourcebibliotek kan du ringe om det samme i test og i produktion.
I vores tilfælde var dette ikke helt egnet, fordi teststakken til udviklere eller til test skulle opnås på en eller anden måde enklere. Og jeg ønskede ikke at gå gennem mapperne og ansøge i den rigtige rækkefølge og bekymre mig om, at basen ville stige, og så ville den instans, der bruger denne base, stige. Derfor blev al test startet fra én mappe. De samme moduler blev kaldt der, men alt gik igennem i én kørsel.
Terraform tager sig af alle afhængigheder. Og den opretter altid ressourcer i den rækkefølge, så du kan få en IP-adresse, for eksempel fra en nyoprettet instans, og få denne IP-adresse i rute53-indgangen.
Derudover er platformen meget stor. Og at køre en teststak, selvom det er i en time, selvom det er i 8 timer, er en ret dyr forretning.
Og vi har automatiseret denne forretning. Og Jenkins-jobbet tillod stakken at løbe. Det var nødvendigt at starte en pull-anmodning i den med de ændringer, som udvikleren ønsker at teste, specificere alle de nødvendige muligheder, komponenter og størrelser. Hvis han ønsker præstationstest, så kan han tage flere tilfælde. Hvis han bare skal tjekke, at der åbner en formular, kan han starte med mindstelønnen. Og angiv også, om en klynge er nødvendig eller ej, osv.
Og så skubbede Jenkins et shell-script, der lidt ændrede koden i Terraform-mappen. Fjernede unødvendige filer, tilføjede de nødvendige filer. Og så, med en omgang Terraform påføring, steg stakken.
Og så var der andre trin, som jeg ikke ønsker at gå ind på.
På grund af det faktum, at vi til test havde brug for lidt flere muligheder end i produktionen, var vi nødt til at lave kopier af modulerne, så vi i disse kopier kunne tilføje de funktioner, der kun er nødvendige i test.
Og det skete så, at i test ser det ud til, at du vil teste de ændringer, der i sidste ende vil gå til produktion. Men faktisk blev én ting testet, og der blev brugt lidt andet i produktionen. Og der var et lille brud i mønsteret, at i produktionen blev alle ændringer anvendt af driftsteamet. Og nogle gange viste det sig, at de ændringer, der skulle gå fra test til produktion, forblev i en anden version.
Derudover var der et sådant problem, at der blev tilføjet en ny tjeneste, som var lidt anderledes end en eksisterende. Og i stedet for at ændre et eksisterende modul, skulle du lave en kopi af det og tilføje de nødvendige ændringer.
Faktisk er Terraform ikke et rigtigt sprog. Dette er en erklæring. Hvis vi har brug for at erklære noget, så erklærer vi det. Og det hele virker.
På et tidspunkt, da jeg diskuterede en af mine pull-anmodninger, sagde en af mine kolleger, at det ikke er nødvendigt at producere snefnug. Jeg spekulerede på, hvad han mente. Der er sådan et videnskabeligt faktum, at der i verden ikke er to identiske snefnug, de er alle lidt, men forskellige. Og så snart jeg hørte dette, mærkede jeg straks den fulde vægt af Terraform-koden. For når det var påkrævet at flytte fra version til version, krævede Terraform et brydende kædeskifte, det vil sige, at koden ikke længere var kompatibel med den næste version. Og jeg var nødt til at lave en pull-anmodning, som dækkede næsten halvdelen af filerne i infrastrukturen, for at bringe infrastrukturen til den næste version af Terraform.
Og efter at sådan et snefnug dukkede op, blev al Terraform-koden, som vi havde forvandlet, til en stor, stor bunke sne.
For en ekstern udvikler, der er uden for drift, betyder det ikke meget for ham, fordi han lavede en pull-anmodning, hans ressource startede. Og det er det, det er ikke hans bekymring. Og DevOps-teamet, der sørger for, at alt er OK, skal foretage alle disse ændringer. Og omkostningerne ved disse ændringer steg meget, meget med hvert ekstra snefnug.
Der er en historie om, hvordan en studerende på et seminar tegner to perfekte cirkler med kridt på en tavle. Og læreren er overrasket over, hvordan det lykkedes ham at tegne så glat uden kompas. Eleven svarer: "Det er meget simpelt, jeg lavede en kødkværn i to år i hæren."
Og ud af de fire år, jeg har været på dette projekt, har jeg lavet Terraform i omkring to år. Og selvfølgelig har jeg nogle tricks, nogle tips til, hvordan man forenkler Terraform-koden, arbejder med den som et programmeringssprog og reducerer byrden for udviklere, der skal holde denne kode ajour.
Den første ting jeg gerne vil starte med er Symlinks. Terraform har en masse gentagne kode. For eksempel er det det samme at ringe til en udbyder på næsten alle steder, hvor vi opretter et stykke infrastruktur. Og det er logisk at lægge det i en separat daddy. Og hvor end udbyderen er forpligtet til at lave Symlinks til denne fil.
For eksempel bruger du antage rolle i produktionen, som giver dig mulighed for at få adgangsrettigheder til en ekstern Amazon-konto. Og ved at ændre én fil, vil alle de resterende, der er i ressourcetræet, have de nødvendige rettigheder, så Terraform ved, hvilket Amazon-segment der skal tilgås.
Hvor Symlinks ikke virker? Terraform har som sagt statsfiler. Og de er meget, meget seje. Men faktum er, at Terraform initialiserer backend i den allerførste. Og han kan ikke bruge nogen variable i disse parametre, de skal altid skrives i tekst.
Og som et resultat, når nogen laver en ny ressource, kopierer han en del af koden fra andre mapper. Og han kan lave en fejl med nøglen eller med spanden. For eksempel laver han en sandkasseting ud af en sandkasse, og laver den så i produktion. Og så kan det vise sig, at spanden i produktionen skal bruges fra sandkassen. Selvfølgelig finder de det hurtigt. Det vil på en eller anden måde være muligt at rette op på dette, men ikke desto mindre er det spild af tid og til en vis grad ressourcer.
Hvad kan vi så gøre? Før du arbejder med Terraform, skal du initialisere den. På initialiseringstidspunktet downloader Terraform alle plugins. På et tidspunkt brød de fra en monolit til en mere mikroservicearkitektur. Og du skal altid lave Terraform init, så den trækker alle moduler op, alle plugins.
Og du kan bruge et shell-script, som for det første kan få alle variablerne. Shell-scriptet er ubegrænset. Og for det andet vejen. Hvis vi altid bruger stien, der er i depotet, som nøglen til tilstandsfilen, vil fejlen følgelig blive udelukket her.
Hvor kan man hente data? JSON-fil. Terraform giver dig mulighed for at skrive infrastruktur ikke kun i hcl (HashiCorp Configuration Language), men også i JSON.
JSON er let at læse fra et shell-script. Derfor kan du lægge en konfigurationsfil med en bøtte et eller andet sted. Og brug denne bøtte både i Terraform-koden og i shell-scriptet til initialisering.
Hvorfor er det vigtigt at have en Terraform-spand? Fordi der er sådan noget som fjerntilstandsfiler. Det vil sige, når jeg hæver en eller anden ressource, for at fortælle Amazon: "Vær venlig at hæve instans", skal jeg angive en masse påkrævede parametre.
Og disse identifikatorer er gemt i en anden mappe. Og jeg kan tage det og sige: "Terraform, løb venligst til statens fil for netop den ressource og skaffe mig disse identifikatorer." Og dermed er der en slags forening mellem forskellige regioner eller miljøer.
Det er ikke altid muligt at bruge en ekstern tilstandsfil. For eksempel oprettede du manuelt en VPC. Og Terraform-koden, der skaber VPC'en, skaber en så anderledes VPC, at det tager meget lang tid, og du skal justere den ene til den anden, så du kan bruge følgende trick.
Altså at lave et modul, der sådan set laver VPC og giver dig identifikatorer, men i virkeligheden er der bare en fil med hårdkodede værdier, der kan bruges til at lave den samme instans.
Det er ikke altid nødvendigt at gemme tilstandsfilen i skyen. For eksempel, når du tester moduler, kan du bruge backend-initialisering, når filen bliver gemt kun på disken på testtidspunktet.
Nu lidt om at teste. Hvad kan testes i Terraform? Sandsynligvis er meget muligt, men jeg vil tale om disse 4 ting.
HashiCorp har en forståelse af, hvordan man formaterer Terraform-kode. Og Terraform fmt lader dig formatere den kode, du redigerer i henhold til den overbevisning. Testene skal derfor nødvendigvis kontrollere, om formateringen stemmer overens med det, HashiCorp testamenterede, så man ikke skal ændre placeringen af parenteser mv.
Den næste er Terraform-validering. Det gør lidt mere end et syntakstjek - ala, er alle parenteserne parret. Hvad er vigtigt her? Vi har en meget tynd infrastruktur. Den har mange forskellige mapper. Og i hver skal du køre Terraform-validering.
For at fremskynde testningen kører vi derfor flere processer parallelt ved hjælp af parallel.
Parallel er en meget cool ting, brug den.
Men hver gang Terraform initialiseres, går den til HashiCorp og spørger: "Hvad er de seneste plugins? Og plugin'et som jeg har i cachen - er det den ene eller ej den? Og det bremsede ved hvert skridt.
Hvis Terraform fortæller dig, hvor plugins er, vil Terraform sige: "OK, det er nok det friskeste, der findes. Jeg går ingen steder, jeg begynder at validere din Terraform-kode med det samme."
For at fylde mappen med de nødvendige plugins, har vi en meget simpel Terraform-kode, som blot skal initialiseres. Her skal du selvfølgelig angive alle de udbydere, der på en eller anden måde deltager i din kode, ellers vil Terraform sige: "Jeg kender ikke nogen udbyder, for den er ikke i cachen."
Den næste er Terraform-planen. Udviklingen er som sagt cyklisk. Vi laver kode med ændringer. Og så skal du finde ud af, hvilke ændringer der er planlagt for infrastrukturen.
Og når infrastrukturen er meget, meget stor, kan du ændre et modul, rette et testmiljø eller en bestemt region og bryde et tilstødende. Derfor bør der laves en Terraform-plan for hele infrastrukturen og vise hvilke ændringer der er planlagt.
Du kan gøre det på den smarte måde. For eksempel skrev vi et Python-script, der løser afhængigheder. Og alt efter hvad der er blevet ændret: et Terraform-modul eller bare en specifik komponent, laver den planer for alle afhængige mapper.
Terraform plan skal udføres efter anmodning. Det er i hvert fald det, vi gør.
Tests er selvfølgelig gode at lave for hver ændring, for hver commit, men planer er ret dyrt. Og vi siger i pull-anmodningen: "Giv mig venligst planerne." Robotten starter. Og sender til kommentarer eller til at vedhæfte alle de planer, der forventes fra dine ændringer.
Planen er en ret dyr ting. Det tager tid, fordi Terraform går til Amazon og spørger: "Eksisterer denne instans stadig? Har denne autoskalering nøjagtig de samme parametre?”. Og for at fremskynde det, kan du bruge en parameter som refresh=false. Dette betyder, at Terraform vil tømme S3-tilstanden. Og vil tro, at staten præcis vil matche, hvad der er i Amazon.
Sådan en Terraform-plan er meget hurtigere, men staten skal matche din infrastruktur, dvs. et eller andet sted skal Terraform-opdateringen engang starte. Terraform refresh gør præcis det, så staten svarer til, hvad der er i den reelle infrastruktur.
Og jeg må sige om sikkerhed. Det var her, det skulle være startet. Hvor du kører Terraform og Terraform arbejder med din infrastruktur, er der en sårbarhed. Det vil sige, at du i det væsentlige udfører kode. Og hvis pull-anmodningen indeholder en form for ondsindet kode, så kan den udføres på en infrastruktur, der har for meget adgang. Vær derfor forsigtig, hvor du starter Terraform-planen.
Den næste ting, jeg gerne vil tale om, er test af brugerdata.
Hvad er brugerdata? I Amazon, når vi opretter en instans, kan vi sende en form for brev fra instansen – metadata. Når en instans startes, er cloud init normalt altid til stede på disse instanser. Cloud init læser dette brev og siger: "OK, i dag er jeg en load balancer." Og i overensstemmelse med disse forskrifter udfører han nogle handlinger.
Men desværre, når vi laver Terraform-plan og Terraform anvender, ser brugerdata ud som denne opsummering af tal. Det vil sige, at han bare sender dig en hash. Og alt, du kan se i planen, er, om der vil ske ændringer, eller om hashen forbliver den samme.
Og hvis du ikke er opmærksom på dette, kan en eller anden slået tekstfil gå til Amazon, til den rigtige infrastruktur.
Alternativt kan du angive ikke hele infrastrukturen under udførelsen, men kun skabelonen. Og sig i koden: "Vis venligst denne skabelon for mig." Og som et resultat kan du få en udskrift af, hvordan dine data kommer til at se ud på Amazon.
En anden mulighed er at bruge et modul til at generere brugerdata. Du vil anvende dette modul. Hent filen på disken. Sammenlign det med referencen. Og derfor, hvis en jun beslutter sig for at rette lidt brugerdata, så vil dine test sige: "OK, der er nogle ændringer her og der - det er normalt."
Den næste ting, jeg gerne vil tale om, er Automate Terraform application.
Selvfølgelig er det skræmmende nok at gøre Terraform anvende i automatisk tilstand, for hvem ved, hvilke ændringer der er sket der, og hvor skadelige de kan være for en levende infrastruktur.
For et testmiljø er det hele fint. Det vil sige, at et job, der skaber et testmiljø, er, hvad alle udviklere har brug for. Og sådan et udtryk som "alt fungerede for mig" er ikke et sjovt meme, men et bevis på, at en person blev forvirret, rejste en stak, lancerede nogle test på denne stak. Og han sørgede for, at alt var i orden der og sagde: "OK, koden, som jeg udgiver, er blevet testet."
I produktion, sandkasse og andre miljøer, der er mere forretningskritiske, er det sikkert delvist at bruge nogle ressourcer, fordi det ikke får nogen til at dø. Disse er: autoskaleringsgrupper, sikkerhedsgrupper, roller, route53 og der kan listen være ret stor. Men hold øje med, hvad der sker, læs rapporter om automatiserede applikationer.
Hvor det er farligt eller skræmmende at bruge, for eksempel hvis det er nogle vedvarende ressourcer, fra en database, så få rapporter om, at der er uanvendte ændringer i et eller andet stykke infrastruktur. Og ingeniøren er allerede overvåget med at køre job for at ansøge eller gøre det fra sin konsol.
Amazon har sådan noget som Terminate-beskyttelse. Og det kan i nogle tilfælde beskytte mod ændringer, der ikke er nødvendige for dig. Så Terraform gik til Amazon og sagde "Jeg er nødt til at dræbe denne instans for at lave endnu en". Og Amazon siger: "Beklager, ikke i dag. Vi har Terminate-beskyttelse."
Og prikken over i'et er kodeoptimering. Når vi arbejder med Terraform kode, skal vi videregive et meget stort antal parametre til modulet. Det er de parametre, der er nødvendige for at skabe en form for ressource. Og koden bliver til store lister over parametre, der skal overføres fra modul til modul, fra modul til modul, især hvis modulerne er indlejret.
Og det er meget svært at læse. Det er meget svært at gennemgå dette. Og meget ofte viser det sig, at nogle parametre bliver gennemgået, og det er ikke helt dem, der er brug for. Og det koster tid og penge at ordne det senere.
Derfor foreslår jeg, at du bruger sådan en ting som en kompleks parameter, der inkluderer et bestemt træ af værdier. Det vil sige, du har brug for en form for mappe, hvor du har alle de værdier, som du gerne vil have på et eller andet miljø.
Og ved at kalde dette modul, kan du få et træ, der er genereret i ét fælles modul, altså i et fælles modul, der fungerer ens for hele infrastrukturen.
I dette modul kan du lave nogle beregninger ved at bruge en så frisk funktion i Terraform som lokalbefolkningen. Og udgiv derefter en form for kompleks parameter i et output, som kan omfatte hashes, arrays osv.
På dette, alle de bedste fund, som jeg har afsluttet. Og jeg vil gerne fortælle en historie om Columbus. Da han ledte efter penge til sin ekspedition for at opdage Indien (som han troede dengang), var der ingen, der troede på ham og troede, at det var umuligt. Så sagde han: "Sørg for, at ægget ikke falder." Alle bankfolkene, meget rige og sandsynligvis kloge mennesker, forsøgte at lægge ægget på en eller anden måde, og det faldt hele tiden. Så tog Columbus ægget, trykkede lidt på det. Skallen krøllede, og ægget forblev ubevægeligt. De sagde: "Åh, det er for nemt!" Og Columbus svarede: ”Ja, det er for simpelt. Og når jeg åbner Indien, vil alle bruge denne handelsrute."
Og det, jeg lige har fortalt dig, er nok ret simple og trivielle ting. Og når du finder ud af dem og begynder at bruge dem, er det i tingenes rækkefølge. Så brug det. Og hvis det er helt normale ting for dig, så ved du i hvert fald, hvordan du lægger et æg, så det ikke falder.
Lad os opsummere:
- Prøv at undgå snefnug. Og jo færre snefnug, jo færre ressourcer skal du bruge for at foretage ændringer i hele din store infrastruktur.
- Konstant forandring. Det vil sige, at når der er sket nogle ændringer i koden, skal du hurtigst muligt bringe din infrastruktur i overensstemmelse med disse ændringer. Der burde ikke være en situation, hvor nogen kommer om to eller tre måneder for at se på Elasticsearch, laver en Terraform-plan, og der er en masse ændringer, som han ikke havde forventet. Og det tager meget tid at bringe alt i orden igen.
- Test og automatisering. Jo mere din kode er dækket af test og chips, jo mere tillid har du til, at du gør alt rigtigt. Og automatisk levering vil øge din selvtillid mange gange.
- Koden for test- og produktionsmiljøerne bør være næsten den samme. Rent praktisk, fordi produktionen trods alt er lidt anderledes, og der vil stadig være nogle nuancer, der vil gå ud over testmiljøet. Men ikke desto mindre kan plus eller minus det leveres.
- Og hvis du har meget Terraform-kode, og det tager meget tid at holde denne kode ajour, så er det aldrig for sent at omstrukturere og bringe den i god form.
- uforanderlig infrastruktur. AMI levering efter planen.
- Struktur for route53, når du har mange poster og ønsker, at de skal være i en ensartet rækkefølge.
- Kæmp mod API-hastighedsgrænser. Det er, når Amazon siger: "Det er det, jeg kan ikke acceptere flere anmodninger, vent venligst." Og halvdelen af kontoret venter, indtil det kan lancere sin infrastruktur.
- få øje på tilfælde. Amazon er ikke en billig begivenhed, og spots giver dig mulighed for at spare ret meget. Og der kan du fortælle en hel rapport om det.
- Sikkerhed og IAM roller.
- Søg efter tabte ressourcer, når du har tilfælde af ukendt oprindelse i Amazone, spiser de penge. Selvom tilfælde koster 100-150 USD om måneden, er det mere end 1 USD om året. At finde sådanne ressourcer er en lukrativ forretning.
- Og reserverede tilfælde.
Det var alt for mig. Terraform er meget cool, brug den. Tak skal du have!
R'RѕRїSЂRѕSЃS <
Tak for rapporten! Du har en tilstandsfil i S3, men hvordan løser du problemet med, at flere personer kan tage denne tilstandsfil og forsøge at implementere?
For det første har vi ikke travlt. For det andet er der flag, hvor vi rapporterer, at vi arbejder på et eller andet stykke kode. Det vil sige, på trods af at infrastrukturen er meget stor, betyder det ikke, at nogen konstant bruger noget. Og når der var en aktiv fase, var dette et problem, vi opbevarede tilstandsfiler i Git. Dette var vigtigt, ellers ville nogen lave en tilstandsfil, og vi måtte manuelt samle dem i en bunke for at fortsætte videre. Nu er der ikke noget sådant problem. Generelt løste Terraform dette problem. Og hvis noget hele tiden ændrer sig, så kan du bruge låse, der forhindrer det, du sagde.
Bruger du open source eller virksomhed?
Ingen virksomhed, det vil sige alt, hvad du kan gå og downloade gratis.
Mit navn er Stanislav. Jeg ville lave en lille tilføjelse. Du talte om Amazon-funktionen, der giver dig mulighed for at gøre en instans udødelig. Dette er også i Terraform selv, i Life Second-blokken kan du foreskrive et forbud mod forandring eller et forbud mod ødelæggelse.
Var begrænset i tid. God pointe.
Jeg ville også spørge om to ting. Først talte du om test. Har du brugt nogle testværktøjer? Jeg hørte om plugin'et Test Kitchen. Måske er der noget andet. Og jeg vil gerne spørge om lokale værdier. Hvordan adskiller de sig grundlæggende fra inputvariabler? Og hvorfor kan jeg ikke parametrisere noget kun gennem lokale værdier? Jeg forsøgte at beskæftige mig med dette emne, men på en eller anden måde fandt jeg ikke ud af det selv.
Vi kan tale mere detaljeret bag denne sal. Testværktøjer er vores komplette selvfremstillede. Der er ikke noget at teste der. Generelt er der muligheder, når automatiske test hæver infrastrukturen et sted, tjekker, at den er i orden, og så ødelægger alt med en rapport om, at din infrastruktur stadig er i god stand. Det har vi ikke, fordi teststakkene kører hver dag. Og det er nok. Og hvis noget begynder at gå i stykker, så begynder det at gå i stykker, uden at vi tjekker det et andet sted.
Med hensyn til lokale værdier, lad os fortsætte samtalen uden for publikum.
Hej! Tak for rapporten! Meget informativ. Du sagde, at du har meget af den samme type kode til at beskrive infrastrukturen. Har du overvejet at generere denne kode?
Godt spørgsmål, tak! Pointen er, at når vi bruger infrastruktur som kode, antager vi, at vi ser på koden og forstår, hvilken slags infrastruktur der ligger bag denne kode. Hvis koden genereres, så er vi nødt til at forestille os, hvilken kode der vil blive genereret for at forstå, hvilken slags infrastruktur der vil være der. Eller vi genererer koden, begår den, og faktisk får vi det samme. Derfor gik vi den måde, vi skrev, vi fik det. Plus, generatorer dukkede op lidt senere, da vi begyndte at lave. Og det var for sent at ændre.
Har du hørt om jsonnet?
Nej.
Se, det er virkelig seje ting. Jeg ser et specifikt tilfælde, hvor du kan anvende det og generere en datastruktur.
Generatorer er gode, når du har dem, som i joken om barbermaskinen. Det vil sige, første gang er ansigtet anderledes, men så har alle det samme ansigt. Generatorerne er meget seje. Men desværre er vores ansigter lidt anderledes. Dette er et problem.
Bare se. Tak skal du have!
Mit navn er Maxim, jeg er fra Sberbank. Du sagde lidt, at du forsøgte at bringe Terraform til en analog af et programmeringssprog. Er det ikke nemmere at bruge Ansible?
Det er meget forskellige ting. Ansible kan skabe ressourcer, og Puppet kan skabe ressourcer i Amazon. Men Terraform er ligefrem skærpet.
Har du kun Amazon?
Det er ikke, at vi kun har Amazon. Vi har næsten kun Amazon. Men nøglefunktionen er, at Terraform husker. I Ansible, hvis du siger: "Pick me up 5 instances", så hæver det, og så siger du: "Og nu skal jeg bruge 3". Og Terraform vil sige: "Ok, jeg dræber 2", og Ansible vil sige: "Ok, her er 3 til dig." I alt 8.
Hej! Tak for din rapport! Det var meget interessant at høre om Terraform. Jeg vil lige komme med en lille kommentar om, at Terraform stadig ikke har en stabil udgivelse, så vær meget forsigtig med Terraform.
Fin ske til aftensmaden. Det vil sige, at hvis man har brug for en løsning, så udskyder man nogle gange det, der er ustabilt osv., men det virker og hjalp os.
Spørgsmålet er. Du bruger Remote backend, du bruger S 3. Hvorfor bruger du ikke den officielle backend?
Officiel?
Terraform Cloud.
Hvornår dukkede han op?
4 måneder siden.
Hvis det var dukket op for 4 år siden, så ville jeg sandsynligvis have svaret på dit spørgsmål.
Der er allerede en indbygget funktion og låse, og du kan gemme en tilstandsfil. Prøv det. Men jeg har heller ikke testet.
Vi er på et stort tog, der kører med høj hastighed. Og du kan ikke bare tage og smide et par biler ud.
Du talte om snefnug, hvorfor brugte du ikke gren? Hvorfor gik det ikke sådan?
Vi har sådan en tilgang, at hele infrastrukturen er i ét depot. Terraform, Puppet, alle de scripts, der på en eller anden måde relaterer til dette, de er alle i ét lager. På denne måde kan vi sikre, at trinvise ændringer testes én efter én. Hvis det var en flok grene, så ville et sådant projekt være næsten umuligt at vedligeholde. Der går seks måneder, og de divergerer så meget, at det bare er en form for straf. Det var det, jeg ville løbe væk fra, før jeg refaktorerede.
dvs det virker ikke?
Det virker slet ikke.
I gren klippede jeg mappesliden ud. Det vil sige, at hvis du gør for hver teststak, for eksempel hold A har sin egen daddy, hold B har sin egen daddy, så virker dette heller ikke. Vi lavede en samlet testmiljøkode, der var fleksibel nok til at passe til alle. Det vil sige, at vi serverede én kode.
Hej! Mit navn er Yura! Tak for rapporten! Spørgsmål om moduler. Du siger, at du bruger moduler. Hvordan løser du problemet, hvis der blev foretaget ændringer i ét modul, som ikke er kompatible med en anden persons ændring? På en eller anden måde versionerer moduler eller prøver at bringe et vidunderbarn til at opfylde to krav?
Dette er det store snebunkeproblem. Det er det, vi lider af, når en eller anden uskadelig forandring kan bryde en del af infrastrukturen. Og det vil først kunne mærkes efter lang tid.
Det er altså ikke besluttet endnu?
Du laver universelle moduler. Undgå snefnug. Og alt vil løse sig. Anden halvdel af rapporten handler om, hvordan man undgår det.
Hej! Tak for rapporten! Jeg vil gerne præcisere. Bag kulisserne var der en stor bunke, som jeg kom for. Hvordan er Puppet og rollefordeling integreret?
brugerdata.
Det vil sige, spytter du bare filen ud og på en eller anden måde eksekverer på den?
Brugerdata er en note, dvs. når vi laver en billedklon, så rejser Daemon sig der og prøver at finde ud af, hvem han er, læser en note om, at han er en load balancer.
Det vil sige, er det en slags separat proces, der gives væk?
Vi har ikke opfundet det. Vi bruger det.
Hej! Jeg har lige et spørgsmål om Bruger - data. Du sagde, at der er problemer der, at nogen måske sender noget til det forkerte sted. Er der en måde at gemme brugerdata på i samme Git, så det altid er klart, hvad brugerdata refererer til?
Vi genererer brugerdata fra skabelon. Det vil sige, at et vist antal variabler griber dertil. Og Terraform genererer det endelige resultat. Derfor kan du ikke bare se på skabelonen og sige, hvad der sker, for alle problemerne er relateret til, at udvikleren tror, at han sender en streng i denne variabel, og så bruges et array. Og han - bang og jeg - sådan og så, sådan og så, den næste linje, og alt gik i stykker. Hvis dette er en ny ressource, og en person rejser den, ser, at noget ikke fungerer, så er dette hurtigt løst. Og hvis denne autoskaleringsgruppe er blevet opdateret, begynder instanserne i autoskaleringsgruppen på et tidspunkt at blive erstattet. Og klap, noget virker ikke. Det gør ondt.
Det viser sig, at den eneste løsning er at teste?
Ja, du ser problemet, du tilføjer testtrin der. Det vil sige, at output også kan testes. Måske ikke så praktisk, men du kan også sætte nogle mærker - tjek at User-data er nailed her.
Mit navn er Timur. Det er meget fedt, at der er rapporter om, hvordan man organiserer Terraform korrekt.
Jeg startede ikke engang.
Jeg tror, at der måske bliver det på den næste konference. Jeg har et simpelt spørgsmål. Hvorfor hardkoder du værdien i et separat modul i stedet for at bruge tfvars, dvs. er et modul med værdier bedre end tfvars?
Det vil sige, jeg skulle skrive her (slide: Produktion/miljø/indstillinger.tf): domæne = variabel, domæne vpcnetwork, vpcnetwork variabel og stvars - får du det samme?
Det gør vi præcis. Vi henviser for eksempel til indstillingskildemodulet.
Faktisk er dette sådan en tfvars. Tfvars er meget praktisk i et testmiljø. Jeg har tfvars til store instanser, til små. Og jeg smed en fil ind i mappen. Og fik hvad jeg ville have. Når vi så infrastruktur, vil vi gerne kunne se og med det samme forstå alt. Og så viser det sig, at du skal kigge her, så se i tfvars.
Det viser sig, at alt var på ét sted?
Ja, tfvars er, når du har én kode. Og den bruges flere forskellige steder med forskellige nuancer. Så ville du kaste tfvars og få dine nuancer. Og vi er infrastruktur som kode i sin reneste form. Kiggede og forstået.
Hej! Er du stødt på situationer, hvor cloud-udbyderen blander sig i, hvad du har gjort med Terraform? Lad os sige, at vi redigerer metadataene. Der er ssh-nøgler. Og Google smutter konstant sine metadata, sine nøgler der. Og Terraform skriver altid, at den har ændringer. Efter hver kørsel, selvom intet ændrer sig, siger han altid, at han vil opdatere dette felt nu.
Med nøgler, men - ja, en del af infrastrukturen er påvirket af sådan noget, dvs Terraform kan ikke ændre noget. Vi kan heller ikke ændre noget med vores hænder. Så længe vi lever med det.
Det vil sige, du stødte på dette, men fandt ikke på noget, hvordan gør han det og gør det selv?
Desværre ja.
Hej! Mit navn er Stanislav Starkov. Post. en gruppe. Hvordan løser man problemet med at generere et tag på ..., hvordan sender man det ind? Som jeg forstår det, gennem Bruger - data, for at angive værtsnavnet, tilskynde Puppet? Og anden del af spørgsmålet. Hvordan løser du dette problem i SG, dvs. når du genererer SG, hundrede forekomster af samme type, hvordan navngives dem korrekt?
De tilfælde, der er meget vigtige for os, vil vi navngive dem smukt. Dem, der ikke er nødvendige, er der et efterskrift om, at dette er en autoskaleringsgruppe. Og i teorien kan den sømmes, og få en ny.
Hvad angår problemet med tagget, er der ikke noget sådant problem, men der er sådan en opgave. Og vi bruger tags meget, meget kraftigt, fordi infrastrukturen er stor og dyr. Og vi skal se på, hvad der bruges penge på, så tags giver os mulighed for at finde ud af, hvad og hvor det gik hen. Og derfor er søgningen efter noget her en masse penge brugt.
Hvad handlede spørgsmålet ellers om?
Når SG opretter hundrede forekomster, skal de så skelnes på en eller anden måde?
Nej, lad være. Hver instans har en agent, der fortæller mig, at jeg har et problem. Hvis agenten rapporterer, så kender agenten til ham, og i det mindste eksisterer hans IP-adresse. Du kan allerede løbe. For det andet bruger vi Consul for Discovery, hvor der ikke er nogen Kubernetes. Og Consul viser også instansens IP-adresse.
Det vil sige, at du målretter mod præcis IP-adressen og ikke værtsnavnet?
Det er umuligt at navigere efter værtsnavn, det vil sige, at der er mange af dem. Der er instansidentifikatorer - AE osv. Du kan finde det et sted, du kan smide det ind i søgningen.
Hej! Jeg indså, at Terraform er en god ting, skræddersyet til skyerne.
Ikke kun.
Det er spørgsmålet, der interesserer mig. Hvis du beslutter dig for at flytte for eksempel til Bare Metal i massevis med alle dine tilfælde? Vil der være problemer? Eller skal du stadig bruge andre produkter, for eksempel den samme Ansible, som blev nævnt her?
Ansible handler lidt om noget andet. Det vil sige, at Ansible allerede kører, når instansen er startet. Og Terraform virker før instansen er startet. At skifte til Bare Metal er det ikke.
Ikke nu, men erhvervslivet vil komme og sige: "Kom nu."
Skifter til en anden sky – ja, men der er en lidt anden funktion her. Du skal skrive Terraform-kode på en sådan måde, at du kan skifte til en anden sky med mindre blodsudgydelser.
I første omgang var opgaven, at hele vores infrastruktur er agnostisk, dvs. enhver sky skulle være i orden, men på et tidspunkt gav forretningen op og sagde: ”OK, i de næste N år går vi ingen steder, du kan bruge tjenester fra Amazon".
Terraform giver dig mulighed for at oprette Front-End jobs, konfigurere PagerDuty, data docs osv. Det har mange haler. Han kan praktisk talt kontrollere hele verden.
Tak for rapporten! Jeg har også spindet Terraform i 4 år nu. På stadiet af en glidende overgang til Terraform, til infrastruktur, til en deklarativ beskrivelse, stod vi over for en situation, hvor nogen lavede noget i hånden, og du forsøgte at lave en plan. Og jeg fik en fejl der. Hvordan håndterer du sådanne problemer? Hvordan finder du de mistede ressourcer, der blev angivet?
Mest med vores hænder og øjne, hvis vi ser noget mærkeligt i rapporten, så analyserer vi, hvad der sker der, eller vi slår det bare ihjel. Generelt er pull-anmodninger en almindelig ting.
Hvis der er en fejl, ruller du tilbage? Har du prøvet at gøre dette?
Nej, dette er en beslutning truffet af en person i det øjeblik, han ser problemet.
Kilde: www.habr.com