Wechsel von Terraform zu CloudFormation – und bereut

Die Darstellung von Infrastruktur als Code in einem wiederholbaren Textformat ist eine bewährte Praxis für Systeme, die kein Mausefällchen erfordert. Diese Praxis hat den Namen - Infrastructure as Code, und bisher gibt es dafür, insbesondere in AWS, zwei beliebte Werkzeuge: Terraform und CloudFormation.

Ich vergleiche die Erfahrungen mit Terraform und CloudFormation

Vor meinem Wechsel zu Twitch (auch bekannt als Amazon Jr.) war ich beschäftigt in einem Startup 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ßlich CloudFormation, durchgesetzt hat. Ich habe eifrig die besten Praktiken für beide Werkzeuge entwickelt und beide in sehr komplexen Arbeitsabläufen im Unternehmensmaßstab eingesetzt. Später, nachdem ich die Folgen des Wechsels von Terraform zu CloudFormation sorgfältig abgewogen hatte, stellte ich fest, dass Terraform wahrscheinlich die beste Wahl für das Unternehmen ist.

Terraform ist schrecklich

Die Beta-Version der Software

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ändert, aber damals terraform apply brach oft nach mehreren Updates oder einfach nach ein paar Jahren Nutzung zusammen. Ich würde sagen, dass „es jetzt ganz anders ist“, aber… so scheint es wohl jeder zu sagen, oder? Es gibt Änderungen, die mit vorherigen Versionen nicht kompatibel sind, obwohl sie angebracht sind, und es hat sogar den Anschein, als wäre die Syntax und die Abstraktionen der Ressourcenspeicher jetzt genau richtig. Das Werkzeug scheint tatsächlich besser geworden zu sein, aber… :-0

Auf der anderen Seite hat AWS gut gearbeitet, um die Kompatibilität mit vorherigen Versionen zu unterstützen. Wahrscheinlich liegt das daran, dass ihre Dienste häufig gründlich im Unternehmen getestet werden und erst dann umbenannt veröffentlicht werden. Daher ist „gut gearbeitet“ sogar noch schwach ausgedrückt. Die Unterstützung der Kompatibilität mit vorherigen API-Versionen für ein so variantenreiches und komplexes System wie AWS ist unglaublich schwierig. Jeder, der schon einmal öffentliche APIs gepflegt hat, die so weit verbreitet sind, sollte verstehen, wie schwer das über so viele Jahre hinweg ist. Das Verhalten von CloudFormation hingegen hat sich meiner Erinnerung nach im Laufe der Jahre nie verändert.

Lerne kennen, Fuß… das ist eine Kugel

Soweit ich weiß, lässt sich ein Ressource von Dritten nicht löschen Es ist nicht möglich, einen CloudFormation-Stack aus einem eigenen CF-Stack zu stehlen. Ähnlich verhält es sich mit Terraform. Es ermöglicht, bestehende Ressourcen in seinen Stack zu importieren. Man kann sagen, diese Funktion ist erstaunlich, aber mit großer Kraft kommt große Verantwortung. Sobald man eine Ressource in den Stack aufnimmt, kann man diese Ressource nicht mehr löschen oder ändern, während man mit seinem Stack arbeitet. Einmal kam das zurück, um einen zu beißen. Irgendwo auf der Webseite von Twitch hat jemand, ohne böse Absichten, versehentlich die AWS-Sicherheitsgruppe eines anderen in seinen eigenen Terraform-Stack importiert. Er gab ein paar Befehle ein und… die Sicherheitsgruppe (nebst dem eingehenden Datenverkehr) verschwand.

Terraform Großartig

Wiederherstellung aus unvollständigen Zuständen

Manchmal kann CloudFormation nicht vollständig von einem Zustand in einen anderen übergehen. In diesem Fall versucht es, zum vorherigen Zustand zurückzukehren. Schade, dass das nicht immer machbar ist. Es kann ganz schön beängstigend sein, das, was am Ende herauskommt, zu debuggen — man weiß nie, ob CloudFormation sich freut, dass man es hackt — wenn auch nur zur Reparatur. Ob es gelingt oder nicht, zum vorherigen Zustand zurückzukehren, kann es nicht wirklich bestimmen und wartet standardmäßig stundenlang auf ein Wunder.

Terraform hingegen neigt dazu, nach fehlgeschlagenen Übergängen viel eleganter wiederherzustellen und bietet erweiterte Debugging-Tools an.

Klarere Änderungen im Dokumentzustand

„Okay, Lastenausgleich, du änderst dich. Aber wie?“

— besorgter Ingenieur, bereit, die Annahmetaste zu drücken.

Manchmal muss ich ein paar Manipulationen mit dem Lastenausgleich im CloudFormation-Stack durchführen — zum Beispiel eine Portnummer hinzufügen oder die Sicherheitsgruppe ändern. CloudFormation zeigt Änderungen schwach an. Ich hingegen bin ganz nervös und prüfe die YAML-Datei mindestens zehnmal, um sicherzustellen, dass ich nichts Wichtiges gelöscht oder etwas Überflüssiges hinzugefügt habe.

Terraform ist in dieser Hinsicht viel transparenter. Manchmal ist es sogar zu transparent (sprich: nervig). Glücklicherweise wurde in die letzte Version eine verbesserte Anzeige von Änderungen aufgenommen — jetzt sieht man genau, was sich ändert.

Flexibilität

Schreibt Software von hinten.

Um es direkt zu sagen, das wichtigste Unterscheidungsmerkmal langlebiger Software ist ihre Fähigkeit, sich an Veränderungen anzupassen. Jede Software solltest du umgekehrt entwickeln. Ich habe mich oft dabei erwischt, dass ich einen ‚einfachen‘ Dienst genommen habe und dann versucht habe, alles in einen einzigen CloudFormation- oder Terraform-Stack zu quetschen. Und natürlich stellte sich Monate später heraus, dass ich alles falsch verstanden hatte und der Dienst in Wirklichkeit nicht einfach war! Und ich musste auf irgendeine Weise den großen Stack in kleine Komponenten zerlegen. Wenn du mit CloudFormation arbeitest, ist das nur möglich, wenn du den bestehenden Stack zuerst wiederherstellst, was ich mit meinen Datenbanken nicht mache. Terraform hingegen ermöglichte es mir, den Stack zu zerlegen und in verständlichere, kleinere Teile zu gliedern.

Module in git

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 überhaupt auf Git zu Gunsten von S3 verzichten sollten.

Die Organisation wuchs, und die Fähigkeit, gemeinsame Stacks zu teilen, erreichte ein kritisches Niveau. Mit Terraform gelingt das leicht und natürlich, während CloudFormation dich dazu zwingt, durch viele Ringe zu springen, bevor du etwas Ähnliches zum Laufen bringst.

Operations als Code

„Lass uns das skripten und gut ist“.

– Ingenieur drei Jahre bevor er das Fahrrad Terraform erfand.

Wenn es um Softwareentwicklung geht, ist Go oder ein Programm in Java nicht nur Code.

Code als Code

Es gibt auch die Infrastruktur, auf der sie läuft.

Infrastructure as Code

Aber woher kommt die dort? Wie überwacht man sie? Wo lebt dein Code? Brauchen Entwickler eine Genehmigung, um darauf zuzugreifen?

Operations als Code

Ein Softwareentwickler zu sein bedeutet nicht nur, Code zu schreiben.

Nicht nur AWS: Du nutzt sicher auch die Dienste anderer Anbieter. SignalFx, PagerDuty oder Github. Vielleicht hast du einen internen Jenkins-Server für CI/CD oder ein internes Grafana-Dashboard zur Überwachung. Infra as Code wird aus verschiedenen Gründen gewählt, und jeder ist für alles, was mit Software zu tun hat, gleich wichtig.

Als ich bei Twitch arbeitete, beschleunigten wir die Dienste innerhalb gemischter eingebetteter Systeme und der AWS-Systeme von Amazon. Wir erzeugten und unterstützten zahlreiche Mikrodienste und erhöhten die Betriebskosten. Die Diskussionen verliefen ungefähr in folgendem Sinne:

• Ich: Mann, das sind ganz schön viele Handgriffe, um einen Mikrodienst zu starten. Ich muss dieses Ding benutzen, um ein AWS-Konto zu erstellen (wir strebten zwei Konten an auf Mikrodienst), dann dieses hier – für die Einrichtung von Benachrichtigungen, noch dieses – für das Code-Repository, und dieses – für die Liste der E-Mail-Adressen, und dieses hier…
• Lead: Lass uns ein Skript schreiben und gut ist.
• Ich: Einverstanden, aber das Skript wird sich ändern. Wir brauchen einen Weg, um zu überprüfen, dass all diese eingebetteten Amazon-Sachen einen aktuellen Zustand haben.
• Lead: Klingt gut. Und dafür werden wir ein Skript schreiben.
• Ich: Ausgezeichnet! Und das Skript muss sicherlich auch Parameter annehmen. Nimmt es die entgegen?
• Lead: Natürlich, was sollte es sonst tun?
• Ich: Der Prozess könnte sich ändern, die Abwärtskompatibilität könnte verloren gehen. Wir werden eine Art semantische Versionskontrolle benötigen.
• Lead: Großartige Idee!
• Ich: Die Werkzeuge können manuell im Benutzerinterface geändert werden. Wir benötigen einen Weg, um das zu überprüfen und zu beheben.

…3 Jahre später:

• Lead: Und so haben wir Terraform.

Die Moral der Geschichte: selbst wenn Sie bis zur Halskrause in allem Amazon sind, verwenden Sie immer noch etwas, das nicht von AWS stammt, und diese Dienste haben einen Zustand, der eine Sprache zur Konfiguration verwendet, um diesen Zustand zu synchronisieren. CloudFormation Lambda vs. Git-Module TerraformLambda ist die Lösung von CloudFormation für das Thema benutzerdefinierte Logik. Mit Lambda kann man

Makros

benutzerdefinierte Ressourcen . Dieser Ansatz bringt zusätzliche Komplikationen mit sich, die es in der semantischen Versionskontrolle von Git-Modulen bei Terraform nicht gibt. Für mich wurde die dringlichste Herausforderung die Verwaltung von Berechtigungen für all diese benutzerdefinierten Lambdas (und das sind Dutzende von AWS-Konten). Ein weiteres wichtiges Problem war die Frage „Was war zuerst – das Huhn oder das Ei?“: Sie hing mit dem Lambda-Code zusammen. Diese Funktion selbst ist Infrastruktur und Code, und sie benötigt selbst Monitoring und Updates. Der letzte Nagel im Sarg war die Schwierigkeit, semantische Aktualisierungen im Lambda-Code vorzunehmen; außerdem musste sichergestellt werden, dass die Aktionen des Stacks nicht ohne direkten Befehl zwischen den Ausführungen änderten. oder benutzerdefinierte Ressourcen.

Ich erinnere mich, dass ich irgendwann einen Canary-Deploy für die Elastic Beanstalk-Umgebung mit einem klassischen Load Balancer erstellen wollte. Am einfachsten wäre es gewesen, ein zweites Deployment für EB neben der Produktionsumgebung zu machen, indem ich einen weiteren Schritt gehe: die automatisch skalierbare Gruppe des Canary-Deployments mit dem LB-Deployment in die Produktionsumgebung zu kombinieren. Da Terraform verwendet ASG beantalk als Ausgabe, benötigt es 4 zusätzliche Zeilen Code in Terraform. Als ich nach einer vergleichbaren Lösung in CloudFormation fragte, wurde ich auf ein ganzes Repository auf Git hingewiesen, das ein Deployment-Pipeline und mehr enthält: und all das nur, damit man die unglücklichen 4 Zeilen Terraform-Code machen könnte.

Es erkennt Drift besser

Stellen Sie sicher, dass die Realität Ihren Erwartungen entspricht.

Drift-Erkennung ist eine sehr leistungsstarke Funktion von Operations as Code, da sie sicherstellt, dass die Realität Ihren Erwartungen entspricht. Sie ist sowohl mit CloudFormation als auch mit Terraform verfügbar. Aber mit zunehmendem Wachstum des Stacks sorgte die Drift-Suche in CloudFormation für immer mehr Fehlalarme.

Mit Terraform haben Sie viel fortgeschrittenere Lebenszyklus-Hooks zur Drift-Erkennung. Zum Beispiel geben Sie den Befehl ignore_changes direkt in die ECS-Aufgabendefinition ein, wenn Sie Änderungen an einer bestimmten Aufgabe ignorieren möchten, ohne dabei Änderungen am gesamten ECS-Deployment zu ignorieren.

CDK und die Zukunft von CloudFormation

CloudFormation ist schwer zu verwalten in großen, bereichsübergreifenden Maßstäben. Viele dieser Schwierigkeiten sind anerkannt, und das Tool benötigt Dinge wie aws-cdk, eine Struktur zur Definition der Cloud-Infrastruktur im Code und zur Durchführung über AWS CloudFormation. Es wird interessant sein zu sehen, was die Zukunft für aws-cdk bereithält, aber es wird schwierig sein, mit den anderen Vorteilen von Terraform zu konkurrieren; um CloudFormation aufzuholen, werden umfassende Änderungen notwendig sein.

Damit Terraform nicht enttäuscht

Es handelt sich schließlich um 'Infrastructure as CODE' und nicht um 'wie Text'.

Mein erster Eindruck von Terraform war ziemlich negativ. Ich denke, ich habe den Ansatz einfach nicht verstanden. Fast alle Ingenieure sehen es zunächst unfreiwillig als Textformat, das in die gewünschte Infrastruktur umgewandelt werden muss. DAS MUSS NICHT SEIN.

Die einfachen Wahrheiten guter Softwareentwicklung gelten auch für Terraform.

Ich habe gesehen, dass viele Praktiken, die zur Erstellung guten Codes beitragen, in Terraform ignoriert werden. Sie haben jahrelang gelernt, um ein guter Programmierer zu werden. Geben Sie diese Erfahrung nicht einfach auf, nur weil Sie mit Terraform arbeiten. Grundsatzweisheiten guter Softwareentwicklung gelten auch für Terraform.

Wie kann man Code nicht dokumentieren?

Ich habe riesige Terraform-Stacks ohne jede Dokumentation gesehen. Wie kann man Code seitenweise schreiben — völlig ohne Dokumentation? Fügen Sie Dokumentation hinzu, die erklärt, was Ihr Code Terraform (hier liegt der Schwerpunkt auf dem Wort „Code“), warum dieser Abschnitt so wichtig ist und was Sie tun.

Wie können Sie Dienste bereitstellen, die einst eine große Funktion main() waren?

Mir sind sehr komplexe Terraform-Stacks begegnet, die als einzelnes Modul dargestellt wurden. Warum implementieren wir Software nicht so? Warum teilen wir große Funktionen in kleinere auf? Die gleichen Antworten gelten auch für Terraform. Wenn Ihr Modul zu groß ist — sollten Sie es in kleinere Module aufteilen.

Benutzt Ihr Unternehmen etwa keine Bibliotheken?

Ich habe gesehen, wie Ingenieure, die ein neues Projekt mit Terraform hochziehen, große Teile aus anderen Projekten einfach kopiert und eingefügt haben, und dann daran herumgebastelt haben, bis es funktioniert hat. Würden Sie in Ihrem Unternehmen so mit „Produktions“-Code arbeiten? Wir verwenden Bibliotheken nicht ohne Grund. Ja, nicht alles sollte eine Bibliothek sein, aber wo wären wir ohne gemeinsame Bibliotheken im Prinzip?!

Benutzen Sie nicht PEP8 oder gofmt?

In den meisten Programmiersprachen gibt es ein standardisiertes Formatierungschema. In Python ist es PEP8. In Go — gofmt. Terraform hat sein eigenes: terraform fmt. Nutzen Sie es gerne!

Würden Sie React verwenden, ohne JavaScript zu kennen?

Terraform-Module können einen Teil der von Ihnen erstellten komplexen Infrastruktur vereinfachen, aber das bedeutet nicht, dass Sie überhaupt nichts davon verstehen können. Möchten Sie Terraform korrekt verwenden, ohne die Ressourcen zu verstehen? Sie sind zum Scheitern verurteilt: Die Zeit vergeht, und Sie werden Terraform nicht erlernen.

Programmieren Sie mit Singletons oder durch Injektion von Abhängigkeiten?

Dependency Injection ist eine anerkannte Best Practice für die Softwareentwicklung, die von Singleton-Architekturen bevorzugt wird. Wie kann das in Terraform nützlich sein? Mir sind Terraform-Module begegnet, die von einem Remote-Status abhängen. Anstatt Module zu schreiben, die den Remote-Status abrufen, sollten Sie ein Modul erstellen, das Parameter akzeptiert. Übergeben Sie dann diese Parameter an das Modul.

Machen Ihre Bibliotheken zehn Dinge gut oder eins – hervorragend?

Am besten funktionieren Bibliotheken, die sich auf eine einzige Aufgabe konzentrieren, die sie ausgezeichnet erfüllen. Anstatt große Terraform-Module zu schreiben, die versuchen, alles auf einmal zu erledigen, teilen Sie sie in Komponenten auf, die jeweils eine Sache gut machen. Kombinieren Sie diese dann nach Bedarf.

Wie bringen Sie Änderungen in Bibliotheken ohne Abwärtskompatibilität ein?

Ein allgemeines Terraform-Modul, ebenso wie eine normale Bibliothek, muss den Benutzern auf irgendeine Weise über Änderungen ohne Abwärtskompatibilität berichten. Wenn solche Änderungen in Bibliotheken vorgenommen werden, ist das ärgerlich, und es ist genau so ärgerlich, wenn Abwärtskompatibilität in Terraform-Modulen verletzt wird. Es wird empfohlen, git-Tags und semver beim Einsatz von Terraform-Modulen zu verwenden.

Läuft der Produktionsdienst auf Ihrem Laptop oder in einem Rechenzentrum?

Hashicorp hat Tools wie terraform cloud um Ihr Terraform auszuführen. Diese zentralisierten Dienste erleichtern die Verwaltung, Prüfung und Genehmigung von Änderungen in Terraform.

Schreiben Sie keine Tests?

Ingenieure erkennen an, dass der Code getestet werden muss, aber oft vernachlässigen sie die Tests, während sie mit Terraform arbeiten. Für die Infrastruktur kann das zu heimtückischen Problemen führen. Ich empfehle, Stacks mit Modulen zu 'testen' oder 'Beispiele' zu erstellen, die korrekt bereitgestellt werden können, um sie während CI/CD zu überprüfen.

Terraform und Microservices

Die Existenz und das Versagen von Microservice-Unternehmen hängt von der Geschwindigkeit, Aktualisierung und dem Abbau neuer microservice-basierten Arbeits-Stacks ab.

Das am häufigsten genannte negative Element im Zusammenhang mit Microservice-Architekturen, von dem man sich nicht befreien kann, hängt mit der Arbeit und nicht mit dem Code zusammen. Wenn Sie Terraform nur als Mittel zur Automatisierung des infrastrukturellen Teils einer Microservice-Architektur betrachten, berauben Sie sich der echten Vorteile dieses Systems. Jetzt schon alles – als Code.

Quelle: habr.com