AWS CloudFormation og Terraform – ikke sikker på hva du skal velge? Denne artikkelen vil hjelpe deg å ta en smart avgjørelse.
Cloud Computing har revolusjonert verden av DevOps. Det er ikke bare et moteord lenger; den er her og den er her for å endre måten vi utvikler og vedlikeholder applikasjonene våre på. Selv om det er utallige grunner til at du bør bruke cloud computing for alle skalaer av virksomheter, er det en liten begrensning, du må klargjøre infrastrukturen din manuelt.
Du må gå til konsollene til skyleverandørene dine og fortelle dem nøyaktig hva du vil ha. Dette fungerer bra for små brukstilfeller, men hva om du har forskjellige personer som gjør konfigurasjonsendringer i konsollen. Du kan ende opp med en superkomplisert infrastruktur som bare blir vanskeligere og vanskeligere å vedlikeholde. Det er ingen effektiv måte å samarbeide på eller holde styr på endringene i infrastrukturen i skyen. Vel, det er det faktisk. Infrastruktur som en kode.
Infrastruktur som kode er et veldig populært begrep innen cloud computing. Det er prosessen med å administrere IT-infrastrukturen din ved hjelp av kode. Ja det er riktig. I stedet for å gå til konsollen og gjøre alt manuelt; Infrastruktur som en kode, aka IAAC eller IAC, lar deg skrive konfigurasjonsfiler, som deretter sørger for skyinfrastrukturen din. IAC gir oss fordelene som konsistens, enkelt og raskt vedlikehold og ikke rom for menneskelige feil.
Innholdsfortegnelse
Bruker IAC med Amazon Web Services
AWS er den ledende cloud computing-tjenesten i verden, med dobbel markedsandel enn den neste skyleverandøren etter den. Det er over 200 tjenester på AWS som kan dekke hundrevis og tusenvis av brukssaker.
Når du begynner å bruke IAC med AWS, vil du ofte begrense valgene dine til AWS CloudFormation og åpen kildekode-verktøyet, Terraform. Når du prøver å velge mellom de to, kan det være ganske overveldende å forstå de mange funksjonene som begge verktøyene tilbyr. I denne artikkelen vil vi se på forskjellene mellom AWS CloudFormation og Terraform for å hjelpe deg med å bestemme hvilket verktøy som passer best til dine behov.
Terraform vs. AWS CloudFormation: Forskjeller
Modularitet
Ved bruk av IAC i store organisasjoner kan modularitet være en stor faktor for å velge riktig verktøy.
CloudFormation
CloudFormation har ikke innebygd støtte for moduler. Den lar deg bruke noe som kalles nestede stabler som moduler.
Du kan for eksempel ha en standardkonfigurasjon av hvordan du vil klargjøre en S3-bøtte i organisasjonen din. Så du lager en standard CloudFormation-mal som lager S3-bøtter. Nå når en sluttbruker ønsker å lage S3-bøtten, kan de bruke denne CloudFormation-malen som en nestet stabel og lage en standard S3-bøtte.
Det er også en mindre kjent tjeneste til AWS, den AWS servicekatalog som kan hjelpe deg med modulariteten til AWS CloudFormation. Service Catalog er en AWS-tjeneste som er utviklet spesifikt for organisasjoner som ønsker å begrense omfanget av AWS-tjenester for å oppfylle krav til samsvar, sikkerhet, kostnader eller ytelse. Og gjett hva? AWS Service Catalog bruker CloudFormation-maler i backend.
La oss raskt forstå dette med et eksempel. S3-bøtter, hvis de ikke brukes riktig, kan snart være katastrofale for dine konfidensielle data. La oss ta det samme eksempelet, du vil ha en standard måte på hvordan du vil bruke S3 i din organisasjon. Det første alternativet er å lage den nestede stabelmalen, som kan brukes i andre CloudFormation-stabler og er like god.
Hvis du ikke vil at brukere skal bruke denne standardmalen som en nestet stabel, kan du bruke AWS Service Catalog. Service Catalog vil tillate brukere å bruke denne standardmalen fra brukergrensesnittet til konsollen og spesifisere noen parametere for små tilpasninger. Dette lar deg kontrollere hvordan infrastruktur klargjøres i AWS-kontoene dine og forhindre uønskede scenarier.
Terraform
Terraform har innebygd støtte for moduler. Den lar deg lage standardkonfigurasjoner omtrent som AWS CloudFormation og bruke den i andre terraform-konfigurasjoner.
Siden Terraform er et åpen kildekode-verktøy kan du også finne og bruke noen forhåndslagde åpen kildekode-moduler i Terraform-registeret. Du kan også lage dine egne moduler med dine egne konfigurasjoner og være vert for dem i et privat modulregister.
Personlig ville jeg foretrekke å bruke Terraform fremfor CloudFormation hvis modularitet var et stort krav.
Å bruke en nestet stabel i CloudFormation er ikke like enkelt som å bruke moduler i Terraform. Hovedfaktoren er at det kan være ganske komplisert å overføre data fra en CFN-mal til den nestede stabelen.
Det er ikke noe standard sted hvor CloudFormation-maler kan deles. Du har AWS Service Catalog, men det er bare en måte for deg å håndheve noen regler for å lage infrastruktur via konsollen. Vi handler alle om kode. Når du bruker Service Catalog, selv om noen kompliserte oppgaver er innkapslet av CloudFormation-filer, må du fortsatt gå gjennom den manuelle oppgaven med å gå til konsollen og spesifisere parametere for å lage infrastrukturen din.
Terraform har på sin side en fast metode for å lage, vedlikeholde og dele modulene. Du kan se de nøyaktige kravene til modulene i Terraform Module Registry og bruke dem i terraform-filene dine veldig enkelt.
Kontroll og styring over infrastruktur
Hvis du vil begrense hvilke ressurser folkene dine kan opprette i AWS-kontoene dine: Både AWS CloudFormation og Terraform gir deg midler til å gjøre det.
La oss snakke om CloudFormation først. CloudFormation i seg selv gir ingen kontroll over hvordan malene brukes, men du kan bruke AWS IAM-policyene til å bare tillate brukerne i AWS-kontoen din å bruke standard CloudFormation-malene for ressursoppretting. I vårt S3-bøtteeksempel vil du kanskje begrense alle «S3 Create»-tillatelser for brukere og bare la dem lage S3-buckets fra AWS Service Catalog eller Nested Stacks.
Terraform lar deg kontrollere hvilke ressurser brukerne dine kan opprette ved å bruke en policy som et kodeverktøy vakt. Sentinel lar deg håndheve finmaskede, logikkbaserte retningslinjer for å tillate eller nekte brukerhandlinger via Terraform. Du kan for eksempel nekte alle ressurser som lager S3-bøtter og bare tillate brukere å lage S3-bøtter fra en standardmodul.
Statens ledelse
Både AWS CloudFormation og Terraform må holde styr på ressursene de vedlikeholder.
Terraform lagrer tilstanden til infrastrukturen din i en tilstandsfil. Denne filen lagres lokalt som standard, men du kan lagre den på eksterne backends som S3 og få flere brukere til å gjøre endringer i det samme settet med infrastruktur.
CloudFormation opprettholder ikke en tilstandsfil, i hvert fall ikke en vi kan se. CloudFormation er en administrert tjeneste, så den utfører alt statlig vedlikehold og kontroller i bakgrunnen.
Både AWS CloudFormation og Terraform har et middel for deg å sjekke hvilke endringer som skal gjøres i infrastrukturen din. I Terraform kan du kjøre en kommando – «terraform plan» og hvordan Terraform planlegger å bruke konfigurasjonsendringene dine. I CloudFormation kan brukere se denne informasjonen via endringssett.
Språk
Terraform bruker HashiCorp Configuration Language, HCL, et språk laget av HashiCorp. Den er veldig lik JSON med ekstra innebygde funksjoner og muligheter.
CloudFormation-maler er skrevet i YAML- eller JSON-formater
Logging og tilbakeføringer
Både AWS CloudFormation og Terraform har gode loggingsmuligheter. Etter min erfaring har feilene og problemene vært enkle (for det meste).
CloudFormation: Som standard ruller CloudFormation tilbake alle endringene dine i tilfelle en mislykket stabelendring. Dette er en god funksjon og kan deaktiveres for alle feilsøkingsformål.
Terraform: Terraform vil ikke automatisk rulle tilbake endringene i tilfelle det mislykkes. Dette er ikke et problem siden du alltid kan kjøre kommandoen terraform destroy for å slette den halvveis tilrettelagte konfigurasjonen og starte en Terraform-kjøring på nytt.
omfang
Terraform er ikke begrenset til AWS Cloud. Den viktigste faktoren når du skal velge mellom Terraform og CloudFormation er at Terraform støtter andre skyleverandører og tjenester.
Så hvis du planlegger å bruke IAC for flere skyplattformer, er Terraform det beste valget. CloudFormation, selv om det er et kraftig verktøy, er bare begrenset til AWS. Ved å bruke Terraform kan du sette opp infrastruktur og distribuere applikasjonen din i flere skyplattformer, og dermed gjøre applikasjonen din mer tilgjengelig og robust.
Funksjonsstøtte
Vanligvis, når AWS ruller ut nye tjenester og funksjoner, vil CloudFormation bli oppdatert før Terraform, siden det er en AWS-tjeneste. Per nå dekker begge verktøyene de fleste av tjenestene og funksjonene til disse tjenestene. Dette kan være en liten ulempe ved å bruke Terraform, men vi har en løsning.
Det er også en mulighet for deg å lage en CloudFormation-stabel i Terraform-koden din. Så hvis du bruker Terraform og den ikke har en funksjon, kan du midlertidig sette opp en CloudFormation-stabel inne i Terraform-koden din.
Teknisk støtte
Den betalte AWS tekniske støtteplanen dekker også CloudFormation-støtte.
HashiCorp har betalt planer for teknisk støtte på Terraform også.
Konklusjon
Både AWS CloudFormation og Terraform er kraftige og ferdigutviklede verktøy. Forskjellene ovenfor vil hjelpe deg å ta en informert beslutning om å velge verktøyet basert på dine behov. Som et personlig forslag, hvis du planlegger å bruke flere skyplattformer i fremtiden eller for øyeblikket bruker flere skyer, bør du bruke Terraform som en one-stop-shop for alle dine behov. Hvis du leter etter et IAC-verktøy kun for AWS, er både AWS CloudFormation og Terraform rettferdig spill.
Hvis du er interessert i å lære Terraform, sjekk ut disse nettkursene.