Infrastruktur als Code im wiederholbaren Textformat darzustellen, ist eine bewährte Praxis für Systeme, die sich nicht vor einem Mouse-Over scheuen. Diese Praxis wird auch genannt – , und bisher gibt es zwei beliebte Werkzeuge, um dies zu realisieren, besonders bei AWS: und .
Ich vergleiche die Erfahrungen mit Terraform und CloudFormation
Bevor ich zu (auch bekannt als ) kam, arbeitete ich und nutzte drei Jahre lang Terraform. An meinem neuen Arbeitsplatz verwendete ich ebenfalls intensiv Terraform, aber schließlich setzte das Unternehmen auf alles aus der Amazon-Welt, einschließlich CloudFormation. Ich entwickelte eifrig Best Practices für beide Werkzeuge und setzte sie in sehr komplexen Arbeitsabläufen 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ür die Organisation ist.
Terraform ist schrecklich
Beta-Software
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ändert, aber damals war noch terraform apply Es kam häufig nach mehreren Updates oder einfach nach ein paar Jahren Nutzung zu Problemen. Ich könnte sagen, dass „jetzt alles anders ist“, aber… so sagt es doch jeder, oder? Es gibt Änderungen, die nicht mit vorherigen Versionen kompatibel sind, obwohl sie sinnvoll sind, und es fühlt sich sogar so an, als sei die Syntax und die Abstraktion der Ressourcenverwaltung jetzt genau richtig. Das Werkzeug scheint tatsächlich besser geworden zu sein, aber… :-0
Auf der anderen Seite hat AWS gute Arbeit geleistet, um die Kompatibilität mit vorherigen Versionen zu unterstützen. Wahrscheinlich liegt das daran, dass ihre Dienste oft gut intern getestet werden, bevor sie umbenannt und veröffentlicht werden. „Gut gemacht“ ist da noch gelinde gesagt. Die Kompatibilität mit vorherigen API-Versionen für ein so variantenreiches und komplexes System wie AWS aufrechtzuerhalten, ist unglaublich schwierig. Jeder, der einmal öffentlich zugängliche APIs unterstützt hat, die so weit verbreitet genutzt werden, sollte verstehen, wie schwer das über so viele Jahre hinweg ist. Das Verhalten von CloudFormation hat sich meiner Erinnerung nach nicht einmal über die Jahre geändert.
Lernt kennen, Fuß… das ist eine Kugel.
Soweit ich weiß, kann man eine Ressource entfernen. fremd Es ist nicht möglich, einen CloudFormation-Stack aus seinem CF-Stack zu extrahieren. Ähnlich verhält es sich mit Terraform. Es ermöglicht das Importieren bestehender Ressourcen in seinen Stack. Diese Funktion ist wirklich beeindruckend, aber mit großer Macht kommt auch große Verantwortung. Sobald eine Ressource im Stack ist, kann sie nicht mehr entfernt oder verändert werden, während man mit dem Stack arbeitet. Einmal gab es ein Vorfall. Auf der Website von Twitch importierte jemand, ohne böse Absichten, versehentlich eine Sicherheitsgruppe von AWS in seinen eigenen Terraform-Stack. Er gab ein paar Befehle ein und… die Sicherheitsgruppe (samt dem eingehenden Verkehr) war verschwunden.
Terraform ist großartig
Wiederherstellung aus unvollständigen Zuständen
Manchmal kann CloudFormation nicht vollständig von einem Zustand in einen anderen übergehen. In diesem Fall wird es versuchen, zum vorherigen Zustand zurückzukehren. Schade, dass dies nicht immer möglich ist. Es kann beängstigend sein, das, was dabei herauskommt, zu debuggen – man weiß nie, ob sich CloudFormation freut, dass es gehackt wird – auch wenn es nur zur Reparatur dient. Ob es gelingt, zum vorherigen Zustand zurückzukehren, kann es nicht richtig bestimmen und hängt standardmäßig stundenlang auf in der Hoffnung auf ein Wunder.
Terraform hingegen ist dazu in der Lage, sich nach fehlgeschlagenen Übergängen eleganter zu erholen und bietet ein erweitertes Debugging-Toolkit.
Eindeutigere Änderungen im Dokumentzustand
„Okay, Lastenausgleich, du änderst dich. Aber wie?“
—ein besorgter Ingenieur, der bereit ist, die Schaltfläche „Akzeptieren“ zu drücken.
Manchmal muss ich einige Anpassungen am Lastenausgleich im CloudFormation-Stack vornehmen – zum Beispiel die Portnummer hinzufügen oder die Sicherheitsgruppe ändern. CloudFormation zeigt Änderungen schwach an. Ich prüfe die YAML-Datei zehnmal, um sicherzustellen, dass ich nichts Wichtiges gelöscht und nichts Überflüssiges hinzugefügt habe.
In dieser Hinsicht ist Terraform deutlich transparenter. Manchmal ist er sogar zu transparent (sprich: nervig). Glücklicherweise wurde in die letzte Version eine verbesserte Änderungsanzeige eingeführt – jetzt ist genau ersichtlich, was sich ändert.
Flexibilität
Schreiben Sie Software rückwärts.
Um es direkt zu sagen: Die wichtigste Eigenschaft langlebiger Software ist die Fähigkeit, sich an Veränderungen anzupassen. Bei jeder Software sollte man rückwärts denken. Ich habe oft den Fehler gemacht, einen „einfachen“ Dienst auszuwählen, um dann alles in einem einzigen CloudFormation- oder Terraform-Stack unterzubringen. Und natürlich stellte sich Monate später heraus, dass ich alles falsch verstanden hatte und der Dienst tatsächlich nicht so einfach war! Daher musste ich auf irgendeine Weise den großen Stack in kleinere Komponenten zerlegen. Wenn man mit CloudFormation arbeitet, kann man dies nur tun, indem man zuerst den bestehenden Stack wiederherstellt, was ich mit meinen Datenbanken nicht mache. Terraform hingegen erlaubte es mir, den Stack zu zerlegen und in verständlichere kleinere Teile zu gliedern.
Module in git
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 über semantische Versionskontrolle darauf zugreifen. Jeder, der Zugriff auf dieses Repository hat, kann den gemeinsamen Code erneut nutzen. Das Äquivalent in CloudFormation ist S3, aber es bietet nicht die gleichen Vorteile und es gibt keinen Grund, warum wir Git zugunsten von S3 überhaupt aufgeben sollten.
Das Unternehmen wuchs und die Fähigkeit, gemeinsame Stacks zu teilen, erreichte einen kritischen Punkt. Mit Terraform funktioniert das ganz einfach und natürlich, während CloudFormation Sie durch mehrere Hürden springen lässt, bevor Sie etwas Ähnliches zum Laufen bringen können.
Operations als Code
«Lass uns das skripten und gut ist.»
— Ingenieur drei Jahre, bevor Terraform das Fahrrad erfand.
Wenn es um Softwareentwicklung geht, ist Go oder ein Java-Programm nicht nur Code.
Code als Code
Es gibt schließlich auch die Infrastruktur, auf der es läuft.
Infrastructure as Code
Aber woher kommt sie? Wie wird sie überwacht? Wo wohnt Ihr Code? Brauchen die Entwickler Zugriffserlaubnis?
Operations als Code
Softwareentwickler zu sein bedeutet nicht nur, Code zu schreiben.
Nicht nur AWS: Sie nutzen mit Sicherheit auch Dienste anderer Anbieter wie SignalFx, PagerDuty oder GitHub. Vielleicht haben Sie einen internen Jenkins-Server für CI/CD oder ein internes Grafana-Dashboard zur Überwachung. Infra as Code wird aus verschiedenen Gründen ausgewählt, und jeder ist ebenso wichtig für alles, was mit Software zu tun hat.
Als ich bei Twitch arbeitete, haben wir die Dienste in hybriden Embedded-Systemen und AWS-Systemen von Amazon beschleunigt. Wir haben zahlreiche Mikrodienste erstellt und unterstützt, was die Betriebskosten erhöht hat. Die Diskussionen liefen etwa so ab:
- Ich: Wow, das ist ganz schön viel Aufwand, um einen einzelnen Mikrodienst zu beschleunigen. Ich werde diese ganze Sache brauchen, um ein AWS-Konto zu erstellen (wir haben auf 2 Konten aufgestockt, Mikrodienst), danach diese hier für die Einrichtung von Benachrichtigungen, dann diese für das Code-Repository, und diese für die E-Mail-Adressenliste, und dann noch diese…
- Lead: Lass uns das skripten und gut ist.
- Ich: Okay, aber das Skript wird sich ändern. Wir brauchen einen Weg, um sicherzustellen, dass all diese eingebetteten Amazon-Dinge aktuell sind.
- Lead: Klingt gut. Dafür schreiben wir ein Skript.
- Ich: Super! Das Skript wird sicher auch Parameter benötigen. Wird es die akzeptieren?
- Lead: Klar wird es das akzeptieren, was denkst du denn?
- Ich: Der Prozess könnte sich ändern, die Rückwärtskompatibilität geht verloren. Wir brauchen eine Art semantische Versionskontrolle.
- Lead: Tolle Idee!
- Ich: Werkzeuge können manuell im Benutzerinterface geändert werden. Wir benötigen einen Weg, um dies zu überprüfen und zu korrigieren.
…3 Jahre später:
- Lead: Und wir haben Terraform erstellt.
Die Moral der Geschichte ist: Selbst wenn Sie in allem von Amazon stecken,nutzen Sie dennoch etwas, das nicht von AWS stammt, und diese Dienste haben einen Zustand, der Sprache zur Konfiguration verwendet, um diesen Zustand zu synchronisieren.
CloudFormation Lambda vs. Git-Module Terraform
Lambda ist die Lösung von CloudFormation für die Benutzerlogik. Mit Lambda können Sie oder . Dieser Ansatz bringt zusätzliche Komplikationen mit sich, die im semantischen Versionskontrollsystem von Git bei Terraform nicht vorkommen. Für mich war das drängendste Problem die Verwaltung der Berechtigungen für all diese benutzerdefinierten Lambdas (und das sind Dutzende von AWS-Konten). Ein weiteres wichtiges Problem war die klassische Henne-Ei-Frage, die sich auf den Lambda-Code bezog. Diese Funktion ist sowohl Infrastruktur als auch Code und benötigt selbst Monitoring sowie Updates. Der letzte Nagel im Sarg war die Schwierigkeit bei der semantischen Aktualisierung der Lambda-Codeänderungen; es musste auch sichergestellt werden, dass die Aktionen der Stacks ohne direkte Befehle zwischen den Ausführungen nicht verändert wurden.
Ich erinnere mich, dass ich einmal einen Canary-Deployment für die Elastic Beanstalk-Umgebung mit einem klassischen Lastenausgleich erstellen wollte. Es wäre am einfachsten gewesen, ein zweites Deployment für EB neben der Produktionsumgebung zu erstellen, und einen weiteren Schritt zu unternehmen, indem ich die automatisch skalierbare Gruppe des Canary-Deployments mit dem LB-Deployment in der Produktionsumgebung kombinierte. Und da Terraform verwendet , das erfordert 4 zusätzliche Codezeilen in Terraform. Als ich nach einer vergleichbaren Lösung in CloudFormation fragte, wurde ich auf ein ganzes Git-Repository mit einem Bereitstellungspipeline und mehr verwiesen: und das alles nur wegen 4 armen Zeilen Terraform-Code.
Es erkennt Drift besser
Stellen Sie sicher, dass die Realität den Erwartungen entspricht.
ist eine sehr leistungsstarke Funktion von Operations as Code, da sie hilft sicherzustellen, dass die Realität den Erwartungen entspricht. Sie ist sowohl mit CloudFormation als auch mit Terraform verfügbar. Aber mit zunehmender Größe des Stacks gab es bei der Drifterkennung in CloudFormation immer mehr Fehlalarme.
Mit Terraform haben Sie viel fortschrittlichere Lifecycle-Hooks zur Drift-Erkennung. Zum Beispiel geben Sie den Befehl direkt in der ECS-Aufgabenbeschreibung ein, wenn Sie Änderungen an der Beschreibung einer bestimmten Aufgabe ignorieren möchten, ohne Änderungen an der gesamten ECS-Bereitstellung zu ignorieren.
CDK und die Zukunft von CloudFormation
CloudFormation ist in großen, inter-infrastrukturellen Maßstäben schwierig zu handhaben. Viele dieser Schwierigkeiten sind bekannt, und das Werkzeug benötigt Dinge wie , Struktur zur Definition von Cloud-Infrastruktur im Code und ihrer Implementierung über AWS CloudFormation. Es wird interessant sein zu sehen, was die Zukunft für AWS CDK bereithält, aber es wird schwer sein, mit den anderen Vorteilen von Terraform zu konkurrieren; um CloudFormation wettbewerbsfähig zu machen, sind umfassende Änderungen erforderlich.
Damit Terraform nicht enttäuscht.
Es handelt sich um «Infrastructure as Code» und nicht um «Textangebot».
Mein erstes Eindrück von Terraform war eher negativ. Ich glaube, ich habe den Ansatz einfach nicht verstanden. Fast alle Ingenieure nehmen es zunächst unfreiwillig als Textformat wahr, das in die gewünschte Infrastruktur umgewandelt werden muss. DAS IST NICHT NOTWENDIG.
Die grundlegenden Prinzipien guter Softwareentwicklung gelten auch für Terraform.
Ich habe gesehen, wie viele bewährte Praktiken für die Erstellung von gutem Code in Terraform ignoriert werden. Sie haben jahrelang gelernt, um ein guter Programmierer zu werden. Verwerfen Sie dieses Wissen nicht einfach, nur weil Sie mit Terraform arbeiten. Die grundlegenden Prinzipien guter Softwareentwicklung gelten auch für Terraform.
Wie kann man Code schreiben und ihn nicht dokumentieren?
Ich bin auf riesige Terraform-Stacks gestoßen, die völlig ohne Dokumentation auskamen. Wie kann man Code ohne jegliche Dokumentation schreiben? Fügen Sie Dokumentationen 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 früher eine große Funktion in der main() waren?
Ich habe sehr komplexe Terraform-Stacks gesehen, die als eine einzige Modulstruktur präsentiert wurden. Warum erstellen wir Software nicht so? Warum zerlegen wir große Funktionen in kleinere? Dieselben Antworten gelten auch für Terraform. Wenn Ihr Modul zu groß ist, sollten Sie es in kleinere Module aufteilen.
Verwendet Ihr Unternehmen nicht Bibliotheken?
Ich habe gesehen, wie Ingenieure beim Start eines neuen Projekts mit Terraform einfach große Teile aus anderen Projekten kopiert und eingefügt haben und die dann bearbeitet haben, bis es funktionierte. Würden Sie so mit „Produktions-“Code in Ihrem Unternehmen arbeiten? Wir nutzen doch nicht ohne Grund Bibliotheken. Ja, aber wo wären wir ohne gemeinsame Bibliotheken im Grunde genommen?!
Verwenden Sie nicht PEP8 oder gofmt?
In den meisten Programmiersprachen gibt es ein anerkanntes Standardformatierungsschema. In Python ist es PEP8. In Go – gofmt. Terraform hat sein eigenes: terraform fmt. Viel Spaß damit!
Würden Sie React verwenden, ohne JavaScript zu kennen?
Terraform-Module können einige Teile Ihrer komplexen Infrastruktur vereinfachen, aber das bedeutet nicht, dass Sie die Grundlagen nicht verstehen müssen. Möchten Sie Terraform richtig nutzen, ohne die Ressourcen zu verstehen? Das wird schwierig: die Zeit vergeht, und Sie werden Terraform nicht meistern.
Programmieren Sie mit Singletons oder durch Dependency Injection?
Dependency Injection ist eine weithin anerkannte Best Practice in der Softwareentwicklung, die von Singletons bevorzugt wird. Wie kommt das in Terraform zum Tragen? Ich habe Terraform-Module gesehen, die auf den Remote-Status angewiesen sind. Anstatt Module zu schreiben, die aus dem Remote-Status herauslesen, erstellen Sie ein Modul, das Parameter akzeptiert. Übergeben Sie diese Parameter dann an das Modul.
Machen Ihre Bibliotheken zehn Dinge gut oder eine Sache ausgezeichnet?
Bibliotheken, die sich auf eine einzige Aufgabe konzentrieren, funktionieren am besten. Anstatt große Terraform-Module zu schreiben, die versuchen, alles gleichzeitig zu erledigen, teilen Sie sie in Teile auf, die jeweils eine Sache gut können. Kombinieren Sie dann diese Teile nach Bedarf.
Wie nehmen Sie Änderungen an Bibliotheken ohne Abwärtskompatibilität vor?
Ein allgemeines Terraform-Modul benötigt wie jede Bibliothek einen Weg, um Benutzer über Änderungen ohne Abwärtskompatibilität zu informieren. Solche Änderungen in Bibliotheken sind ärgerlich, und ebenso ärgerlich sind Änderungen ohne Abwärtskompatibilität in Terraform-Modulen. Es wird empfohlen, Git-Tags und Semver bei der Verwendung von Terraform-Modulen zu verwenden.
Läuft Ihr Produktionsservice auf Ihrem Laptop oder im Rechenzentrum?
Hashicorp bietet Werkzeuge wie zur Ausführung Ihres Terraform. Diese zentralisierten Dienste erleichtern das Management, die Überprüfung und die Genehmigung von Terraform-Änderungen.
Schreiben Sie keine Tests?
Ingenieure wissen, dass Code getestet werden muss, aber oftmals vernachlässigen sie die Überprüfungen, während sie mit Terraform arbeiten. Für die Infrastruktur kann dies heimtückische Probleme mit sich bringen. Ich empfehle, Stacks mit Modulen zu "testen" oder "Beispiele" zu erstellen, die korrekt deployt werden können, um sie während CI/CD zu überprüfen.
Terraform und Mikrodienste
Das Leben und die Zukunft von Unternehmen, die auf Mikrodiensten basieren, hängt von der Geschwindigkeit, Aktualisierung und Zerstörung neuer Mikrodienst-Produktionsstacks ab.
Das am häufigsten genannte negative Merkmal von Mikrodienstarchitekturen, dem sich kaum entkommen lässt, betrifft die Arbeitsweise und nicht den Code. Wenn man Terraform nur als Werkzeug betrachtet, um die infrastrukturelle Seite der Mikrodienstarchitektur zu automatisieren, beraubt man sich der echten Vorteile dieses Systems. Heutzutage ist bereits alles – .
Quelle: habr.com
