Das Problem
In vielen Unternehmen existiert die Infrastruktur zweimal: als laufende Systeme und im Kopf der Person, die sie aufgebaut hat. Fällt diese Person aus, beginnt bei jeder Störung die Suche. Dokumentation wurde irgendwann geschrieben und seitdem nicht gepflegt. Und nach einem Totalausfall müsste man die Umgebung aus Erinnerungen, alten Screenshots und Konfigurationsdateien zusammensetzen.
Infrastructure as Code gilt oft als Thema für AWS, Azure und große DevOps-Teams. Das Prinzip funktioniert aber genauso für einen Proxmox-Cluster, Linux-Server, eine Firewall oder DNS-Einträge im Mittelstand.
Dokumentierte Infrastruktur oder Infrastruktur, aus der Dokumentation entsteht
| Dokumentierte Infrastruktur | Infrastruktur, aus der Dokumentation entsteht |
|---|---|
| Jemand schreibt auf, was er vorfindet. | Die Umgebung ist als Code beschrieben; Inventar und Netzplan werden daraus erzeugt. |
| Stimmt am Tag der Abgabe. | Bleibt aktuell, solange Änderungen über den Code laufen. |
| Änderungen werden vergessen. | Jede Änderung im Code ist ein Eintrag in Git: wer, wann, warum. |
| Wiederaufbau: Handarbeit nach Anleitung. | Wiederaufbau: Code erneut ausführen und das Runbook abarbeiten. |
Unsere Lösung
Wir nehmen Ihre Umgebung auf und überführen sie Schritt für Schritt in Code, ohne den Betrieb zu unterbrechen: virtuelle Maschinen und Ressourcen in Terraform, Betriebssysteme und Dienste in Ansible, Zugangsdaten verschlüsselt im Vault. Alles liegt in einem Git-Repository – in Ihrem GitLab oder bei uns gehostet. Daraus entstehen Inventar und Netzplan in NetBox, die Monitoring-Konfiguration und ein Runbook für den Wiederaufbau. Wo genau die Grenze zwischen beiden Werkzeugen verläuft, beschreiben wir im Beitrag Terraform und Ansible: wer konfiguriert was.
Vom Code zum Wiederanlauf
Was automatisch kommt – und was nicht
| Quelle | Was daraus übernommen wird |
|---|---|
| Terraform | VM-Größen (vCPU, RAM, Disk), DNS-Einträge, Zugänge |
| Ansible | Hosts, Gruppen, Dienste und ihre Konfiguration |
| Proxmox | laufende VMs und Container, IP-Adressen, Interfaces, MAC-Adressen |
| LLDP der Switches | welches Kabel an welchem Port steckt |
| OPNsense | Interfaces, VLANs, VPN-Verbindungen |
| Git | Historie aller Änderungen am Code |
| NetBox | führt alles zusammen und erzeugt Netzpläne |
Weiterhin manuell gepflegt: Zweck und Verantwortliche eines Systems, Verträge und Ansprechpartner, Geräte ohne Schnittstelle (z. B. ältere Switches, Drucker), Rack-Positionen. Unsichere Daten werden in NetBox als „zu prüfen“ markiert, bis jemand sie bestätigt hat.
Wann sich die Doku aktualisiert: bei jedem Abgleich, nicht in Echtzeit.
Was sich als Code abbilden lässt
- Proxmox-Cluster und virtuelle Maschinen
- Linux-Server und Dienste
- Firewall (OPNsense)
- Switches (VLANs, Link-Aggregation, SNMP)
- DNS-Einträge, auch auf Windows-DNS-Servern
- Microsoft 365, z. B. Verteilerlisten
- Monitoring-Ziele
- Dokumentation
Grenzen
Nicht alles lässt sich vollständig als Code beschreiben. Ältere Switches, Geräte ohne Schnittstelle und manche Einstellungen in Windows oder Microsoft 365 bleiben teilweise Handarbeit. Das halten wir offen fest, statt es zu verschweigen.
Code beschreibt außerdem nur dann die Wirklichkeit, wenn Änderungen auch über den Code laufen. Wer an der Konsole ändert, erzeugt Abweichungen. Ob Code und Umgebung übereinstimmen, zeigt ein Terraform-Plan oder ein Ansible-Lauf im Prüfmodus. Wie oft wir das prüfen, legen wir mit Ihnen fest.
Ergebnis
- Das Wissen über Ihre Infrastruktur steckt im Code, nicht nur in einzelnen Köpfen.
- Änderungen sind nachvollziehbar und lassen sich prüfen, bevor sie wirken.
- Inventar und Netzplan bleiben aktuell, solange Änderungen über den Code laufen.
- Ein Runbook beschreibt den Wiederaufbau auf neuer Hardware Schritt für Schritt.
- Ihr Team kann weiterarbeiten – oder ein anderer Dienstleister übernehmen.
So gehen wir vor
- Bestandsaufnahme – Systeme, Netz, Zugänge, vorhandene Dokumentation.
- Repository-Gerüst – Struktur, Zugangsdaten-Verwaltung, Zugriff für Ihr Team.
- Ressourcen abbilden – VMs, DNS und Zugänge in Terraform.
- Konfiguration abbilden – Betriebssysteme und Dienste in Ansible.
- Abgleich – Code und Live-Umgebung stimmen überein.
- Dokumentation – NetBox befüllen, Netzplan erzeugen.
- Runbook – Wiederaufbau-Reihenfolge festlegen.
- Übergabe – Workshop für Ihr Team, optional laufende Pflege durch uns.
Leistungsumfang
- Bestandsaufnahme
- Repository bei Ihnen oder bei uns
- Terraform für Ressourcen
- Ansible für Konfiguration
- verschlüsselte Zugangsdaten
- NetBox
- Anbindung an das Monitoring
- Kaltstart-Runbook
- Datenschutz-Übersicht für Ihren Datenschutzbeauftragten
- Übergabe-Workshop
Technischer Einblick
- Terraform mit
bpg/proxmox, Cloudflare- und Hetzner-Provider; ein Modul pro Umgebung, wiederverwendet über Git-Submodule. - Ansible ≥ 2.18, Rollen pro Dienst, idempotente Playbooks, Ansible Vault (AES256) für Zugangsdaten.
- NetBox mit idempotentem Loader: Daten aus Repository, Terraform, Proxmox (
qm/pct), LLDP und OPNsense; Netzpläne als Mermaid und Graphviz. - GitLab mit Runnern für Pipelines. Self-Service per Merge Request ist möglich: Ein Team ändert DNS-Einträge oder Verteilerlisten in einer YAML-Datei, die Pipeline setzt um – ohne dass jemand die Zugangsdaten sieht.
- Datenschutz: Für eine Kundenumgebung haben wir eine Übersicht für den Datenschutzbeauftragten erstellt: welche Daten wo liegen, wer Zugriff hat.
Warum cloudbase.run
- Wir arbeiten selbst so. Unsere eigene Infrastruktur – Proxmox-Cluster, Switches, Firewall, Dienste – verwalten wir über Git, Terraform und Ansible.
- Erprobt bei Kunden. Für ein Einkaufszentrum haben wir einen Proxmox-Cluster mit fünf Nodes als Code abgebildet, inklusive eigener NetBox und Runbook für den Wiederaufbau auf neuer Hardware.
- Für klassische Infrastruktur. Wir wenden das Prinzip auf Proxmox, Linux, Netzwerk und Windows-DNS an – nicht nur auf Public Cloud.
- Nachweisbar. Änderungshistorie und belegter Soll-Zustand helfen bei Audits, etwa bei der TISAX-Vorbereitung.
Für wen geeignet
- Unternehmen mit eigenem Proxmox- oder Linux-Betrieb
- Umgebungen, die stark an einzelnen Personen hängen
- Betreiber, die einen Wiederaufbau nach Totalausfall planen müssen
Für wen nicht geeignet
- Reine Arbeitsplatz-Landschaften ohne eigene Server
- Organisationen, die Änderungen dauerhaft direkt an der Konsole machen wollen – dann veraltet der Code