Folge 53: Terraform

Klicken Sie auf den unteren Button, um den Inhalt von podcasters.spotify.com zu laden.

Inhalt laden

In dieser Folge unterhalten wir uns mit dem Automatisierungsexperten Helge Zimpel über Terraform.
Was ist es, wofür wird es verwendet, und wie fügt es sich in den weiteren Zoo von DevOps Werkzeugen ein?

In dieser Episode des Podcasts „DevOps – auf die Ohren und ins Hirn“ sprechen die Moderatoren Luca Ingianni und Dierk Söllner mit Helge Zimpel, einem erfahrenen DevOps-Automatisierungsexperten. Sie diskutieren detailliert über Terraform, ein Tool für Infrastructure as Code, seine Anwendung in verschiedenen IT-Umgebungen, dessen Vorteile wie Dokumentation und Reproduzierbarkeit, und wie es sich von anderen Tools wie Docker und Ansible unterscheidet. Helge betont auch die Bedeutung von Terraform in Bezug auf die DevOps-Kultur und agile Prozesse sowie die Herausforderungen und Vorteile der Implementierung in Unternehmen verschiedener Größen.

Inhalt

  • Einführung und Vorstellung von Helge Zimpel
  • Grundkonzept und Vorteile von Terraform
  • Unterschiede zwischen Terraform und anderen Tools wie Docker und Ansible
  • Anwendungsbereiche und Grenzen von Terraform
  • Bedeutung von Terraform im Kontext von DevOps und agilem Arbeiten
  • Praktische Tipps und Best Practices zur Implementierung von Terraform
  • Helge Zimpels berufliche Tätigkeit und Angebot auf seiner Webseite

Shownotes:

Das Thema der Folge: Terraform
Die angesprochene Testframework für Terraform: Terratest
Helges Webseite: kontainer.sh

Transkript (automatisiert erstellt, wer Fehler findet darf sie behalten)

DevOps – auf die Ohren und ins Hirn
Ein Podcast rund um DevOps
Von Luca Ingianni und Dirk Söllner
Hallo und herzlich willkommen zu einer neuen Folge des Podcasts DevOps – auf die Ohren und ins Hirn.
Gestaltet und produziert von Luca Ingianni, Dierk Söllner und Falco Werner.
Wir sind DevOps-Trainer und Coaches mit langjähriger Erfahrung.
DevOps umfasst für uns kulturelle, organisatorische und technische Aspekte.
Und heute kommen wir zu einem technischen Aspekt.
Zu Gast haben wir Helge Zimpel.
Und ich würde sagen, bevor ich jetzt lange dich vorstelle, Helge, übernimm du es doch selber.
Bitteschön.
Ja, ich bin der Helge. Ich bin Experte für DevOps-Automatisierung
und begleite meine Kunden auf dem Weg zu weniger Routinearbeit als Entwickler.
Und mit meiner langen Erfahrung als Entwickler unterstütze ich bei der Einführung agiler Vorgehensmodelle,
bei der Ausschöpfung von Automatisierungspotenzialen im Entwicklungsprozess
und bringe meine Erfahrung aus vielen größeren Softwareprojekten dort ein, aus der Praxis.
Super. Das ist ganz interessant, weil ich bin ja nicht so der Technik-Freak.
Ich kann zwar ein bisschen was zu Technik erklären, aber ich glaube,
in den meisten Fällen gibt es auch in meinen Trainings,
sehr viel mehr Leute, die da vielleicht an einigen Stellen tiefer drin sind.
Insofern werde ich wahrscheinlich heute auch noch ein bisschen was lernen.
Luca, das heißt, du übernimmst den Experten-Part auf der Frage-Seite
und ich übernehme den Part mit den dummen Fragen.
Ach je, aber ich wollte eigentlich auch gerne die dummen Fragen stellen.
Ja gut, okay.
Dann müssen wir das beide machen.
Gut, wir haben uns ja vorgenommen, heute zu sprechen über das Thema Terraform.
Was ist denn das eigentlich, Helge?
Also die Idee hinter Terraform ist Infrastructure as Code.
Das ist die Idee, Infrastruktur ja im Grunde auch zu programmieren,
in Form einer Programmiersprache seine Infrastruktur zu definieren.
Und das, was man sonst klassischerweise per Hand macht oder auf der Kommandozeile
bei der Einrichtung von Servern, bei der Installation von Backdingen
oder wenn man sich durch eine Oberfläche klickt, bei Amazon Cloud gibt es hier eine Web-Oberfläche,
wo ich mir auch die ganzen Dinge über eine Oberfläche einrichten kann,
Server aufsetzen kann und alle möglichen Dinge hinterlegen kann.
Und bei Terraform ist die Idee, das Ganze auch in Form von Code zu hinterlegen,
hat zum einen den schönen Seiteneffekt, dass auch alles gleich dokumentiert ist
und das Wissen nicht verloren geht und dass man es auch reproduzieren kann
und wiederverwenden kann.
Super, da haben wir ja gleich mal zwei Vorteile.
Reproduktion und Dokumentation.
Das sind ja zwei Punkte, die, wie ich finde, auch für einen normalen Administrator
eigentlich von Interesse sein sollten, weil IT-Experten und Dokumentation,
das sind ja so zwei Welten, die aufeinandertreffen.
Wenn ich mal ein paar so Klischees bemühe, gibt es noch ein paar Punkte,
die du erklären würdest zu Terraform, was noch so ein paar wichtige Highlights sind?
Also erstmal ist die Idee, dass Terraform deklarativ arbeitet.
Das heißt, ich beschreibe im Grunde einen Sollzustand meiner Infrastruktur.
Wie soll die Infrastruktur aussehen?
Das heißt jetzt nicht nur irgendwelche Server, sondern kann in einer Cloud-Umgebung auch bedeuten.
Datenbanken kann heißen Benutzerrechte und Rollen oder verschiedene weitere Services,
die innerhalb der Infrastruktur genutzt werden.
Man definiert halt, wie die einzelnen Komponenten funktionieren.
Und dann kann man in Terraform erstmal das Ganze durchspielen.
Das gibt so einen Befehl auf der Kommandozeile Terraform-Plan,
wo man erstmal ausprobieren kann, stimmt das Setup und was würde passieren,
wenn ich das jetzt ausführen würde auf der Infrastruktur.
Und dann kann man das Ganze erstmalig ausführen.
Okay, du hast eben zu Anfang deiner Antwort gesagt, deklarativ.
Gibt es noch irgendetwas, gibt es andere Ansätze, die quasi,
ein Gegenteil oder eine andere Abwandlung von deklarativ sind?
Ja, es gibt auch Ansätze, die im Grunde wie,
die entweder sogar auf klassischen Programmiersprachen beruhen.
Das heißt, das sind dann Bibliotheken für Sprachen wie Python oder Java.
Es gibt natürlich auch spezialisierte Tools,
um beispielsweise ein Kubernetes-Cluster aufzusetzen oder so etwas.
Und bei Terraform ist halt die Idee dann auch noch,
einen Soll- und Ist-Zustand immer wieder abzugleichen.
Das heißt, wenn ich dann Änderungen vornehme,
dann erkennt das Terraform, wie unterscheidet sich denn jetzt meine Infrastruktur,
die gerade läuft, mit dem, was ich, mit meinem Zielzustand,
und gleicht dann das gegeneinander ab und führt dann die notwendigen Änderungen aus
und rollt sie aus.
Ja, okay.
Ich fand es sehr interessant, weil du sagtest, man kann das durchspielen.
Und dann, ich dachte, der Befehl würde heißen Terraform Play.
Aber okay, Plan macht natürlich Sinn, auch wenn man es wirklich mal so durchspielen will,
Plan und Ist vergleichen würde.
Okay.
Gibt es noch ein paar Punkte, die du,
die du zu Terraform sagen würdest, die wir auch nutzen können,
um Infrastructure as Code Leuten wie mir zu erklären,
also die eigentlich wenig technisches Gefühl haben
und die das quasi einfach lernen können von Leuten wie dir?
Ja, also zunächst mal gibt es eine Programmiersprache,
in der man, oder eine Konfigurationssprache, besser gesagt,
in der man die Infrastruktur beschreibt.
Das, die nennt sich HCL, HashiCore Configuration Language.
Terraform speichert lokal den Zustand der Infrastruktur ab,
um hinterher diesen Abgleich zu machen zwischen dem,
wie soll denn mein neuer Soll-Zustand sein und wie ist der derzeitige Ist-Zustand?
Und was Terraform auch macht, ist die Abhängigkeiten aufzulösen.
Und das kennt man auch so aus dem Linux-Umfeld von Paketmanagern,
wo dann der Paketmanager weiß, das Paket B hängt von Paket A ab
und das muss ich, demzufolge muss ich B zuerst installieren.
Und so funktioniert das hier auch, wenn ich jetzt abhängige Ressourcen habe,
eine, ein Festplatten-Volume und ich möchte eine Maschine aufsetzen,
mit der dieses Volume verknüpft ist,
dann wird das in der richtigen Reihenfolge ausgerollt,
sodass es dann auch funktioniert.
Und darum kümmert sich Terraform automatisch, dass das klappt.
Oder meckert zum Beispiel auch, wenn man jetzt so genannte Zirkelbezüge hat,
also wenn A von B abhängt, B von C und dann wiederum der Kreis geschlossen wird hin zu A.
Okay, also ich kenne die Zirkelbezüge nur von Excel,
aber ich glaube, dass sie in der,
in der Terraform-Umgebung wahrscheinlich etwas kritischer sind als, als in Excel.
Gut, wobei, wenn ich einen Controller fragen würde,
der würde wahrscheinlich sagen, in Excel könnte das auch kritischer sein.
Ebenso, oder so gehst du baden, ne?
Ja, stimmt. Okay, also Zirkelbezüge werden aufgelöst.
Ähm, warte mal ein Stück zurück.
Für mich, du hast ja gesagt, ähm, ich definiere einen Sollzustand
und Terraform gleicht immer ab, ähm, quasi von einem Ist zum Sollzustand.
Jetzt hätte ich gesagt, äh, ich will den Sollzustand sofort haben.
Warum muss da noch was abgeglichen werden?
Also, man benutzt Terraform ja nicht nur initial,
um die Infrastruktur aufzusetzen beim ersten Mal,
sondern auch, um sie weiter zu pflegen.
Und wenn ich dann Änderungen vornehme,
dann werden entsprechend nur diese Änderungen ausgerollt
und die Komponenten der Infrastruktur abgeändert,
an denen ich Modifikationen vornehme.
In einer Cloud-Umgebung kann das zum Beispiel auch heißen,
eine Instanz mit mehr Speicher oder mit größerer Festplatte anderer CPU.
Was dann sogar im laufenden Betrieb, ja, innerhalb von wenigen Sekunden umsetzbar ist,
dass ich sage, ich möchte meine Festplatte beibehalten,
möchte jetzt aber auf eine Instanz mit mehr Speicher oder besserer CPU wechseln.
Ja, ähm, jetzt bin ich doch neugierig, weil das klingt ja dann so,
als ob Terraform immer noch dieses Modell zugrunde legt,
dass es eigentlich langlebige Ressourcen gibt.
Irgendwie langlebige Server, die jetzt, ich sag jetzt mal, monatelang laufen
und du änderst halt dann und wann mal ihre Konfigurationen, aus welchen Gründen auch immer.
Ist das nicht ein Modell, das sich so ein bisschen mittlerweile überholt hat,
wenn ich an unveränderliche Infrastruktur denke,
wenn ich an die Risiken von Konfigurationsdrift denke oder sowas?
Jetzt mal ganz blöd gefragt, ist Terraform dann nicht jetzt schon überholt?
Also es gibt ja zum einen den Aspekt, den ich gerade genannt habe,
ich möchte mein Setup im Code festhalten,
möchte es in Form des Codes dokumentieren und weiterentwickeln.
Es geht natürlich mit Cloud-Umgebungen auch immer mehr dahin,
dass man gar nicht einen Server langlebig,
betreibt, sondern eher sagt, wenn dort etwas zum Beispiel nicht funktioniert,
ich habe ihn ja definiert in Form eines Terraform Setups,
kann ihn leicht produzieren, dann kann ich auch sagen, ich schmeiße so eine Instanz weg
und erzeuge sie einfach neu und tausche sie gegen die alte aus.
Oder wenn man jetzt an Cluster-Umgebungen denkt, Docker, Container, Kubernetes,
dass man einfach sagt, ich habe eine Vielzahl immer wieder ähnlicher Umgebungen,
versuche die auch möglichst simpel zu halten, auf ein Basis-Setup zu beschränken,
versuche dort auch gar keine Software zu installieren,
sondern das alles in Form von Containern zu betreiben,
dann kann es dahin gehen, dass ich halt einfach eine Vielzahl in meinem Cluster
von identischen Containern habe.
Oder ein weiterer Aspekt wären jetzt noch so etwas wie verschiedene Umgebungen
für Test, für Staging, für Entwicklung, für Produktion,
wo man einfach die Änderungen durch verschiedene Instanzen hinweg schleust
im Rahmen des Entwicklungsprozesses, vielleicht dann auch verknüpft
mit der Versionsverwaltung und entsprechenden Feature-Branches
oder Branchen.
Interventionsverwaltung, die ich dann ausrolle auf Kopien des jeweiligen Setups.
Ich denke so an meine Urzeiten in der IT zurück, ist ein bisschen länger her
und damals war Krawatte tragen noch wichtig.
Gerade wenn man als Berater zum Kunden ging, sollte man eine Krawatte anhaben.
Das ist natürlich für die Berater, die sich die Hände nicht schmutzig machen,
kein Problem gewesen.
Aber für die Berater, die Server aufgesetzt haben,
die vielleicht auch mal unter den Tisch krabbeln mussten,
war ganz blöd gesprochen.
Da sah das manchmal ein bisschen komisch aus.
Das heißt, das ist ja, wenn man es mal ganz platt formuliert,
ein schöner Vorteil.
Der Berater, der einen Server aufsetzt, der kann sich jetzt wirklich
mit Krawatte ins Büro setzen, wird er wahrscheinlich nicht machen.
Gibt es noch ein paar andere Punkte, die für einen Administrator,
sag ich mal, von Vorteil sind, wenn er über Infrastructure as Code arbeitet?
Denn ich hätte in den ersten Schritt, hätte ich jetzt sozusagen Angst,
dass mein Job in Gefahr ist.
Richtig.
Es gibt natürlich diese Administratoren, die versuchen,
sich unersetzlich zu machen und den Server über Jahre hinweg pflegen,
vielleicht sogar Änderungen vornehmen, den Kernel patchen,
irgendwo Dinge einbauen, die hinterher keiner mehr nachvollziehen kann
und wenn es diesen Entwickler nicht mehr gibt, reproduzieren kann.
Generell, wenn man jetzt an unser Thema DevOps denkt,
geht es ja auch darum, dass der Administrator und die Rolle des Entwicklers
zusammenwachsen und miteinander harmonisch zusammenspielen in einem Prozess.
Und beim Thema DevOps hat man ja auch die Anforderung,
in immer kürzeren Zyklen Releases auszurollen oder Entwickler möchten nicht.
In vielen Unternehmen ist es noch so, da muss ich irgendwie einen Antrag stellen
auf einem Server per Papier oder muss eine virtuelle Maschine beantragen
und dann muss ich begründen, warum brauche ich sie und später kriege ich sie.
Und mit dem ganzen Thema Cloud und solchen, die im Grunde self-managed sind,
wo ich selber mir Dinge aufsetzen kann,
wachsen diese Rollen des Entwicklers und des Admin immer mehr zusammen,
weil ja auch die Infrastruktur ja dort dokumentiert ist.
Vielleicht nimmt der Entwickler sogar dort Modifikationen vor
oder testet sie in seiner lokalen Umgebung auf seinem Rechner,
probiert dort das Setup auch schon aus und rollt es dann auf die spätere Infrastruktur aus.
Ja, du hast ein Stichwort gegeben und hast mich damit implizit daran erinnert,
dass ich ja die Eingangsfrage vergessen habe.
Wir fragen unsere Gäste ja immer, was verstehen sie unter DevOps?
Und insofern, da du jetzt das Thema DevOps angesprochen hast und ja,
ich würde sagen, wir holen die Frage einfach nach.
Helge, was verstehst du, wie würdest du DevOps beschreiben oder definieren?
Weil ich glaube, ein paar Punkte hast du ja eben ja auch schon gesagt.
Aber insofern, wie würdest du DevOps definieren?
Also es gibt ja diese klassische DevOps-Grafik, diesen DevOps-Seigel,
der aussieht wie so ein Endlichzeichen oder eine liegende Acht,
wo es zum einen die Schritte drin sind, die in der Entwicklung vorgenommen werden.
Das geht von der Spezifikation los, wo man noch gar nicht programmiert,
erst mal seine Anforderungen zu managen mit Tools wie Jira, Confluence
und was es dazu gibt mit Ticketsystemen, die Anforderungen zu beschreiben.
Dann geht es irgendwann in die Entwicklung.
Dann gibt es so Themen wie automatisiertes Testen.
Dann gibt es Themen, das ganze Rollen auf die Infrastruktur,
wo dann CI, CD-Tools für Continuous Integration, Continuous Delivery zum Tragen kommen,
damit dieses ganze Ausrollen einer Software eines neuen Releases automatisiert wird.
Und damit kommen wir dann in den Bereich rein, der klassischerweise vom Admin betrieben wird,
nämlich dann die Infrastruktur auch zu überwachen, zu monitoren,
also um den Betrieb stabil zu halten, Ausfälle automatisch zu erkennen,
Fehler vielleicht irgendwie automatisch zu beheben, wenn eine Instanz nicht mehr funktioniert,
sie automatisch neu zu starten.
Und natürlich dann auch irgendwie sowas wie Dashboards, Monitoring Tools.
Ja, okay. Das waren jetzt alles ziemlich viele technische Themen.
Das heißt, wenn ich das richtig interpretiere, ist für dich DevOps
zu einem sehr großen Anteil von Technik betrieben oder durch Technik umgesetzt.
Also ich komme jetzt aus der technischen Ecke, darum habe ich es vielleicht jetzt so formuliert.
Ich sehe aber auch den Aspekt, ja einmal das Zusammenarbeiten,
die enge Zusammenarbeit zwischen Administration und Entwicklung,
um halt Betrieb und Entwicklung näher aneinander zu bringen und sehe auch dort die Vorteile
in einfach kurzen Release-Zyklen, Automatisierung von Prozessen,
die dann in Projekten, wo ich sehr kurze Zyklen habe und immer wieder Releases bereitstellen wollen,
einfach extrem weiterhelfen. Ich erinnere mich noch an alte Zeiten,
wo ich bei einem ERP-Hersteller gearbeitet habe.
Da war es noch üblich, dass alle ein, zwei Jahre ein Release ausgerollt wurde.
Das ist heute gar nicht mehr denkbar.
Da werden Zwischenreleases gemacht und wenn es Richtung Cloud geht,
ja dann ist es ja eigentlich gang und gäbe, dass man auch von den Releases
gar nichts mehr mitkriegt, sondern eigentlich, wie man es von Plattformen wie Facebook singt,
das System einfach immer kontinuierlich weiterentwickelt wird oder in kurzen Zyklen entwickelt wird.
Ja, aber wenn wir jetzt gerade einen Techniker, ich sage jetzt mal Techniker, hier an Bord haben im Podcast,
was erlebst du denn, wenn Entwickler und Administratoren zusammenarbeiten?
Der eine muss auf den anderen zugehen. Was sind denn deine Erfahrungen?
Wie reagieren denn diese Experten? Weil dann menschelt das ja auch.
Ja, das ist dann schon natürlich erstmal, jeder sieht dann irgendwo sein Hoheitsgebiet bedroht
oder sagt, das zählt ja eigentlich gar nicht zu meinen Aufgaben, das jetzt auch noch zu tun und mich damit befassen zu müssen.
Da ist, glaube ich, einfach eine gewisse Phase erforderlich, um das Team dafür zu begeistern,
diese Bedenken auszuräumen einfach und die Vorteile dann zu sehen.
Also das erlebe ich auch in meinen Projekten. Das gilt auch für andere Themen wie Testautomatisierung,
dort den Nutzen und die Vorteile zu sehen.
Okay, und sie auch vielleicht gemeinsam zu erarbeiten, weil du kommst ja mit der Erfahrung, dass du quasi beide Seiten kennst,
dass du beide Seiten ja auch ansprichst.
Und kannst dann auch halt über die technische Ebene, über die technischen Aspekte die Vorteile aufsehen,
die du dir auch jetzt teilweise schon im Podcast hier aufgezählt hast.
Genau. Was zum Beispiel auch noch so Punkte sind, wenn man Entwicklung outsourced,
nearshoring betreibt oder offshoring in Indien oder sonst wo entwickeln lässt,
dass oft die Auftraggeber, wenn die jetzt eher managementlastig sind, gar nicht darauf achten,
dass sie auch den Code zur Verfügung haben, dass der Prozess automatisiert ist,
falls man mal mit dieser Einheit dann nicht mehr zusammenarbeiten möchte,
dass man wirklich über alle Dinge verfügt.
Und das fördert dieser Ansatz hier natürlich auch noch, wenn man alles in der Versionsverwaltung hat
und in der Lage ist, das Setup wieder zu reproduzieren, dass man dann diese Abhängigkeit auch zu den externen Dienstleistern hin verringert.
Ja, das leuchtet mir sehr ein, auch insbesondere dann im Zusammenspiel mit Continuous Integration,
dass man sagt, ich weise ständig nach, dass einerseits mein Produkt noch geht
und dass es zweitens auch immer noch zu meiner Plattform passt, zu meiner Infrastruktur passt,
die ich dann zum Beispiel mithilfe von Terraform definiert habe.
Genau. Und da spielen dann natürlich auch automatisierte Tests mit rein, die noch vor dem Deployment ausgeführt werden,
in Form von Unit-Tests oder Integrationstests, um einfach sicherzustellen, dass auch noch alles weiterhin funktioniert,
was dort so im Git eingecheckt ist, nicht Dinge fehlen.
Frage von mir nochmal, wenn wir jetzt wieder so ein bisschen auf das Thema Infrastruktur denken,
also, wie kann man mit dem AWS Code zurückkommen?
Wir reden ja unter anderem, oder wir reden ja über das Produkt Terraform.
Wie kann ich mir das vorstellen? Ich kenne so Produkte wie Docker, Ansible, Kubernetes, hast du ja auch schon eben angesprochen.
Wie muss ich mir da Terraform quasi gedanklich, wie muss ich das einsortieren?
Übernimmt das die, ersetzt das Docker beispielsweise? Also, wie muss ich mir das vorstellen bei Terraform?
Bei Terraform ist, oder bei Terraform liegt der Schwerpunkt drauf, muss man sagen, die Infrastruktur bereitzustellen
und weniger die Provisionierung von Software vorzunehmen, während Ansible versucht, beides abzudecken.
Da kann ich ja, kann ich auch Infrastrukturen aufsetzen oder mit Tools wie Chef oder so etwas.
Aber Terraform versucht eigentlich nicht, Software zu provisionieren, Pakete zu installieren, dann auf dem System oder Docker-Container zu installieren.
Das sind dann klassischerweise nachgelagerte Schritte.
Bei Terraform geht es erstmal darum, wenn ich eine Cloud-Umgebung nutze, zu definieren,
was brauche ich für Instanzen, was brauche ich für Volumes im Bereich Speicher,
was brauche ich für Rollen und Berechtigungen für User-Zugänge per SSH bereitzustellen.
Vielleicht gemanagte Services der Cloud-Anbieter mit einzubinden, wie gemanagte Datenbank-Instanzen
oder irgendwelche weiteren Services wie Elasticsearch.
Oder was es sonst noch so geben könnte.
Und nachgelagert auf dieser Infrastruktur ist dann zu sehen, das auf der Maschine Software zu installieren.
Sei es jetzt klassisch in Form von Paketen, die ich dort installiere oder in Form von Docker-Containern.
Um da nochmal ein bisschen nachzufragen und das vielleicht noch ein bisschen schärfer zu konturieren.
Bis jetzt hast du das ja immer so im Kontext von Maschinen erzählt.
Aber wäre dann Terraform zum Beispiel auch geeignet, um, ich sage jetzt mal, virtuelle Netzwerke aufzuspannen zwischen mehreren virtuellen Maschinen?
Oder ist das dann auch schon wieder etwas, was, sagen wir mal, nicht mehr zu Terraforms Spezialitäten gehört?
Ja, doch. Das gehört dort noch alles dazu.
Und je nach Cloud-Anbieter, vielleicht nochmal um auszuholen, bei Terraform gibt es sogenannte Provider.
Das ist sozusagen die Schnittstelle zu einem bestimmten Cloud-Anbieter oder zu einer bestimmten Virtualisierungssoftware.
Also zu klassischerweise Amazon, Azure von Microsoft, Google Cloud oder auch kleinere Anbieter wie Hetzner.
So etwas oder auch Virtualisierungsumgebungen, die man dort anbindet.
Und bei Amazon oder Azure oder Google Cloud hat man dort eine sehr große Bandbreite an Services, die man dort einbinden kann.
Wo dann auch wirklich alle weiteren Bereiche mit abgedeckt sind.
Und um zur Frage zurückzukommen, da zählt dann auch das Thema Netzwerk dazu.
Da zählt dann auch das Thema Firewall-Konfiguration dazu.
Wie möchte ich die…
Man hat vielleicht auch verschiedene Netzwerke, die man aufbauen möchte.
Wenn ich jetzt ein Cluster betreibe, möchte ich den beim Cloud-Anbieter zum Beispiel vielleicht in verschiedenen Rechenzentren,
in verschiedenen Regionen des Rechenzentrums betreiben, um Ausfallsicherheit zu gewährleisten, wenn jetzt ein Knoten dort nicht verfügbar ist.
Und dieses ganze Setup, wo soll das Ganze liegen, wie ist das Netzwerk technisch miteinander verknüpft, kann man dort auch definieren.
Okay, das heißt, vielleicht kann man es dann tatsächlich so zusammenfassen, dass Terraform, so wie du es ja eigentlich schon gesagt hast,
seine Stärken darin hat, salopp gesagt, das Blech im Keller zu verwalten, auch wenn es virtuelles Blech sein mag.
Und die Sachen, die obendrauf kommen, in Form von Paketen, in Form von dann vielleicht Applikationen oder sowas,
das ließe sich dann vielleicht sogar besser abbilden mit Hilfe von beispielsweise Docker oder mit Hilfe von beispielsweise Ansible oder sowas.
Ganz genau, darum würde ich auch sagen, es steht nicht in Konkurrenz, sondern es ergänzt sich eigentlich sehr gut.
Und was auch noch ein Vorteil ist, es steht ja auch Terraform in Konkurrenz.
In Konkurrenz zu den Tools der jeweiligen Cloud-Anbieter.
Und Terraform verfolgt halt den Ansatz, Multicloud fähig zu sein.
Und was ja die Tools der Cloud-Anbieter naturgemäß nicht sind, weil dort die Anbieter versuchen natürlich eine Bindung zu schaffen,
ein Login zu schaffen an die jeweilige Cloud-Plattform.
Wenn man mit Tools wie Terraform arbeitet, für die Infrastruktur und mit Docker, genau.
Das haben wir vorhin schon gesagt, die Administratoren haben, wenn sie sich dem Thema öffnen,
einen Vorteil, sie können vor der Konsole sitzen bleiben, sie müssen nicht unter den Tisch krabbeln.
Sie können sich ganz normal anziehen, müssen keine Krawatte oder können die Krawatte anziehen.
Du hast eben gesagt, ich werde unabhängiger von verschiedenen Cloud-Anbietern.
Ich kann das im Prinzip auch nutzen, um mit verschiedenen Cloud-Anbietern zu arbeiten.
Gibt es noch ein paar andere Punkte, die quasi Terraform von Vorteil sind, die wir auch insgesamt auf Infrastructure as Code ausdehnen können?
Also ein Punkt ist natürlich so verschiedene Umgebungen, was ich vorhin schon mal ausgeführt habe,
wenn ich Entwicklungsumgebung, Staging, Produktion habe, immer wieder ähnliche Setups ausrollen will.
Oder ein Thema wäre jetzt wiederholte Verwendung ähnlicher Setups, wenn man jetzt irgendwie an Web-Agenturen oder so etwas denkt,
die immer wieder Content-Management-Systeme in Kombination mit anderen Komponenten einer bestimmten Datenbank,
vielleicht Suchmaschinen wie Elasticsearch verwenden.
Dann kann man halt so ein ganzes Setup, was ich immer wiederholt bei Kunden verwende, auch automatisiert duplizieren und dann erneut ausrollen.
Dann generell natürlich Thema Testumgebungen aufsetzen, einen Server einfach mal so und noch mal so aufsetzen, wie er woanders läuft.
Okay. Wir hatten ja den Punkt Dokumentation als Vorteil.
Jetzt würde ich gerne noch mal so ein bisschen in deine praktischen Erfahrungen einsteigen, weil du ja gesagt hast,
ich habe quasi Dokumentation in Form von Code. In deinen Projekten, ist das wirklich eine Anforderung deiner Auftraggeber,
dass man das wirklich umsetzen kann? Sehen die das auch als Vorteil oder ist das einfach nur so ein Marketing-Gag,
zu sagen, hey, wir müssen nicht mehr dokumentieren. Wir haben die Dokumentation in Form von Code.
Also ist das wirklich aus deiner Erfahrung heraus ein wirklich genutzter Vorteil?
Also erstmal hängt es natürlich vom…
sage ich mal, Reifegrad und Wissensstand der Kunden ab, ob man erst diese Vorteile erläutern muss
oder ob sie schon sagen, was ich nicht… Startups sind ja vielleicht eher technikaffin, wo sie dann schon sagen,
wir wollen so etwas, wir wollen Kubernetes, wir wollen Infrastructure as Code, wir wollen das in einer Cloud-Infrastruktur betreiben.
Und andere Softwareanbieter, die schon sehr lange am Markt sind, aus alten Zeiten gewachsen sind,
die sehen dann vielleicht diese Vorteile noch nicht.
Die dann aber, wenn es auch darum geht, Änderungen durchzuführen, Infrastruktur vielleicht auch zu konsolidieren auf eine Cloud-Plattform
oder generell die Migration erstmal in die Cloud zu vollziehen.
Und dann spielt es dort natürlich dann seine Vorteile aus, die ich eben auch schon genannt hatte,
dass ich dann eben sehr schnell Umgebungen reproduzieren kann, wiederholt aufsetzen kann.
Und dort…
Wenn es Probleme gibt, natürlich auch irgendwie viel schneller reagieren kann.
Jetzt frage ich mich gerade eins.
Also ich meine, wenn ich auf der grünen Wiese anfange, wenn ich zum Beispiel ein neues Startup habe oder sowas,
dann leuchtet mir das sehr ein, dass man vielleicht direkt sagt, gut, wir machen es gleich von Anfang an richtig und wir führen Terraform ein.
Aber wie gehe ich denn jetzt vor in einer gewachsenen Infrastruktur mit einem Unternehmen, das schon Jahrzehnte alt ist,
das natürlich auch schon seit was weiß ich wann irgendwie verschiedenste Jahre ist.
Und das ganze Produkt im Rechenzentrum oder vielleicht sogar mittlerweile in der Cloud hat.
Wie kriege ich denn da mit Terraform sinnvollerweise den Fuß in die Tür?
Was es gibt in Terraform ist die Möglichkeit auch, wenn ich schon eine Umgebung in der Cloud habe,
auch dort entsprechend diesen Ist-Zustand, wie er in der Cloud ist, dann auch zu importieren in Terraform.
Das heißt, ich kann meine Ressourcen, die ich schon bei Amazon angelegt habe, in ein Terraform-Setup importieren
und diesen Bezug dann erstmal herstellen zwischen meiner lokalen Definition der Infrastruktur
und kann sagen, diese Instanz oder diese Datenbank, die gibt es schon,
die ist unter diesem Namen bei Amazon angelegt, unter dieser ID angelegt.
Und dann kann ich auch ein bestehendes Setup in ein Terraform-Setup überführen auf diesem Weg.
Der andere Ansatz wäre halt, ich soll sagen, man zieht in die Cloud um oder man stellt sein Setup um.
Dann muss ich es ja neu aufsetzen und dann habe ich aber da natürlich auch den Vorteil,
dass ich dann anfange, mein Setup auch nachzudokumentieren und zu automatisieren.
Ja, jetzt kommt vielleicht eine ganz blöde Frage.
Aber wenn ich als Manager, nee, nicht als Manager, wenn ich als BWLer höre, ich habe eine Importfunktion,
könnte ich nicht auch oder macht es Sinn, wenn Terraform sich quasi meine Infrastruktur,
meine physische Infrastruktur automatisch anguckt und das genauso quasi importiert,
zumindestens die Beschreibung? Geht das? Macht das Sinn oder ist das eine abstruse Idee?
Also die komplette Beschreibung erzeugen geht nicht. Bei dem Import geht es eher darum, diesen Bezug herzustellen,
zu sagen, ich habe dort eine Instanz, die gibt es schon und jetzt definiere ich sie in dieser Konfigurationssprache
und sage dann, diese Ressource, die existiert schon und stellt dort die Verknüpfung her,
dieses ganze Setup jetzt automatisch zu generieren.
Aus einer Infrastruktur. Das ist mit Terraform so nicht möglich.
Ist denn die Frage dumm oder wäre das eine coole Sache?
Das wäre vielleicht initial eine interessante Sache.
Man müsste dann aber anfangen, auch Dinge zu modularisieren, zu parametrisieren.
Gerade wenn ich Setups wiederverwenden will, dann sollte man auch schauen, dass man diese Setups auch wirklich parametrisiert hat,
sprich in verschiedenen Umgebungen.
Mit einer gewissen Variation auch wiederverwenden zu können und da bietet Terraform dann Mechanismen wie Module zu bilden
oder gewisse Einstellungen zu parametrisieren, den Namen der Instanz, die IP-Adresse der Instanz, wie viel Speicher hat sie, welche CPU.
Also so gesehen ist es wahrscheinlich dann wirklich besser, dann eben manuell anzufangen und das Ganze manuell quasi nachzubilden,
um sich nicht, ich sage mal, gleich mit dem Start alles zu verbauen.
Also dann habe ich so verstanden, es macht Sinn, dass man dann sich einfach hinsetzt und das manuell erfasst, um Terraform auch richtig zu konfigurieren.
Ja, so ein bisschen so wie mit Tools, die auch es gibt, um eine Programmiersprache vielleicht in irgendwie eine neuere Programmiersprache zu überführen,
wo ich dann aber im Grunde natürlich auch alten Code von Programmiersprache A in Code der Programmiersprache B umwandle und dann eigentlich auch anfangen müsste zu refactoren, zu überarbeiten.
Ja, okay.
Wenn nur das alte Gewachsene dann überführt hätte in etwas Neues.
Ja, ich denke, der Vorteil von so einer Importfunktion besteht halt darin, dass man, man weiß zwar nicht genau, was drin ist, aber man hat immerhin mal einen bekannten und benannten Stand
und kann sich auf den beziehen, kann vielleicht auch wieder sich auf den zurück retten, wenn man irgendwie versucht hat, vorwärts zu schreiten und festgestellt hat, die Richtung war irgendwie die verkehrte.
Aber eine Importfunktion, die dann wirklich ein System auseinanderdröselt und das dann in eine,
und das dann versucht, den tatsächlichen Code umzumünzen, ich glaube, das läuft dann ein bisschen so wie mit Hieroglyphen oder sowas.
Du siehst dann da irgendwie so eine Säule und da stehen dann halt irgendwie Zeichen drauf und weißt schon, naja, das ist irgendwie ein Vogel und das da drüben ist ein, was haben die denn noch, die Eulen und sowas.
Aber du hast keine Ahnung, was wir eigentlich damit sagen wollten. Ich glaube, das wäre das, was dann passieren würde.
Okay. Ich habe ja gesagt, ich stelle die doofen Fragen und lerne heute auch was. Okay.
Ich mache dann die doofen Analogien, können wir uns da drauf einigen.
Okay, gut, okay. Du hast eben schon so ein bisschen…
darauf angesprochen oder wir sind ein bisschen in die Richtung gegangen, wo Terraform zum Einsatz kommt.
Hast du es schon auch mal erlebt, dass quasi in deinen Projekten Terraform zum Einsatz kommen sollte, wo du gesagt hast, das macht gar keinen Sinn?
Also wenn ein stabiles Setup da ist, wenn da eine gewachsene Infrastruktur da ist, die läuft, die funktioniert und die auch vielleicht sogar schnell auf Änderungen reagieren kann,
ist dir so etwas schon mal passiert, dass du gesagt hast oder hättest, Mensch, eigentlich müssen wir das gar nicht in Terraform überführen?
Ja, die Fälle gibt es durchaus und das ist halt gerade, wenn ich sehr gewachsene, sehr stabile Umgebungen habe, wenn es jetzt nur um den Betrieb einer Software geht
oder vielleicht auch um Software, die man gar nicht selber entwickelt, die lediglich auf diesem Server betrieben wird, könnte jetzt sein ein Content-Management-System
oder könnte sein ein webbasiertes ERP-System oder ein…
CRM-System, wo es einfach nur darum geht, diese Software zu betreiben und dort vielleicht vorhandene Update-Mechanismen der Hersteller zu benutzen, dann macht so ein Setup weniger Sinn.
Wenn es aber darum geht, dass ich wirklich an Software entwickle, dann spielt Terraform eigentlich immer Vorteile aus, wenn es nicht nur rein um den Betrieb geht,
sondern um die Verknüpfung mit Entwicklung und dort einfach schnell und agil zu werden.
Da werde ich jetzt immer an dich denken, Helge, wenn ich in unserem Phoenix-Projekt…
in unserer DevOps-Simulation, da gibt es so ein Fast-Deployment-Tool, was wir dann quasi spielen.
Das heißt, dann kommt dann der Chef und sagt, hey, ich war auf einer Messe und ich habe da so ein tolles Tool gesehen, das müssen wir unbedingt einführen.
Und da werde ich jetzt immer an dich denken, weil es gibt Teams, die verstehen das und dann gibt es Teams, die sind ganz überrascht, dass man ja auch Dinge automatisieren könnte.
Das heißt, da hat der Chef eigentlich den richtigen Riecher gehabt, aber wie gesagt, da werde ich jetzt immer an dich denken.
Jetzt haben wir gesagt oder ich habe eben so ein bisschen darauf abgezielt, was es bedeutet, wofür Terraform nicht so unbedingt seine Vorteile ausspielen sollte.
Gibt es noch ein paar andere Punkte, die man oder wo du sagen würdest, Mensch, die profitieren genau nicht von Terraform.
Wir haben ja davon gesprochen vorhin, es gibt Administratoren, die natürlich vielleicht ihre Server so wie so ein Haustier pflegen.
Also wenn was krank ist, dann versuchen sie das zu gesunden und so weiter.
Also gibt es noch andere Aspekte, noch andere Stakeholder, wie wir sie so gerne nennen, die eigentlich eher quasi gegen Terraform wären, weil sich für die etwas zum Negativen verändert?
Also es gibt natürlich zum einen Dinge, wo Terraform einfach eine Nummer zu groß wäre, wenn ein klassischer Mietserver auch ausreicht oder ein Webspace und man damit leben kann, dann wäre Terraform aus meiner Sicht einfach oversized.
Und es spielt natürlich seine Vorteile auch in Cloud-Umgebungen oder in virtualisierten Umgebungen.
Könnte jetzt auch die Private Cloud sein mit so etwas wie OpenStack, wo ich dann eine Cloud-Umgebung bei mir lokal betreibe.
Da spielt es seine Vorteile aus, wenn ich wirklich auch Maschinen über eine Cloud ähnlich oder über eine Virtualisierungsinfrastruktur dann auch schnell und automatisch aufsetzen kann.
Weil die Voraussetzung für Terraform hatte ich ja vorhin gesagt, ist dieser sogenannte Provider, den man so nennt.
Wenn man sich vorstellen kann, wie ein Treiber zu einer Infrastruktur und wenn diese Infrastruktur gar nicht dynamisch ist oder veränderbar ist, dann kann ich Terraform natürlich auch nicht nutzen.
Das bedeutet, und das liegt wahrscheinlich auch ein bisschen nahe, je größer meine Umgebung ist, desto wertvoller wird Terraform auch irgendwie.
Wegen der Maschine hier und der Maschine da. Lohnt sich die Mühe nicht? Höre ich das richtig?
Also ich habe es auch eingesetzt schon wirklich für einzelne Server.
Zum Beispiel meine Webseite.
Die habe ich ja auch betrieben auf einem Server bei Amazon, der mit Terraform aufgesetzt ist, wo ich dann das Ganze in Kombination mit Docker-Containern nutze.
Das heißt, ich habe dort mein, in dem Fall ist es ein WordPress, habe ich dann auch mit Docker virtualisiert und das ganze Setup automatisiert und betreibe das dort entsprechend.
Und da ist dann natürlich auch sehr einfach mal zu sagen, ich brauche jetzt eine größere Instanz, ich habe mehr Traffic auf meiner Webseite, meine CPU, mein Speicher reicht mir nicht mehr aus.
Dann kann ich dort im Betrieb diese Änderungen vornehmen.
Oder wenn es jetzt darum geht, ich bin mir bei einem neuen Release von WordPress unsicher, spielt das noch mit meinen ganzen Plugins zusammen?
Dann möchte ich mir vielleicht erst mal diese Instanz duplizieren, mir eine Testumgebung schaffen, dort alles nochmal auf, die Docker-Container dort dann nochmal aufsetzen und gucken, läuft dort alles?
Würde es funktionieren, wenn ich jetzt auf das nächste WordPress-Major-Release gehen würde?
Okay, wenn wir jetzt mal so ein bisschen nochmal überlegen.
Oder ich versuche ja trotzdem.
Zumindest in dem Podcast jetzt hier, wenn wir jetzt keinen Werbepodcast für Terraform machen, natürlich fällt das vielleicht quasi ab.
Wenn man jetzt mal überlegt, so eine Situation, eben ein, ich sage mal, ein normales und ein normales Unternehmen, eine handelsübliche Größe, die jetzt sagt, okay, wir möchten jetzt unsere Infrastruktur quasi as a Service, also wir möchten eine Infrastruktur as a Service bereitstellen wollen,
das mit Terraform in Code überführt.
Wie würde man das tun?
Also gibt es ein paar Vorgehensweisen, die du bei Terraform kennst, die du von Terraform her empfehlen würdest, die du auch gelernt hast, die man übertragen kann auf jedes andere Infrastructure-as-a-Code-Projekt?
Also erstmal würde ich als Empfehlung mitgeben, einfach zu starten, nicht jetzt von vornherein versuchen, alles zu parametrisieren, zu modularisieren, sondern sich erstmal heranzutasten, erstmal anfangen mit einem relativ einfachen Projekt.
Ja, genau.
Und dann ist es dann auch so, dass man sich mal anschaut, wo lohnt es sich zu parametrisieren, wo lohnt es sich, Module zu bilden, wo habe ich Wiederverwendbarkeit, ähnlich wie es auch in der Softwareentwicklung ist, wo man auch bei der Architektur Schritt für Schritt anfangen sollte und nicht von vornherein die nach der perfekten Architektur suchen sollte, die dann vielleicht hinterher gar nicht trägt.
Zweite wichtige Regel ist, keine Änderungen an dem Tool, an dem Infrastructure-as-a-Code-Tool vorbei.
Das heißt dann nicht auf dem Server.
Aber doch noch über die Oberfläche etwas umzustellen, weil es mal schnell gehen muss oder weil es so praktisch ist, die Oberfläche zu nutzen, weil dann könnte man in Probleme laufen, auch wenn der Zustand dann vielleicht noch dann wieder abgeglichen werden kann.
In manchen Fällen wäre es dann vielleicht aber nicht mehr möglich, weil dann irgendwie doch Bezüge verloren gehen und die Dokumentation natürlich verloren geht.
Da muss ich jetzt aber doch nochmal nachfragen, weil wenn jetzt die Hütte brennt, soll ich dann wirklich erstmal an der Terraform-Config rumbasteln und so?
Kann ich dann nicht mal eben in die Web-Oberfläche reingehen und da in Gottes Namen ein paar neue virtuelle Maschinen aufstellen oder virtuelle Netzwerk-Interfaces einrichten oder was auch immer da halt Not tut?
Also wenn es jetzt wirklich brennt, kann man natürlich auch bei Amazon aus einem Backup einer Instanz sehr einfach eine zweite herstellen.
Und in dem Fall würde ich sagen, kann man durchaus auch diesen Notfallmechanismus, den Amazon dort bietet, aus dem Backup jetzt wieder die Instanz so herzustellen, dass sie dann gleich wieder läuft, nutzen.
Ansonsten würde ich aber empfehlen, einfach auch darauf zu achten, dass mein Setup so ist, dass ich im Fall der Fälle schnell eine, die Instanz nochmal aufsetzen kann, so wie man es auch bei einem Backup, ein Backup nützt mir halt nichts, wenn ich nie die Rücksicherung getestet habe.
Und so ist bei Infrastructure as Code, muss ich getestet haben, dass ich es auch noch so, dass die Infrastruktur auch noch so neu erzeugt wird und nicht nur, wenn ich sie ein Jahr lang fortgepflegt habe, vielleicht meine Änderungen alle funktioniert haben.
Naja, das ist natürlich klar.
Also die Administratoren, die ich kenne, die testen das immer sehr, sehr gerne.
Also die, ja Luca, du guckst jetzt so komisch, das war der Ironie-Modus jetzt hier.
Also ich meine, gut, ich sage ja in meiner Entschuldigung immer Anwesende ausgeschlossen.
Also wenn ich jetzt hier gegen Administratoren, ja weiß nicht, piekse, dann ist das natürlich jetzt immer nicht persönlich gemeint.
Aber insofern, klar, man sollte das testen.
Gibt es da irgendwo Mechanismen, die ein Terraform bereitsteckt, die das Ganze einfach machen oder abwerten?
Absichern oder ist das einfach Standard?
Also was es noch gibt, nicht von Terraform selbst, aber von anderen Anbietern, die das Ganze Open Source gestellt haben,
dass es auch Test-Tools gibt für Infrastruktur, wie man es aus der Programmierung kennt mit Unit-Tests,
wo man dann auch Infrastruktur testen kann und gucken kann, wenn ich eine Infrastruktur ausgerollt habe,
sind dann die Komponenten, die ich dort erwarte, die Dienste verfügbar auf meiner Infrastruktur.
Dann könnte man hergehen mit Autos.
Diese Infrastruktur einfach über einen CI-CD-Server, über einen Automatisierungs-Server wie Jenkins oder so etwas wie GitLab.
Auch einfach automatisiert aus dem Setup zyklisch immer wieder zu erzeugen, zu gucken, laufen meine Tests durch, sind die Dienste danach verfügbar.
Also im Grunde kann ich, weil Infrastructure as Code bedeutet, ich programmiere meine Infrastruktur,
alle Mechanismen, die man aus der Softwareentwicklung oder aus der agilen Entwicklung kennt, auch dort übertragen auf die Infrastruktur.
Jetzt nochmal so.
Irgendwie ein paar Namen parat von entsprechenden Tools?
Es gibt ein Test-Tool, das kommt von der Firma Grundwork.
Die haben das Open Source gestellt.
Den Namen habe ich gerade nicht griffbereit.
Den können wir noch nachliefern.
Ich wollte gerade sagen, das packen wir einfach in die Shownotes.
Aber das ist bestimmt für viele wieder spannend, weil du hast mir da das Stichwort tatsächlich etwas weggenommen, Dirk.
Ich war nämlich auch total gespannt darauf, wie ich dann…
Wie man diese Mechanismen, die man auch aus der sonstigen Softwareentwicklung kennt, übertragen kann auf Infrastructure as Code.
Also, weil ich würde mir dann vorstellen, dass ich auch das dann, dass ich auch Terraform zum Beispiel testen werde, den Code, den ich da habe.
Dass ich womöglich sogar Testgetrieben entwickle.
Sind das Sachen, die dir begegnet sind?
Ist das Stand der Technik?
Also, was üblich ist, ist zu versionieren.
Automatisierte Tests auszuführen, würde ich jetzt eher als exotische bezeichnen.
Das wird seltener gemacht und auch das automatisierte Deployment, ja, wird auch seltener benutzt, weil ich sie auch auf der Kommandozeile ausrollen kann.
Das macht, macht aber natürlich auch Sinn, es durch zu automatisieren und darauf zu achten, dass ich wirklich GitOps betreibe, dass ich eigentlich nur Code in meine Versionsverwaltung stelle und dann alles Weitere dann den CICD-Server machen lasse.
Wenn ich so auf die Uhr gucke, dann…
Kommen wir so langsam zum Ende, zumindest unserem geplanten Ende.
Und wir fragen ja eigentlich immer auch nochmal die Gäste in unserem Podcast, ob es doch irgendetwas gibt, was wir noch nicht besprochen haben.
Also, gibt es noch irgendetwas, was du noch loswerden möchtest zu dem Thema Fachlichkeit, zum Thema Infrastructure as Code, was du jetzt noch, obwohl du nochmal einen kleinen Block kriegst dafür?
Warte ich, wir haben schon viele Bereiche jetzt.
Angesprochen, was ich wirklich nahelegen würde, ist die Kombination dann auch mit Docker-Containern, mit Virtualisierung zu nutzen und deren Vorteile dann zu nutzen.
Das muss nicht immer ein Kubernetes-Cluster sein, das könnte jetzt auch schon sein, einfach ein einfacher Docker-Container, die ich auf einer Maschine dann ausrolle.
Kleiner Tipp vielleicht noch in dem Zusammenhang, es gibt ein sehr schönes Linux-Betriebssystem, das nennt sich Flatcar-Container-Linux.
Das ist ein…
Stammt ab von dem ehemaligen…
Core-OS, was dann an Red Hat verkauft wurde und Red Hat pflegt das jetzt selber so nicht in der Form weiter und das wird von einer deutschen Firma, die glaube ich in Berlin ansässig ist, jetzt weiter betrieben.
Und dieses Flatcar-Container-Linux ist im Grunde ein ganz minimalistisches Linux, was keinen Paketmanager hat, was wartungsfrei betrieben werden kann, wo der Kernel immer wieder automatisiert aktualisiert wird und wo ich im Grunde alles, was ich dort aufspiele, in Form von Docker-Containern aufspiele.
Das heißt, um dieses Betriebssystem…
muss man sich nicht kümmern, es läuft, aktualisiert sich automatisch und ist nahezu wartungsfrei und eignet sich, wenn ich jetzt keinen, eignet sich dann schon, auch wenn ich keinen Kubernetes-Cluster betreiben will, wo ja doch einiges Wissen zu notwendig ist, wenn man nicht ein fertiges Setup oder einen Anbieter, der das als Managed Service anbietet, nutzt.
Und da kann man sehr einfach auch mit einem Knoten in eine, sage ich mal, Container-basierte Docker-Umgebung starten für die Produktion.
Sehr schön, gut. Wir hatten ja eben schon den Punkt, dass wir ein paar Tipps von dir in die Shownotes packen.
Vielleicht gibt es noch ein paar andere Fragen an dich. Wo findet man dich denn? Also wo kann man Kontakt zu dir aufnehmen?
Meine Webseite heißt container.sh, Container mit K geschrieben. Das ist eine Anspielung auf Kubernetes.
Und das ist H für die Shell, weil ich mich halt mit Infrastructure as Code, wo man auf der Shell arbeitet…
…auf der Kommandozeile arbeitet, befasse. Daher dieser Name und was ich dort anbiete, ist alles rund um das Thema DevOps, DevOps-Automatisierung.
Ich unterstütze Unternehmen bei der Einführung von DevOps, bei der Einführung von agilen Prozessen.
Ich biete Mentorings an für Entwickler, unterstütze Entwickler dann, sich mit diesen Tools vertraut zu machen, das Wissen zu erwerben.
Biete auch Tutorials an, biete ein Newsletter an auf meiner Webseite und plane für die Zukunft.
Auch noch weitere Angebote im Bereich Infrastructure as Code.
Tja, also ich finde das mit dem Mentoring klingt sehr, sehr interessant, weil da natürlich die Chance ist, quasi zu einer Vertrauensperson, die aber auch Experte ist, mit dem einfach in so ein paar Gespräche einzusteigen und diese Veränderung, über die wir ja mit DevOps eigentlich immer sprechen.
Wir reden ja über, natürlich über Technik, aber wir reden auch über Veränderung. Wir reden über andere Arbeitsweisen.
Wir reden darüber, dass der Job anders.
Und da denke ich, ist es wahrscheinlich ganz, ganz hilfreich, jemanden zu haben, der das sozusagen schon mal durchgemacht hat und der einen dann auch versteht und einem auch technische Tipps geben kann.
Genau, und ich habe dort auch bewusst nach einer anderen Form gesucht, als diese klassische Schulungen abdecken, wo man irgendwie seine Entwickler in ein Hotel schickt für zwei, drei Tage und die dann in einen Seminarraum setzt und dann versuchen sie an ihrem Rechner zwei Tage etwas auszuprobieren.
Vielleicht haben sie hinterher gar nicht die Möglichkeit, es in der Praxis dann auch anzuwenden.
Und in einem so längeren Mentoring-Prozess kann man den Entwickler wirklich längerfristig begleiten und immer wieder, wenn er Nachfragen hat, wenn er Bedarf hat an Schulungen, an Erklärungen oder vielleicht an einem Review dessen, was er gemacht hat, dann kann man ihn immer wieder unterstützen und ihn in diesem Prozess begleiten.
Gut, Helge, ich bedanke mich. Also ich habe jetzt keine Fragen mehr. Ich habe, glaube ich, genug kluge, aber auch genug dumme Fragen gestellt.
Also ich würde mich jetzt bedanken bei dir für diese, naja, es war ja fast schon eine Stunde, zumindest für die vielen, vielen Aussagen und ich glaube, ich kann das ganze Thema jetzt einfach noch ein bisschen besser einsortieren. Also von meiner Seite aus herzlichen Dank.
Ja, ich bedanke mich auch bei euch. Hat großen Spaß gemacht mit euch und fand es auch interessant heute die Kombination, weil ihr ja jetzt eher von der Beratungsseite herkommt, auch mal euren Blickpunkt auf das Thema zu hören und was ich jetzt auch noch so mitnehme, diesen Aspekt dann auch bei mir.
Ja, das ist, ich glaube, damit würdest du deinen Kunden einen gewaltigen Dienst erweisen, weil Jammel ist gleich geschrieben, aber die Gedanken, die man sich dahinter machen muss und die menschliche Seite, da, glaube ich, passieren die wirklich spannenden Sachen.
Aber ich möchte mich auch ganz herzlich bedanken, dass du bei uns im Podcast warst heute. Das war sehr spannend, war sehr interessant und ich bin zwar ein größerer Technik-Daddler als der Dirk, aber ich habe trotzdem auch sehr viel gelernt.
Insofern vielen Dank für alles, was du uns heute erzählt hast.
Sehr gerne.

„Workaround for Joe’s Problem“

Heute hörte ich von einem Team das jeden Tag eine .csv Datei mittels FTP herunterlädt, drei Zeilen löscht, und sie dann manuell woanders hin hochlädt.

Wieso? Weil eines Tages diese drei Zeilen nicht richtig in eine Datenbank geladen werden konnten, und ihr Workaround war, diese drei Zeilen eben zu löschen.

Und das machen sie nun Tag für Tag… seit 2009.

Teils natürlich auch einfach deshalb, weil sie in einer regulierten Industrie arbeiten, und dieser Prozeß wurde irgendwann mal dokumentiert und somit verpflichtend.

(Er ist dokumentiert als „workaround für Joe’s Problem“. Keiner kann sich erinnern, wer dieser Joe eigentlich war.)

Diese Geschichte ist einerseits amüsant, andererseits aber auch lehrreich.

Ähnliche Vorgänge finden sich in praktisch jeder Organisation. Seltsame Prozesse, die irgendwann von irgendwem eingeführt wurden, und mittlerweile selbst ein Eigenleben entwickelt haben.

Und unser aller Reflex ist vermutlich, kurzerhand den beschriebenen Prozess zu automatisieren. Das ist sicherlich eine gute Idee: die Qualität wird steigen (weil keiner mal versehentlich was verkehrt macht), die Mitarbeiter Zeit und mentale Kapazität zurückgewinnen für wichtigere, wertschöpfendere Dinge.

Andererseits ist das aber vielleicht gar nicht so eine tolle Lösung: einen etwas merkwürdigen Prozeß haben wir jetzt auch noch verewigt!

In der Tat frage ich mich, ob das dem Workaround zugrundeliegende Problem nicht in den letzten 12 Jahren irgendwann den Weg des Dodo ging. Und falls es noch existiert: ob es nicht eine gelungenere Möglichkeit gibt, diesem Problem zu begegnen, z.B. durch geeignete Validierung in der Datenbank, oder was einem auch sonst so einfällt.

Diese Geschichte weist neben der unmittelbaren Moral (automatisiere es!) aber noch eine zweite, etwas indirektere auf: auch eigenwillige Lösungen sind stets Reaktionen auf reale (oder als real empfundene) Probleme, entwickeln dann aber ein Eigenleben abseits dieser Probleme. Und können somit lange weiterexistieren, nachdem das Problem aufhörte, eines zu sein.

Insofern ist der erste Schritt einer Verbesserung durch Automatisierung ein ganz anderer: sich zu überlegen, ob das Problem weiterhin besteht und ob es weiterhin so gelöst werden muß.

Automation kann eben nicht nur segensreich zur Verringerung der Arbeitslast beitragen, sondern manchmal auch Ungünstiges erst recht zementieren.

DevOps ist keine IT-Philosophie, es ist eine Unternehmensphilosophie

„Unsere IT-Organisation führt jetzt DevOps ein“: famous last words. DevOps kommt aus der IT-Ecke, benutzt IT-Begriffe und -Denkweisen. Es ist also naheliegend, es als ein IT-Thema anzusehen.

Zugleich ist diese enge Auslegung eines der heikelsten Themen, die uns in unserer Arbeit regelmäßig begegnet.

Sei es in Schulungen oder in er begleitenden Beratung, die größten Schwierigkeiten zeigen sich erstaunlicherweise nicht in jenen Organisationsteilen, in denen DevOps eingeführt wird. Sondern an den Nahtstellen, wo die agile, DevOps einsetzende Organisation auf jene Unternehmensteile trifft, die sich eben nicht (oder noch nicht) umgestellt haben; seien es benachbarte Entwicklungsorganisation, das Controlling, die Unternehmensleitung, die Personalverwaltung oder gar der Kunde.

In einer Umfrage, die wir unter etlichen hundert IT-Verantwortlichen durchgeführt haben, zeigte sich das gleiche Bild: die größte Überraschung, so teilten viele mit, waren die Spannungen, die sich plötzlich außerhalb der IT auftaten.

Das ist ein derart überraschendes Resultat, daß ich es nochmal wiederholen möchte: die größten Schwierigkeiten mit einer DevOps-Transformation zeigen sich oft gar nicht innerhalb der IT-Organisation, sondern außerhalb davon.

Das klingt vielleicht wie eine schlechte Nachricht, aber eigentlich ist es ein gutes Zeichen: DevOps wirkt! Es führt zu so tiefgreifenden Änderungen darin, wie die IT-Organisation nach außen wirkt, daß andere Bereiche nicht einfach bei der Tagesordnung bleiben können. Sie müssen sich mit diesem Wandel auseinadersetzen: ein hervorragendes Zeichen dafür, wie groß der Unterschied tatsächlich ist.

Ob das nun heißt, daß Euner Controlling nun ein DevOps-Controlling werden muß, ist vielleicht die falsche Frage. Das Wichtige ist, daß Organisation und Prozesse zu den Veränderungen innerhalb der DevOps-Organisation passen.

Wenn auf der einen Seite die Budgetprozesse weiterhin davon ausgehen, zwei-Jahres-Pläne zu verfassen und diese dann systematisch abzuarbeiten, während auf der anderen Seite eine agile Organisation selbstbewußt darauf pocht, den maximalen Kundennutzen erst unterwegs zu erkennen und ihm Rechnung zu tragen — na dann muß es ja in Streit enden, unabhängig davon, wer überhaupt Recht hat!

DevOps demaskiert technische Schulden

Eins der großen Themen von DevOps ist Sichtbarkeit: Sichtbarmachen vorn Arbeit, von Zusammenhängen, von Abläufen.

Das ist sicherlich eine gute Sache, kann aber manchmal einen, sagen wir, beunruhigenden Nebeneffekt haben: DevOps Einführungen machen eben auch Dinge sichtbar, die nicht so schön anzuschauen sind.

Das mag verschiedenste Ebenen betreffen: von verbreiteten Schwächen der Unternehmenskultur bis hin zu unsauberem Handwerk einzelner Entwickler.

Konkret ist mir eine Situation in Erinnerung, in der ein Unternehmen continuous integration einführen wollte. An sich keine allzu große Sache, sollte man meinen. Sicherlich muß man etwas Energie hineinstecken, bis alles rund läuft, aber im Regelfall ist diese Umsetzung eher überschaubar.

Nicht so in einem bestimmten Team: dessen Produkt widersetzte sich standhaft allen Versuchen, die builds zu automatisieren.

Zug um Zug stellte sich nämlich heraus, daß sehr viele implizite Annahmen getroffen wurden: über die Art, builds anzustoßen; über Pfade, Nutzer und Rechte; über die Art, wie Parameter übermittelt wurden (auf der Kommandozeile, in Umgebungsvariablen oder in Dateien). Und nicht nur, daß diese Annahmen implizit waren und nun den Automationsentwicklern ohne Vorwarnung um die Ohren flogen, sondern jeder Entwickler hatte seine eigenen Vorlieben (…die sich bei manchen auch noch über die Zeit änderten).

Bald setzte ein allgemeines Grummeln über DevOps im Allgemeinen und Automation im Speziellen ein: kostet wohl doch mehr als von Automationsverfechtern gern angegeben!

Aber die Kosten entstanden natürlich im Wesentlichen nicht aus den Mühen der Build-Automation: sondern daraus, daß nun die technischen Schulden wieder beglichen wurden, die sich über einenm langen Zeitraum aufgebaut hatten.

(Ich weiß übrigens nicht, wie’s in dieser Geschichte ausgegangen ist — ich schied bald darauf aus dem Projekt aus).

Diese Geschichte ist insofern sehr erzählenswert, als sie einem oft beobachteten Muster folgt: die agilen / DevOpslichen Ansätze führen zu mehr Sichtbarkeit — und nicht alles, was man zu sehen bekommt, gefällt einem auch.

Die technischen Schulden waren natürlich schon vorher da, aber jetzt sind sie sichtbar, fühlbar, und müssen behandelt werden.

Vermutlich bringt jegliche Transformation solche Effekte mit sich, aber Agile mit seinem Fokus auf klare Konturen ist da vielleicht besonders… intensiv; im Guten wie im Schlechten.