We're sorry but this page doesn't work properly without JavaScript enabled. Please enable it to continue.
Feedback

Terraform - A more versatile tool, than you thought

00:00

Formal Metadata

Title
Terraform - A more versatile tool, than you thought
Title of Series
Number of Parts
94
Author
License
CC Attribution 4.0 International:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor.
Identifiers
Publisher
Release Date
Language

Content Metadata

Subject Area
Genre
Abstract
Terraform is a tool, which is around for more than four years. Its main purpose is to manage resources as infrastructure-as-(a)-Code. That gives the advantages to create reproducible resources and reduces the factor of human error. Usually you encounter Terraform in combination with cloud-providers like AWS, Azure or GCP. However, this talk will focus on other providers and show its versatility particularly in Kubernetes-context. Hopefully, after this talk you will be inspired to use Terraform on more providers, than you have thought before.
Keywords
15
Thumbnail
1:16:56
20
Thumbnail
59:24
23
Thumbnail
10:02
48
Thumbnail
50:08
56
76
Thumbnail
12:05
CodeHausdorff spaceXMLComputer animationMeeting/Interview
ChecklistLecture/Conference
CodeCodeComputer animation
APIEASY <Programm>ProviderCodeWalkthroughConfiguration spaceRevision controlSource codeCodeOpen sourceComputer animation
ProviderCodeLink (knot theory)ProviderComputer animationProgram flowchart
InternetdienstPoint cloudProviderComputing platformAPIVersion <Informatik>APIPoint cloudStrich <Typographie>CodeProviderPlug-in (computing)Computer animation
CodeCodeVariable (mathematics)DiagramProgram flowchart
Variable (mathematics)Coma BerenicesVariable (mathematics)Quantum stateSoftware repositoryGit <Software>Module (mathematics)Source codeComputer animation
ProviderVersion <Informatik>Computer animation
Version <Informatik>Server (computing)Software repositoryComputer animation
SelektorTemplate (C++)Version <Informatik>Parameter (computer programming)Computer animation
Template (C++)Server (computing)Server (computing)Cache (computing)Web browserVariable (mathematics)Computer animation
Server (computing)Template (C++)RelationalsystemComputer animation
SelektorTemplate (C++)Dynamical systemProviderComputer animation
APIComputer animationLecture/ConferenceMeeting/Interview
DemosceneTemplate (C++)Run-time systemComputer animation
Template (C++)DemosceneComputer animation
TOUR <Programm>Software repositoryComputer animation
Computer animation
Token ringSoftware repositoryComputer animation
DemosceneTangible user interfaceComputer animation
Project <Programm>TOUR <Programm>Computer animation
Software repositoryKubuntu <Programm>Computer animation
OutlookCodeProviderVersion <Informatik>CodeComputer animation
AutomationData centerComputer animation
Open sourceConfiguration spaceMobile appPoint cloudPoint (geometry)Open sourceVariable (mathematics)Template (C++)Sage <Programm>Computer animationLecture/Conference
TypProviderComputer animation
ProviderSet (mathematics)TypCodeAPIMobile appLecture/Conference
openSUSEXMLComputer animation
Transcript: German(auto-generated)
Welcome to my talk. Terraform, a more versatile tool than you thought. Ja, eine kleine Vorwarnung. Dieser Talk ist wirklich ein high-level talk.
Das heißt, ich werde eher an der Oberfläche rumkratzen und versuchen einen guten Einstieg in die Thematik zu geben. Und für Illustrationszwecke ist der Code nicht unbedingt im best practice, aber einfach nur, um es sinnbezuhalten. Am Ende des Tages ist meine Hauptmotivation, erstens, probiert einfach mal Terraform aus.
Und zweitens, es ist wirklich wesentlich vielseitiger als ihr glaubt. So, wie wer von euch kennt nicht diese Situation, sitzt zu Hause oder im Office, kriegt die Anforderung, wir brauchen jetzt N-Resourcen, und zwar sofort, die das und das können.
Wer kennt das nicht? Und wenn das passiert, kann es zwei Szenarien geben. Entweder, es klappt relativ schnell, oder es klappt relativ schnell innerhalb ein paar Tagen.
Oder, man wartet und wartet und wartet. Au, es sind Ferien. Und wartet und wartet. Ja, es gibt halt Zeiten, da war es größtenteils abhängig von ein oder zwei Operatoren,
die dann sich durchgeklickt haben oder ihre Checkliste an Shellbefehlen durchgeführt haben. Wenn sie versionierter waren, haben sie Bash-Skripte verwendet. Aber das ist alles recht zeitaufwendig, und man kommt sich irgendwie vor wie in einer Wüste.
Das ist der Moment, wo Terraform ins Spiel kommt. Terraform, dieser Begriff, oder das Terraforming, kam in den 40er Jahren von Science-Fiction Autoren auf, die den Prozess beschrieben haben, einen wüsten, leblosen Hemmetskörper in einen erdähnlichen,
deswegen terraähnlichen Zustand zu verbringen, was schon fast paradiesisch ist. Das einfängliche Beispiel ist eher ein wüster Planet, wo man warten muss und warten muss und warten muss.
Jenseits des Paradieses. Aber wir wollen ja eigentlich eher paradiesähnlichen Zustand. Terraform arbeitet nach dem Prinzip Infrastructure as Code. Es stammt von Haschikorp, ähnlich wie Ward und Packer. Für diejenigen, die jetzt vielleicht beim vorhergehenden Talk von Emily anwesend waren,
sind sehr viele Übereinstimmungen der Einleitung. Aber andererseits, es ist eine super Gelegenheit, um dafür zu sorgen, dass wirklich jeder einen einfachen Einstieg kriegt. So, weiter. Ich beschreibe Terraform immer gerne als kodifizierte API-Calls in einer deklarativen Konfigurationssprache.
Weil, wenn man unter die Haube schaut, läuft es genau auf das hinaus. Ein schöner Vorteil ist, es ist Open Source. Das heißt, man kann den Quellcode nehmen, man kann Change-Requests einreichen.
Und die Marketingversprechen sind in der Hinsicht sicher vorhersagbar. Man kann seine Infrastruktur erstellen, ändern, verbessern, unterschiedliche Provider konfigurieren. Und allgemeine Vorteile sind allgemein, wenn man seine Infrastructure als Code definiert hat,
können diese in Versionskontrolle eingepflegt werden. Und somit kann ein vorhergehender, funktionierender Zustand wieder hergestellt werden. Weiterer Vorteil ist, es ist modular und einfach zu automatisieren. Jetzt ganz einfach schematisiert, Infrastructure als Code kann wie folgt aufgebaut sein.
Der Code zur Linken schickt die API-Befehle an den Provider. Und der Provider richtet dann die Infrastructure ein, wie das im Code definiert ist. Dabei können mehrere Sachen gleichzeitig nebeneinander oder in aufeinander folgender Reihenfolge definiert sein.
Das Schöne ist, Terraform kann in unterschiedlichen Providergruppen zusammengefasst werden. Diese sind Cloud Provider, Container, Plattform, Network Provider. Also Cloud Provider, ich glaube, darüber brauchen wir nicht reden.
Container, Docker, Kubernetes, aber auch Nomad. Network Provider, Big F5, Big IP zum Beispiel. Versionskontrolle, GitLab, GitHub, Bitbucket. Monitoring, Grafana, Ichinga. Databases, die klassischen SQL Databases.
Und am Strich kann man sagen, wenn es eine API hat, ist es wahrscheinlich auch mit Terraform manageable. Oder entweder offizielle Provider-Plugins oder auch Community-Plugins.
Der normale Ablauf ist im Prinzip, es existiert der Code. Dann führt man Terraform Init aus. Terraform Init lädt die benötigen Plugins und überprüft nach groben Syntaxfehlern. Dann sagt man Terraform Plan. Dann bekommt man eine Übersicht dessen, was erstellt werden würde oder was geändert werden würde.
Im Vergleich zum existierenden Zustand. Dann kann man überprüfen, ob das übereinstimmt mit dem, wie man es sich vorstellt. Wenn es angewandt werden soll, kann Terraform Apply verwendet werden. Und die Infrastruktur steht.
Wenn man die Infrastruktur nicht mehr haben, führt man Terraform Destroy aus. Und all das, was definiert ist im Code, wird entfernt. Und es entstehen keine weiteren Kosten. Ganz einfach, um die Konfigurationssprache zu verstehen. Die HersheyCorp Configuration Language, oder was mehr oder minder auf JSON aufbaut, sieht wie folgt aus.
Die Variablen können wie folgt definiert werden, deklariert werden. In der TF werden die dann auch definiert.
Und im Code werden die so verwendet. Wenn keine Variable definiert ist, sondern nur deklariert ist, dann wird beim Ausführen von Terraform Plan oder Terraform Apply gefragt, welchen Wert man für diese Variable haben möchte. So kann man auch seinen Code variabler gestalten.
Und es lässt sich wunderbar mit Modulen kombinieren. Wie gesagt, der vorhergehende Vortrag von Emily war sehr gut, was auch die Module betraf. Aber nur einfach, um es kurz darzustellen. Module können so verwendet werden. Quellcode gibt man einfach an.
Modul sagt, wo gibt den Pfad zum Modul an. Dieser kann lokal liegen. Oder es ist auch möglich, ein Git Repo zu verwenden und einfach einen bestimmten Tag von diesem Git Repo zu verwenden. Somit kann man auch leichter Zustände wieder herstellen,
wenn man Breaking Changes durchgeführt hat. Und die können auch mit Variablen kombiniert werden. Wenn mehrere zusammenarbeiten, wird das TF State File, welches den Zustand beschreibt, in einem Backend gespeichert.
Und je nach Form des Backends wird auch ein Log verwendet, das nicht mehrere gleichzeitig Änderungen durchführen kann, was vielleicht zu unvorhersehbaren Resultaten führen kann. Aber so viel zur Einleitung. Ich möchte mich in meinem Talk mehr auf das Management von Colena-Plattform
und Versionkontrollsystemen befassen. Ein kleines Beispiel, Terraform und Kubernetes. Zugegebenermaßen, es ist ein sehr primitives Konstrukt. Ich sage mit Terraform, kommuniziere mit dem Kubernetes Cluster und erstelle mir ein, zwei oder drei Engine X Server
und frage die einfach ab. Weil, wie gesagt, ich möchte einen High-Level Vortrag halten und einfach nur zeigen, wie easy es geht. Genau, hier ist mein Repo.
Dann führe ich aus Terraform Plan, um einfach eine Übersicht zu bekommen, was verändert werden soll. Nichts wirklich Spektakuläres. Mit der Version 0.12 wurde es um einiges ausführlicher.
Wenn es mir gefällt, sage ich Terraform Apply. Mit der Version 0.12 kam zu, dass bei Apply auch noch gesagt wird oder nochmal alles aufgeführt wird. Zusätzlich kann man auch einen Output definieren,
der ausgibt, was beim Erstellen der Infrastructure für Parameter gesetzt wurde. Ich habe gesagt, dass da nur ein Engine X erstellt werden und auf diesem Port erreichbar sein. Das können wir einfach mal kurz überprüfen.
Ich verwende in diesem Falle Curl, weil im Browser wird Caching genutzt und dadurch sieht man keine Veränderung. In dem Falle sehen wir, okay, der Engine X Server läuft auf der SEMA IP.
Nichts Spektakuläres. Wenn wir aber sagen, wir wollen letztendlich nicht einen Engine X haben, sondern drei, sagen wir einfach, okay, Variable 3. Der stellt fest, was für eine Veränderung stattfinden soll.
Gibt es hier an, mache aus 1 Replika 3. Ich bin damit einverstanden. Und dann sollte man sehen, dass sich eigentlich auch genau die Container ändern.
Relativ simpel und nichts Großspektakuläres. Kein Hexenwerk. Wenn man einfach sagt, okay, ich habe genug davon. Terraform Destroy.
Und das war es aus dem Aus. Gut. Man könnte argumentieren, okay, mit Deployment und dynamischem System. Es kann kümmern, jedes von alleine.
Oder ich hätte es mit wenigen Zeilen Helmschad auch bekommen können. Kann ich zwei Dinge dazu sagen. Erstens, Terraform kann auch Helmschads verwenden. Und zweitens, wie gesagt, ich möchte mit dem Talk inspirieren, einfach Terraform außerhalb nur der Cloud-Umgebung zu benutzen.
Es supportet sehr viele Provider. Und vielleicht ermöglicht es für euch, den Alltag leichter zu machen. Nächste Beispiel. Terraform und GitLab. Ich weiß nicht, hat jemand von euch schon mal an so einen Gedanken oder so einen Gedanken gehabt.
Möchte ich vielleicht mein GitLab mit Terraform kommunizieren lassen. Weil GitLab hat ja auch eine API. Und das ist sogar supported. In dem Falle sage ich, mit Terraform erstelle ich mir ein GitLab-Projekt. Also meine GitLab-Umgebung ist leer.
Keine Projekte. Langweilig. Ich weiß. GitLab. Den Terraform-Plantei erspare ich euch mal.
Genau. Aus Debugging-Gründen und zur Illustration habe ich gesagt, dass gleich mein GitLab-Token von dem Projekt, was ich mit Terraform erstellen ließ, ausgegeben wird. Eigentlich sollte man den gut aufbewahren und sicher halten.
Aber naja. Es ist, wie gesagt, zu Illustrationszwecken. Schauen wir auf unser GitLab. Sehen wir, okay, wir haben ein Projekt mit Terraform erstellt. Das ist doch toll. Aber langweilig. Was nützt uns das? Ja, nichts.
Nicht mal eine Pipeline. Sorry. Nachschauen, Runner. Ja, können wir hinzufügen. Aber wir erkennen zumindest, dass der Token der gleiche ist, wie er uns ausgegeben wurde. Ja, gut. Was ist, wenn wir einfach mal sagen,
wir wollen einen GitLab-Runner zu unserem Projekt hinzufügen oder mit dem Projekt zusammen einen GitLab-Runner erstellen und den auch einwenden? Weil es ist nicht unbedingt immer gleich, dass die Leute, die Developer sind und einen GitLab-Repo nutzen,
auch für die Infrastruktur zuständig sind. Manchmal heißt es, wir wollen ein neues Repo. Blah, machen wir das, dass da Runner funktioniert. Somit lässt sich das mit einem einfachen Terraform-Befehl ausführen. Wir haben unseren Runner hinzugefügt. Neues Projekt erstellt, Runner eingebunden, fertig.
No Act. Ohne irgendwelche manuellen Eingriffe, Suchen von irgendwelchen Tokens, irgendwelche Tokens hinzufügen. Man kann einfach sagen, dass der Token, der von dem GitLab-Projekt erstellt wird, auch gleich direkt an den Runner weitergegeben wird. Kein Problem.
Genau, das haben wir gerade gemacht. Aber wenn wir ein GitLab-Projekt haben, können wir auch noch andere Spiele reinmachen. Zum Beispiel. Es können ja auch Leute geben, die sagen,
ich will keinen GitLab-Runner haben, mich interessiert ein gebarniertes Cluster daran anzubinden. Kein Problem. Einfach Terraform apply, Enter, bestätigen.
Ich habe jetzt absichtlich gezeigt, was da die Hintergründe sind, weil sonst sollte man das Zertifikat auch nicht so offenlegen. Schauen wir einfach mal wieder in unseren GitLab hinein. Siehe da, wir haben unser Demo-Order.
Und wenn wir operation gehen, kubernetes, erstmal ein Cluster, angebunden, that's it. So einfach kann es gehen. Hauptsache man hat erstmal sein Cluster fertig oder vorher zu stehen, oder kann ihn auch mit Terraform erstellen. Wie man möchte. Und, genau.
Damit war ich etwas schneller als geplant. Etwas arg schneller, okay. Meine aktuellen Kritikpunkte sind, es gibt eine wunderbare Übersicht, was geändert wird, also als positive Kritik. Es ist aber auch sehr provider-spezifisch.
Es heißt, wenn man jetzt wieder zurück zum Cloud-Gedanken kommt, man kann nicht eins zu eins den Code übertragen, von AWS zu Azure, zu Google. Weil einfach, wie die Cloud-Provider im Hintergrund funktionieren, lässt sich nicht eins zu eins übertragen. Und dadurch ist es auch nicht so einfach, den Code so anzupassen.
Wenn man jetzt Provisioner benutzen möchte, geht zurzeit Sword, Chef und Puppet. Und auch rudimentäre Provider, wie zum Beispiel Bash oder Shell-Befäle.
Gegenwärtig ist kein Ansible-Support, aber ich habe in einem vorhergehenden Talk gezeigt, wie es möglich ist, mit Ansible Terraform auszuführen, die Informationen, die Terraform ein zurückgibt, wieder für Ansible zu benutzen, um dann weitere Sachen zu provisionieren. Gegenwärtig ist es zwar Version 0.12, aber es können eigentlich immer größere Änderungen erwartet werden.
Nichtsdestotrotz sind die Versionen in der Regel sehr stabil. Es gab eine größere Veränderung von 0.11 zu 0.12, was die Konfigurationssprache angeht. Aber die Dokumentation ist sehr gut. Kurz noch als Anmerkung.
Ich arbeite als IT-Consultant für die ATIX AG. Wir machen im Prinzip alles, was um Rechenzentrum Automatisierung sich dreht. Das sind unsere Kontaktdaten. Und wir veranstalten auch im Oktober die OSAT Open Source Automatization Days,
was sich mit diesen Punkten befasst. Vielen Dank für die Aufmerksamkeit. Gibt es Fragen? Ja, bitte.
Am Beispiel ein repo anlegen zu wollen, in GitLab in dem Fall. Ich werde ja in der Regel das gleiche repo nur einmal anlegen. Aber man will vermutlich ein Template haben, welches man immer wieder benutzt für neue Repositories. Wie sieht das aus mit diesem Templating?
Beispielsweise, wie ich anfangs gesagt habe, kann das Mikrofon vielleicht etwas reduziert werden? Wie ich anfangs gesagt habe, die Variablen können deklariert werden, aber nicht definiert werden. So kann beispielsweise Terraform Apply ausgeführt werden.
Und dann kommt eine Abfrage, wie möchtest du dein GitLab Projekt nennen? Und dann wird es dementsprechend erstellt. So kann man das machen. Oder man kann direkt beim Ausführen die Variablen geben, so wie ich gerade eben diese Repli gesetzt habe. So ist das beispielsweise möglich.
Gut, vielen Dank. Ja, bitte. Sag einfach.
Was ist das Zauberwort, mit dem sich dieser State über Teams, oder vor kurzem über Stärken lässt? Backhands ist das Zauberwort. Ich schlage vor, am besten rede mit der Emily. Oder schau dir den Tag von der Emily an.
Genau darauf geht sie ein. Und auch ihr bevorzugter Rapper für Terraform Terragrunt. Da erklärt sie das wunderbar. Ansonsten lässt sich das kurz zusammenfassen. Du gibst im Prinzip als zusätzlichen Provider Backhands an. Sagst, welchen Typ dieser Provider hat.
Die Frage war, wenn mehrere Leute zusammenarbeiten, wie ist es möglich, dass der Zustand, der MTF-State abgespeichert wird, auch für alle einsichtig ist und auch gleichzeitig verwendet werden können. Dazu kommen die Backhands ins Spiel. Die werden verwendet wie ein klassischer Provider.
Dann sagt Provider Backhand, gibt den Typ an, S3-Bucket, Azure, whatever. Und je nachdem, welcher Typ verwendet wird, ist ein Lock-Mechanismus möglich, der verhindert, dass mehrere zeitgleich darauf zugreifen oder Veränderungen durchführen. Das sollte das Problem lösen.
Gerne. Gibt es weitere Fragen? Anmerkungen? Gut. Wie gesagt, meine Hauptmotivation war, einfach anzuregen. Das Tool ist leicht zu verwenden. Es gibt eine sehr große Menge an Provider. Manche API-Calls werden recht umständlich umgesetzt.
Wenn das Tool eine API hat, nutzt es. Wenn es in Code um zu formulieren ist, umso besser macht es. Es ist wirklich einfach. Ansonsten, go nuts, have fun.