Zum Inhalt springen
Beta

Automatisierung (IaC)

In 3 Trails

Zuletzt aktualisiert am

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.

  • STACKIT API: Nutzen Sie die API als grundlegende Steuerungsschnittstelle für Plattformautomatisierung und Integrationsmuster. Dokumentation
  • Terraform Provider: Nutzen Sie den offiziellen Provider für deklarative Infrastruktur-Bereitstellung und Lifecycle-Steuerung. Dokumentation
  • OpenTofu Provider: Nutzen Sie OpenTofu mit dem STACKIT Provider als offene IaC-Option mit vergleichbaren deklarativen Workflows. Dokumentation
  • Pulumi: Nutzen Sie Pulumi, wenn Teams für Infrastruktur-Automatisierung allgemeine Programmiersprachen bevorzugen. Dokumentation
  • 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. Dokumentation
  • SDKs (Go, Python, Java): Nutzen Sie SDKs für kundenspezifische Automatisierung und Service-Integrationen, wenn IaC-Abstraktionen nicht ausreichen. Go SDK , Python SDK , Java SDK .
  • STACKIT Git: Nutzen Sie Git als Source of Truth für IaC-Module, Policies und Delivery-Workflows. Dokumentation
  • CI/CD Pipeline: Nutzen Sie Pipelines für Validierung, Policy-Prüfungen, kontrollierte Promotion und auditierbare Releases. Dokumentation
  • Container Registry: Nutzen Sie eine zentrale Registry für versionierte Build-Artefakte und konsistente Deployments über Umgebungen hinweg. Dokumentation
  • 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.

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.

Terraform / OpenTofu

Verantwortet den Infrastruktur-Lifecycle: Projekte, Netzwerke, Sicherheitskontrollen, Compute, Storage, Managed Services und die für das Konfigurationsmanagement benötigten Outputs.

Ansible

Verantwortet die Konfiguration im erreichbaren Ziel: Betriebssystempakete, Middleware, Applikationsartefakte, Service Units und die Validierung auf Workload-Ebene.

  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.

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.

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