Infrastruktur und Cloud 7 Min.

Infrastructure as Code: einen Server mit einem Befehl neu aufbauen

Infrastructure as Code beschreibt Server, Netzwerk, Zugriffe und Dienste in versionierten Dateien statt in Klicks. Dieselbe Datei erzeugt bei jeder Ausführung dieselbe Umgebung: Einen verlorenen Server neu aufbauen, eine Testkopie anlegen oder den Hoster wechseln wird zu einem geprüften Befehl, und die Beschreibung dient als stets aktuelle Dokumentation.

Inhalt8
  1. 01Was „Infrastructure as Code“ bedeutet
  2. 02Was das für das Unternehmen ändert
  3. 03Die Werkzeuge, Schicht für Schicht
  4. 04Was sie nicht wiederherstellt
  5. 05Was wir gelernt haben
  6. 06Wo man anfängt, ohne alles neu zu schreiben
  7. 07Der Rest der Baustelle
  8. 08Häufige Fragen

Ein vor drei Jahren installierter Server hat einiges erlebt: ein Paket, das an einem Abend mit Störung hinzugefügt wurde, eine für einen Kunden geänderte Einstellung, ein von Hand gestarteter und nie dokumentierter Dienst. Er läuft, und niemand könnte ihn identisch nachbauen. An dem Tag, an dem er verschwindet, beginnt der Wiederaufbau mit einer Spurensuche. Infrastructure as Code geht vom anderen Ende aus: Der Server wird in Dateien beschrieben, und geändert wird die Beschreibung, nicht die Maschine. Sie gehört zu den Bausteinen unseres Leitfadens zum Fundament einer Cloud-Infrastruktur.

Kurz gesagt

  • Infrastructure as Code beschreibt die Infrastruktur in versionierten, geprüften und wiederholbar ausführbaren Dateien, statt sie von Hand zu konfigurieren.
  • Microsoft stellt sie als Antwort auf das Auseinanderdriften von Umgebungen dar: „Schneeflocken“-Server, einzigartig und nicht reproduzierbar.
  • Für das Unternehmen dient sie vor allem der Notfallwiederherstellung, der Nachvollziehbarkeit von Änderungen und der Freiheit, den Hoster zu wechseln.
  • Die Werkzeuge ordnen sich nach Schichten: die Ressourcen (Terraform, OpenTofu, Pulumi), die Konfiguration der Maschinen (Ansible, cloud-init), die Dienste (Docker Compose).
  • Sie baut die Maschine neu auf, nicht die Daten: Sicherungen und ein Tresor für Geheimnisse bleiben unverzichtbar.

Was „Infrastructure as Code“ bedeutet

Definition

Infrastructure as Code

Die Praxis, Server, Netzwerke, Zugriffsrechte und Dienste in Textdateien zu beschreiben, die wie Code in einem Repository liegen, und dann ein Werkzeug diese Beschreibung anwenden zu lassen.

Microsoft fasst das Prinzip in seiner Einführung in Infrastructure as Code zusammen:

So wie derselbe Quellcode immer dasselbe Binärprogramm erzeugt, erzeugt ein IaC-Modell bei jeder Bereitstellung dieselbe Umgebung.

Microsoft Learn, What is infrastructure as code, aus dem Englischen übersetzt

Derselbe Text benennt das Problem, das sie löst: Ohne sie wird jede Umgebung mit der Zeit zu einer „Schneeflocke“ (im Original „snowflake“), einer einzigartigen Konfiguration, die sich nicht mehr automatisch reproduzieren lässt. Er betont die Idempotenz: Ein Bereitstellungsbefehl bringt die Umgebung immer in denselben Zustand, unabhängig vom Ausgangspunkt. Und die Methode: Um etwas zu ändern, ändert das Team die Quelle, nicht das Ziel.

Was das für das Unternehmen ändert

Der Nutzen ist nicht technisch. Er zeigt sich in vier Situationen, die jedes Unternehmen irgendwann erlebt.

  • Der verlorene Server. Hardwareausfall, Bedienfehler, gesperrtes Konto: Mit einer aktuellen Beschreibung folgt der Wiederaufbau einem Rezept statt einer Erinnerung. Das ist der Teil „Neustart“ des Notfallwiederherstellungsplans.
  • Die geprüfte Änderung. Eine Änderung an der Infrastruktur geht denselben Weg wie eine Codeänderung: vorgeschlagen, geprüft, angewendet, in der Historie aufbewahrt. Man weiß, wer welchen Port wann und warum geöffnet hat.
  • Die Testkopie. Dieselbe Datei erzeugt eine Testumgebung, die mit der Produktion identisch ist, für die Dauer eines Update-Tests, und löscht sie danach.
  • Der Ausgang. Eine beschriebene Infrastruktur lässt sich leichter zu einem anderen Hoster umziehen: Man weiß genau, was neu angelegt werden muss. Das ist ein Vorteil bei einer Cloud-Migration, ohne alles kaputt zu machen wie bei Überlegungen zur Abhängigkeit von der amerikanischen Cloud.

Der Weg einer Infrastrukturänderung

  1. Der Vorschlag

    Die Änderung wird in die Datei geschrieben.

  2. Die Prüfung

    Eine andere Person liest sie, und das Werkzeug zeigt, was sich ändern wird.

  3. Die Anwendung

    Das Werkzeug bringt die Infrastruktur in den beschriebenen Zustand.

  4. Die Historie

    Die Änderung bleibt datiert, signiert, umkehrbar.

Die Systemadministratoren verschwinden dabei nicht: Sie schreiben die Beschreibung, prüfen sie und entscheiden, was sie enthält. Ihr Wissen lebt nur nicht mehr in einem einzigen Kopf.

Die Werkzeuge, Schicht für Schicht

Kein Werkzeug kann alles. Man ordnet sie danach, was sie beschreiben.

  • Die Ressourcen. Maschinen, Netzwerke, DNS-Einträge, Speicherkonten, bei einem oder mehreren Anbietern. Terraform ist das verbreitetste Werkzeug; OpenTofu ist ein freier Ableger davon; Pulumi beschreibt dieselben Ressourcen in einer Programmiersprache. Jede große Cloud hat zudem ihr eigenes Format, wie ARM-Vorlagen und Bicep bei Microsoft Azure oder CloudFormation bei AWS.
  • Die Konfiguration der Maschinen. Pakete, Benutzer, Firewall-Regeln, Konfigurationsdateien: Ansible wendet diese Einstellungen auf eine oder mehrere Maschinen an, cloud-init setzt sie beim ersten Start.
  • Die Dienste. Auf einem Server mit Containern beschreibt eine Docker-Compose-Datei jeden Dienst, seine Datenvolumes, sein Netzwerk und seine Neustartrichtlinie.

Die Lizenz zählt bei der Wahl, denn sie hat sich schon einmal geändert:

  1. 10. August 2023

    HashiCorp kündigt an, dass seine Produkte, darunter Terraform, von der Lizenz MPL 2.0 zur Business Source License wechseln, die es konkurrierenden Dienstanbietern untersagt, die folgenden Versionen einzubinden.

  2. Nach der Ankündigung

    Softwarehersteller gründen OpenTofu, einen Ableger von Terraform unter dem Dach der Linux Foundation, der als direkter Ersatz vorgestellt wird.

Ein Unternehmen, das Terraform für sich selbst nutzt, darf weitermachen. Die Wahl zwischen beiden fällt nach Governance und unterstützten Anbietern, nicht aus Angst vor einem Prozess.

Was sie nicht wiederherstellt

Achtung

Die Maschine, nicht die Daten

Infrastructure as Code erzeugt einen leeren, gut konfigurierten Server. Die Kunden im CRM, die Rechnungen, die von Nutzern hochgeladenen Dateien kommen aus den Sicherungen, und nur von dort. Passwörter und API-Schlüssel haben in den Beschreibungsdateien nichts zu suchen: Sie liegen in einem Tresor, auf den die Beschreibung verweist, ohne sie zu enthalten.

Schnell neu aufzubauen nützt nichts, wenn die Daten nicht folgen. Unser Leitfaden zu den Sicherungen eines eigenen Servers beschreibt, wie man prüft, ob eine Wiederherstellung wirklich funktioniert, und unser Artikel zu verwaltetem oder selbst gehostetem Postgres behandelt den Fall der Datenbank. Für die Geheimnisse siehe den Tresor für Geheimnisse und gestohlene API-Schlüssel.

Was wir gelernt haben

Aus der Praxis

Am 5. Juli 2026 hat ein falsch adressierter Aufräumbefehl auf einen Schlag die Container von zehn Diensten auf unserem Server zerstört. Die in Volumes abgelegten Daten wurden gerettet; unsere Betriebsregeln sind inzwischen schriftlich festgehalten. Die Lehre: Was beschrieben und von den Daten getrennt ist, lässt sich neu erstellen, was nur auf der Maschine lebt, geht verloren. Die Website, die Sie gerade lesen, folgt derselben Idee: Ihre Hosting-Konfiguration, ihre Weiterleitungen und ihre Header sind Dateien in ihrem Repository, und die Veröffentlichung verweigert sich, wenn eine Seite unter einer umgeleiteten Adresse liegt.

Wo man anfängt, ohne alles neu zu schreiben

Niemand muss seine gesamte Infrastruktur auf einmal beschreiben. Die Reihenfolge, die sich am schnellsten auszahlt:

  1. Bestandsaufnahme machen.

    Jeder Server, jeder Dienst, jeder DNS-Eintrag, und wo ihre Daten liegen.

  2. Zuerst die Dienste beschreiben.

    Eine Datei pro Dienst, mit getrennten Datenvolumes: Das wird am häufigsten neu erstellt.

  3. Dann die Maschine.

    Pakete, Benutzer, Firewall, Reverse Proxy, in einem Konfigurationswerkzeug.

  4. Den Wiederaufbau testen.

    Auf einer neuen Maschine, mit einer echten Sicherung: Die Stoppuhr zeigt, ob das Rezept hält.

  5. Jede Änderung über die Beschreibung laufen lassen.

    Eine von Hand auf dem Server vorgenommene Änderung ist eine Schuld; man überträgt sie noch am selben Tag in die Dateien.

Der Rest der Baustelle

Infrastructure as Code gilt unabhängig vom Hosting-Ort (dedizierter Server, VPS oder Cloud) und setzt kein Kubernetes voraus (wann ein KMU es nicht braucht). Sie macht die Ressourcen sichtbar, die Geld kosten (die Posten, die eine Cloud-Rechnung aufblähen), beschreibt den Proxy vor den Diensten (was Cloudflare schützt) und wird durch eine Überwachung ergänzt, die vor den Kunden warnt. Sie gilt auch für selbst gehostete Werkzeuge (n8n im Produktivbetrieb, die Werkzeuge, die man zuerst aus dem SaaS holt, die Kosten eines SaaS-Ausstiegs über drei Jahre) und für KI-Server (die nötige Hardware). Die Zugänge des Teams (ein Passwortmanager), die E-Mail (Google, Microsoft oder europäischer Hoster) und die Resilienzpflichten (NIS2 in Frankreich) vervollständigen das Fundament.

Unser SaaS-Ausstieg liefert Ihre Werkzeuge installiert auf einem eigenen Server, mit Sicherungen außerhalb des Servers, deren Wiederherstellung getestet ist, und einer Betriebsdokumentation: 5 500 € und drei Wochen.

Häufige Fragen

Lohnt sich Infrastructure as Code für einen einzigen Server?

Ja, und oft zahlt sie sich gerade dort am schnellsten aus. Ein einziger Server ist ein einziger Ausfallpunkt: Verschwindet er, muss alles, was darauf lief, neu gemacht werden. Seine Dienste und seine Konfiguration in Dateien zu beschreiben, macht diesen Wiederaufbau zu einem bekannten Verfahren, das man vorab auf einer neuen Maschine testen kann. Der Gewinn hängt nicht von der Anzahl der Maschinen ab.

Terraform oder OpenTofu: Welches wählen?

Beide beschreiben dieselben Ressourcen mit derselben Sprache; OpenTofu ist nach dem Lizenzwechsel von 2023 als Ableger von Terraform entstanden. Ein Unternehmen, das seine eigene Infrastruktur beschreibt, kann das eine oder das andere nutzen. Die Wahl fällt nach der Governance des Projekts, den unterstützten Anbietern und den Gewohnheiten des Teams oder des Dienstleisters, der es betreiben wird.

Muss man alles beschreiben, bevor man anfängt?

Nein. Beginnen Sie mit den Diensten, mit getrennten Daten, dann mit der Konfiguration der Maschine, dann mit den Ressourcen beim Anbieter. Jeder Schritt hat für sich allein seinen Wert. Wichtig ist, den Wiederaufbau schon ab dem ersten Schritt auf einer neuen Maschine zu testen und danach jede Änderung über die Dateien statt über den Server laufen zu lassen.

Ersetzt Infrastructure as Code die Sicherungen?

Nein. Sie erzeugt eine konfigurierte, aber leere Maschine. Die Daten Ihrer Werkzeuge, etwa Kundendatensätze, Rechnungen oder hochgeladene Dateien, kommen nur über die Sicherungen zurück, vorausgesetzt, eine Wiederherstellung wurde getestet. Beides ergänzt sich: Die Beschreibung baut den Server neu auf, die Sicherung stellt seinen Inhalt wieder her, und der Wiederherstellungsplan sagt, in welcher Reihenfolge.

Quellen

  1. Microsoft Learn, What is infrastructure as code? (neuer Tab)learn.microsoft.com
  2. HashiCorp, Ankündigung vom 10. August 2023 (neuer Tab)hashicorp.com
  3. OpenTofu, Website des Projekts (neuer Tab)opentofu.org
Quelle 1

Microsoft Learn, What is infrastructure as code?

Auf learn.microsoft.com lesen(neuer Tab)
Quelle 2

HashiCorp, Ankündigung vom 10. August 2023

Auf hashicorp.com lesen(neuer Tab)
Quelle 3

OpenTofu, Website des Projekts

Auf opentofu.org lesen(neuer Tab)

Jim · Gründer von Brain Plus AI

Ebenfalls lesenswert zu infrastruktur und cloud

  • Praxisleitfaden12 Min. Der Leitfaden zum Thema

    Cloud-Infrastruktur: das gemeinsame Fundament all Ihrer Projekte

    Vor dem ersten Projekt regelt ein Fundament der Cloud-Infrastruktur ein für alle Mal Konten, Zugänge, Backups und Budget, und jedes folgende Projekt erbt es. Was es enthält, wo man es aufsetzt, was es kostet und warum sein Betrieb mehr zählt als seine Einrichtung.

  • Verstehen6 Min.

    Cloud and AI Development Act: Rechenzentren verdreifachen

    Der am 3. Juni 2026 vorgestellte Cloud and AI Development Act will die Kapazität europäischer Rechenzentren verdreifachen und ein vierstufiges Souveränitätsraster für die öffentliche Beschaffung von Cloud-Diensten schaffen. Was der Vorschlag enthält, wo die Verhandlungen stehen und was für die Wahl eines Hosters heute weiterhin gilt.

  • Verstehen7 Min.

    Data Act: keine Cloud-Ausstiegsgebühren mehr ab Januar 2027

    Ab dem 12. Januar 2027 darf ein Cloud-Anbieter den Anbieterwechsel nicht mehr in Rechnung stellen, und neue vernetzte Geräte geben ihre Daten bereits an ihre Nutzer heraus. Was Sie dank des Data Act verlangen können, und was er Ihnen nicht abnimmt.

WhatsApp