Einheit 2.1: Compute und Serverautomatisierung

Einführung

Sie bauen TaskBoard, einen Task-Management-Service, der einen persistenten API-Server und eine Flotte von stateless Arbeitern benötigt. Bevor irgendwelcher Anwendungscode ausgeführt wird, müssen Sie die Compute-Ebene reproduzierbar, jedes Mal, aus einem Git-Repository und nicht aus einer Konsole bereitstellen. Diese Einheit führt Sie von einer einzelnen ionoscloud_server-Ressource zu einer Auto-Scaling-Gruppe, alles ausgedrückt als Code.

Compute auf IONOS Cloud bietet Ihnen zwei Servermodelle mit unterschiedlichen Abrechnungs- und CPU-Semantiken, automatisierte erste Boot-Konfiguration durch cloud-init und einen horizontalen Auto-Scaler, der harte Anforderungen hat, die Sie korrekt kodieren müssen, oder Ihr terraform apply-System wird fehlschlagen. Sie werden die Terraform für TaskBoards API-Server (Dedicated Core, 4 Kerne, 8 GB RAM) und dessen Arbeiter (vCPU, 2 Kerne) schreiben, cloud-init einbinden, um die Laufzeit zu installieren, und eine öffentliche IP anhängen, damit Sie SSH einwählen und das Ergebnis überprüfen können.

1. Bereitstellung von Servern mit Terraform

Die ionoscloud_server-Ressource ist das Kernbaustein der Compute-Ebene. Ein Server befindet sich immer innerhalb eines ionoscloud_datacenter (eines virtuellen Rechenzentrums oder VDC) und wird mit einer CPU-Familie, einer Kernanzahl und einer Menge RAM erstellt. Die beiden Entscheidungen, die alles andere bestimmen, sind der Servertyp, ENTERPRISE für Dedicated Core oder CUBE für Cubes, und ob Sie eine Dedicated Core-Konfiguration oder eine vCPU-Konfiguration wählen.

Eine minimale Dedicated Core Server für TaskBoards API-Ebene sieht wie folgt aus. Das Boot-Volume wird inline deklariert und das Betriebssystem-Image wird durch eine Datenquelle aufgelöst, anstatt hartcodiert zu werden.

resource "ionoscloud_datacenter" "taskboard" {
  name     = "taskboard-prod"
  location = "de/txl"
}

data "ionoscloud_image" "ubuntu" {
  type       = "HDD"
  cloud_init = "V1"
  image_alias = "ubuntu:latest"
  location   = "de/txl"
}

resource "ionoscloud_server" "api" {
  name              = "taskboard-api"
  datacenter_id     = ionoscloud_datacenter.taskboard.id
  cores             = 4
  ram               = 8192
  cpu_family        = "INTEL_ICELAKE"
  availability_zone = "AUTO"

  volume {
    name      = "api-boot"
    size      = 20
    disk_type = "SSD Premium"
    image_name = data.ionoscloud_image.ubuntu.id
    ssh_keys  = [var.ssh_public_key]
  }

  nic {
    lan             = ionoscloud_lan.public.id
    dhcp            = true
    firewall_active = false
  }
}

Der RAM wird in Megabyte angegeben, sodass 8 GB 8192 entsprechen. Die Servererstellung ist asynchron, aber der Terraform-Anbieter pollt intern den IONOS-Anfragestatus, sodass zum Zeitpunkt, an dem apply zurückgegeben wird, der Server den DONE-Zustand erreicht hat und die Boot-Volume angehängt ist. Sie müssen nicht manuell innerhalb von Terraform pollen, wie Sie es bei einem rohen API-Aufruf tun würden.

1.1 Dedicated Core versus vCPU

Die Wahl des Servermodells ist nicht kosmetisch. Ein Dedicated Core Server bietet Ihrem VM die exklusive Nutzung seiner physischen Kerne, und Sie können die CPU-Familie auswählen und später ändern. Ein vCPU Server teilt CPU-Ressourcen, und seine CPU-Familie ist bei der Erstellung festgelegt und kann später nicht geändert werden. TaskBoards API-Stufe benötigt eine vorhersehbare Latenz, daher wird Dedicated Core verwendet. Die Worker-Stufe ist bursty und kostensensibel, daher wird vCPU verwendet.

Die beiden Modelle teilen die gleiche RAM-Obergrenze, aber unterscheiden sich in der CPU-Dimension. Die Grenzwerte unten stammen direkt von der Plattform und sind die Werte, gegen die Terraform validiert.

Der RAM kann in Inkrementen von 0,25 GB festgelegt werden. Die CPU-Familien-Änderungsfunktion auf Dedicated Core-Servern wird als Core Technology Choice bezeichnet, die es ermöglicht, einen bestehenden Server auf eine neuere CPU-Generation ohne Neuaufbau zu übertragen. Verfügbare CPU-Modelle umfassen AMD EPYC Gen 3 (Milan), AMD EPYC Gen 5 (Turin), mehrere Intel Xeon Gen 5-Familien (Haswell, Broadwell, Skylake, Ice Lake) und Intel Xeon Gen 6 (Sierra Forest).

Der TaskBoard-Worker ist ein vCPU Server. Beachten Sie das Fehlen von cpu_family, da es nicht ausgewählt werden kann.

resource "ionoscloud_vcpu_server" "worker" {
  name          = "taskboard-worker"
  datacenter_id = ionoscloud_datacenter.taskboard.id
  cores         = 2
  ram           = 4096
  # cpu_family omitted: vCPU servers do not allow CPU family selection

  volume {
    name       = "worker-boot"
    size       = 10
    disk_type  = "SSD Standard"
    image_name = data.ionoscloud_image.ubuntu.id
    ssh_keys   = [var.ssh_public_key]
  }

  nic {
    lan  = ionoscloud_lan.app.id
    dhcp = true
  }
}

1.2 Verfügbarkeitszonen

Rechnerserver können in der Verfügbarkeitszone 1, Zone 2 oder AUTO platziert werden. Es gibt keine Zone 3 für Rechenressourcen, obwohl Block Storage-Volumen eine Zone 3 anbieten. Wenn Sie availability_zone = "ZONE_3" auf einem Server festlegen, schlägt die Anfrage fehl. Verwenden Sie AUTO, es sei denn, Sie verteilen Replikate absichtlich über Zonen für die Fehlertoleranz, in diesem Fall binden Sie einen Server an ZONE_1 und einen anderen an ZONE_2.

resource "ionoscloud_server" "api_zone_a" {
  # ...
  availability_zone = "ZONE_1"
}

resource "ionoscloud_server" "api_zone_b" {
  # ...
  availability_zone = "ZONE_2"
}

2. Cloud-init für automatisierte Bootstrapping

Ein bereitgestellter Server ohne Software ist nicht nützlich. Cloud-init ist das Paket, das beim ersten Start ausgeführt wird und Ihre Konfiguration anwendet: Installation von Paketen, Schreiben von Dateien, Starten von Diensten und Einschleusen von SSH-Schlüsseln. Alle öffentlichen Linux-Images auf IONOS Cloud (Alma Linux, Debian, Rocky Linux und Ubuntu) werden mit cloud-init bereits installiert, sodass Sie die Konfiguration über das user_data-Feld übergeben und sie automatisch ausgeführt wird.

Sie übergeben user_data als base64-kodierten String in Terraform und dem API. Der dekodierte Inhalt kann ein cloud-config-YAML-Dokument, ein Shell-Skript, eine Include-Datei oder eines der anderen unterstützten Formate sein. Für TaskBoard ist ein cloud-config-Dokument der sauberste Weg, den gewünschten Endzustand zu deklarieren.

2.1 Cloud-config für TaskBoard

Das folgende cloud-config installiert die Container-Laufzeit, erstellt einen Anwendungsbenutzer und startet den TaskBoard-API-Dienst. Es befindet sich in einer separaten Datei und wird von Terraform's base64encode-Funktion base64-kodiert.

#cloud-config
package_update: true
packages:
  - docker.io
  - postgresql-client
users:
  - name: taskboard
    groups: docker
    sudo: ALL=(ALL) NOPASSWD:ALL
    ssh_authorized_keys:
      - ${ssh_public_key}
runcmd:
  - systemctl enable --now docker
  - docker run -d --restart unless-stopped -p 80:8080 \
      --name taskboard-api registry.example/taskboard-api:latest

Verbinden Sie es mit der Server-Ressource mit user_data. Mit templatefile können Sie Variablen wie den SSH-Schlüssel in die cloud-config zur Planungszeit einschleusen.

resource "ionoscloud_server" "api" {
  name          = "taskboard-api"
  datacenter_id = ionoscloud_datacenter.taskboard.id
  cores         = 4
  ram           = 8192
  cpu_family    = "INTEL_ICELAKE"

  volume {
    name       = "api-boot"
    size       = 20
    disk_type  = "SSD Premium"
    image_name = data.ionoscloud_image.ubuntu.id
    user_data  = base64encode(templatefile("${path.module}/cloud-init.yaml", {
      ssh_public_key = var.ssh_public_key
    }))
  }

  nic {
    lan  = ionoscloud_lan.public.id
    dhcp = true
  }
}

Die unterstützten user-data-Formate umfassen base64-kodierte Daten (der dekodierte Inhalt muss zu einem unterstützten Typ auflösbar sein), ein user-data-Skript, das mit #! oder Content-Type: text/x-shellscript beginnt, eine Include-Datei, die mit #include beginnt, cloud-config-Daten, die mit #cloud-config in YAML beginnen, und upstart-Jobs. Die user_data-Eigenschaft ist unveränderlich: Sie wird nur bei der Erstellung des Volume berücksichtigt, sodass eine spätere Änderung die Neuerstellung des Volume und nicht die Aktualisierung an Ort und Stelle erfordert.

2.2 SSH-Schlüssel und First-Boot-Verifizierung

Sie können SSH-Schlüssel auf zwei Arten einschleusen: über die Volume-Liste oder innerhalb des cloud-config-ssh_authorized_keys-Blocks. Das ssh_keys-Argument ist der einfachste Weg für einen einzelnen Schlüssel auf dem Standardbenutzer. Nach apply erscheint der öffentliche IP in den exportierten Attributen der NIC und Sie können sofort eine Verbindung herstellen.

terraform output api_public_ip
#=> 203.0.113.42
ssh root@203.0.113.42 'cloud-init status --wait'
#=> status: done

Die Ausführung von cloud-init status --wait-Blöcken wird bis zum Abschluss der First-Boot-Konfiguration fortgesetzt, was das richtige Signal dafür ist, dass Ihre Pakete installiert und Ihre Dienste ausgeführt werden. Nehmen Sie nicht an, dass der Server bereit ist, nur weil SSH die Verbindung akzeptiert.

3. Öffentliche IP-Zuweisung

Server in einem öffentlichen LAN erhalten eine IP-Adresse von DHCP automatisch, aber diese Adresse ist ephemeral und kann sich ändern. Für eine stabile, reservierte öffentliche IP-Adresse wird ein ionoscloud_ipblock alloziert und eine seiner Adressen dem Netzwerkadapter (NIC) zugewiesen. Dies ist erforderlich für den API-Endpunkt von TaskBoard, auf den DNS-Einträge und Lastenausgleichsgeräte verweisen.

resource "ionoscloud_ipblock" "api_ip" {
  location = ionoscloud_datacenter.taskboard.location
  size     = 1
  name     = "taskboard-api-ip"
}

resource "ionoscloud_server" "api" {
  # ... cores, ram, volume as above ...

  nic {
    lan  = ionoscloud_lan.public.id
    dhcp = true
    ips  = [ionoscloud_ipblock.api_ip.ips[0]]
  }
}

output "api_public_ip" {
  value = ionoscloud_ipblock.api_ip.ips[0]
}

Das size-Argument steuert, wie viele Adressen der Block reserviert. Eine reservierte IP-Adresse überlebt die Neuerstellung des Servers, was bedeutet, dass Sie den API-Server ohne Änderung der Adresse neu aufbauen können, auf die Ihre DNS-Einträge verweisen. Die location des IP-Blocks muss mit dem Standort des Rechenzentrums übereinstimmen, sonst schlägt die Zuweisung fehl.

4. Images & Snapshots als Code

Die ionoscloud_image-Datenquelle löst ein Betriebssystem-Image in eine ID bei der Planung auf, sodass Sie nie einen volatilen Bild-Identifikator hartcodieren müssen. Filtern Sie nach type, location, cloud_init und image_alias, um das genaue Bild zu fixieren, das Sie wollen.

data "ionoscloud_image" "rocky" {
  type        = "HDD"
  cloud_init  = "V1"
  image_alias = "rockylinux:latest"
  location    = "de/txl"
}

Für reproduzierbare Goldumgebungen erfassen Sie eine konfigurierte Boot Volume als ein Snapshot und stellen neue Server daraus bereit. Die ionoscloud_snapshot-Ressource erstellt ein Snapshot aus einem vorhandenen Volume, und die Snapshot-ID kann zukünftige Volumen initialisieren.

resource "ionoscloud_snapshot" "api_golden" {
  datacenter_id = ionoscloud_datacenter.taskboard.id
  volume_id     = ionoscloud_server.api.boot_volume
  name          = "taskboard-api-golden-v3"
}

Snapshots sind vollständig und liegen in der gleichen Region wie die Quelle Volume. Durch die Verwendung eines Snapshot als Basis für neue Server wird der cloud-init-Installationschritt für alles, was in das Image eingebaut ist, übersprungen, was die Skalierbarkeit beschleunigt und die Abweichung zwischen frisch erstellten Knoten reduziert.

5. VM Auto Scaling

VM Auto Scaling befindet sich derzeit im Early-Access-Status (EA). IONOS empfiehlt, es auf nicht-produktive Workloads zu beschränken, und seine Cloud-API ist in einer separaten Versionierung unter https://api.ionos.com/autoscaling (Version v1.ea) verfügbar, anstatt der stabilen /cloudapi/v6-Oberfläche, die für Server und IP-Blöcke verwendet wird.

VM Auto Scaling erstellt und entfernt Server-Replikate automatisch basierend auf Metriken. Es unterstützt nur horizontales Skalieren: Es fügt mehr virtuelle Maschinen hinzu, es vergrößert jedoch keine vorhandene VM. Sie definieren eine Ziel-Replikate-Konfiguration, Skalierungsrichtlinien für das Skalieren und die Metrik, die diese steuert.

Halten Sie das Skalierungsmodell im Blick: VM Auto Scaling ist nur horizontal. Es fügt ganze Server-Replikate zu Ihrem ionoscloud_autoscaling_group hinzu, das von Compute Engine-Servern unterstützt wird. Änderungen an der Replikate-Konfiguration gelten nur für neu erstellte Replikate, nicht für bereits laufende Replikate. Die unterstützten Replikate-Speichertypen sind HDD, SSD Premium und SSD Standard. Die Skalierungsmetrik-Optionen sind Instanz-CPU-Auslastungsdurchschnitt (Prozent), eingehende Netzwerkbytes, ausgehende Netzwerkbytes, eingehende Netzwerkpakete und ausgehende Netzwerkpakete.

5.1 Auto-Skalierungsgruppe via Terraform

Die ionoscloud_autoscaling_group-Ressource definiert die Gruppe, ihre Replikate-Vorlage und ihre Richtlinie. Die Replikate-Vorlage definiert die Größe für jede Server-Replikate, die die Gruppe bereitstellt.

resource "ionoscloud_autoscaling_group" "workers" {
  datacenter_id = ionoscloud_datacenter.taskboard.id
  name          = "taskboard-worker-asg"
  max_replica_count = 10
  min_replica_count = 1

  policy {
    metric             = "INSTANCE_CPU_UTILIZATION_AVERAGE"
    range              = "PT24H"
    scale_in_threshold  = 33
    scale_out_threshold = 77
    unit               = "PERCENTAGE"

    scale_in_action {
      amount      = 1
      amount_type = "ABSOLUTE"
      cooldown_period = "PT5M"
    }
    scale_out_action {
      amount      = 1
      amount_type = "ABSOLUTE"
      cooldown_period = "PT5M"
    }
  }

  replica_configuration {
    cores     = 4
    ram       = 4096
    cpu_family = "INTEL_ICELAKE"
    availability_zone = "AUTO"

    nic {
      lan  = ionoscloud_lan.app.id
      name = "worker-nic"
      dhcp = true
    }

    volume {
      image      = data.ionoscloud_image.ubuntu.id
      name       = "worker-vol"
      size       = 10
      type       = "SSD Standard"
      user_data  = base64encode(file("${path.module}/worker-init.yaml"))
    }
  }
}

Der amount_type kann ABSOLUTE (eine feste Anzahl von virtuellen Maschinen) oder PERCENTAGE (ein Anteil der aktuellen Anzahl) sein. Die Standard-Abkühlungsperiode beträgt 5 Minuten, die Mindestanzahl der Repliken beträgt 1 und bis zu etwa 100 Repliken ist die empfohlene Obergrenze. Eine Gruppe kann mit einem Application Load Balancer verknüpft werden, sodass neue Repliken automatisch dem Lastverteilungs-Zielpool hinzugefügt werden.

5.2 Repliken Werden Benannt, Nicht Über Den Server-ID Adressierbar

Ein subtiler operativer Haken: automatisch generierte Replik-Servernamen sind Namen, keine Server-IDs, und sie können nicht verwendet werden, um Informationen über den API abzurufen. Wenn Ihre Überwachungs- oder Bereitstellungsskripte annehmen, dass sie die Repliken GET /servers/{id} verwenden können, schlägt der Aufruf fehl. Behandeln Sie Repliken wie Vieh. Verweisen Sie auf sie über die Gruppe und den Load Balancer, nicht über die individuelle Server-ID.

6. Cubes für Zustandslose Workloads

Cubes sind eine Art von Compute-Servern mit obligatorischem direkt angefügtem NVMe-Speicher, der durch ein Konfigurationsvorlage definiert wird. Die kleinste Vorlage, Basic Cube XS, bietet 1 vCPU, 2 GB RAM und 60 GB direkt angefügten NVMe-Speicher. Die vCPU, RAM und die Größe des direkt angefügten Speichers sind durch die Vorlage festgelegt und können nach der Bereitstellung des Cubes nicht geändert werden, und der NVMe-Volume kann nicht abgemountet oder gelöscht werden.

Ein Cube ist jedoch nicht nur ein Speicher. Neben dem obligatorischen NVMe-Volume können Sie bis zu 23 zusätzliche Block Storage-Geräte anhängen, für insgesamt 24 Gerätesteuerelemente, wobei der NVMe-Volume einen Steuerungsslot belegt. Die festen Vorlagen-NVMe-Speicher plus das günstigere, suspend-freundliche Modell machen Cubes zu einer guten Wahl für zustandslose oder ephemere Workloads, bei denen Sie ein vorhersehbares Paket wünschen.

resource "ionoscloud_server" "cube_runner" {
  name          = "taskboard-batch"
  type          = "CUBE"
  template_uuid = data.ionoscloud_template.basic_xs.id
  datacenter_id = ionoscloud_datacenter.taskboard.id

  volume {
    name      = "cube-das"
    disk_type = "DAS"
    licence_type = "LINUX"
  }

  nic {
    lan  = ionoscloud_lan.app.id
    dhcp = true
  }
}

Eine Abrechnungsnuance, die Sie in Ihre Lifecycle-Skripte aufnehmen sollten: für Cubes wird die Abrechnung nur durch Löschung gestoppt, nicht durch Suspension. Die Suspension eines Cubes lässt die Abrechnung weiterlaufen. Wenn Sie Cubes für Batch-Jobs starten und erwarten, die Abrechnung durch Suspension zu stoppen, werden Sie überrascht sein. Führen Sie terraform destroy auf ephemeren Cubes-Instanzen aus, um die Abrechnung tatsächlich zu stoppen.

API Referenz-Quick-Card

Wichtige API-Endpunkte für die Bereitstellung von Rechenressourcen:

Compute Engine / IP-Blöcke Basis-URL: https://api.ionos.com/cloudapi/v6 VM Auto Scaling-Basis-URL (Frühzugang): https://api.ionos.com/autoscaling/v1.ea Authentifizierung: Authorization: Bearer <token>

Code-Lab

Ziel: Bereitstellung der Compute-Ebene von TaskBoard mit Terraform: Ein Dedicated Core API-Server, der von cloud-init bootgestartet wird, mit einer reservierten öffentlichen IP, und Überprüfung des SSH-Zugriffs.

Voraussetzungen:

• IONOS Cloud-Konto mit einem API-Token (IONOS_TOKEN exportiert)
• Terraform 1.5+ lokal installiert
• Ein SSH-Schlüsselpaar (~/.ssh/id_ed25519.pub)

Schritt 1: Konfigurieren des Anbieters

terraform {
  required_providers {
    ionoscloud = {
      source  = "ionos-cloud/ionoscloud"
      version = "~> 6.0"
    }
  }
}
provider "ionoscloud" {}

Erwartete Ausgabe:

$ terraform init
Terraform has been successfully initialized!

Schritt 2: Schreiben der cloud-init-Datei (cloud-init.yaml)

#cloud-config
package_update: true
packages: [docker.io]
runcmd:
  - systemctl enable --now docker

Erwartete Ausgabe:

(file saved, no command output)

Schritt 3: Definieren des Rechenzentrums, des Images und des IP-Blocks

resource "ionoscloud_datacenter" "taskboard" {
  name = "taskboard-lab"; location = "de/txl"
}
data "ionoscloud_image" "ubuntu" {
  type = "HDD"; cloud_init = "V1"
  image_alias = "ubuntu:latest"; location = "de/txl"
}
resource "ionoscloud_ipblock" "api_ip" {
  location = "de/txl"; size = 1; name = "lab-ip"
}

Erwartete Ausgabe:

(validated by terraform plan in Step 5)

Schritt 4: Definieren des API-Servers

resource "ionoscloud_server" "api" {
  name = "taskboard-api"; datacenter_id = ionoscloud_datacenter.taskboard.id
  cores = 4; ram = 8192; cpu_family = "INTEL_ICELAKE"
  volume {
    name = "api-boot"; size = 20; disk_type = "SSD Premium"
    image_name = data.ionoscloud_image.ubuntu.id
    ssh_keys = [file("~/.ssh/id_ed25519.pub")]
    user_data = base64encode(file("cloud-init.yaml"))
  }
  nic { lan = 1; dhcp = true; ips = [ionoscloud_ipblock.api_ip.ips[0]] }
}
output "api_ip" { value = ionoscloud_ipblock.api_ip.ips[0] }

Schritt 5: Planen und Anwenden

terraform plan
terraform apply -auto-approve

Erwartete Ausgabe:

Apply complete! Resources: 4 added, 0 changed, 0 destroyed.
Outputs:
api_ip = "203.0.113.42"

Schritt 6: Überprüfen von cloud-init und SSH

ssh root@$(terraform output -raw api_ip) 'cloud-init status --wait && docker --version'

Erwartete Ausgabe:

status: done
Docker version 24.0.x, build ...

Validierungs-Checkliste:

• [ ] terraform apply wird abgeschlossen mit 4 hinzugefügten Ressourcen
• [ ] Die Ausgabe api_ip zeigt eine reservierte öffentliche Adresse
• [ ] cloud-init status gibt done zurück und Docker ist installiert
• [ ] SSH verbindet sich mithilfe des injizierten Schlüssels

Aufräumen:

terraform destroy -auto-approve

Häufige Fallstricke

Entwicklerfehler, die bei der Compute-Automatisierung auf IONOS Cloud vermieden werden sollten:

1. Festlegung einer CPU-Familie auf einem vCPU Server

   • Problem: Ihr terraform apply schlägt fehl oder der Worker-Server wird mit einer unerwarteten CPU bereitgestellt, wenn Sie cpu_family auf einer vCPU-Konfiguration festlegen.
   • Warum es passiert: Die CPU-Familie eines vCPU Server kann nicht bei der Erstellung ausgewählt werden und kann später nicht geändert werden. Nur Dedicated Core-Server unterstützen die Auswahl der Familie (Core-Technologie-Auswahl).
   • Lösung: Lassen Sie cpu_family vollständig für vCPU-Server weg und legen Sie es nur auf Dedicated Core-Server fest:

   resource "ionoscloud_server" "worker" {
     cores = 2
     ram   = 4096
     # no cpu_family on vCPU servers
   }
   

2. Erwartung, dass VM Auto Scaling eine laufende VM ändert

   • Problem: Sie erhöhen die Kerne oder RAM in der Replikakonfiguration und erwarten, dass die bestehenden Replikas wachsen, aber die laufenden Virtuellen Maschinen bleiben dieselbe Größe.
   • Warum es passiert: VM Auto Scaling ist nur horizontal. Es fügt und entfernt ganze Replikas, anstatt sie zu ändern, und Änderungen an der Replikakonfiguration gelten nur für neu erstellte Replikas.
   • Lösung: Lassen Sie die Gruppe durch Hinzufügen von Replikas skaliert werden, um die Last aufzunehmen. Wenn ein Workload tatsächlich größere einzelne Virtuelle Maschinen benötigt, ändern Sie die Servergröße außerhalb der Auto-Skalierungsgruppe oder lassen Sie die Gruppe die Replikas ersetzen, damit die neue Größe wirksam wird.

3. Annahme, dass ein Cube die Abrechnung stoppt, wenn er ausgesetzt wird

   • Problem: Sie setzen Cubes, die für Batch-Jobs verwendet werden, aus, um Geld zu sparen, aber die Rechnung wächst weiter.
   • Warum es passiert: Für Cubes stoppt nur die Löschung die Abrechnung, nicht die Aussetzung. Die obligatorischen NVMe-Volume- und Template-Ressourcen bleiben während der Aussetzung reserviert.
   • Lösung: Bauen Sie ephemere Cubes mit terraform destroy ab, anstatt sie auszusetzen, oder konvertieren Sie den Workload in einen Standard-Server, den Sie stoppen können.

Zusammenfassung

Sie können jetzt IONOS-Computer vollständig als Code bereitstellen: Dedicated Core- und vCPU-Server mit den richtigen CPU- und RAM-Einschränkungen, cloud-init-Bootstrapping, das Ihre Laufzeit bei erstem Start installiert und startet, reservierte öffentliche IPs, die Rebuilds überstehen, und eine horizontale Auto-Skalierungsgruppe für zustandslose Arbeiter. Sie wissen auch, welche Workloads auf Standard-Servern versus Cubes gehören und wie sich die Abrechnungs- und Speichermodelle zwischen ihnen unterscheiden.

Dies ist die Compute-Basis von TaskBoard. Die nächste Einheit verbindet diese Server mit einem mehrstufigen Netzwerk, aber die Muster hier, datenquellenbasierte Bilder, base64-Cloud-Konfiguration, reservierte IP-Blöcke und horizontale Auto-Skalierung, wiederholen sich in jedem Infrastruktur-Stack, den Sie auf IONOS Cloud erstellen.

Wichtige Punkte:

• Dedicated Core-Server ermöglichen die Auswahl der CPU-Familie; vCPU-Server haben eine feste Familienauswahl bei der Erstellung
• VM Auto Scaling ist nur horizontal: es fügt ganze Server-Repliken hinzu und entfernt sie, und Änderungen an der Replik-Konfiguration gelten nur für neue Repliken
• Beide Servermodelle haben eine maximale Leistung von 62 Kernen / 60 vCPUs und 230 GB RAM, wobei RAM in 0,25-GB-Schritten eingestellt wird
• Cloud-init user_data ist base64-kodiert und unveränderlich; Änderungen erfordern die Neuerstellung des Volume
• Compute-Server existieren nur in Zone 1, Zone 2 oder AUTO, ohne Zone 3 für Compute
• Cubes haben eine feste, obligatorische NVMe-Volume-Konfiguration, unterstützen bis zu 23 zusätzliche Block Storage-Geräte und stoppen die Abrechnung nur bei Löschung

Wichtige Begriffe:

• Dedicated Core Server: Ein Compute-Server mit exklusiven physischen Kernen und einer auswählbaren, änderbaren CPU-Familie.
• vCPU Server: Ein Compute-Server mit gemeinsamen CPU-Ressourcen, deren CPU-Familie bei der Erstellung festgelegt ist.
• Cloud-init: Das erste-Start-Automatisierungspaket, das auf allen öffentlichen Linux-Bildern vorhanden ist und user_data-Konfigurationen wie Paketinstallationen und SSH-Schlüsselinjektion anwendet.
• Kern-Technologie-Auswahl: Die Dedicated Core-Funktion, die es Ihnen ermöglicht, einen vorhandenen Server auf eine neuere CPU-Generation ohne Neuaufbau zu übertragen.
• IP-Block: Ein reservierter Satz öffentlicher IP-Adressen (ionoscloud_ipblock), der über die Neuerstellung des Servers hinweg besteht und für stabile Endpunkte verwendet wird.

Nächste Schritte

Weiterlernen: Einheit 2.2: Netzwerk und Konnektivität als Code

Verwandte Themen:

• Einheit 1.2: Terraform-Anbieter und Kernmuster
• Einheit 2.4: Speicherbereitstellung als Code