Projekt anfragen
Aufgeklappter Laptop in dunkler Umgebung, auf dem Bildschirm Projektbaum und Terminal-Ausgabe eines Testlaufs

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 Zum Repository-Layout
  • Remote-State mit Sperre
  • Plan im Pull Request, Apply nach Freigabe
  • Policy-Prüfung und Drift-Erkennung

Autor: Ibrahim Yesilay, Gründer und Geschäftsführer Stand:

01Ausgangslage

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, 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.

  • 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

02Vorgehen

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) oder mit Atlantis, 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.

03Werkzeugwahl

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
FrageTerraform / OpenTofuCrossplane
ArbeitsweisePlan/Apply-Zyklus aus Dateien mit StateKubernetes-Ressourcen (Composition, Managed Resources); laut Crossplane-Dokumentation ein „control plane framework for platform engineering“
Wo läuft die Logik?In CI-Läufen oder auf AnfrageIm Kubernetes-Cluster, über die Kubernetes-API
Wann passt es?Fundament: Konten, Netzwerke, Cluster, Landing ZonesSelf-Service-Bereitstellung aus Kubernetes heraus, zum Beispiel im Rahmen einer Developer-Plattform
VoraussetzungSicherer State-BetriebEin bereits betriebener Kubernetes-Verwaltungscluster
Typischer FehlerAlles in einem State, großer Blast RadiusPlattform-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.

04Repository-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.

05

Module, States und Änderungsablauf im Zusammenhang

Repository- und State-Layout für Infrastructure as Code Versionierte Module werden von Umgebungskomponenten mit jeweils eigenem State genutzt; der Pull-Request-Ablauf führt über plan, Review und apply, der State ist gesperrt. REPOSITORY-LAYOUTÄNDERUNGSABLAUF modules/ versioniert, getestet Version v1.2 live/prod/network live/prod/cluster live/prod/data live/staging/network live/staging/cluster State Outputs lesen Pull Request plan + Policy-Prüfung Review und Freigabe apply State gesperrt während apply Je Umgebungskomponente ein eigener State, um den Blast Radius zu begrenzen.
Der Änderungsablauf: Pull Request, plan, Review, apply, mit Sperre am State.
Repository- und State-Layout für Infrastructure as Code Versionierte Module werden von Umgebungskomponenten mit jeweils eigenem State genutzt; der Pull-Request-Ablauf führt über plan, Review und apply, der State ist gesperrt. REPOSITORY-LAYOUT modules/ versioniert, getestet Version v1.2 live/prod/network live/prod/cluster live/prod/data live/staging/network live/staging/cluster Outputs lesen State ÄNDERUNGSABLAUF Pull Request plan + Policy-Prüfung Review und Freigabe apply State gesperrt während apply Je Umgebungskomponente ein eigener State,um den Blast Radius zu begrenzen.
Der Änderungsablauf: Pull Request, plan, Review, apply, mit Sperre am State.

06State-Audit

Sechs Prüfpunkte, an denen sich sicherer State-Betrieb zeigt

OpenTofu speichert den Zustand standardmäßig in einer lokalen Datei 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 in der Doku des jeweiligen Backends. Beispiel STACKIT: Laut README des STACKIT-Terraform-Providers (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.

07Zugriff 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.

Landing Zone mit IaC

Nahaufnahme eines Rechenzentrums-Switches mit Glasfaser-Transceivern und türkisfarbenen Anschlusskabeln

08Passung

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, ein separates Produkt.

09Voraussetzungen

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

10Aufwand

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 Alle Leistungen