Viele kennen und verwenden Terraform in ihrem täglichen Arbeitsalltag, doch es haben sich bislang keine Best Practices herausgebildet. Jedes Team muss seine eigenen Ansätze und Methoden erfinden.
Ihre Infrastruktur beginnt wahrscheinlich auf ganz einfache Weise: einige Ressourcen + einige Entwickler. Mit der Zeit wächst sie in alle möglichen Richtungen. Sie finden Wege, Ressourcen in Terraform-Module zu gruppieren, organisieren den Code in Ordnern, und was könnte dabei schon schiefgehen? (bekannte letzte Worte)
Die Zeit vergeht, und Sie haben das Gefühl, dass Ihre Infrastruktur Ihr neues Haustier ist. Aber warum? Sie sind besorgt über unerklärliche Veränderungen in der Infrastruktur, haben Angst, die Infrastruktur und den Code anzutasten — letztlich verzögern Sie neue Funktionen oder verringern die Qualität...
Nach drei Jahren der Verwaltung einer Sammlung von Community-Modulen für Terraform auf Github für AWS und der langfristigen Betreuung von Terraform in der Produktion ist Anton Babенко bereit, seine Erfahrungen zu teilen: wie man TF-Module schreibt, damit es in Zukunft nicht schmerzhaft wird.
Am Ende des Vortrags werden die Teilnehmer besser mit den Prinzipien des Ressourcenmanagements in Terraform, den besten Praktiken im Zusammenhang mit Modulen in Terraform und einigen Prinzipien der kontinuierlichen Integration, die mit dem Infrastrukturmanagement verbunden sind, vertraut sein.
Haftungsausschluss: Ich möchte darauf hinweisen, dass der Vortrag auf November 2018 datiert ist – es sind bereits 2 Jahre vergangen. Die im Vortrag behandelte Version von Terraform 0.11 wird nicht mehr unterstützt. In den letzten 2 Jahren wurden 2 neue Versionen veröffentlicht, die viele Neuerungen, Verbesserungen und Änderungen mit sich brachten. Bitte beachten Sie dies und vergleichen Sie es mit der Dokumentation.
Links:
- +
- — automatisches Formatieren von Code und Dokumentation
- — Generator für Terraform-Module (WIP)
- — Generator von Terraform-Code aus visuellen Diagrammen (WIP)
- www.terraform-best-practices.com
- (Neue Beiträge finden Sie auf der persönlichen Website www.antonbabenko.com/)
- @antonbabenko — Twitter und viele verschiedene Slacks
Mein Name ist Anton Babenko. Einige von Ihnen haben wahrscheinlich den Code verwendet, den ich geschrieben habe. Ich werde jetzt mit mehr Selbstvertrauen darüber sprechen als je zuvor, denn ich habe Zugang zu den Statistiken.
Ich beschäftige mich mit Terraform und bin seit 2015 aktives Mitglied und Mitwirkender an zahlreichen Open-Source-Projekten, die mit Terraform und Amazon zu tun haben.
Seitdem habe ich genug Code geschrieben, um das in einer interessanten Form darzustellen. Und genau das werde ich jetzt versuchen zu erklären.
Ich werde über die Feinheiten und spezifischen Aspekte der Arbeit mit Terraform sprechen. Aber eigentlich ist das nicht das Thema für HighLoad. Und jetzt werdet ihr verstehen, warum.
Im Laufe der Zeit habe ich angefangen, Terraform-Module zu schreiben. Benutzer hatten Fragen, ich habe sie umgeschrieben. Dann habe ich verschiedene Tools für die Codeformatierung mit pre-commit Hooks geschrieben usw.
Es gab viele interessante Projekte. Ich mag es, Code-Generatoren zu entwickeln, denn ich liebe es, wenn der Computer immer mehr Arbeit für mich und den Programmierer erledigt. Deshalb arbeite ich jetzt an einem Generator für Terraform-Code aus visuellen Diagrammen. Vielleicht hat einer von euch sie gesehen. Das sind schöne Kästchen mit Pfeilen. Und ich finde es großartig, wenn man auf die Schaltfläche 'Exportieren' klicken kann und all dies als Code erhält.
Ich komme aus der Ukraine. Ich lebe seit vielen Jahren in Norwegen.
Die Informationen für diesen Vortrag stammen auch von Personen, die meinen Namen kennen und mich in sozialen Netzwerken finden. Ich habe fast immer denselben Benutzernamen.
Wie ich bereits erwähnt habe, bin ich der Hauptmaintainer der Terraform AWS-Module, einem der größten Repositories auf GitHub, wo wir Module für die häufigsten Aufgaben hosten: VPC, Autoscaling, RDS.
Was Sie gerade gehört haben, ist das Allerwichtigste. Wenn Sie Zweifel daran haben, dass Sie verstehen, was Terraform ist, dann ist es besser, Ihre Zeit woanders zu verbringen. Hier wird es viele technische Begriffe geben. Ich habe nicht gescheut, das höchstmögliche Niveau dieses Vortrags zu verkünden. Das bedeutet, dass ich alle möglichen Begriffe ohne besondere Erklärungen verwenden kann.
Terraform wurde 2014 als ein Tool eingeführt, das es ermöglicht, Infrastruktur als Code zu schreiben, zu planen und zu verwalten. Der Schlüsselbegriff hier ist „Infrastruktur als Code“.
Die gesamte Dokumentation, wie ich bereits sagte, ist auf . Ich hoffe, dass die meisten von Ihnen von dieser Seite wissen und die Dokumentation gelesen haben. Wenn ja, sind Sie am richtigen Ort.
So sieht eine typische Terraform-Konfigurationsdatei aus, in der wir zunächst einige Variablen definieren.
In diesem Fall definieren wir „aws_region“.
Dann beschreiben wir, welche Ressourcen wir erstellen möchten.
Wir führen einige Befehle aus, insbesondere „terraform init“, um Abhängigkeiten und Provider zu laden.
Und wir führen den Befehl „terraform apply“ aus, um zu überprüfen, ob die angegebene Konfiguration mit den Ressourcen übereinstimmt, die wir erstellt haben. Da wir zuvor nichts erstellt haben, schlägt Terraform vor, diese Ressourcen zu erstellen.
Wir bestätigen dies. So erstellen wir einen Bucket, der seasnail heißt.
Es gibt auch einige ähnliche Tools. Viele von euch, die Amazon nutzen, kennen AWS CloudFormation oder Google Cloud Deployment Manager oder Azure Resource Manager. Jedes von ihnen hat eine eigene Implementierung zur Verwaltung von Ressourcen innerhalb dieser Public-Cloud-Anbieter. Terraform ist besonders nützlich, da es die Verwaltung von über 100 Anbietern ermöglicht. (Mehr erfahren) )
Die Ziele, die Terraform von Anfang an verfolgt hat:
- Terraform bietet eine einheitliche Ansicht von Ressourcen.
- Es ermöglicht die Unterstützung aller modernen Plattformen.
- Terraform wurde von Anfang an als ein Werkzeug konzipiert, das es ermöglicht, Infrastruktur sicher und vorhersehbar zu ändern.
Im Jahr 2014 klang das Wort „vorhersehbar“ in diesem Kontext sehr ungewöhnlich.
Terraform ist ein universelles Tool. Wenn Sie eine API haben, können Sie alles verwalten:
- Sie können über 120 Anbieter verwenden, um alles zu steuern, was Ihnen beliebt.
- Beispielsweise kann Terraform verwendet werden, um den Zugang zu GitHub-Repositories zu beschreiben.
- Man kann sogar Bugs in Jira erstellen und schließen.
- Es ist möglich, New Relic-Metriken zu verwalten.
- Sie können sogar Dateien in Dropbox erstellen, wenn Ihnen danach ist.
All dies wird durch Terraform-Provider erreicht, die eine offene API haben und in Go beschrieben werden können.
Angenommen, Sie haben mit Terraform begonnen, haben etwas Dokumentation auf der Website gelesen, sich ein Video angesehen und angefangen, main.tf zu schreiben, wie ich in den vorherigen Folien gezeigt habe.
Und es läuft alles super, Sie haben eine Datei erstellt, die ein VPC erstellt.
Wenn Sie ein VPC erstellen möchten, geben Sie ungefähr diese 12 Zeilen an. Sie beschreiben, in welcher Region Sie es erstellen möchten und welchen CIDR-Block von IP-Adressen Sie verwenden wollen. Das war's.
Natürlich wird das Projekt schrittweise wachsen.
Und Sie werden dabei eine Menge neuer Dinge hinzufügen: Ressourcen, Datenquellen, Sie werden sich mit neuen Anbietern integrieren, unerwartet möchten Sie Terraform verwenden, um die Nutzer in Ihrem GitHub-Konto zu verwalten, usw. Vielleicht möchten Sie verschiedene DNS-Anbieter nutzen und alles miteinander kombinieren. Terraform macht das einfach.
Betrachten wir folgendes Beispiel.
Sie fügen schrittweise ein internet_gateway hinzu, weil Sie möchten, dass die Ressourcen aus Ihrem VPC Zugang zum Internet haben. Das ist eine gute Idee.
Am Ende sieht die main.tf so aus:
Das ist der obere Teil der main.tf.
Das ist der untere Teil der main.tf.
Dann fügen Sie ein subnet hinzu. Wenn Sie zu dem Zeitpunkt NAT-Gateways, Routen, Routing-Tabellen und eine Menge anderer Subnets hinzufügen möchten, wird Ihre Datei nicht 38 Zeilen haben, sondern etwa 200-300 Zeilen.
Das heißt, Ihre main.tf-Datei wächst allmählich. Und ziemlich oft packen die Leute alles in eine Datei. Die main.tf erreicht 10-20 Kb. Stellen Sie sich vor, 10-20 Kb sind Textinhalte. Und alles hängt mit allem zusammen. Mit der Zeit wird es schwierig, damit zu arbeiten. 10-20 Kb sind ein guter Anwendungsfall, es kann auch mehr sein. Und nicht immer halten die Leute das für schlecht.
Wie im herkömmlichen Programmieren, also nicht Infrastruktur als Code, sind wir es gewohnt, eine Menge verschiedener Klassen, Pakete, Module und Gruppierungen zu verwenden. Terraform ermöglicht im Grunde das Gleiche.
- Der Code wächst.
- Auch die Abhängigkeiten zwischen den Ressourcen wachsen.
Und wir haben ein großes, dringendes Bedürfnis. Wir erkennen, dass wir so nicht weiterleben können. Unser Code wird unüberschaubar. 10-20 Kb sind natürlich nicht besonders unüberschaubar, aber das sprechen wir nur über den Netzwerkstapel, d. h. Sie haben nur Netzwerkräume hinzugefügt. Wir sprechen noch nicht über den Application Load Balancer, Deployment von ES-Clustern, Kubernetes usw., woran man leicht noch 100 Kb dran hängen kann. Wenn Sie all dies schreiben, werden Sie sehr schnell feststellen, dass Terraform Terraform-Module bereitstellt.
Terraform-Module sind eine eigenständige Terraform-Konfiguration, die als Gruppe verwaltet wird. Das ist alles, was Sie über Terraform-Module wissen müssen. Sie sind nicht intelligent, sie ermöglichen Ihnen keine komplexen Verbindungen in Abhängigkeit von irgendetwas. Das liegt ganz in der Verantwortung der Entwickler. Das heißt, es ist einfach eine Terraform-Konfiguration, die Sie bereits geschrieben haben. Und man kann sie einfach als Gruppe aufrufen.
So versuchen wir zu verstehen, wie wir unseren Code von 10-20-30 Kb optimieren können. Allmählich erkennen wir, dass wir bestimmte Module verwenden müssen.
Der erste Typ von Modulen, der vorkommt, sind Ressourcenmodule. Sie verstehen nichts über Ihre Infrastruktur, Ihr Geschäft, wo und unter welchen Bedingungen sie arbeiten. Das sind genau die Module, die ich zusammen mit der Open-Source-Community verwalte und die wir als die grundlegendsten Bausteine für Ihre Infrastruktur herausstellen.
Ein Beispiel für ein Ressourcenmodul.
Wenn wir ein Ressourcenmodul aufrufen, geben wir an, von welchem Pfad wir dessen Inhalt laden müssen.
Wir geben an, welche Version wir laden möchten.
Wir übergeben dort eine Menge Argumente. Und das war's. Das ist alles, was wir wissen müssen, wenn wir dieses Modul verwenden.
Viele denken, dass die Verwendung der neuesten Version alles stabil macht. Aber das ist nicht der Fall. Die Infrastruktur muss versioniert sein; wir müssen klar beantworten, welche Version bei der Bereitstellung des jeweiligen Moduls verwendet wurde.
Hier ist der Code, der sich innerhalb dieses Moduls befindet. Modul security-group. Hier scrollt es bis zur 640. Zeile. Die Erstellung einer security-group-Ressource in Amazon in allen möglichen Konfigurationen ist eine ziemlich komplexe Aufgabe. Es reicht nicht aus, einfach eine security-group zu erstellen und zu sagen, welche Regeln ihr übergeben werden sollen. Das wäre viel zu einfach. Innerhalb von Amazon gibt es Millionen verschiedener Einschränkungen. Zum Beispiel, wenn Sie VPC-Endpunkten, Präfixlisten, verschiedenen APIs und alles zu versuchen, damit zu kombinieren, erlaubt Terraform Ihnen das nicht. Und auch die Amazon API erlaubt es nicht. Deshalb muss diese gesamte komplizierte Logik in ein Modul versteckt werden, und dem Benutzer muss ein Code präsentiert werden, der nur so aussieht.
Der Benutzer muss nicht wissen, wie es intern funktioniert.
Der zweite Modultyp besteht aus Ressourcenmodulen und löst bereits Aufgaben, die besser für Ihr Unternehmen geeignet sind. Oft handelt es sich um einen Ort, der eine Erweiterung für Terraform darstellt und bestimmte feste Werte für Tags und Unternehmensstandards festlegt. Zudem können dort Funktionen hinzugefügt werden, die derzeit nicht mit Terraform verwendet werden können. Das ist genau jetzt der Fall. Aktuell ist Version 0.11, die bald in der Vergangenheit liegen wird. Dennoch sind Preprozessoren, jsonnet, cookiecutter und viele andere Dinge die unterstützenden Mechanismen, die für eine vollständige Nutzung erforderlich sind.
Ich werde Ihnen nun einige Beispiele dafür zeigen.
Das Infrastrukturmodul wird genau auf die gleiche Weise aufgerufen.
Die Quelle, von der der Inhalt geladen werden soll, wird angegeben.
Eine Reihe von Werten wird übergeben, die in dieses Modul gehen.
Innerhalb dieses Moduls werden dann mehrere Ressourcenmodule zum Erstellen von VPC, Application Load Balancer oder zum Erstellen von Sicherheitsgruppen oder für einen Elastic Container Service-Cluster aufgerufen.
Es gibt zwei Arten von Modulen. Das ist wichtig zu verstehen, denn die meisten Informationen, die ich in diesem Vortrag zusammengefasst habe, sind nicht in der Dokumentation aufgeführt.
Die Dokumentation in Terraform ist momentan ziemlich problematisch, da sie lediglich sagt, dass es solche Funktionen gibt, die Sie verwenden können. Sie erklärt jedoch nicht, wie diese Funktionen genutzt werden sollten oder warum sie besser sind. Daher schreiben viele Leute etwas, mit dem sie später nicht leben können.
Lassen Sie uns nun ansehen, wie man diese Module schreibt. Danach schauen wir, wie man sie aufruft und wie man mit dem Code arbeitet.
Terraform Registry —
Tipp Nr. 0 – schreiben Sie keine Ressourcennutzer-Module. Die meisten dieser Module wurden bereits für Sie geschrieben. Wie ich sagte, sie sind Open Source, sie enthalten keine Ihrer Geschäftslogiken, und es sind keine fest codierten Werte für IP-Adressen, Passwörter usw. enthalten. Ein Modul ist sehr flexibel. Und es wurde höchstwahrscheinlich bereits geschrieben. Für Amazon-Ressourcen gibt es viele Module. Etwa 650. Und die meisten von ihnen sind von guter Qualität.
In diesem Beispiel kommt jemand zu Ihnen und sagt: „Ich möchte in der Lage sein, eine Datenbank zu verwalten. Erstelle ein Modul, damit ich eine Datenbank anlegen kann.“ Die Person kennt die Details der Implementierung weder von Amazon noch von Terraform. Sie sagt einfach: „Ich möchte MSSQL verwalten.“ Das heißt, wir gehen davon aus, dass sie unser Modul aufruft, den Typ des Engines übergibt und die Zeitzone angibt.
Die Person sollte nicht wissen, dass wir innerhalb dieses Moduls zwei verschiedene Ressourcen erstellen werden: eine für MSSQL und die andere für alles andere, nur weil man in Terraform 0.11 keine optionalen Zeitzonenwerte angeben kann.
Am Ende dieses Moduls wird die Person einfach die Adresse abrufen können. Sie wird nicht wissen, von welcher Datenbank oder von welcher Ressource wir das alles im Hintergrund erstellen. Dies ist ein sehr wichtiger Aspekt der Verschleierung. Und das gilt nicht nur für die Module, die öffentlich im Open Source bereitstehen, sondern auch für die Module, die Sie innerhalb Ihrer eigenen Projekte und Teams schreiben werden.
Dies ist das zweite Argument, das ziemlich wichtig ist, wenn Sie Terraform schon eine Weile verwenden. Sie haben ein Repository, in dem Sie alle Ihre Terraform-Module für Ihr Unternehmen ablegen. Es ist durchaus normal, dass dieses Projekt im Laufe der Zeit auf etwa ein bis zwei Megabyte anwächst. Das ist in Ordnung.
Das Problem liegt allerdings darin, wie Terraform diese Module aufruft. Wenn Sie beispielsweise ein Modul aufrufen, um jeden einzelnen Benutzer zu erstellen, lädt Terraform zunächst das gesamte Repository und geht dann in den Ordner, in dem dieses spezielle Modul gespeichert ist. So laden Sie jedes Mal ein Megabyte herunter. Wenn Sie 100 oder 200 Benutzer verwalten, laden Sie also 100 oder 200 Megabyte herunter, bevor Sie in diesen Ordner wechseln. Daher möchten Sie natürlich nicht jedes Mal, wenn Sie «Terraform init» drücken, eine Menge Daten herunterladen.
Es gibt zwei Lösungen für dieses Problem. Die erste besteht darin, relative Pfade zu verwenden. So geben Sie im Code an, dass der Ordner lokal ist (./). Und bevor Sie etwas ausführen, klonen Sie dieses Repository lokal mit Git. Damit machen Sie dies einmal.
Natürlich gibt es viele Nachteile. Zum Beispiel kann man kein Versioning verwenden. Damit muss man manchmal leben.
Die zweite Lösung. Wenn Sie viele Submodule haben und bereits über eine etablierte Pipeline verfügen, gibt es das Projekt MBT, das es ermöglicht, aus einem Monorepo viele verschiedene Pakete zu erstellen und diese auf S3 hochzuladen. Das ist eine sehr gute Methode. So wird die Datei iam-user-1.0.0.zip nur 1 Kb groß sein, weil der Code zur Erstellung dieses Ressourcen sehr klein ist. Und es wird viel schneller funktionieren.
Lassen Sie uns darüber sprechen, was in Modulen nicht verwendet werden kann.
Warum ist es böse, in Modulen zu arbeiten? Das Schlimmste ist das Assume User. Assume User ist eine Art der Authentifizierung beim Provider, die von verschiedenen Personen genutzt werden kann. Zum Beispiel werden wir alle eine Rolle annehmen. Das bedeutet, dass Terraform diese Rolle akzeptiert und dann mit dieser Rolle die weiteren Aktionen ausführt.
Das Problem ist, dass wenn Vasja sich auf eine Weise mit Amazon verbindet, zum Beispiel standardmäßig über Umgebungsvariablen, und Petja seinen geheimen shared key verwenden möchte, der sich an einem geheimen Ort befindet, dann kann man in Terraform nicht beides gleichzeitig angeben. Um zu verhindern, dass sie leiden, sollte dieser Block nicht im Modul angegeben werden. Das muss auf einer höheren Ebene geschehen. Das heißt, wir haben ein Ressourcenmodul, ein Infrastrukturmodul und eine darüberliegende Komposition. Und irgendwo weiter oben sollte das angegeben werden.
Das zweite Problem liegt im Provisioner. Hier ist das Problem nicht ganz trivial, denn wenn du den Code schreibst und er für dich funktioniert, könntest du denken, dass du ihn nicht ändern musst, wenn er funktioniert.
Das Problem besteht darin, dass du nicht immer kontrollierst, wann dieser Provisioner konkret ausgeführt wird, erstens. Und zweitens kontrollierst du nicht, was aws ec2 bedeutet, das heißt, wir sprechen hier über Linux oder Windows. Daher kannst du nichts schreiben, das in verschiedenen Betriebssystemen oder für unterschiedliche Anwendungsfälle gleich funktioniert.
Das am häufigsten genannte Beispiel, das auch in der offiziellen Dokumentation aufgeführt ist, ist, dass wenn Sie aws_instance schreiben und eine Menge Argumente angeben, es nichts Schlimmes daran gibt, wenn Sie dort auch den Provisioner 'local-exec' angeben und Ihr ansible-playbook ausführen.
Tatsächlich – ja, es ist nichts Schlimmes daran. Aber schon bald werden Sie erkennen, dass diese local-exec-Funktion zum Beispiel in launch_configuration nicht existiert.
Und wenn Sie launch_configuration verwenden und aus einer Instance eine Autoscaling-Gruppe erstellen möchten, gibt es in launch_configuration kein Konzept von 'Provisioner'. Dort gibt es das Konzept von 'User Data'.
Daher ist die Verwendung von User Data eine universellere Lösung. Diese wird entweder direkt auf der Instance ausgeführt, wenn die Instance gestartet wird, oder in denselben User Data, wenn die Autoscaling-Gruppe dieses launch_configuration verwendet.
Wenn Sie dennoch den Provisioner ausführen möchten, weil er ein Verbindungsstück ist, das benötigt wird, wenn eine Ressource erstellt wird und dann Ihr Provisioner, Ihr Befehl ausgeführt werden muss. Solcher Situationen gibt es viele.
Die beste Ressource dafür nennt sich null_resource. Null_resource ist eine fiktive Ressource, die in Wirklichkeit niemals erstellt wird. Sie greift auf nichts zu, es gibt keine API und kein Autoscaling. Aber sie ermöglicht es, den Zeitpunkt des Befehlsaufrufs zu steuern. In diesem Fall wird der Befehl während der Erstellung aufgerufen.
Link
Es gibt mehrere Anzeichen. Ich werde nicht auf alle Anzeichen im Detail eingehen. Es gibt einen Artikel darüber. Aber wenn Sie mit Terraform gearbeitet oder fremde Module verwendet haben, ist Ihnen wahrscheinlich aufgefallen, dass viele Module, wie auch der größte Teil des Codes im Open Source, von Leuten für ihre eigenen Bedürfnisse geschrieben werden. Eine Person hat es geschrieben, um ihr Problem zu lösen. Sie hat es auf GitHub gepostet, damit es weiterlebt. Es wird weiterleben, aber wenn es keine Dokumentation und Beispiele gibt, wird es niemand nutzen. Und wenn es keine Funktionalität bietet, die mehr als nur das spezifische Problem löst, wird es ebenfalls niemand nutzen. Es gibt sehr viele Möglichkeiten, Benutzer zu verlieren.
Wenn Sie etwas schreiben möchten, das von Menschen genutzt wird, empfehle ich, diesen Anzeichen zu folgen.
Das sind:
- Dokumentation und Beispiele.
- Vollständige Funktionalität.
- Sinnvolle Standardwerte.
- Sauberer Code.
- Tests.
Tests sind eine besondere Angelegenheit, weil sie ziemlich schwierig zu schreiben sind. Ich vertraue mehr auf Dokumentation und Beispiele.
Also, wir haben uns angeschaut, wie man Module schreibt. Es gibt zwei Argumente. Das erste, das am wichtigsten ist: Schreibe nicht, wenn du es vermeiden kannst, denn viele Menschen haben diese Aufgaben bereits vorher erledigt. Und zweitens, wenn du es doch tust, versuche, in den Modulen keine Provider und Provisioner zu verwenden.
Das ist der graue Bereich der Dokumentation. Du könntest jetzt denken: „Das ist nicht ganz klar. Nicht überzeugt.“ Aber lass uns in sechs Monaten darauf zurückblicken.
Jetzt sprechen wir darüber, wie man diese Module aufruft.
Wir verstehen, dass unser Code im Laufe der Zeit wächst. Wir haben nicht mehr nur eine Datei, sondern bereits 20 Dateien. Alle liegen in einem Ordner. Oder vielleicht in fünf Ordnern. Vielleicht beginnen wir, sie nach Regionen oder Komponenten zu sortieren. Dann merken wir, dass wir nun Ansätze für Synchronisation und Orchestrierung benötigen. Das heißt, wir müssen verstehen, was zu tun ist, wenn wir Netzwerkressourcen geändert haben, was wir mit unseren anderen Ressourcen tun sollen, wie wir diese Abhängigkeiten aufrufen usw.
Es gibt zwei Extreme. Das erste Extreme ist die All-in-One-Lösung. Wir haben eine Master-Datei. Bis vor einiger Zeit war dies die offizielle Best Practice auf der Terraform-Website.
Aber jetzt ist es als veraltet markiert und entfernt worden. Im Lauf der Zeit hat die Terraform-Community erkannt, dass dies bei weitem nicht die Best Practice ist, da Menschen das Projekt in verschiedenen Formen nutzen. Das führt zu Problemen. Zum Beispiel, wenn wir alle Abhängigkeiten an einem Ort angeben. Es gibt Situationen, in denen wir 'Terraform plan' ausführen und während Terraform den Status aller Ressourcen aktualisiert, kann eine Menge Zeit vergehen.
Eine Menge Zeit sind beispielsweise 5 Minuten. Für manche ist das eine Menge Zeit. Ich habe Fälle gesehen, in denen es 15 Minuten dauerte. 15 Minuten lang hat das AWS-API angefragt, um herauszufinden, wie es um den Status jeder Ressource steht. Das ist ein sehr großer Bereich.
Und selbstverständlich tritt ein verwandtes Problem auf, wenn Sie etwas an einer Stelle ändern möchten, dann 15 Minuten gewartet haben und Ihnen eine Vielzahl von Änderungen angezeigt wird. Sie haben aufgegeben, »Ja« geschrieben und es ging etwas schief. Das ist ein ganz reales Beispiel. Terraform versucht nicht, Sie von Problemen abzuschotten. Das heißt, schreiben Sie, was Sie wollen. Auftretende Probleme – das sind Ihre Probleme. Bisher versucht Terraform 0.11 nicht, Ihnen zu helfen. In 0.12 gibt es einige interessante Punkte, die es Ihnen ermöglichen zu sagen: „Vasya, willst du das wirklich? Denk nochmal darüber nach.“
Der zweite Weg besteht darin, diesen Bereich zu reduzieren, das heißt, man kann weniger Aufrufe von einem Ort zu einem anderen binden.
Das einzige Problem ist, dass man mehr Code schreiben muss, das heißt, man muss Variablen in vielen Dateien beschreiben und aktualisieren. Manche mögen das nicht. Für mich ist das in Ordnung. Andere denken: „Warum sollte ich das an verschiedenen Orten schreiben, ich könnte alles an einem Ort erledigen.“ Man kann es auch so machen, aber das ist die zweite Extreme.
Wo lebt das alles an einem Ort? Eine, zwei, drei Personen, das heißt, irgendjemand nutzt es.
Wer ruft konkret eine einzelnen Komponente, ein Block oder ein Infrastrukturmodul auf? Fünf bis sieben Personen. Das ist großartig.
Die häufigste Antwort ist irgendwo dazwischen. Wenn das Projekt groß ist, haben Sie häufig die Situation, dass keine der Lösungen geeignet ist und dort nicht alles funktioniert, sodass es eine Mischung gibt. Das ist nichts Schlechtes, solange Sie verstehen, dass sowohl das eine als auch das andere Vorteile haben.
Wenn sich etwas im VPC-Stack geändert hat und Sie diese Änderungen in EC2 anwenden möchten, d. h. Sie möchten die Autoscaling-Gruppe aktualisieren, weil Sie ein neues Subnetz hinzugefügt haben, nenne ich solche Abhängigkeiten Orchestrierung. Gibt es dafür Lösungen: Wer nutzt was?
Ich kann Ihnen sagen, welche Lösungen es gibt. Man kann Terraform verwenden, um Magie zu vollbringen, oder Makefiles nutzen, um Terraform zu verwenden. Und man kann überprüfen, ob sich dort etwas geändert hat, dass man es hier starten kann.
Wie finden Sie diese Lösung? Glaubt jemand, dass es eine großartige Lösung ist? Ich sehe ein Lächeln, da sind wohl Zweifel aufgekommen.
Natürlich, wiederholen Sie das nicht zu Hause. Terraform wurde nie entwickelt, um aus Terraform heraus ausgeführt zu werden.
Jemand hat mir in einem Vortrag gesagt: „Nein, das wird nicht funktionieren.“ Das Ding ist, dass es auch nicht so funktionieren sollte. Auch wenn es beeindruckend aussieht, wenn du Terraform mit Terraform startest und da noch Terraform drin ist, solltest du das nicht so machen. Terraform sollte immer ganz einfach gestartet werden.
Wenn Sie eine Orchestrierung von Aufrufen benötigen, wenn sich etwas an einem Ort geändert hat, dann gibt es Terragrunt.
Terragrunt ist ein Tool, eine Erweiterung von Terraform, das es ermöglicht, infrastrukturelle Module zu koordinieren und Aufrufe zu orchestrieren.
Eine typische Terraform-Konfigurationsdatei sieht so aus.
Sie geben an, welches spezifische Modul Sie aufrufen möchten.
Welche Abhängigkeiten das Modul hat.
Und welche Argumente dieses Modul akzeptiert. Das ist alles, was man über Terragrunt wissen muss.
Die Dokumentation ist vorhanden, 1.700 Sterne auf GitHub gibt es auch. Aber in den meisten Fällen ist das alles, was man wissen muss. Und es lässt sich sehr einfach in Unternehmen integrieren, die gerade erst mit Terraform begonnen haben.
Somit ist die Orchestrierung Terragrunt. Es gibt auch andere Optionen.
Jetzt lassen Sie uns darüber sprechen, wie man mit dem Code arbeitet.
Wenn Sie Features in den Code hinzufügen müssen, ist das in den meisten Fällen einfach. Sie erstellen eine neue Ressource, das ist sehr unkompliziert.
Wenn Sie bereits eine Ressource eingerichtet haben, beispielsweise, wenn Sie nach der Erstellung Ihres AWS-Kontos von Terraform erfahren haben und die vorhandenen Ressourcen nutzen möchten, wäre es sinnvoll, Ihr Modul so zu erweitern, dass es die Verwendung bestehender Ressourcen unterstützt.
Und die Erstellung neuer Ressourcen unter Verwendung des Resource-Blocks unterstützt.
Am Ende geben wir immer eine Output-ID zurück, abhängig davon, was verwendet wurde.
Ein weiteres sehr wesentliches Problem in Terraform 0.11 ist die Arbeit mit Listen.
Die Schwierigkeit liegt darin, dass wir eine solche Liste von Benutzern haben.
Wenn wir diese Benutzer unter Verwendung des Resource-Blocks erstellen, funktioniert alles einwandfrei. Wir gehen die gesamte Liste durch und erstellen für jeden eine Datei. Das läuft gut. Und dann, zum Beispiel, wenn Benutzer 3, der in der Mitte ist, entfernt werden soll, werden alle Ressourcen, die nach ihm erstellt wurden, neu erstellt, weil sich der Index ändern wird.
Arbeiten mit Listen in einer stateful Umgebung. Was ist eine stateful Umgebung? Das ist die Situation, in der ein neues Wert beim Erstellen dieser Ressource entsteht. Zum Beispiel, AWS Access Key oder AWS Secret Key, d. h. wenn wir einen Benutzer anlegen, erhalten wir einen neuen Access oder Secret Key. Und jedes Mal, wenn wir einen Benutzer löschen, wird dieser Benutzer einen neuen Schlüssel haben. Aber das ist nicht nach dem Feng Shui, denn der Benutzer möchte nicht mit uns befreundet sein, wenn wir jedes Mal einen neuen Benutzer für ihn erstellen, wenn jemand das Team verlässt.
Die Lösung sieht so aus. Das ist der Code, geschrieben in Jsonnet. Jsonnet ist eine Template-Sprache von Google.
Dieser Befehl ermöglicht es, dieses Template zu übernehmen, und als Ausgabe erhält man eine JSON-Datei, die nach Ihrem Template erstellt wurde.
Das Template sieht so aus.
Terraform ermöglicht die Arbeit sowohl mit HCL als auch mit Json gleichwertig, daher, wenn Sie die Möglichkeit haben, Json zu generieren, können Sie es in Terraform einfügen. Eine Datei mit der Erweiterung .tf.json wird erfolgreich geladen.
Und dann arbeiten wir damit wie gewohnt: terraform init, terraform apply. Und wir erstellen zwei Benutzer.
Jetzt haben wir keine Angst mehr, wenn jemand das Team verlässt. Wir bearbeiten einfach die JSON-Datei. Wanja Pupkin ist gegangen, Petja Pjatotschkin bleibt. Petja Pjatotschkin erhält keinen neuen Schlüssel.
Die Integration von Terraform mit anderen Tools ist im Wesentlichen keine Aufgabe von Terraform. Terraform wurde als Plattform zum Erstellen von Ressourcen entwickelt und das war's. Alles, was danach passt, ist nicht die Sorge von Terraform. Und man muss das nicht einfädeln. Es gibt Ansible, das alles erledigt, was notwendig ist.
Aber es gibt Situationen, in denen wir Terraform ergänzen und einen bestimmten Befehl aufrufen möchten, nachdem etwas ausgeführt wurde.
Erste Methode. Wir erstellen einen Output, in dem wir diesen Befehl schreiben.
Und dann rufen wir diesen Befehl aus dem Shell terraform output auf und geben den Wert an, den wir möchten. So wird der Befehl mit allen angegebenen Werten ausgeführt. Das ist sehr praktisch.
Zweite Methode. Das ist die Verwendung von null_resource in Abhängigkeit von Änderungen in unserer Infrastruktur. Wir können dasselbe local-exec aufrufen, sobald sich die ID eines bestimmten Ressourcen ändert.
Natürlich sieht das alles auf dem Papier glatt aus, denn Amazon hat wie alle anderen Public-Provider eine Menge eigener Edge Cases.
Der häufigste Edge Case besteht darin, dass es wichtig ist, welche Regionen Sie verwenden, wenn Sie ein AWS-Konto eröffnet haben; ob diese Funktion dort aktiviert ist; möglicherweise haben Sie es nach Dezember 2013 eröffnet; vielleicht verwenden Sie die Standardeinstellung in VPC usw. Es gibt viele Einschränkungen. Und Amazon hat sie in der gesamten Dokumentation verstreut.
Es gibt einige Dinge, die ich empfehle zu vermeiden.
Zunächst vermeiden Sie alle nicht geheimen Argumente innerhalb des Terraform-Plans oder der Terraform-CLI. Das alles kann entweder in eine tfvars-Datei oder in Umgebungsvariablen gepackt werden.
Aber Sie müssen sich nicht diesen ganzen magischen Befehl merken. Terraform plan – var und los geht's. Die erste Variable – var, die zweite Variable – var, die dritte, die vierte. Der wichtigste Grundsatz von Infrastructure as Code, den ich am häufigsten verwende, ist, dass ich nur einen Blick auf den Code werfen muss, um genau zu verstehen, was bereitgestellt wurde, in welchem Zustand es ist und mit welchen Werten. Deshalb muss ich nicht die Dokumentation lesen oder Wanja fragen, welche Parameter er verwendet hat, um unseren Cluster zu erstellen. Es reicht, die tfvars-Datei zu öffnen, die häufig mit der Umgebung übereinstimmt, und alles dort anzuschauen.
Sie sollten auch keine Zielargumente verwenden, um den Geltungsbereich zu verringern. Stattdessen ist es viel einfacher, kleine Infrastrukturmodule zu verwenden.
Es ist auch nicht ratsam, den Parallelismus zu begrenzen oder zu erhöhen. Wenn ich 150 Ressourcen habe und den Parallelismus von Amazon von 10 (was der Standard ist) auf 100 erhöhen möchte, wird wahrscheinlich etwas schiefgehen. Es kann jetzt gut gehen, aber wenn Amazon später sagt, dass Sie zu viele Aufrufe machen, werden Probleme auftreten.
Terraform wird versuchen, die meisten dieser Probleme neu zu starten, aber Sie werden kaum etwas erreichen. Parallelismus=1 ist eine wichtige Einstellung, die verwendet werden sollte, wenn Sie auf einen Bug innerhalb der AWS API oder im Terraform-Provider stoßen. Dann sollten Sie angeben: parallelism=1 und warten, bis Terraform einen Aufruf abgeschlossen hat, dann den zweiten, dann den dritten. Es wird sie nacheinander ausführen.
Oft werde ich gefragt: „Warum glaube ich, dass Terraform-Arbeitsbereiche schlecht sind?“. Ich glaube, dass das Prinzip von Infrastructure as Code darin besteht, zu sehen, welche Infrastruktur erstellt wurde und mit welchen Werten.
Workspaces wurde nicht von den Benutzern erstellt. Das bedeutet nicht, dass die Benutzer in GitHub-Issues geschrieben haben, dass sie ohne Terraform-Workspaces nicht leben können. Nein, so ist es nicht. Terraform Enterprise ist eine kommerzielle Lösung. HashiCorp hat beschlossen, dass wir Workspaces benötigen, also werden wir das umsetzen. Ich halte es für viel einfacher, dies in einen separaten Ordner zu legen. Das wird zwar etwas mehr Dateien bedeuten, aber es wird klarer sein.
Wie arbeitet man mit dem Code? Im Grunde ist die Arbeit mit Listen die einzige Herausforderung. Betrachten Sie Terraform einfacher. Es ist nicht das Tool, das alles für Sie großartig erledigt. Stecken Sie nicht alles hinein, was in der Dokumentation geschrieben steht.
In dem Thema des Vortrags stand "für die Zukunft". Ich werde dies sehr kurz ansprechen. Für die Zukunft – das bedeutet, dass bald Version 0.12 herauskommt.
0.12 bringt eine Menge neuer Funktionen. Wenn Sie aus der traditionellen Programmierung kommen, dann vermissen Sie verschiedene dynamische Blöcke, Schleifen, korrekte und bedingte Vergleichsoperationen, bei denen die linke und die rechte Seite nicht gleichzeitig ausgewertet werden, sondern abhängig von der Situation. Sie vermissen das sehr, und daher wird 0.12 dieses Problem für Sie lösen.
Aber! Wenn Sie weniger und einfacher schreiben, indem Sie vorgefertigte Module und Drittanbieter-Lösungen verwenden, müssen Sie nicht warten und hoffen, dass 0.12 kommt und alles für Sie repariert.
Danke für den Vortrag! Du hast über Infrastruktur als Code gesprochen und hast nur ein Wort über Tests gesagt. Sind Tests in den Modulen notwendig? Wessen Verantwortung ist das? Muss man selbst schreiben oder ist das die Verantwortung der Module?
Das nächste Jahr wird voller Vorträge darüber sein, dass wir alles testen wollen. Was wir testen müssen, ist die größte Frage. Es gibt viele Abhängigkeiten und verschiedene Einschränkungen von Anbietern. Wenn wir miteinander sprechen und du sagst: "Ich brauche Tests", frage ich: "Was wirst du testen?" Du sagst, dass du in deiner Region testen wirst. Dann sage ich, dass das in meiner Region nicht funktioniert. Das heißt, wir können uns nicht einmal darauf einigen. Ganz zu schweigen von den vielen technischen Problemen. Das heißt, wie man diese Tests schreibt, damit sie angemessen sind.
Ich beschäftige mich aktiv mit diesem Thema, d. h. wie man Tests automatisch auf der Grundlage der Infrastruktur generiert, die du geschrieben hast. Wenn du diesen Code geschrieben hast, muss ich ihn ausführen; darauf basierend kann ich Tests erstellen.
Das ist eine der am häufigsten erwähnten Bibliotheken, die es ermöglichen, Integrations-Tests für Terraform zu schreiben. Es ist eines der Hilfsprogramme. Ich bevorzuge mehr den DSL-Typ, z. B. rspec.
Anton, danke für den Vortrag! Mein Name ist Valerij. Ich erlaube mir, eine etwas philosophische Frage zu stellen. Es gibt, sozusagen, Provisioning und Deployment. Provisioning erstellt meine Infrastruktur, im Deployment fügen wir ihr nützliche Dinge hinzu, wie Server, Anwendungen usw. In meinem Kopf habe ich die Vorstellung, dass Terraform mehr für das Provisioning gedacht ist, während Ansible mehr für das Deployment geeignet ist, weil Ansible auch auf physischer Infrastruktur nginx oder Postgres installieren kann. Aber gleichzeitig scheint Ansible auch das Provisioning, zum Beispiel für Amazon- oder Google-Ressourcen, zu ermöglichen. Allerdings kann auch Terraform mit seinen Modulen eine Software bereitstellen. Siehst du, ist da eine Grenze zwischen Terraform und Ansible, wann und wo man was besser einsetzen sollte? Oder denkst du zum Beispiel, dass Ansible nun schon obsolet ist und man versuchen sollte, Terraform für alles zu verwenden?
Gute Frage, Valery. Ich denke, dass sich Terraform seit 2014 in seiner Funktionalität nicht verändert hat. Es wurde für Infrastruktur geschaffen und ist für Infrastruktur gedacht. Wir haben nach wie vor einen Bedarf an Configuration Management mit Ansible. Das Problem besteht darin, dass es im launch_configuration user data gibt. Und dort rufst du Ansible usw. auf. Das ist die Standardtrennung, die ich am meisten mag.
Wenn wir über schöne Infrastruktur sprechen, gibt es Utilities wie Packer, das dieses Image erstellt. Terraform nutzt dann data source, um dieses Image zu finden und seine launch_configuration zu aktualisieren. Das heißt, der Pipeline-Prozess besteht darin, dass wir zunächst Tracker aufrufen und dann Terraform. Und wenn ein Build stattgefunden hat, erfolgt eine neue Änderung.
Hallo! Vielen Dank für den Vortrag! Ich heiße Misha, von der Firma RBS. Ansible kann über Provisioner beim Erstellen einer Ressource aufgerufen werden. Außerdem gibt es in Ansible die Funktion des dynamischen Inventars. Man kann zuerst Terraform aufrufen und dann Ansible, das aus dem State die Ressourcen entnimmt und ausführt. Was ist besser?
Sowohl das eine als auch das andere wird von den Menschen mit gleicher Effektivität genutzt. Ich denke, dass Inventarverwaltung in Ansible nützlich ist, es sei denn, wir sprechen von einer Auto-Scaling-Gruppe. Denn in einer Auto-Scaling-Gruppe haben wir bereits unser eigenes Werkzeug, das als Launch-Konfiguration bekannt ist. In der Launch-Konfiguration notieren wir alles, was gestartet werden muss, wenn wir eine neue Ressource erstellen. Daher halte ich es für überflüssig, mit Amazon ein dynamisches Inventar zu verwenden und die Terraform ts-Datei zu lesen. Wenn Sie jedoch andere Tools verwenden, bei denen es kein Konzept von „Auto-Scaling-Gruppe“ gibt, wie zum Beispiel DigitalOcean oder einen anderen Anbieter ohne Auto-Scaling-Gruppe, dann müssen Sie die API manuell abfragen, IP-Adressen finden, eine dynamische Inventar-Datei erstellen, und Ansible wird dann damit arbeiten. Das heißt, für Amazon gibt es die Launch-Konfiguration, und für alles andere gibt es das dynamische Inventar.
Quelle: habr.com
