Es scheint, dass die Entwickler von Terraform ausreichend nützliche Best Practices für die Arbeit mit AWS-Infrastrukturen anbieten. Aber es gibt einen Haken. Im Laufe der Zeit vermehrt sich die Anzahl der Umgebungen, wobei jede ihre eigenen Besonderheiten aufweist. Es entsteht fast eine Kopie des Anwendungsstacks in einer benachbarten Region. Und der Terraform-Code muss sorgfältig kopiert und an die neuen Anforderungen angepasst oder als Schneeflocke erstellt werden.
Meine Präsentation über Muster in Terraform zur Bekämpfung von Chaos und manueller Routine in großen, langfristigen Projekten.
Video:
Ich bin 40 Jahre alt und seit 20 Jahren im IT-Bereich tätig. Seit 12 Jahren arbeite ich bei Ixtens. Wir beschäftigen uns mit ecommerce-driven Development. Und seit 5 Jahren praktiziere ich DevOps-Praktiken.
Mein Bericht wird über die Erfahrungen in einem Projekt eines Unternehmens handeln, dessen Name ich aus Gründen der Geheimhaltung nicht nennen werde.
Die Zahlen auf der Folie dienen dazu, den Umfang des Projekts zu verdeutlichen. Und alles, was ich anschließend sagen werde, bezieht sich auf Amazon.
Ich bin vor 4 Jahren zu diesem Projekt gestoßen. Zu diesem Zeitpunkt habe ich die Infrastruktur umgestaltet, weil das Projekt gewachsen ist. Die bisherigen Muster waren nicht mehr passend. Angesichts des geplanten Wachstums des Projekts musste etwas Neues her.
Danke an Matwei, der mir gestern erzählt hat, was bei Dodo Pizza passiert ist. Das ist etwas, das bei uns vor 4 Jahren geschehen ist.
Die Entwickler kamen und begannen, infrastrukturellen Code zu erstellen.
Die offensichtlichsten Gründe, warum dies erforderlich war, waren der Time-to-Market. Es musste sichergestellt werden, dass das DevOps-Team kein Engpass beim Rollout war. Außerdem wurden auf der ersten Ebene Terraform und Puppet verwendet.
Terraform ist ein Open-Source-Projekt von HashiCorp. Für diejenigen, die damit nicht vertraut sind, folgen hier die nächsten Folien.
Infrastruktur als Code bedeutet, dass wir unsere Infrastruktur beschreiben und Roboter anweisen können, die Ressourcen bereitzustellen, die wir beschrieben haben.
Zum Beispiel benötigen wir virtuelle Maschine. Wir werden es beschreiben und ein paar erforderliche Parameter hinzufügen.
Danach richten wir in der Konsole den Zugang zu Amazon ein und fordern Terraform plan an. Terraform plan wird sagen: „Okay, für Ihre Ressource können wir die folgenden Dinge tun.“ Und mindestens eine Ressource wird hinzugefügt. Änderungen sind nicht zu erwarten.
Sobald Sie zufrieden sind, können Sie Terraform apply anfordern, und Terraform wird Ihnen eine Instanz erstellen, sodass Sie eine virtuelle Maschine in Ihrer Cloud erhalten.
Unser Projekt entwickelt sich weiter. Wir fügen einige Änderungen hinzu. Wir bitten um zusätzliche Instanzen und fügen einen A-Record hinzu.
Und wir wiederholen den Vorgang. Wir fordern den Plan an und sehen, welche Änderungen vorgesehen sind. Wir wenden sie an und somit wächst unsere Infrastruktur.
Terraform verwendet sogenannte State-Dateien. Das heißt, alle Änderungen, die an Amazon gesendet werden, werden in einer Datei gespeichert, in der für jede Ressource, die Sie beschrieben haben, die entsprechenden Ressourcen aufgeführt sind, die in Amazon erstellt wurden. So weiß Terraform genau, was in Amazon geändert werden muss, wenn die Beschreibung einer Ressource geändert wird.
Diese State-Dateien waren ursprünglich einfache Dateien. Wir haben sie in Git gespeichert, was äußerst unpraktisch war. Jemand hat ständig vergessen, die Änderungen zu committen, was zu vielen Konflikten führte.
Jetzt haben Sie die Möglichkeit, das Backend zu nutzen, d. h. Terraform gibt an, in welchem Bucket und unter welchem Schlüssel die State-Datei gespeichert werden soll. Terraform kümmert sich dann selbst darum, die State-Datei abzurufen, alle notwendigen Vorgänge durchzuführen und das finale Ergebnis zurückzulegen.
Unsere Infrastruktur wächst. Hier ist unser Code. Und wir wollen nicht einfach nur eine virtuelle Maschine erstellen, wir benötigen jetzt eine Testumgebung.
Mit Terraform können Sie ein Modul erstellen, d. h. das Gleiche in einem bestimmten Ordner beschreiben.
Sie können dieses Modul zum Testen aufrufen und erhalten das gleiche Ergebnis, als hätten wir Terraform apply im Modul selbst ausgeführt. Für die Tests wird dieser Code verwendet.
Für die Produktion können wir Änderungen vornehmen, denn in der Testumgebung benötigen wir keine großen Instanzen, aber in der Produktion sind diese großen Instanzen sehr nützlich.
Ich werde also zurück zum Projekt kommen. Es war eine anspruchsvolle Aufgabe, die Infrastruktur wurde als sehr umfangreich geplant. Der gesamte Code musste so strukturiert werden, dass er für alle benutzerfreundlich war: sowohl für diejenigen, die Wartungsarbeiten an dem Code durchführen, als auch für die, die Änderungen vornehmen. Es war vorgesehen, dass jeder Entwickler die Infrastruktur anpassen kann, um sie für seinen Teil der Plattform so zu gestalten, wie es benötigt wird.
Dies ist die von HashiCorp empfohlene Verzeichnisstruktur, wenn Sie ein großes Projekt haben und es sinnvoll ist, die gesamte Infrastruktur in kleinere Teile zu gliedern und jeden Teil in einem eigenen Ordner zu beschreiben.
Mit einer umfangreichen Bibliothek von Ressourcen ist es möglich, in der Test- und Produktionsumgebung nahezu dasselbe zu verwenden.
In unserem Fall war das nicht ganz passend, da der Test-Stack für Entwickler oder Tests einfacher bereitgestellt werden musste. Es war unpraktisch, durch verschiedene Ordner zu navigieren und diese in der richtigen Reihenfolge anzuwenden, und sich Sorgen zu machen, dass zuerst die Datenbank gestartet wird und dann die Instanz, die diese Datenbank nutzt. Daher wurde das gesamte Testen aus einem einzigen Ordner heraus initiiert. Dort wurden dieselben Module aufgerufen, aber alles lief in einem Durchgang ab.
Terraform kümmert sich um alle Abhängigkeiten und erstellt stets Ressourcen in der Reihenfolge, die es ermöglicht, beispielsweise eine IP-Adresse von einer neu erstellten Instanz zu erhalten und diese IP-Adresse in einen Route53-Eintrag zu integrieren.
Darüber hinaus ist die Plattform sehr umfangreich. Der Start eines Test-Stacks, selbst für eine Stunde oder acht Stunden, ist eine kostspielige Angelegenheit.
Wir haben dies automatisiert. Der Jenkins-Job ermöglichte das Starten des Stacks. Dabei musste ein Pull-Request mit den Änderungen eingereicht werden, die der Entwickler testen wollte, sowie alle benötigten Optionen, Komponenten und Größen angeben. Wenn er Leistungstests durchführen wollte, konnte er mehrere Instanzen wählen. Wenn er nur überprüfen wollte, dass eine bestimmte Maske geöffnet wird, konnte er mit minimalen Einstellungen starten. Außerdem konnte er angeben, ob ein Cluster benötigt wird oder nicht, usw.
Anschließend führte Jenkins ein Shell-Skript aus, das den Code im Terraform-Verzeichnis leicht modifizierte: es entfernte überflüssige Dateien und fügte die benötigten Dateien hinzu. Danach wurde mit einem einzigen Durchgang 'Terraform apply' der Stack erstellt.
Die weiteren Schritte möchte ich jedoch nicht vertiefen.
Da wir für die Tests etwas mehr Optionen benötigten als in der Produktionsumgebung, mussten wir Kopien der Module erstellen, um in diesen Kopien die Funktionen hinzuzufügen, die nur für Tests erforderlich sind.
So kam es, dass wir im Test die Änderungen, die letztlich in die Produktion gehen sollten, zu testen versuchten. In der Realität wurde jedoch etwas anderes getestet, und in der Produktion wurden geringfügig andere Änderungen angewendet. Das führte zu einer kleinen Diskrepanz, da alle Änderungen in der Produktionsumgebung vom Operationsteam umgesetzt wurden. Manchmal geschah es, dass die Änderungen, die aus dem Test in die Produktion übergehen sollten, in einer anderen Version verblieben.
Darüber hinaus gab es das Problem, dass ein neuer Dienst hinzugefügt wurde, der sich etwas von einem bereits bestehenden unterschied. Statt das bestehende Modul zu modifizieren, war es notwendig, eine Kopie zu erstellen und die erforderlichen Änderungen hinzuzufügen.
Im Grunde genommen ist Terraform keine echte Sprache. Es ist eine Deklaration. Wenn wir etwas deklarieren müssen, dann tun wir das. Und alles funktioniert.
Irgendwann, als einer meiner Pull Requests besprochen wurde, sagte ein Kollege, dass man keine Schneeflocken produzieren solle. Das hat mich neugierig gemacht, was er damit meint. Es gibt die wissenschaftliche Tatsache, dass es auf der Welt keine zwei identischen Schneeflocken gibt; sie unterscheiden sich immer ein wenig. Sobald ich das hörte, wurde mir die gesamte Komplexität des Terraform-Codes bewusst. Denn wenn man von einer Version zur nächsten wechseln wollte, verlangte Terraform ein breaking change, was bedeutete, dass der Code nicht mehr mit der nächsten Version kompatibel war. Das brachte uns dazu, einen Pull Request zu erstellen, der fast die Hälfte der Dateien in der Infrastruktur betraf, um die Infrastruktur auf die nächste Version von Terraform zu bringen.
Und nachdem so eine Schneeflocke aufgetaucht war, verwandelte sich unser gesamter Terraform-Code in einen riesigen Haufen Schnee.
Für einen externen Entwickler, der nicht im Betrieb ist, hat das keine große Bedeutung, denn er hat einen Pull Request erstellt, seine Ressource wurde gestartet, und das war's, damit hat er nichts mehr zu tun. Aber das DevOps-Team, das dafür sorgt, dass alles in Ordnung ist, muss all diese Änderungen vornehmen. Und die Kosten für diese Änderungen stiegen mit jeder zusätzlichen Schneeflocke enorm.
Es gibt eine Geschichte über einen Studenten, der während eines Seminars mit Kreide zwei perfekte Kreise an die Tafel zeichnet. Der Dozent ist erstaunt, wie es ihm gelungen ist, so gleichmäßig ohne Zirkel zu zeichnen. Der Student antwortet: „Das ist ganz einfach, ich habe zwei Jahre lang in der Armee eine Fleischerei gedreht.“
Von den vier Jahren, in denen ich an diesem Projekt beteiligt bin, arbeite ich etwa zwei Jahre mit Terraform. Natürlich habe ich einige Tricks und Tipps, wie man Terraform-Code vereinfachen kann, ihn wie eine Programmiersprache behandelt und die Last für die Entwickler reduziert, die diesen Code aktuell halten müssen.
Das erste, womit ich beginnen möchte, sind Symlinks. Terraform hat viel sich wiederholenden Code. Zum Beispiel wird der Provider an fast jedem Punkt, an dem wir einen Teil der Infrastruktur erstellen, gleich aufgerufen. Daher ist es logisch, ihn in einen separaten Ordner auszulagern. An allen Stellen, wo der Provider benötigt wird, sollten Symlinks auf diese Datei erstellt werden.
Zum Beispiel verwenden Sie in Ihrer Produktionsumgebung eine Assume Role, die Ihnen Zugriff auf ein externes Amazon-Konto ermöglicht. Durch das Ändern einer Datei erhalten alle anderen Dateien im Ressourcenbaum die erforderlichen Berechtigungen, damit Terraform weiß, auf welches Amazon-Segment es zugreifen soll.
Wo funktionieren Symlinks nicht? Wie bereits erwähnt, enthält Terraform State-Dateien. Und diese sind wirklich sehr nützlich. Das Problem ist, dass Terraform den Backend im allerersten Schritt initialisiert. Dabei kann es in diesen Parametern keine Variablen verwenden, sie müssen immer als Text angegeben werden.
Infolgedessen kopiert jemand, der eine neue Ressource erstellt, Teile des Codes aus anderen Verzeichnissen. Dabei kann es zu einem Fehler kommen, was den Schlüssel oder den Bucket betrifft. Zum Beispiel, wenn er eine Sandbox-Ressource zur Sandbox kopiert und dann in der Produktion verwendet. So könnte es passieren, dass der Bucket in der Produktion aus der Sandbox genutzt wird. Natürlich würde das schnell auffallen. Man könnte es irgendwie beheben, aber dennoch ist das Zeit- und in gewisser Weise Ressourcenverlust.
Was können wir als Nächstes tun? Bevor Sie mit Terraform arbeiten, müssen Sie es initialisieren. Während der Initialisierung lädt Terraform alle Plugins herunter. Diese haben sich irgendwann von einem Monolithen zu einer mikroservicebasierten Architektur entwickelt. Daher ist es immer notwendig, Terraform init auszuführen, damit alle Module und Plugins geladen werden.
Sie können ein Shell-Skript verwenden, das erstens alle Variablen abrufen kann. Ein Shell-Skript ist in seiner Funktionalität nicht eingeschränkt. Zweitens können Sie die Pfade angeben. Wenn wir immer den gleichen Pfad verwenden, der im Repository als Schlüssel zur Statusdatei dient, wird ein Fehler hier ausgeschlossen.
Woher kommen die Daten? Aus einer JSON-Datei. Terraform ermöglicht es, Infrastruktur nicht nur in HCL (HashiCorp Configuration Language), sondern auch in JSON zu speichern.
JSON lässt sich leicht aus einem Shell-Skript lesen. Somit können Sie eine Konfigurationsdatei mit einem Bucket an einem Ort ablegen. Dieser Bucket kann sowohl im Terraform-Code als auch im Shell-Skript zur Initialisierung verwendet werden.
Warum ist es wichtig, einen Bucket für Terraform zu haben? Weil es so etwas wie Remote-Statusdateien gibt. Das heißt, wenn ich eine Ressource starte, muss ich Amazon viele erforderliche Parameter angeben, um zu sagen: "Bitte starten Sie das Instance."
Diese Identifikatoren werden in einem anderen Ordner gespeichert. Ich kann sagen: „Terraform, bitte gehe zum State-File dieses Ressourcen und hole mir diese Identifikatoren.“ So entsteht eine gewisse Vereinheitlichung zwischen verschiedenen Regionen oder Umgebungen.
Es ist nicht immer möglich, eine entfernte State-Datei zu verwenden. Zum Beispiel, wenn Sie manuell ein VPC erstellt haben. Der Terraform-Code, der das VPC erstellt, erzeugt ein so unähnliches VPC, dass Sie viel Zeit damit verbringen müssen, um es anzupassen. Daher kann man den folgenden Ansatz verwenden.
Das heißt, Sie erstellen ein Modul, das gewissermaßen ein VPC erstellt und Ihnen die Identifikatoren zur Verfügung stellt, tatsächlich gibt es jedoch eine Datei mit fest kodierten Werten, die zur Erstellung desselben Instances verwendet werden kann.
Es ist nicht immer notwendig, die State-Datei in der Cloud zu speichern. Wenn zum Beispiel Module getestet werden, kann man die Backend-Initialisierung verwenden, bei der die Datei einfach während des Testens auf der Festplatte gespeichert wird.
Jetzt ein bisschen über das Testen. Was kann man in Terraform testen? Wahrscheinlich vieles, aber ich werde über diese 4 Punkte sprechen.
HashiCorp hat ein klares Verständnis davon, wie Terraform-Code formatiert werden sollte. Mit Terraform fmt können Sie den Code, den Sie bearbeiten, gemäß dieser Auffassung formatieren. Daher sollten die Tests sicherstellen, dass die Formatierung den Vorgaben von HashiCorp entspricht, um Änderungen an der Position von Klammern usw. zu vermeiden.
Der nächste Schritt ist Terraform validate. Dieser erledigt etwas mehr als nur eine Syntaxprüfung – etwa, ob alle Klammern paarig sind. Was hier wichtig ist? Unsere Infrastruktur ist sehr komplex. Sie umfasst viele verschiedene Ordner. In jedem muss Terraform validate ausgeführt werden.
Um die Tests zu beschleunigen, führen wir mehrere Prozesse parallel aus.
Parallelität ist ein sehr nützliches Feature, nutzen Sie es.
Aber jedes Mal, wenn Terraform initialisiert wird, fragt es bei HashiCorp nach: „Was sind die neuesten Plugin-Versionen? Und das Plugin, das ich im Cache habe – ist das das richtige oder nicht?“ Das hat jedes Mal zu einer Verzögerung geführt.
Wenn Terraform gefragt wird, wo die Plugins liegen, wird Terraform sagen: „Okay, das ist wohl das Neueste, was es gibt. Ich werde nirgendwo hingehen, ich beginne sofort, Ihren Terraform-Code zu validieren.“
Um den entsprechenden Ordner mit den benötigten Plugins zu füllen, haben wir einen sehr einfachen Terraform-Code, den Sie nur initialisieren müssen. Hier müssen natürlich alle Anbieter angegeben werden, die in Ihrem Code eine Rolle spielen, sonst wird Terraform sagen: „Ich kenne keinen Anbieter, weil dieser nicht im Cache ist.“
Das Nächste ist Terraform plan. Wie bereits erwähnt, ist die Entwicklung zyklisch. Wir machen Code mit Änderungen. Und dann müssen wir herausfinden, welche Änderungen für die Infrastruktur geplant sind.
Und wenn die Infrastruktur sehr, sehr groß ist, kann man ein Modul ändern, eine Testumgebung reparieren oder eine bestimmte Region und dabei eine benachbarte kaputt machen. Daher sollte Terraform plan für die gesamte Infrastruktur durchgeführt werden und zeigen, welche Änderungen geplant sind.
Man kann es intelligent angehen. Zum Beispiel haben wir ein Python-Skript geschrieben, das die Abhängigkeiten auflöst. Abhängig davon, was geändert wurde – ein Terraform-Modul oder einfach ein bestimmtes Element – erstellt es Pläne für alle abhängigen Verzeichnisse.
Terraform-Pläne sollten auf Anfrage erstellt werden. Das ist zumindest das, was wir tun.
Tests sind natürlich gut, um jede Änderung, jeden Commit zu überprüfen, aber Pläne sind eine recht kostspielige Angelegenheit. Und im Pull-Request sagen wir: "Bitte, gib mir die Pläne." Ein Bot wird gestartet und sendet in den Kommentaren oder als Anhang alle Pläne, die aus deinen Änderungen abgeleitet werden.
Ein Plan ist eine recht kostspielige Angelegenheit. Er benötigt Zeit, da Terraform bei Amazon nachfragt: "Existiert diese Instanz noch? Hat dieses Autoscale tatsächlich diese Parameter?" Um dies zu beschleunigen, kann man einen Parameter wie refresh=false verwenden. Das bedeutet, dass Terraform den Status aus S3 lädt und davon ausgeht, dass der Status genau dem entspricht, was bei Amazon vorhanden ist.
Ein solcher Terraform-Plan wird deutlich schneller ausgeführt, jedoch muss der State Ihrer Infrastruktur entsprechen. Das bedeutet, dass irgendwann und irgendwo ein Terraform Refresh durchgeführt werden muss. Terraform Refresh sorgt genau dafür, dass der State mit dem übereinstimmt, was sich in der realen Infrastruktur befindet.
Ein wichtiger Punkt, den ich ansprechen möchte, ist die Sicherheit. Darin hätte man beginnen sollen. An dem Ort, wo Sie Terraform ausführen und es mit Ihrer Infrastruktur arbeitet, gibt es eine Verwundbarkeit. Das heißt, Sie führen im Grunde genommen Code aus. Wenn der Pull-Request schadhafter Code enthält, kann dieser auf einer Infrastruktur ausgeführt werden, die zu viel Zugriff hat. Seien Sie daher vorsichtig, wo Sie den Terraform-Plan ausführen.
Das nächste Thema, über das ich sprechen möchte, ist das Testen von User-Data.
Was ist User-Data? Bei Amazon, wenn wir eine Instanz erstellen, können wir von dieser Instanz aus eine Art Nachricht senden – Metadaten. Wenn die Instanz gestartet wird, ist Cloud Init normalerweise immer auf diesen Instanzen vorhanden. Cloud Init liest diese Nachricht und sagt: „Okay, heute bin ich der Load Balancer.“ Und entsprechend diesen Vorgaben führt es bestimmte Aktionen durch.
Leider sieht user-data wie ein Wirrwarr aus Zahlen aus, wenn wir Terraform plan und Terraform apply durchführen. Das bedeutet, dass er Ihnen lediglich einen Hash sendet. Alles, was Sie im Plan sehen können, sind mögliche Änderungen oder der Hash bleibt gleich.
Wenn man dem keine Beachtung schenkt, könnte auf Amazon ein beschädigtes Textdatei auf die tatsächliche Infrastruktur übertragen werden.
Eine alternative Methode wäre, nur das Template anzugeben, anstatt die gesamte Infrastruktur auszuführen. Im Code können Sie sagen: „Bitte zeigen Sie mir dieses Template an“. So erhalten Sie eine Ausgabe, wie Ihre Daten auf Amazon aussehen werden.
Eine andere Möglichkeit besteht darin, ein Modul zur Generierung von user-data zu verwenden. Sie setzen dieses Modul ein, erhalten eine Datei auf der Festplatte und vergleichen sie mit der Referenz. Dadurch wird, falls ein Junior etwas an user-data ändern möchte, Ihre Testumgebung zeigen: „In Ordnung, hier und hier gibt es einige Änderungen – das ist normal.“
Das nächste, worüber ich sprechen möchte, ist Automate Terraform apply.
Natürlich ist es ziemlich beängstigend, Terraform im automatischen Modus auszuführen, denn wer weiß, welche Änderungen dort vorgenommen wurden und wie schädlich sie für die live Infrastruktur sein könnten.
Für Testumgebungen ist das alles in Ordnung. Das bedeutet, dass ein Job, der eine Testumgebung erstellt, für alle Entwickler wichtig ist. Und eine Aussage wie „bei mir hat alles funktioniert“ ist kein lustiger Meme, sondern ein Beweis dafür, dass die Person sich damit beschäftigt hat, das Stack aufgebaut, einige Tests auf diesem Stack ausgeführt hat und festgestellt hat, dass alles in Ordnung ist, und gesagt hat: „Okay, der Code, den ich herausgebe, wurde getestet.“
In Produktions-, Sandbox- und anderen Umgebungen, die geschäftlich wichtiger sind, können einige Ressourcen teilweise relativ sicher angewendet werden, da dies nicht dazu führt, dass jemand ausfällt. Dazu gehören: Autoscale-Gruppen, Sicherheitsgruppen, Rollen, Route53 und die Liste kann recht umfangreich sein. Aber achten Sie darauf, was passiert, und lesen Sie die Berichte über automatische Anwendungen.
Wo Anwendung gefährlich oder beängstigend ist, beispielsweise bei persistenten Ressourcen oder Datenbanken, erhalten Sie Berichte darüber, dass in einem Teil der Infrastruktur nicht angewendete Änderungen vorliegen. Der Ingenieur startet dann unter Aufsicht Jobs, um diese Änderungen anzuwenden oder erledigt dies über seine Konsole.
Bei Amazon gibt es eine Funktion namens Terminate Protection. Diese kann in bestimmten Fällen vor unerwünschten Änderungen schützen. Das heißt, Terraform fragt Amazon: „Ich muss dieses Instance löschen, um ein anderes zu erstellen“. Und Amazon antwortet: „Entschuldigung, nicht heute. Wir haben die Terminate Protection aktiviert.“
Das Sahnehäubchen ist die Optimierung des Codes. Wenn wir mit Terraform-Code arbeiten, müssen wir dem Modul eine sehr große Anzahl an Parametern übergeben. Diese Parameter sind notwendig, um eine bestimmte Ressource zu erstellen. Der Code verwandelt sich in lange Listen von Parametern, die von Modul zu Modul übergeben werden müssen, insbesondere wenn es sich um verschachtelte Module handelt.
Dies ist sehr schwer lesbar. Es ist schwierig, dazu eine Überprüfung durchzuführen. Oft passiert es, dass bestimmte Parameter überprüft werden und sie nicht ganz den Anforderungen entsprechen. Das kostet Zeit und Geld, um später Korrekturen vorzunehmen.
Deshalb schlage ich vor, eine Funktion zu verwenden, die einen komplexen Parameter beinhaltet, der eine Art Wertbaum enthält. Das heißt, Sie benötigen einen Ordner, in dem alle Werte aufgeführt sind, die Sie in einer bestimmten Umgebung haben möchten.
Durch den Aufruf dieses Moduls kann man einen Baum erhalten, der in einem gemeinsamen Modul generiert wird, also in einem Modul, das für die gesamte Infrastruktur einheitlich funktioniert.
In diesem Modul können Sie Berechnungen durchführen, indem Sie eine neue Funktion in Terraform nutzen, wie z.B. locals. Anschließend können Sie mit einem Output einen komplexen Parameter ausgeben, der Hashes, Arrays usw. enthalten kann.
Das waren all meine besten Funde, und ich möchte euch eine Geschichte über Kolumbus erzählen. Als er Geld für seine Expedition suchte, um Indien zu entdecken (so dachte er damals), glaubte niemand an ihn, und alle hielten es für unmöglich. Daraufhin sagte er: 'Macht so, dass das Ei nicht fällt.' Alle Bankiers – sehr reiche und wahrscheinlich kluge Leute – versuchten auf irgendeine Weise, das Ei aufzustellen, und es fiel immer wieder. Dann nahm Kolumbus das Ei, drückte leicht darauf, die Schale gab nach und das Ei blieb stehen. Sie sagten: 'Oh, das ist zu einfach!'. Und Kolumbus antwortete: 'Ja, das ist zu einfach. Und wenn ich Indien entdecke, werden alle diesen Handelsweg nutzen.'
Das, was ich euch gerade erzählt habe, sind wahrscheinlich ziemlich einfache und triviale Dinge. Und wenn du sie erkennst und anfängst, sie zu nutzen, ist das völlig normal. Also macht Gebrauch davon. Und wenn das für euch ganz normale Dinge sind, dann wisst ihr zumindest, wie man ein Ei aufstellt, damit es nicht fällt.
Fassen wir zusammen:
- Vermeiden Sie Schneeflocken. Je weniger Schneeflocken, desto weniger Ressourcen benötigen Sie, um Änderungen an Ihrer umfangreichen Infrastruktur vorzunehmen.
- Ständige Änderungen. Das bedeutet, dass nach Änderungen im Code Ihre Infrastruktur so schnell wie möglich angepasst werden muss. Es sollte nicht vorkommen, dass jemand nach zwei oder drei Monaten kommt, um sich Elasticsearch anzusehen, ein Terraform-Plan durchführt und feststellt, dass es eine Menge unerwarteter Änderungen gibt. Dies kostet viel Zeit, um alles wieder in Ordnung zu bringen.
- Tests und Automatisierung. Je mehr Ihr Code durch Tests und Funktionen abgedeckt ist, desto mehr Vertrauen haben Sie, dass Sie alles richtig machen. Automatisierte Lieferungen erhöhen Ihr Vertrauen erheblich.
- Der Code für Test- und Produktionsumgebungen sollte nahezu identisch sein. Nahezu, da die Produktionsumgebung doch etwas anders ist und es dabei immer Unterschiede geben wird, die über die Testumgebung hinausgehen. Dennoch kann man das in etwa sicherstellen.
- Wenn Sie viel Terraform-Code haben und die Pflege dieses Codes viel Zeit in Anspruch nimmt, ist es nie zu spät, eine Refaktorisierung vorzunehmen und ihn in eine gute Form zu bringen.
- Unveränderliche Infrastruktur. Bereitstellung von AMI nach Zeitplan.
- Struktur für Route53, wenn Sie sehr viele Einträge haben und sicherstellen möchten, dass sie in einer konsistenten Reihenfolge sind.
- Umgang mit API-Ratenlimits. Wenn Amazon sagt: „Ich kann keine Anfragen mehr annehmen, bitte warten Sie“. Und die Hälfte des Unternehmens wartet, bis es seine Infrastruktur starten kann.
- Spot-Instances. Amazon ist keine günstige Lösung, und Spot-Instances ermöglichen erhebliche Einsparungen. Darüber könnte man eine ganze Präsentation halten.
- Sicherheit und IAM-Rollen.
- Suche nach verlorenen Ressourcen, wenn Sie in Amazon Instances unbekannter Herkunft haben, die Geld kosten. Selbst wenn diese Instances 100-150 Dollar im Monat kosten – im Jahr ergibt sich das auf über 1.000 Dollar. Das Auffinden solcher Ressourcen kann profitabel sein.
- Und reservierte Instances.
Das wäre alles von meiner Seite. Terraform ist großartig, nutzen Sie es. Vielen Dank!
Fragen
Vielen Dank für den Vortrag! Ihr State-File liegt in S3, aber wie lösen Sie das Problem, dass mehrere Personen dieses State-File nehmen und versuchen, es zu deployen?
Zunächst einmal haben wir es nicht eilig. Zweitens gibt es Flags, mit denen wir kommunizieren, dass wir an einem bestimmten Code-Bereich arbeiten. Das heißt, auch wenn die Infrastruktur sehr groß ist, bedeutet das nicht, dass ständig jemand etwas anwendet. In der aktiven Phase war das ein Problem, wir haben die State-Files in Git gespeichert. Das war wichtig, sonst würde jemand ein State-File erstellen und wir müssten sie manuell zusammenführen, damit alles weitergehen konnte. Jetzt gibt es dieses Problem nicht mehr. Generell hat Terraform dieses Problem gelöst. Und wenn sich ständig etwas ändert, können Sie Locks verwenden, die verhindern, was Sie gesagt haben.
Verwenden Sie die Open-Source-Version oder die Enterprise-Version?
Keine Enterprise, das heißt, alles, was man herunterladen und kostenlos nutzen kann.
Ich heiße Stanislav. Ich wollte eine kleine Ergänzung machen. Sie haben über das Feature von Amazon gesprochen, das es ermöglicht, eine Instanz unzerstörbar zu machen. Das gibt es auch in Terraform, im Block Life Second kann man ein Änderungsverbot oder ein Zerstörungsverbot festlegen.
Die Zeit war begrenzt. Ein guter Hinweis.
Ich wollte noch zwei Dinge fragen. Erstens, Sie haben das Testen angesprochen. Haben Sie irgendwelche Tools zum Testen verwendet? Ich habe von dem Plugin Test Kitchen gehört. Vielleicht gibt es noch andere. Und ich würde auch gerne etwas über Local Values fragen. Wie unterscheiden sie sich grundsätzlich von Input Variables? Und warum kann ich nichts nur über Local Values parametrieren? Ich habe versucht, mich mit diesem Thema auseinanderzusetzen, aber ich bin nicht wirklich weitergekommen.
Wir können dieses Thema gerne detaillierter hinter dem Saal besprechen. Die Testtools sind bei uns komplett selbstgemacht. Da gibt es nichts, um wirklich zu testen. Es gibt jedoch Optionen, wo automatische Tests die Infrastruktur irgendwo hochfahren, überprüfen, dass sie in Ordnung ist, und dann alles mit einem Bericht vernichten, dass Ihre Infrastruktur weiterhin gut funktioniert. Das haben wir nicht, weil die Test-Stacks jeden Tag gestartet werden. Und das ist ausreichend. Wenn etwas anfängt kaputtzugehen, dann wird es ohnehin kaputtgehen, ohne dass wir es vorher anderswo testen.
Was die Local Values betrifft, lassen Sie uns das Gespräch gerne hinter dem Saal fortsetzen.
Hallo! Danke für deinen Vortrag! Sehr aufschlussreich. Du hast erwähnt, dass ihr sehr viel ähnliche Codes zur Beschreibung der Infrastruktur habt. Habt ihr in Betracht gezogen, diesen Code zu generieren?
Das ist eine großartige Frage, danke! Das Problem ist, dass, wenn wir Infrastruktur als Code verwenden, wir davon ausgehen, dass wir den Code betrachten und verstehen, welche Infrastruktur dahinter steckt. Wenn der Code generiert wird, müssen wir uns vorstellen, welcher Code erzeugt wird, um zu verstehen, welche Infrastruktur dort vorhanden ist. Entweder generieren wir den Code, committen ihn und im Grunde genommen ist es das Gleiche. Deshalb sind wir den Weg gegangen, wie wir es geschrieben haben, und das haben wir erhalten. Zudem sind die Generatoren etwas später aufgekommen, als wir damit begonnen haben. Und es war schon zu spät, um zu ändern.
Hast du schon etwas von Jsonnet gehört?
Nein.
Das ist wirklich eine interessante Sache. Ich sehe einen spezifischen Anwendungsfall, wo man es verwenden und Datenstrukturen generieren kann.
Generatoren sind gut, wenn man, wie im Witz über den Rasierer, denkt. Das heißt, beim ersten Mal sieht das Gesicht anders aus, aber dann haben alle das gleiche Gesicht. Generatoren kommen sehr gut an. Aber leider sind unsere Gesichter ein bisschen unterschiedlich. Das ist das Problem.
Schau einfach mal. Danke!
Mein Name ist Maxim, ich komme von Sberbank. Sie haben ein wenig erzählt, dass Sie versucht haben, Terraform mit einer Programmiersprache gleichzusetzen. Ist es nicht einfacher, Ansible zu verwenden?
Das sind ganz unterschiedliche Dinge. Man kann sowohl mit Ansible als auch mit Puppet Ressourcen in Amazon erstellen. Aber Terraform ist dafür besonders geeignet.
Haben Sie nur Amazon?
Es geht nicht darum, dass wir nur Amazon haben. Es ist fast ausschließlich Amazon. Aber das Hauptmerkmal ist, dass Terraform sich merkt, was Sie tun. Wenn Sie Ansible sagen: „Starte mir 5 Instanzen“, dann macht er das, und wenn Sie dann sagen: „Ich hätte jetzt gerne 3“, wird Terraform sagen: „Okay, ich lösche 2“, während Ansible einfach sagt: „Okay, hier sind 3“. Damit wären es insgesamt 8.
Guten Tag! Vielen Dank für Ihren Vortrag! Es war interessant, mehr über Terraform zu erfahren. Ich möchte gleich einen kleinen Kommentar dazu abgeben, dass Terraform dennoch keine stabile Version hat, also gehen Sie mit Vorsicht an Terraform heran.
Nach dem Essen ist die beste Zeit für einen Löffel. Das heißt, wenn Sie eine Lösung brauchen, dann verschieben Sie manchmal, was instabil und so weiter ist, aber es funktioniert und hat uns geholfen.
Ich habe eine Frage. Sie verwenden Remote-Backends, Sie verwenden S3. Warum verwenden Sie nicht das offizielle Backend?
Offiziell?
Terraform Cloud.
Wann wurde es eingeführt?
Vor etwa 4 Monaten.
Wenn es vor 4 Jahren erschienen wäre, hätte ich wahrscheinlich auf Ihre Frage geantwortet.
Es gibt bereits eine eingebaute Funktion sowie Locks, und man kann die State-Datei speichern. Probieren Sie es aus. Aber ich habe es auch nicht getestet.
Wir fahren mit einem großen Zug, der sich mit hoher Geschwindigkeit bewegt. Man kann nicht einfach ein paar Waggons rauswerfen.
Sie sprachen von den Schneeflocken, warum haben Sie nicht den Branch benutzt? Warum konnte es nicht so gemacht werden?
Wir haben den Ansatz, dass die gesamte Infrastruktur in einem Repository ist. Terraform, Puppet, alle Skripte, die irgendwie damit zu tun haben, sind alle in einem Repository. So können wir garantieren, dass inkrementelle Änderungen nacheinander getestet werden. Wenn es viele Branches gäbe, wäre ein solches Projekt praktisch unmöglich zu warten. Ein halbes Jahr vergeht, und sie gehen so weit auseinander, dass es einfach wie eine Bestrafung erscheint. Das ist es, wovor ich bis zum Refactoring fliehen wollte.
Das heißt, es funktioniert nicht?
Das funktioniert überhaupt nicht.
In dem Branch habe ich den Ordnerslide entfernt. Das heißt, wenn wir für jedes Test-Stack zum Beispiel ein Ordner für das Team A und einen für das Team B machen, funktioniert das auch nicht. Wir haben einen einheitlichen Code für die Testumgebung erstellt, der flexibel genug war, um allen gerecht zu werden. Das heißt, wir haben nur einen Code verwaltet.
Hallo! Ich bin Juri! Vielen Dank für die Präsentation! Ich habe eine Frage zu den Modulen. Sie sagen, dass Sie Module verwenden. Wie gehen Sie damit um, wenn in einem Modul Änderungen vorgenommen wurden, die mit den Änderungen eines anderen nicht kompatibel sind? Versionieren Sie die Module irgendwie oder versuchen Sie, eine Wunderwaffe zu erstellen, um beiden Anforderungen gerecht zu werden?
Das ist das Problem mit dem großen Schneeballsystem. Das ist es, worunter wir leiden, wenn eine scheinbar harmlose Änderung einen Teil der Infrastruktur kaputtmachen kann. Und das wird erst nach einer längeren Zeit bemerkbar.
Das heißt, gibt es bisher keine Lösung?
Erstellen Sie universelle Module. Vermeiden Sie Schneebälle. Dann wird alles klappen. Der zweite Teil der Präsentation handelt davon, wie man das vermeiden kann.
Hallo! Danke für den Bericht! Ich möchte etwas klären. Hinter den Kulissen bleibt eine große Menge übrig, wegen der ich hier bin. Wie sind Puppet und die Rollenzuweisung integriert?
User-Daten.
Das heißt, Sie generieren einfach die Datei und führen Sie dann irgendwie aus?
User-Daten sind eine Notiz, das heißt, wenn wir ein Image klonen, fährt Daemon hoch und versucht herauszufinden, wer er ist, und liest die Notiz, dass er ein Load Balancer ist.
Das heißt, das ist ein separater Prozess, der übergeben wird?
Wir haben ihn nicht erfunden. Wir nutzen ihn.
Hallo! Ich habe eine Frage zu User-Daten. Sie haben gesagt, dass es Probleme gibt, dass jemand etwas falsch übergeben könnte. Gibt es einen Weg, User-Daten im gleichen Git zu speichern, sodass immer klar ist, worauf sich die User-Daten beziehen?
Wir generieren die User-Daten aus der Vorlage. Das bedeutet, dass einige Variablen verwendet werden. Terraform erzeugt schließlich das Endergebnis. Daher kann man nicht einfach einen Blick auf die Vorlage werfen und sagen, was dabei herauskommt, denn alle Probleme entstehen, weil der Entwickler denkt, dass er in dieser Variable einen String übergibt, dabei kommt ein Array an. Und dann – zack – ist es jemand oder etwas anderes, die nächste Zeile und alles ist kaputt. Wenn es sich um eine neue Ressource handelt und jemand sie hochfährt, sieht er, dass etwas nicht funktioniert, dann kann er das schnell beheben. Aber wenn diese Autoscale-Gruppe aktualisiert wurde, fangen irgendwann die Instanzen in der Autoscale-Gruppe an, sich auszutauschen. Und auf einmal funktioniert etwas nicht mehr. Das ist frustrierend.
Scheint, dass die einzige Lösung darin besteht, zu testen?
Ja, wenn Sie das Problem sehen, fügen Sie Testschritte hinzu. Das heißt, auch mit dem Output kann man testen. Es ist vielleicht nicht so bequem, aber man kann auch irgendwelche Markierungen setzen – überprüfen Sie, dass die User-Daten hier festgeschraubt sind.
Ich heiße Timur. Es ist großartig, dass es Vorträge darüber gibt, wie man Terraform richtig organisiert.
Ich habe noch nicht einmal angefangen.
Ich frage mich, ob es bei der nächsten Konferenz vielleicht eine Diskussion darüber geben wird. Ich habe eine einfache Frage: Warum kodiert ihr Werte in einem separaten Modul fest, anstatt tfvars zu verwenden? Was macht ein Modul mit Werten besser als tfvars?
Das heißt, ich muss hier (Folie: Production/environment/settings.tf) schreiben: domain = Variable, domain vpcnetwork, Variable vpcnetwork und stvars – komme ich damit zum gleichen Ergebnis?
Genau so machen wir es. Wir verweisen auf das Setting-Modul, zum Beispiel.
Im Grunde ist das ein tfvars. Tfvars sind im Testumfeld sehr praktisch. Ich habe tfvars für große Instanzen, für kleine. Und ich habe eine Datei in den Ordner gelegt und das bekommen, was ich wollte. Wenn wir die Infrastruktur aufbauen, möchten wir, dass alles an einem Ort verständlich ist. So muss man zuerst hierhin und dann zu den tfvars schauen.
Läuft es also darauf hinaus, alles an einem Ort zu haben?
Ja, tfvars sind nützlich, wenn ihr einen Code habt, der an mehreren Orten mit unterschiedlichen Nuancen verwendet wird. Dann würde man tfvars verwenden und die jeweiligen Nuancen erhalten. Was wir haben, ist Infrastruktur als Code in Reinform. Man schaut einfach und versteht es sofort.
Hallo! Hatten Sie schon einmal die Situation, dass ein Cloud-Anbieter in das eingreift, was Sie mit Terraform gemacht haben? Angenommen, wir bearbeiten Metadaten. Dort sind SSH-Schlüssel. Und Google fügt ständig seine Metadaten und Schlüssel hinzu. Und Terraform meldet immer, dass es Änderungen gibt. Nach jedem Lauf, selbst wenn sich nichts ändert, sagt es immer, dass es dieses Feld jetzt aktualisieren wird.
Mit den Schlüsseln, aber – ja, ein Teil der Infrastruktur wird von so einer Sache betroffen, d. h. Terraform kann nichts ändern. Wir können auch von Hand nichts ändern. Momentan leben wir damit.
Das heißt, Sie haben damit zu tun gehabt, aber nichts erfunden, es macht einfach weiterhin selbst weiter?
Leider ja.
Hallo! Mein Name ist Stanislav Starkov. Mail.ru Group. Wie lösen Sie das Problem mit der Generierung des Tags auf …, wie übermitteln Sie es intern? Ich verstehe, durch User-Data, um den Hostnamen anzugeben und Puppet zu verwenden? Und die zweite Frage. Wie gehen Sie mit diesem Problem in SG um, d. h. wenn Sie SG generieren, hunderte identische Instanzen, wie benennen Sie diese korrekt?
Die Instances, die uns sehr wichtig sind, benennen wir entsprechend. Die, die nicht benötigt werden, haben den Zusatz, dass es sich um eine Autoscale-Gruppe handelt. Idealerweise können wir diese entfernen und eine neue erhalten.
Bezüglich des Problems mit dem Tag gibt es kein Problem, sondern eine Aufgabe. Tags werden bei uns sehr intensiv genutzt, weil die Infrastruktur groß und teuer ist. Wir müssen darauf achten, wo das Geld hingeht, und die Tags ermöglichen es, nachzuvollziehen, was und wohin ausgegeben wurde. Das erleichtert die Suche nach den Bereichen, in denen viel Geld fließt.
Worüber war noch die Rede?
Wenn SG hundert Instances erstellt, müssen sie dann unterscheidbar sein?
Nein, das ist nicht nötig. Jeder Instance hat einen Agenten, der meldet, wenn ein Problem auftritt. Wenn der Agent eine Meldung abgibt, kennt dieser Agent bereits die IP-Adresse des betreffenden Instances. Damit können wir eingreifen. Außerdem verwenden wir Consul für das Discovery, dort, wo es kein Kubernetes gibt. Consul zeigt ebenfalls die IP-Adresse der Instance an.
Das heißt, Sie orientieren sich genau an der IP und nicht am Hostnamen?
Es ist nicht möglich, sich am Hostnamen zu orientieren, da es zu viele gibt. Es gibt Identifikatoren für Instances – wie AE und so weiter. Diese kann man irgendwo finden oder in die Suche eingeben.
Hallo! Ich habe verstanden, dass Terraform ein nützliches Tool für Cloud-Lösungen ist.
Nicht nur das.
Genau diese Frage interessiert mich. Was passiert, wenn Sie beispielsweise massenhaft auf Bare Metal mit all Ihren Instanzen umziehen? Gibt es da keine Probleme? Oder müssen Sie doch andere Produkte verwenden, wie zum Beispiel Ansible, das hier erwähnt wurde?
Ansible ist ein wenig anders. Das heißt, Ansible wird aktiv, wenn die Instanz bereits gestartet ist. Terraform hingegen arbeitet bereits vor dem Start der Instanz. Ein Umzug auf Bare Metal – muss nicht sein.
Aktuell nicht, aber es könnte sein, dass das Geschäft kommt und sagt: 'Lass uns das machen.'
Ein Umzug zu einem anderen Cloud-Anbieter – ja, aber hier ist die Sache etwas anders. Man muss den Terraform-Code so schreiben, dass der Wechsel zu einer anderen Cloud mit möglichst geringem Aufwand möglich ist.
Anfänglich war das Ziel, unsere gesamte Infrastruktur cloudunabhängig zu gestalten, das heißt, jede Cloud sollte funktionieren, aber irgendwann gab das Unternehmen auf und sagte: 'Okay, in den nächsten N Jahren werden wir nicht umsteigen; wir können die Dienste von Amazon verwenden.'
Terraform ermöglicht es, Front-End-Tasks zu erstellen, PagerDuty zu konfigurieren, Daten-Dokumente usw. Er hat viele Funktionen. Er kann praktisch die ganze Welt steuern.
Danke für den Bericht! Ich arbeite auch seit 4 Jahren mit Terraform. Während der schrittweisen Umstellung auf Terraform, an der Infrastruktur und der deklarativen Beschreibung, sind wir auf Situationen gestoßen, in denen jemand etwas manuell gemacht hat und du versuchst, einen Plan zu erstellen. Dabei erhältst du dann irgendwelche Fehler. Wie geht ihr mit solchen Problemen um? Wie findet ihr verlorene Ressourcen, die angegeben waren?
In der Regel manuell und durch Beobachtung. Wenn wir im Bericht etwas Merkwürdiges sehen, analysieren wir, was vor sich geht, oder wir entfernen es einfach. Generell sind Pull Requests ganz normal.
Wenn ein Fehler auftritt, macht ihr dann ein Rollback? Habt ihr das schon mal versucht?
Nein, das ist eine Entscheidung des Menschen in dem Moment, in dem er das Problem sieht.
Quelle: habr.com
