{"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\/de\/blog\/administrirovanie\/pereshel-s-terraform-na-cloudformation-i-pozhalel","title":{"rendered":"Ich bin von Terraform auf CloudFormation umgestiegen \u2013 und habe es bereut.","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Infrastruktur als Code im wiederholbaren Textformat darzustellen, ist eine bew\u00e4hrte Praxis f\u00fcr Systeme, die sich nicht vor einem Mouse-Over scheuen. Diese Praxis wird auch genannt \u2013 Infrastructure as Code<\/a><\/noindex>, und bisher gibt es zwei beliebte Werkzeuge, um dies zu realisieren, besonders bei AWS: Terraform<\/a><\/noindex> und CloudFormation<\/a><\/noindex>.<\/p>\n

<\/p>\n

\"Ich
\nIch vergleiche die Erfahrungen mit Terraform und CloudFormation<\/em><\/p>\n

<\/p>\n

Bevor ich zu Twitch<\/a><\/noindex> (auch bekannt als Amazon Jr.<\/a><\/noindex>) kam, arbeitete ich in einem Startup<\/a><\/noindex> und nutzte drei Jahre lang Terraform. An meinem neuen Arbeitsplatz verwendete ich ebenfalls intensiv Terraform, aber schlie\u00dflich setzte das Unternehmen auf alles aus der Amazon-Welt, einschlie\u00dflich CloudFormation. Ich entwickelte eifrig Best Practices f\u00fcr beide Werkzeuge und setzte sie in sehr komplexen Arbeitsabl\u00e4ufen auf Unternehmensebene ein. Nachdem ich die Konsequenzen des Wechsels von Terraform zu CloudFormation durchdacht hatte, stellte ich fest, dass Terraform wahrscheinlich die beste Wahl f\u00fcr die Organisation ist.<\/p>\n

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

Terraform ist schrecklich<\/h2>\n

<\/p>\n

Beta-Software<\/h3>\n

<\/p>\n

Terraform hat noch nicht einmal die Version 1.0 erreicht, und das ist ein guter Grund, es nicht zu verwenden. Seitdem ich es zum ersten Mal ausprobiert habe, hat es sich stark ver\u00e4ndert, aber damals war noch terraform apply<\/code> Der Dienst hat nach ein paar Updates oder einfach nach einigen Jahren Nutzung oft versagt. Man k\u00f6nnte sagen: \u201eJetzt ist alles anders\u201c, aber\u2026 so h\u00f6rt man das stets, oder? Es gibt \u00c4nderungen, die nicht mit vorherigen Versionen kompatibel sind, auch wenn sie sinnvoll sind. Man hat sogar das Gef\u00fchl, dass die Syntax und die Abstraktionen der Ressourcenverwaltung nun passen. Das Tool scheint wirklich besser geworden zu sein, aber\u2026 :-0<\/p>\n

<\/p>\n

Auf der anderen Seite hat AWS gute Arbeit geleistet, um die Kompatibilit\u00e4t mit vorherigen Versionen zu wahren. Wahrscheinlich, weil ihre Dienste oft gr\u00fcndlich innerhalb der Organisation getestet werden, bevor sie umbenannt und ver\u00f6ffentlicht werden. Daher ist \u201egut gearbeitet\u201c noch schwach ausgedr\u00fcckt. Die Unterst\u00fctzung der Kompatibilit\u00e4t mit vorherigen API-Versionen in einem so vielseitigen und komplexen System wie AWS ist unglaublich herausfordernd. Jeder, der schon einmal \u00f6ffentliche APIs betreut hat, die so weit verbreitet sind, sollte verstehen, wie schwierig es ist, das \u00fcber viele Jahre hinweg zu tun. Das Verhalten von CloudFormation hat sich in meinen Erinnerungen \u00fcber die Jahre hinweg nicht ge\u00e4ndert.<\/p>\n

<\/p>\n

Lernt kennen, Fu\u00df\u2026 das ist eine Kugel.<\/h3>\n

<\/p>\n

Soweit ich wei\u00df, kann man eine Ressource entfernen. fremd<\/strong> Es ist nicht m\u00f6glich, einen CloudFormation-Stack aus seinem CF-Stack zu extrahieren. \u00c4hnlich verh\u00e4lt es sich mit Terraform. Es erm\u00f6glicht das Importieren bestehender Ressourcen in seinen Stack. Diese Funktion ist wirklich beeindruckend, aber mit gro\u00dfer Macht kommt auch gro\u00dfe Verantwortung. Sobald eine Ressource im Stack ist, kann sie nicht mehr entfernt oder ver\u00e4ndert werden, w\u00e4hrend man mit dem Stack arbeitet. Einmal gab es ein Vorfall. Auf der Website von Twitch importierte jemand, ohne b\u00f6se Absichten, versehentlich eine Sicherheitsgruppe von AWS in seinen eigenen Terraform-Stack. Er gab ein paar Befehle ein und\u2026 die Sicherheitsgruppe (samt dem eingehenden Verkehr) war verschwunden.<\/p>\n

<\/p>\n

Terraform ist gro\u00dfartig<\/h2>\n

<\/p>\n

Wiederherstellung aus unvollst\u00e4ndigen Zust\u00e4nden<\/h3>\n

<\/p>\n

Manchmal kann CloudFormation nicht vollst\u00e4ndig von einem Zustand in einen anderen \u00fcbergehen. In diesem Fall wird es versuchen, zum vorherigen Zustand zur\u00fcckzukehren. Schade, dass dies nicht immer m\u00f6glich ist. Es kann be\u00e4ngstigend sein, das, was dabei herauskommt, zu debuggen \u2013 man wei\u00df nie, ob sich CloudFormation freut, dass es gehackt wird \u2013 auch wenn es nur zur Reparatur dient. Ob es gelingt, zum vorherigen Zustand zur\u00fcckzukehren, kann es nicht richtig bestimmen und h\u00e4ngt standardm\u00e4\u00dfig stundenlang auf in der Hoffnung auf ein Wunder.<\/p>\n

<\/p>\n

Terraform hingegen ist dazu in der Lage, sich nach fehlgeschlagenen \u00dcberg\u00e4ngen eleganter zu erholen und bietet ein erweitertes Debugging-Toolkit.<\/p>\n

<\/p>\n

Eindeutigere \u00c4nderungen im Dokumentzustand<\/h3>\n

<\/p>\n

\u201eOkay, Lastenverteiler, du ver\u00e4nderst dich. Aber wie?\u201c<\/p>\n

\u2014 ein besorgter Ingenieur, bereit, den Button \u201eAkzeptieren\u201c zu dr\u00fccken.<\/p><\/blockquote>\n

Manchmal muss ich einige Anpassungen am Lastenausgleich im CloudFormation-Stack vornehmen \u2013 zum Beispiel die Portnummer hinzuf\u00fcgen oder die Sicherheitsgruppe \u00e4ndern. CloudFormation zeigt \u00c4nderungen schwach an. Ich pr\u00fcfe die YAML-Datei zehnmal, um sicherzustellen, dass ich nichts Wichtiges gel\u00f6scht und nichts \u00dcberfl\u00fcssiges hinzugef\u00fcgt habe.<\/p>\n

<\/p>\n

In dieser Hinsicht ist Terraform deutlich transparenter. Manchmal ist er sogar zu transparent (sprich: nervig). Gl\u00fccklicherweise wurde in die letzte Version eine verbesserte \u00c4nderungsanzeige eingef\u00fchrt \u2013 jetzt ist genau ersichtlich, was sich \u00e4ndert.<\/p>\n

<\/p>\n

Flexibilit\u00e4t<\/h3>\n

<\/p>\n

Schreiben Sie Software r\u00fcckw\u00e4rts.<\/p><\/blockquote>\n

Um es direkt zu sagen, das wichtigste Unterscheidungsmerkmal langlebiger Software ist die F\u00e4higkeit, sich an Ver\u00e4nderungen anzupassen. Jede Software sollte man von hinten her denken. Oft habe ich den Fehler gemacht, einen \u201eeinfachen\u201c Service zu w\u00e4hlen und ihn dann in einen einzigen CloudFormation- oder Terraform-Stack zu integrieren. Und wie es nun einmal so ist, stellte sich Monate sp\u00e4ter heraus, dass ich es ganz falsch verstanden hatte und der Service in Wirklichkeit gar nicht so einfach war! Also musste ich irgendwie einen gro\u00dfen Stack in kleine Komponenten aufteilen. Wenn man mit CloudFormation arbeitet, ist das nur m\u00f6glich, wenn man zun\u00e4chst den bestehenden Stack neu erstellt, und das mache ich mit meinen Datenbanken nicht. Terraform hingegen erlaubte es mir, den Stack zu zerlegen und in verst\u00e4ndlichere kleinere Teile zu zergliedern.<\/p>\n

<\/p>\n

Module in git<\/h3>\n

<\/p>\n

Es ist viel einfacher, Terraform-Code zwischen mehreren Stacks zu teilen als CloudFormation-Code. Mit Terraform kann man den Code in ein Git-Repository legen und \u00fcber semantische Versionskontrolle darauf zugreifen. Jeder, der Zugriff auf dieses Repository hat, kann den gemeinsamen Code erneut nutzen. Das \u00c4quivalent in CloudFormation ist S3, aber es bietet nicht die gleichen Vorteile und es gibt keinen Grund, warum wir Git zugunsten von S3 \u00fcberhaupt aufgeben sollten.<\/p>\n

<\/p>\n

Das Unternehmen wuchs und die F\u00e4higkeit, gemeinsame Stacks zu teilen, erreichte einen kritischen Punkt. Mit Terraform funktioniert das ganz einfach und nat\u00fcrlich, w\u00e4hrend CloudFormation Sie durch mehrere H\u00fcrden springen l\u00e4sst, bevor Sie etwas \u00c4hnliches zum Laufen bringen k\u00f6nnen.<\/p>\n

<\/p>\n

Operations als Code<\/h3>\n

<\/p>\n

\u201eLass uns das einfach skripten.\u201c<\/p>\n

\u2014 Ingenieur drei Jahre, bevor Terraform das Fahrrad erfand.<\/p><\/blockquote>\n

Wenn es um Softwareentwicklung geht, ist Go oder ein Java-Programm nicht nur Code.<\/p>\n

<\/p>\n

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

<\/p>\n

Es gibt schlie\u00dflich auch die Infrastruktur, auf der es l\u00e4uft.<\/p>\n

<\/p>\n

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

<\/p>\n

Aber woher kommt sie? Wie wird sie \u00fcberwacht? Wo wohnt Ihr Code? Brauchen die Entwickler Zugriffserlaubnis?<\/p>\n

<\/p>\n

\"Ich
\nOperations als Code<\/em><\/p>\n

<\/p>\n

Softwareentwickler zu sein bedeutet nicht nur, Code zu schreiben.<\/p><\/blockquote>\n

Nicht nur AWS: Sie nutzen mit Sicherheit auch Dienste anderer Anbieter wie SignalFx, PagerDuty oder GitHub. Vielleicht haben Sie einen internen Jenkins-Server f\u00fcr CI\/CD oder ein internes Grafana-Dashboard zur \u00dcberwachung. Infra as Code wird aus verschiedenen Gr\u00fcnden ausgew\u00e4hlt, und jeder ist ebenso wichtig f\u00fcr alles, was mit Software zu tun hat.<\/p>\n

<\/p>\n

Als ich bei Twitch arbeitete, haben wir die Services in gemischten Embedded-Systemen und den AWS-Systemen von Amazon beschleunigt. Wir haben zahlreiche Mikrodienste erstellt und gewartet, was die Betriebskosten erh\u00f6ht hat. Die Diskussionen liefen ungef\u00e4hr so ab:<\/p>\n

<\/p>\n