Tools für die Migration zu STACKIT

Vier Aufgaben, vier Arten von Tools

• Erfassen und bewerten

  Wissen, was heute läuft, wie es voneinander abhängt und was jeder Teil auf STACKIT wird. StackToIT tut das aus Infrastrukturcode und RVTools-Exporten; Discovery-Plattformen tun es aus der laufenden Umgebung.

• Ziel entwerfen und aufbauen

  Die STACKIT-Infrastruktur als Code beschreiben und erstellen. Der STACKIT Terraform Provider, der Pulumi-Provider, die CLI und die SDKs sind die plattformeigenen Werkzeuge dafür.

• Workloads und Daten bewegen

  Virtuelle Maschinen replizieren, Kubernetes-Workloads neu ausrollen oder wiederherstellen, Buckets kopieren und Datenbanken migrieren. Jedes hat sein eigenes Tool, gewählt je Workload.

• Betreiben

  Nach dem Cutover übernehmen die Plattformdienste von STACKIT und Ihre bestehende Delivery- und Monitoring-Praxis. Die Migrationstools sind dann nicht mehr im Spiel.

Welches Tool was tut

Die Phasen folgen dem STACKIT Cloud Framework: Assess, Design and Mobilize, Migrate, Run. Eine Zeile je Tool oder Toolfamilie, mit der Aufgabe, für die es tatsächlich gebaut ist.

Alle Produkte gehören ihren jeweiligen Herstellern und Projekten. Die Nennung beschreibt, was sie tun; sie bedeutet keine Partnerschaft oder Integration mit StackToIT.

Bewerten und planen: StackToIT, Discovery-Plattformen und das STACKIT-Framework

• StackToIT für Umgebungen, die in Code beschrieben sind

  Eingabe ist ein Terraform- oder OpenTofu-Root-Modul oder ein RVTools-Export. Ausgabe ist ein Paket: jede Ressource mit Klasse, STACKIT-Ziel und Begründung, Terraform-Entwürfe für unterstützte Einheiten, Diagramme, ein geordneter Plan und die offenen Entscheidungen. Es läuft lokal, braucht keine Cloud-Zugangsdaten und ändert in keiner Cloud etwas.

• Discovery-Plattformen für die undokumentierte Umgebung

  Device42, Txture und Flexera One inventarisieren, was läuft, bilden Abhängigkeiten ab und liefern Portfolio- und Kostensichten. Sie kennen STACKIT nicht als Ziel und schreiben kein STACKIT-Terraform. Sie sind der richtige Anfang, wenn wenig Infrastruktur in Code vorliegt.

• Das STACKIT Cloud Framework für die Methode

  Das Framework von STACKIT beschreibt die Assess-Phase als Rapid Discovery, ein Readiness Assessment über die Dimensionen Technik, Prozesse, Personal, Finanzen und Governance sowie Workshops. Es nennt kein Assessment-Tool; es legt die Fragen fest, die ein Tool beantworten muss.

• Wie sie zusammenpassen

  Discovery liefert das vollständige Inventar; StackToIT liefert die STACKIT-spezifische Antwort für den in Code beschriebenen Teil; das Readiness Assessment des Frameworks deckt Organisation und Governance ab. Zusammen ergeben sie die Grundlage, die die Design-Phase braucht.

Das Ziel aufbauen: die eigenen Werkzeuge von STACKIT

• Terraform Provider und OpenTofu

  Der Standardweg, STACKIT-Infrastruktur aus Code zu erstellen. Die Entwürfe von StackToIT werden gegen eine festgelegte Provider-Version geschrieben und statisch mit OpenTofu validiert, sodass Ihr Plattformteam Provider-Code prüft, den es bereits kennt.

• Pulumi-Provider

  Der Pulumi-Provider von STACKIT deckt IaaS- und Resource-Manager-Dienste aus Node.js ab und ist in der offiziellen Dokumentation als Alpha eingestuft. Für eine vollständige Umgebung ist heute der Terraform Provider die Referenz.

• CLI und SDKs

  Die CLI deckt Projekte, Service Accounts und Ressourcen für die tägliche Arbeit und Skripte ab. Die SDKs für Go, Python und Java kapseln die STACKIT-APIs für eigene Werkzeuge.

Workloads und Daten bewegen: ein Tool je Workload

• Virtuelle Maschinen

  Hystax Acura repliziert laufende Maschinen mit unbegrenzten Testmigrationen und einer letzten Synchronisation beim Cutover nach STACKIT; es dient auch der Disaster Recovery. Coriolis repliziert agentenlos zwischen Plattformen. Das STACKIT Cloud Framework nennt beide für die Verlagerung von VMs.

• Kubernetes

  Velero sichert Cluster-Ressourcen und Persistent Volumes und stellt sie auf dem neuen Cluster wieder her. Wo Workloads bereits aus Git ausgerollt werden, rollen Argo CD oder Flux sie auf SKE neu aus, und nur die Daten brauchen einen eigenen Weg.

• Object Storage

  rclone kopiert und synchronisiert Buckets zwischen S3-kompatiblen Diensten wie Amazon S3 und STACKIT Object Storage und liest Azure Blob Storage und Google Cloud Storage über eigene native Backends, mit Prüfsummen und wiederaufnehmbaren Läufen.

• Datenbanken

  PostgreSQL zieht mit pg_dump und pg_restore oder mit logischer Replikation für einen kurzen Cutover zu PostgreSQL Flex um. Der Open-Source-Migrator von credativ ist eine Option, wenn eine proprietäre Engine zu PostgreSQL werden soll. Engines ohne verwaltetes STACKIT-Gegenstück sind zuerst eine Architekturentscheidung, wie das Assessment zeigt.

Wie Sie wählen

• Beim Inventar anfangen

  Liegt die Umgebung in Terraform oder OpenTofu vor, führen Sie zuerst StackToIT aus: Es sagt je Ressource, was umzieht, was sich ändert und was entschieden werden muss. Wenn nicht, beginnen Sie mit Discovery.

• Je Workload wählen

  VMs, Kubernetes, Objekte und Datenbanken haben jeweils ein bewährtes Umzugstool. Der Ausführungsplan benennt den Schritt; das Tool ist Ihre Wahl.

• Das Ziel in Code halten

  Was auch immer die Daten bewegt, die STACKIT-Seite sollte zuerst als Terraform oder Pulumi existieren. Das macht die Migration wiederholbar und prüfbar.

Fragen zur Toolwahl

Quellen

• STACKIT Cloud Framework: Migrationsübersicht (Englisch)
• STACKIT Cloud Framework: Assess (Englisch)
• STACKIT Cloud Framework: Relocate (Coriolis, Hystax Acura; Englisch)
• STACKIT-Dokumentation: Terraform Provider
• STACKIT-Dokumentation: Pulumi
• STACKIT-Dokumentation: STACKIT CLI
• STACKIT-Dokumentation: Go SDK
• Hystax: Live-Cloud-Migration zu STACKIT (Englisch)
• Cloudbase Solutions: Coriolis (Englisch)
• Velero-Dokumentation (Englisch)
• Argo-CD-Dokumentation (Englisch)
• Flux-Dokumentation (Englisch)
• rclone-Dokumentation (Englisch)
• PostgreSQL: pg_dump (Englisch)
• credativ-pg-migrator auf GitHub
• Device42 (Englisch)
• Txture (Englisch)
• Flexera One (Englisch)