Azure Virtual Machines nach STACKIT Compute, Schritt für Schritt

Der Ablauf in sechs Schritten

Jeder Schritt nennt die Datei, in der die Antwort steht. So wiederholen Sie ihn mit Ihrem eigenen Terraform.

1. 01

   1. Die Umgebung in einen Ordner legen

   StackToIT liest azurerm-Terraform aus einem Verzeichnis und verbindet sich nie mit einem Azure-Konto. Die Demo ist eine main.tf mit Ressourcengruppe, virtuellem Netzwerk, Subnetz, einer Linux-VM mit verwalteter Datendisk und einer Windows-VM.

2. 02

   2. Die Bewertung starten

   Der Befehl ist stacktoit assess mit Eingabe- und Ausgabeverzeichnis. Für diese Anleitung läuft er offline; die OpenTofu-Prüfung der Quelle war abgeschaltet, weil kein Provider-Mirror vorlag.

3. 03

   3. Lesen, was blockiert ist

   Eine Variable ohne Wert hält die Einheiten an, die sie lesen (und alles, was an ihnen hängt). Der erste Lauf nennt die Variable und die Datei, die sie braucht, und die Konsole sagt, wie viele Einheiten ohne Entwurf bleiben.

4. 04

   4. Wert liefern und erneut starten

   Eine Variablendatei im bewerteten Verzeichnis genügt. Der zweite Lauf entwirft alle vier Einheiten mit STACKIT-Ressource: Subnetz, beide VMs und die Datendisk.

5. 05

   5. Den Entwurf lesen

   terraform/compute.tf enthält Server, Volume und Anbindung. Jeder Block trägt Prüfkommentare zu den Einstellungen, die er nicht übernehmen konnte.

6. 06

   6. Entscheiden, dann die Disks übertragen

   Image, Maschinentyp, Speicherklasse, Anmeldung und Lizenzierung sind Variablen oder Entscheidungen. Für die Datendisk ist kein Verfahren gewählt: migration/data-movement.md sagt das, und den Umzug planen Sie selbst.

Schritte 3 und 4: fehlende Variable, dann vollständiger Lauf

Dieselbe Umgebung, zweimal bewertet. Links: die zwei Zeilen der Konsolenzusammenfassung nach dem ersten Lauf, in dem die Variable für den SSH-Schlüssel keinen Wert hatte. Rechts: dieselben Zeilen, nachdem eine terraform.tfvars mit Demowerten neben der main.tf lag.

Source        9 resources · 5 units · visibility: Required input missing
Migration     2 drafted · 1 need no resource · 2 have no draft because an input the source needs is not in the package (of 5 units: 3 the draft considered, 2 have no draft)

Source        9 resources · 5 units · visibility: Complete
Migration     4 drafted · 1 need no resource (of 5 units the draft considered)

• Erforderliche Eingabe fehlt

  Der erste Lauf meldet die Quelle als unvollständig und entwirft 2 von 5 Einheiten: das Subnetz und die Windows-VM. Die Linux-VM bleibt ohne Entwurf, weil ihr SSH-Schlüssel aus einer Variable stammt, die niemand gesetzt hat; die Datendisk bleibt es, weil sie an dieser VM hängt. Der Architektenbericht nennt die Variable und die Zeile der main.tf, die sie liest.

• Es wird nichts erraten

  Die Engine erfindet keinen Schlüssel, um die Lücke zu überbrücken. Die Werte in dieser Demo sind Platzhalter, die für diese Seite geschrieben wurden. In Ihrer Umgebung übergeben Sie die echte Variablendatei mit dem bewerteten Verzeichnis oder erklären eine Eingabe bewusst für entfernt.

• Der Schlüssel steht im Entwurf

  Der öffentliche Schlüssel aus der Variablendatei wird als Literal in den Block stackit_key_pair geschrieben. Behandeln Sie den Entwurfsordner wie Quellcode: prüfen Sie ihn vor dem Einchecken, und halten Sie Geheimnisse aus der bewerteten Variablendatei heraus.

Schritt 5: Die Linux-VM wird zum Server mit Key Pair

Links: die azurerm_linux_virtual_machine wie geschrieben. Rechts: die STACKIT-Blöcke, die die Engine dafür entworfen hat: Key Pair, die Netzwerkschnittstelle aus der Quell-NIC und den Server. Die Prüfkommentare über jedem Block der Datei sind in diesem Ausschnitt weggelassen; die Liste „Was aus den Azure-VM-Einstellungen wird“ weiter unten fasst sie zusammen.

resource "azurerm_linux_virtual_machine" "app01" {
  name                  = "vm-billing-app01"
  location              = azurerm_resource_group.app.location
  resource_group_name   = azurerm_resource_group.app.name
  size                  = "Standard_D4s_v5"
  admin_username        = "azureops"
  network_interface_ids = [azurerm_network_interface.app01.id]
  zone                  = "1"

  admin_ssh_key {
    username   = "azureops"
    public_key = var.admin_public_key
  }

  os_disk {
    caching              = "ReadWrite"
    storage_account_type = "Premium_LRS"
    disk_size_gb         = 64
  }

  source_image_reference {
    publisher = "Canonical"
    offer     = "0001-com-ubuntu-server-jammy"
    sku       = "22_04-lts-gen2"
    version   = "latest"
  }
}

resource "stackit_key_pair" "app01" {
  name       = "vm-billing-app01-key"
  public_key = "ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIDemoKeyForThisGuideOnlyNotARealKey00000 ops@example.org"
}

resource "stackit_network_interface" "app01_1" {
  project_id = var.project_id
  network_id = stackit_network.vms.network_id
  ipv4       = "10.40.1.10"
}

resource "stackit_server" "app01" {
  project_id        = var.project_id
  name              = "vm-billing-app01"
  machine_type      = var.app01_machine_type
  availability_zone = var.availability_zone
  boot_volume = {
    source_type           = "image"
    source_id             = var.app01_image_id
    size                  = 64
    delete_on_termination = true
  }
  keypair_name       = stackit_key_pair.app01.name
  network_interfaces = [stackit_network_interface.app01_1.network_interface_id]
}

• Größe der Bootdisk bleibt

  Die 64-GB-OS-Disk wird zum Boot-Volume mit size 64. Das Boot-Volume startet aus einer Image-Variable, das Image liefern also Sie.

• Die Größe ist eine Variable, keine Vermutung

  Standard_D4s_v5 steht in der Variablenbeschreibung mit etwa 4 vCPU und 16 GiB. Den passenden STACKIT-Maschinentyp wählen Sie. Die Seite zu den STACKIT-Maschinentypen führt feste Kombinationen aus vCPU und RAM auf; eine individuelle Anpassung ist nicht möglich.

• Die Anmeldung wandert ins Image

  Ein STACKIT-Key-Pair enthält nur einen öffentlichen Schlüssel. Administratorname und Passwortverwaltung von Azure werden nicht übernommen; der Anmeldebenutzer stammt aus dem Image oder aus cloud-init-Daten, und der Entwurf sagt das im Block.

• Die statische Adresse bleibt

  Die Quell-NIC hatte die statische private Adresse 10.40.1.10; die entworfene stackit_network_interface übernimmt sie als ipv4 im Netzwerk, das aus dem Subnetz (10.40.1.0/24) entsteht. Die NIC der Windows-VM war dynamisch, ihre Schnittstelle erhält daher keine feste Adresse.

Die Datendisk wird zu Volume und Anbindung

Aus demselben Lauf. Links: die verwaltete Disk und ihre Anbindung. Rechts: Volume und Anbindungsressource des Entwurfs, ohne ihre Prüfkommentare.

resource "azurerm_managed_disk" "data" {
  name                 = "disk-billing-app01-data"
  location             = azurerm_resource_group.app.location
  resource_group_name  = azurerm_resource_group.app.name
  storage_account_type = "Premium_LRS"
  create_option        = "Empty"
  disk_size_gb         = 256
  zone                 = "1"
}

resource "azurerm_virtual_machine_data_disk_attachment" "data" {
  managed_disk_id    = azurerm_managed_disk.data.id
  virtual_machine_id = azurerm_linux_virtual_machine.app01.id
  lun                = 0
  caching            = "ReadOnly"
}

resource "stackit_volume" "data" {
  project_id        = var.project_id
  name              = "disk-billing-app01-data"
  availability_zone = var.availability_zone
  size              = 256
  performance_class = var.data_performance_class
}

resource "stackit_server_volume_attach" "data" {
  project_id = var.project_id
  server_id  = stackit_server.app01.server_id
  volume_id  = stackit_volume.data.volume_id
}

• Größe übernommen, Einheit prüfen

  Aus 256 wird 256. Der Entwurf merkt an, dass STACKIT die Größe als GB angibt, ohne GiB oder 10^9 Byte zu nennen. Prüfen Sie die Einheit am Ziel, bevor Daten kopiert werden.

• Zone, LUN und Caching entfallen

  Das Volume entsteht in der Zone der Variable availability_zone, Standard ist eu01-1. LUN und das Host-Caching ReadOnly haben keine Entsprechung; ein Gast sollte das Volume daher über seine ID finden, nicht über die LUN.

• Die Speicherklasse bestimmen Sie

  Premium_LRS lässt sich nicht von selbst einer Performance-Klasse zuordnen. Die Variable data_performance_class listet die Klassen des Katalogs eu01 auf und prüft Ihre Wahl.

Die Werte, die der Entwurf Ihnen überlässt

Links: die Demo-Variablendatei, mit der die Linux-VM im zweiten Lauf entworfen wurde. Rechts: die beiden Variablen aus der variables.tf des Entwurfs, die der Linux-Server liest. Keine hat einen Standardwert; ohne sie lässt sich der Entwurf nicht planen.

admin_public_key   = "ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIDemoKeyForThisGuideOnlyNotARealKey00000 ops@example.org"
win_admin_password = "placeholder-not-a-secret"

variable "app01_image_id" {
  type        = string
  description = "STACKIT image replacing the image of azurerm_linux_virtual_machine.app01, Azure image Canonical:0001-com-ubuntu-server-jammy:22_04-lts-gen2:latest (public image, or an uploaded raw/qcow2 conversion of the VHD)."
}

variable "app01_machine_type" {
  type        = string
  description = "STACKIT machine type replacing azurerm_linux_virtual_machine.app01 (Azure Standard_D4s_v5 ≈ 4 vCPU / 16 GiB). See https://docs.stackit.cloud/products/compute-engine/server/basics/machine-types/"
}

• Image-ID

  Verwenden Sie ein öffentliches STACKIT-Image oder die ID eines Images, das Sie aus der konvertierten Disk importiert haben. Die Bewertung führt das Image als Einstellung, die eine Person gegen den aktuellen Image-Katalog prüft, bevor die ID festgeschrieben wird.

• Maschinentyp

  Dieselbe Logik: Die Variablenbeschreibung nennt die Quellgröße, die Wahl treffen Sie anhand der Maschinentyp-Tabellen.

So wird die Demo-Umgebung zugeordnet

Klassen und Konfidenz (bei allen fünf Einheiten MEDIUM) so, wie der Lauf sie entschieden hat. Die Netzwerkschnittstelle ist keine eigene Einheit: Sie wird mit dem Server entworfen, der sie nutzt.

Was aus den Azure-VM-Einstellungen wird

Entnommen aus den Prüfkommentaren des Entwurfs und den offenen Einstellungen des Architektenberichts.

• Administratorkonto und Passwort

  Nicht übernommen. stackit_server kennt kein Administratorkonto und kein Passwort. Legen Sie einen benannten Benutzer ins Image oder in die cloud-init-Benutzerdaten.

• Disk-Caching und Speichertyp

  Nicht übernommen. Für das Boot-Volume wird nur die Größe übernommen; die Performance-Klasse wählen Sie selbst.

• Verfügbarkeitszone

  Azure-Zone 1 wird nicht zugeordnet. Server und Volume liegen in der Zone der Variable availability_zone; Server verteilen Sie mit einer Affinitätsgruppe.

• Windows-Lizenz

  license_type = Windows_Server steht beim Windows-Server als nicht übernommen. Wie Windows-Lizenzierung am Ziel funktioniert, klären Sie über Ihren STACKIT-Vertrag, nicht über das Terraform.

• Ressourcengruppe

  STACKIT kennt keine Ressourcengruppen. Jede Ressource landet in var.project_id, und eine Person entscheidet, wie Gruppengrenzen Projekten und Rollen zugeordnet werden.

Die Disks übertragen

Der Lauf schreibt Ziel und Reihenfolge. Daten überträgt er nicht.

1. 01

   Disk exportieren

   Azure exportiert keine VHD von einer Disk, die an einer laufenden VM hängt. Halten Sie die VM an, oder erstellen Sie einen Snapshot und exportieren Sie diesen. Eine schreibgeschützte SAS-URL erzeugt az disk grant-access mit höchstens 60 Tagen Gültigkeit; az disk revoke-access entzieht den Zugriff danach wieder.

2. 02

   Konvertieren

   STACKIT importiert raw, qcow2 und iso. Eine VHD wird vorher umgewandelt, zum Beispiel mit qemu-img; den Aufruf convert mit -O raw zeigt auch die STACKIT-Dokumentation.

3. 03

   Image importieren

   Über die STACKIT-IaaS-API legen Sie ein Image an (es steht zunächst in der Warteschlange), laden die Datei an die zurückgegebene Upload-URL hoch und prüfen vor der Nutzung, dass das Image den Zustand AVAILABLE hat. Die dokumentierte Höchstgröße eines Images beträgt 70 GB; eine größere Systemdisk braucht einen anderen Weg, etwa ein neu gebautes Image.

4. 04

   Server anlegen

   Setzen Sie app01_image_id auf die neue Image-ID und führen Sie apply aus. Datenvolumes werden leer angelegt und angebunden; die Daten kopieren Sie danach.

5. 05

   Die Datenkopie planen

   migration/data-movement.md führt die Datendisk als zustandsbehaftete Einheit mit dem Verfahren UNKNOWN. Die bereitgestellte Kapazität (256 GB) ist keine Datenmenge. Änderungsrate, tolerierte Ausfallzeit und Konsistenz entscheiden zwischen einer Kopie auf Blockebene, einer Synchronisation auf Dateiebene und einem Export auf Anwendungsebene.

Entscheidungen, die bei Ihren Architekten liegen

• Maschinentyp je Server

  Aus Quellgröße und tatsächlicher Auslastung, nicht aus dem Namen der Azure-Größe.

• Image je Server

  Ein öffentliches STACKIT-Image oder ein importiertes, konvertiertes Image; erst prüfen, dann die ID festschreiben.

• Performance-Klasse

  Eine Variable für die Datenvolumes, damit Speicher an einer Stelle entschieden wird.

• Anmeldung und Härtung

  Benannte Benutzer, SSH-Schlüssel, Passwortrichtlinie und Agenten kommen aus Image oder cloud-init.

• Reihenfolge der Umzüge

  Der Lauf setzt das Netzwerk zuerst, die Server danach und die Datendisk zuletzt (Welle 4). Den Zeitplan legen Sie fest.

Fragen zum Umzug von Azure-VMs

Quellen

• Linux-VHD aus Azure herunterladen (Microsoft Learn)
• Eigene Images mit der IaaS-API nutzen (STACKIT-Dokumentation)
• Maschinentypen (STACKIT-Dokumentation)