Viele Menschen kennen Terraform und nutzen es in ihrer täglichen Arbeit, aber Best Practices dafür wurden noch nicht entwickelt. Jedes Team muss seine eigenen Ansätze und Methoden erfinden.
Ihre Infrastruktur beginnt mit ziemlicher Sicherheit einfach: ein paar Ressourcen + ein paar Entwickler. Mit der Zeit wächst es in alle möglichen Richtungen. Finden Sie Möglichkeiten, Ressourcen in Terraform-Modulen zu gruppieren, Code in Ordnern zu organisieren und was kann sonst noch schief gehen? (berühmte 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 Änderungen in der Infrastruktur, Sie haben Angst, die Infrastruktur und den Code anzufassen – dadurch verzögern Sie neue Funktionen oder verringern die Qualität ...
Nach drei Jahren der Verwaltung einer Sammlung von Terraform-Community-Modulen für AWS auf Github und der langfristigen Wartung von Terraform in der Produktion ist Anton Babenko bereit, seine Erfahrungen zu teilen: wie man TF-Module schreibt, damit es in Zukunft nicht weh tut.
Am Ende des Vortrags werden die Teilnehmer mit den Prinzipien des Ressourcenmanagements in Terraform, Best Practices im Zusammenhang mit Modulen in Terraform und einigen Prinzipien der kontinuierlichen Integration im Zusammenhang mit dem Infrastrukturmanagement besser vertraut sein.
Haftungsausschluss: Ich stelle fest, dass dieser Bericht vom November 2018 stammt – es sind also bereits zwei Jahre vergangen. Die im Bericht besprochene Version von Terraform 2 wird nicht mehr unterstützt. In den letzten 0.11 Jahren sind 2 neue Releases erschienen, die viele Neuerungen, Verbesserungen und Änderungen enthalten. Bitte beachten Sie dies und prüfen Sie die Dokumentation.
Links:
- +
- — Code und Dokumentation zur automatischen Formatierung
- — Generator von Terraform-Modulen (WIP)
- — Terraform-Codegenerator aus visuellen Diagrammen (WIP)
- www.terraform-best-practices.com
- (Neue Beiträge finden Sie auf meiner persönlichen Website www.antonbabenko.com/)
- @antonbabenko – Twitter und eine Menge verschiedener Slacks
Mein Name ist Anton Babenko. Einige von Ihnen haben wahrscheinlich den Code verwendet, den ich geschrieben habe. Ich werde jetzt selbstbewusster als je zuvor darüber sprechen, da ich Zugriff auf Statistiken habe.
Ich arbeite an Terraform und bin seit 2015 aktiver Teilnehmer und Mitwirkender an einer Vielzahl von Open-Source-Projekten im Zusammenhang mit Terraform und Amazon.
Seitdem habe ich genug Code geschrieben, um es auf interessante Weise auszudrücken. Und ich werde versuchen, Ihnen jetzt davon zu erzählen.
Ich werde über die Feinheiten und Besonderheiten der Arbeit mit Terraform sprechen. Aber das ist eigentlich nicht das Thema von HighLoad. Und jetzt werden Sie verstehen, warum.
Mit der Zeit begann ich, Terraform-Module zu schreiben. Benutzer haben Fragen geschrieben, ich habe sie umgeschrieben. Dann habe ich verschiedene Dienstprogramme geschrieben, um den Code mithilfe eines Pre-Commit-Hooks usw. zu formatieren.
Es gab viele interessante Projekte. Ich mag die Codegenerierung, weil ich möchte, dass der Computer immer mehr Arbeit für mich und den Programmierer erledigt, deshalb arbeite ich derzeit an einem Terraform-Codegenerator aus visuellen Diagrammen. Vielleicht haben einige von Ihnen sie gesehen. Das sind wunderschöne Kisten mit Pfeilen. Und ich finde es großartig, wenn man auf die Schaltfläche „Exportieren“ klicken und alles als Code erhalten kann.
Ich bin aus der Ukraine. Ich lebe seit vielen Jahren in Norwegen.
Außerdem wurden für diesen Bericht Informationen von Personen gesammelt, die meinen Namen kennen und mich in sozialen Netzwerken finden. Ich habe fast immer den gleichen Spitznamen.
Wie bereits erwähnt, bin ich der Hauptbetreuer der Terraform AWS-Module, einem der größten Repositories auf GitHub, in dem wir Module für die häufigsten Aufgaben hosten: VPC, Autoscaling, RDS.
Und was Sie jetzt gehört haben, ist das Grundlegendste. Wenn Sie Zweifel haben, dass Sie verstehen, was Terraform ist, dann verbringen Sie Ihre Zeit besser woanders. Hier wird es viele Fachbegriffe geben. Und ich habe nicht gezögert, das Niveau des Berichts als das höchste zu bezeichnen. Das bedeutet, dass ich ohne große Erklärung mit allen möglichen Begriffen sprechen kann.
Terraform erschien 2014 als Dienstprogramm, mit dem Sie Infrastruktur als Code schreiben, planen und verwalten konnten. Das Schlüsselkonzept hier ist „Infrastruktur als Code“.
Die gesamte Dokumentation ist, wie gesagt, schriftlich . Ich hoffe, dass die meisten Leute von dieser Seite wissen und die Dokumentation gelesen haben. Wenn ja, dann sind Sie hier richtig.
So sieht eine normale Terraform-Konfigurationsdatei aus, in der wir zunächst einige Variablen definieren.
In diesem Fall definieren wir „aws_region“.
Anschließend beschreiben wir, welche Ressourcen wir erstellen möchten.
Wir führen einige Befehle aus, insbesondere „terraform init“, um Abhängigkeiten und Anbieter zu laden.
Und wir führen den Befehl „terraform apply“ aus, um zu prüfen, ob die angegebene Konfiguration mit den von uns erstellten Ressourcen übereinstimmt. Da wir noch nichts erstellt haben, fordert uns Terraform auf, diese Ressourcen zu erstellen.
Wir bestätigen dies. So erstellen wir einen Eimer namens Seasnail.
Es gibt auch mehrere ähnliche Dienstprogramme. Viele von Ihnen, die Amazon nutzen, kennen AWS CloudFormation oder Google Cloud Deployment Manager oder Azure Resource Manager. Jeder von ihnen verfügt über eine eigene Implementierung zur Verwaltung der Ressourcen innerhalb jedes dieser öffentlichen Cloud-Anbieter. Terraform ist besonders nützlich, da Sie damit über 100 Anbieter verwalten können. (Mehr Details )
Die Ziele, die Terraform von Anfang an verfolgt hat:
- Terraform bietet eine einheitliche Ansicht der Ressourcen.
- Ermöglicht die Unterstützung aller modernen Plattformen.
- Und Terraform wurde von Anfang an als Dienstprogramm konzipiert, mit dem Sie die Infrastruktur sicher und vorhersehbar ändern können.
Im Jahr 2014 klang das Wort „vorhersehbar“ in diesem Zusammenhang sehr ungewöhnlich.
Terraform ist ein universelles Dienstprogramm. Wenn Sie über eine API verfügen, können Sie absolut alles steuern:
- Sie können über 120 Anbieter nutzen, um alles zu verwalten, was Sie wollen.
- Beispielsweise können Sie Terraform verwenden, um den Zugriff auf GitHub-Repositorys zu beschreiben.
- Sie können in Jira sogar Fehler erstellen und schließen.
- Sie können New Relic-Metriken verwalten.
- Sie können sogar Dateien in Dropbox erstellen, wenn Sie es wirklich möchten.
Dies alles wird mithilfe von Terraform-Anbietern erreicht, die über eine offene API verfügen, die in Go beschrieben werden kann.
Nehmen wir an, wir haben mit der Verwendung von Terraform begonnen, die Dokumentation auf der Website gelesen, ein Video angesehen und mit dem Schreiben von main.tf begonnen, wie ich auf den vorherigen Folien gezeigt habe.
Und alles ist großartig, Sie haben eine Datei, die eine VPC erstellt.
Wenn Sie eine VPC erstellen möchten, dann geben Sie ungefähr diese 12 Zeilen an. Beschreiben Sie, in welcher Region Sie erstellen möchten und welchen cidr_block von IP-Adressen Sie verwenden möchten. Und alle.
Natürlich wird das Projekt schrittweise wachsen.
Und Sie werden dort eine Menge neuer Dinge hinzufügen: Ressourcen, Datenquellen, Sie werden neue Anbieter integrieren, plötzlich möchten Sie Terraform verwenden, um Benutzer in Ihrem GitHub-Konto zu verwalten usw. Möglicherweise möchten Sie andere verwenden DNS-Anbieter kreuzen alles. Terraform macht dies einfach.
Schauen wir uns das folgende Beispiel an.
Sie fügen internet_gateway nach und nach hinzu, da Sie möchten, dass Ressourcen Ihrer VPC über einen Internetzugang verfügen. Das ist eine gute Idee.
Das Ergebnis ist diese main.tf:
Dies ist der obere Teil von main.tf.
Dies ist der untere Teil von main.tf.
Dann fügen Sie ein Subnetz hinzu. Wenn Sie NAT-Gateways, Routen, Routing-Tabellen und eine Reihe anderer Subnetze hinzufügen möchten, verfügen Sie nicht über 38 Leitungen, sondern über etwa 200–300 Leitungen.
Das heißt, Ihre main.tf-Datei wächst allmählich. Und ziemlich oft legen die Leute alles in einer Datei ab. 10-20 KB erscheinen in main.tf. Stellen Sie sich vor, dass 10–20 KB Textinhalt sind. Und alles ist mit allem verbunden. Allmählich wird es immer schwieriger, damit zu arbeiten. 10–20 KB sind ein guter Anwendungsfall, manchmal auch mehr. Und die Leute denken nicht immer, dass das schlecht ist.
Wie bei der regulären Programmierung, also nicht bei der Infrastruktur als Code, sind wir es gewohnt, eine Reihe verschiedener Klassen, Pakete, Module und Gruppierungen zu verwenden. Mit Terraform können Sie fast das Gleiche tun.
- Der Code wächst.
- Auch die Abhängigkeiten zwischen Ressourcen nehmen zu.
Und wir haben einen großen, großen Bedarf. Wir verstehen, dass wir so nicht länger leben können. Unser Code wird immer größer. 10-20 Kb sind natürlich nicht sehr groß, aber wir reden nur über den Netzwerk-Stack, d. h. Sie haben nur Netzwerkressourcen hinzugefügt. Wir sprechen hier nicht von Application Load Balancer, Deployment-ES-Cluster, Kubernetes usw., wo problemlos 100 KB eingebunden werden können. Wenn Sie das alles aufschreiben, werden Sie sehr schnell erfahren, 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 überhaupt nicht schlau, sie erlauben es Ihnen nicht, abhängig von etwas komplexe Verbindungen herzustellen. Dies alles liegt auf den Schultern der Entwickler. Das heißt, dies ist lediglich eine Art Terraform-Konfiguration, die Sie bereits geschrieben haben. Und Sie können es einfach als Gruppe aufrufen.
Wir versuchen also zu verstehen, wie wir unseren 10-20-30 KB großen Code optimieren können. Nach und nach wird uns klar, dass wir einige Module verwenden müssen.
Der erste Modultyp, auf den Sie stoßen, sind Ressourcenmodule. Sie verstehen nicht, worum es bei Ihrer Infrastruktur geht, worum es bei Ihrem Unternehmen geht, wo und wie die Bedingungen sind. Das sind genau die Module, die ich gemeinsam mit der Open-Source-Community verwalte und die wir als allererste Bausteine für Ihre Infrastruktur vorschlagen.
Ein Beispiel für ein Ressourcenmodul.
Wenn wir ein Ressourcenmodul aufrufen, geben wir an, von welchem Pfad wir seinen Inhalt laden sollen.
Wir geben an, welche Version wir herunterladen möchten.
Wir geben dort eine Reihe von Argumenten weiter. Und alle. Das ist alles, was wir wissen müssen, wenn wir dieses Modul verwenden.
Viele Leute denken, dass alles stabil sein wird, wenn sie die neueste Version verwenden. Aber nein. Die Infrastruktur muss versioniert sein; wir müssen eindeutig beantworten, in welcher Version diese oder jene Komponente bereitgestellt wurde.
Hier ist der Code, der sich in diesem Modul befindet. Sicherheitsgruppenmodul. Hier geht die Schriftrolle bis zur 640. Zeile. Das Erstellen einer Sicherheitsgruppe-Ressource in Amazon in jeder möglichen Konfiguration ist keine triviale Aufgabe. Es reicht nicht aus, einfach eine Sicherheitsgruppe zu erstellen und ihr mitzuteilen, welche Regeln an sie übergeben werden sollen. Es wäre sehr einfach. Innerhalb von Amazon gibt es eine Million verschiedener Einschränkungen. Zum Beispiel, wenn Sie verwenden VPC-Endpunkt, Präfixliste, verschiedene APIs und versucht, dies alles mit allem anderen zu kombinieren, dann erlaubt Ihnen Terraform dies nicht. Und die Amazon API lässt dies auch nicht zu. Deshalb müssen wir all diese schreckliche Logik in einem Modul verstecken und dem Benutzer Code geben, der genau so aussieht.
Der Benutzer muss nicht wissen, wie es im Inneren hergestellt wird.
Der zweite Modultyp, der aus Ressourcenmodulen besteht, löst bereits Probleme, die besser auf Ihr Unternehmen anwendbar sind. Oft handelt es sich hierbei um eine Erweiterung für Terraform, die einige starre Werte für Tags und Unternehmensstandards festlegt. Sie können dort auch Funktionen hinzufügen, deren Nutzung Terraform Ihnen derzeit nicht erlaubt. Das ist genau jetzt. Jetzt Version 0.11, die bald der Vergangenheit angehören wird. Dennoch sind Präprozessoren, Jsonnet, Cookiecutter und viele andere Dinge Hilfsmechanismen, die für eine vollwertige Arbeit verwendet werden müssen.
Als nächstes werde ich einige Beispiele dafür zeigen.
Das Infrastrukturmodul wird genauso aufgerufen.
Die Quelle, von der der Inhalt heruntergeladen werden soll, ist angegeben.
Eine Reihe von Werten werden übergeben und an dieses Modul übergeben.
Als Nächstes werden in diesem Modul eine Reihe von Ressourcenmodulen aufgerufen, um eine VPC oder einen Application Load Balancer oder eine Sicherheitsgruppe oder einen Elastic Container Service-Cluster zu erstellen.
Es gibt zwei Arten von Modulen. Dies ist wichtig zu verstehen, da die meisten Informationen, die ich in diesem Bericht zusammengefasst habe, nicht in der Dokumentation enthalten sind.
Und die Dokumentation in Terraform ist derzeit ziemlich problematisch, weil sie nur besagt, dass es diese Funktionen gibt und man sie nutzen kann. Aber sie sagt nicht, wie man diese Funktionen nutzt und warum es besser ist, sie zu nutzen. Daher schreiben sehr viele Menschen etwas, mit dem sie nicht leben können.
Schauen wir uns als Nächstes an, wie diese Module geschrieben werden. Dann werden wir sehen, wie man sie aufruft und wie man mit dem Code arbeitet.
Terraform-Registrierung -
Tipp Nr. 0 ist, keine Ressourcenmodule zu schreiben. Die meisten dieser Module sind bereits für Sie geschrieben. Wie gesagt, sie sind Open Source, sie enthalten keine Ihrer Geschäftslogik, sie haben keine fest codierten Werte für IP-Adressen, Passwörter usw. Das Modul ist sehr flexibel. Und es wurde höchstwahrscheinlich bereits geschrieben. Es gibt viele Module für Ressourcen von Amazon. Ungefähr 650. Und die meisten davon sind von guter Qualität.
In diesem Beispiel kam jemand zu Ihnen und sagte: „Ich möchte eine Datenbank verwalten können. Erstellen Sie ein Modul, damit ich eine Datenbank erstellen kann. Die Person kennt weder die Implementierungsdetails von Amazon noch von Terraform. Er sagt einfach: „Ich möchte MSSQL verwalten.“ Das heißt, wir meinen, dass es unser Modul aufruft, dort den Engine-Typ übergibt und die Zeitzone angibt.
Und niemand sollte wissen, dass wir in diesem Modul zwei verschiedene Ressourcen erstellen werden: eine für MSSQL, die zweite für alles andere, nur weil Sie in Terraform 0.11 keine Zeitzonenwerte als optional angeben können.
Und am Ausgang dieses Moduls kann eine Person einfach eine Adresse erhalten. Er wird nicht wissen, aus welcher Datenbank, aus welcher Ressource wir das alles intern erstellen. Dies ist ein sehr wichtiges Element der Verschleierung. Und das gilt nicht nur für die Module, die in Open Source öffentlich sind, sondern auch für die Module, die Sie in Ihren Projekten und Teams schreiben.
Dies ist das zweite Argument, das sehr wichtig ist, wenn Sie Terraform schon länger verwenden. Sie verfügen über ein Repository, in dem Sie alle Ihre Terraform-Module für Ihr Unternehmen ablegen. Und es ist ganz normal, dass dieses Projekt mit der Zeit auf eine Größe von ein oder zwei Megabyte anwächst. Es ist in Ordnung.
Das Problem besteht jedoch 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 navigiert dann zu dem Ordner, in dem sich dieses spezifische Modul befindet. Auf diese Weise laden Sie jedes Mal ein Megabyte herunter. Wenn Sie 100 oder 200 Benutzer verwalten, laden Sie 100 oder 200 Megabyte herunter und wechseln dann zu diesem Ordner. Natürlich möchten Sie nicht jedes Mal, wenn Sie auf „Terraform init“ klicken, eine Menge Dinge herunterladen.
Für dieses Problem gibt es zwei Lösungen. Die erste besteht darin, relative Pfade zu verwenden. Auf diese Weise geben Sie im Code an, dass der Ordner lokal ist (./). Und bevor Sie etwas starten, erstellen Sie lokal einen Git-Klon dieses Repositorys. Auf diese Weise machen Sie es einmal.
Natürlich gibt es viele Nachteile. Sie können beispielsweise keine Versionierung verwenden. Und damit kann man manchmal nur schwer leben.
Zweite Lösung. Wenn Sie viele Submodule haben und bereits über eine Art etablierte Pipeline verfügen, dann gibt es das MBT-Projekt, mit dem Sie viele verschiedene Pakete aus einem Monorepository sammeln und in S3 hochladen können. Das ist ein sehr guter Weg. Daher wiegt die Datei iam-user-1.0.0.zip nur 1 KB, da der Code zum Erstellen dieser Ressource sehr klein ist. Und es wird viel schneller funktionieren.
Lassen Sie uns darüber sprechen, was in Modulen nicht verwendet werden kann.
Warum ist das in Modulen so schlimm? Das Schlimmste ist, vom Benutzer auszugehen. Angenommen, Benutzer ist eine Anbieterauthentifizierungsoption, die von verschiedenen Personen verwendet werden kann. Zum Beispiel werden wir alle die Rolle übernehmen. Das bedeutet, dass Terraform diese Rolle übernehmen wird. Und dann wird es mit dieser Rolle andere Aktionen ausführen.
Und das Übel ist, dass Sie nicht beides angeben können, wenn Vasya auf eine Art und Weise eine Verbindung zu Amazon herstellen möchte, beispielsweise über die Standardumgebungsvariable, und Petya gerne seinen gemeinsamen Schlüssel verwendet, den er an einem geheimen Ort hat Terraform. Und damit sie kein Leid erfahren, ist es nicht erforderlich, diese Sperre im Modul anzugeben. Dies muss auf einer höheren Ebene angegeben werden. Das heißt, wir haben ein Ressourcenmodul, ein Infrastrukturmodul und eine Komposition darüber. Und dies sollte irgendwo weiter oben angegeben werden.
Das zweite Übel ist der Versorger. Hier ist das Übel nicht so trivial, denn wenn Sie Code schreiben und er für Sie funktioniert, denken Sie vielleicht, wenn er funktioniert, warum sollten Sie ihn dann ändern?
Das Übel ist, dass Sie nicht immer kontrollieren können, wann dieser Provisioner gestartet wird. Und zweitens haben Sie keine Kontrolle darüber, was aws ec2 bedeutet, d. h. reden wir jetzt über Linux oder Windows. Sie können also nichts schreiben, das auf verschiedenen Betriebssystemen oder für verschiedene Benutzerfälle gleich funktioniert.
Das häufigste Beispiel, das auch in der offiziellen Dokumentation angegeben ist, ist, dass, wenn Sie aws_instance schreiben und eine Reihe von Argumenten angeben, nichts daran falsch ist, wenn Sie dort den Provisioner „local-exec“ angeben und Ihre Ansible-Instanz ausführen. Spielbuch.
Tatsächlich ist daran nichts auszusetzen. Aber im wahrsten Sinne des Wortes werden Sie bald feststellen, dass dieses Local-Exec-Ding beispielsweise in launch_configuration nicht existiert.
Und wenn Sie launch_configuration verwenden und eine Autoscaling-Gruppe aus einer Instanz erstellen möchten, gibt es in launch_configuration kein Konzept für „Provisioner“. Es gibt das Konzept der „Benutzerdaten“.
Daher ist die Verwendung von Benutzerdaten eine universellere Lösung. Und es wird entweder auf der Instanz selbst gestartet, wenn die Instanz eingeschaltet wird, oder in denselben Benutzerdaten, wenn die Autoscaling-Gruppe diese launch_configuration verwendet.
Wenn Sie den Provisioner dennoch ausführen möchten, da es sich um eine Klebekomponente handelt, müssen Sie beim Erstellen einer Ressource in diesem Moment Ihren Provisioner, Ihren Befehl, ausführen. Es gibt viele solcher Situationen.
Und die korrekteste Ressource dafür heißt null_resource. Null_resource ist eine Dummy-Ressource, die nie tatsächlich erstellt wird. Es berührt nichts, keine API, keine automatische Skalierung. Sie können jedoch steuern, wann der Befehl ausgeführt werden soll. In diesem Fall wird der Befehl während der Erstellung ausgeführt.
Link
Es gibt mehrere Anzeichen. Ich werde nicht im Detail auf alle Zeichen eingehen. Hierzu gibt es einen Artikel. Aber wenn Sie mit Terraform gearbeitet oder Module anderer Leute verwendet haben, dann ist Ihnen oft aufgefallen, dass viele Module, wie der Großteil des Codes in Open Source, von Leuten für ihre eigenen Bedürfnisse geschrieben werden. Ein Mann hat es geschrieben und sein Problem gelöst. Ich habe es in GitHub gesteckt und es leben lassen. Es wird leben, aber wenn es dort keine Dokumentation und Beispiele gibt, wird es niemand verwenden. Und wenn es keine Funktionalität gibt, mit der man etwas mehr als seine spezifische Aufgabe lösen kann, dann wird sie auch niemand nutzen. Es gibt so viele Möglichkeiten, Benutzer zu verlieren.
Wenn Sie etwas schreiben möchten, damit die Leute es nutzen, dann empfehle ich Ihnen, diesen Zeichen zu folgen.
Diese sind:
- Dokumentation und Beispiele.
- Volle Funktionalität.
- Angemessene Standardvorgaben.
- Sauberer Code.
- Tests.
Tests stellen eine andere Situation dar, da sie ziemlich schwierig zu schreiben sind. Ich glaube mehr an Dokumentation und Beispiele.
Also haben wir uns angeschaut, wie man Module schreibt. Es gibt zwei Argumente. Die erste und wichtigste besteht darin, nicht zu schreiben, wenn Sie können, da eine Menge Leute diese Aufgaben bereits vor Ihnen erledigt haben. Und zweitens, wenn Sie sich dennoch entscheiden, versuchen Sie, keine Anbieter in Modulen und Provisionern zu verwenden.
Dies ist der graue Teil der Dokumentation. Sie denken jetzt vielleicht: „Etwas ist unklar. Nicht überzeugt." Aber wir werden es in sechs Monaten sehen.
Lassen Sie uns nun darüber sprechen, wie diese Module aufgerufen werden.
Wir verstehen, dass unser Code mit der Zeit wächst. Wir haben nicht mehr eine Datei, wir haben bereits 20 Dateien. Sie befinden sich alle in einem Ordner. Oder vielleicht in fünf Ordnern. Vielleicht fangen wir an, sie irgendwie nach Regionen und einzelnen Komponenten aufzuschlüsseln. Dann verstehen wir, dass wir jetzt über einige Ansätze der Synchronisierung und Orchestrierung verfügen. Das heißt, wir müssen verstehen, was wir tun sollen, wenn wir Netzwerkressourcen ändern, was wir mit den restlichen Ressourcen tun sollen, wie diese Abhängigkeiten entstehen usw.
Es gibt zwei Extreme. Das erste Extrem ist alles in einem. Wir haben eine Masterdatei. Dies war vorerst die offizielle Best Practice auf der Terraform-Website.
Aber jetzt wird es als veraltet geschrieben und entfernt. Im Laufe der Zeit erkannte die Terraform-Community, dass dies alles andere als die beste Vorgehensweise war, da die Leute begannen, das Projekt auf unterschiedliche Weise zu nutzen. Und es gibt Probleme. Zum Beispiel, wenn wir alle Abhängigkeiten an einem Ort auflisten. Es gibt Situationen, in denen wir auf „Terraform-Plan“ klicken und bis Terraform den Status aller Ressourcen aktualisiert, kann viel Zeit vergehen.
Eine Menge Zeit beträgt beispielsweise 5 Minuten. Für manche ist das eine Menge Zeit. Ich habe Fälle gesehen, in denen es 15 Minuten gedauert hat. Die AWS-API verbrachte 15 Minuten damit, herauszufinden, was mit dem Status jeder Ressource geschah. Das ist ein sehr großes Gebiet.
Und natürlich tritt ein damit verbundenes Problem auf, wenn Sie an einer Stelle etwas ändern möchten, dann 15 Minuten warten und dann einen Überblick über einige Änderungen erhalten. Sie haben gespuckt, „Ja“ geschrieben und etwas ist schief gelaufen. Das ist ein sehr reales Beispiel. Terraform versucht nicht, Sie vor Problemen zu schützen. Das heißt, schreiben Sie, was Sie wollen. Es wird Probleme geben – Ihre Probleme. Während Terraform 0.11 nicht versucht, Ihnen in irgendeiner Weise zu helfen. Es gibt bestimmte interessante Stellen in 0.12, an denen man sagen kann: „Vasya, du willst das wirklich, kannst du zur Besinnung kommen?“
Die zweite Möglichkeit besteht darin, diesen Bereich zu verkleinern, d. h. Anrufe von einem Ort aus können von einem anderen Ort aus weniger verbunden sein.
Das einzige Problem besteht darin, dass Sie mehr Code schreiben müssen, d. h. Sie müssen Variablen in einer großen Anzahl von Dateien beschreiben und diese aktualisieren. Manche Leute mögen es nicht. Das ist für mich normal. Und manche Leute denken: „Warum das an verschiedenen Stellen schreiben, ich packe alles an einem Ort zusammen.“ Das ist möglich, aber das ist das zweite Extrem.
Wer hat das alles an einem Ort? Eins, zwei, drei Leute, das heißt, jemand benutzt es.
Und wer nennt eine bestimmte Komponente, einen Block oder ein Infrastrukturmodul? Fünf bis sieben Personen. Es ist toll.
Die häufigste Antwort liegt irgendwo in der Mitte. Wenn es sich um ein großes Projekt handelt, kommt es oft vor, dass keine Lösung passt und nicht alles klappt, sodass am Ende eine Mischung entsteht. Daran ist nichts auszusetzen, solange Sie verstehen, dass beides Vorteile hat.
Wenn sich in der Stack-VPC etwas geändert hat und Sie diese Änderungen auf EC2 anwenden wollten, also die Autoscaling-Gruppe aktualisieren wollten, weil Sie ein neues Subnetz hatten, dann nenne ich diese Art der Abhängigkeitsorchestrierung. Es gibt einige Lösungen: Wer nutzt was?
Ich kann vorschlagen, welche Lösungen es gibt. Sie können Terraform verwenden, um die Magie auszuführen, oder Sie können Makefiles verwenden, um Terraform zu verwenden. Und sehen Sie, ob sich dort etwas geändert hat, Sie können es hier starten.
Wie gefällt Ihnen diese Entscheidung? Glaubt irgendjemand, dass das eine coole Lösung ist? Ich sehe ein Lächeln, offenbar haben sich Zweifel eingeschlichen.
Versuchen Sie das natürlich nicht zu Hause. Terraform wurde nie für die Ausführung in Terraform konzipiert.
Bei einem Bericht sagten sie mir: „Nein, das wird nicht funktionieren.“ Der Punkt ist, dass es nicht funktionieren sollte. Obwohl es so beeindruckend aussieht, wenn Sie Terraform über Terraform und dann Terraform starten können, sollten Sie das nicht tun. Terraform sollte immer sehr einfach starten.
Wenn Sie eine Anruforchestrierung benötigen, wenn sich an einer Stelle etwas geändert hat, dann gibt es Terragrunt.
Terragrunt ist ein Dienstprogramm, ein Add-on zu Terraform, mit dem Sie Aufrufe von Infrastrukturmodulen koordinieren und orchestrieren können.
Eine typische Terraform-Konfigurationsdatei sieht so aus.
Sie geben an, welches konkrete Modul Sie aufrufen möchten.
Welche Abhängigkeiten hat das Modul?
Und welche Argumente akzeptiert dieses Modul. Das ist alles, was Sie über Terragrunt wissen müssen.
Die Dokumentation ist vorhanden und auf GitHub gibt es 1 Sterne. Aber in den meisten Fällen ist es das, was Sie wissen müssen. Und das ist in Unternehmen, die gerade erst anfangen, mit Terraform zu arbeiten, sehr einfach umzusetzen.
Orchestrierung ist also Terragrunt. Es gibt andere Möglichkeiten.
Lassen Sie uns nun darüber sprechen, wie Sie mit dem Code arbeiten.
Wenn Sie Ihrem Code neue Funktionen hinzufügen müssen, ist dies in den meisten Fällen einfach. Sie schreiben eine neue Ressource, alles ist einfach.
Wenn Sie über eine Ressource verfügen, die Sie im Voraus erstellt haben, beispielsweise nachdem Sie ein AWS-Konto eröffnet haben und von Terraform erfahren haben, und die bereits vorhandenen Ressourcen nutzen möchten, wäre es angebracht, Ihr Modul auf diese Weise zu erweitern es unterstützt die Nutzung vorhandener Ressourcen.
Und unterstützte die Erstellung neuer Ressourcen mithilfe der Blockressource.
Bei der Ausgabe geben wir immer die Ausgabe-ID zurück, je nachdem, was verwendet wurde.
Das zweite sehr große Problem in Terraform 0.11 ist die Arbeit mit Listen.
Die Schwierigkeit besteht darin, dass wir eine solche Benutzerliste haben.
Und wenn wir diese Benutzer mithilfe von Blockressourcen erstellen, läuft alles gut. Wir gehen die gesamte Liste durch und erstellen für jede eine Datei. Alles ist gut. Und dann sollte zum Beispiel Benutzer3, der sich in der Mitte befindet, von hier entfernt werden, dann werden alle Ressourcen, die nach ihm erstellt wurden, neu erstellt, da sich der Index ändert.
Arbeiten mit Listen in einer zustandsbehafteten Umgebung. Was ist eine zustandsbehaftete Umgebung? Dies ist die Situation, in der beim Erstellen dieser Ressource ein neuer Wert erstellt wird. Zum Beispiel AWS Access Key oder AWS Secret Key, d. h. wenn wir einen Benutzer erstellen, erhalten wir einen neuen Access oder Secret Key. Und jedes Mal, wenn wir einen Benutzer löschen, erhält dieser Benutzer einen neuen Schlüssel. Dies ist jedoch kein Feng Shui, da der Benutzer nicht mit uns befreundet sein möchte, wenn wir jedes Mal, wenn jemand das Team verlässt, einen neuen Benutzer für ihn erstellen.
Das ist die Lösung. Dies ist in Jsonnet geschriebener Code. Jsonnet ist eine Vorlagensprache von Google.
Mit diesem Befehl können Sie diese Vorlage akzeptieren und als Ausgabe eine JSON-Datei zurückgeben, die gemäß Ihrer Vorlage erstellt wurde.
Die Vorlage sieht so aus.
Mit Terraform können Sie auf die gleiche Weise mit HCL und Json arbeiten. Wenn Sie also die Möglichkeit haben, Json zu generieren, können Sie es in Terraform einfügen. Die Datei mit der Erweiterung .tf.json wird erfolgreich heruntergeladen.
Und dann arbeiten wir wie gewohnt damit: Terraform init, Terramorm Apply. Und wir erstellen zwei Benutzer.
Jetzt haben wir keine Angst mehr, wenn jemand das Team verlässt. Wir bearbeiten einfach die JSON-Datei. Wasja Pupkin ging, Petja Pjatotschkin blieb. Petja Pjatotschkin wird keinen neuen Schlüssel erhalten.
Die Integration von Terraform mit anderen Tools ist nicht wirklich die Aufgabe von Terraform. Terraform wurde als Plattform zum Erstellen von Ressourcen erstellt und das war's. Und alles, was später auftaucht, geht Terraform nichts an. Und es besteht keine Notwendigkeit, es dort einzuweben. Es gibt Ansible, das alles kann, was Sie brauchen.
Es treten jedoch Situationen auf, in denen wir Terraform erweitern und einen Befehl aufrufen möchten, nachdem etwas abgeschlossen ist.
Erster Weg. Wir erstellen eine Ausgabe, in der wir diesen Befehl schreiben.
Und dann rufen wir diesen Befehl über die Shell-Terraform-Ausgabe auf und geben den gewünschten Wert an. Somit wird der Befehl mit allen ersetzten Werten ausgeführt. Es ist sehr bequem.
Zweiter Weg. Dies ist die Verwendung von null_resource abhängig von Änderungen in unserer Infrastruktur. Wir können dieselbe lokale Exe aufrufen, sobald sich die ID einer Ressource ändert.
Auf dem Papier ist das natürlich alles glatt, denn Amazon hat, wie alle anderen öffentlichen Anbieter auch, eine Reihe eigener Grenzfälle.
Der häufigste Grenzfall ist, dass es beim Öffnen eines AWS-Kontos darauf ankommt, welche Regionen Sie verwenden; ist diese Funktion dort aktiviert? vielleicht haben Sie es nach Dezember 2013 eröffnet; Möglicherweise verwenden Sie die Standardeinstellung in VPC usw. Es gibt viele Einschränkungen. Und Amazon hat sie in der gesamten Dokumentation verteilt.
Es gibt ein paar Dinge, die ich zu vermeiden empfehle.
Vermeiden Sie zunächst alle nicht geheimen Argumente im Terraform-Plan oder in der Terraform-CLI. All dies kann entweder in eine tfvars-Datei oder in eine Umgebungsvariable eingefügt werden.
Aber Sie müssen sich nicht diesen ganzen magischen Befehl merken. Terraform-Plan – var und los geht’s. Die erste Variable ist var, die zweite Variable ist var, die dritte die vierte. Das wichtigste Prinzip von Infrastructure as Code, das ich am häufigsten verwende, ist, dass ich allein durch die Betrachtung des Codes ein klares Verständnis davon haben sollte, was dort in welchem Zustand und mit welchen Werten bereitgestellt wird. Und so muss ich nicht die Dokumentation lesen oder Vasya fragen, welche Parameter er zur Erstellung unseres Clusters verwendet hat. Ich muss nur eine Datei mit der Erweiterung tfvars öffnen, die oft zur Umgebung passt, und mir dort alles ansehen.
Verwenden Sie außerdem keine Zielargumente, um den Umfang zu reduzieren. Hierfür ist es viel einfacher, kleine Infrastrukturmodule zu verwenden.
Außerdem besteht keine Notwendigkeit, die Parallelität einzuschränken und zu erhöhen. Wenn ich 150 Ressourcen habe und die Amazon-Parallelität von den standardmäßigen 10 auf 100 erhöhen möchte, wird höchstwahrscheinlich etwas schief gehen. Oder es könnte jetzt gut laufen, aber wenn Amazon sagt, dass Sie zu viele Anrufe tätigen, geraten Sie in Schwierigkeiten.
Terraform wird versuchen, die meisten dieser Probleme neu zu beheben, aber Sie werden fast nichts erreichen. Parallelism=1 ist eine wichtige Funktion, wenn Sie auf einen Fehler in der AWS-API oder im Terraform-Anbieter stoßen. Und dann müssen Sie Folgendes angeben: parallelism=1 und warten, bis Terraform einen Aufruf beendet, dann den zweiten und dann den dritten. Er wird sie einzeln starten.
Ich werde oft gefragt: „Warum halte ich Terraform-Arbeitsbereiche für böse?“ Ich glaube, dass das Prinzip von Infrastructure as Code darin besteht, zu sehen, welche Infrastruktur mit welchen Werten geschaffen wurde.
Arbeitsbereiche wurden nicht von Benutzern erstellt. Dies bedeutet nicht, dass Benutzer in GitHub-Ausgaben geschrieben haben, dass wir ohne Terraform-Arbeitsbereiche nicht leben können. Nein, nicht so. Terraform Enterprise ist eine kommerzielle Lösung. Terraform von HashiCorp entschied, dass wir Arbeitsbereiche brauchten, also haben wir es abgelegt. Ich finde es viel einfacher, es in einem separaten Ordner abzulegen. Dann wird es etwas mehr Dateien geben, aber es wird klarer.
Wie arbeite ich mit dem Code? Tatsächlich ist die Arbeit mit Listen das einzige Problem. Und nehmen Sie Terraform einfacher. Dies ist nicht das, was alles für Sie großartig machen wird. Es ist nicht nötig, alles, was in der Dokumentation steht, dorthin zu schieben.
Das Thema des Berichts war „für die Zukunft“ geschrieben. Ich werde ganz kurz darüber sprechen. Für die Zukunft bedeutet dies, dass 0.12 bald veröffentlicht wird.
0.12 ist eine Menge neuer Sachen. Wenn Sie aus der regulären Programmierung kommen, dann vermissen Sie allerlei dynamische Blöcke, Schleifen, korrekte und bedingte Vergleichsoperationen, bei denen die linke und rechte Seite nicht gleichzeitig, sondern situationsabhängig berechnet werden. Sie vermissen es sehr, also wird 0.12 es für Sie lösen.
Aber! Wenn Sie weniger und einfacher schreiben und vorgefertigte Module und Lösungen von Drittanbietern verwenden, müssen Sie nicht warten und hoffen, dass 0.12 kommt und alles für Sie repariert.
Danke für den Bericht! Sie haben über Infrastruktur als Code gesprochen und im wahrsten Sinne des Wortes ein Wort über Tests gesagt. Sind Tests in Modulen erforderlich? Wessen Verantwortung liegt hier? Muss ich es selbst schreiben oder liegt es in der Verantwortung der Module?
Das nächste Jahr wird voller Berichte sein, dass wir beschlossen haben, alles zu testen. Was getestet werden soll, ist die größte Frage. Es gibt viele Abhängigkeiten, viele Einschränkungen von verschiedenen Anbietern. Wenn Sie und ich uns unterhalten und Sie sagen: „Ich brauche Tests“, dann frage ich: „Was werden Sie testen?“ Sie sagen, dass Sie in Ihrer Region testen werden. Dann sage ich, dass das in meiner Region nicht funktioniert. Das heißt, wir werden uns nicht einmal darauf einigen können. Ganz zu schweigen davon, dass es viele technische Probleme gibt. Das heißt, wie man diese Tests so schreibt, dass sie angemessen sind.
Ich recherchiere aktiv zu diesem Thema, d. h. wie man automatisch Tests basierend auf der von Ihnen geschriebenen Infrastruktur generiert. Das heißt, wenn Sie diesen Code geschrieben haben, muss ich ihn ausführen. Auf dieser Grundlage kann ich Tests erstellen.
ist eine der am häufigsten genannten Bibliotheken, mit der Sie Integrationstests für Terraform schreiben können. Dies ist eines der Dienstprogramme. Ich bevorzuge den DSL-Typ, zum Beispiel rspec.
Anton, danke für den Bericht! Mein Name ist Valery. Lassen Sie mich eine kleine philosophische Frage stellen. Es gibt bedingt eine Bereitstellung, es gibt eine Bereitstellung. Durch die Bereitstellung wird meine Infrastruktur erstellt. Bei der Bereitstellung füllen wir sie mit etwas Nützlichem, zum Beispiel Servern, Anwendungen usw. Und in meinem Kopf ist Terraform eher für die Bereitstellung und Ansible eher für die Bereitstellung gedacht, da Ansible auch für die physische Infrastruktur gedacht ist ermöglicht die Installation von Nginx und Postgres. Aber gleichzeitig scheint Ansible die Bereitstellung beispielsweise von Amazon- oder Google-Ressourcen zu ermöglichen. Aber Terraform ermöglicht Ihnen auch die Bereitstellung einiger Software mithilfe seiner Module. Gibt es aus Ihrer Sicht eine Art Grenze, die zwischen Terraform und Ansible verläuft, wo und was ist besser zu verwenden? Oder denken Sie beispielsweise, dass Ansible bereits Müll ist und Sie versuchen sollten, Terraform für alles zu verwenden?
Gute Frage, Valery. Ich glaube, dass sich der Zweck von Terraform seit 2014 nicht verändert hat. Es wurde für die Infrastruktur geschaffen und ist für die Infrastruktur gestorben. Wir hatten und werden weiterhin Bedarf an Ansible-Konfigurationsmanagement haben. Die Herausforderung besteht darin, dass in launch_configuration Benutzerdaten vorhanden sind. Und da ziehen Sie Ansible usw. Das ist die Standardunterscheidung, die mir am besten gefällt.
Wenn es um eine schöne Infrastruktur geht, dann gibt es Dienstprogramme wie Packer, die dieses Bild sammeln. Und dann verwendet Terraform die Datenquelle, um dieses Bild zu finden und seine Startkonfiguration zu aktualisieren. Das heißt, die Pipeline besteht auf diese Weise darin, dass wir zuerst Tracker und dann Terraform abrufen. Und wenn ein Build stattfindet, erfolgt eine neue Änderung.
Guten Tag! Danke für den Bericht! Mein Name ist Misha, RBS-Unternehmen. Sie können Ansible beim Erstellen einer Ressource über den Provisioner aufrufen. Ansible hat auch ein Thema namens dynamisches Inventar. Und Sie können zuerst Terraform und dann Ansible aufrufen, wodurch Ressourcen aus dem Status entnommen und ausgeführt werden. Was ist besser?
Die Leute nutzen beide mit gleichem Erfolg. Mir scheint, dass dynamisches Inventar in Ansible eine praktische Sache ist, wenn es nicht um Autoscaling-Gruppen geht. Denn in der Autoscaling-Gruppe haben wir bereits ein eigenes Toolkit, das launch_configuration heißt. In launch_configuration erfassen wir alles, was gestartet werden muss, wenn wir eine neue Ressource erstellen. Daher ist es meiner Meinung nach bei Amazon übertrieben, dynamisches Inventar zu verwenden und die Terraform-TS-Datei zu lesen. Und wenn Sie andere Tools verwenden, bei denen es kein Konzept einer „Autoscaling-Gruppe“ gibt, beispielsweise DigitalOcean oder einen anderen Anbieter, bei dem es keine Autoscaling-Gruppe gibt, müssen Sie dort die API manuell abrufen, IP-Adressen suchen und erstellen eine dynamische Inventardatei, und Ansible wird sie bereits durchgehen. Das heißt, für Amazon gibt es launch_configuration und für alles andere gibt es dynamisches Inventar.
Source: habr.com