---
title: Automatisierung (IaC)
description: Nutzen Sie Infrastructure as Code und Policy as Code für eine konsistente, wiederholbare und auditierbare Landing-Zone-Bereitstellung auf STACKIT Cloud heute.
sidebar:
  label: Automatisierung (IaC)
  order: 15
source_url: "https://framework.stackit.cloud/de/migration/design-and-mobilize/landing-zones/automation-iac/"
source_file: "docs/de/migration/design-and-mobilize/landing-zones/automation-iac.mdx"
---

## Zielbild

Automatisierung stellt sicher, dass Landing-Zone-Funktionen reproduzierbar, versioniert und testbar bereitgestellt werden.

Für Migrations-Landing-Zones ist Automatisierung das Delivery-Rückgrat, das Plattform-APIs, IaC-Werkzeuge, Entwickler-Workflows und Release-Kontrollen in ein verlässliches Betriebsmodell überführt.

## Kernbausteine der Automatisierung

- **STACKIT API**: Nutzen Sie die API als grundlegende Steuerungsschnittstelle für Plattformautomatisierung und Integrationsmuster. <LinkChip href="https://docs.stackit.cloud/de/developer-tools/stackit-api/">Dokumentation</LinkChip>
- **Terraform Provider**: Nutzen Sie den offiziellen Provider für deklarative Infrastruktur-Bereitstellung und Lifecycle-Steuerung. <LinkChip href="https://registry.terraform.io/providers/stackitcloud/stackit/latest/docs">Dokumentation</LinkChip>
- **OpenTofu Provider**: Nutzen Sie OpenTofu mit dem STACKIT Provider als offene IaC-Option mit vergleichbaren deklarativen Workflows. <LinkChip href="https://search.opentofu.org/provider/stackitcloud/stackit/latest">Dokumentation</LinkChip>
- **Pulumi**: Nutzen Sie Pulumi, wenn Teams für Infrastruktur-Automatisierung allgemeine Programmiersprachen bevorzugen. <LinkChip href="https://github.com/stackitcloud/pulumi-stackit">Dokumentation</LinkChip>
- **Ansible**: Nutzen Sie Ansible primär für Post-Provisioning-Konfiguration und Betriebsaufgaben. In einem kombinierten Modell stellen Terraform/OpenTofu die Infrastruktur bereit, während Ansible OS- und Middleware-Konfiguration übernimmt.
- **STACKIT CLI**: Standardisieren Sie CLI-basierte Operationen für Skripting, Fehleranalyse und wiederholbare Betriebsaufgaben. <LinkChip href="https://docs.stackit.cloud/de/developer-tools/stackit-cli/">Dokumentation</LinkChip>
- **SDKs (Go, Python, Java)**: Nutzen Sie SDKs für kundenspezifische Automatisierung und Service-Integrationen, wenn IaC-Abstraktionen nicht ausreichen. <LinkChip href="https://docs.stackit.cloud/de/developer-tools/stackit-sdk/stackit-go-sdk/">Go SDK</LinkChip>, <LinkChip href="https://docs.stackit.cloud/de/developer-tools/stackit-sdk/stackit-python-sdk/">Python SDK</LinkChip>, <LinkChip href="https://docs.stackit.cloud/de/developer-tools/stackit-sdk/stackit-java-sdk/">Java SDK</LinkChip>.
- **STACKIT Git**: Nutzen Sie Git als Source of Truth für IaC-Module, Policies und Delivery-Workflows. <LinkChip href="https://docs.stackit.cloud/de/products/developer-platform/git/basics/introduction-to-stackit-git/">Dokumentation</LinkChip>
- **CI/CD Pipeline**: Nutzen Sie Pipelines für Validierung, Policy-Prüfungen, kontrollierte Promotion und auditierbare Releases. <LinkChip href="https://docs.stackit.cloud/de/products/developer-platform/git/basics/stackit-pipelines/">Dokumentation</LinkChip>
- **Container Registry**: Nutzen Sie eine zentrale Registry für versionierte Build-Artefakte und konsistente Deployments über Umgebungen hinweg. <LinkChip href="https://docs.stackit.cloud/de/products/developer-platform/container-registry/basics/introduction-to-container-registry/">Dokumentation</LinkChip>

## Wie die Bausteine zusammenspielen

- **Steuerungsschicht**: STACKIT API, CLI und SDKs liefern direkte und programmierbare Steuerungsschnittstellen.
- **Provisioning-Schicht**: Terraform/OpenTofu und Pulumi definieren und synchronisieren den gewünschten Infrastrukturzustand.
- **Konfigurationsschicht**: Ansible setzt Host- und Middleware-Konfiguration nach dem Infrastruktur-Provisioning um.
- **Delivery-Schicht**: Git und CI/CD Pipelines erzwingen Qualitäts-Gates, Policy-Prüfungen und kontrollierten Rollout über Umgebungen.
- **Artefakt-Schicht**: Die Container Registry liefert unveränderliche und versionierte Artefakte für vorhersehbare Deployments.

## Delivery-Flow mit Terraform/OpenTofu und Ansible

Terraform oder OpenTofu und Ansible lösen unterschiedliche Aufgaben innerhalb eines Delivery-Flows.
Halten Sie die Grenze explizit, damit Infrastrukturänderungen prüfbar und Host-Konfigurationen
wiederholbar bleiben.

<CardGrid>
  <Card title="Terraform / OpenTofu">
    Verantwortet den Infrastruktur-Lifecycle: Projekte, Netzwerke, Sicherheitskontrollen, Compute,
    Storage, Managed Services und die für das Konfigurationsmanagement benötigten Outputs.
  </Card>
  <Card title="Ansible">
    Verantwortet die Konfiguration im erreichbaren Ziel: Betriebssystempakete, Middleware,
    Applikationsartefakte, Service Units und die Validierung auf Workload-Ebene.
  </Card>
</CardGrid>

<Steps>

1. Versionieren Sie Infrastruktur-Inputs, Konfiguration und Referenzen auf Applikationsartefakte in Git.
2. Validieren und prüfen Sie den Terraform/OpenTofu-Plan einschließlich Ersetzungen und Security-Auswirkungen.
3. Wenden Sie den freigegebenen Plan an und übergeben Sie nur das von Ansible benötigte Zielinventar und die erforderlichen Outputs.
4. Führen Sie Ansible idempotent aus, um Betriebssystem, Middleware, Workload und Telemetrie zu konfigurieren.
5. Validieren Sie Infrastrukturzustand, Service Health und betriebliche Kontrollen und bewahren Sie die Nachweise auf.
6. Promoten Sie denselben versionierten Workflow durch die Umgebungen, statt manuelle Einrichtungsschritte zu wiederholen.

</Steps>

Verwischen Sie die Zuständigkeit beider Ebenen nicht durch Provisioner oder Ad-hoc-Skripte. Ansible
aus Terraform anzustoßen kann eine praktische Brücke sein, aber jedes Werkzeug muss eigenständig
verständlich, testbar und wiederholbar bleiben.

## Empfohlenes Betriebsmodell

- **Empfehlung 1**: Nutzen Sie Git plus CI/CD als Standard-Steuerungspfad und vermeiden Sie direkte manuelle Änderungen in produktiven Scopes.
- **Empfehlung 2**: Wählen Sie je Plattformdomäne ein primäres IaC-Tool (Terraform oder OpenTofu), um Fragmentierung zu reduzieren.
- **Empfehlung 3**: Nutzen Sie Ansible für Konfigurationsmanagement, nicht als Ersatz für deklaratives Infrastruktur-Provisioning.
- **Empfehlung 4**: Nutzen Sie SDKs für domänenspezifische Automatisierung, wenn Provider-Ressourcen das gewünschte Verhalten nicht abdecken.
- **Empfehlung 5**: Versionieren und promoten Sie Container-Artefakte über klare Umgebungsstufen mit rollbackfähigen Tags.

## Wichtige Entscheidungen

- **Automatisierungs-Schnittstellenstrategie**: Definieren Sie, wo API, CLI, SDK und IaC-Werkzeuge als Primärschnittstellen eingesetzt werden.
- **IaC-Tool-Strategie**: Entscheiden Sie Terraform versus OpenTofu versus Pulumi anhand von Skills, Governance und Ecosystem-Fit.
- **Modul- und Repository-Strategie**: Definieren Sie wiederverwendbare Modulgrenzen, Versionierung und Ownership.
- **Pipeline-Control-Modell**: Implementieren Sie Validierung, Policy-Prüfungen, Freigaben und Promotion-Gates.
- **Artefakt- und Release-Strategie**: Definieren Sie Registry-Nutzung, Image-Versionierung und Rollback-Standards.

## Typische Ergebnisse

- **Wiederverwendbare Automatisierungs-Baseline**: IaC-Module, Templates und Konfigurations-Playbooks mit Ownership-Modell.
- **Delivery-Blueprint**: CI/CD-Flow mit Qualitäts-Gates, Policy-Prüfungen und gestufter Promotion.
- **Integrations-Toolkit**: Standardisierte Nutzung von CLI- und SDK-Automatisierung für Betrieb und produktspezifische Workflows.
- **Release-Baseline**: Versionierter Artefakt-Lifecycle in der Container Registry mit rollbackfähigen Praktiken.

## Typische Anti-Patterns

- **Zu viele Automatisierungs-Paradigmen**: Parallele Tool-Stacks ohne klare Ownership oder Governance-Modell.
- **Provisioning und Konfiguration ad hoc vermischt**: Keine klare Trennung zwischen IaC-Provisioning und Ansible-Konfiguration.
- **Keine Artefakt-Disziplin**: Veränderliche Container-Tags und unklare Release-Nachverfolgbarkeit.
- **CLI-Skripte ohne Git- und Pipeline-Kontrollen**: Betriebsautomatisierung ist nicht verlässlich auditierbar oder reproduzierbar.