--- title: "Infrastructure as Code mit Terraform & OpenTofu | SKAFFON" description: "Terraform- und OpenTofu-Beratung: Modulstruktur, Remote-State mit Sperre, Policy-Prüfung, Drift-Erkennung und Secrets. Mit Reifegrad-Checkliste." url: https://skaffon.de/leistungen/infrastructure-as-code/ --- ![Aufgeklappter Laptop in dunkler Umgebung, auf dem Bildschirm Projektbaum und Terminal-Ausgabe eines Testlaufs](/_astro/laptop-terminal-code-dunkel.63oD2l6E_ZCJXeN.jpg) 1. [Startseite](/) 2. [Leistungen](/leistungen/) 3. Infrastructure as Code: Terraform- und OpenTofu-Beratung Terraform · OpenTofu · Crossplane # Infrastructure as Code: Terraform- und OpenTofu-Beratung Ihre Umgebung als Code: neu aufbaubar, im Pull Request prüfbar und ohne Angst vor dem nächsten Apply. Wir bringen State, Module, Pipeline und Policies in einen Zustand, den Ihr Team selbst weiterentwickeln kann. [Projekt anfragen](/projekt-anfragen/) [Zum Repository-Layout](/leistungen/infrastructure-as-code/#ein-state-je-lebenszyklus) - Remote-State mit Sperre - Plan im Pull Request, Apply nach Freigabe - Policy-Prüfung und Drift-Erkennung Autor: [Ibrahim Yesilay](/unternehmen/ibrahim-yesilay/), Gründer und Geschäftsführer Stand: 13.11.2026 Ausgangslage ## Wenn die Umgebung nur noch in den Köpfen existiert SKAFFON berät und baut Infrastructure as Code für Unternehmen, die Cloud- und Kubernetes-Umgebungen reproduzierbar, prüfbar und per Pull Request änderbar betreiben wollen. Wir arbeiten mit Terraform und [OpenTofu](https://opentofu.org/), und wo es passt mit Crossplane. Die Seite richtet sich an Platform- und Infrastruktur-Teams. Wer den größeren Rahmen aus Pipelines, GitOps und Release sucht, findet ihn in der [DevOps-Beratung](/leistungen/devops-automatisierung/). - Infrastruktur wurde über Konsolen angeklickt; niemand kann die Umgebung neu aufbauen. - State liegt lokal oder in einem ungesicherten Bucket, und zwei Personen können gleichzeitig anwenden. - Ein Modul wurde kopiert und pro Umgebung leicht verändert; Änderungen müssen mehrfach eingepflegt werden. - Niemand weiß, ob die reale Umgebung noch dem Code entspricht. - Zugangsdaten stehen in Variablen oder im State. ![Dunkle Reihen von Serverschränken im Rechenzentrum mit roten und grünen Statusleuchten](/_astro/dunkle-serverschraenke-statusleuchten.DSrfwUu5_1lQtdR.jpg) Vorgehen ## Von der Handarbeit zum reviewbaren Code in sieben Schritten Bestehende, manuell erstellte Ressourcen können wir übernehmen (Import); das ist Aufwand und wird im Angebot gesondert ausgewiesen. 1. 01 ### Bestandsaufnahme Ergebnis: Übernahmeplan Was ist Code, was ist Handarbeit, was ist Drift? Das Ergebnis ist ein Übernahmeplan mit Priorisierung. 2. 02 ### Modulkonzept Ergebnis: Modulbibliothek Wiederverwendbare Module mit klarer Schnittstelle, Versionierung und Tests; Trennung von Umgebungen. 3. 03 ### State-Betrieb Ergebnis: sicheres Backend Remote-Backend, Sperre, Zugriffsmodell, Sicherung und Aufteilung nach Blast Radius, wie im Layout unten gezeigt. 4. 04 ### Pipeline Ergebnis: Änderungsablauf Plan im Pull Request, Apply nach Freigabe, zum Beispiel mit GitLab CI oder GitHub Actions ([CI/CD-Pipelines](/leistungen/ci-cd-pipelines/)) oder mit [Atlantis](https://www.runatlantis.io/docs/), das laut Dokumentation Terraform und OpenTofu mit Locking und Autoplanning unterstützt. 5. 05 ### Policy und Drift Ergebnis: Regeln als Code Regeln als Code, die vor dem Apply prüfen, und ein regelmäßiger Abgleich von Soll und Ist. 6. 06 ### Secrets Ergebnis: Secrets-Konzept Keine Klartext-Geheimnisse im Repository, Anbindung an einen Secret-Store und ein Umgang mit sensiblen Werten im State. 7. 07 ### Übergabe Ergebnis: Ihr Team kann es Dokumentation, Runbooks und Schulung. Ihr Team soll Module selbst weiterentwickeln. Werkzeugwahl ## Terraform, OpenTofu oder Crossplane: wofür welches Werkzeug Die Matrix ist ein Bewertungsraster, keine Rangliste. Lizenz- und Roadmap-Details der Werkzeuge ändern sich; prüfen Sie sie in der jeweiligen Dokumentation. __Terraform/OpenTofu und Crossplane im Vergleich__ | Frage | Terraform / OpenTofu | Crossplane | | ------------------- | ---------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Arbeitsweise | Plan/Apply-Zyklus aus Dateien mit State | Kubernetes-Ressourcen (Composition, Managed Resources); laut [Crossplane-Dokumentation](https://docs.crossplane.io/v2.4/) ein „control plane framework for platform engineering“ | | Wo läuft die Logik? | In CI-Läufen oder auf Anfrage | Im Kubernetes-Cluster, über die Kubernetes-API | | Wann passt es? | Fundament: Konten, Netzwerke, Cluster, Landing Zones | Self-Service-Bereitstellung aus Kubernetes heraus, zum Beispiel im Rahmen einer [Developer-Plattform](/leistungen/platform-engineering/) | | Voraussetzung | Sicherer State-Betrieb | Ein bereits betriebener Kubernetes-Verwaltungscluster | | Typischer Fehler | Alles in einem State, großer Blast Radius | Plattform-API zu früh und zu groß entworfen | In der Praxis kombinieren wir beides: Fundament mit Terraform oder OpenTofu, Self-Service-Schicht darüber, wenn eine Plattformstrategie es rechtfertigt. Die Wahl zwischen Terraform und OpenTofu treffen wir nach Ihren Lizenz- und Betriebsvorgaben; beide folgen dem Schreib-, Plan- und Apply-Ablauf. Auf Azure ist Bicep eine Option, siehe [Azure-Beratung](/cloud/azure-beratung/). Repository-Layout ## Ein State je Lebenszyklus: so schneiden wir das Repository Die Struktur trennt wiederverwendbare Module von umgebungsspezifischer Komposition. Jede Umgebungskomponente hat einen eigenen State, damit ein Fehler nicht die gesamte Plattform betrifft. ``` infra/ modules/ # versionierte, getestete Bausteine network/ kubernetes-cluster/ postgres/ live/ prod/ network/ # eigener State cluster/ # eigener State, liest Outputs aus network data/ staging/ network/ cluster/ policies/ # Policy als Code, im Pull Request geprüft .ci/ # Plan im PR, Apply nach Freigabe ``` 1. **Ein State je Lebenszyklus und Zuständigkeit.** Netzwerk ändert sich selten, Anwendungsressourcen oft; getrennte States begrenzen den Schaden eines fehlerhaften Apply. 2. **Module versionieren.** Umgebungen referenzieren feste Modulversionen; ein Update ist ein bewusster Pull Request. 3. **Keine Kopien pro Umgebung.** Unterschiede laufen über Variablen, nicht über Forks von Modulen. ## Module, States und Änderungsablauf im Zusammenhang Der Änderungsablauf: Pull Request, plan, Review, apply, mit Sperre am State. Der Änderungsablauf: Pull Request, plan, Review, apply, mit Sperre am State. State-Audit ## Sechs Prüfpunkte, an denen sich sicherer State-Betrieb zeigt OpenTofu speichert den Zustand [standardmäßig in einer lokalen Datei](https://opentofu.org/docs/language/state/) und empfiehlt für Teams eine Lösung, die State versioniert, verschlüsselt und sicher teilt. Wir prüfen: - **Remote-Backend vorhanden.** Kein lokaler State auf Arbeitsplätzen. - **Sperre wirksam.** Nicht jedes Backend unterstützt Sperren; das steht laut [OpenTofu-Dokumentation](https://opentofu.org/docs/language/state/backends/) in der Doku des jeweiligen Backends. Beispiel STACKIT: Laut README des [STACKIT-Terraform-Providers](https://github.com/stackitcloud/terraform-provider-stackit) (Stand der Prüfung: 13.11.2026) hat die S3-Option `use_lockfile` mit STACKIT Object Storage keine Wirkung; empfohlen wird ein PostgreSQL-Backend für die State-Sperre. Prüfen Sie diesen Hinweis vor der Umsetzung gegen die aktuelle Provider-Dokumentation. - **Zugriff nach minimalen Rechten.** State kann sensible Werte enthalten; Lesezugriff gilt als sensibel. - **Sicherung und Wiederherstellung** des State getestet. - **Beta- und Experimentierfunktionen kennen.** Der STACKIT-Provider kennzeichnet einzelne Ressourcen als Beta oder Experiment ohne Support-Zusage; solche Ressourcen setzen wir nur bewusst und dokumentiert ein. - **Drift-Lauf** geplant und Ergebnis wird einer Person zugewiesen. Zugriff und Grenzen ## Der Apply läuft mit Ihren Rechten, nicht mit unseren Zugangsdaten bleiben bei Ihnen; Pipelines erhalten nur die Rechte, die der Apply benötigt. Wir arbeiten in Ihren Repositories und Konten, zeitlich und rollenbasiert begrenzt. Policy-Prüfung unterstützt Ihre Vorgaben, ersetzt aber keine Compliance-Bewertung. Technische Absicherung finden Sie unter [Cloud Security](/cybersecurity/cloud-security/). [Landing Zone mit IaC](/leistungen/landing-zone-iac/) ![Nahaufnahme eines Rechenzentrums-Switches mit Glasfaser-Transceivern und türkisfarbenen Anschlusskabeln](/_astro/netzwerk-switch-glasfaser-transceiver.BEiEweYs_Z26iQck.jpg) Passung ## Wann sich ein IaC-Projekt nicht lohnt ### Das passt - Mehrere Umgebungen oder Plattformen, die sich häufig ändern und reproduzierbar sein müssen. - Verantwortliche für Plattform und Sicherheit sind benannt und tragen den Betrieb mit. ### Das passt nicht - Sie haben eine einzelne, selten geänderte Umgebung; der Aufwand für eine Modulstruktur lohnt sich nicht. - Sie wollen ein Werkzeug gekauft bekommen, ohne Verantwortliche für den Betrieb zu benennen. - Sie suchen reine Schulung; für Cloud-native Lernpfade siehe [GoldenKube](/produkte/goldenkube/), ein separates Produkt. Voraussetzungen ## Zugänge und Unterlagen, die den IaC-Start ermöglichen - Lesender Zugriff auf Ihre Konten oder Projekte - Vorhandener Code und State - Liste der Plattformen, zum Beispiel STACKIT, AWS, Azure, Google Cloud, Proxmox, Kubernetes - Ihre Freigabe- und Compliance-Vorgaben - Das eingesetzte Quellcode- und CI-System - Verantwortliche für Plattform und Sicherheit Aufwand ## Was den Aufwand eines IaC-Projekts bestimmt Den Aufwand bestimmen die Zahl der Plattformen und Umgebungen, der Umfang des Imports vorhandener Ressourcen, der Modulbedarf, Policy- und Freigabeanforderungen sowie der Anteil von Beratung, Umsetzung und Schulung. ## Wie sieht Ihr State heute aus? Beschreiben Sie Ihre Umgebung und den heutigen Umgang mit State; wir sagen Ihnen, womit die Übernahme beginnt. [Projekt anfragen](/projekt-anfragen/) [Alle Leistungen](/leistungen/)