{"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\/nl\/blog\/administrirovanie\/pereshel-s-terraform-na-cloudformation-i-pozhalel","title":{"rendered":"Ik ben van Terraform naar CloudFormation overgestapt \u2014 en het was een vergissing","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Infrastructuur presenteren als code in een herhaalbaar tekstformaat is een eenvoudig betere praktijk voor systemen waarmee je niet hoeft te rommelen. Deze praktijk staat bekend als \u2014 Infrastructure as Code<\/a><\/noindex>, en totdat nu zijn er vooral twee populaire tools voor implementatie, vooral in AWS: Terraform<\/a><\/noindex> en CloudFormation<\/a><\/noindex>.<\/p>\n

<\/p>\n

\"Ik
\nIk vergelijk de ervaring met Terraform en CloudFormation<\/em><\/p>\n

<\/p>\n

Voor ik bij Twitch<\/a><\/noindex> (ook wel bekend als Amazon Jr.<\/a><\/noindex>) werkte, heb ik in een startup gewerkt<\/a><\/noindex> en heb drie jaar Terraform gebruikt. Bij mijn nieuwe werkgever heb ik ook volop Terraform gebruikt, maar daarna heeft het bedrijf de overstap naar alles dat lijkt op Amazon doorgedrukt, inclusief CloudFormation. Ik heb hard gewerkt aan de beste praktijken voor zowel het een als het ander, en beide tools gebruikt in zeer complexe workflows op organisatorische schaal. Later, na zorgvuldig de gevolgen van de overstap van Terraform naar CloudFormation af te wegen, realiseerde ik me dat Terraform waarschijnlijk de beste keuze voor de organisatie is.<\/p>\n

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

Terraform is verschrikkelijk<\/h2>\n

<\/p>\n

Beta-versie van de software<\/h3>\n

<\/p>\n

Terraform heeft zelfs nog geen versie 1.0 uitgebracht, en dat is een goede reden om het niet te gebruiken. Sinds ik het voor het eerst probeerde, is het aanzienlijk veranderd, maar destijds was het nog terraform apply<\/code> Het viel vaak uit na een paar updates of gewoon na een paar jaar gebruik. Ik zou zeggen dat 'nu alles anders is', maar\u2026 dat zeggen toch eigenlijk allemaal, niet? Er zijn wijzigingen die niet compatibel zijn met eerdere versies, hoewel ze gerechtvaardigd zijn, en zelfs het gevoel dat de syntaxis en abstraheringen van hulpbronnen nu precies goed zijn. Het lijkt wel alsof het hulpmiddel echt beter is geworden, maar\u2026 :-0<\/p>\n

<\/p>\n

Aan de andere kant heeft AWS goed zijn best gedaan om de compatibiliteit met eerdere versies te behouden. Waarschijnlijk omdat hun diensten vaak grondig intern worden getest en pas daarna, onder een andere naam, worden gepubliceerd. Dus 'goed gedaan' is nog zwak uitgedrukt. Compatibiliteit met eerdere versies van de API behouden voor zo'n veelzijdig en complex systeem als AWS is ongelooflijk moeilijk. Iedereen die ooit publieke API's heeft moeten onderhouden die zo breed worden gebruikt, moet begrijpen hoe moeilijk het is om dit jarenlang vol te houden. Het gedrag van CloudFormation is in mijn herinnering nooit veranderd door de jaren heen.<\/p>\n

<\/p>\n

Maak kennis met je voet\u2026 dit is een kogel<\/h3>\n

<\/p>\n

Voor zover ik weet, kun je een externe bron niet verwijderen.<\/strong> Het is niet mogelijk om een CloudFormation-stack vanuit je CF-stack te importeren. Hetzelfde geldt ongeveer voor Terraform. Dit stelt je in staat om bestaande resources in je stack te importeren. Het is een indrukwekkende functie, maar met grote kracht komt ook grote verantwoordelijkheid. Nadat je een resource in de stack hebt toegevoegd, kun je deze niet verwijderen of wijzigen terwijl je met je stack werkt. Eens leidde dit tot problemen. Iemand importeerde per ongeluk een beveiligingsgroep van AWS in zijn eigen Terraform-stack op de Twitch-website. Hij voerde een paar opdrachten in en... de beveiligingsgroep (samen met het inkomende verkeer) verdween.<\/p>\n

<\/p>\n

Terraform de Grote<\/h2>\n

<\/p>\n

Herstellen vanuit onvolledige toestanden<\/h3>\n

<\/p>\n

Soms is CloudFormation niet in staat om volledig van de ene toestand naar de andere over te gaan. In dat geval probeert het terug te keren naar de vorige toestand. Helaas is dat niet altijd mogelijk. Het kan behoorlijk eng zijn om te debuggen wat het resultaat is \u2014 je weet nooit of CloudFormation blij is dat je het probeert te hakken \u2014 zelfs als het om te herstellen is. Of het lukt om naar de vorige toestand terug te keren, weet het niet echt en standaard hangt het urenlang te wachten op een wonder.<\/p>\n

<\/p>\n

Terraform daarentegen is over het algemeen beter in het herstellen na mislukte overgangen en biedt een uitgebreid debugging-hulpmiddel.<\/p>\n

<\/p>\n

Duidelijkere verandering in documenttoestanden<\/h3>\n

<\/p>\n

'Goed, load balancer, je verandert. Maar hoe?'<\/p>\n

- bezorgde ingenieur, klaar om op de knop 'accepteren' te drukken.<\/p><\/blockquote>\n

Soms moet ik een aantal handelingen uitvoeren met de load balancer in de CloudFormation-stack \u2014 bijvoorbeeld een poortnummer toevoegen of de beveiligingsgroep wijzigen. CloudFormation toont wijzigingen slecht weer. Ik controleer het yaml-bestand wel tien keer om er zeker van te zijn dat ik niets belangrijks heb verwijderd en niets overbodigs heb toegevoegd.<\/p>\n

<\/p>\n

Terraform is hierin veel transparanter. Soms zelfs te transparant (lees: irritant). Gelukkig is in de laatste versie verbeterde weergave van wijzigingen toegevoegd \u2014 nu is het precies zichtbaar wat er verandert.<\/p>\n

<\/p>\n

Flexibiliteit<\/h3>\n

<\/p>\n

Schrijf software van achter naar voren.<\/p><\/blockquote>\n

Eerlijk gezegd is de belangrijkste onderscheidende eigenschap van langlevende software de mogelijkheid om zich aan veranderingen aan te passen. Schrijf elke software vanuit de achterkant. Ik stelde meestal teleurstellingen vast toen ik een 'eenvoudige' service nam en vervolgens alles in \u00e9\u00e9n CloudFormation- of Terraform-stack probeerde te proppen. En natuurlijk werd pas maanden later duidelijk dat ik het helemaal verkeerd begreep, en de service was in werkelijkheid helemaal niet zo eenvoudig! En nu moet ik op een of andere manier een grote stack opdelen in kleinere onderdelen. Wanneer je met CloudFormation werkt, is het mogelijk dit alleen te doen door de bestaande stack opnieuw op te bouwen, en dat doe ik niet met mijn databases. Terraform daarentegen stelde me in staat om de stack te dissecteren en op te splitsen in meer begrijpelijke kleinere delen.<\/p>\n

<\/p>\n

Modules in git<\/h3>\n

<\/p>\n

Het delen van Terraform-code tussen talloze stacks is veel eenvoudiger dan het delen van CloudFormation-code. Met Terraform kun je code in een git-repository plaatsen en deze aanspreken met semantische versiecontrole. Iedereen met toegang tot deze repository kan de gedeelde code opnieuw gebruiken. Het CloudFormation-equivalent is S3, maar dat heeft niet dezelfde voordelen, en er is geen enkele reden waarom we \u00fcberhaupt S3 ten koste van git zouden moeten gebruiken.<\/p>\n

<\/p>\n

De organisatie groeide en de mogelijkheid om gedeelde stacks te delen bereikte een kritiek niveau. Met Terraform gaat dit allemaal gemakkelijk en natuurlijk, terwijl CloudFormation je door hoepels laat springen voordat je iets dergelijks aan de praat krijgt.<\/p>\n

<\/p>\n

Operations as code<\/h3>\n

<\/p>\n

'Laten we maar gaan script-igen.'<\/p>\n

- een ingenieur drie jaar voordat hij de fiets Terraform uitvond.<\/p><\/blockquote>\n

Als het om softwareontwikkeling gaat, is Go of een programma in Java niet zomaar code.<\/p>\n

<\/p>\n

\"Ik
\nCode als Code<\/em><\/p>\n

<\/p>\n

Er is ook de infrastructuur waarop het draait.<\/p>\n

<\/p>\n

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

<\/p>\n

Maar waar komt het vandaan? Hoe monitor je het? Waar woont jouw code? Hebben ontwikkelaars toestemming voor toegang nodig?<\/p>\n

<\/p>\n

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

<\/p>\n

Software-ontwikkeling is niet alleen code schrijven.<\/p><\/blockquote>\n

Niet alleen AWS: je gebruikt ongetwijfeld de diensten van andere leveranciers. SignalFx, PagerDuty of Github. Misschien heb je een interne Jenkins-server voor CI\/CD of een intern Grafana-dashboard voor monitoring. Infra as Code wordt om verschillende redenen gekozen, en elke reden is even belangrijk voor alles wat met software te maken heeft.<\/p>\n

<\/p>\n

Toen ik bij Twitch werkte, versnelden we diensten binnen gemengde ingebouwde systemen en systemen van AWS Amazon. We produceerden en ondersteunden talloze microservices, wat de operationele kosten verhoogde. De discussies verliepen ongeveer als volgt:<\/p>\n

<\/p>\n