At repræsentere infrastruktur som kode i et repeterbart tekstformat er en enkel bedste praksis for systemer, der ikke kræver at tumle med mus. Denne praksis har et navn - , og indtil videre er der to populære værktøjer til at implementere det, især i AWS: и .
Sammenligning af erfaring med Terraform og CloudFormation
Inden man kommer til (Aka ) Jeg arbejdede og brugte Terraform i tre år. På det nye sted brugte jeg også Terraform med al min magt, og så skubbede virksomheden overgangen til alt a la Amazon, inklusive CloudFormation. Jeg har flittigt udviklet best practices for begge, og har brugt begge værktøjer i meget komplekse, organisationsdækkende arbejdsgange. Senere, efter omhyggeligt at have afvejet implikationerne af migrering fra Terraform til CloudFormation, blev jeg overbevist om, at Terraform nok var det bedste valg for organisationen.
Terraform Horrible
Beta software
Terraform har ikke engang udgivet version 1.0 endnu, hvilket er en god grund til ikke at bruge den. Det har ændret sig meget, siden jeg selv prøvede det første gang, men dengang terraform apply gik ofte i stykker efter flere opdateringer eller blot efter et par års brug. Jeg vil sige, at "alt er anderledes nu", men ... det er det, alle synes at sige, ikke? Der er ændringer, der er uforenelige med tidligere versioner, selvom de er passende, og det føles endda som om syntaksen og abstraktionerne af ressourcelagre nu er, hvad vi har brug for. Instrumentet ser ud til virkelig at være blevet bedre, men... :-0
På den anden side har AWS gjort et godt stykke arbejde med at opretholde bagudkompatibilitet. Dette skyldes sandsynligvis, at deres tjenester ofte bliver grundigt testet i organisationen og først derefter, omdøbt, udgives. Så "de prøvede hårdt" er en underdrivelse. At opretholde bagudkompatibilitet med API'er for et system så varieret og komplekst som AWS er utroligt svært. Enhver, der har skullet vedligeholde offentlige API'er, der bruges så bredt, som de er, bør forstå, hvor svært det er at gøre det i så mange år. Men CloudFormations adfærd, i min hukommelse, har aldrig ændret sig gennem årene.
Mød benet... det er en kugle
Så vidt jeg ved, slet ressourcen outsider CloudFormation-stak fra din CF-stak er ikke mulig. Det samme er tilfældet med Terraform. Det giver dig mulighed for at importere eksisterende ressourcer til din stak. Funktionen kan siges at være fantastisk, men med stor magt følger et stort ansvar. Du skal blot tilføje en ressource til stakken, og mens du arbejder med din stak, kan du ikke slette eller ændre denne ressource. En dag gav det bagslag. En dag på Twitch importerede nogen ved et uheld en andens AWS-sikkerhedsgruppe til deres egen Terraform-stak, mens de ikke var i stand til at gøre noget galt. Jeg indtastede flere kommandoer og... sikkerhedsgruppen (sammen med indgående trafik) forsvandt.
Terraform Fantastisk
Genopretning fra ufuldstændige tilstande
Nogle gange formår CloudFormation ikke helt at gå fra en tilstand til en anden. Samtidig vil han forsøge at vende tilbage til den forrige. Det er ærgerligt, at det ikke altid er muligt. Det kan være ret skræmmende at fejlsøge, hvad der skete senere - man ved aldrig, om CloudFormation bliver glad for, at det bliver hacket - selv bare for at rette op på det. Hvorvidt det vil være muligt at vende tilbage til den tidligere tilstand eller ej, ved han virkelig ikke, hvordan han skal bestemme, og som standard hænger han i timevis og venter på et mirakel.
Terraform har på den anden side en tendens til at komme sig efter mislykkede overgange meget mere yndefuldt og tilbyder avancerede fejlfindingsværktøjer.
Tydeligere ændringer af dokumentstatus
"Okay, load balancer, du ændrer dig. Men hvordan?"
-ivrig ingeniør, klar til at trykke på "accepter"-knappen.
Nogle gange har jeg brug for at lave nogle manipulationer med belastningsbalanceren i CloudFormation-stakken, såsom at tilføje et portnummer eller ændre en sikkerhedsgruppe. ClouFormation viser dårlige ændringer. Jeg, på nåle og nåle, dobbelttjekker yaml-filen ti gange for at sikre mig, at jeg ikke har slettet noget nødvendigt og ikke har tilføjet noget unødvendigt.
Terraform er meget mere gennemsigtig i denne henseende. Nogle gange er han endda for gennemsigtig (læs: irriterende). Heldigvis indeholder den seneste version forbedret visning af ændringer, så du nu kan se præcis, hvad der ændrer sig.
fleksibilitet
Skriv software baglæns.
For at sige det ligeud er den vigtigste egenskab ved langlivet software evnen til at tilpasse sig forandringer. Skriv enhver software baglæns. Oftest lavede jeg fejl ved at tage en "simpel" tjeneste og derefter begynde at proppe alt i en enkelt CloudFormation eller Terraform stack. Og selvfølgelig, måneder senere blev det afsløret, at jeg havde forstået alt forkert, og betjeningen var faktisk ikke enkel! Og nu skal jeg på en eller anden måde bryde en stor stak op i små komponenter. Når du arbejder med CloudFormation, kan dette kun gøres ved først at genskabe den eksisterende stak, men det gør jeg ikke med mine databaser. Terraform gjorde det derimod muligt at dissekere stakken og nedbryde den i mere forståelige mindre dele.
Moduler i git
At dele Terraform-kode på tværs af flere stakke er meget nemmere end at dele CloudFormation-kode. Med Terraform kan du lægge din kode i et git-lager og få adgang til det ved hjælp af semantisk versionskontrol. Alle med adgang til dette lager kan genbruge den delte kode. CloudFormations ækvivalent er S3, men det har ikke de samme fordele, og der er ingen grund til, at vi overhovedet skal opgive git til fordel for S3.
Organisationen voksede, og evnen til at dele fælles stakke nåede et kritisk niveau. Terraform gør det hele nemt og naturligt, hvorimod CloudFormation får dig til at springe gennem bøjler, før du kan få sådan noget til at virke.
Operationer som kode
"Lad os skrive det og okay."
-en ingeniør 3 år før han opfandt Terraform-cyklen.
Når det kommer til softwareudvikling, er Go eller et Java-program ikke bare kode.
Kode som kode
Der er også infrastrukturen, som det fungerer på.
Infrastruktur som kode
Men hvor er hun fra? Hvordan overvåger man det? Hvor bor din kode? Har udviklere brug for adgangstilladelse?
Operationer som kode
At være softwareudvikler betyder ikke kun at skrive kode.
AWS er ikke den eneste: du bruger sandsynligvis 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 er valgt af forskellige årsager, og hver er lige vigtig for alt relateret til software.
Da jeg arbejdede hos Twitch, accelererede vi tjenester inde i Amazons blandede indlejrede og AWS-systemer. Vi brugte og støttede mange mikrotjenester, hvilket øgede driftsomkostningerne. Diskussionerne gik nogenlunde sådan her:
- Я: Damn, det er mange bevægelser for at overclocke én mikrotjeneste. Jeg bliver nødt til at bruge dette affald til at oprette en AWS-konto (vi gik til 2 konti på mikroservice), så denne til opsætning af advarsler, denne til et kodelager, og denne til en e-mailliste, og så denne...
- At føre: Lad os skrive det og okay.
- Я: Okay, men selve scriptet vil ændre sig. Vi har brug for en måde at kontrollere, at alle disse indbyggede Amazon dimser er opdateret.
- At føre: Lyder godt. Og vi skriver et manuskript til dette.
- Я: Store! Og scriptet skal sandsynligvis stadig indstille parametre. Vil han acceptere dem?
- At føre: Lad ham tage, hvor han går!
- Я: Processen kan ændre sig, og bagudkompatibilitet vil gå tabt. En form for semantisk versionskontrol vil være påkrævet.
- At føre: Rigtig god idé!
- Я: Værktøjer kan ændres manuelt, inde i brugergrænsefladen. Vi skal bruge en måde at tjekke og rette dette på.
…3 år senere:
- At føre: Og vi fik terraform.
Moralen i historien er: selvom du pladask i alt Amazon, bruger du stadig noget, der ikke er fra AWS, og disse tjenester har en tilstand, der bruger et konfigurationssprog til at holde denne tilstand synkroniseret.
CloudFormation lambda vs git moduler terraform
lambda er CloudFormations løsning på det brugerdefinerede logikproblem. Med lambda kan du eller . Denne tilgang introducerer yderligere kompleksiteter, som ikke er til stede i Terraforms semantiske versionering af git-moduler. For mig var det mest presserende problem at administrere tilladelser for alle disse bruger-lambdaer (og disse er snesevis af AWS-konti). Et andet vigtigt problem var "hvad kom først, hønen eller ægget?"-problemet: det var relateret til lambda-koden. Denne funktion er i sig selv infrastruktur og kode, og den har i sig selv behov for overvågning og opdateringer. Det sidste søm i kisten var vanskeligheden ved semantisk at opdatere lambda-kodeændringer; vi skulle også sikre os, at stakhandlingerne uden en direkte kommando ikke ændrede sig mellem kørsler.
Jeg kan huske, at jeg engang ønskede at skabe en kanarie-installation til Elastic Beanstalk-miljøet med en klassisk load balancer. Den nemmeste ting at gøre ville være at lave en anden implementering for EB'en ved siden af produktionsmiljøet og tage det et skridt videre: at kombinere den automatiske kanarie-udrulningsgruppe med implementerings-LB i produktionsmiljøet. Og da Terraform bruger , vil dette kræve 4 ekstra linjer kode i Terraform. Da jeg spurgte, om der var en sammenlignelig løsning i CloudFormation, pegede de mig på et helt git-lager med en implementeringspipeline og det hele, alt sammen for noget, som dårlige 4 linjer Terraform-kode kunne gøre.
Den registrerer drift bedre
Sørg for, at virkeligheden svarer til forventningerne.
er en meget kraftfuld operation som kodefunktion, fordi den hjælper med at sikre, at virkeligheden matcher forventningerne. Den er tilgængelig med både CloudFormation og Terraform. Men efterhånden som produktionsstakken voksede, frembragte søgningen efter drift i CloudFormation flere og flere falske registreringer.
Med Terraform har du meget mere avancerede livscykluskroge til afdriftsdetektering. For eksempel indtaster du kommandoen direkte i ECS-opgavedefinitionen, hvis du vil ignorere ændringer af en specifik opgavedefinition uden at ignorere ændringer af hele din ECS-implementering.
CDK og fremtiden for CloudFormation
CloudFormation er vanskelig at administrere i stor skala på tværs af infrastruktur. Mange af disse vanskeligheder er anerkendt, og værktøjet har brug for ting som , en ramme til at definere cloud-infrastruktur i kode og køre den gennem AWS CloudFormation. Det bliver interessant at se, hvad fremtiden bringer for aws-cdk, men det får svært ved at konkurrere med Terraforms øvrige styrker; for at bringe CloudFormation ajour, vil der være behov for globale ændringer.
Så den Terraform skuffer ikke
Dette er "infrastruktur som en kode" og ikke "som en tekst".
Mit første indtryk af Terraform var ret dårligt. Jeg tror bare ikke jeg forstod tilgangen. Næsten alle ingeniører opfatter det ufrivilligt som et tekstformat, der skal konverteres til den ønskede infrastruktur. GØR DET IKKE SÅDAN.
Truismerne ved god softwareudvikling gælder også for Terraform.
Jeg har set mange metoder, der er blevet vedtaget for at skabe god kode, blive ignoreret i Terraform. Du har studeret i årevis for at blive en god programmør. Giv ikke op denne oplevelse, bare fordi du arbejder med Terraform. Truismerne ved god softwareudvikling gælder for Terraform.
Hvordan kan koden ikke dokumenteres?
Jeg har set enorme Terraform stakke med absolut ingen dokumentation. Hvordan kan du skrive kode i sider - helt uden dokumentation? Tilføj dokumentation, der forklarer din kode Terraform (med vægt på ordet "kode"), hvorfor dette afsnit er så vigtigt, og hvad du gør.
Hvordan kan vi implementere tjenester, der engang var én stor hovedfunktion()?
Jeg har set meget komplekse Terraform-stakke præsenteret som et enkelt modul. Hvorfor implementerer vi ikke software på denne måde? Hvorfor opdeler vi store funktioner i mindre? De samme svar gælder for Terraform. Hvis dit modul er for stort, skal du opdele det i mindre moduler.
Bruger din virksomhed ikke biblioteker?
Jeg har set, hvordan ingeniører, der lavede et nyt projekt ved hjælp af Terraform, dumt kopierede store bidder fra andre projekter ind i deres egne og derefter pillede ved dem, indtil det begyndte at virke. Ville du arbejde sådan med "combat"-kode i din virksomhed? Vi bruger ikke kun biblioteker. Ja, men hvor er vi uden fælles biblioteker i princippet?!
Bruger du ikke PEP8 eller gofmt?
De fleste sprog har et standard, accepteret formateringsskema. I Python er dette PEP8. I Go - gofmt. Terraform har sin egen: terraform fmt. Nyd det for dit helbred!
Vil du bruge React uden at kende JavaScript?
Terraform-moduler kan forenkle en del af den komplekse infrastruktur, du opretter, men det betyder ikke, at du slet ikke kan pille ved det. Vil du bruge Terraform korrekt uden at forstå ressourcer? Du er dømt: tiden vil gå, og du vil aldrig mestre Terraform.
Koder du med singletons eller afhængighedsinjektion?
Afhængighedsinjektion er en anerkendt bedste praksis for softwareudvikling og foretrækkes frem for singletons. Hvordan er dette nyttigt i Terraform? Jeg har set Terraform-moduler, der afhænger af fjerntilstand. I stedet for at skrive moduler, der henter fjerntilstand, skal du skrive et modul, der tager parametre. Og videregiv derefter disse parametre til modulet.
Gør dine biblioteker ti ting godt eller én ting godt?
Biblioteker, der fungerer bedst, er dem, der fokuserer på én opgave, som de udfører meget godt. I stedet for at skrive store Terraform-moduler, der forsøger at gøre alt på én gang, skal du bygge dele af dem, der gør én ting godt. Og så kombiner dem efter behov.
Hvordan laver man ændringer i biblioteker uden bagudkompatibilitet?
Et almindeligt Terraform-modul, som et almindeligt bibliotek, skal på en eller anden måde kommunikere ændringer til brugerne uden at være bagudkompatibelt. Det er irriterende, når disse ændringer sker i biblioteker, og det er lige så irriterende, når der laves ikke-bagudkompatible ændringer i Terraform-moduler. Det anbefales at bruge git-tags og semver, når du bruger Terraform-moduler.
Kører din produktionstjeneste på din bærbare computer eller i et datacenter?
Hashicorp har værktøjer som at køre din terraform. Disse centraliserede tjenester gør det nemt at administrere, revidere og godkende terraformændringer.
Skriver du ikke prøver?
Ingeniører erkender, at koden skal testes, men de glemmer selv ofte at teste, når de arbejder med Terraform. For infrastruktur er dette fyldt med forræderiske øjeblikke. Mit råd er at "teste" eller "opret eksempel"-stabler ved hjælp af moduler, der kan implementeres korrekt til test under CI/CD.
Terraform og mikrotjenester
Mikroservicevirksomheders liv og død afhænger af hastigheden, innovationen og afbrydelsen af nye mikroservice-workstacks.
Det mest almindelige negative aspekt forbundet med mikroservicearkitekturer, og som ikke kan elimineres, er relateret til arbejdet, ikke koden. Hvis du tænker på Terraform som blot en måde at automatisere kun infrastruktursiden af en mikroservicearkitektur, så går du glip af de sande fordele ved systemet. Nu er det allerede .
Kilde: www.habr.com