Skillbyte Podcast #36: Terraform - Virtuelles Rechenzentrum mit dem Infrastructure as a Service (IaaS) Werkzeug

Willkommen zum Skillbyte-Podcast! Skillbyte ist Ihr Partner für digitale Exzellenz.

In diesem Podcast geht es um das Thema: Terraform - Virtuelles Rechenzentrum mit dem Infrastructure as a Service (IaaS) Werkzeug

// Inhalt //
01:10 - Definition: Was ist Terraform? Was leistet die Software?
06:23 - Software eats Hardware -> Infrastructure as a Service
07:42 - Welches Problem löst Terraform und wie erfolgt der Einsatz?
08:40 - So sieht ein typisches Terraform Projekt aus
11:53 - Der Terraform State - am besten remote in der Cloud
16:18 - Vorteile von Terraform
16:28 - Vorteil: Infrastructure as Code / Versionierbar in GIT
16:48 - Vorteil: Infrastrukturänderungen können sofort getestet werden
17:12 - Vorteil: Integration in CI/CD Pipeline
17:50 - Vorteil: Zentrale Infrastrukturpakete /-module
20:11 - Vorteil: Buildserver kann Terraform ausführen
20:44 - Vorteil: Portierbarkeit zwischen Cloudplattformen
23:22 - Nachteile von Terraform (Funktionsgrenzen, Cloud Limits)
23:30 - Nachteil: keine Einheitliche Benamung bei unterschiedlichen Providern; unvollständige Dokumentation
26:20 - Detaileinrichtung von VMs benötigt weitere Werkezuge (Ansible, Puppet, Chef)
27:48 - Vorteil: Kubernetes Umgebungen können mit Terraform provisioniert werden
28:35 - Nachteil: Proprietäre Cloud Features via Terraform nicht oder später verfügbar
31:48 - Nachteil: Abstraktionsschichten erhöhen immer die Komplexität
32:47 - Vorteile: Infrastruktur versionierbar, kurzfristige Wartezeit auf Ressourcen, Rückgabe nicht verwendeter Ressourcen, große Community
34:17 - Variablen in Terraform Templates für unterschiedliche Umgebungen
35:54 - Terraform Graph: stets aktuelle Dokumentation der Infrastruktur

Abonnieren Sie diesen Podcast und besuchen Sie uns auf https://www.skillbyte.de

Feedback und Fragen gerne an podcast@skillbyte.de

AUTOMATISCH ERZEUGTES TRANSKRIPT

Im Endeffekt kann Terraforming die meisten Services, die man in dem grafischen Interface bei den verschiedensten Cloud-Anbieter zusammen klicken kann, kann man auch über Terraforming abdecken.

Herzlich willkommen zu unserem Skillbyte Podcast Episode 36 Tierform Virtuelles Rechenzentrum mit dem Infrastructure as a Service Werkzeug abonniert unser Podcast für mehr spannende Technologie Themen Wenn Ihr IT Entscheider oder IT Fachkraft seid, wenn ihr eine Frage habt, könnt ihr die gerne einsetzen an Podcasts skillbyte Wir freuen uns immer über Bewertungen und weitere Empfehlungen an eure Freunde und Kollegen, wenn sie thematisch auch interessiert sind. Ich bin heute wieder hier mit dem Skillbyte Experten Max Max.

Hallo Maurice, schön wieder dabei zu sein.

Ich freue mich auch tierisch, denn wir sprechen heute über das Werkzeug Terraforming, mit dem wir beide ja auch schon viel Zeit verbracht haben und das wir kennen und lieben lernen durften in den vergangenen Wochen und Monaten. Möchtest du kurz sagen, was Terraforming ist?

Gerne. Terraforming ist eine Software, die von der Firma Hatschi Corp entwickelt wird, die dazu gedacht ist, Infrastruktur in einer dekorativen Konfiguration Sprache zu positionieren. Wie viele der Tutzinger verwenden, ist das auch Open Source in dem Fall und die Konfiguration Sprache kann man sich aussuchen, ob man die eigene Konfiguration Lankwitz benutzen möchte oder Jason. Das erstere ist etwas Menschen lesbarer an der Stelle und das Ziel von Terraforming ist es, am Ende die Infrastruktur über Infrastruktur Code abzubilden und Provider übergreifend das zu ermöglichen, so dass man quasi Infrastruktur, Übersetzer, Google oder auch im lokalen Rechenzentrum darüber verwalten kann.

Genauso Terraforming ist sozusagen der Nukleus in der Mitte, der mit Plugins der einzelnen Cloud Provider Amazon, Google, Microsoft, also AWS, Escher und GSVP erweitert werden kann, um die einzelnen Cloud Features dann zu nutzen. Also virtuelle Maschinen hochfahren, Storage positionieren und so weiter. Und bei der Vorbereitung zu dieser Episode ist mir aufgefallen, dass es ganz interessant ist, das Terraforming im Wesentlichen nur vier Aufrufe benutzt init, plan, apply und destroy und so im Prinzip perfekt.

Dieses Ziel verkörpert ich schreibe in der Sprache meine Wunschvorstellung der Infrastruktur herunter und kann diese dann genauso auf meinem bleiben wir mal beim Cloud-Anbieter in dieser Cloud Umgebung bereitstellen. Das geht auch sehr sehr schnell und sehr sehr komfortabel. Man kann sich das wirklich vorstellen, dass man um beim Beispiel zu bleiben, man legt eine Datei an, wie die Netze konfiguriert werden sollen, welche VMs man braucht, ob man ein Luftballon braucht, welche Rechte Gruppenzugehörigkeit und so weiter konfiguriert. Terraforming, das ist beispielsweise gegen die Google Cloud arbeitet und sagt dann also erst mal Terraforming Unit lädt die Plug ins runter, dann Terraforming Plan, dann guckt der vom quasi in die Cloud rein.

Okay, welchen Zustand hat das heute und welchen möchtest du? Oder hast du in den Dateien beschrieben? Und Terraforming Play führt dann die Änderungen aus, die dafür nötig sind. Vielleicht habe ich ja schon drei VMs und möchte noch eine vierte hinzunehmen. Dann würde noch eine neue hinzugefügt werden. Und Terraforming auch so schlau das zu erkennen, dass hier nicht alles neu aufgebaut werden muss, sondern dann die einzelnen Änderungen, das Delta zwischen Code Konfiguration und dem aktuellen Zustand dann eben ausgeführt.

Genau. Und das sei auch so intelligent zu erkennen, wenn bestimmte Abhängigkeiten bestehen zwischen Systemen zum Beispiel, wie du angedeutet hast, oder in deinem Beispiel Das virtuelle Netz möchtest du wahrscheinlich zuerst erzeugen, so dass deine VMs nachher in diesem Netz gestartet werden können. Und dann, wenn man das richtig Code konfiguriert, erkennt Terraforming der Stelle auch, dass zuerst das sucht Netz aufgebaut werden muss und erst nachdem dann alle Informationen zur Verfügung stehen über dieses suppt Netz. Um die virtuellen Maschinen an der Stelle dann hochzufahren, werden die dann im zweiten Teil Schritt sozusagen in dem Netz konfiguriert, mit den entsprechenden IP zuweisen und so weiter.

Und das ist eben sehr komfortabel an der Stelle, dass man selber nicht diese ganzen Abhängigkeiten im Kopf haben muss, sondern dadurch, dass man sagt Ich möchte eine IP-Adresse aus diesem suppt Netz der VM zuweisen. Dann erkennt Terraforming Das Subjekt muss zuerst da sein, bevor ich die VM hochfahren kann.

Wahrscheinlich. Die Plugins der Hersteller legen dann die Reihenfolge fest, das Terraforming implizit erkennen kann, in welcher Reihenfolge es die einzelnen Teilschritte abarbeiten muss bis zum gewissen Grade, so dass es meistens, sobald in einer Ressource oder am Beispiel der VM würde man der jetzt innerhalb zuweisen wollen, aber die IP oder virtuelles Netz. Aber das Netz referenziert du quasi auf das, was du vorher definiert hast und dann merkst Terraforming einfach anhand dieser Referenz, dass das Subjekt eben zuerst da sein muss an der Stelle und interne Abhängigkeiten daneben komplexe Ressource hochgefahren wird.

Das wird dann natürlich in den einzelnen Modulen vorbehalten.

Das Schöne ist. Dass man diese Infrastruktur entwickeln kann im Code auch mit je nachdem welchen Editor man verwendet, bekommt man ja auch Autovervollständigung und Hinweise zu den einzelnen Plugins. Das hat mir zum Beispiel sehr geholfen und das ist dann wirklich magisch zu sehen, wenn man diese Datei erstellt sozusagen. Und jetzt Baues auf und dann geht man hin und baut es auf. Und man kann es natürlich, dass das vierte Kommando mit Terraforming die Streu auch alles wieder abreißen. Das würde man jetzt nicht in der Produktiv Umgebung machen, aber für eine Testumgebung ist das natürlich super praktisch, weil man im Grunde den Code den man schon für die produktiv Umgebung hat, kann man dann auf eine mehr oder weniger identische ganz identisch natürlich nicht Testumgebung verwenden, die man hinterher wieder zerstören kann oder die Visionären kann.

Und dadurch, dass er in der Cloud nur die wirklich genutzten Ressourcen bezahlt, ist das sehr sehr günstig und deshalb möglich. Natürlich auch ne schnellere Iteration in der Entwicklung, dass man selber sagen kann Hey, die Infrastruktur, wir brauchen da noch einen neuen Service nach der anderen Infrastruktur Anforderungen. Das kann man dann in der Testumgebung auch dann schnell einmal ändern und gucken, wie sich das auswirkt.

Ja, Terraforming ist auch wieder so ein wunderschönes Beispiel für dieses Paradigma. Software ist Hardware. Also früher wäre der Admin hingegangen, hätte die Maschinen in das Rack geschraubt, hätte die verkabelt, hätte das Netzwerk aufgesetzt, hätte die User angelegt, die Maschinen in die verschiedenen rechte Gruppen gehievt. Heute schreibt man das alles dekorativ, meistens Jamel oder Jason fall runter und das wird dann einfach angewendet. Binnen Minuten ist natürlich schon eine erhebliche Arbeitserleichterung, muss man ganz klar sagen.

Aber es folgt ja so ein bisschen im Trend, dass immer weniger Firmen an der Stelle ihre eigenen Rechenzentren betreiben, einfach weil sie eben variable Anforderungen haben und auch zum Teil die Personaldecke nicht haben, um die gewachsenen Anforderungen an die IT an der Stelle zu erfüllen. Und dann kann man eben auch quasi in die Cloud wandern. An der Stelle aber braucht man natürlich idealerweise auch ein Werkzeug, um eben die ganze Infrastruktur in der Cloud gut verwalten zu können bzw. statt jetzt quasi zum Händler zu gehen und sich den Server zu bestellen, macht man das dann da mit Infrastruktur zu Code Terraforming macht das anhand der Parameter, die man eingetragen hat in das Plugin wird über die API sozusagen der Server bestellt oder die Rechenkapazität bestellt und die Lieferzeiten sind etwas kürzer an der Stelle.

Innerhalb von wenigen Sekunden oder Minuten ist man da schon einsatzfähig. Ich glaube, was auch wichtig ist als Abgrenzung zu sagen ist wirklich Terraforming hat auch Grenzen. Also es geht wirklich um die Infrastruktur, Netze, Rechte, Gruppen, Storage, VMS oder auch Kubernetes Umgebungen, wenn man erweiterte Anforderungen hat. Also ich habe jetzt eine VM bestellt und möchte jetzt auf dieser VM weitere Software installieren, Docker Container hochfahren und so weiter und so fort. Dann wäre Terraforming nicht das richtige Werkzeug, sondern dann muss man auch so ein weiteres Provisionsbasis Werkzeug einsetzen.

Dann Software, Provisoriums, Werkzeug wie Puppet oder Chef.

Genauso steht auch so in der Dokumentation das Helm Terraforming an der Stelle quasi Infrastruktur positioniert und dass das in Zusammenarbeit mit einem Configuration Management Tool wie zum Beispiel Puppet anzubrüllen oder andere ähnliche Programme zusammen genutzt werden soll. Also Terraforming hat quasi da auf, wo die Anwendung der Konfiguration Tools ist an der Stelle.

Also jetzt habe ich eine Vorstellung, was Terraforming macht, wenn ich jetzt Entwickler bin oder der Fachkraft. Wie sieht so ein typisches Terraforming Projekt aus? Ich installiere Terraforming. Erst mal fand ich das etwas gewöhnungsbedürftig, dass es ein relativ großes Binary das alles drin, also ein paar MB groß, man weiß nicht so genau bzw. man könnte ja in den Source Code gucken, aber es ist nur eine Datei. Jetzt lege ich ein Terraforming Projekt an, das heißt ich fange an, lass uns mal sein.

Wir würden die Jason Konfigurationsdatei verwenden wollen. Also wir starten dann im Jason Dialekt mit der Datei Menüpunkte und fangen dort an, also grundlegende Variablen zu definieren oder? Die könnte man ja auch auslagern in eine eigene variablen Datei. Aber generell ist es schon so, dass man mehrere Dateien dann anlegt, wo man dann zum Beispiel Storage positioniert Kubernetes, Cluster, Provision, VMS, Provision, Netze, Provision, so dass man im Grunde mehrere Dateien, die nebeneinander liegen, in einem Projekt Verzeichnis hat.

Aber das erste, was man eigentlich macht an der Stelle ist das Plugin oder den sogenannten Provider zu definieren, den man benutzen möchte, um die ganze Liste an Dingen, die du aufgezählt hast, zu positionieren, weil es gibt eben verschiedene Cloud-Anbieter und die meisten von denen stellen dann an der Stelle ein sogenanntes Provider Plugin zu Verfügung. Und da konfiguriert man dann auch den User, der benutzt wird um sich gegen die API des Providers zu authentifizieren. Und das gibt dir dann eben die Möglichkeit Ressourcen von diesem entsprechenden Cloud-Anbieter zu nutzen.

Und das ist meistens die erste Sache, die man an der Stelle tun sollte, dass man. Lächelnd weiß, wogegen man Provisionen hat und welcher User man an der Stelle auch benutzt.

Okay, sozusagen man verknüpft Terra Form mit dem Provider, den man einsetzen möchte, also mit dem Cloud Provider in den meisten Fällen, so dass eben über die API Infrastruktur bestellt werden kann.

Und theoretisch ist man auch nicht an einen einzigen Provider pro Script gebunden. Es gibt mehrere Anwendungsfälle, wo man zum Beispiel sagen möchte ich hab mehrere Provider des gleichen Anbieters. Zum Beispiel Google ist es ja so, dass man zum Teil verschiedene Google Projekte hat und dann könnte man eben hingehen und sagen gut, ich möchte jetzt pro Google Projekt was ich verwalte einen extra Provider haben.

Das ist jedes mal der Google Provider, aber den internen Namen würde man daneben leicht ändern. Dann kann man eben in diesen verschiedenen Projekten entsprechend dann auch Ressourcen Provisionen oder aber wenn man einen Multi Cloud Ansatz fährt, dann kann man eben auch alte Scobel und in der gleichen Terraforming Konfiguration mit verwalten. Ob man das am Ende möchte? Und von der Komplexität des Projekts muss man eben immer Projekt spezifisch evaluieren. Aber prinzipiell ist es möglich an der Stelle.

Okay, das wusste ich nicht, dass man Multi Clouds in ein und demselben Terraforming Projekt verwalten kann.

Prinzipiell. Also du definierst eben diese verschiedenen Provider und bei jeder Ressource die du dann pro Visionärs gibst du an was für ein Provider genutzt werden soll. Und da kannst du dann eben genau diese Entscheidung treffen, was ja wirklich sehr flexibel. Ein weiterer ganz entscheidender Punkt bei Terraforming ist der Staat. Also wir haben ja schon gesagt, Terraforming guckt sich quasi an, welchen Zustand hat die Infrastruktur aktuell? Da gehe ich ja über gewisse Schnittstellen, die die Plugins anbieten des Cloud Providers und sagen Okay, das ist der Zustand, der momentan vorherrscht.

Und das ist der Zustand aus den TF Dateien, der gewünscht ist. Wenn man vom Plan zum Beispiel ausführt, dann guckt er sich an welchen Zustand finde ich vor in den TF Dateien? Welchen finde ich tatsächlich vor eine Cloud? Und was muss ich machen um den Zustand der TF Dateien herzustellen und listet dann die einzelnen Schritte auf, so dass man im Grunde noch mal eine Kontrolle hat über die einzelnen Schritte, die Terraforming durchführen würde, um zu diesem Zielzustand zu gelangen.

Und Terraforming speichert den Staat der aktuellen Umgebung ja in einer Datei ab, in dem Terror vom Staate. Und das ist natürlich auch ganz wichtig, wenn ich Terraforming jetzt einfach lokal bei mir ausführen würde, die State Datei lokal bei mir auf dem Rechner ausgeführt werden. Das möchte man natürlich nicht, sondern ich möchte ja im Grunde diesen State in der Cloud Umgebung behalten, die ich auch einsetze. Jetzt gehen wir mal nicht von Multi Cloud Umgebungen aus, da wird es noch interessanter.

Das heißt man kann Terraforming auch so konfigurieren, dass der State direkt in einem Cloud Backend bei AWS oder in einer Cloud Folder bei Google dann abgespeichert wird.

Genauso dass man sich an der Stelle Backend Backend Konfiguration und da kann man dann eben sogenannte Remote Erbakans definieren, wo dann eben Estrade unterstützt wird Google, Cloud Storage, Plop Storage und so weiter. Und da ist man dann relativ flexibel in der Wahl des Beckens. Aber wie du richtig sagst, man sollte ein Bonmot bekannt an der Stelle machen, das für alle Entwickler, die an dieser Umgebung arbeiten zugänglich ist, weil sonst können sich die verschiedenen Nutzer in die Quere kommen.

Wenn du und ich unterschiedlich Lokale entwickeln und der State Lokal liegt und ich eine Änderung planen möchte, dann sieht er eben eine komplett andere Infrastruktur. Oder kann die Infrastruktur, die momentan existiert, nicht mit dem Konfigurationsdatei übereinanderlegen, weil der Hauptnutznießer dieses Staates ist, um die Terraforming internen Namen auf die Cloud Namen zu nennen.

Bei Google ins Backend in S zum Beispiel hatte ein bestimmtes Narayen Schema und das möchte man nicht immer in der Form angeben. Deswegen kann man intern in Terraforming einen etwas handlichen Namen vergeben. Und dieses Matching zwischen dem Namen in der Cloud und der Terra Form, das muss eben gegeben sein und das wird gerade im Staat gespeichert. Das ist eine der wichtigsten Informationen, die im Staate drin steht. Und wenn ich jetzt als lokale Entwickler diese Information nicht habe oder man Terraforming das nicht hat, dann kann er eben diese Ressourcen an der Stelle nicht machen.

Und im schlimmsten Fall zerstört er die Ressource, weil es eben einfach keinen Platz gibt an der Stadt. Und das kann man eben darüber vermeiden, dass entsprechend der State Remote irgendwo Krieg, der von allen Entwicklern zugänglich ist und was auch sehr wichtig ist, der Staat sollte den sogenannten Lock Mechanismus unterstützen, sodass der Reform den State locken kann, wenn es zum Beispiel Play durchführt, weil mit Play kann durchaus mehrere Minuten dauern. Und wenn jetzt während dieses Plays jemand anderes versucht Änderungen an der Infrastruktur durchzuführen, würde das den.

Einer mittleren Katastrophe enden wohl um das zu vermeiden lockerer Form, dann eben die Datei in dem Mod Stories und teils sozusagen allen anderen Instanzen, die auf den gleichen Status zugreifen dadurch mit Hallo, ich bin hier gerade am arbeiten. Bitte ändert nichts an der Infrastruktur, deswegen sollte das Becken, was man dann etwas genauer unterstützen aber eigentlich unterstützen. Alle gängigen Becken sind an der Stelle.

Das ist ja fast eine notwendige Bedingung für die Entwicklung. Also dass der Staat dann zentral gehalten werden muss und nicht auf irgendeinem Entwicklungs Rechner liegt, der vielleicht auch nicht gesichert ist oder so. Also das haben wir ja auch sofort bei unseren Projekten so eingerichtet, dass man im Grunde man muss sich nur das Binary installieren. Man konfiguriert Terraforming um den gewünschten Provider, zeigt den wo der Staat liegt und von da an kommt Helm Reform zurecht und man kommt sich nicht in die Quere.

Das hatte ich auch schon ein paar Mal, dass dann gesagt wird Helm des Staates gelockt, da arbeitet jemand dran, da kannste jetzt nichts machen.

Wir sind schon auf viele Punkte eingegangen, wie flexibel man ist, dass man eine Infrastruktur jetzt als Code ablegen kann. Da haben auch schon in anderen Podcast Episoden drüber gesprochen. Ein Hauptvorteil ist natürlich das Reformprojekt oder das Infrastrukturprojekt. Dadurch, dass es ja jetzt Code ist, ist Mitglied oder einem anderen Versions Kontrollsystem Versionierung lehrbar. Das heißt, man kann nachvollziehen, wer welche Änderungen gemacht hat und hat die ganze Git Goddess mit Branches Emerging Base und seine Infrastruktur zu verwalten.

Änderungen können sofort getestet und validiert werden. Da sind wir auch schon darauf eingegangen. Das heißt, wenn ich eine weitere Maschine brauche, kann ich die einfach eintragen und gesetzt den Fall ich bekomme das Lock, kann ich die dann auch mit Terraforming planen? Mir erst mal anzeigen lassen. Okay, er würde nur die eine Maschine hinzufügen und mit Terraforming Play macht er es dann auch wirklich. Also Terraforming Plan ist so eine Art Dry Run, bevor er noch ausgeführt werden.

Ein super praktischer Mechanismus, wenn man das ein bisschen weiter spinnt ist natürlich auch Testumgebung. In hoch und wieder runterfahren hatte ich eben schon kurz angesprochen. Das kann mit Terraforming einfach in die CIC die Pipeline, also Continuous Integration ist Delivery integriert werden und so direkt aus Git Lab oder GitHub heraus ausgeführt werden. Also ganze Testumgebung für komplexe Projekte können hochgefahren werden. Die Tests kann ausgeführt werden. Am Ende mit der Reform Destroy kann es wieder runtergefahren werden und man hat im Grunde nur minimalste Abweichungen zum Produktions Cluster oder zur Produktions Umgebung, was ja dann die Aussagekraft der Tests erhöht.

Ein anderer Vorteil wäre es an der Stelle auch, ich nenne es mal zentrale Infrastruktur Pakete. Da sind wir bis jetzt noch nicht drauf eingegangen. Aber Terraforming bietet die Möglichkeit sogenannte Module zu schreiben, was im Endeffekt ein eigenes Terraforming Script, es möchte es mal nennen, was aber definierte Inputs und Outputs hat. Und da kann man dann komplexe Abhängigkeiten oder komplexe Infrastruktur quasi in einem Modul kapseln und dann als Input zum Beispiel Name, Anzahl oder andere notwendige Konfiguration eingeben und als Output dann zum Beispiel den Namen der resultierenden Infrastruktur.

Und dadurch, dass es dann eben relativ leicht möglich, dass wenige Leute, die sich sehr gut mit Terraforming auskennen und komplexe Infrastruktur positionieren können, sei es aufgrund von Netzwerk oder anderen Thematiken, können dann eben diese Module schreiben, die zentral zur Verfügung stellen. Dann können verschiedene Entwicklerteams eben diese vor konfektioniert Infrastruktur in ihrem Projekt ausrollen. Gutes Beispiel ist da eine vordefinierte Mittelstrecke inklusive Infrastruktur und der Computer Menschen darunter und so weiter. Das kann man dann eben sozusagen in ein Modul packen.

Und das einzige, was das Entwicklerteam dann noch rein gibt es zum Beispiel die URL der Docker Image Tech, der in der Umgebung mit dem Plot werden soll, wo dann tatsächlich der tatsächliche Software Logik dahinter steckt, was in der Therapieplan getan werden soll. Aber alles drumherum kann man dann quasi in dem Modul weggeschubst. Dann macht es eben sehr einfach, komplexe Strukturen über verschiedene Teams zu teilen und das macht den Code dann auch wieder verwertbar an der Stelle.

Das heißt, man schnürt einfach ein Paket mit mehreren Hardware, Ressourcen oder auch natürlich Netz Konfiguration, um komplexe Infrastruktur Anforderungen zu kapseln glauben, die dann eben von beliebigen Teams dann wiederverwertet werden kann. Und ein Vorteil an diesen Modulen ist natürlich, wenn die dann zentral gemanagt werden, dass wenn man merkt oh da ist ein Setting ist richtig, weil ein Service Nutzer zu viele Rechte hat oder sowas. Das kann dann eben zentral gefixt werden und dann dem nächsten Versions WDS, der dann von den Konsumenten natürlich auch eingespielt werden muss, sprechen, dann auch auf alle Infrastruktur ausgerollt werden.

Was ich noch ganz interessant fand war Terraforming kann ja auch vom Server selber ausgeführt. Werden also im Prinzip kann ich mit meinem Software Projekt habe ich auch ein Terraforming Projekt, wo die Infrastruktur worauf die Software läuft eingecheckt ist und wenn ich eine Infrastruktur was ändere kann ich das mit einzuchecken und entsprechende git hooks vorausgesetzt provisorisch mit der Bild Server dann automatisch diese neue Maschine, so sie denn notwendig ist. Das halte ich auch für charmant, ist aber letztlich nur eine Konsequenz aus dieser Integration in die Klinik die Pipeline.

Wie ist das bei dir zum Thema Portier bei kühlten? Jetzt könnte man eigentlich meinen, das ist ja klasse bei Terraforming Provision eine Infrastruktur, virtuelle Maschinen laut Malenkow, Firewalls, Benutzergruppen, die gibt es überall. Und dann sage ich jetzt hier mit auf die Platinen und auf AWS die Platine und in die Google Cloud die Platine.

Ich würde sagen, es ist eingeschränkt Poti, aber Parteireform nutzt ja die Plugins der jeweiligen Cloud Provider. Jetzt sind diesen drei Beispielen und die Namen dieser Plugins ist natürlich etwas unterschiedlich. Oder die Parameter, die diese Plugins aufnehmen.

Genau. Ja, ich bin da deiner Meinung. Es ist immer mit Aufwand verbunden, wenn man den Anbieter wechseln möchte. Also einfach liegt ja auch daran, dass die verschiedenen Cloud-Anbieter zum Teil leicht andere Konfigurationen für ähnliche Services verlangen, dass es zum Teil nicht genau den gleichen Service in jeder beliebigen Cloud gibt. Deswegen ist es sehr schwer möglich, eine weitere Abstraktion einzuziehen, ohne dass du Funktionalität verlierst. Und deswegen ist es eben auch tatsächlich hier der Fall, dass die verschiedenen Provider in den meisten Fällen von den Cloud selber gepflegt werden, müssen all diese Ressourcen wieder zur Verfügung gestellt werden.

Und dann muss man, wenn man sich eben entscheidet, zum Beispiel von Apps nach Google wechseln, muss man dann eben einmal gucken. Okay, was sind die äquivalenten Konfigurationen bei dem anderen Provider? Prinzipiell etwas einfacher ist es natürlich. Ich möchte nicht sagen, dass es komplett schwierig ist, weil du hast ja schon eine funktionierende Infrastruktur und muss jetzt quasi die Übersetzung von einem Anbieter zum anderen machen, was deutlich einfacher ist als jetzt zum Beispiel ein komplett anderes Tool zu benutzen, was das dann eben möglich macht.

Zum Beispiel Cloud Front bei Apps genannt. Wenn man jetzt zu Google wechselt, kann man Cloud Front dann nicht weiter benutzen, um Google zu positionieren. Da müsste man dann eben auch das Tool wechseln. Das muss man bei Terraforming eben nicht. Man muss aber dann sozusagen den Provider in der Form selber wechseln.

Genau. Also im Prinzip sieht das so aus Man hat zwei Browserfenster offen mit der Dokumentation der vergleichbaren Plugins. Also auf der einen Seite die virtuelle Maschine beispielsweise von ASA, auf der anderen Seite von Google. Und dann guckt man Was bedeutet denn das eine? Was bedeutet denn das andere? Aber ja, man braucht menschliche Intelligenz auf jeden Fall, um dieses Mapping zu machen. Ich weiß, bei Google heißen die virtuellen Maschinen irgendwie N2, B2, S2 und bei A reißen sie irgendwie anders.

So was muss man dann selber sich raussuchen, was dann das passende Äquivalent ist. Zum Beispiel Jetzt haben wir schon einige Vorteile genannt. Lass uns mal mit den Nachteilen anfangen. Was ist denn nachteilig beim Einsatz von Terraforming?

Im Endeffekt können wir da an der Stelle anknüpfen an das, was wir gerade gesagt haben, weil es gibt eben keine einheitlichen Namen der verschiedenen Ressourcen bei verschiedenen Providern. Das ist einfach wie wir eben gesagt haben geschuldet, das den Backend von den Providern selber bereitgestellt werden und die halten sich natürlich an die Namen bis bei ihrer Cloud. Aber man muss im Endeffekt wenn man jetzt viel auf APS positioniert hat, muss man sich dann eben potenziell eine leicht andere Syntax oder vielleicht anderes Schema bei Google gewöhnen, wenn man dem Zwitschern der Sterne macht.

Das ist jetzt kein so großer Nachteil, aber man muss eben immer sozusagen die Dokumentation an der Stelle offen haben, um zu sehen Okay, welchen Parameter muss ich angeben und welche nicht. Je nachdem, welchen Provider man da hat und welche Ressourcen man genau positionieren möchte, ist dann auch die Dokumentation noch ausbaufähig an manchen Stellen, weil das Plug in an der Stelle einfach nur eine Entwicklung ist. Da gehe ich mit. Die Dokumentation da war nicht immer optimal. Ich gebe dir recht, es fehlt einfach noch so ein Zwischenschritt, der im Grunde die Abstraktion Eisschicht zwischen der Form und den einzelnen Cloud Providern darstellt.

Das ist ja auch nicht gesagt, dass so was nicht noch kommt. Ich würde sagen im Container Umfeld macht genau Kubernetes so was. Also du hast natürlich deine Kubernetes Umgebung auf den verschiedenen Cloud Providern, aber dann bist du in dieser Umgebung immer gleich oder verwaltet diese Umgebung immer gleich und benutzt jetzt nicht Docker auf den einzelnen virtuellen Maschinen.

Diese Zwischenschicht, die müsste auch noch zwischen Terraforming und den Plugins der einzelnen Anbieter eingezogen werden, damit man eben den gleichen Service in Anspruch nehmen kann. Das ist aber noch nicht. Geschehen. Man muss wirklich die Plugins der einzelnen Provider muss man im Prinzip selber erlernen oder die Dokumentation verwenden dazu, die von unterschiedlicher Güte sein kann, also die Interaktion oder die Integration in Therapie an der Stelle ist natürlich immer gleich, weil es die gleiche Konfiguration Sprache bzw. Jason Formates, aber die Parameter unterscheiden sich dann zum Teil.

Da hilft dann doch der Editor die Autovervollständigung hat, weil der dann normalerweise die auch anzeigt, welche der unzähligen Parameter die angegeben werden können, dann an der Stelle verpflichtend sind, welche optional.

Es ist schon interessant, früher im Rechenzentrum hatte man den Microsoft Server Spezialisten, den Linux Server Spezialisten, vielleicht den Unix Server Spezialisten und heute unter der Verwendung der Infrastruktur, also Service hat man dann wahrscheinlich den Perform Plug in Apps. Spezialisten sind Terraforming Plugin in Spezialisten und es verschiebt sich einfach nur. Aber natürlich muss man seine Werkzeuge kennen. Dass die State Datei idealerweise selber in der Cloud liegt, darauf sind wir schon eingegangen. Dass die dt. Positionierung der virtuellen Maschinen mit weiteren Tools erfolgen muss, wie Chef und Puppet.

Wenn man jetzt beispielsweise noch mit apt get Pakete installieren möchte oder die Maschinen dann noch feiner einrichten möchte mit Start up Scripts, das haben wir auch schon gesagt. Also da hört es bei der Reform dann auch auf. Ich weiß nicht, ob man sich per vom Plugin PSS hier irgendwo einloggen kann und eine Aktion ausführen kann. Aber wenn das notwendig ist, wäre das für mich ein klarer Punkt, dass hier noch ein weiteres Werkzeug eingesetzt werden muss.

Genau das ist auch genau das, was ich von Anfang an sagen. Sie versprechen nicht die Komplettlösung an der Stelle, sondern konzentrieren sich eben genau auf die Infrastruktur, um dann den Admin sozusagen für die restliche Provisionszahlungen oder die Konfiguration der VMS an der Stelle ihrer gewohnten Tools an die Hand geben. Wobei man an der Stelle natürlich auch sagen muss, dass ich in letzter Zeit sehr selten eine einzelne VM über den Weg gelaufen bin, die eben stand alone s, wo Pakete installiert werden mussten oder sonst was.

Sehr viel wird ja mittlerweile tatsächlich an der Stelle, dann über Container in, dann sei es Kubernetes oder der Managed TM in der entsprechenden Cloud zum Beispiel liegt, dass man eben darüber sozusagen genau diese Konfiguration dann auch wiederum in Entwickler Hände legt und nur in sehr speziellen Anwendungsfällen dann tatsächlich eine einzelne VM oder auch mehrere VMS hat, die man dann entsprechend konfigurieren muss.

Das sollten wir vielleicht auch noch sagen, dass die Kubernetes Umgebungen, die ja nur eine weitere Ausführung Umgebung sind für Container, dass die natürlich sehr wohl auch mit Terraforming Revisionist werden können, auch wenn das jetzt nicht wirklich Basis Infrastruktur ist, wie in laut Pelinka, sondern schon eine Abstraktionsebene höher liegt. Aber das ist ja auch ein zentraler Verwendungszweck von Terraforming, dass man eben diese Kubernetes Umgebungen hochfahren und damit auch Provisionen kann. Ja, das haben wir selber gemacht.

Also vielleicht an der Stelle noch mal zu betonen Im Endeffekt kann Terraforming die meisten Services, die man im grafischen Interface bei den verschiedensten Cloud-Anbieter zusammen klicken kann, kann man auch über Terraforming abdecken. Und solange das eben in Provider verfügbar ist und dass es eben ein weiterer Nachteil aus meiner Sicht, dass manche Features noch nicht gänzlich oder gar nicht in den Terraforming Plugins unterstützt sind, so dass wenn man das neueste Feature aus einer bestimmten Cloud möchte oder die neueste Ressource, dass das zum Teil dann an der Stelle nicht möglich ist, dass über Terraforming zu realisieren.

Bei Masiar gibt es zum Beispiel ein paar Funktionen, die neuen Beamten möglich sind an der Stelle. Es gibt dann die Möglichkeit des tatsächlichen Terraforming ein am Template anzuwenden, was an der Stelle natürlich eine Krücke ist und die Funktionalität bereitstellen zu können. Aber du hast dann trotzdem wieder den Poch an der Stelle und das ist eben dann an der Stelle die Anführungszeichen Unzulänglichkeit mancher Plugins, dass sie eben noch nicht auf dem Stand sind, was der Provider eigentlich zur Verfügung stellen könnte.

Ja, das ist einfach aus der Entwicklungsgeschichte heraus. Zuerst wird das neue Feature in der Cloud Umgebung bereitgestellt im UI, dann muss das vom Plugin nachgezogen werden oder es muss erst mal eine Schnittstelle geben, dass dieses Feature auch via API benutzt werden kann. Wenn das geschehen ist, dann kann es vom Plugin nachgezogen werden und dann können eben diese Funktionen auch in Terraforming verwendet werden. Und da ist natürlich die Features, die viel nachgefragt werden von vielen Usern. Die schaffen das natürlich relativ schnell, aber im Nischen Bereich dauert es dann durchaus schon mal länger.

Und vielleicht eine andere Einschränkung, die dann auch spontan entfällt. Oder ein anderes Beispiel für solch eine Einschränkung In der Google Cloud gibt es den sogenannten Google Composer. Was an der Stelle. Ein gemanaged das er Flow ist und in der Dokumentation zu der Ressource und Therapieform, wo man den Google Composer anlegen kann, steht explizit drin, dass wenn der Composer über Terraforming mitwirkt, also abgeräumt wird, das dann zum Teil Ressourcen in der Cloud zurückbleiben. Bei Terraforming die einfach nicht kennt, weil beim Hochfahren des Computers immer Ressourcen angelegt werden, die in dem aktuellen Plugin oder in der Version des Plugins nicht getrackt werden, so dass dann, wenn man dann eben das T2 macht, an der Stelle Reste übrig bleiben, die man dann noch mal händisch wegräumen muss, die auch Geld kosten, wenn man sie nicht abräumt und nicht dran denkt.

Vermutlich genau. Also es ist jetzt nicht so schlimm, dass da ein ganzer Kubernetes Cluster stehen bleibt. Also ein paar Service Rollen und ein oder zwei Backups meine ich. Aber es ist am Ende trotzdem aus meiner Sicht ein bisschen unsauber, dass da dann eben am Ende was übrig bleibt, weil eigentlich würde man eben erwarten, wenn man das dann auch tatsächlich alles von der Ressource an der Stelle abgewandt hat. Das wird vielleicht in der Zukunft mit dem nächsten Update dann behoben, aber es ist eben ein anderes Beispiel, wo man eben sich nicht immer auf die ausgereifte Zeit der Plugins verlassen kann.

Ich denke, das wird ganz sicher behoben werden müssen, weil der Anspruch ist ja schon alles was du mit Apply erstellst, musst mit Destroy wieder abgerissen werden können. Also es ist einfach ein Bug in dem Plugin oder in dem Produkt. Aktuell noch ein weiterer Nachteil. Das ist jetzt aber nichts spezifisches, sondern das ist generell oder es ist ein generisches Thema. Zwar jede Abstraktion Schicht erhöht natürlich die Komplexität, wobei ich hier sagen würde Du tauschst ja nur, dass physikalische Hardware Management gegen Software Hardware Management.

Also ob es wirklich eine zusätzliche Abstraktion Schicht ist, sei mal dahingestellt, aber man muss auf jeden Fall umlernen, ganz klar. Aber gut, in der IT muss man immer dazulernen. Das geht nicht anders. Auf keinen Fall.

Also sehe ich auch nur als sehr geringen Nachteil an der Stelle, weil du durch diese zusätzliche Komplexität unterstrichen, hast du eben tatsächlich was gewonnen, was du im klassischen Umfeld nicht so hast. Du hast eben mehr oder weniger Dokumentation. Welche Hardware an der Stelle existiert, das kriegt ihr geschenkt. An der Stelle, an der kauft es sich immer mit gewissen Komplexität an der Stelle.

Also man muss einfach was neues lernen, aber nicht wirklich ein Nachteil, das stimmt.

Auf der positiven Seite also Vorteile von Terraforming, ganz klar. Das ist mit. Der Hauptvorteil ist, dass die Infrastruktur Versionierung ist und einfach auch im Code runter geschrieben werden kann. Ich kann mir eine Infrastruktur aufbauen hier zu Hause, die in der Cloud laufen lassen, kann sie um die Welt schicken und jemand anders kann das identische Setup bei sich in der Cloud dann hochfahren. Das ist natürlich schon wunderbar, diese Möglichkeit zu haben. Die Infrastruktur steht binnen kurzer Zeit binnen weniger Minuten.

Ich weiß, manche Datenbanken in der Cloud brauchen bis zu 20 Minuten, bis sie proportioniert sind. Das ist dann natürlich immer noch viel schneller als früher, aber immer noch lange Zeit, wenn man den Bildschirm dabei nur anguckt. Dennoch ist natürlich die Bereitstellung sehr, sehr schnell. Nicht benötigte Ressourcen kann man zeitnah wieder zurückgeben. Also das ist einfach der Cloud Vorteil. Migration von einem zum anderen Cloud-Anbieter ist auch eingeschränkt möglich. Ich würde das mal als soften Vendor Lock in bezeichnen.

Also es ist möglich, es ist schon mit Aufwand verbunden, aber es ist auf gar keinen Fall so, als wenn du einen Server Paar gekauft hättest und diesen jetzt gegen andere Server tauschen möchtest. Also da ist es wesentlich zügiger. Man hat eine hohe Flexibilität für Tests oder auch bei Skalierung Anforderungen und es gibt eine große Community rund um die Plugins und um die Terraforming Entwicklung selbst. Meinem Eindruck nach. Ich habe auch ein oder zwei Tickets mal aufgemacht in den Vorbeihuschen Korb.

Man ist meistens dann noch, wenn man dann Probleme hat, entsprechend schnell fündig geworden muss. Es gibt noch ein oder zwei andere Sachen, die ich hinzufügen würde. Meinen Vorteil eine Sache, auf die wir nämlich überhaupt noch nicht eingegangen sind, ist, dass man die Infrastruktur Code, die man geschrieben hat, auch über entsprechende Parameter konfigurieren kann. Dass man dann eben sagt, dass man den Wert oder die Anzahl der virtuellen Maschinen, die man benutzt, um Kubernetes Cluster an der Stelle hochzuziehen oder tatsächlich physikalischer Maschinen den Cluster zu positionieren, eben konfigurierbar macht.

Der Vorteil ist dann, dass man über ein sogenanntes Value fein an der Stelle für verschiedene Umgebungen, zum Beispiel Tests, Reports und produktiv, am Ende dann sehr leicht verschiedene Werte für die Infrastruktur eingeben kann, so dass im Test ein Cluster mit drei NOZ läuft und den Production einer mit 20 zum Beispiel. Und das ist eben ohne dass du den Code änderst, sondern nur die Konfigurationsdateien. Da die Value Datei, die du über gibt es anders und das macht es eben dann auch einfach die Infrastruktur.

Vorher zu testen in kleinem Rahmen und die dann sehr leicht für verschiedene Umgebungen zu skalieren. An der Stelle, und es ist natürlich nicht nur auf die Maschinen Anzahl eingeschränkt, sondern im Endeffekt jeden Parameter, den man angibt, kann man dann auch konfigurierbar machen. Nur ab einem gewissen Grad ist dann eben wenig sinnvoll, wenn man quasi noch mal alle Parameter neu eingeben muss.

Also im Grunde auch bei diesem Modul Bildung, von der wir eben gesprochen haben. Du Parameter riskierst deine Schablone je nach Einsatzzweck und da kann man dann eben z.B. Masiar etc. die Pipeline entsprechend auch empfehlen, wo man gerade erst andere Konfigurationsdatei übergeben und ein andere Sache, die bisschen Vorbereitung dieses Podcasts auch drüber gestolpert bin, ist Terraforming Kram. Das ist ein weiteres Coman, was sehr Terraforming Client kann, zuzüglich zu dem Inet Plan Client History, was wir schon aufgezählt haben und der gibt dir im Endeffekt eine Grafik aus der das Kaff Command generiert eine Grafik von den Abhängigkeiten der Infrastruktur.

Weißt du, Sets zum Beispiel die virtuelle Maschine ist von dem PC abhängig und von dem Service Nutzer, den du, der angelegt wird, damit entsprechend, dass die VM auf irgendetwas anderes zugreifen kann. Und das fand ich eine sehr interessante Übersicht, die einfach mal zu generieren und dann zu gucken. Abhängigkeiten habe ich von einem in der Infrastruktur und es gibt auch die Möglichkeit, zyklische Abhängigkeiten entsprechend farbig hervorzuheben, so dass du dann eben siehst Okay, das soll dich vielleicht noch mal überdenken.

Das, was dann entsprechend potenziell nicht gut positioniert werden kann oder mehrere Plays braucht, damit es überhaupt funktioniert.

Ja, Wahnsinn. Das heißt, du bekommst zu deinem virtuellen Rechenzentrum im Grunde noch so einen Aufbau Diagramm, also über die Ressourcen, die Terraforming kennt. Ja und nutzt er dafür die State Datei?

Ich glaube du kannst verschiedene Sachen florieren. Also du kannst einmal das was im Staate steht oder das was er beim Clan ausspucken würde an der Stelle dann. Also du kannst auch sozusagen aktuell mit zukünftig vergleichen und wahrscheinlich, wenn man genug Muße hat, quasi einen Diff in diesen Graphen dann degenerieren lassen, sodass du dann farbig einzeichnen kannst. Das ändert sich im Vergleich zu dem.

Das ist natürlich für Unternehmen ein Riesenvorteil, wenn man die Dokumentation der Infrastruktur implizit dann aus der Konfiguration heraus generieren kann oder aus der laufenden Umgebung heraus generieren kann und sich stets vor Augen führen kann. Wie sieht das denn eigentlich aus? Ich habe schon einige Rechenzentren gesehen und da gibt es natürlich auch Dokumentation wie was funktioniert und welche Abhängigkeiten es gibt. Aber so ganz genau glaube ich, ist man dann immer noch auf den Experten angewiesen, der vor Ort sitzt, weil man kennt das Dokumentation, die irgendwo auf der Festplatte liegt, die veraltet schnell.

Aber wenn Terraforming das generieren kann aus dem aktuell laufenden System heraus, dann wäre das natürlich ein Riesenvorteil, weil dadurch ist diese Dokumentation immer aktuell.

Gab es tatsächlich einmal aus Interesse auf einen etwas komplexer das Projekt angewendet vor dem Podcast.

Es funktioniert, aber je komplexer das Projekt, das so unübersichtlicher wird, das Diagramm dann natürlich.

Das heißt, die grafische Darstellung ist noch ein Problem.

Genau das könnte man vielleicht noch verbessern, aber das wird über Diagramms gemacht, so dass man da wahrscheinlich mit entsprechenden Tools auch dann vielleicht händisch noch mal ein bisschen aufarbeiten kann. Also Du kriegst tatsächlich Jason Fallen aus der Generierung raus, was dann der etwas angibt zwischen den verschiedenen Komponenten, dann kann man das dann wiederum in externe Tools Python oder einbinden, das dann entsprechend der Kraft generiert wurde.

Okay, also die Darstellung, das ist ja wahrscheinlich dann nur noch eine Sache von der Weiterentwicklung. Wichtig ist aber, dass man quasi alle Informationen erst zusammenträgt und wie dann die grafische Aufbereitung erfolgt, gerade auch wenn man dann schon existierende Tools nutzen kann. Da bin ich sicher, dass da sehr schnell geeignete Darstellungsform, möchte ich es mal nennen, gefunden werden. Ja, da habe ich noch nicht gesehen. Werde ich mir auf jeden Fall anschauen, weil das ist natürlich ein Riesenvorteil.

Dokumentation der Infrastruktur stets aktuell. Das hilft den Unternehmen doch dann immer zu wissen, welche Infrastruktur sie gerade einsetzen. Wenn unsere Zuhörer Fragen haben oder Feedback zu aktuellen Podcast Episode, können Sie uns gerne eine E-Mail schicken an Podcasts skillbyte Wir freuen uns immer über eine Bewertung und eine Weiterempfehlung an eure Freunde und Kollegen. Lass uns gerne ein Abo da und abonniert unseren Podcast. Und wenn euch weitere Themen interessieren, schaut auch gerne auf Skillbyte Slash Blog vorbei. Max Es war eine Freude heute mit dir über Erfolg sprechen zu dürfen.

Danke!

Moritz hat mir auch wieder viel Spaß gemacht an der Stelle.

Was? Gut, die einen schönen Abend.

Danke gleichfalls.