Einheit 1.2: Terraform Provider und Kernmuster

Einführung

In Einheit 1.1 haben Sie einen Server auf drei Arten provisioniert: über die rohe API mit curl, über das Python SDK und über ionosctl. Alle drei Ansätze sind imperativ. Sie senden eine POST, befragen /requests/{id}/status, bis DONE, und senden dann den nächsten Aufruf. Das funktioniert, liefert aber keine reproduzierbare, versionierte Beschreibung Ihrer Infrastruktur. Für TaskBoard, die Aufgabenvorgabe-API und das Frontend, die Sie in diesem Kurs entwickeln, benötigen Sie Infrastruktur, die in Git verwaltet wird, wie Code geprüft wird und sauber abgebaut wird, damit Testumgebungen Sie nie unbemerkt in Rechnung stellen.

In dieser Einheit wechseln Sie zu deklarativem Provisioning mit dem IONOS CLOUD Terraform Provider. Sie schreiben das HCL, das die Basis-VDC von TaskBoard erstellt, beobachten, was Terraform unter der Haube mit der asynchronen IONOS CLOUD API tut, speichern den Zustand remote in Object Storage und übernehmen das Muster für ephemere Umgebungen, das Kosten unter Kontrolle hält. Das asynchrone Abfragen, das Sie in 1.1 manuell durchgeführt haben, ist nun Aufgabe des Providers.

1. Provider-Einrichtung und Authentifizierung

Der IONOS CLOUD Provider für Terraform interagiert mit Compute-, Storage- und Netzwerkressourcen von IONOS CLOUD. Er unterstützt derzeit die neuesten V5- und V6-API-Angebote und wird im Terraform Registry unter ionos-cloud/ionoscloud veröffentlicht. Damit alles funktioniert, benötigen Sie ein IONOS CLOUD Konto, dessen Zugangsdaten sich gegenüber der Cloud API authentifizieren, genau wie in Einheit 1.1.

1.1 Deklaration und Versionsfestlegung des Providers

Legen Sie die Provider-Version immer fest. Der required_providers-Block von Terraform sichert eine bekannte, stabile Version, sodass ein terraform init im nächsten Monat keine brechenden Änderungen in Ihre Pipeline einzieht.

# versions.tf
terraform {
  required_version = ">= 1.5.0"

  required_providers {
    ionoscloud = {
      source  = "ionos-cloud/ionoscloud"
      version = "~> 6.4"
    }
  }
}

Die ~> 6.4-Einschränkung erlaubt Patch- und Minor-Updates innerhalb der 6.x-Zeile, blockiert jedoch einen Sprung auf 7.0. Führen Sie terraform init aus, um den festgelegten Provider in .terraform/ herunterzuladen. Übergeben Sie die generierte .terraform.lock.hcl-Datei in die Versionskontrolle, damit jeder Teammitglied und jeder CI-Runner den identischen Provider-Build auflöst.

1.2 Authentifizierung: Umgebungsvariable vs. Provider-Block

Das sauberste Muster besteht darin, sich über die Umgebungsvariable IONOS_TOKEN mit dem Bearer-Token von Token Manager (in Einheit 1.1 behandelt) zu authentifizieren. So berührt kein sensibler Inhalt Ihr HCL oder Ihre Git-Verlaufshistorie.

export IONOS_TOKEN="eyJ0eXAiOiJKV1QiLCJraWQiO..."
terraform plan

Da die Variable gesetzt ist, kann der Provider-Block leer sein:

# provider.tf
provider "ionoscloud" {}

Sie können auch Credentials explizit im Provider-Block übergeben, was nützlich ist, wenn eine einzelne Konfiguration Ressourcen über mehr als ein Konto hinweg verwaltet. Benutzername und Passwort (Basic Auth) werden als Alternative zum Token unterstützt.

provider "ionoscloud" {
  token = var.ionos_token   # never hardcode; pass via TF_VAR_ionos_token
}

Verwenden Sie die Umgebungsvariable IONOS_TOKEN, anstatt ein Token in einer .tfvars-Datei zu versionieren. Falls Sie eine Variable verwenden müssen, markieren Sie sie als sensitive = true und stellen Sie sie über TF_VAR_ionos_token in Ihrer Shell oder Ihrem CI-Secret-Store bereit.

2. Kernressourcen: Aufbau eines VDC

Eine TaskBoard-Basisumgebung benötigt ein virtuelles Rechenzentrum, ein LAN, einen Server, ein Boot-Volume und eine NIC, die den Server mit dem LAN verbindet. Jede IONOS CLOUD Terraform-Ressource ist mit ionoscloud_ präfixiert, was sie eindeutig macht, wenn eine Konfiguration mehrere Provider mischt.

2.1 Rechenzentrum, LAN, Server, Volume, NIC

Die unten aufgeführten Ressourcennamen (ionoscloud_datacenter, ionoscloud_lan, ionoscloud_server, ionoscloud_nic) und ihre Attribut-Schemata folgen der Dokumentation des IONOS CLOUD Terraform-Providers. Der Standortwert und die Bildauswahl basieren auf den Data-Source-Abschnitten dieser Einheit.

# main.tf
resource "ionoscloud_datacenter" "taskboard" {
  name        = "taskboard-base"
  location    = "de/fra"
  description = "TaskBoard base VDC, managed by Terraform"
}

resource "ionoscloud_lan" "app" {
  datacenter_id = ionoscloud_datacenter.taskboard.id
  name          = "taskboard-app-lan"
  public        = true
}

resource "ionoscloud_server" "api" {
  name              = "taskboard-api"
  datacenter_id     = ionoscloud_datacenter.taskboard.id
  cores             = 2
  ram               = 4096
  cpu_family        = "INTEL_SKYLAKE"
  availability_zone = "AUTO"

  volume {
    name           = "taskboard-api-boot"
    size           = 20
    disk_type      = "SSD"
    image_name     = data.ionoscloud_image.ubuntu.id
    image_password = var.server_password
  }

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

Beachten Sie, dass die Inline-Blöcke volume und nic es Ihnen ermöglichen, die Boot-Disk und die Netzwerkanbindung als Teil des Servers auszudrücken. Für ein nach dem Bootvorgang angehängtes Datenvolumen oder um den Lebenszyklus einer Disk unabhängig zu verwalten, deklarieren Sie stattdessen ein eigenständiges ionoscloud_volume.

2.2 Eigenständiges Volume und NIC

resource "ionoscloud_volume" "data" {
  datacenter_id = ionoscloud_datacenter.taskboard.id
  server_id     = ionoscloud_server.api.id
  name          = "taskboard-data"
  size          = 50
  disk_type     = "SSD"
  licence_type  = "OTHER"
}

resource "ionoscloud_nic" "extra" {
  datacenter_id = ionoscloud_datacenter.taskboard.id
  server_id     = ionoscloud_server.api.id
  lan           = ionoscloud_lan.app.id
  dhcp          = true
}

Die Referenzen wie ionoscloud_datacenter.taskboard.id und ionoscloud_server.api.id sind es, die Terraform seine Reihenfolge geben. Da das server_id des Volumes aus der Serverressource liest, weiß Terraform, dass der Server zuerst existieren muss. Sie schreiben nie explizite „Warte auf das Rechenzentrum"-Logik. Dieser Abhängigkeitsgraph ist der eigentliche Grund, von den imperativen Skripten aus Einheit 1.1 wegzugehen.

3. Der plan/apply/destroy-Lebenszyklus

Die drei Befehle, die Sie ständig ausführen werden, sind terraform plan, terraform apply und terraform destroy. Das Verständnis dessen, was jeder dieser Befehle gegenüber der asynchronen IONOS CLOUD API tut, spart Stunden an Verwirrung.

3.1 Was im Hintergrund geschieht

terraform plan liest Ihre HCL, liert den aktuellen Zustand ab, fragt bei der IONOS CLOUD API den Live-Zustand jeder verwalteten Ressource ab und gibt die Differenz aus. Es ändert nichts. terraform apply führt diese Differenz aus, indem es dieselben POST, PUT und DELETE-Aufrufe ausführt, die Sie in 1.1 manuell getätigt haben.

Hier ist der entscheidende Punkt: IONOS CLOUD API-Vorgänge sind asynchron. Ein POST gibt eine Request-ID zurück, und die Ressource ist noch nicht bereit. In Einheit 1.1 haben Sie /requests/{id}/status abgefragt, bis DONE, bevor der nächste Aufruf erfolgte. Der IONOS CLOUD Terraform Provider führt dieses Abfragen intern für jede Ressource durch. Wenn apply eine Ressource als noch in der Erstellung anzeigt, wartet er genau auf diesen Request-Status, bevor er zu abhängigen Ressourcen übergeht.

terraform plan -out=taskboard.tfplan
terraform apply taskboard.tfplan

Das Speichern des Plans in einer Datei mit -out und das Anwenden genau dieser Datei stellt sicher, dass apply genau das ausführt, was Sie überprüft haben, ohne Abweichungen zwischen Plan und Anwendung. Dies ist das sichere Muster für CI/CD.

3.2 Zerstören und gezielte Operationen

# Preview what will be torn down
terraform plan -destroy

# Tear it all down
terraform destroy

# Operate on a single resource (use sparingly)
terraform apply -target=ionoscloud_server.api

terraform destroy durchläuft den Abhängigkeitsgraphen in umgekehrter Reihenfolge: NICs und Volumes vor dem Server, der Server vor dem LAN, das LAN vor dem Datacenter. Diese umgekehrte Reihenfolge ist der Grund, warum Sie Terraform die Verwaltung des gesamten Stacks überlassen sollten, anstatt Ressourcen manuell im DCD zu löschen, was dazu führen kann, dass der Terraform-Zustand nicht mehr mit der Realität übereinstimmt.

4. Remote State in Object Storage

Standardmäßig schreibt Terraform den State in eine lokale terraform.tfstate-Datei. Das funktioniert weder für ein Team noch für eine Pipeline. Der State muss an einem gemeinsamen Ort abgelegt werden. IONOS Cloud Object Storage ist S3-kompatibel und eignet sich daher als Terraform-Backend.

4.1 Konfiguration des S3-Backends

IONOS CLOUD Object Storage authentifiziert sich mit einem Access Key und einem Secret Key, nicht mit Bearer-Tokens. Es handelt sich um dieselben S3-Zugangsdaten, die Sie in der Key-Verwaltung von Object Storage erzeugen. Object Storage ist in mehreren Regionen verfügbar, wobei jede Region über ein eigenes Endpoint verfügt, darunter Frankfurt (de) unter s3.eu-central-1.ionoscloud.com, Berlin (eu-central-2) unter s3.eu-central-2.ionoscloud.com und Logroño (eu-south-2) unter s3.eu-south-2.ionoscloud.com.

# backend.tf
terraform {
  backend "s3" {
    bucket   = "taskboard-tfstate"
    key      = "base/terraform.tfstate"
    region   = "eu-central-1"
    endpoints = {
      s3 = "https://s3.eu-central-1.ionoscloud.com"
    }
    skip_credentials_validation = true
    skip_region_validation      = true
    skip_requesting_account_id  = true
    skip_s3_checksum            = true
  }
}

Die skip_* Flags sind erforderlich, da es sich um einen externen (nicht-AWS) S3-Anbieter handelt. Ohne diese Flags versucht das Backend, AWS-spezifische Endpunkte wie den Security Token Service aufzurufen, was zu einem Fehler führt. Stellen Sie die Zugangsdaten über die standardmäßigen S3-Umgebungsvariablen bereit, damit sie niemals in Ihrem HCL-Code enthalten sind:

export AWS_ACCESS_KEY_ID="your-object-storage-access-key"
export AWS_SECRET_ACCESS_KEY="your-object-storage-secret-key"
terraform init   # migrates local state into the bucket

4.2 Überlegungen zum State Locking

State Locking verhindert, dass zwei apply-Ausführungen den State gleichzeitig beschädigen. AWS S3-Backends stützen sich traditionell auf eine DynamoDB-Tabelle für Locks, die IONOS CLOUD Object Storage nicht bereitstellt. Behandeln Sie das IONOS CLOUD S3-Backend als nicht gesperrt: Serialisieren Sie Applies über eine einzelne CI/CD-Pipeline, führen Sie niemals parallele Applies gegen denselben State-Schlüssel aus und verwenden Sie einen separaten State-key pro Umgebung (zum Beispiel base/, staging/, prod/), damit nicht zusammenhängende Stacks niemals um Ressourcen konkurrieren.

5. Datenquellen, Importe und Kostenkontrolle

Das Harteinbetten von Bild-IDs und Regionszeichenketten macht Konfigurationen anfällig. Datenquellen fragen die IONOS CLOUD API während der Planungsphase ab, damit Ihr HCL portierbar bleibt. Importe übernehmen Ressourcen, die außerhalb von Terraform erstellt wurden, in die Verwaltung. Und eine disziplinierte Zerstörung hält Ihre Rechnung ehrlich.

5.1 Datenquellen für Bilder und Standorte

data "ionoscloud_location" "frankfurt" {
  name    = "fra"
  feature = "SSD"
}

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

Die ionoscloud_image-Datenquelle löst ein aktuelles Image auf, sodass Sie keine veraltete Image-UUID verwenden, die möglicherweise außer Dienst gestellt wird. Die ionoscloud_location-Datenquelle bestätigt eine Region und die Verfügbarkeit ihrer Funktionen, bevor Sie darin Ressourcen bereitstellen. Verweisen Sie auf das Ergebnis mit data.ionoscloud_image.ubuntu.id im volume-Block des Servers, wie in Abschnitt 2 gezeigt.

Die folgende Tabelle fasst die vier Möglichkeiten zusammen, die Bereitstellung in IONOS CLOUD zu steuern, die Sie in den Einheiten 1.1 und 1.2 kennengelernt haben.

Verwenden Sie Terraform, wenn die Infrastruktur reproduzierbar und überprüfbar sein muss. Greifen Sie für Laufzeitoperationen und schnelle Prüfungen, die nicht in Ihrem deklarativem Stack gehören, zum SDK oder zu ionosctl.

5.2 Importieren bestehender Ressourcen

Wenn ein Rechenzentrum oder ein Server bereits existiert, möglicherweise erstellt im DCD oder durch ein früheres curl-Skript, importieren Sie ihn, anstatt ihn neu zu erstellen. Erstellen Sie zuerst einen passenden Ressourcenblock und importieren Sie dann. IONOS CLOUD-Importe verwenden eine zusammengesetzte ID, die die Rechenzentrums-ID und die Ressourcen-ID verbindet.

# Import an existing server: format is datacenter_id/server_id
terraform import ionoscloud_server.api \
  3fa85f64-5717-4562-b3fc-2c963f66afa6/9bc92f81-1234-4cde-8901-abcdef012345

# Import a datacenter (single ID)
terraform import ionoscloud_datacenter.taskboard 3fa85f64-5717-4562-b3fc-2c963f66afa6

Nach dem Import führen Sie terraform plan aus. Wenn der Plan Änderungen anzeigt, entspricht Ihre HCL-Datei noch nicht dem Ist-Zustand. Passen Sie die Attribute des Ressourcenblocks an die laufende Konfiguration an, bis plan keine Änderungen mehr meldet. Erst dann wird die Ressource sicher verwaltet.

5.3 Kostenbewusstsein und ephemere Umgebungen

Jede Ressource, die Terraform in apply bereitstellt, verursacht Kosten ab dem Zeitpunkt ihrer Existenz. Der disziplinierte Workflow lautet: Führen Sie immer plan vor apply aus und räumen Sie immer destroy auf, was Sie für Tests gestartet haben. Das Muster der ephemeren Umgebung erstellt einen vollständigen Stack für einen Testlauf und baut ihn anschließend wieder ab.

# Spin up a throwaway environment for a feature branch
terraform workspace new pr-142
terraform apply -auto-approve

# ... run integration tests against the live infrastructure ...

# Tear it all down so it stops billing
terraform destroy -auto-approve
terraform workspace delete pr-142

Das Einbinden von terraform destroy in den Aufräum-Schritt eines CI-Jobs stellt sicher, dass eine vergessene Branch-Umgebung nicht über Wochen hinweg unbemerkt Kosten verursacht.

API-Referenz Schnellkarte

Der IONOS CLOUD Terraform-Provider ruft intern diese Cloud-API-Endpunkte auf. Das Wissen darüber hilft bei der Fehlersuche in einem festgefahrenen apply.

Basis-URL: https://api.ionos.com/cloudapi/v6 Authentifizierung: Authorization: Bearer <token> (der Provider liest IONOS_TOKEN)

Code Lab

Ziel: Erstellen Sie das Basis-VDC von TaskBoard mit Terraform: ein Datacenter, ein LAN und ein Server mit einem angehängten Volume. Planen, anwenden, verifizieren und zerstören.

Voraussetzungen:

• IONOS CLOUD Konto mit einem als IONOS_TOKEN exportierten API-Token
• Lokal installiertes Terraform 1.5 oder neuer
• ionosctl konfiguriert (aus Einheit 1.1) zur Verifizierung

Schritt 1: Konfiguration aufbauen

mkdir taskboard-base && cd taskboard-base
touch versions.tf provider.tf main.tf

Erwartete Ausgabe:

(no output; three empty files created)

Schritt 2: Anbieter hinzufügen und Version festlegen

Fügen Sie den Inhalt von versions.tf aus Abschnitt 1.1 und provider "ionoscloud" {} aus Abschnitt 1.2 in Ihre Dateien ein und initialisieren Sie anschließend.

terraform init

Erwartete Ausgabe:

Initializing provider plugins...
- Installing ionos-cloud/ionoscloud v6.4.x...
Terraform has been successfully initialized!

Schritt 3: VDC-Ressourcen schreiben

Fügen Sie die Blöcke ionoscloud_datacenter, ionoscloud_lan und ionoscloud_server aus Abschnitt 2.1 sowie die Datenquelle ionoscloud_image aus Abschnitt 5.1 zu main.tf hinzu.

Schritt 4: Planen und überprüfen

export TF_VAR_server_password="ChangeMe-Strong-Pw-1"
terraform plan -out=taskboard.tfplan

Erwartete Ausgabe:

Plan: 3 to add, 0 to change, 0 to destroy.

Schritt 5: Anwenden

terraform apply taskboard.tfplan

Erwartete Ausgabe:

ionoscloud_datacenter.taskboard: Creation complete after 25s [id=3fa85f64-...]
ionoscloud_server.api: Still creating... [1m20s elapsed]
ionoscloud_server.api: Creation complete after 2m10s [id=9bc92f81-...]
Apply complete! Resources: 3 added, 0 changed, 0 destroyed.

Schritt 6: Verifizieren mit ionosctl

terraform output -raw datacenter_id 2>/dev/null || true
ionosctl server list --datacenter-id $(terraform state show ionoscloud_datacenter.taskboard | grep -m1 'id ' | awk '{print $3}' | tr -d '"')

Erwartete Ausgabe:

ServerId   Name            State       Cores   Ram
9bc92f81   taskboard-api   AVAILABLE   2       4096

Schritt 7: Zustand prüfen

terraform state list

Erwartete Ausgabe:

data.ionoscloud_image.ubuntu
ionoscloud_datacenter.taskboard
ionoscloud_lan.app
ionoscloud_server.api

Prüfliste:

• [ ] terraform apply mit 3 hinzugefügten Ressourcen abgeschlossen
• [ ] ionosctl server list zeigt den Server als AVAILABLE
• [ ] terraform state list zeigt alle verwalteten Ressourcen

Aufräumarbeiten:

terraform destroy -auto-approve

Häufige Fehler

1. Löschen von Ressourcen im DCD, die von Terraform verwaltet werden

   • Problem: Sie löschen den Server manuell in der Web-Oberfläche, woraufhin terraform apply einen Fehler meldet oder versucht, nicht zusammenhängende Ressourcen neu zu erstellen.
   • Ursache: Der Terraform-Zustand erfasst den gelöschten Server weiterhin. Die aktive API enthält ihn nicht mehr, sodass sich Zustand und Realität voneinander unterscheiden.
   • Lösung: Entfernen Sie den veralteten Eintrag aus dem Zustand und lassen Sie dann Terraform die Abweichungen beheben:

   terraform state rm ionoscloud_server.api
   terraform plan   # now matches reality
   

2. Vergessen der S3-Backend-Skip-Flags

   • Problem: terraform init gegen das Object Storage-Backend hängt oder schlägt mit einem STS- oder Account-ID-Fehler fehl.
   • Ursache: Das S3-Backend geht von AWS aus und versucht AWS-spezifische Aufrufe, die IONOS CLOUD Object Storage nicht implementiert.
   • Lösung: Fügen Sie die Skip-Flags und den expliziten Endpunkt zum Backend-Block hinzu:

   skip_credentials_validation = true
   skip_region_validation      = true
   skip_requesting_account_id  = true
   endpoints = { s3 = "https://s3.eu-central-1.ionoscloud.com" }
   

3. Ein veraltetes Image-UUID fest einbinden, anstatt eine Datenquelle zu verwenden

   • Problem: terraform apply schlägt Monate nach der letzten erfolgreichen Konfiguration mit einem Fehler fehl, bei dem das Image nicht gefunden wird.
   • Ursache: Eine hartkodierte Image-UUID wurde auf der Quellseite zurückgezogen. Die asynchrone Servererstellung wird abgebrochen, da ihr Startvolumen auf ein fehlendes Image verweist.
   • Lösung: Lösen Sie das Image zur Planungszeit mit der Datenquelle auf und verweisen Sie darauf:

   data "ionoscloud_image" "ubuntu" {
     type        = "HDD"
     location    = "de/fra"
     image_alias = "ubuntu:latest"
   }
   # volume { image_name = data.ionoscloud_image.ubuntu.id }
   

Zusammenfassung

Sie können nun IONOS CLOUD-Infrastruktur deklarativ beschreiben und ihren vollständigen Lebenszyklus aus Code heraus verwalten. Sie haben den IONOS CLOUD Terraform-Provider konfiguriert und versioniert festgelegt, sich mit IONOS_TOKEN authentifiziert und die Basis-VDC von TaskBoard aus ionoscloud_datacenter, ionoscloud_lan, ionoscloud_server, ionoscloud_volume und ionoscloud_nic-Ressourcen aufgebaut. Sie haben den Zustand in ein S3-kompatibles Object Storage-Backend verschoben, Datenquellen verwendet, um Images und Standorte dynamisch aufzulösen, vorhandene Ressourcen importiert und das Muster für ephemere Umgebungen übernommen, damit Testinfrastruktur sauber abgebaut wird.

Das asynchrone Bereitstellungsmodell, das Sie in Einheit 1.1 manuell behandelt haben, ist nun eine interne Angelegenheit des Providers: Terraform fragt den Status von Anfragen für Sie ab und ordnet Operationen über seinen Abhängigkeitsgraphen. Ab hier baut jede Infrastruktureinheit in diesem Kurs auf dieser gleichen Terraform-Grundlage auf.

Wichtige Punkte:

• Der IONOS CLOUD-Provider unterstützt die API-Angebote V5 und V6; legen Sie die Version immer mit required_providers fest und übernehmen Sie die Lock-Datei
• Authentifizieren Sie sich mit IONOS_TOKEN, damit kein Geheimnis in Ihr HCL gelangt; alle Ressourcen sind mit ionoscloud_ präfixiert
• Terraform fragt den asynchronen /requests/{id}/status-Endpunkt intern ab und ordnet Operationen über den Ressourcen-Abhängigkeitsgraphen
• Das Object Storage S3-Backend benötigt die skip_*-Flags und einen expliziten IONOS CLOUD-Endpunkt und authentifiziert sich mit Access Key plus Secret Key, nicht mit einem Bearer-Token
• Führen Sie immer plan vor apply aus und destroy ephemere Umgebungen, um Kosten zu steuern

Wichtige Begriffe:

• Provider: Das Plugin, das HCL-Ressourcen in IONOS CLOUD API-Aufrufe übersetzt, veröffentlicht als ionos-cloud/ionoscloud
• Zustand: Die Aufzeichnung von Terraform darüber, welche realen IONOS CLOUD-Ressourcen es verwaltet, lokal gespeichert oder in einem Object Storage-Backend
• Datenquelle: Eine schreibgeschützte Abfrage gegen die IONOS CLOUD API zur Planungszeit, wie ionoscloud_image, verwendet, um das Hardcodieren von IDs zu vermeiden
• Import: Ein bestehendes IONOS CLOUD-Ressource unter Terraform-Verwaltung zu stellen, indem eine zusammengesetzte datacenter_id/resource_id verwendet wird
• Ephemere Umgebung: Ein vollständiger Stack, der für einen Testlauf erstellt und mit terraform destroy abgebaut wird, um anhaltende Kosten zu vermeiden

Nächste Schritte

Weiter lernen: Einheit 1.3: Wissensprüfung - Programmatische Grundlagen

Verwandte Themen:

• Einheit 1.1: IONOS CLOUD API, Authentifizierung und asynchrones Modell
• Einheit 2.1: Compute und Server-Automatisierung