Was ist Infrastructure as Code? Infrastruktur mit Terraform steuern

Was ist Infrastructure as Code?

Infrastructure as Code (IaC, Infrastruktur als Code) bezeichnet die Methode, Server, Netzwerke, Datenbanken und andere Ressourcen über Definitionsdateien aufzubauen und zu verwalten, statt sie von Hand in einer Oberfläche zu klicken. In der Praxis legen Teams diese Dateien in der Versionskontrolle ab, prüfen sie und führen sie aus. So entsteht jedes Mal dasselbe Ergebnis.

Stellen Sie sich eine Restaurantküche vor. Baut ein Koch sie jedes Mal aus dem Gedächtnis auf, sieht sie also immer anders aus. Mit einem schriftlichen Plan und einer Maßliste baut dagegen jeder dieselbe Küche, denn nichts bleibt dem Zufall überlassen. IaC ist dieser schriftliche Plan für Ihre Infrastruktur.

Dieser Beitrag behandelt genau einen Begriff: Infrastructure as Code und das bekannteste Werkzeug dazu, Terraform. Wir preisen kein Produkt an, weil es uns um Verständnis geht. Stattdessen erklären wir die Idee, die Funktionsweise, die Vorteile und die Risiken in einfacher Sprache. Wer fragt, was ist Infrastructure as Code, braucht vor allem ein klares Bild. Verwandte Begriffe erwähnen wir nur in der Vergleichstabelle und kurz im Kontext.

Was ist Infrastructure as Code und worin unterscheidet es sich vom manuellen Aufbau?

Beim manuellen Aufbau öffnet eine Person die Cloud Oberfläche, legt einen Server an, ergänzt eine Sicherheitsregel und richtet eine Datenbank ein. Außerdem existieren die meisten dieser Schritte nur im Kopf der Person oder in ein paar Screenshots. Bei kleinen Umgebungen geht das trotzdem gut. Allerdings weiß bei wachsender Umgebung niemand mehr, wer was warum geändert hat.

Bei IaC hat dagegen jede Ressource eine Definition in einer Datei. Wer etwas ändern möchte, bearbeitet zunächst die Datei. Danach liest ein Kollege die Änderung, bevor sie live geht. Das heißt, eine Infrastrukturänderung durchläuft Vorschlag, Freigabe und Rücknahme wie eine Codeänderung.

• Manueller Aufbau: Startet schnell, hinterlässt aber keine Aufzeichnung und lässt sich schwer wiederholen.
• Aufbau mit Code: Kostet am Anfang Mühe, lässt sich aber wiederholen und prüfen.
• Mischform: Halb von Hand, halb per Code ist der riskanteste Zustand.

Konkret ist die Mischform besonders gefährlich. Ihr Code entfernt sich nämlich von der echten Umgebung, und niemand weiß, welcher Quelle er trauen soll.

Wie funktioniert Infrastructure as Code?

Kurz gesagt besteht der Ablauf aus drei Schritten. Zunächst schreiben Sie die gewünschte Infrastruktur in eine Definitionsdatei. Danach vergleicht das Werkzeug diese Definition mit der echten Umgebung und zeigt, was sich ändern würde. Schließlich setzt es die Änderungen nach Ihrer Freigabe über die Schnittstelle des Anbieters um. Eine API (Programmierschnittstelle) ist dabei der Weg, auf dem Software mit anderer Software spricht.

Die offizielle Dokumentation von Terraform beschreibt diesen Ablauf als schreiben, planen und anwenden (write, plan, apply). Zum einen beantwortet der Planschritt die Frage, was passieren wird. Zum anderen führt der Anwendungsschritt die freigegebene Änderung aus. Außerdem erkennt das Werkzeug Abhängigkeiten zwischen Ressourcen. Zum Beispiel legt es keine Datenbank an, bevor das Netzwerk existiert.

Der Wert dieses Ablaufs liegt in der Vorhersehbarkeit. Das heißt, Sie sehen vor der Ausführung, was eine Änderung bewirkt. Somit gibt es weniger Überraschungen.

Ein weiterer Gedanke ist wichtig: Dieselbe Definition zweimal auszuführen sollte dasselbe Ergebnis liefern. Zum Beispiel: Angenommen, Sie haben drei Server verlangt, und drei Server existieren bereits. Dann legt das Werkzeug nichts Neues an. Die Datei erneut laufen zu lassen ist also sicher, denn das Werkzeug setzt nur den Unterschied um.

Was ist der Unterschied zwischen deklarativ und imperativ?

Zunächst zum deklarativen Ansatz: Sie beschreiben das gewünschte Ergebnis. Beim imperativen Ansatz schreiben Sie dagegen die Schritte hin, die zu diesem Ergebnis führen. Der erste sagt: Es soll drei Server geben. Der zweite sagt: Lege einen Server an, danach noch einen.

Konkret arbeiten Terraform und OpenTofu deklarativ. Die offiziellen Dokumentationen betonen, dass Sie keine Schritt für Schritt Anweisungen schreiben müssen. Somit berechnet das Werkzeug die Lücke zwischen Ist und Soll und tut nur das Nötige.

Keiner der beiden Stile gewinnt immer. Dennoch passt der deklarative Stil gut zur Infrastruktur, denn die Frage, was existieren soll, ist meist wichtiger als die Frage, wie man es baut.

Was ist die State Datei und warum ist sie so wichtig?

Der State ist die Aufzeichnung, die die echten Ressourcen, die ein Werkzeug verwaltet, mit Ihren Definitionen verknüpft. Die Dokumentation von Terraform beschreibt ihn als Speicher für die Zuordnung zwischen Objekten im entfernten System und den Ressourcen aus Ihrer Konfiguration. Folglich weiß das Werkzeug nur dank dieser Aufzeichnung, was es verwaltet.

Ohne State könnte das Werkzeug nicht beantworten, ob ein Server schon existiert oder neu angelegt werden soll. Deshalb dient der State als Quelle der Wahrheit für Ihre Umgebung. Zum Beispiel: Geht er verloren, erkennt das Werkzeug die Umgebung nicht mehr. Ist er dagegen beschädigt, trifft es womöglich falsche Entscheidungen.

Außerdem ist der State mehr als ein technisches Detail. Denn er enthält Ressourcendaten und manchmal sensible Werte. Behandeln Sie ihn daher nicht wie eine gewöhnliche Datei.

• Die offizielle Dokumentation rät davon ab, den State an einem Ort ohne Sperrfunktion oder Zugriffskontrolle abzulegen.
• Für die Teamarbeit empfehlen wir einen entfernten Speicherort, ein sogenanntes Remote Backend.
• Daher verhindert die Sperre (Locking), dass zwei Personen den State gleichzeitig ändern.

Eine Regel kommt hinzu: Bearbeiten Sie die State Datei nie von Hand. Dafür gibt es stattdessen die eigenen Befehle des Werkzeugs. Sonst kann eine manuelle Änderung die Aufzeichnung von der Realität entkoppeln. Bei Problemen prüfen Sie zunächst Ihr Backup und die offizielle Dokumentation.

Was bedeuten Plan und Apply in der Praxis?

Zunächst: Ein Plan ist die Vorschau auf eine Änderung, bevor Sie sie ausführen. Das Werkzeug liest Ihre Definitionen und den State, prüft die echte Umgebung und listet auf, was es hinzufügt, ändert oder löscht. Apply führt diesen Plan dann aus. Die Trennung beider Schritte hilft Ihnen, eine fehlerhafte Änderung zu erkennen, bevor sie die Produktion erreicht.

Beispielszenario: Ein Team möchte in einer Testumgebung eine Datenbank umbenennen. Die Planausgabe zeigt, dass die Änderung die alte Datenbank löschen und eine neue anlegen würde. Dann bemerkt das Team das und wählt einen anderen Weg. Sonst hätte es Daten verlieren können.

Deshalb sollte das Lesen des Plans zur Gewohnheit werden. Achten Sie vor allem auf Zeilen zum Löschen und Neuanlegen. Vor der Freigabe sollte außerdem eine zweite Person den Plan ansehen.

Die Ausgabe wirkt anfangs allerdings unübersichtlich. Nach ein paar Versuchen liest sie sich allerdings leichter. Schauen Sie zunächst auf die Zahl der hinzugefügten, geänderten und gelöschten Ressourcen. Dann prüfen Sie, ob eine Zeile Sie überrascht. Vor allem ist jede überraschende Zeile ein Signal, anzuhalten und nachzufragen.

Was ist Terraform und wie hängt es mit Infrastructure as Code zusammen?

Konkret ist Terraform ein IaC Werkzeug von HashiCorp. Laut offizieller Beschreibung können Sie damit Cloud Ressourcen und Ressourcen im eigenen Rechenzentrum mit gut lesbaren Konfigurationsdateien aufbauen, ändern und versionieren. Anders gesagt: Terraform ist kein Begriff, sondern ein Werkzeug, das die IaC Idee umsetzt.

Zudem verwaltet Terraform Ressourcen über Provider. Also ist ein Provider ein Plugin, das mit der Schnittstelle einer bestimmten Plattform spricht. Laut der Dokumentation bietet die Registry Provider für viele Plattformen, etwa für Cloud Dienste, Kubernetes und Plattformen für Quellcode.

Außerdem kennt das Werkzeug Module. Außerdem macht ein Modul aus einem wiederkehrenden Infrastrukturteil ein wiederverwendbares Paket. Somit schreiben Sie dasselbe Netzwerklayout nicht in jedem Projekt neu.

Aktuelle Funktionen und Versionsdetails prüfen Sie in der offiziellen Einführung von Terraform. Deshalb konzentrieren wir uns hier auf den stabilen Kern des Konzepts.

Was ist OpenTofu und unterscheidet es sich von Terraform?

OpenTofu ist ein von der Community getragenes IaC Werkzeug, das derselben Idee wie Terraform folgt. Zudem nennt die offizielle Webseite das Projekt ein Projekt unter dem Dach der Linux Foundation. Der Ablauf aus schreiben, planen und anwenden sowie die State Logik ähneln denen von Terraform also stark.

Die Dokumentation von OpenTofu sagt, dass Sie mit dem Plugin SDK von Terraform eigene Provider schreiben können. Das deutet daher auf eine architektonische Nähe beider Werkzeuge hin. Allerdings kann der Umfang der Kompatibilität je nach Version variieren.

Unterschiede bei Lizenz und Governance sind ein eigenes Streitthema. Deshalb geben wir dazu keine eigene Meinung ab. Lesen Sie vor einer Entscheidung die offizielle Dokumentation von OpenTofu und die Lizenztexte beider Projekte. Bauen Sie eine Unternehmensumgebung auf, fragen Sie zudem Ihre Rechtsabteilung.

Zum Lernen des Konzepts spielt Ihre Wahl kaum eine Rolle. Denn die Logik bleibt gleich. Die Werkzeugwahl hängt dagegen von den Bedürfnissen Ihres Teams und den Regeln Ihres Unternehmens ab.

Welche anderen Kategorien von IaC Werkzeugen gibt es?

Terraform und OpenTofu sind nicht die einzigen Optionen. Zunächst können Sie IaC Werkzeuge grob in drei Kategorien einteilen. Diese Einteilung beschreibt also einen Ansatz, keine Markenliste.

• Allgemeine deklarative Werkzeuge: Sie verwalten mehrere Clouds und Dienste mit einer Sprache.
• Werkzeuge der Cloud Anbieter: Sie binden sich eng an eine Cloud und unterstützen deren Neuheiten schnell.
• Werkzeuge in einer Programmiersprache: Sie lassen Sie Infrastruktur in einer vertrauten Sprache mit Schleifen und Bedingungen beschreiben.

Welche ist richtig? Das hängt zum Beispiel von den Fähigkeiten Ihres Teams und den genutzten Clouds ab. Bleiben Sie bei einer einzigen Cloud, genügt womöglich das Werkzeug des Anbieters. Verwalten Sie dagegen mehrere Plattformen, ist ein allgemeines Werkzeug sinnvoller.

Stellen Sie deshalb bei der Auswahl ein paar Fragen. Welche Sprache liest unser Team mühelos? Welche Clouds nutzen wir? Wie stark ist die Unterstützung durch die Community? Prüfen Sie zudem, ob die Dokumentation aktuell ist, denn gute Dokumentation verkürzt die Einarbeitung.

Daher erklären wir kein Produkt zum besten. Am sichersten testen Sie zwei Werkzeuge in einer kleinen Testumgebung und beobachten, womit Ihr Team besser zurechtkommt.

Was ist Infrastructure as Code wert? Die wichtigsten Vorteile

Der Kernvorteil von IaC ist die Wiederholbarkeit. Erstens bauen Sie mit denselben Definitionsdateien Test, Staging und Produktion ähnlich auf. Das Problem „bei mir hat es funktioniert“ schrumpft daher, denn Unterschiede zwischen den Umgebungen sehen Sie in den Dateien.

Zweitens bietet IaC Versionskontrolle. Weil die Dateien in einem System wie Git liegen, hat jede Änderung Autor, Datum und Begründung. Nach einer fehlerhaften Änderung kehren Sie also leichter zum früheren Stand zurück. Grundlagen zu Git finden Sie in unserer Anleitung zu Git und GitHub.

Drittens hilft IaC bei der Wiederherstellung nach einem Ausfall. Fällt eine Umgebung aus, macht ein schriftliches Rezept den Neuaufbau planbar. Allerdings ist die Datensicherung ein eigenes Thema. Kurz gesagt: IaC bringt Ihre Infrastruktur zurück, nicht Ihre Daten.

• Wiederholbarkeit: Dieselbe Definition erzeugt dieselbe Umgebung.
• Nachvollziehbarkeit: Sie sehen, wer was wann geändert hat.
• Tempo: Eine neue Umgebung entsteht in einem Vorgang.
• Zusammenarbeit: Auch Infrastrukturänderungen durchlaufen eine Prüfung.

Ein vierter Vorteil hilft neuen Teammitgliedern. Wer die Infrastruktur verstehen will, liest daher die Dateien, statt herumzufragen. Somit wandert das Wissen aus den Köpfen in eine gemeinsame Quelle. Diese Entlastung spüren schon kleine Teams.

Was ist Infrastructure as Code in Bezug auf Risiken? Die größten Gefahren

IaC ist mächtig, deshalb wirken seine Fehler stark. Zum Beispiel kann eine einzige falsche Zeile viele Ressourcen einer Umgebung löschen. Vor allem ist die Freigabe ohne Blick auf den Plan die häufigste Quelle dieses Risikos.

Das zweite Risiko ist die State Datei. Geht sie verloren, ist sie beschädigt oder gelangt sie an Unbefugte, entstehen Probleme für Betrieb und Sicherheit. Das dritte Risiko sind Geheimnisse im Code. Deshalb gehen wir im nächsten Abschnitt ein.

Das vierte Risiko heißt Drift. Öffnet jemand die Oberfläche und ändert eine Einstellung von Hand, weicht die echte Umgebung von Ihrem Code ab. Dann versucht beim nächsten Lauf das Werkzeug womöglich, diesen Unterschied rückgängig zu machen. Folglich brauchen Sie die Teamregel: Änderungen laufen nur über den Code.

• Geben Sie nie eine Änderung frei, ohne den Plan zu lesen.
• Bewahren Sie den State an einem sicheren, gesperrten Ort auf.
• Verbieten Sie manuelle Änderungen oder dokumentieren Sie sie als bewusste Ausnahme.
• Nutzen Sie bei kritischen Ressourcen einen Löschschutz.

Wie schützen Sie Geheimnisse und Passwörter bei IaC?

Schreiben Sie Passwörter, API Schlüssel und Zugriffstoken nie im Klartext in Definitionsdateien. Denn diese Dateien landen in der Versionskontrolle und bleiben in deren Verlauf. Außerdem kann ein Schlüssel, der einmal im Repository stand, dort auch nach dem Löschen im Verlauf sichtbar bleiben.

Der sicherere Weg ist ein eigenes System zur Verwaltung von Geheimnissen, auf das der Code nur verweist. Bedenken Sie außerdem, dass auch die State Datei geheime Werte enthalten kann. Die Dokumentation von Terraform weist darauf hin, dass ein State ohne Zugriffskontrolle Geheimnisse offenlegen kann. Lesen Sie deshalb die offizielle Seite zum State aufmerksam.

Ein neues Passwort erzeugen Sie zum Beispiel mit unserem Passwort Generator. Speichern Sie das Ergebnis dann im System für Geheimnisse und nicht in einer Definitionsdatei.

1. Prüfen Sie Dateien auf Geheimnisse, bevor sie ins Repository gelangen.
2. Geben Sie jedem Schlüssel nur die niedrigste nötige Berechtigung.
3. Widerrufen und ersetzen Sie jeden Schlüssel, bei dem Sie einen Abfluss vermuten.
4. Beschränken Sie den Zugriff auf den State nach Person und Rolle.

Wie unterscheiden sich IaC, Konfigurationsmanagement und Container?

Diese drei Begriffe verschwimmen oft, weil alle drei nach automatischem Einrichten einer Umgebung klingen. Tatsächlich arbeitet allerdings jeder auf einer anderen Ebene. Konkret erzeugt IaC die Infrastruktur, das Konfigurationsmanagement richtet das Innere eines Servers ein, und Container verpacken die Anwendung.

Die drei konkurrieren nicht miteinander. Zum Beispiel legen viele Teams Server mit IaC an und betreiben die Anwendung in Containern. Das Konfigurationsmanagement kommt vor allem dann ins Spiel, wenn Server dauerhafte Einstellungen im Inneren brauchen.

Wie nutzen Sie IaC zusammen mit Docker und Kubernetes?

Zunächst: Ein Container verpackt eine Anwendung mit ihren Abhängigkeiten. Wie Container funktionieren, haben wir im Leitfaden zu Docker erklärt. Wir wiederholen es hier daher nicht. Wichtig ist, dass der Ort, an dem Container laufen, ebenfalls irgendwoher kommen muss.

Hier kommt daher IaC ins Spiel. Das Fundament aus Servern, Netzwerken und Clustern bauen Sie mit Code, und die Anwendung betreiben Sie in Containern. Zur Container Orchestrierung, also zur Verwaltung vieler Container, lesen Sie unseren Beitrag zum Unterschied zwischen Docker und Kubernetes.

Beispielszenario: Ein Team baut für eine kleine Anwendung einen Cluster und eine Datenbank. Die IaC Dateien definieren Cluster und Netzwerk. Danach schickt das Team die Anwendung als Container in den Cluster. Somit sind Fundament und Anwendung dokumentiert und wiederholbar.

Wo bewahren Sie Infrastrukturcode auf und wie überwachen Sie ihn?

Zunächst: Auch Infrastrukturcode lebt in einem Repository. Manche Teams halten Anwendungscode und Infrastrukturcode in einem Repository, andere nutzen getrennte. Allerdings haben beide Wege Vor und Nachteile. Diese Debatte behandeln wir ausführlich in unserem Beitrag zum Monorepo.

Denn die Infrastruktur aufzubauen ist nur die halbe Arbeit. Läuft sie, müssen Sie sehen, was im Inneren passiert. Logs, Metriken und Traces spielen dann eine Rolle. Dazu lesen Sie unseren Beitrag zu Observability und OpenTelemetry.

Kurz gesagt: IaC ist kein Endpunkt. Zusammen mit Repository Aufbau, Prüfprozess und Überwachung ergibt es ein Ganzes.

Wie vereinfachen Module und Variablen die IaC Dateien?

Weil die Infrastruktur wächst, wird es lästig, dieselbe Definition immer wieder zu schreiben. Ein Modul macht aus einem wiederkehrenden Teil ein einziges Paket. Zum Beispiel nutzen Sie ein Netzwerklayout in verschiedenen Projekten erneut. Dadurch sinken Aufwand und Fehlerquote.

Eine Variable erlaubt es, dieselbe Definition mit anderen Werten auszuführen. So bestellen Sie im Test einen kleinen und in der Produktion einen stärkeren Server. Somit bleibt die Definition gleich, nur der Wert ändert sich. Dieser Ansatz zeigt zudem den Unterschied zwischen Umgebungen an einer Stelle.

Allerdings ist übertriebene Abstraktion eine Falle. Machen Sie aus allem einen Parameter, lassen sich die Dateien schlecht lesen. Beginnen Sie einfach und wechseln Sie zu einem Modul, sobald sich Wiederholung zeigt.

Wie trennen Sie Test, Staging und Produktion mit IaC?

Viele Teams arbeiten mit mindestens drei Umgebungen: Test, Staging und Produktion. IaC erleichtert es, sie ähnlich aufzubauen. Konkret stammt jede Umgebung aus derselben Definition, nur Größe und Zugriffsregeln unterscheiden sich.

Beispielszenario: Ein Team probiert eine neue Netzwerkregel zuerst in der Testumgebung aus. Zunächst zeigt die Planausgabe die erwartete Änderung. Danach wendet das Team dieselbe Änderung im Staging an und zuletzt in der Produktion. Somit fällt der Fehler früh auf, und Kunden merken nichts.

Einen eigenen State je Umgebung zu führen ist eine gute Gewohnheit. Dann beschädigt ein Fehler im Test nicht die Aufzeichnung der Produktion. Zudem trennen Sie Zugriffsrechte pro Umgebung. Weniger Personen brauchen das Recht, die Produktion anzufassen, daher bleibt die Wirkung eines falschen Befehls begrenzt.

Welche Sicherheitskontrollen braucht IaC?

IaC greift per Code auf die Infrastruktur zu, also gehört die Sicherheit ebenfalls in den Code. Die erste Kontrolle ist das Prinzip der geringsten Rechte. Geben Sie dem Konto, das das Werkzeug nutzt, nur die nötigen Berechtigungen, denn wer dieses Konto übernimmt, kann Ihre gesamte Infrastruktur ändern.

Zweitens zählt die Prüfung. Verlangen Sie auch für Infrastrukturänderungen ein Code Review. Drittens hilft ein automatischer Scan des Codes. Ein solcher Scan kann zum Beispiel einen für alle offenen Speicherbereich oder eine viel zu weite Netzwerkregel finden.

• Geben Sie dem Konto des Werkzeugs die geringstmögliche Berechtigung.
• Lassen Sie jede Infrastrukturänderung von einer zweiten Person prüfen.
• Starten Sie vor der Freigabe des Codes einen automatischen Sicherheitsscan.
• Bewahren Sie Zugriffsprotokolle auf und kontrollieren Sie sie regelmäßig.

Für zusätzlichen Schutz auf der Serverseite lesen Sie unsere Anleitung zu Fail2ban. Es ersetzt IaC also nicht, schützt aber die Server, die Sie aufbauen.

Wie starten Sie mit Infrastructure as Code?

Machen Sie stattdessen keinen riesigen Umzugsplan. Beginnen Sie mit einer kleinen Ressource mit geringem Risiko. Eine Testumgebung oder das Netzwerklayout eines neuen Projekts eignet sich zum Beispiel gut als erster Schritt. Die bestehende Produktion in Code zu fassen, kommt später.

1. Wählen Sie ein Werkzeug und lesen Sie die offiziellen Einstiegsdokumente.
2. Definieren Sie eine kleine Ressource im Code und prüfen Sie die Planausgabe.
3. Bestimmen Sie einen sicheren Speicherort für den State mit Sperrfunktion.
4. Legen Sie die Definitionsdateien in die Versionskontrolle und setzen Sie eine Prüfregel.
5. Überführen Sie manuelle Änderungen Schritt für Schritt in Code.

Denn eine Aufzeichnung bei jedem Schritt schafft Vertrauen im Team. Außerdem machen Sie den ersten Versuch in einer Umgebung ohne Livebetrieb, wo Fehler weniger kosten. Bei der Serverwahl hilft Ihnen unsere Entscheidungshilfe zu VPS, Cloud Server und VDS, denn die Infrastrukturentscheidung kommt vor der IaC Entscheidung.

Wann braucht ein Unternehmen wirklich IaC?

Zunächst: Nicht jedes Unternehmen braucht IaC sofort. Für eine kleine Firmenseite auf einem einzigen Shared Hosting Konto kann die Methode unnötiger Ballast sein. Der Nutzen wird allerdings deutlich, wenn Sie mehrere Umgebungen, mehrere Personen oder häufige Infrastrukturänderungen haben.

Diese Zeichen sprechen dafür, dass die Zeit für IaC gekommen ist:

• Erinnerte Schritte reichen nicht mehr, wenn Sie dieselbe Umgebung ein zweites Mal bauen müssen.
• Zwischen Test und Produktion tauchen unerklärliche Unterschiede auf.
• Nur eine Person kennt die Infrastruktur, und das Wissen geht mit ihr verloren.
• Sie brauchen aus Prüfgründen ein Änderungsprotokoll.

Beispielszenario: Ein Onlineshop schaltet in Kampagnenzeiten zusätzliche Server hinzu. Statt sich jede Saison an dieselben Schritte zu erinnern, hält das Team die Definition in einer Datei fest. Endet die Kampagne, entfernt es die zusätzlichen Ressourcen mit derselben Datei. Somit geht der Aufbau schneller, und vergessene Server verursachen keine unnötigen Kosten mehr.

Was gehört in eine praktische IaC Checkliste?

Die folgende Liste sammelt die Grundpunkte, die Sie bei der Prüfung eines IaC Aufbaus abhaken können. Alles bleibt daher auf Konzeptebene. Denn die Umsetzungsdetails hängen von Ihrem Werkzeug ab.

• Liegen alle Definitionsdateien in der Versionskontrolle, geschützt vor unbefugten Änderungen?
• Liegt der State an einem entfernten, gesperrten Ort mit begrenztem Zugriff?
• Halten Sie Geheimnisse außerhalb des Codes?
• Prüfen Sie jede Änderung zusammen mit ihrer Planausgabe?
• Steht fest, wer Zeilen zum Löschen oder Neuanlegen freigibt?
• Gibt es eine Regel und ein Erkennungsverfahren für manuellen Drift?
• Sichern Sie Daten getrennt von IaC?
• Versteht mehr als eine Person im Team die Infrastruktur?

Zur Datensicherung lesen Sie unsere Strategie für Website Backups. Außerdem: Wenn Sie Begriffe rund ums Hosting auffrischen möchten, hilft das Glossar der Hosting Begriffe.

Welche Fehler passieren bei IaC am häufigsten?

Erstens lassen Teams den State in einem lokalen Ordner und hängen von einem einzigen Rechner ab. Fällt dieser aus, erkennt das Werkzeug die Umgebung nicht mehr. Zweitens packen sie alles in eine Datei. Dann sinkt die Lesbarkeit, und das Risiko einer Änderung steigt.

Drittens geben sie Änderungen frei, ohne den Plan zu lesen. Viertens betten sie Geheimnisse in den Code ein. Fünftens geht Wissen verloren, wenn die Person geht, die den Code geschrieben hat. Fügen Sie deshalb den Dateien kurze Erläuterungen hinzu und dokumentieren Sie den Ablauf.

Schließlich ist es der teuerste Fehler, das Werkzeug in der Produktion zu testen, bevor man es kennt. Lernen Sie stattdessen in einer getrennten Umgebung. Dann müssen Sie Fehler nicht fürchten.

Ist IaC für ein kleines Team realistisch?

Ja, sofern Sie in überschaubaren Schritten beginnen, denn Maß hilft. Vor allem liegt der größte Gewinn für kleine Teams darin, dass Wissen von Personen in Dateien wandert. Geht jemand in den Urlaub oder verlässt das Team, bleibt das Wissen über die Infrastruktur erhalten.

Auch die Rollen zählen in einem kleinen Team. Eine Person kann zum Beispiel den Infrastrukturcode schreiben, während eine andere die Änderungen prüft. Selbst ein Team aus zwei Personen kann das umsetzen. Trotzdem muss jeder lernen, die Planausgabe zu lesen.

Lernen Sie zunächst die Kernbegriffe: Provider, Ressource, State und Plan. Sie tauchen auch in anderen IaC Werkzeugen auf. Danach folgen Module und Variablen. Außerdem brauchen Sie Cloud Grundlagen wie Netzwerk, Identität und Zugriffsverwaltung, denn IaC automatisiert diese Grundlagen, ersetzt sie aber nicht. Fehlen sie, automatisiert die Automatisierung nur die Fehler.

Wie Domain Einträge funktionieren, sehen Sie mit unserem DNS Abfrage Tool. Zudem gehen viele Infrastrukturprobleme auf einen einzigen DNS Eintrag zurück.

Wir, Talha Aslan und unser Team, sehen bei Softwareprojekten immer wieder, dass die Infrastruktur nachhaltig aufgebaut sein muss. Für eine Struktur, die zu Ihrem Unternehmen passt, informieren Sie sich über unsere individuelle Softwareentwicklung.

Hinweis: Dieser Beitrag ersetzt keine Rechts, Steuer oder Lizenzberatung. Prüfen Sie Lizenzen und aktuelle Funktionen in den offiziellen Dokumenten der Anbieter.