{"id":52367,"date":"2019-11-07T00:00:00","date_gmt":"2019-11-06T21:00:00","guid":{"rendered":"https:\/\/prohoster.info\/blog\/blog_prohoster\/pereshel-s-terraform-na-cloudformation-i-pozhalel"},"modified":"2020-02-18T14:00:04","modified_gmt":"2020-02-18T11:00:04","slug":"pereshel-s-terraform-na-cloudformation-i-pozhalel","status":"publish","type":"post","link":"https:\/\/prohoster.info\/da\/blog\/administrirovanie\/pereshel-s-terraform-na-cloudformation-i-pozhalel","title":{"rendered":"Skiftede fra Terraform til CloudFormation \u2014 og fortr\u00f8d","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

At pr\u00e6sentere infrastruktur som kode i et gentageligt tekstformat er en enkel bedste praksis for systemer, som ikke kr\u00e6ver besv\u00e6r. Denne praksis kaldes \u2014 Infrastructure as Code<\/a><\/noindex>, og indtil nu er der to popul\u00e6re v\u00e6rkt\u00f8jer til at implementere det, is\u00e6r i AWS: Terraform<\/a><\/noindex> og CloudFormation<\/a><\/noindex>.<\/p>\n

<\/p>\n

\"Skiftede
\nJeg sammenligner erfaringen med Terraform og CloudFormation<\/em><\/p>\n

<\/p>\n

F\u00f8r jeg kom til Twitch<\/a><\/noindex> (ogs\u00e5 kendt som Amazon Jr.<\/a><\/noindex>) arbejdede jeg i en startup<\/a><\/noindex> , hvor jeg brugte Terraform i tre \u00e5r. P\u00e5 den nye arbejdsplads brugte jeg ogs\u00e5 meget Terraform, men s\u00e5 pressede virksomheden p\u00e5 for at overg\u00e5 til alt i stil med Amazon, inklusive CloudFormation. Jeg arbejdede h\u00e5rdt p\u00e5 at udvikle bedste praksis for begge v\u00e6rkt\u00f8jer, som blev anvendt i meget komplekse arbejdsgange i stor skala. Efter n\u00f8je at have overvejet konsekvenserne af overgangen fra Terraform til CloudFormation, er jeg overbevist om, at Terraform sandsynligvis er det bedste valg for organisationen.<\/p>\n

<\/a><\/noindex><\/p>\n

Terraform er skr\u00e6mmende<\/h2>\n

<\/p>\n

Beta-versionen af softwaren<\/h3>\n

<\/p>\n

Terraform har ikke engang haft version 1.0 endnu, og det er en gyldig grund til ikke at bruge det. Siden jeg f\u00f8rste gang pr\u00f8vede det, har det \u00e6ndret sig meget, men dengang terraform apply<\/code> Det var ofte defekt efter et par opdateringer eller bare efter et par \u00e5rs brug. Jeg ville sige, at \"nu er alt anderledes\", men... s\u00e5dan siger alle, ikke? Der er \u00e6ndringer, der ikke er kompatible med tidligere versioner, selvom de er rimelige, og man f\u00e5r endda f\u00f8lelsen af, at syntaksen og abstraktionerne af ressourcelagre nu er, som de skal v\u00e6re. V\u00e6rkt\u00f8jet er som om, det virkelig er blevet bedre, men... :-0<\/p>\n

<\/p>\n

P\u00e5 den anden side har AWS gjort et godt stykke arbejde med at opretholde kompatibilitet med tidligere versioner. Det er nok fordi, deres tjenester ofte er godt testet internt i organisationen, og de kun offentligt pr\u00e6senteres efter at v\u00e6re omd\u00f8bt. S\u00e5 det at \"have gjort et godt stykke arbejde\" er virkelig en underdrivelse. At opretholde kompatibilitet med tidligere API-versioner for et s\u00e5 varieret og komplekst system som AWS er utrolig sv\u00e6rt. Enhver, der har arbejdet med offentlige API'er, som er s\u00e5 udbredte, m\u00e5 forst\u00e5, hvor udfordrende det er at g\u00f8re dette i s\u00e5 mange \u00e5r. Og p\u00e5 min hukommelse har CloudFormation aldrig \u00e6ndret sig over tid.<\/p>\n

<\/p>\n

M\u00f8d fod... det er en kugle<\/h3>\n

<\/p>\n

S\u00e5 vidt jeg ved, kan man ikke slette ressourcen uden forst\u00e5ende<\/strong> Det er umuligt at importere en CloudFormation-stak fra sin egen CF-stak. Det er stort set det samme med Terraform. Det g\u00f8r det muligt at importere eksisterende ressourcer til sin stak. Funktionen er, kan man sige, fantastisk, men med stor magt f\u00f8lger ogs\u00e5 stort ansvar. S\u00e5 snart man tilf\u00f8jer en ressource til stakken, kan man ikke slette eller \u00e6ndre denne ressource, mens man arbejder med sin stak. En gang kom det tilbage for at hjems\u00f8ge mig. P\u00e5 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\u2026 sikkerhedsgruppen (sammen med indg\u00e5ende trafik) forsvandt.<\/p>\n

<\/p>\n

Terraform Den Store<\/h2>\n

<\/p>\n

Gendannelse fra ufuldst\u00e6ndige tilstande<\/h3>\n

<\/p>\n

Nogle gange kan CloudFormation ikke fuldt ud overg\u00e5 fra \u00e9n tilstand til en anden. I s\u00e5 fald vil det fors\u00f8ge at vende tilbage til den tidligere tilstand. Desv\u00e6rre er det ikke altid muligt. Fejlfinding af det, der er opst\u00e5et, kan v\u00e6re ret skr\u00e6mmende \u2014 man ved aldrig, om CloudFormation bliver glad for at blive \u2018hacket\u2019 \u2014 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\u00e6nger det i timevis i venten p\u00e5 et mirakel.<\/p>\n

<\/p>\n

Terraform derimod er tilb\u00f8jelig til at komme sig efter mislykkede overgange p\u00e5 en mere elegant m\u00e5de og tilbyder v\u00e6rkt\u00f8jer til udvidet fejlfinding.<\/p>\n

<\/p>\n

Klarere \u00e6ndringer i dokumentets tilstande<\/h3>\n

<\/p>\n

\"Okay, belastningsbalancerer, du \u00e6ndrer dig. Men hvordan?\"<\/p>\n

\u2014 en bekymret ingeni\u00f8r, klar til at trykke p\u00e5 \"accept\u00e9r\"-knappen.<\/p><\/blockquote>\n

Nogle gange skal jeg lave nogle justeringer p\u00e5 belastningsbalanceren i CloudFormation-stakken \u2014 for eksempel tilf\u00f8je portnummeret eller \u00e6ndre sikkerhedsgruppen. CloudFormation viser \u00e6ndringerne svagt. Jeg genkender mig selv som p\u00e5 n\u00e5le, hvor jeg tjekker yaml-filen ti gange for at v\u00e6re sikker p\u00e5, at jeg ikke har slettet noget vigtigt eller tilf\u00f8jet noget un\u00f8dvendigt.<\/p>\n

<\/p>\n

Terraform er p\u00e5 dette omr\u00e5de meget mere gennemsigtig. Nogle gange er den endda for gennemsigtig (l\u00e6s: irriterende). Heldigvis har den seneste version inkluderet forbedret visning af \u00e6ndringer \u2014 nu kan man helt klart se, hvad der \u00e6ndres.<\/p>\n

<\/p>\n

Fleksibilitet<\/h3>\n

<\/p>\n

Skriv software fra slutningen.<\/p><\/blockquote>\n

At sige det ligeud, den vigtigste karakteristik ved langtidsholdbar software er evnen til at tilpasse sig \u00e6ndringer. Uanset hvilken software du skriver, skal det g\u00f8res bagl\u00e6ns. Jeg har ofte f\u00e5et problemer med, at jeg tog en \"simpel\" tjeneste og derefter fors\u00f8gte at presse alt ind i et enkelt CloudFormation- eller Terraform-stak. Og selvf\u00f8lgelig blev det afsl\u00f8ret efter m\u00e5neder, at jeg ikke havde forst\u00e5et det rigtigt, og at tjenesten slet ikke var simpel! S\u00e5 jeg skal p\u00e5 en eller anden m\u00e5de opdele det store stak i mindre komponenter. N\u00e5r man arbejder med CloudFormation, er det muligt at g\u00f8re dette, men kun ved f\u00f8rst at genskabe det eksisterende stak, hvilket jeg ikke g\u00f8r med mine databaser. Terraform tillod mig derimod at dissekere stakken og dele den op i mere forst\u00e5elige mindre dele.<\/p>\n

<\/p>\n

Moduler i git<\/h3>\n

<\/p>\n

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\u00e5 det ved at bruge semantisk versionskontrol. Enhver, der har adgang til dette repositorium, kan genbruge den f\u00e6lles kode. Den tilsvarende l\u00f8sning 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.<\/p>\n

<\/p>\n

Organisationen voksede, og evnen til at dele f\u00e6lles stacks n\u00e5ede et kritisk niveau. Med Terraform er dette nemt og naturligt, mens CloudFormation vil f\u00e5 dig til at hoppe gennem ringe, f\u00f8r noget virker p\u00e5 samme m\u00e5de.<\/p>\n

<\/p>\n

Operations as code<\/h3>\n

<\/p>\n

\"Lad os skripte det, og s\u00e5 er det fint.\"<\/p>\n

- ingeni\u00f8ren tre \u00e5r f\u00f8r han opfandt Terraform-cyklen.<\/p><\/blockquote>\n

N\u00e5r vi taler om softwareudvikling, er Go eller et program p\u00e5 Java ikke bare kode.<\/p>\n

<\/p>\n

\"Skiftede
\nCode as Code<\/em><\/p>\n

<\/p>\n

Der findes ogs\u00e5 infrastrukturen, som det k\u00f8rer p\u00e5.<\/p>\n

<\/p>\n

\"Skiftede
\nInfrastructure as Code<\/em><\/p>\n

<\/p>\n

Men hvor kommer den fra? Hvordan overv\u00e5ger man den? Hvor befinder din kode sig? Skal udviklerne have tilladelse til adgang?<\/p>\n

<\/p>\n

\"Skiftede
\nOperations as Code<\/em><\/p>\n

<\/p>\n

At v\u00e6re softwareudvikler handler ikke bare om at skrive kode.<\/p><\/blockquote>\n

Ikke kun AWS: du bruger sandsynligvis tjenester fra andre udbydere. SignalFx, PagerDuty eller GitHub. M\u00e5ske har du en intern Jenkins-server til CI\/CD eller et internt Grafana-dashboard til overv\u00e5gning. Infra as Code v\u00e6lges af forskellige grunde, og hver eneste er lige s\u00e5 vigtig for alting relateret til software.<\/p>\n

<\/p>\n

Da jeg arbejdede hos Twitch, accelererede vi tjenester inden for blandede indbyggede systemer og AWS-systemer. Vi producerede og vedligeholdt mange mikrotjenester, hvilket \u00f8gede driftsomkostningerne. Diskussionerne forl\u00f8b nogenlunde s\u00e5dan:<\/p>\n

<\/p>\n