Å representere infrastruktur som kode i et repeterbart tekstformat er en enkel beste praksis for systemer som ikke krever fikling med mus. Denne praksisen har et navn - , og så langt er det to populære verktøy for å implementere det, spesielt i AWS: и .
Sammenligning av erfaring med Terraform og CloudFormation
Før du kommer til (Aka ) Jeg jobbet og brukte Terraform i tre år. På det nye stedet brukte jeg også Terraform med all kraft, og da presset selskapet på overgangen til alt a la Amazon, inkludert CloudFormation. Jeg har flittig utviklet beste praksis for begge, og har brukt begge verktøyene i svært komplekse, organisasjonsomfattende arbeidsflyter. Senere, etter å ha vurdert implikasjonene av migrering fra Terraform til CloudFormation, ble jeg overbevist om at Terraform sannsynligvis var det beste valget for organisasjonen.
Terraform fryktelig
Beta programvare
Terraform har ikke engang gitt ut versjon 1.0 ennå, noe som er en god grunn til å ikke bruke den. Det har endret seg mye siden jeg først prøvde det selv, men den gang terraform apply gikk ofte i stykker etter flere oppdateringer eller rett og slett etter et par års bruk. Jeg vil si at "alt er annerledes nå," men ... det er det alle ser ut til å si, ikke sant? Det er endringer som er uforenlige med tidligere versjoner, selv om de er passende, og det føles til og med som om syntaksen og abstraksjonene til ressurslagrene nå er det vi trenger. Instrumentet ser virkelig ut til å ha blitt bedre, men... :-0
På den annen side har AWS gjort en god jobb med å opprettholde bakoverkompatibilitet. Dette er sannsynligvis fordi tjenestene deres ofte er grundig testet i organisasjonen og først da, omdøpt, publiseres. Så "de prøvde hardt" er en underdrivelse. Å opprettholde bakoverkompatibilitet med API-er for et system så variert og komplekst som AWS er utrolig vanskelig. Alle som har måttet vedlikeholde offentlige APIer som brukes så mye som de er, bør forstå hvor vanskelig det er å gjøre det i så mange år. Men oppførselen til CloudFormation, i mitt minne, har aldri endret seg gjennom årene.
Møt beinet... det er en kule
Så vidt jeg vet, slett ressursen utenforstående CloudFormation-stabel fra din CF-stabel er ikke mulig. Det samme gjelder Terraform. Den lar deg importere eksisterende ressurser til stabelen din. Funksjonen kan sies å være fantastisk, men med stor kraft følger stort ansvar. Du trenger bare å legge til en ressurs i stabelen, og mens du jobber med stabelen din kan du ikke slette eller endre denne ressursen. En dag slo det tilbake. En dag på Twitch importerte noen ved et uhell andres AWS-sikkerhetsgruppe inn i sin egen Terraform-stabel uten å ha noen ugagn. Jeg skrev inn flere kommandoer og... sikkerhetsgruppen (sammen med innkommende trafikk) forsvant.
Terraform Flott
Gjenoppretting fra ufullstendige tilstander
Noen ganger klarer ikke CloudFormation å gå fullstendig over fra en tilstand til en annen. Samtidig vil han prøve å gå tilbake til den forrige. Det er synd at dette ikke alltid er gjennomførbart. Det kan være ganske skummelt å feilsøke det som skjedde senere - du vet aldri om CloudFormation vil være glad for at det blir hacket - selv bare for å fikse det. Hvorvidt det vil være mulig å gå tilbake til den forrige tilstanden eller ikke, vet han egentlig ikke hvordan han skal bestemme, og som standard henger han i timevis og venter på et mirakel.
Terraform, på den annen side, har en tendens til å komme seg etter mislykkede overganger mye mer elegant og tilbyr avanserte feilsøkingsverktøy.
Tydeligere endringer i dokumentstatus
«Ok, lastbalanser, du endrer deg. Men hvordan?"
— engstelig ingeniør, klar til å trykke på "godta"-knappen.
Noen ganger må jeg gjøre noen manipulasjoner med lastbalanseren i CloudFormation-stakken, for eksempel å legge til et portnummer eller endre en sikkerhetsgruppe. ClouFormation viser dårlige endringer. Jeg, på nåler og nåler, dobbeltsjekker yaml-filen ti ganger for å være sikker på at jeg ikke har slettet noe nødvendig og ikke har lagt til noe unødvendig.
Terraform er mye mer transparent i denne forbindelse. Noen ganger er han til og med for gjennomsiktig (les: kjedelig). Heldigvis inkluderer den nyeste versjonen forbedret visning av endringer slik at du nå kan se nøyaktig hva som endrer seg.
Fleksibilitet
Skriv programvare bakover.
For å si det rett ut, er den viktigste egenskapen til programvare med lang levetid evnen til å tilpasse seg endringer. Skriv hvilken som helst programvare bakover. Oftest gjorde jeg feil ved å ta en "enkel" tjeneste, og deretter begynne å stappe alt inn i en enkelt CloudFormation- eller Terraform-stabel. Og selvfølgelig, måneder senere ble det avslørt at jeg hadde forstått alt feil, og tjenesten var faktisk ikke enkel! Og nå må jeg på en eller annen måte bryte en stor stabel i små komponenter. Når du jobber med CloudFormation, kan dette bare gjøres ved først å gjenskape den eksisterende stabelen, men jeg gjør ikke dette med databasene mine. Terraform på sin side gjorde det mulig å dissekere stabelen og bryte den ned i mer forståelige mindre deler.
Moduler i git
Å dele Terraform-kode på tvers av flere stabler er mye enklere enn å dele CloudFormation-kode. Med Terraform kan du legge koden din i et git-lager og få tilgang til den ved å bruke semantisk versjonskontroll. Alle med tilgang til dette depotet kan gjenbruke den delte koden. CloudFormations ekvivalent er S3, men det har ikke de samme fordelene, og det er ingen grunn til at vi skal forlate git til fordel for S3 i det hele tatt.
Organisasjonen vokste og evnen til å dele felles stabler nådde et kritisk nivå. Terraform gjør dette enkelt og naturlig, mens CloudFormation vil få deg til å hoppe gjennom bøyler før du kan få noe sånt til å fungere.
Operasjoner som kode
"La oss skrive det og ok."
—en ingeniør 3 år før han oppfant Terraform-sykkelen.
Når det kommer til programvareutvikling er ikke Go eller et Java-program bare kode.
Kode som kode
Det er også infrastrukturen den fungerer på.
Infrastruktur som kode
Men hvor er hun fra? Hvordan overvåke det? Hvor bor koden din? Trenger utviklere tilgangstillatelse?
Operasjoner som kode
Å være programvareutvikler betyr ikke bare å skrive kode.
AWS er ikke den eneste: du bruker sannsynligvis andre leverandører. SignalFx, PagerDuty eller Github. Kanskje du har en intern Jenkins-server for CI/CD eller et internt Grafana-dashbord for overvåking. Infra as Code velges av forskjellige grunner, og hver av dem er like viktige for alt relatert til programvare.
Da jeg jobbet hos Twitch, akselererte vi tjenester i Amazons blandede innebygde og AWS-systemer. Vi skaffet oss og støttet mange mikrotjenester, noe som økte driftskostnadene. Diskusjonene gikk omtrent slik:
- Я: Faen, det er mange bevegelser for å overklokke én mikrotjeneste. Jeg må bruke dette søppelet for å opprette en AWS-konto (vi gikk til 2 kontoer på mikrotjeneste), så denne for å sette opp varsler, denne for et kodelager, og denne for en e-postliste, og så denne...
- Lede: La oss skrive det og greit.
- Я: Ok, men selve skriptet vil endre seg. Vi trenger en måte å sjekke at alle disse innebygde Amazon-dissene er oppdaterte.
- Lede: Høres bra ut. Og vi skal skrive et manus for dette.
- Я: Flott! Og skriptet vil sannsynligvis fortsatt trenge å angi parametere. Vil han godta dem?
- Lede: La ham ta dit han går!
- Я: Prosessen kan endres og bakoverkompatibilitet vil gå tapt. En slags semantisk versjonskontroll vil være nødvendig.
- Lede: God idé!
- Я: Verktøy kan endres manuelt, inne i brukergrensesnittet. Vi trenger en måte å sjekke og fikse dette på.
…3 år senere:
- Lede: Og vi fikk terraform.
Moralen i historien er: selv om du pladask i alt Amazon, bruker du fortsatt noe som ikke er fra AWS, og disse tjenestene har en tilstand som bruker et konfigurasjonsspråk for å holde denne tilstanden synkronisert.
CloudFormation lambda vs git-moduler terraform
lambda er CloudFormations løsning på det tilpassede logikkproblemet. Med lambda kan du eller . Denne tilnærmingen introduserer ytterligere kompleksiteter som ikke er tilstede i Terraforms semantiske versjonering av git-moduler. For meg var det mest presserende problemet å administrere tillatelser for alle disse brukerlambdaene (og dette er dusinvis av AWS-kontoer). Et annet viktig problem var «hva kom først, kyllingen eller egget?»-problemet: det var relatert til lambdakoden. Denne funksjonen i seg selv er infrastruktur og kode, og den trenger i seg selv overvåking og oppdateringer. Den siste spikeren i kista var vanskeligheten med å semantisk oppdatere lambda-kodeendringer; vi måtte også sørge for at stabelhandlingene uten en direkte kommando ikke endret seg mellom kjøringene.
Jeg husker at jeg en gang ønsket å lage en kanari-utplassering for Elastic Beanstalk-miljøet med en klassisk belastningsbalanser. Den enkleste tingen å gjøre ville være å foreta en andre distribusjon for EB ved siden av produksjonsmiljøet, og ta det et skritt videre: å kombinere den automatisk skalerende kanarie-distribusjonsgruppen med distribusjonen LB i produksjonsmiljøet. Og siden Terraform bruker , vil dette kreve 4 ekstra linjer med kode i Terraform. Da jeg spurte om det fantes en sammenlignbar løsning i CloudFormation, viste de meg til et helt git-depot med en distribusjonspipeline og alt, alt av hensyn til noe som dårlige 4 linjer med Terraform-kode kunne gjøre.
Den oppdager drift bedre
Sørg for at virkeligheten samsvarer med forventningene.
er en veldig kraftig operasjon som kodefunksjon fordi den bidrar til å sikre at virkeligheten samsvarer med forventningene. Den er tilgjengelig med både CloudFormation og Terraform. Men etter hvert som produksjonsstabelen vokste, ga søk etter drift i CloudFormation flere og flere falske oppdagelser.
Med Terraform har du mye mer avanserte livssykluskroker for avdriftsdeteksjon. For eksempel skriver du inn kommandoen direkte i ECS-oppgavedefinisjonen hvis du vil ignorere endringer i en spesifikk oppgavedefinisjon uten å ignorere endringer i hele ECS-distribusjonen.
CDK og fremtiden til CloudFormation
CloudFormation er vanskelig å administrere i stor skala på tvers av infrastruktur. Mange av disse vanskelighetene er anerkjent og verktøyet trenger ting som , et rammeverk for å definere skyinfrastruktur i kode og kjøre den gjennom AWS CloudFormation. Det blir interessant å se hva fremtiden bringer for aws-cdk, men det vil ha vanskelig for å konkurrere med Terraforms andre styrker; for å bringe CloudFormation oppdatert, vil globale endringer være nødvendige.
Slik at Terraform ikke skuffer
Dette er "infrastruktur som en kode", og ikke "som en tekst".
Mitt første inntrykk av Terraform var ganske dårlig. Jeg tror jeg bare ikke forsto tilnærmingen. Nesten alle ingeniører oppfatter det ufrivillig som et tekstformat som må konverteres til ønsket infrastruktur. IKKE GJØR DET PÅ DENNE MÅTEN.
Truismene med god programvareutvikling gjelder også for Terraform.
Jeg har sett mange praksiser tatt i bruk for å lage god kode bli ignorert i Terraform. Du har studert i årevis for å bli en god programmerer. Ikke gi opp denne opplevelsen bare fordi du jobber med Terraform. Truismene ved god programvareutvikling gjelder for Terraform.
Hvordan kan koden ikke dokumenteres?
Jeg har sett enorme Terraform-stabler med absolutt ingen dokumentasjon. Hvordan kan du skrive kode på sider - helt uten dokumentasjon? Legg til dokumentasjon som forklarer din kode Terraform (vekt på ordet "kode"), hvorfor denne delen er så viktig, og hva du gjør.
Hvordan kan vi distribuere tjenester som en gang var én stor hovedfunksjon()?
Jeg har sett veldig komplekse Terraform-stabler presentert som en enkelt modul. Hvorfor distribuerer vi ikke programvare på denne måten? Hvorfor deler vi opp store funksjoner i mindre? De samme svarene gjelder for Terraform. Hvis modulen din er for stor, må du dele den opp i mindre moduler.
Bruker ikke din bedrift biblioteker?
Jeg har sett hvordan ingeniører, som spinnet opp et nytt prosjekt ved hjelp av Terraform, dumt kopierte enorme biter fra andre prosjekter inn i sine egne, og så fiklet med dem til det begynte å fungere. Ville du jobbet slik med "kamp"-kode i din bedrift? Vi bruker ikke bare biblioteker. Ja, men hvor er vi uten fellesbibliotek i prinsippet?!
Bruker du ikke PEP8 eller gofmt?
De fleste språk har et standard, akseptert formateringsskjema. I Python er dette PEP8. I Go - gofmt. Terraform har sin egen: terraform fmt. Bruk på helse!
Vil du bruke React uten å kunne JavaScript?
Terraform-moduler kan forenkle en del av den komplekse infrastrukturen du lager, men dette betyr ikke at du ikke kan tukle med den i det hele tatt. Vil du bruke Terraform riktig uten å forstå ressurser? Du er dømt: tiden vil gå, og du vil aldri mestre Terraform.
Koder du med singletons eller avhengighetsinjeksjon?
Avhengighetsinjeksjon er en anerkjent beste praksis for programvareutvikling og foretrekkes fremfor singletons. Hvordan er dette nyttig i Terraform? Jeg har sett Terraform-moduler som er avhengige av ekstern tilstand. I stedet for å skrive moduler som henter ekstern tilstand, skriv en modul som tar parametere. Og send deretter disse parameterne til modulen.
Gjør bibliotekene dine ti ting bra eller én ting bra?
Biblioteker som fungerer best er de som fokuserer på én oppgave som de gjør veldig bra. I stedet for å skrive store Terraform-moduler som prøver å gjøre alt på en gang, bygg deler av dem som gjør én ting bra. Og deretter kombinere dem etter behov.
Hvordan gjør du endringer i biblioteker uten bakoverkompatibilitet?
En vanlig Terraform-modul, som et vanlig bibliotek, må på en eller annen måte kommunisere endringer til brukere uten å være bakoverkompatibel. Det er irriterende når disse endringene skjer i biblioteker, og det er like irriterende når ikke-bakoverkompatible endringer gjøres i Terraform-moduler. Det anbefales å bruke git-tags og semver når du bruker Terraform-moduler.
Kjører produksjonstjenesten din på den bærbare datamaskinen eller i et datasenter?
Hashicorp har verktøy som å kjøre terraformen din. Disse sentraliserte tjenestene gjør det enkelt å administrere, revidere og godkjenne terraform-endringer.
Skriver du ikke prøver?
Ingeniører erkjenner at koden må testes, men de glemmer selv ofte testing når de jobber med Terraform. For infrastruktur er dette full av forræderske øyeblikk. Mitt råd er å "teste" eller "lage eksempel"-stabler ved å bruke moduler som kan distribueres riktig for testing under CI/CD.
Terraform og mikrotjenester
Livet og døden til mikrotjenesteselskaper avhenger av hastigheten, innovasjonen og forstyrrelsen av nye mikrotjenestearbeidstabler.
Det vanligste negative aspektet knyttet til mikrotjenestearkitekturer, og som ikke kan elimineres, er relatert til arbeidet, ikke koden. Hvis du tenker på Terraform som bare en måte å automatisere kun infrastruktursiden av en mikrotjenestearkitektur, går du glipp av de sanne fordelene med systemet. Nå er det allerede .
Kilde: www.habr.com