AWS CloudFormation og Terraform – ikke sikker på, hvad du skal vælge? Denne artikel hjælper dig med at træffe en smart beslutning.
Cloud Computing har revolutioneret verden af DevOps. Det er ikke bare et buzzword længere; det er her, og det er her for at ændre den måde, vi udvikler og vedligeholder vores applikationer på. Selvom der er utallige grunde til, at du bør bruge cloud computing til alle skalaer af virksomheder, er der en lille begrænsning, du er nødt til at klargøre din infrastruktur manuelt.
Du skal gå til dine cloud-udbyderes konsoller og fortælle dem præcis, hvad du vil have. Dette fungerer godt til små brugssager, men hvad nu hvis du har forskellige personer, der laver konfigurationsændringer i konsollen. Du kan ende med en superkompliceret infrastruktur, som kun bliver sværere og sværere at vedligeholde. Der er ingen effektiv måde at samarbejde eller holde styr på ændringerne af infrastrukturen i skyen. Nå, det er der faktisk. Infrastruktur som en kode.
Infrastruktur som kode er et meget populært begreb inden for cloud computing. Det er processen med at administrere din it-infrastruktur ved hjælp af kode. Ja det er rigtigt. I stedet for at gå til konsollen og gøre alt manuelt; Infrastruktur som en kode, alias IAAC eller IAC, giver dig mulighed for at skrive konfigurationsfiler, som derefter klargør din cloud-infrastruktur. IAC giver os fordelene som konsekvens, nem og hurtig vedligeholdelse og ingen plads til menneskelige fejl.
Indholdsfortegnelse
Brug af IAC med Amazon Web Services
AWS er den førende cloud computing-tjeneste i verden, med dobbelt markedsandel end den næste cloud-udbyder efter den. Der er over 200 tjenester på AWS, der kan imødekomme hundredvis og tusindvis af brugssager.
Når du begynder at bruge IAC med AWS, vil du ofte indsnævre dine valg til AWS CloudFormation og open source-værktøjet, Terraform. Når du prøver at træffe et valg mellem de to, kan det være ret overvældende at forstå de mange funktioner, som begge værktøjer tilbyder. I denne artikel vil vi se på forskellene mellem AWS CloudFormation og Terraform for at hjælpe dig med at beslutte, hvilket værktøj der passer bedst til dine behov.
Terraform vs. AWS CloudFormation: Forskelle
Modularitet
Når du bruger IAC i store organisationer, kan modularitet være en stor faktor for at vælge det rigtige værktøj.
CloudFormation
CloudFormation har ikke indbygget understøttelse af moduler. Det giver dig mulighed for at bruge noget, der hedder indlejrede stakke som moduler.
Du kan f.eks. have en standardkonfiguration af, hvordan du vil klargøre en S3-bucket i din organisation. Så du opretter en standard CloudFormation-skabelon, der opretter S3-bøtter. Når en slutbruger nu vil oprette S3-bøtten, kan de bruge denne CloudFormation-skabelon som en indlejret stak og oprette en standard S3-bøtte.
Der er også en mindre kendt tjeneste af AWS, den AWS servicekatalog der kan hjælpe dig med modulariteten af din AWS CloudFormation. Service Catalog er en AWS-tjeneste, der er designet specifikt til organisationer, der ønsker at begrænse omfanget af AWS-tjenester for at opfylde krav til overholdelse, sikkerhed, omkostninger eller ydeevne. Og gæt hvad? AWS Service Catalog bruger CloudFormation-skabeloner i backend.
Lad os hurtigt forstå dette med et eksempel. S3-spande, hvis de ikke bruges korrekt, kan snart være katastrofale for dine fortrolige data. Lad os tage det samme eksempel, du vil have en standard måde for, hvordan du vil bruge S3 i din organisation. Den første mulighed er at oprette den indlejrede stak-skabelon, som kan bruges i andre CloudFormation-stakke og er lige så god.
Hvis du ikke ønsker, at brugere skal bruge denne standardskabelon som en indlejret stak, kan du bruge AWS Service Catalog. Service Catalog giver brugerne mulighed for at bruge denne standardskabelon fra konsollens brugergrænseflade og specificere nogle parametre for små tilpasninger. Dette giver dig mulighed for at kontrollere, hvordan infrastrukturen klargøres i dine AWS-konti og forhindre uønskede scenarier.
Terraform
Terraform har indbygget understøttelse af moduler. Det giver dig mulighed for at oprette standardkonfigurationer ligesom AWS CloudFormation og bruge det i andre terraform-konfigurationer.
Da Terraform er et open source-værktøj, kan du også finde og bruge nogle præfabrikerede open source-moduler i Terraform Registry. Du kan også oprette dine egne moduler med dine egne konfigurationer og hoste dem på et privat modulregister.
Personligt ville jeg foretrække at bruge Terraform frem for CloudFormation, hvis modularitet var et stort krav.
At bruge en indlejret stak i CloudFormation er ikke så let som at bruge moduler i Terraform. Den vigtigste faktor er, at det kan være ret kompliceret at overføre data fra en CFN-skabelon til den indlejrede stak.
Der er ikke noget standardsted, hvor CloudFormation-skabeloner kan deles. Du har AWS Service Catalogue, men det er kun en måde for dig at håndhæve nogle regler for oprettelse af infrastruktur via Console. Vi handler alle om kode. Når du bruger Service Catalog, selv om nogle komplicerede opgaver er indkapslet af CloudFormation-filer, skal du stadig gennemgå den manuelle opgave med at gå til konsollen og angive parametre for at lave din Infrastruktur.
Terraform har på den anden side en fast metode til at skabe, vedligeholde og dele modulerne. Du kan se de nøjagtige krav til modulerne i Terraform Module Registry og bruge dem i dine terraform-filer meget nemt.
Kontrol og styring af infrastruktur
Hvis du vil begrænse, hvilke ressourcer dine medarbejdere kan oprette i dine AWS-konti: Både AWS CloudFormation og Terraform giver dig midlerne til at gøre det.
Lad os først tale om CloudFormation. CloudFormation i sig selv tilbyder ikke nogen kontrol over, hvordan skabelonerne bruges, men du kan bruge AWS IAM-politikkerne til kun at tillade brugerne på din AWS-konto kun at bruge standard CloudFormation-skabelonerne til ressourceoprettelse. I vores S3-bucket-eksempel vil du måske begrænse alle “S3 Create”-tilladelser for brugere og kun tillade dem at oprette S3-buckets fra AWS Service Catalog eller Nested Stacks.
Terraform giver dig mulighed for at kontrollere, hvilke ressourcer dine brugere kan oprette ved hjælp af en politik som kodeværktøj vagtpost. Sentinel giver dig mulighed for at håndhæve finkornede, logikbaserede politikker for at tillade eller afvise brugerhandlinger via Terraform. For eksempel kan du nægte alle ressourcer, der opretter S3-buckets, og kun tillade brugere at oprette S3-buckets fra et standardmodul.
Statsledelse
Både AWS CloudFormation og Terraform skal holde styr på de ressourcer, de vedligeholder.
Terraform gemmer din infrastrukturs tilstand i en tilstandsfil. Denne fil gemmes lokalt som standard, men du kan gemme den på eksterne backends som S3 og få flere brugere til at foretage ændringer i det samme sæt infrastruktur.
CloudFormation vedligeholder ikke en tilstandsfil, i hvert fald ikke en vi kan se. CloudFormation er en administreret tjeneste, så den udfører al statsvedligeholdelse og kontrol i baggrunden.
Både AWS CloudFormation og Terraform har et middel til, at du kan tjekke, hvilke ændringer der vil blive foretaget i din infrastruktur. I Terraform kan du køre en kommando – “terraform plan” og hvordan Terraform planlægger at anvende dine konfigurationsændringer. I CloudFormation kan brugere se disse oplysninger via Change Sets.
Sprog
Terraform bruger HashiCorp Configuration Language, HCL, et sprog skabt af HashiCorp. Det ligner meget JSON med yderligere indbyggede funktioner og muligheder.
CloudFormation-skabeloner er skrevet i YAML- eller JSON-formater
Logning og tilbagerulninger
Både AWS CloudFormation og Terraform har gode logningsmuligheder. Efter min erfaring har fejlene og problemerne været ligetil (for det meste).
CloudFormation: Som standard ruller CloudFormation alle dine ændringer tilbage i tilfælde af en mislykket stakændring. Dette er en god funktion og kan deaktiveres til alle fejlretningsformål.
Terraform: Terraform vil ikke automatisk rulle dine ændringer tilbage, hvis det mislykkes. Dette er ikke et problem, da du altid kan køre kommandoen terraform destroy for at slette den halvt leverede konfiguration og genstarte en Terraform-kørsel igen.
Omfang
Terraform er ikke begrænset til AWS Cloud. Den vigtigste faktor, når du skal vælge mellem Terraform og CloudFormation, er, at Terraform understøtter andre cloud-udbydere og tjenester.
Så hvis du planlægger at bruge IAC til flere skyplatforme, er Terraform dit bedste valg. Selvom CloudFormation er et kraftfuldt værktøj, er det kun begrænset til AWS. Ved at bruge Terraform kan du opsætte infrastruktur og implementere din applikation i flere cloud-platforme, og derved gøre din applikation mere tilgængelig og robust.
Funktionssupport
Normalt, når AWS udruller nye tjenester og funktioner, vil CloudFormation blive opdateret før Terraform, da det er en AWS-tjeneste. Fra nu af dækker begge værktøjer de fleste af tjenesterne og funktionerne i disse tjenester. Dette kan være en lille ulempe ved at bruge Terraform, men vi har en løsning.
Der er også mulighed for, at du kan oprette en CloudFormation-stak i din Terraform-kode. Så hvis du bruger Terraform, og den ikke har en funktion, kan du midlertidigt opsætte en CloudFormation-stak i din Terraform-kode.
Teknisk support
Den betalte AWS tekniske supportplan dækker også CloudFormation-support.
HashiCorp har også betalt planer for teknisk support på Terraform.
Konklusion
Både AWS CloudFormation og Terraform er kraftfulde og fuldt udviklede værktøjer. Forskellene ovenfor hjælper dig med at træffe en informeret beslutning om at vælge værktøjet baseret på dine krav. Som et personligt forslag, hvis du planlægger at bruge flere cloud-platforme i fremtiden eller i øjeblikket bruger flere skyer, bør du bruge Terraform som en one-stop-shop til alle dine behov. Hvis du leder efter et IAC-værktøj kun til AWS, er både AWS CloudFormation og Terraform fair game.
Hvis du er interesseret i at lære Terraform, så tjek disse online kurser.