Checkliste für die Migration von Oracle Cloud zu STACKIT

Zwei Einheiten, die keine Zuordnung abdeckt

Beginnen Sie damit, die Einheiten zu finden, die der Lauf nicht entscheiden konnte. In der Demo-Umgebung enden eine private DNS-Zone und eine IAM-Policy als MANUAL_REVIEW. Links die Eingabe, rechts die Entscheidung, wie sie in assessment.json steht. Da assessment.json in einer einzigen Zeile geschrieben ist, zeigt der Ausschnitt ausgewählte Felder jeder Einheit, eingerückt und so verschachtelt wie in der Datei, mit unveränderten Werten.

resource "oci_dns_zone" "internal" {
  compartment_id = var.compartment_id
  name           = "batch.example.internal"
  zone_type      = "PRIMARY"
  scope          = "PRIVATE"
}

resource "oci_identity_policy" "batch" {
  compartment_id = var.compartment_id
  name           = "batch-policy"
  description    = "Allow the batch group to manage objects"
  statements     = ["Allow group batch-operators to manage objects in compartment batch"]
}

[
  {
    "id": "oci_dns_zone.internal",
    "result": {
      "class": "MANUAL_REVIEW",
      "confidence": "LOW",
      "reason": "oci_dns_zone is not in the knowledge base catalogue; an architect has to decide the target. Nothing of this resource is assessed or drafted (unknown source type)."
    }
  },
  {
    "id": "oci_identity_policy.batch",
    "result": {
      "class": "MANUAL_REVIEW",
      "confidence": "LOW",
      "reason": "OCI policies have no document-level counterpart on STACKIT. Map people and workloads to STACKIT roles and service accounts."
    }
  }
]

• Unbekannter Typ, kein Ziel

  oci_dns_zone steht nicht im Katalog dieses Builds, daher wird dazu nichts bewertet oder entworfen. Daraus wird ein manueller Schritt ohne verantwortliche Rolle, wie execution/manual/actions.md ausdrücklich festhält.

• Eine Policy ist keine Rolle

  OCI-Policies haben auf STACKIT keine Entsprechung auf Dokumentebene. Der Lauf verlangt, Personen und Workloads auf STACKIT-Rollen und Service Accounts abzubilden.

Phase 1 · Bestandsaufnahme: wissen, was der Lauf gesehen hat

• Lock-Datei committen

  .terraform.lock.hcl gehört zum Root-Modul. Ohne Eintrag für oci warnt der Bericht, dass die Provider-Version nicht belegt ist, und begrenzt die Einheiten auf mittlere Konfidenz. Prüfen: engineering/architect-report.md, Hinweis zu den Quell-Providern.

• Vollständigkeit der Quelle bestätigen

  Die Zusammenfassung muss Quellstatus COMPLETE zeigen, und der Abschnitt „Source status“ darf kein ungescanntes Modul nennen. Prüfen: assessment.json, summary, und architect-report.md.

• Einheitenzahl mit der Tenancy abgleichen

  Die Demo hat 8 Ressourcen und 8 Einheiten. Was in der Konsole angelegt wurde und nicht in Terraform steht, sieht der Lauf nicht; erfassen Sie es von Hand. Prüfen: Tabelle „Summary“ im Bericht.

• Jede MANUAL_REVIEW-Einheit auflisten

  Hier: DNS-Zone und IAM-Policy. Für jede muss eine Person entscheiden. Prüfen: „Architect review queue“ im Bericht.

Phase 2 · Design: entscheiden, was der Lauf offen lässt

• Die Regionsanfrage beantworten

  Eine Anfrage blockiert den Entwurf: target.region, eu01 oder eu02. Prüfen: review/inputs.yaml, danach den Lauf mit demselben Ausgabeordner wiederholen.

• Policies auf Rollen abbilden

  Die Gruppe batch der Demo braucht eine STACKIT-Rolle und einen Service Account für den Workload. Prüfen: Einheit oci_identity_policy.batch im Bericht.

• Ziel für die DNS-Zone wählen

  Es wird kein Ziel vorgeschlagen. Entscheiden Sie, ob die private Zone eine STACKIT-DNS-Zone oder ein anderer Entwurf wird, und halten Sie es in der Notiz ihres Schritts in review/progress.yaml fest.

• Flavor für die Instanz wählen

  Aus der Shape VM.Standard.E5.Flex mit 4 OCPUs und 32 GB wird ein STACKIT-Flavor; das Image wird neu gebaut oder importiert. Prüfen: Einheit oci_core_instance.batch.

• Performance-Klasse für das Volume wählen

  vpus_per_gb = 10 ist eine OCI-Einstellung, die nicht übernommen wird. Prüfen: Einheit oci_core_volume.scratch.

Phase 3 · Aufbau: das Ziel in der Reihenfolge des Laufs anlegen

• Den Wellen folgen

  Welle 1: VCN, Volume, Dateisystem, Bucket, DNS-Zone und Policy. Welle 2: das Subnetz. Welle 3: die Instanz. Prüfen: migration/technical-sequencing.md.

• Das Terraform selbst schreiben

  Der Entwurf enthält 0 Einheiten: terraform/ hat nur Provider- und Variablendateien. Planen Sie Ihr eigenes STACKIT-Terraform aus den obigen Entscheidungen. Prüfen: terraform/README.md.

• Das Image importieren

  STACKIT akzeptiert Images in raw, qcow2 und iso bis 70 GB; prüfen Sie, dass das hochgeladene Image den Status AVAILABLE zeigt, bevor Sie einen Server daraus erstellen. Prüfen: STACKIT-Dokumentation zu eigenen Images.

• Zugriff auf die Dateifreigabe neu schreiben

  Aus dem Dateisystem wird eine Freigabe in STACKIT File Storage; Mount Targets und Export-Regeln werden neu geschrieben. Prüfen: Einheit oci_file_storage_file_system.shared.

• Bucket-Regeln neu anlegen

  Clients wechseln Endpunkt und Zugangsdaten; Lifecycle-, Replikations- und Zugriffsregeln werden neu geschrieben. Versionierung ist in der Eingabe aktiv; STACKIT führt Versionierung unter den Funktionen von Object Storage, also schalten Sie sie für den neuen Bucket ein und prüfen Sie das. Prüfen: Einheit oci_objectstorage_bucket.exports.

Phase 4 · Daten: drei zustandsbehaftete Einheiten, kein Verfahren gewählt

• Ergänzen, was der Lauf nicht wissen kann

  Alle drei zustandsbehafteten Einheiten (Volume, Dateisystem, Bucket) zeigen Verfahren UNKNOWN und Zustand DECISION_REQUIRED, mit Datenklasse, Recovery Point und Ausfalltoleranz NOT_PROVIDED. Prüfen: migration/data-movement.md und data-movement.csv.

• Größen selbst notieren

  Der Lauf führt die bereitgestellte Kapazität als nicht in der Quelle angegeben, obwohl das Volume 500 GB setzt. Nehmen Sie Größen aus der Konsole, nicht aus dem Lauf.

• Je Einheit ein Verfahren wählen

  Block-Volume auf Host-Ebene oder aus einem Backup, Dateikopie für die Freigabe, ein S3-kompatibler Client für den Bucket (zum Beispiel rclone). StackToIT überträgt nie Daten.

• Probelauf und Verifikation

  Einmal kopieren, Objektzahlen und Prüfsummen vergleichen, die Dauer messen. Ein Probelauf, der nie stattgefunden hat, ist kein Plan (allgemeine Praxis).

Phase 5 · Cutover: eine Umstellung nach der anderen

• DNS-TTL vor dem Fenster senken

  Gilt für jeden Eintrag, der eine OCI-Adresse nennt (allgemeine Praxis).

• Schreibstopp vereinbaren

  Für Bucket, Freigabe und Volume festlegen, wer wann die Schreibzugriffe stoppt (allgemeine Praxis).

• Rollback vor dem Fenster schreiben

  Was zurückgeschaltet wird, in welcher Reihenfolge und wer entscheidet. Die vollständige Liste steht in der Checkliste zu Cutover und Rollback.

• Prüfen, ob für jeden Schritt Verantwortliche benannt sind

  Ein Schritt in diesem Lauf hat keine verantwortliche Rolle. Solange niemand dafür verantwortlich ist, ist der Plan nicht vollständig. Prüfen: execution/manual/actions.md, Abschnitt „Assign an owner“.

Phase 6 · Nachbereitung: sauber abschließen

• Die Bewertung erneut laufen lassen

  Sind die Entscheidungen festgehalten, den Lauf wiederholen und die Ergebnisse vergleichen. Prüfen: die neue index.html und Ihre Schrittzustände in review/progress.yaml.

• Die OCI-Umgebung für die vereinbarte Frist vorhalten

  Löschen Sie die OCI-Umgebung erst nach der Haltefrist (allgemeine Praxis).

• Den Review-Ordner zusammen mit dem Code ablegen

  review/inputs.yaml beantwortet den Lauf, und review/progress.yaml ist Ihr Journal je Schritt mit Zustand, Verantwortlichem und Notiz. Für diese Umgebung hat der Lauf keine Entscheidungsdatensätze angelegt; decisions.yaml bleibt leer.

Wo welche Antwort steht

Fragen vor dem Start

Quellen

• STACKIT-Dokumentation: Eigene Images mit der IaaS-API nutzen
• STACKIT-Dokumentation: Einführung in Object Storage