Praxishandbuch Terraform (eBook)

KAPITEL 1

Warum Terraform?

Software ist nicht fertig, wenn der Code auf Ihrem Computer läuft. Sie ist nicht fertig, wenn die Tests erfolgreich durchlaufen werden. Und sie ist nicht fertig, wenn jemand bei einem Code Review sein Okay gibt. Software ist erst fertig, wenn Sie sie zu den Benutzern und Benutzerinnen ausliefern.

Software Delivery besteht aus all der Arbeit, die zu erledigen ist, um den Code für einen Kunden oder eine Kundin verfügbar zu machen – zum Beispiel das Ausführen dieses Codes auf produktiven Servern, das Schützen vor Angriffen und indem dafür gesorgt wird, dass der Code widerstandsfähiger in Bezug auf Ausfälle und Lastspitzen wird. Bevor Sie sich in die Details von Terraform vertiefen, lohnt es sich, einen Schritt zurückzutreten und zu sehen, wo Terraform in das Gesamtbild der Software Delivery passt.

In diesem Kapitel werden wir uns mit folgenden Themen befassen:

• Was ist DevOps?
• Was ist Infrastructure as Code?
• Was sind die Vorteile von Infrastructure as Code?
• Wie arbeitet Terraform?
• Wie verhält sich Terraform im Vergleich zu anderen IaC-Tools?

Was ist DevOps?

Wollten Sie in gar nicht so ferner Vergangenheit eine Softwarefirma aufbauen, mussten Sie sich auch mit ziemlich viel Hardware herumschlagen. Sie hätten Schränke und Racks aufbauen müssen, sie mit Servern bestücken, diese verkabeln, eine Kühlung installieren, redundante Stromversorgung aufsetzen und so weiter. Es war sinnvoll, ein Team zu haben – meist als Developer (Devs) bezeichnet –, das sich nur um das Schreiben der Software kümmerte, und ein anderes Team – meist Operations (Ops) genannt –, das für diese Hardware verantwortlich war.

Das typische Dev-Team hätte eine Anwendung gebaut und sie zum Ops-Team »über den Zaun geworfen«. Dann lag es an Ops, herauszufinden, wie man diese Anwendung deployt und laufen lässt. Das meiste davon geschah manuell. Teilweise war das unvermeidbar, weil ein Großteil der Arbeit mit dem physischen Aufsetzen der Hardware zu tun hatte (zum Beispiel das Einbauen von Servern oder das Legen von Netzwerkkabeln). Aber selbst die Arbeit, die Ops in Software zu erledigen hatte, wie das Installieren der Anwendung und ihrer Abhängigkeiten, geschah oft durch das manuelle Ausführen von Befehlen auf einem Server.

Eine Weile geht das gut, aber wenn die Firma wächst, stoßen Sie irgendwann auf Probleme. Meist läuft es so ab: Weil Releases manuell durchgeführt werden, werden sie bei einer wachsenden Anzahl von Servern langsam, schmerzhaft und unvorhersehbar. Das Ops-Team macht gelegentlich Fehler, daher erhalten Sie sogenannte Snowflake-Server, bei denen jeder eine leicht andere Konfiguration besitzt (ein Problem, das als Konfigurationsdrift bekannt ist). Als Ergebnis steigt die Zahl der Fehler. Entwicklerinnen und Entwickler zucken mit den Schultern und sagen: »Also auf meinem Rechner funktioniert alles!« Ausfälle und Downtimes werden häufiger.

Das Ops-Team – ermüdet davon, dass ihre Pager nach jedem Release pünktlich nachts um drei Uhr losgehen – verlängert den Release-Zyklus auf einmal pro Woche. Dann auf einmal pro Monat. Dann auf einmal alle sechs Monate. Wochen vor dem halbjährlichen Release beginnen die Teams damit, zu versuchen, all ihre Projekte zusammenzuführen, was zu einem großen Berg an Merge-Konflikten führt. Keiner kann den Release-Branch stabilisieren. Die Teams geben sich gegenseitig die Schuld. Es entstehen Silos. Die Firma kommt knirschend zum Stehen.

Heutzutage ist ein Paradigmenwechsel im Gange. Statt ihre eigenen Datacenter zu managen, wechseln viele Firmen in die Cloud und nutzen die Vorteile von Diensten wie Amazon Web Services (AWS), Microsoft Azure oder Google Cloud Platform (GCP). Statt massiv in Hardware zu investieren, verbringen viele Ops-Teams ihre gesamte Zeit nun mit dem Arbeiten an Software und nutzen Tools wie Chef, Puppet, Terraform, Docker und Kubernetes. Statt Server in Racks einzubauen und Netzwerkkabel anzuschließen, schreiben viele Sysadmins Code.

So verbringen sowohl Devs wie auch Ops einen Großteil ihrer Zeit mit der Arbeit an Software, und die Trennung zwischen beiden Teams verschwindet. Es mag immer noch sinnvoll sein, ein eigenes Dev-Team zu haben, das für den Anwendungscode zuständig ist, und ein Ops-Team, das den Operations-Code betreut, aber es ist klar, dass Dev und Ops enger zusammenarbeiten müssen. Und daraus ist die DevOps-Bewegung entstanden.

DevOps ist weder ein Name für ein Team noch ein Jobtitel oder eine bestimmte Technologie. Stattdessen handelt es sich um einen Satz an Prozessen, Ideen und Techniken. Jeder nutzt eine etwas andere Definition von DevOps, aber in diesem Buch werde ich die folgende verwenden:

Das Ziel von DevOps ist, Software Delivery erheblich effizienter zu machen.

Statt mehrtägiger Merge-Albträume integrieren Sie kontinuierlich Code und halten ihn immer in einem deploybaren Status. Statt Code einmal pro Monat zu deployen, können Sie ihn dutzendfach pro Tag deployen oder sogar nach jedem einzelnen Commit. Und statt regelmäßig Ausfälle und Downtimes zu haben, bauen Sie resiliente, sich selbst heilende Systeme und nutzen Monitoring und Alerts, um von Problemen zu erfahren, die nicht automatisch aufgelöst werden können.

Die Ergebnisse von Firmen, die eine DevOps-Transformation durchlaufen haben, sind erstaunlich. So hat Nordstrom beispielsweise festgestellt, dass nach dem Anwenden von DevOps-Praktiken in der Organisation die Anzahl an Features, die monatlich ausgeliefert werden können, um 100% gestiegen ist, die Anzahl an Fehlern um 50% sank, die Lead Times um 60% verringert wurden (das ist die Zeit von einer Idee bis zum produktiv laufenden Code) und die Anzahl an Produktivzwischenfällen um 60% bis 90% geringer wurde. Nachdem die LaserJet-Firmware-Abteilung von HP mit dem Einsatz von DevOps-Praktiken begann, stieg der Zeitanteil, den Entwicklerinnen und Entwickler mit dem Schaffen neuen Features verbrachten, von 5% auf 40%, und die Gesamtentwicklungskosten wurden um 40% reduziert. Etsy hat DevOps-Praktiken genutzt, um von stressigen, unregelmäßigen Deployments, die häufig für Ausfälle sorgten, auf 25 bis 50 Deployments pro Tag zu kommen und dabei viel weniger Outages zu haben.1

Es gibt viele zentrale Werte in der DevOps-Bewegung: Kultur, Automation, Messen und Teilen (Sharing) (manchmal abgekürzt mit dem Akronym CAMS). Dieses Buch soll keinen umfassenden Überblick über DevOps geben (im Anhang finden Sie Leseempfehlungen), daher werde ich mich nur auf einen dieser Werte fokussieren: Automation.

Das Ziel ist, so viel Ihres Softwareauslieferungsprozesses wie möglich zu automatisieren. Das bedeutet, dass Sie Ihre Infrastruktur nicht durch Herumklicken auf einer Webseite oder durch manuelles Eingeben von Shell-Befehlen managen, sondern per Code. Dies ist ein Konzept, das im Allgemeinen als Infrastructure as Code bezeichnet wird.

Was ist Infrastructure as Code?

Die Idee hinter Infrastructure as Code (IaC) ist, dass Sie Code schreiben und ausführen, mit dem Sie Ihre Infrastruktur definieren, deployen, aktualisieren und abräumen. Dies steht für einen wichtigen Wechsel der Denkweise: Sie behandeln alle Aspekte von Operations als Software – selbst die, die Hardware repräsentieren (zum Beispiel das »physische« Aufsetzen von Servern). Tatsächlich besteht eine zentrale Erkenntnis von DevOps darin, dass Sie nahezu alles per Code managen können, einschließlich der Server, Datenbanken, Netzwerke, Logdateien, Anwendungskonfigurationen, der Dokumentation, der automatisierten Tests, der Deployment-Prozesse und so weiter.

Es gibt fünf große Kategorien an IaC-Tools:

• Ad-hoc-Skripte
• Konfigurationsmanagementtools
• Server-Templating-Tools
• Orchestrierungstools
• Provisionierungstools

Schauen wir sie uns alle an.

Ad-hoc-Skripte

Der einfachste Ansatz zum Automatisieren ist das Schreiben eines Ad-hoc-Skripts. Sie nehmen sich eine beliebige Aufgabe, die Sie bisher manuell umgesetzt haben, teilen sie in einzelne Schritte auf, nutzen die Ihnen genehmste Skriptsprache (zum Beispiel Bash, Ruby oder Python), um jeden dieser Schritte in Code zu definieren, und führen dieses Skript auf Ihrem Server aus (siehe Abbildung 1-1).

Abbildung 1-1: Am direktesten automatisieren Sie Dinge, indem Sie ein Ad-hoc-Skript schreiben, das auf Ihrem Server läuft.

Dies ist beispielsweise ein Bash-Skript mit dem Namen setup-webserver.sh, das einen Webserver konfiguriert, indem es Abhängigkeiten installiert, Code aus einem Git-Repo auscheckt und einen Apache-Webserver hochfährt: