Einheit 2.1: Compute und Server-Automatisierung

Einführung

Sie entwickeln TaskBoard, einen Task-Management-Dienst, der einen persistenten API-Server und eine Flotte zustandsloser Worker benötigt. Bevor Anwendungscode ausgeführt wird, muss die Compute-Ebene reproduzierbar, jedes Mal, aus einem Git-Repository und nicht aus einer Konsole provisioniert werden. Diese Einheit führt Sie von einer einzelnen ionoscloud_server-Ressource zu einer Auto-Scaling-Gruppe, wobei alles als Code ausgedrückt wird.

Compute in IONOS CLOUD bietet zwei Servermodelle mit unterschiedlichen Abrechnungs- und CPU-Semantiken, automatisierte Erststart-Konfiguration über cloud-init sowie einen horizontalen Auto-Scaler, der harte Anforderungen hat, die Sie korrekt kodieren müssen, damit Ihr terraform apply nicht fehlschlägt. Sie schreiben das Terraform für den API-Server von TaskBoard (Dedicated Core, 4 Kerne, 8 GB RAM) und seinen Worker (vCPU, 2 Kerne), integrieren cloud-init zur Installation der Laufzeitumgebung und verbinden eine öffentliche IP, damit Sie per SSH zugreifen und das Ergebnis überprüfen können.

1. Server mit Terraform provisionieren

Die ionoscloud_server-Ressource ist der zentrale Baustein der Compute-Ebene. Ein Server befindet sich immer in einem ionoscloud_datacenter (einem virtuellen Rechenzentrum, auch VDC genannt) und wird mit einer CPU-Familie, einer Kernanzahl und einem RAM-Bestand erstellt. Die zwei Entscheidungen, die alles Weitere bestimmen, sind der Servertyp, ENTERPRISE für Dedicated Core oder CUBE für Cubes, sowie die Wahl zwischen einer Dedicated Core-Konfiguration und einer vCPU-Konfiguration.

Ein minimales Dedicated Core-Server-Setup für die API-Ebene von TaskBoard sieht wie folgt aus. Das Boot-Volumen wird inline deklariert, und das Betriebssystem-Image wird über eine Datenquelle aufgelöst, statt hartkodiert 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
  }
}

RAM wird in Megabyte angegeben, daher entspricht 8 GB 8192. Die Servererstellung ist asynchron, aber der Terraform-Provider fragt den Status der IONOS CLOUD-Anfrage intern ab, sodass der Server zum Zeitpunkt, zu dem apply zurückkehrt, den Zustand DONE erreicht hat und das Boot-Volumen angehängt ist. Sie müssen in Terraform nicht manuell abfragen, wie Sie es bei einem direkten API-Aufruf tun würden.

1.1 Dedizierter Kern versus vCPU

Die Wahl des Servermodells ist nicht nur kosmetischer Natur. Ein Server mit dedizierten Kernen gewährt Ihrer VM den exklusiven Zugriff auf seine physischen Kerne, und Sie können die CPU-Familie auswählen und später ändern. Ein vCPU-Server teilt sich CPU-Ressourcen, und seine CPU-Familie ist bei der Erstellung festgelegt und kann danach nicht mehr geändert werden. Die API-Ebene von TaskBoard benötigt eine vorhersehbare Latenz, daher verwendet sie dedizierte Kerne. Die Worker-Ebene ist bursty und kostensensibel, daher verwendet sie vCPU.

Die beiden Modelle teilen sich dieselbe RAM-Obergrenze, unterscheiden sich jedoch in der CPU-Dimension. Die folgenden Grenzen stammen direkt von der Plattform und sind die Werte, gegen die Terraform validiert.

RAM kann in Schritten von 0,25 GB eingestellt werden. Die Funktion zur Änderung der CPU-Familie bei Servern mit dedizierten Kernen heißt Core Technology Choice, mit der Sie einen vorhandenen Server auf eine neuere CPU-Generation migrieren können, ohne ihn neu aufzubauen. Zu den verfügbaren CPU-Modellen gehören AMD EPYC Gen 3 (Milan), AMD EPYC Gen 5 (Turin), mehrere Intel Xeon Gen 5-Familien (Haswell, Broadwell, Skylake, Ice Lake) sowie Intel Xeon Gen 6 (Sierra Forest).

Der TaskBoard-Worker ist ein vCPU-Server. Beachten Sie das Fehlen von cpu_family, da diese 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

Compute-Server können in Verfügbarkeitszone 1, Zone 2 oder AUTO platziert werden. Für Compute gibt es keine Zone 3, obwohl Block Storage-Volumes 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 hinweg zur Fehlertoleranz. In diesem Fall binden Sie einen Server an ZONE_1 und einen weiteren 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 automatisiertes Bootstrapping

Ein provisionierter 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 Einfügen von SSH-Schlüsseln. Alle öffentlichen Linux-Images auf IONOS CLOUD (Alma Linux, Debian, Rocky Linux und Ubuntu) werden mit bereits installiertem cloud-init ausgeliefert, sodass Sie die Konfiguration über das Feld user_data übergeben und diese automatisch ausgeführt wird.

Sie übergeben user_data als base64-kodierten String in Terraform und der API. Der dekodierte Inhalt kann ein cloud-config YAML-Dokument, ein Shell-Skript, eine Include-Datei oder mehrere andere unterstützte 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-Runtime, erstellt einen Anwendungsnutzer und startet den TaskBoard API-Dienst. Es befindet sich in einer separaten Datei und wird durch die Funktion base64encode von Terraform 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

Binden Sie es mit user_data in die Server-Ressource ein. Die Verwendung von templatefile ermöglicht es Ihnen, Variablen wie den SSH-Schlüssel zum Planungszeitpunkt in die cloud-config einzufügen.

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
  }
}

Zu den unterstützten Formaten für Benutzerdaten gehören base64-kodierte Daten (der dekodierte Inhalt muss zu einem unterstützten Typ auflösbar sein), ein Benutzerdatenskript, das mit #! oder Content-Type: text/x-shellscript beginnt, eine Include-Datei, die mit #include beginnt, cloud-config-Daten, die in YAML mit #cloud-config beginnen, sowie upstart-Jobs. Die Eigenschaft user_data ist unveränderlich: Sie wird nur bei der Erstellung des Volumes berücksichtigt. Eine spätere Änderung erfordert daher die Neuerschaffung des Volumes, nicht eine Aktualisierung an Ort und Stelle.

2.2 SSH-Schlüssel und Verifikation beim ersten Start

Sie können SSH-Schlüssel auf zwei Weisen einfügen: über die Liste ssh_keys des Volumes oder innerhalb des cloud-config-Blocks ssh_authorized_keys. Das Argument ssh_keys ist der einfachste Weg für einen einzelnen Schlüssel für den Standardbenutzer. Nach apply erscheint die öffentliche IP in den exportierten Attributen der Netzwerkkarte, und Sie können sich sofort verbinden.

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 wird fortgesetzt, bis die Erststartkonfiguration abgeschlossen ist. Dies ist das korrekte Signal dafür, dass Ihre Pakete installiert und die Dienste ausgeführt werden. Gehen Sie nicht davon aus, dass der Server bereit ist, nur weil SSH die Verbindung akzeptiert.

3. Zuweisung öffentlicher IP-Adressen

Server in einem öffentlichen LAN erhalten automatisch eine IP-Adresse über DHCP, diese Adresse ist jedoch temporär und kann sich ändern. Für eine stabile, reservierte öffentliche IP-Adresse wird ein ionoscloud_ipblock zugewiesen und eine seiner Adressen der NIC zugewiesen. Dies ist für den API-Endpunkt von TaskBoard erforderlich, auf den DNS-Einträge und Load Balancer zeigen.

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 Argument size steuert, wie viele Adressen der Block reserviert. Eine reservierte IP übersteht die Neuerrichtung eines Servers, was bedeutet, dass Sie den API-Server neu aufbauen können, ohne die Adresse zu ändern, auf die Ihre DNS-Einträge zeigen. Der Wert location des IP-Blocks muss dem Standort des Rechenzentrums entsprechen, andernfalls schlägt die Zuweisung fehl.

4. Images und Snapshots als Code

Die Datenquelle ionoscloud_image löst ein Betriebssystem-Image bei der Planungsphase in eine ID auf, sodass Sie eine volatile Image-Kennung niemals hartkodieren müssen. Filtern Sie nach type, location, cloud_init und image_alias, um das exakte Image festzulegen, das Sie benötigen.

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

Für reproduzierbare Goldumgebungen erfassen Sie ein konfiguriertes Boot-Volumen als Snapshot und provisionieren Sie neue Server daraus. Die Ressource ionoscloud_snapshot erstellt einen Snapshot aus einem vorhandenen Volumen, und diese Snapshot-ID kann zur Initialisierung zukünftiger Volumene verwendet werden.

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 befinden sich in derselben Region wie das Quellvolumen. Die Verwendung eines Snapshots als Grundlage für neue Server überspringt den cloud-init-Installationsschritt für alle in das Image integrierten Komponenten. Dadurch wird das Skalieren beschleunigt und Drift zwischen neu erstellten Knoten vermieden.

5. VM Auto Scaling

VM Auto Scaling ist derzeit im Early Access (EA); IONOS CLOUD empfiehlt, den Einsatz auf Nicht-Produktions-Workloads zu beschränken. Die Cloud API ist separat versioniert unter https://api.ionos.com/autoscaling (Version v1.ea), nicht unter 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 weitere VMs hinzu, vergrößert jedoch keine bestehende VM. Sie definieren eine Zielkonfiguration für Replikate, Skalierungsrichtlinien für Skalierung nach innen und nach außen sowie die Metrik, die diese steuert.

Behalten Sie das Skalierungsmodell im Blick: VM Auto Scaling ist ausschließlich horizontal. Es fügt ganze Server-Replikate Ihrem ionoscloud_autoscaling_group hinzu und entfernt sie wieder, unterstützt durch Compute Engine-Server. Änderungen an der Replikat-Konfiguration gelten für neu erstellte Replikate, nicht für bereits laufende Replikate. Die unterstützten Replikat-Speicherarten sind HDD, SSD Premium und SSD Standard. Die verfügbaren Skalierungsmetriken sind: durchschnittliche CPU-Auslastung der Instanz (Prozent), eingehende Netzwerk-Bytes, ausgehende Netzwerk-Bytes, eingehende Netzwerk-Pakete und ausgehende Netzwerk-Pakete.

5.1 Auto Scaling Group via Terraform

Die ionoscloud_autoscaling_group-Ressource definiert die Gruppe, deren Replikat-Vorlage und deren Richtlinie. Die Replikat-Vorlage definiert die Dimensionierung für jedes Server-Replikat, das 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"))
    }
  }
}

Die amount_type kann ABSOLUTE (eine feste Anzahl von VMs) oder PERCENTAGE (ein Anteil der aktuellen Anzahl) sein. Die Standard-Cooling-Down-Zeit beträgt 5 Minuten, die minimale Replikatenanzahl ist 1, und der empfohlene Höchstwert liegt bei etwa 100 Replikaten. Eine Gruppe kann einem Application Load Balancer zugeordnet werden, sodass neue Replikate automatisch dem LB-Ziel-Pool hinzugefügt werden.

5.2 Replikate werden benannt, nicht über Server-ID adressierbar

Ein subtiler operativer Stolperstein: automatisch generierte Servernamen von Replikaten sind Namen, keine Server-IDs, und sie können nicht verwendet werden, um Informationen über die API abzurufen. Wenn Ihre Überwachungs- oder Deployment-Skripte davon ausgehen, dass sie GET /servers/{id} können, indem sie den Replikatennamen verwenden, schlägt der Aufruf fehl. Behandeln Sie Replikate als Viehherde. Verweisen Sie über die Gruppe und den Load Balancer, nicht über eine individuelle Server-ID.

6. Cubes für stateless Workloads

Cubes sind ein Servertyp für Compute mit verpflichtend direkt angebundenem NVMe-Speicher, der durch ein Konfigurationsvorlage definiert wird. Die kleinste Vorlage, Basic Cube XS, bietet 1 vCPU, 2 GB RAM und 60 GB direkt angebundenen NVMe-Speicher. Die Größe der vCPU, des RAM und des direkt angebundenen Speichers ist durch die Vorlage festgelegt und kann nach der Bereitstellung des Cubes nicht geändert werden. Der NVMe-Volumen kann nicht ausgehängt oder gelöscht werden.

Ein Cube besteht jedoch nicht nur aus Speicher. Zusätzlich zum verpflichtenden NVMe-Volumen können Sie bis zu 23 zusätzliche Block-Speichergeräte anbinden, insgesamt 24 Geräteslots, wobei das NVMe-Volumen einen Slot belegt. Der NVMe-Speicher mit fester Vorlage und das günstigere, suspend-freundliche Modell machen Cubes zu einer guten Wahl für stateless oder ephemere Workloads, bei denen ein vorhersehbares Bundle gewünscht ist.

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 Abrechnungsfeinheit, die in Ihren Lebenszyklus-Skripten berücksichtigt werden sollte: Bei Cubes stoppt nur die Löschung die Abrechnung, nicht die Aussetzung. Die Aussetzung eines Cubes lässt den Zähler weiterlaufen. Wenn Sie Cubes für Batch-Jobs starten und erwarten, dass die Kosten durch deren Aussetzung gestoppt werden, werden Sie überrascht sein. Führen Sie terraform destroy auf ephemeren Cubes aus, um die Kosten tatsächlich zu stoppen.

API-Referenz-Schnellkarte

Wichtige API-Endpunkte für die Compute-Versorgung:

Compute Engine / IP Blocks Basis-URL: https://api.ionos.com/cloudapi/v6 VM Auto Scaling Basis-URL (Early Access): https://api.ionos.com/autoscaling/v1.ea Authentifizierung: Authorization: Bearer <token>

Code Lab

Ziel: Deployment der Compute-Ebene von TaskBoard mit Terraform: ein Dedicated Core API-Server, der durch cloud-init initialisiert wird, mit einer reservierten öffentlichen IP, sowie Überprüfung des SSH-Zugriffs.

Voraussetzungen:

• IONOS CLOUD-Konto mit einem API-Token (IONOS_TOKEN exportiert)
• Lokal installiertes Terraform 1.5 oder höher
• Ein SSH-Schlüsselpaar (~/.ssh/id_ed25519.pub)

Schritt 1: Provider konfigurieren

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

Erwartete Ausgabe:

$ terraform init
Terraform has been successfully initialized!

Schritt 2: Die cloud-init-Datei erstellen (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: Rechenzentrum, Image und IP-Block definieren

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: Den API-Server definieren

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: cloud-init und SSH überprüfen

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

Erwartete Ausgabe:

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

Validierungscheckliste:

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

Aufräumen:

terraform destroy -auto-approve

Häufige Fehler

Fehler von Entwicklerinnen und Entwicklern, die bei der Compute-Automatisierung auf IONOS CLOUD zu vermeiden sind:

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 in einer vCPU-Konfiguration festlegen.
   • Ursache: Die CPU-Familie eines vCPU-Servers kann weder bei der Erstellung ausgewählt noch später geändert werden. Nur Dedicated Core-Server unterstützen die Auswahl der Familie (Core Technology Choice).
   • Lösung: cpu_family für vCPU-Server vollständig weglassen und nur auf Dedicated Core-Servern festlegen:

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

2. Erwartung, dass VM Auto Scaling eine laufende VM neu dimensioniert

   • Problem: Sie erhöhen die Anzahl der Kerne oder den RAM in der Replikatkonfiguration in der Erwartung, dass bestehende Replikate wachsen, aber die laufenden VMs bleiben gleich groß.
   • Ursache: VM Auto Scaling ist ausschließlich horizontal. Es fügt ganze Replikate hinzu und entfernt sie, anstatt sie neu zu dimensionieren, und Änderungen an der Replikatkonfiguration gelten nur für neu erstellte Replikate.
   • Lösung: Lassen Sie die Gruppe durch Hinzufügen von Replikaten horizontal skalieren, um die Last aufzunehmen. Wenn eine Workload tatsächlich größere einzelne VMs benötigt, dimensionieren Sie den Server außerhalb der Auto-Scaling-Gruppe neu oder lassen Sie die Gruppe Replikate ersetzen, damit die neue Dimensionierung wirksam wird.

3. Annahme, dass ein Cube bei Suspendierung keine Kosten mehr verursacht

   • Problem: Sie suspendieren Cubes, die für Batch-Jobs verwendet werden, um Geld zu sparen, aber die Rechnung wird weiterhin größer.
   • Ursache: Bei Cubes stoppt nur die Löschung die Abrechnung, nicht die Suspendierung. Das obligatorische NVMe-Volumen und die Template-Ressourcen bleiben während der Suspendierung reserviert.
   • Lösung: Richten Sie ephemere Cubes mit terraform destroy ab, anstatt sie zu suspendieren, oder wandeln Sie die Workload in einen Standard-Server um, den Sie stoppen können.

Zusammenfassung

Sie können Compute-Ressourcen in IONOS CLOUD nun vollständig als Code provisionieren: Dedicated Core- und vCPU-Server mit den richtigen CPU- und RAM-Einschränkungen, cloud-init-Bootstrapping, das Ihre Laufzeitumgebung beim ersten Start installiert und startet, reservierte öffentliche IPs, die Rebuilds überstehen, und eine horizontale Auto-Scaling-Gruppe für stateless Worker. Sie wissen auch, welche Workloads auf Standardservern und welche auf Cubes laufen sollten, und wie sich die Abrechnungs- und Speichermodelle zwischen ihnen unterscheiden.

Dies ist die Compute-Grundlage von TaskBoard. Die nächste Einheit verbindet diese Server mit einem mehrstufigen Netzwerk, aber die hier gezeigten Muster, also datenquellenbasiert aufgelöste Images, base64-kodiertes cloud-config, reservierte IP-Blöcke und horizontales Auto-Scaling, wiederholen sich in jedem Infrastruktur-Stack, den Sie auf IONOS CLOUD aufbauen.

Wichtige Punkte:

• Dedicated Core-Server ermöglichen die Auswahl der CPU-Familie; vCPU-Server haben einen festen Satz an Familien bei der Erstellung
• VM Auto Scaling ist ausschließlich horizontal: Es fügt ganze Server-Replikate hinzu und entfernt sie, und Änderungen an der Replikat-Konfiguration gelten nur für neue Replikate
• Beide Servermodelle erreichen maximal 62 Kerne / 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; eine Änderung erfordert die Neuerstellung des Volumes
• Compute-Server existieren nur in Zone 1, Zone 2 oder AUTO, ohne Zone 3 für Compute
• Cubes haben ein festes, verpflichtendes NVMe-Volume, unterstützen bis zu 23 zusätzliche Block-Speichergeräte und stoppen die Abrechnung nur bei der Löschung

Wichtige Begriffe:

• Dedicated Core-Server: Ein Compute-Server mit exklusiven physischen Kernen und einer wählbaren, änderbaren CPU-Familie.
• vCPU-Server: Ein Compute-Server mit geteilten CPU-Ressourcen, dessen CPU-Familie nicht wählbar und nicht änderbar ist (der Hypervisor weist sie zu).
• Cloud-init: Das Automatisierungspaket für den ersten Start, das auf allen öffentlichen Linux-Images vorhanden ist und user_data-Konfigurationen wie Paketinstallationen und SSH-Schlüssel-Injektion anwendet.
• Core Technology Choice: Die Dedicated Core-Funktion, mit der Sie einen vorhandenen Server auf eine neuere CPU-Generation migrieren können, ohne ihn neu aufzubauen.
• IP-Block: Ein reservierter Satz öffentlicher IP-Adressen (ionoscloud_ipblock), der bei der Neuerstellung von Servern bestehen bleibt und für stabile Endpunkte verwendet wird.

Nächste Schritte

Weiter lernen: Einheit 2.2: Netzwerk und Konnektivität als Code

Verwandte Themen:

• Einheit 1.2: Terraform Provider und Kernmuster
• Einheit 2.4: Speicherbereitstellung als Code