Mange kender og bruger Terraform i deres daglige arbejde, men bedste praksis for det er endnu ikke blevet dannet. Hvert team skal opfinde sine egne tilgange og metoder.
Din infrastruktur starter næsten helt enkelt: nogle få ressourcer + nogle få udviklere. Med tiden vokser det i alle mulige retninger. Finder du måder at gruppere ressourcer i Terraform-moduler, organisere kode i mapper, og hvad der ellers kan gå galt? (Berømte sidste ord)
Tiden går, og du føler, at din infrastruktur er dit nye kæledyr, men hvorfor? Du er bekymret for uforklarlige ændringer i infrastrukturen, du er bange for at røre ved infrastrukturen og koden - som følge heraf forsinker du ny funktionalitet eller reducerer kvaliteten...
Efter tre år med styring af en samling af Terraform-fællesskabsmoduler til AWS på Github og langsigtet vedligeholdelse af Terraform i produktionen, er Anton Babenko klar til at dele sin erfaring: hvordan man skriver TF-moduler, så det ikke gør ondt i fremtiden.
Ved afslutningen af foredraget vil deltagerne være mere fortrolige med ressourcestyringsprincipper i Terraform, bedste praksis forbundet med moduler i Terraform og nogle kontinuerlige integrationsprincipper i forbindelse med infrastrukturstyring.
Disclaimer: Jeg bemærker, at denne rapport er dateret november 2018 – der er allerede gået 2 år. Den version af Terraform 0.11, der er omtalt i rapporten, understøttes ikke længere. I løbet af de seneste 2 år er der udgivet 2 nye udgivelser, som indeholder en masse innovationer, forbedringer og ændringer. Vær opmærksom på dette og tjek dokumentationen.
referencer:
- +
- — autoformatering af kode og dokumentation
- — generator af Terraform-moduler (WIP)
- — Terraform kodegenerator fra visuelle diagrammer (WIP)
- www.terraform-best-practices.com
- (Nye indlæg er på min personlige hjemmeside www.antonbabenko.com/)
- @antonbabenko - Twitter, og en masse forskellige Slacks
Mit navn er Anton Babenko. Nogle af jer brugte sikkert den kode, jeg skrev. Jeg vil nu tale om dette med mere selvtillid end nogensinde, fordi jeg har adgang til statistik.
Jeg arbejder på Terraform og har været aktiv deltager og bidragyder til en lang række open source-projekter relateret til Terraform og Amazon siden 2015.
Siden da har jeg skrevet nok kode til at sætte det på en interessant måde. Og jeg vil prøve at fortælle dig om dette nu.
Jeg vil tale om forviklingerne og detaljerne ved at arbejde med Terraform. Men det er egentlig ikke emnet for HighLoad. Og nu vil du forstå hvorfor.
Med tiden begyndte jeg at skrive Terraform-moduler. Brugere skrev spørgsmål, jeg omskrev dem. Derefter skrev jeg forskellige hjælpeprogrammer til at formatere koden ved hjælp af en pre-commit hook osv.
Der var mange spændende projekter. Jeg kan godt lide kodegenerering, fordi jeg godt kan lide, at computeren udfører mere og mere arbejde for mig og programmøren, så jeg arbejder i øjeblikket på en Terraform-kodegenerator fra visuelle diagrammer. Måske nogle af jer har set dem. Det er smukke æsker med pile. Og jeg synes, det er fantastisk, hvis du kan klikke på knappen "Eksporter" og få det hele som kode.
Jeg er fra Ukraine. Jeg har boet i Norge i mange år.
Også oplysninger til denne rapport blev indsamlet fra personer, der kender mit navn og finder mig på sociale netværk. Jeg har næsten altid det samme kaldenavn.
Som jeg nævnte, er jeg hovedvedligeholder af Terraform AWS-moduler, som er et af de største repositories på GitHub, hvor vi hoster moduler til de mest almindelige opgaver: VPC, Autoscaling, RDS.
Og det, du har hørt nu, er det mest basale. Hvis du tvivler på, at du forstår, hvad Terraform er, så er det bedre at bruge din tid et andet sted. Der vil være en masse fagudtryk her. Og jeg tøvede ikke med at erklære rapportens niveau for det højeste. Det betyder, at jeg kan tale ved at bruge alle de mulige udtryk uden megen forklaring.
Terraform dukkede op i 2014 som et hjælpeprogram, der tillod dig at skrive, planlægge og administrere infrastruktur som kode. Nøglekonceptet her er "infrastruktur som kode."
Al dokumentation er som sagt skrevet ind . Jeg håber, at de fleste kender til denne side og har læst dokumentationen. Hvis ja, så er du på det rigtige sted.
Sådan ser en almindelig Terraform-konfigurationsfil ud, hvor vi først definerer nogle variabler.
I dette tilfælde definerer vi "aws_region".
Derefter beskriver vi, hvilke ressourcer vi ønsker at skabe.
Vi kører nogle kommandoer, især "terraform init" for at indlæse afhængigheder og udbydere.
Og vi kører kommandoen "terraform apply" for at kontrollere, om den angivne konfiguration matcher de ressourcer, vi oprettede. Da vi ikke har oprettet noget før, beder Terraform os om at oprette disse ressourcer.
Det bekræfter vi. Således skaber vi en spand kaldet sønegl.
Der er også flere lignende hjælpeprogrammer. Mange af jer, der bruger Amazon, kender AWS CloudFormation eller Google Cloud Deployment Manager eller Azure Resource Manager. Hver af dem har sin egen implementering af en eller anden art til styring af ressourcer inden for hver af disse offentlige cloud-udbydere. Terraform er især nyttig, fordi den giver dig mulighed for at administrere over 100 udbydere. (Flere detaljer )
De mål, som Terraform har forfulgt lige fra begyndelsen:
- Terraform giver et enkelt overblik over ressourcer.
- Giver dig mulighed for at understøtte alle moderne platforme.
- Og Terraform er designet fra begyndelsen som et hjælpeprogram, der giver dig mulighed for at ændre infrastruktur sikkert og forudsigeligt.
I 2014 lød ordet "forudsigelig" meget usædvanligt i denne sammenhæng.
Terraform er et universelt værktøj. Hvis du har en API, så kan du kontrollere absolut alt:
- Du kan bruge mere end 120 udbydere til at administrere alt, hvad du ønsker.
- For eksempel kan du bruge Terraform til at beskrive adgang til GitHub-depoter.
- Du kan endda oprette og lukke fejl i Jira.
- Du kan administrere New Relic-metrics.
- Du kan endda oprette filer i dropbox, hvis du virkelig vil.
Det hele opnås ved hjælp af Terraform-udbydere, som har en åben API, der kan beskrives i Go.
Lad os sige, at vi begyndte at bruge Terraform, læste noget dokumentation på webstedet, så noget video og begyndte at skrive main.tf, som jeg viste på de tidligere slides.
Og alt er fantastisk, du har en fil, der opretter en VPC.
Hvis du vil oprette en VPC, så angiver du cirka disse 12 linjer. Beskriv i hvilken region du vil oprette, hvilken cidr_blok af IP-adresser du skal bruge. Det er alt.
Naturligvis vil projektet gradvist vokse.
Og du vil tilføje en masse nye ting der: ressourcer, datakilder, du vil integrere med nye udbydere, pludselig vil du bruge Terraform til at administrere brugere på din GitHub-konto osv. Du vil måske bruge forskellige DNS-udbydere, kryds alt. Terraform gør dette nemt.
Lad os se på følgende eksempel.
Du tilføjer gradvist internet_gateway, fordi du ønsker, at ressourcer fra din VPC skal have internetadgang. Det er en god idé.
Resultatet er denne main.tf:
Dette er den øverste del af main.tf.
Dette er den nederste del af main.tf.
Så tilføjer du subnet. På det tidspunkt, du vil tilføje NAT-gateways, ruter, routingtabeller og en masse andre undernet, vil du ikke have 38 linjer, men cirka 200-300 linjer.
Det vil sige, din main.tf-fil vokser gradvist. Og ganske ofte lægger folk alt i én fil. 10-20 Kb vises i main.tf. Forestil dig, at 10-20 Kb er tekstindhold. Og alt er forbundet med alt. Dette er efterhånden svært at arbejde med. 10-20 Kb er et godt brugercase, nogle gange mere. Og folk tror ikke altid, at det er dårligt.
Som i almindelig programmering, altså ikke infrastruktur som kode, er vi vant til at bruge en masse forskellige klasser, pakker, moduler, grupperinger. Terraform giver dig mulighed for at gøre stort set det samme.
- Koden vokser.
- Afhængigheder mellem ressourcer vokser også.
Og vi har et stort, stort behov. Vi forstår, at vi ikke kan leve sådan længere. Vores kode er ved at blive enorm. 10-20 Kb er selvfølgelig ikke særlig stort, men vi taler kun om netværksstakken, dvs. du har kun tilføjet netværksressourcer. Vi taler ikke om Application Load Balancer, deployment ES cluster, Kubernetes osv., hvor 100 Kb nemt kan væves ind. Hvis du skriver alt dette ned, vil du meget hurtigt lære, at Terraform tilbyder Terraform-moduler.
Terraform-moduler er en selvstændig Terraform-konfiguration, der administreres som en gruppe. Det er alt, du behøver at vide om Terraform-moduler. De er slet ikke smarte, de tillader dig ikke at lave komplekse forbindelser afhængigt af noget. Alt dette falder på udviklernes skuldre. Det vil sige, dette er bare en slags Terraform-konfiguration, som du allerede har skrevet. Og du kan simpelthen kalde det som en gruppe.
Så vi forsøger at forstå, hvordan vi vil optimere vores 10-20-30 Kb kode. Vi er efterhånden klar over, at vi skal bruge nogle moduler.
Den første type moduler, du støder på, er ressourcemoduler. De forstår ikke, hvad din infrastruktur går ud på, hvad din virksomhed går ud på, hvor og hvad betingelserne er. Det er netop de moduler, som jeg sammen med open source-fællesskabet administrerer, og som vi fremlægger som de allerførste byggesten til din infrastruktur.
Et eksempel på et ressourcemodul.
Når vi kalder et ressourcemodul, angiver vi, fra hvilken sti vi skal indlæse dets indhold.
Vi angiver, hvilken version vi ønsker at downloade.
Vi fremfører en masse argumenter der. Det er alt. Det er alt, hvad vi behøver at vide, når vi bruger dette modul.
Mange mennesker tror, at hvis de bruger den nyeste version, vil alt være stabilt. Men nej. Infrastrukturen skal være versioneret, vi skal klart svare på, hvilken version denne eller hin komponent blev installeret til.
Her er koden, der er inde i dette modul. Sikkerhedsgruppemodul. Her går rullen til 640. linje. At skabe en sikkerheds-croup-ressource i Amazon i enhver mulig konfiguration er en meget ikke-triviel opgave. Det er ikke nok blot at oprette en sikkerhedsgruppe og fortælle den, hvilke regler den skal videregive til den. Det ville være meget enkelt. Der er en million forskellige restriktioner inde i Amazon. Hvis du f.eks. bruger VPC-slutpunkt, præfiksliste, forskellige API'er og forsøger at kombinere alt dette med alt andet, så tillader Terraform dig ikke at gøre dette. Og Amazon API tillader heller ikke dette. Derfor er vi nødt til at skjule al denne forfærdelige logik i et modul og give brugerkoden, der ser sådan ud.
Brugeren behøver ikke at vide, hvordan den er lavet indvendigt.
Den anden type moduler, som består af ressourcemoduler, løser allerede problemer, der er mere anvendelige for din virksomhed. Ofte er dette et sted, der er en udvidelse for Terraform og sætter nogle stive værdier for tags, for virksomhedens standarder. Du kan også tilføje funktionalitet der, som Terraform ikke i øjeblikket tillader dig at bruge. Det er lige nu. Nu version 0.11, som er ved at blive fortid. Men stadigvæk er præprocessorer, jsonnet, cookiecutter og en masse andre ting den hjælpemekanisme, der skal bruges til fuldgyldigt arbejde.
Herefter vil jeg vise nogle eksempler på dette.
Infrastrukturmodulet kaldes på nøjagtig samme måde.
Kilden, hvorfra indholdet skal downloades, er angivet.
En masse værdier sendes ind og overføres til dette modul.
Dernæst, inde i dette modul, kaldes en masse ressourcemoduler til at oprette en VPC eller Application Load Balancer, eller for at oprette en sikkerhedsgruppe eller for en Elastic Container Service-klynge.
Der er to typer moduler. Dette er vigtigt at forstå, fordi de fleste af de oplysninger, jeg har grupperet i denne rapport, ikke er skrevet i dokumentationen.
Og dokumentationen i Terraform lige nu er ret problematisk, fordi den bare siger, at der er disse funktioner, du kan bruge dem. Men hun siger ikke, hvordan man bruger disse funktioner, hvorfor det er bedre at bruge dem. Derfor skriver et meget stort antal mennesker noget, som de ikke kan leve med.
Lad os tage et kig på, hvordan man skriver disse moduler næste gang. Så vil vi se, hvordan man kalder dem, og hvordan man arbejder med koden.
Terraform Registry -
Tip #0 er ikke at skrive ressourcemoduler. De fleste af disse moduler er allerede skrevet til dig. Som sagt er de open source, de indeholder ingen af din forretningslogik, de har ikke hårdkodede værdier for IP-adresser, adgangskoder osv. Modulet er meget fleksibelt. Og det er højst sandsynligt allerede skrevet. Der er mange moduler til ressourcer fra Amazon. Omkring 650. Og de fleste af dem er af god kvalitet.
I dette eksempel kom nogen til dig og sagde: "Jeg vil gerne være i stand til at administrere en database. Opret et modul, så jeg kan oprette en database." Personen kender ikke implementeringsdetaljerne for hverken Amazon eller Terraform. Han siger blot: "Jeg vil administrere MSSQL." Det vil sige, vi mener, at det vil kalde vores modul, videregive motortypen der, og angive tidszonen.
Og en person skal ikke vide, at vi vil oprette to forskellige ressourcer inde i dette modul: en til MSSQL, den anden for alt andet, kun fordi du i Terraform 0.11 ikke kan angive tidszoneværdier som valgfrie.
Og ved udgangen fra dette modul vil en person blot kunne modtage en adresse. Han vil ikke vide, fra hvilken database, fra hvilken ressource vi opretter alt dette internt. Dette er et meget vigtigt element i fortielsen. Og det gælder ikke kun for de moduler, der er offentlige i open source, men også for de moduler, som du vil skrive inde i dine projekter og teams.
Dette er det andet argument, som er ret vigtigt, hvis du har brugt Terraform i et stykke tid. Du har et repository, hvor du lægger alle dine Terraform-moduler til din virksomhed. Og det er helt normalt, at dette projekt med tiden vokser til en størrelse på en eller to megabyte. Det er fint.
Men problemet er, hvordan Terraform kalder disse moduler. For eksempel, hvis du kalder et modul for at oprette hver enkelt bruger, vil Terraform først indlæse hele depotet og derefter navigere til den mappe, hvor det specifikke modul er placeret. På denne måde vil du downloade en megabyte hver gang. Hvis du administrerer 100 eller 200 brugere, vil du downloade 100 eller 200 megabyte og derefter gå til den mappe. Så du vil naturligvis ikke downloade en masse ting, hver gang du trykker på "Terraform init".
Der er to løsninger på dette problem. Den første er at bruge relative stier. På denne måde angiver du i koden, at mappen er lokal (./). Og før du starter noget, laver du en Git-kloning af dette lager lokalt. På denne måde gør du det én gang.
Der er selvfølgelig mange ulemper. For eksempel kan du ikke bruge versionering. Og det er nogle gange svært at leve med.
Anden løsning. Hvis du har mange undermoduler, og du allerede har en form for etableret pipeline, så er der MBT-projektet, som giver dig mulighed for at samle mange forskellige pakker fra et monorepository og uploade dem til S3. Dette er en meget god måde. Således vil iam-user-1.0.0.zip-filen kun veje 1 Kb, fordi koden til at oprette denne ressource er meget lille. Og det vil virke meget hurtigere.
Lad os tale om, hvad der ikke kan bruges i moduler.
Hvorfor er dette ondt i moduler? Det værste er at antage bruger. Antag, at brugeren er en udbydergodkendelsesindstilling, der kan bruges af forskellige personer. For eksempel vil vi alle assimilere rollen. Det betyder, at Terraform påtager sig denne rolle. Og så med denne rolle vil den udføre andre handlinger.
Og det onde er, at hvis Vasya kan lide at oprette forbindelse til Amazon på én måde, for eksempel ved at bruge standard miljøvariablen, og Petya kan lide at bruge sin delte nøgle, som han har et hemmeligt sted, så kan du ikke angive begge dele i Terraform. Og for at de ikke skal opleve lidelse, er der ingen grund til at angive denne blok i modulet. Dette skal angives på et højere niveau. Det vil sige, at vi har et ressourcemodul, et infrastrukturmodul og en sammensætning oveni. Og dette bør angives et sted højere.
Det andet onde er proviantøren. Her er ondskaben ikke så triviel, for hvis du skriver kode, og det virker for dig, så tænker du måske, at hvis det virker, hvorfor så ændre det.
Det onde er, at du for det første ikke altid kontrollerer, hvornår denne provisioner vil blive lanceret. Og for det andet styrer du ikke, hvad aws ec2 betyder, altså taler vi om Linux eller Windows nu. Så du kan ikke skrive noget, der fungerer ens på forskellige operativsystemer eller til forskellige brugertilfælde.
Det mest almindelige eksempel, som også er angivet i den officielle dokumentation, er, at hvis du skriver aws_instance og specificerer en masse argumenter, så er der ikke noget galt i det, hvis du angiver provideren "local-exec" der og kører din ansible- spillebog.
Faktisk, ja, det er der ikke noget galt i. Men bogstaveligt talt snart vil du indse, at denne lokale-exec-ting ikke eksisterer, for eksempel i launch_configuration.
Og når du bruger launch_configuration, og du vil oprette en autoskaleringsgruppe fra én instans, så er der i launch_configuration ikke noget begreb om "provisioner". Der er begrebet "brugerdata".
Derfor er en mere universel løsning at bruge brugerdata. Og den vil blive lanceret enten på selve instansen, når instansen er tændt, eller i de samme brugerdata, når autoskaleringsgruppen bruger denne launch_configuration.
Hvis du stadig ønsker at køre provisioneren, fordi den er en limningskomponent, når en ressource er oprettet, skal du på det tidspunkt køre din provisioner, din kommando. Der er mange sådanne situationer.
Og den mest korrekte ressource til dette kaldes null_resource. Null_resource er en dummy-ressource, der aldrig faktisk oprettes. Det rører ikke noget, ingen API, ingen autoskalering. Men det giver dig mulighed for at kontrollere, hvornår kommandoen skal køres. I dette tilfælde køres kommandoen under oprettelsen.
Link
Der er flere tegn. Jeg vil ikke komme nærmere ind på alle tegnene. Der er en artikel om dette. Men hvis du har arbejdet med Terraform eller brugt andres moduler, så har du ofte bemærket, at mange moduler, ligesom det meste af koden i open source, er skrevet af folk til deres egne behov. En mand skrev det og løste sit problem. Jeg satte den fast i GitHub, lad den leve. Det vil leve, men hvis der ikke er dokumentation og eksempler der, så vil ingen bruge det. Og hvis der ikke er nogen funktionalitet, der giver dig mulighed for at løse lidt mere end sin specifikke opgave, så er der heller ingen, der vil bruge det. Der er så mange måder at miste brugere på.
Hvis du vil skrive noget, så folk vil bruge det, så anbefaler jeg at følge disse tegn.
De er:
- Dokumentation og eksempler.
- Fuld funktionalitet.
- Rimelige standardindstillinger.
- Ren kode.
- Tests.
Tests er en anden situation, fordi de er ret svære at skrive. Jeg tror mere på dokumentation og eksempler.
Så vi så på, hvordan man skriver moduler. Der er to argumenter. Den første, som er den vigtigste, er ikke at skrive, hvis du kan, fordi en flok mennesker allerede har udført disse opgaver før dig. Og for det andet, hvis du stadig beslutter dig, så prøv ikke at bruge udbydere i moduler og udbydere.
Dette er den grå del af dokumentationen. Du tænker måske nu: "Noget er uklart. Ikke overbevist." Men vi får se om seks måneder.
Lad os nu tale om, hvordan man kalder disse moduler.
Vi forstår, at vores kode vokser over tid. Vi har ikke længere én fil, vi har allerede 20 filer. De er alle i én mappe. Eller måske fem mapper. Måske begynder vi på en eller anden måde at opdele dem efter region, efter nogle komponenter. Så forstår vi, at nu har vi nogle rudimenter af synkronisering og orkestrering. Det vil sige, at vi skal forstå, hvad vi skal gøre, hvis vi ændrede netværksressourcer, hvad vi skal gøre med resten af vores ressourcer, hvordan vi forårsager disse afhængigheder osv.
Der er to yderpunkter. Den første yderlighed er alt i ét. Vi har en masterfil. For øjeblikket var dette den officielle bedste praksis på Terraform-webstedet.
Men nu er det skrevet som forældet og fjernet. Over tid indså Terraform-fællesskabet, at dette langt fra var den bedste praksis, fordi folk begyndte at bruge projektet på forskellige måder. Og der er problemer. For eksempel når vi lister alle afhængigheder ét sted. Der er situationer, hvor vi klikker på "Terraform plan", og indtil Terraform opdaterer tilstandene for alle ressourcer, kan der gå meget tid.
Meget tid er f.eks. 5 minutter. For nogle er dette meget tid. Jeg har set tilfælde, hvor det tog 15 minutter. AWS API brugte 15 minutter på at finde ud af, hvad der skete med hver ressources tilstand. Dette er et meget stort område.
Og naturligvis vil et relateret problem dukke op, når du vil ændre noget ét sted, så venter du 15 minutter, og det giver dig et lærred af nogle ændringer. Du spyttede, skrev "Ja", og noget gik galt. Dette er et meget reelt eksempel. Terraform forsøger ikke at beskytte dig mod problemer. Det vil sige, skriv hvad du vil. Der vil være problemer - dine problemer. Mens Terraform 0.11 ikke forsøger at hjælpe dig på nogen måde. Der er visse interessante steder i 0.12, der giver dig mulighed for at sige: "Vasya, du vil virkelig have det her, kan du komme til fornuft?"
Den anden måde er at reducere dette område, det vil sige, at opkald fra et sted kan være mindre forbundet fra et andet sted.
Det eneste problem er, at du skal skrive mere kode, dvs. du skal beskrive variabler i et stort antal filer og opdatere dette. Nogle mennesker kan ikke lide det. Det er normalt for mig. Og nogle mennesker tænker: "Hvorfor skrive dette forskellige steder, jeg lægger det hele ét sted." Dette er muligt, men dette er den anden yderlighed.
Hvem bor alt dette på ét sted? En, to, tre personer, det vil sige, nogen bruger det.
Og hvem kalder én bestemt komponent, én blok eller ét infrastrukturmodul? Fem til syv personer. Det her er sejt.
Det mest almindelige svar er et sted i midten. Hvis projektet er stort, så vil du ofte have en situation, hvor ingen løsning er egnet og ikke alt fungerer derude, så du ender med en blanding. Det er der ikke noget galt med, så længe du forstår, at begge dele har fordele.
Hvis noget ændrede sig i stakken VPC, og du ønskede at anvende disse ændringer på EC2, dvs. du ønskede at opdatere autoskaleringsgruppen, fordi du havde et nyt undernet, så kalder jeg denne form for afhængighedsorkestrering. Der er nogle løsninger: hvem bruger hvad?
Jeg kan foreslå, hvilke løsninger der er. Du kan bruge Terraform til at gøre magien, eller du kan bruge make-filer til at bruge Terraform. Og se om noget har ændret sig der, kan du starte det her.
Hvordan kan du lide denne beslutning? Er der nogen, der tror, at dette er en fed løsning? Jeg ser et smil, tvivlen har åbenbart sneget sig ind.
Selvfølgelig skal du ikke prøve dette derhjemme. Terraform blev aldrig designet til at blive kørt fra Terraform.
Ved en rapport sagde de til mig: "Nej, det her vil ikke fungere." Pointen er, at det ikke burde virke. Selvom det ser så imponerende ud, når du kan starte Terraform fra Terraform, og så Terraform, bør du ikke gøre det. Terraform skal altid starte meget nemt.
Har du brug for opkaldsorkestrering, når noget har ændret sig ét sted, så er der Terragrunt.
Terragrunt er et hjælpeprogram, en tilføjelse til Terraform, der giver dig mulighed for at koordinere og orkestrere opkald til infrastrukturmoduler.
En typisk Terraform-konfigurationsfil ser sådan ud.
Du angiver hvilket specifikt modul du vil ringe til.
Hvilke afhængigheder har modulet?
Og hvilke argumenter accepterer dette modul. Det er alt, der er at vide om Terragrunt.
Dokumentationen er der, og der er 1 stjerner på GitHub. Men i de fleste tilfælde er det, hvad du har brug for at vide. Og det er meget nemt at implementere i virksomheder, der lige er begyndt at arbejde med Terraform.
Så orkestrering er Terragrunt. Der er andre muligheder.
Lad os nu tale om, hvordan man arbejder med koden.
Hvis du har brug for at tilføje nye funktioner til din kode, er det i de fleste tilfælde nemt. Du skriver en ny ressource, alt er enkelt.
Hvis du har en ressource, som du har oprettet i forvejen, f.eks. lærte om Terraform efter at du åbnede en AWS-konto og gerne vil bruge de ressourcer, du allerede har, så vil det være hensigtsmæssigt at udvide dit modul på denne måde, så det understøtter brugen af eksisterende ressourcer.
Og understøttede oprettelsen af nye ressourcer ved hjælp af blokressourcen.
På output returnerer vi altid output-id afhængig af hvad der blev brugt.
Det andet meget væsentlige problem i Terraform 0.11 er at arbejde med lister.
Vanskeligheden er, at hvis vi har sådan en liste over brugere.
Og når vi opretter disse brugere ved hjælp af blokressourcer, så går alt fint. Vi gennemgår hele listen og opretter en fil til hver. Alt er fint. Og så skal f.eks user3, som er i midten, fjernes herfra, så bliver alle de ressourcer, der blev oprettet efter ham, genskabt, fordi indekset ændres.
Arbejde med lister i et stateful miljø. Hvad er et stateful miljø? Dette er den situation, hvor en ny værdi skabes, når denne ressource skabes. For eksempel AWS Access Key eller AWS Secret Key, dvs. når vi opretter en bruger, modtager vi en ny adgang eller hemmelig nøgle. Og hver gang vi sletter en bruger, vil denne bruger have en ny nøgle. Men dette er ikke feng shui, fordi brugeren ikke vil være venner med os, hvis vi opretter en ny bruger til ham, hver gang nogen forlader holdet.
Dette er løsningen. Dette er kode skrevet i Jsonnet. Jsonnet er et skabelonsprog fra Google.
Denne kommando giver dig mulighed for at acceptere denne skabelon og som output returnerer den en json-fil, der er lavet i henhold til din skabelon.
Skabelonen ser sådan ud.
Terraform giver dig mulighed for at arbejde med både HCL og Json på samme måde, så hvis du har mulighed for at generere Json, så kan du glide det ind i Terraform. Filen med filtypenavnet .tf.json vil blive downloadet med succes.
Og så arbejder vi med det som normalt: terraform init, terramorm gælder. Og vi opretter to brugere.
Nu er vi ikke bange, hvis nogen forlader holdet. Vi redigerer bare json-filen. Vasya Pupkin gik, Petya Pyatochkin forblev. Petya Pyatochkin vil ikke modtage en ny nøgle.
At integrere Terraform med andre værktøjer er egentlig ikke Terraforms opgave. Terraform blev skabt som en platform til at skabe ressourcer, og det er det. Og alt, hvad der kommer op senere, er ikke Terraforms bekymring. Og der er ingen grund til at væve det derind. Der er Ansible, som gør alt hvad du har brug for.
Men situationer opstår, når vi ønsker at udvide Terraform og kalde en kommando, efter at noget er fuldført.
Første vej. Vi opretter et output, hvor vi skriver denne kommando.
Og så kalder vi denne kommando fra shell terraform output og specificerer den værdi, vi ønsker. Således udføres kommandoen med alle de erstattede værdier. Det er meget behageligt.
Anden vej. Dette er brugen af null_resource afhængigt af ændringer i vores infrastruktur. Vi kan kalde den samme lokale exe, så snart id'et for nogle ressourcer ændres.
Naturligvis er alt dette glat på papiret, fordi Amazon, ligesom alle andre offentlige udbydere, har en masse sine egne kantsager.
Det mest almindelige edge-tilfælde er, at når du åbner en AWS-konto, er det ligegyldigt, hvilke regioner du bruger; er denne funktion aktiveret der; måske har du åbnet den efter december 2013; måske bruger du standard i VPC osv. Der er mange begrænsninger. Og Amazon spredte dem gennem hele dokumentationen.
Der er et par ting, jeg anbefaler at undgå.
For at starte skal du undgå alle ikke-hemmelige argumenter i Terraform-planen eller Terraform CLI. Alt dette kan sættes enten i en tfvars-fil eller i en miljøvariabel.
Men du behøver ikke at huske hele denne magiske kommando. Terraform plan – var og afsted. Den første variabel er var, den anden variabel er var, den tredje, fjerde. Det vigtigste princip for infrastruktur som kode, som jeg oftest bruger, er, at jeg bare ved at se på koden, skal have en klar forståelse af, hvad der er installeret der, i hvilken tilstand og med hvilke værdier. Så jeg behøver ikke at læse dokumentationen eller spørge Vasya, hvilke parametre han brugte til at skabe vores klynge. Jeg skal bare åbne en fil med filtypenavnet tfvars, som ofte matcher miljøet, og se på alt der.
Brug heller ikke målargumenter til at reducere omfanget. Til dette er det meget nemmere at bruge små infrastrukturmoduler.
Der er heller ingen grund til at begrænse og øge paralleliteten. Hvis jeg har 150 ressourcer, og jeg vil øge Amazon-parallelismen fra standard 10 til 100, så vil der højst sandsynligt gå noget galt. Eller det går måske godt nu, men når Amazon siger, at du foretager for mange opkald, får du problemer.
Terraform vil forsøge at genstarte de fleste af disse problemer, men du opnår næsten ingenting. Parallelism=1 er en vigtig ting at bruge, hvis du falder over en fejl inde i AWS API eller inde i Terraform-udbyderen. Og så skal du specificere: parallelisme=1 og vente, indtil Terraform afslutter et opkald, så det andet, så det tredje. Han vil lancere dem én efter én.
Folk spørger mig ofte: "Hvorfor tror jeg, at Terraform-arbejdsområder er onde?" Jeg mener, at princippet om infrastruktur som kode er at se, hvilken infrastruktur der er skabt og med hvilke værdier.
Arbejdsrum blev ikke oprettet af brugere. Dette betyder ikke, at brugere skrev i GitHub-problemer, at vi ikke kan leve uden Terraform-arbejdsområder. Nej ikke sådan her. Terraform Enterprise er en kommerciel løsning. Terraform fra HashiCorp besluttede, at vi havde brug for arbejdsrum, så vi arkiverede det. Jeg synes, det er meget nemmere at lægge det i en separat mappe. Så kommer der lidt flere filer, men det bliver mere overskueligt.
Hvordan arbejder man med koden? Faktisk er arbejdet med lister den eneste smerte. Og tag Terraform lettere. Dette er ikke den ting, der vil gøre alt godt for dig. Der er ingen grund til at skubbe alt, hvad der er skrevet i dokumentationen dertil.
Emnet for rapporten var skrevet "for fremtiden." Jeg vil tale om dette meget kort. For fremtiden betyder det, at 0.12 snart vil blive frigivet.
0.12 er et væld af nye ting. Kommer du fra almindelig programmering, så savner du alle mulige dynamiske blokke, loops, korrekte og betingede sammenligningsoperationer, hvor venstre og højre side ikke beregnes samtidigt, men afhængig af situationen. Du savner det meget, så 0.12 løser det for dig.
Men! Hvis du skriver mindre og mere enkelt ved at bruge færdige moduler og tredjepartsløsninger, så behøver du ikke vente og håbe på, at 0.12 kommer og ordner alt for dig.
Tak for rapporten! Du talte om infrastruktur som kode og sagde bogstaveligt talt et ord om tests. Er der behov for test i moduler? Hvis ansvar er dette? Skal jeg selv skrive det, eller er det modulernes ansvar?
Det næste år vil være fyldt med rapporter om, at vi har besluttet at teste alt. Hvad man skal teste er det største spørgsmål. Der er mange afhængigheder, mange begrænsninger fra forskellige udbydere. Når du og jeg taler, og du siger: "Jeg har brug for test", så spørger jeg: "Hvad vil du teste?" Du siger, at du vil teste i din region. Så siger jeg, at det her ikke virker i min region. Det vil sige, at vi ikke engang kan blive enige om dette. For ikke at nævne, at der er mange tekniske problemer. Altså hvordan man skriver disse test, så de er fyldestgørende.
Jeg undersøger aktivt dette emne, dvs. hvordan man automatisk genererer test baseret på den infrastruktur, du skrev. Det vil sige, hvis du skrev denne kode, så skal jeg køre den, ud fra dette kan jeg lave tests.
er et af de hyppigst nævnte biblioteker, der giver dig mulighed for at skrive integrationstest til Terraform. Dette er et af hjælpeprogrammerne. Jeg foretrækker DSL-typen, for eksempel rspec.
Anton, tak for rapporten! Mit navn er Valery. Lad mig stille et lille filosofisk spørgsmål. Der er, betinget, klargøring, der er udrulning. Provisionering skaber min infrastruktur, i udrulning fylder vi den med noget nyttigt, for eksempel servere, applikationer osv. Og det er i mit hoved, at Terraform er mere til provisionering, og Ansible er mere til udrulning, fordi Ansible også er til fysisk Infrastrukturen giver dig mulighed for at installere nginx, Postgres. Men samtidig ser det ud til, at Ansible tillader provisionering af for eksempel Amazon- eller Google-ressourcer. Men Terraform giver dig også mulighed for at implementere noget software ved hjælp af dets moduler. Fra dit synspunkt, er der en form for grænse, der går mellem Terraform og Ansible, hvor og hvad er bedre at bruge? Eller synes du for eksempel at Ansible allerede er skrald, skal du prøve at bruge Terraform til alt?
Godt spørgsmål, Valery. Jeg mener, at Terraform ikke har ændret sig med hensyn til formål siden 2014. Det blev skabt til infrastruktur og døde for infrastruktur. Vi havde og vil stadig have et behov for konfigurationsstyring Ansible. Udfordringen er, at der er brugerdata inde i launch_configuration. Og der trækker du Ansible osv. Det er den standard skelnen, som jeg bedst kan lide.
Hvis vi taler om i smuk infrastruktur, så er der hjælpeprogrammer som Packer, der samler dette billede. Og så bruger Terraform datakilden til at finde dette billede og opdatere dets launch_configuration. Det vil sige, på denne måde er pipelinen, at vi først trækker Tracker, derefter trækker Terraform. Og hvis opbygning sker, så sker der en ny ændring.
Hej! Tak for rapporten! Mit navn er Misha, RBS-firma. Du kan ringe til Ansible via provisioner, når du opretter en ressource. Ansible har også et emne kaldet dynamisk beholdning. Og du kan først ringe til Terraform og derefter ringe til Ansible, som vil tage ressourcer fra staten og udføre det. Hvad er bedre?
Folk bruger begge med lige stor succes. Det forekommer mig, at dynamisk opgørelse i Ansible er en praktisk ting, hvis vi ikke taler om autoskaleringsgruppe. For i autoskaleringsgruppen har vi allerede vores eget værktøjssæt, som hedder launch_configuration. I launch_configuration registrerer vi alt, hvad der skal lanceres, når vi opretter en ny ressource. Derfor er det efter min mening overkill at bruge dynamisk inventar og læse Terraform ts-filen med Amazon. Og hvis du bruger andre værktøjer, hvor der ikke er noget begreb om "autoskaleringsgruppe", for eksempel, du bruger DigitalOcean eller en anden udbyder, hvor der ikke er nogen autoskaleringsgruppe, så skal du manuelt trække API'en, finde IP-adresser, oprette en dynamisk opgørelsesfil, og Ansible vil allerede vandre gennem den. Det vil sige, for Amazon er der launch_configuration, og for alt andet er der dynamisk inventar.
Kilde: www.habr.com