At præsentere infrastruktur som kode i et gentageligt tekstformat er en enkel bedste praksis for systemer, som ikke kræver besvær. Denne praksis kaldes — , og indtil nu er der to populære værktøjer til at implementere det, især i AWS: og .
Jeg sammenligner erfaringen med Terraform og CloudFormation
Før jeg kom til (også kendt som ) arbejdede jeg , hvor jeg brugte Terraform i tre år. På den nye arbejdsplads brugte jeg også meget Terraform, men så pressede virksomheden på for at overgå til alt i stil med Amazon, inklusive CloudFormation. Jeg arbejdede hårdt på at udvikle bedste praksis for begge værktøjer, som blev anvendt i meget komplekse arbejdsgange i stor skala. Efter nøje at have overvejet konsekvenserne af overgangen fra Terraform til CloudFormation, er jeg overbevist om, at Terraform sandsynligvis er det bedste valg for organisationen.
Terraform er skræmmende
Beta-versionen af softwaren
Terraform har ikke engang haft version 1.0 endnu, og det er en gyldig grund til ikke at bruge det. Siden jeg første gang prøvede det, har det ændret sig meget, men dengang terraform apply brød ofte sammen efter et par opdateringer eller blot efter et par års drift. Jeg ville sige, at "nu er alt anderledes", men... det siger alle, ikke? Der er ændringer, der ikke er kompatible med tidligere versioner, selvom de er passende, og der er endda en følelse af, at syntaksen og abstraktionerne for ressourceopbevaringssystemer nu fungerer godt. Værktøjet virker til at være blevet bedre, men… :-0
På den anden side har AWS gjort et godt stykke arbejde med at opretholde kompatibilitet med tidligere versioner. Alt dette fordi deres tjenester ofte testes grundigt internt, og først derefter offentliggøres de under nye navne. Så "de har gjort et godt stykke arbejde" er næsten en underdrivelse. At opretholde kompatibilitet med tidligere versioner af API'et for et så mangfoldigt og komplekst system som AWS er utroligt vanskeligt. Enhver, der har skullet opretholde offentlige API'er, der bruges så bredt, skal forstå, hvor svært det er at gøre det i så mange år. Men CloudFormations adfærd er, efter hvad jeg kan huske, aldrig ændret sig gennem årene.
Mød fod... det er en kugle
Så vidt jeg ved, kan man ikke slette ressourcen uden forstående Det er umuligt at importere en CloudFormation-stak fra sin egen CF-stak. Det er stort set det samme med Terraform. Det gør det muligt at importere eksisterende ressourcer til sin stak. Funktionen er, kan man sige, fantastisk, men med stor magt følger også stort ansvar. Så snart man tilføjer en ressource til stakken, kan man ikke slette eller ændre denne ressource, mens man arbejder med sin stak. En gang kom det tilbage for at hjemsøge mig. På Twitch-siden importerede nogen, uden at have onde hensigter, utilsigtet en andens AWS-sikkerhedsgruppe til sin egen Terraform-stak. De indtastede et par kommandoer og… sikkerhedsgruppen (sammen med indgående trafik) forsvandt.
Terraform Den Store
Gendannelse fra ufuldstændige tilstande
Nogle gange kan CloudFormation ikke fuldt ud overgå fra én tilstand til en anden. I så fald vil det forsøge at vende tilbage til den tidligere tilstand. Desværre er det ikke altid muligt. Fejlfinding af det, der er opstået, kan være ret skræmmende — man ved aldrig, om CloudFormation bliver glad for at blive ‘hacket’ — selvom det er for at reparere. Om det overhovedet vil kunne vende tilbage til den tidligere tilstand, kan det ikke vurdere ordentligt, og som standard hænger det i timevis i venten på et mirakel.
Terraform derimod er tilbøjelig til at komme sig efter mislykkede overgange på en mere elegant måde og tilbyder værktøjer til udvidet fejlfinding.
Klarere ændringer i dokumentets tilstande
«Okay, belastningsbalance, du ændrer dig. Men hvordan?»
—udtrykt bekymret ingeniør, klar til at trykke på knappen ‘accepter’.
Nogle gange skal jeg lave nogle justeringer på belastningsbalanceren i CloudFormation-stakken — for eksempel tilføje portnummeret eller ændre sikkerhedsgruppen. CloudFormation viser ændringerne svagt. Jeg genkender mig selv som på nåle, hvor jeg tjekker yaml-filen ti gange for at være sikker på, at jeg ikke har slettet noget vigtigt eller tilføjet noget unødvendigt.
Terraform er på dette område meget mere gennemsigtig. Nogle gange er den endda for gennemsigtig (læs: irriterende). Heldigvis har den seneste version inkluderet forbedret visning af ændringer — nu kan man helt klart se, hvad der ændres.
Fleksibilitet
Skriv software fra slutningen.
For at sige det lige ud, den vigtigste egenskab ved langtidsholdbar software er evnen til at tilpasse sig ændringer. Når man skriver software, bør man ofte tænke baglæns. Jeg har ofte været skyld i, at jeg tog en "simpel" service, og så forsøgte at presse det hele ind i en samlet CloudFormation- eller Terraform-stack. Og selvfølgelig, efter flere måneder opdagede jeg, at jeg ikke havde forstået det korrekt, og at servicen i virkeligheden ikke var simpel! Jeg måtte på en eller anden måde opdele den store stack i mindre dele. Når man arbejder med CloudFormation, er det kun muligt at gøre dette, hvis man først genskaber den eksisterende stack, og det gør jeg ikke med mine databaser. Terraform tillod mig derimod at dissekere stacken og opdele den i mere forståelige mindre dele.
Moduler i git
Det er meget lettere at dele Terraform-kode mellem mange stacks end CloudFormation-kode. Med Terraform kan man placere koden i et Git-repositorium og tilgå det ved at bruge semantisk versionskontrol. Enhver, der har adgang til dette repositorium, kan genbruge den fælles kode. Den tilsvarende løsning i CloudFormation er S3, men den har ikke de samme fordele, og der er ikke nogen grund til, at vi skulle opgive git til fordel for S3.
Organisationen voksede, og evnen til at dele fælles stacks nåede et kritisk niveau. Med Terraform er dette nemt og naturligt, mens CloudFormation vil få dig til at hoppe gennem ringe, før noget virker på samme måde.
Operations as code
"Lad os skripte det, og så er det klart."
- ingeniøren tre år før han opfandt Terraform-cyklen.
Når vi taler om softwareudvikling, er Go eller et program på Java ikke bare kode.
Code as Code
Der findes også infrastrukturen, som det kører på.
Infrastructure as Code
Men hvor kommer den fra? Hvordan overvåger man den? Hvor befinder din kode sig? Skal udviklerne have tilladelse til adgang?
Operations as Code
At være softwareudvikler handler ikke bare om at skrive kode.
Ikke kun AWS: du bruger sandsynligvis tjenester fra andre udbydere. SignalFx, PagerDuty eller GitHub. Måske har du en intern Jenkins-server til CI/CD eller et internt Grafana-dashboard til overvågning. Infra as Code vælges af forskellige grunde, og hver eneste er lige så vigtig for alting relateret til software.
Da jeg arbejdede hos Twitch, optimerede vi tjenester indeni blandede indlejrede systemer og AWS-systemer. Vi producerede og vedligeholdte mange mikrotjenester og øgede driftsomkostningerne. Diskusionerne foregik omtrent i denne stil:
- Jeg: Damn, det kræver en del bevægelser at starte en mikrotjeneste. Jeg kommer til at bruge det her for at oprette en AWS-konto (vi gik efter 2 konti på mikrotjeneste), så det her — til opsætning af alarmer, og dette — til kode-repositoriet, og dette — til listen over e-mailadresser, og så det her…
- Lead: Lad os skripte det og så være færdige.
- Jeg: Okay, men selve scriptet vil ændre sig. Vi får brug for en måde at kontrollere, at alle disse indbyggede Amazon-ting har den aktuelle status.
- Lead: Lyder godt. Og til det vil vi skrive et script.
- Jeg: Fantastisk! Og scriptet skal helt sikkert have nogle parametre. Kan det tage dem?
- Lead: Ja, det kan det! Det skal finde sin vej.
- Jeg: Processen kan ændre sig, og der kan gå tab af bagudkompatibilitet. Vi får brug for en form for semantisk versionskontrol.
- Lead: Fremragende idé!
- Jeg: Værktøjerne kan ændres manuelt i brugergrænsefladen. Vi får brug for en måde at kontrollere og rette dette.
…3 år senere:
- Lead: Og vi endte med terraform.
Moralen i fabelen er: selvom du er knyttet til alt det Amazon, bruger du stadig noget, der ikke er fra AWS, og disse tjenester har en status, der benytter et sprog til konfiguration for at synkronisere denne status.
CloudFormation lambda vs git-moduler terraform
lambda er CloudFormation-løsningen til spørgsmålet om brugerlogik. Med lambda kan du eller . Denne tilgang indebærer yderligere kompleksiteter, som ikke findes i den semantiske versionskontrol af git-moduler i Terraform. For mig blev den mest presserende problemstilling at håndtere tilladelser for alle disse bruger-lambdaer (det drejer sig om dusinvis af AWS-konti). Et andet vigtigt problem blev spørgsmålet om, hvad der kom først — hønen eller ægget?: det var relateret til lambda-koden. Selve denne funktion — infrastrukturen og koden — kræver overvågning og opdatering. Den sidste søm i kisten blev besværet ved semantisk opdatering af ændringerne i lambda-koden; der var også behov for at sikre, at staktags handlinger ikke ændrede sig mellem kørselene uden direkte kommando.
Jeg husker, at jeg engang fik lyst til at oprette en kanariefugl-distribution til et Elastic Beanstalk-miljø med en klassisk belastningsbalancer. Det ville være nemmest at lave en anden distribution for EB ved siden af produktionsmiljøet ved at tage et ekstra skridt: at forbinde den autoskalerede kanariefugl-distribution med LB-distributionen i produktionsmiljøet. Og da Terraform bruger , vil det kræve 4 ekstra linjer kode i Terraform. Da jeg spurgte, om der fandtes en tilsvarende løsning i CloudFormation, blev jeg henvist til et helt repository på Git med en distributionspipeline og andet: alt dette var for noget, man kunne gøre med de stakkels 4 linjer Terraform-kode.
Det opdager bedre afvigelse
Sørg for, at virkeligheden stemmer overens med forventningerne.
— en meget kraftfuld funktion ved drift som kode, fordi det hjælper med at sikre, at virkeligheden svarer til forventningerne. Den er tilgængelig både i CloudFormation og Terraform. Men efterhånden som stakken vokser, gav afvigelsesdetektion i CloudFormation flere og flere falske fund.
Med Terraform har du meget mere avancerede livscyklushooks til afvigelsesdetektion. For eksempel kan du indtaste kommandoen direkte i opgavebeskrivelsen for ECS, hvis du vil ignorere ændringer i definitionen af en bestemt opgave uden at ignorere ændringer i hele ECS-distributionen.
CDK og fremtiden for CloudFormation
CloudFormation er svært at administrere i stor målestok på tværs af infrastrukturer. Mange af disse udfordringer er anerkendt, og værktøjet har brug for noget som , en struktur til at definere cloudinfrastruktur i kode og implementere den gennem AWS CloudFormation. Det bliver interessant at se, hvad der venter aws-cdk i fremtiden, men det vil have svært ved at konkurrere med andre fordele ved Terraform; der vil kræves globale ændringer for at indhente CloudFormation.
For at Terraform ikke skuffer
Det er "infrastruktur som KODE", ikke "som tekst".
Mit første indtryk af Terraform var ret dårligt. Jeg tror, jeg bare ikke forstod tilgangen. Næsten alle ingeniører opfatter det i starten utilsigtet som et tekstformat, der skal omdannes til det ønskede infrastruktur. DET SKAL IKKE GØRES.
Selvfølgeligheder om god softwareudvikling gælder også for Terraform.
Jeg har set, hvordan mange praksisser, der er nødvendige for at skabe god kode, ignoreres i Terraform. Du har i årevis lært for at blive en god programmør. Giv ikke slip på den erfaring blot fordi du arbejder med Terraform. De grundlæggende sandheder om god softwareudvikling gælder også for Terraform.
Hvordan kan man skrive kode og ikke dokumentere det?
Jeg er stødt på enorme Terraform-stakke helt uden dokumentation. Hvordan kan man skrive kode over sider — helt uden dokumentation? Tilføj dokumentation, der forklarer din koden Terraform (fokus er på ordet "kode"), hvorfor denne sektion er så vigtig, og hvad du laver.
Hvordan kan man implementere tjenester, der engang var en stor main()-funktion?
Jeg har set meget komplekse Terraform-stakke præsenteret som et enkelt modul. Hvorfor implementerer vi ikke software på den måde? Hvorfor opdeler vi store funktioner i mindre? De samme svar gælder for Terraform. Hvis dit modul er for stort — skal det opdeles i mindre moduler.
Bruger din virksomhed ikke biblioteker?
Jeg har set ingeniører, der lancerer et nyt projekt ved hjælp af Terraform, simpelthen copy-paste store dele fra andre projekter ind i deres egne, og derefter pille ved det, indtil det begynder at fungere. Ville du arbejde sådan med "live" kode i din virksomhed? Vi bruger jo ikke bare biblioteker for sjov. Ja, men hvor ville vi være uden fælles biblioteker helt generelt?!
Bruger du ikke PEP8 eller gofmt?
I de fleste sprog findes der en standardiseret formatregel. I Python er det PEP8. I Go er det gofmt. Terraform har sin egen: terraform fmt. Brug det frit!
Vil du bruge React uden at kende JavaScript?
Terraform-moduler kan forenkle nogle dele af den komplekse infrastruktur, du skaber, men det betyder ikke, at du fuldstændig kan undgå at forstå den. Vil du bruge Terraform korrekt uden at forstå ressourcerne? Du er dømt: tiden vil gå, og du vil stadig ikke mestre Terraform.
Koder du med singletons, eller injicerer du afhængigheder?
Dependency injection er anerkendt som den bedste praksis for softwareudvikling, som foretrækkes af singletoner. Hvordan kommer det til nytte i Terraform? Jeg har set Terraform-moduler, der afhænger af en fjern tilstand. I stedet for at skrive moduler, der henter fra den fjern tilstand, skal du skrive et modul, der tager parametre. Og så kan du videregive disse parametre til modulet.
Gør dine biblioteker ti ting godt eller én ting fremragende?
Biblioteker fungerer bedst, når de fokuserer på én opgave, som de udfører fremragende. I stedet for at skrive store Terraform-moduler, der prøver at gøre alt på én gang, så bryd dem op i dele, der klarer en enkelt ting godt. Så kan du kombinere dem, som det er nødvendigt.
Hvordan ændrer du biblioteker uden bagudkompatibilitet?
Et generelt Terraform-modul, ligesom et almindeligt bibliotek, skal på en eller anden måde informere brugerne om ændringer uden bagudkompatibilitet. Når ændringer sker i biblioteker, er det irriterende, og det samme gælder, når der foretages ændringer uden bagudkompatibilitet i Terraform-moduler. Det anbefales at anvende git-tags og semver, når du bruger Terraform-moduler.
Kører din produktionsservice på din bærbare computer eller i datacenteret?
Hashicorp har værktøjer som til at køre dit terraform. Disse centraliserede tjenester gør det lettere at administrere, auditerer og godkende ændringer i terraform.
Skriver du ikke tests?
Ingeniører anerkender, at koden skal testes, men de glemmer ofte at køre tests, mens de arbejder med Terraform. For infrastrukturen kan det være fyldt med snedige problemer. Jeg anbefaler at "teste" eller "lave eksempler" på stacks ved hjælp af moduler, der kan implementeres korrekt til test under CI/CD.
Terraform og mikroservices
Livet og døden for mikroservicefirmaer afhænger af hastighed, opdatering og destruktion af nye mikroservice-arbejdsstakke.
Den mest udbredte negative faktor ved mikroservicearkitekturer, som man aldrig slipper for, handler om arbejdet og ikke koden. Hvis du ser Terraform kun som en måde at automatisere den infrastrukturelle del af mikroservicearkitekturen på, berøver du dig selv de sande fordele ved dette system. Det er nu allerede .
Kilde: habr.com
