{"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":"Wechsel von Terraform zu CloudFormation \u2013 und bereut","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Die Darstellung von Infrastruktur als Code in einem wiederholbaren Textformat ist eine bew\u00e4hrte Praxis f\u00fcr Systeme, die kein Mausef\u00e4llchen erfordert. Diese Praxis hat den Namen - Infrastructure as Code<\/a><\/noindex>, und bisher gibt es daf\u00fcr, insbesondere in AWS, zwei beliebte Werkzeuge: Terraform<\/a><\/noindex> und CloudFormation<\/a><\/noindex>.<\/p>\n

<\/p>\n

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

<\/p>\n

Vor meinem Wechsel zu Twitch<\/a><\/noindex> (auch bekannt als Amazon Jr.<\/a><\/noindex>) war ich besch\u00e4ftigt in einem Startup<\/a><\/noindex> und habe etwa drei Jahre Terraform verwendet. An meinem neuen Arbeitsplatz habe ich ebenfalls intensiv Terraform genutzt, bis das Unternehmen den Wechsel zu allem was Amazon angeht, einschlie\u00dflich CloudFormation, durchgesetzt hat. Ich habe eifrig die besten Praktiken f\u00fcr beide Werkzeuge entwickelt und beide in sehr komplexen Arbeitsabl\u00e4ufen im Unternehmensma\u00dfstab eingesetzt. Sp\u00e4ter, nachdem ich die Folgen des Wechsels von Terraform zu CloudFormation sorgf\u00e4ltig abgewogen hatte, stellte ich fest, dass Terraform wahrscheinlich die beste Wahl f\u00fcr das Unternehmen ist.<\/p>\n

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

Terraform ist schrecklich<\/h2>\n

<\/p>\n

Die Beta-Version der Software<\/h3>\n

<\/p>\n

Terraform hat noch nicht einmal Version 1.0 erreicht, und das ist ein gewichtiges Argument, es nicht zu verwenden. Seit ich es das erste Mal ausprobiert habe, hat es sich stark ver\u00e4ndert, aber damals terraform apply<\/code> Es ist oft nach mehreren Updates oder einfach nach ein paar Jahren der Benutzung ausgefallen. Ich w\u00fcrde sagen, dass \"jetzt alles anders ist\", aber... so sagen es wohl alle, oder? Es gibt \u00c4nderungen, die mit fr\u00fcheren Versionen inkompatibel sind, auch wenn sie sinnvoll sind, und sogar das Gef\u00fchl, dass die Syntax und die Abstraktionen von Ressourcenspeichern jetzt genau richtig sind. Das Tool scheint tats\u00e4chlich besser geworden zu sein, aber\u2026 :-0<\/p>\n

<\/p>\n

Andererseits hat AWS gute Arbeit geleistet, indem es die Kompatibilit\u00e4t mit vorherigen Versionen unterst\u00fctzt hat. Das liegt wahrscheinlich daran, dass ihre Dienste oft gr\u00fcndlich intern getestet werden, bevor sie umbenannt ver\u00f6ffentlicht werden. Daher ist \"gut gemacht\" eigentlich noch geschmeichelt. Die Kompatibilit\u00e4t mit vorherigen API-Versionen f\u00fcr ein so vielschichtiges und komplexes System wie AWS aufrechtzuerhalten, ist unglaublich schwierig. Jeder, der \u00f6ffentliche APIs, die so weit verbreitet verwendet werden, warten musste, sollte verstehen, wie schwierig es ist, das \u00fcber so viele Jahre hinweg zu tun. Aber das Verhalten von CloudFormation hat sich meiner Erinnerung nach \u00fcber die Jahre nie ge\u00e4ndert.<\/p>\n

<\/p>\n

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

<\/p>\n

Soweit ich wei\u00df, l\u00e4sst sich ein Ressource von Dritten nicht l\u00f6schen<\/strong> Es ist nicht m\u00f6glich, einen CloudFormation-Stack aus einem eigenen CF-Stack zu stehlen. \u00c4hnlich verh\u00e4lt es sich mit Terraform. Es erm\u00f6glicht, bestehende Ressourcen in seinen Stack zu importieren. Man kann sagen, diese Funktion ist erstaunlich, aber mit gro\u00dfer Kraft kommt gro\u00dfe Verantwortung. Sobald man eine Ressource in den Stack aufnimmt, kann man diese Ressource nicht mehr l\u00f6schen oder \u00e4ndern, w\u00e4hrend man mit seinem Stack arbeitet. Einmal kam das zur\u00fcck, um einen zu bei\u00dfen. Irgendwo auf der Webseite von Twitch hat jemand, ohne b\u00f6se Absichten, versehentlich die AWS-Sicherheitsgruppe eines anderen in seinen eigenen Terraform-Stack importiert. Er gab ein paar Befehle ein und\u2026 die Sicherheitsgruppe (nebst dem eingehenden Datenverkehr) verschwand.<\/p>\n

<\/p>\n

Terraform 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 versucht es, zum vorherigen Zustand zur\u00fcckzukehren. Schade, dass das nicht immer machbar ist. Es kann ganz sch\u00f6n be\u00e4ngstigend sein, das, was am Ende herauskommt, zu debuggen \u2014 man wei\u00df nie, ob CloudFormation sich freut, dass man es hackt \u2014 wenn auch nur zur Reparatur. Ob es gelingt oder nicht, zum vorherigen Zustand zur\u00fcckzukehren, kann es nicht wirklich bestimmen und wartet standardm\u00e4\u00dfig stundenlang auf ein Wunder.<\/p>\n

<\/p>\n

Terraform hingegen neigt dazu, nach fehlgeschlagenen \u00dcberg\u00e4ngen viel eleganter wiederherzustellen und bietet erweiterte Debugging-Tools an.<\/p>\n

<\/p>\n

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

<\/p>\n

\"Okay, Lastenausgleich, du \u00e4nderst dich. Aber wie?\"<\/p>\n

- besorgter Ingenieur, bereit, die Schaltfl\u00e4che \"Akzeptieren\" zu dr\u00fccken.<\/p><\/blockquote>\n

Manchmal muss ich ein paar Manipulationen mit dem Lastenausgleich im CloudFormation-Stack durchf\u00fchren \u2014 zum Beispiel eine Portnummer hinzuf\u00fcgen oder die Sicherheitsgruppe \u00e4ndern. CloudFormation zeigt \u00c4nderungen schwach an. Ich hingegen bin ganz nerv\u00f6s und pr\u00fcfe die YAML-Datei mindestens zehnmal, um sicherzustellen, dass ich nichts Wichtiges gel\u00f6scht oder etwas \u00dcberfl\u00fcssiges hinzugef\u00fcgt habe.<\/p>\n

<\/p>\n

Terraform ist in dieser Hinsicht viel transparenter. Manchmal ist es sogar zu transparent (sprich: nervig). Gl\u00fccklicherweise wurde in die letzte Version eine verbesserte Anzeige von \u00c4nderungen aufgenommen \u2014 jetzt sieht man genau, was sich \u00e4ndert.<\/p>\n

<\/p>\n

Flexibilit\u00e4t<\/h3>\n

<\/p>\n

Schreibt Software von hinten.<\/p><\/blockquote>\n

Um es klar zu sagen, das wichtigste Merkmal langlebiger Software ist die F\u00e4higkeit, sich an Ver\u00e4nderungen anzupassen. Jegliche Software sollte man r\u00fcckblickend entwickeln. Ich habe meistens dadurch Fehler gemacht, dass ich einen \"einfachen\" Dienst genommen habe und dann versucht habe, alles in einen einzigen CloudFormation- oder Terraform-Stack zu zw\u00e4ngen. Und nat\u00fcrlich stellte sich Monate sp\u00e4ter heraus, dass ich alles falsch verstanden hatte und der Dienst in Wirklichkeit gar nicht einfach war! Ich musste den gro\u00dfen Stack somehow in kleinere Komponenten zerlegen. Wenn man mit CloudFormation arbeitet, ist das nur m\u00f6glich, wenn man den bestehenden Stack zuvor wiederherstellt, was ich mit meinen DBs nicht mache. Terraform hingegen erlaubte es, den Stack auseinanderzunehmen und in verst\u00e4ndlichere, kleinere Teile zu zerlegen.<\/p>\n

<\/p>\n

Module in git<\/h3>\n

<\/p>\n

Code zwischen zahlreichen Stacks in Terraform zu teilen ist viel einfacher als in CloudFormation. Mit Terraform kannst du den Code in ein Git-Repository speichern und ihn unter Verwendung von semantischer Versionskontrolle darauf zugreifen. Jeder, der Zugang zu diesem Repository hat, kann den gemeinsamen Code wiederverwenden. Das Pendant in CloudFormation ist S3, aber es hat nicht die gleichen Vorteile, und es gibt keinen Grund, warum wir \u00fcberhaupt auf Git zu Gunsten von S3 verzichten sollten.<\/p>\n

<\/p>\n

Die Organisation wuchs, und die F\u00e4higkeit, gemeinsame Stacks zu teilen, erreichte ein kritisches Niveau. Mit Terraform gelingt das leicht und nat\u00fcrlich, w\u00e4hrend CloudFormation dich dazu zwingt, durch viele Ringe zu springen, bevor du etwas \u00c4hnliches zum Laufen bringst.<\/p>\n

<\/p>\n

Operations als Code<\/h3>\n

<\/p>\n

\"Lass uns das skripten und fertig!\"<\/p>\n

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

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

<\/p>\n

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

<\/p>\n

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

<\/p>\n

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

<\/p>\n

Aber woher kommt die dort? Wie \u00fcberwacht man sie? Wo lebt dein Code? Brauchen Entwickler eine Genehmigung, um darauf zuzugreifen?<\/p>\n

<\/p>\n

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

<\/p>\n

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

Nicht nur AWS: Du nutzt sicher auch die Dienste anderer Anbieter. SignalFx, PagerDuty oder Github. Vielleicht hast du einen internen Jenkins-Server f\u00fcr CI\/CD oder ein internes Grafana-Dashboard zur \u00dcberwachung. Infra as Code wird aus verschiedenen Gr\u00fcnden gew\u00e4hlt, und jeder ist f\u00fcr alles, was mit Software zu tun hat, gleich wichtig.<\/p>\n

<\/p>\n

Als ich bei Twitch arbeitete, beschleunigten wir Dienste innerhalb gemischter eingebetteter Systeme und des AWS-Systems von Amazon. Wir stellten eine Vielzahl von Mikrodiensten her und unterst\u00fctzten sie, wodurch die Betriebskosten stiegen. Die Diskussionen verliefen in etwa so:<\/p>\n

<\/p>\n