17 Min. Lesezeit

Lernziele

Am Ende dieses Moduls werden Sie in der Lage sein:

  • Sich gegenüber der IONOS CLOUD API mit Bearer-Tokens aus dem Token Manager und Basic Auth authentifizieren und den Token-Lebenszyklus (Erstellung, Scope-Einstellung, Rotation) programmatisch verwalten
  • Das asynchrone Bereitstellungsmodell korrekt umsetzen, indem Sie den Request-Status-Endpunkt abfragen, bis `DONE`, bevor Sie abhängige Operationen ausführen
  • Dieselbe Ressource auf drei Arten bereitstellen (rohes `curl`, das Python-`ionoscloud`-SDK und `ionosctl`) und die richtige Schnittstelle für eine gegebene Aufgabe auswählen
  • Rate Limiting (`429`) mit exponentiellem Backoff behandeln und große Sammlungen mit Offset/Limit-Paginierung durchlaufen
  • Häufige API-Fehler beheben, einschließlich der `404`-während-Bereitstellung-Falle, die Entwickler Stunden kostet

Einheit 1.1: IONOS CLOUD API, Authentifizierung und asynchrones Modell

Einführung

Sie sind dabei, TaskBoard zu erstellen, eine Aufgabenverwaltungs-API mit einem Web-Frontend, und jedes einzelne Element davon über Code auf IONOS CLOUD bereitzustellen. Kein Klicken im Data Center Designer. Bevor Sie einen einzigen Server bereitstellen können, müssen Sie drei Dinge korrekt verdrahten: wie Sie sich authentifizieren, wie die API Ihnen mitteilt, dass eine Ressource tatsächlich bereit ist, und welchen Client (rohes HTTP, SDK oder CLI) Sie in jeder Situation verwenden.

Diese Einheit ist der Vertrag, den Sie mit der IONOS CLOUD API schließen. Die wichtigste Tatsache, die Sie verinnerlichen müssen, ist, dass die Bereitstellung asynchron abläuft: Ein POST wird sofort mit einer Anfrage-ID zurückgegeben, nicht mit einer fertigen Ressource. Behandeln Sie die Antwort als „angenommen, wird bearbeitet“ und nicht als „fertig“, und Sie vermeiden die häufigste Art von Automatisierungsfehler auf dieser Plattform. Sie richten die Authentifizierung ein, lernen die Abfrage-Schleife, die jede abhängige Operation steuert, und stellen einen Server über alle drei Schnittstellen bereit, damit Sie sie direkt vergleichen können.

1. Die IONOS CLOUD REST API

Jede TaskBoard-Ressource, die Sie erstellen, vom Datacenter über den Server bis hin zum Load Balancer, wird über die IONOS CLOUD REST API abgewickelt. Die Cloud API ist versioniert und befindet sich unter einer einzigen Basis-URL. Alle Kernaufrufe der CloudAPI richten sich an https://api.ionos.com/cloudapi/v6, und Anfragen sowie Antworten sind JSON (Content-Type: application/json).

Ressourcen werden hierarchisch adressiert. Ein Server befindet sich beispielsweise unter seinem Datacenter: /datacenters/{datacenterId}/servers/{serverId}. Diese Verschachtelung ist wichtig, da Sie fast immer einen Elternelement vor dem Kind erstellen und das Elternelement zuerst vollständig bereitgestellt werden muss (siehe Abschnitt 3).

1.1 Basis-URL, Versionierung und Inhaltstypen

Die CloudAPI-Oberfläche ist im Pfad an v6 festgelegt. Verwenden Sie diese Version in Ihrem Code explizit, anstatt sich auf einen nicht versionierten Alias zu verlassen, damit eine Versionsänderung auf der Übertragungsseite das Verhalten Ihrer Automatisierung nie stillschweigend ändert.

# Smoke-test connectivity and auth: list your datacenters
curl -s -X GET 'https://api.ionos.com/cloudapi/v6/datacenters?depth=1' \
  -H 'Authorization: Bearer '"$IONOS_TOKEN" \
  -H 'Content-Type: application/json'

Der Abfrageparameter depth steuert, wie viel des verschachtelten Ressourcenbaums zurückgegeben wird. depth=1 gibt die Sammlung mit den Eigenschaften der obersten Ebene zurück; höhere Ebenen fügen Kinderressourcen inline ein. Halten Sie depth bei Listenaufrufen niedrig, um die Größe der Nutzlast zu reduzieren, und fordern Sie eine bestimmte Ressource per ID an, wenn Sie vollständige Details benötigen.

1.2 Hinweis zu separaten API-Hosts

Nicht jeder IONOS CLOUD-Dienst ist unter cloudapi/v6 angesiedelt. Einige Dienste stellen eigene Hosts bereit (zum Beispiel verwendet IAM Federation https://iam.ionos.com, und das CDN verwendet einen regionalen Host). Wenn Sie diese Dienste in späteren Modulen integrieren, lesen Sie den Endpunkt aus der Dokumentation des jeweiligen Dienstes, anstatt die Basis der Kern-CloudAPI vorauszusetzen. Der Authentifizierungsheader bleibt jedoch auf diesen Hosts derselbe Bearer-Token.

2. Authentifizierung

Die IONOS CLOUD API akzeptiert zwei Authentifizierungsmethoden: einen Bearer Token (die primäre, empfohlene Methode) und Basic Auth mit Ihrem Konto-Benutzernamen und -Passwort.

Zwei operative Fakten steuern die Wahl. Erstens müssen Konten, bei denen 2FA aktiviert oder erzwungen ist, die Bearer-Token-Authentifizierung verwenden. Zweitens ist die Basic-Authentifizierung als in naher Zukunft eingestuft dokumentiert und sollte nur in Kombination mit 2FA verwendet werden. Die praktische Empfehlung für jede neue Automatisierung: Bearer Tokens verwenden.

2.1 Bearer Tokens über den Token Manager

Sie erzeugen Tokens über den API/SDK Authentication Token Manager (im DCD unter Menü > Verwaltung > Token Manager, über die API oder über die CLI). Ein Token ist eine Zeichenfolge, die Sie in den Authorization-Header jedes Anfrages setzen.

# Bearer token on every CloudAPI request
curl -s -X GET 'https://api.ionos.com/cloudapi/v6/datacenters' \
  -H 'Authorization: Bearer '"$IONOS_TOKEN"

Sie können ein Token programmgesteuert über den Token-Generierungs-Endpunkt anfordern und diesen Tokenwert für nachfolgende API- und SDK-Aufrufe wiederverwenden:

# Generate a token using Basic auth, then switch to the token for all later calls
TOKEN=$(curl -s -u "$IONOS_USERNAME:$IONOS_PASSWORD" \
  -X GET 'https://api.ionos.com/auth/v1/tokens/generate' \
  | python3 -c 'import sys,json; print(json.load(sys.stdin)["token"])')

export IONOS_TOKEN="$TOKEN"

Beachten Sie, dass der Host für die Token-Erstellung auth/v1 ist, nicht cloudapi/v6. Das zurückgegebene Token wird anschließend gegenüber der CloudAPI verwendet.

2.2 Token-Lebenszyklus: Erstellung, Scoping und Rotation

Der Token Manager legt konkrete Grenzen fest, die bei der Planung berücksichtigt werden müssen. Pro Benutzer können bis zu 100 Authentifizierungs-Token erstellt werden, und die TTL jedes Tokens wird bei der Erstellung aus einem festen Satz von Optionen ausgewählt: 1 Stunde, 4 Stunden, 1 Tag, 7 Tage, 30 Tage, 60 Tage, 90 Tage, 180 Tage und 365 Tage.

Der Token-Wert wird bei der Erstellung genau einmal angezeigt und ist danach nicht wiederherstellbar; zu diesem Zeitpunkt kann er auch als Datei heruntergeladen werden. Erfassen Sie ihn sofort in Ihrem Secret Store, da es später keine Funktion „erneut anzeigen“ gibt.

Diese Grenzen formen ein Muster mit geringsten Berechtigungen, das sich gut für Rotation eignet. Erstellen Sie für jeden Dienst und jede Umgebung ein separates Token mit kurzer TTL (ein Token für die TaskBoard-CI-Pipeline, ein Token für den laufenden API-Dienst und so weiter), anstatt ein langlebiges Token überall zu verwenden. Da Tokens nach einer festen TTL ablaufen, ist die Rotation eine Routine, die automatisiert wird, und kein Notfall.

# Read the token from the environment, never hardcode it
import os

IONOS_TOKEN = os.environ["IONOS_TOKEN"]  # fails loudly if unset
# Hardcoding a 365-day token in source is the fastest way to leak credentials.

Die Obergrenze von 100 Tokens bedeutet, dass ein außer Kontrolle geratenes Skript, das bei jedem Durchlauf ein neues Token erzeugt, Ihr Kontingent erschöpft. Erzeugen Sie ein Token nur einmal, speichern Sie es, verwenden Sie es bis zum Ablaufdatum und rotieren Sie es anschließend.

3. Das asynchrone Provisionierungsmodell

Diese Regel verursacht mehr Probleme bei der Automatisierung in IONOS CLOUD als jede andere: Provisionierungsvorgänge sind asynchron. Ein POST oder ein PUT gibt keine fertige Ressource zurück. Stattdessen wird 202 Accepted zurückgegeben, die neue Ressource befindet sich in einem BUSY-Zustand, und ein Location-Header verweist auf eine Status-URL, die Sie abfragen, bis die Provisionierung abgeschlossen ist.

Sie müssen auf den Abschluss warten, bevor Sie einen Vorgang ausführen, der von der neuen Ressource abhängt. Das Anhängen eines Volumes an einen Server, der sich noch im Zustand BUSY befindet, oder das Erstellen einer NIC in einem nur teilweise provisionierten Datacenter schlägt fehl. Das asynchrone Modell ist nicht optional, und es lässt sich nicht allein durch Wiederholungen des abhängigen Aufrufs umgehen.

3.1 Die Antwort 202 und der Location-Header

Wenn Sie eine Ressource erstellen, ist der Antwortstatus 202 Accepted, der Antwortkörper enthält die neue Ressource id, und der Antwortheader enthält eine Status-URL zum Abfragen.

# Create a datacenter; capture the request status URL from the Location header
curl -s -D - -o /tmp/dc.json \
  -X POST 'https://api.ionos.com/cloudapi/v6/datacenters' \
  -H 'Authorization: Bearer '"$IONOS_TOKEN" \
  -H 'Content-Type: application/json' \
  -d '{"properties":{"name":"taskboard-dc","location":"de/fra"}}' \
  | grep -i '^location:'

Der Header Location enthält die Status-URL der Anfrage. Das Muster ist über alle Ressourcentypen hinweg identisch: Die Dokumentation der zentralen Cloud-API-Endpunkte gibt an, dass die Antwort einen Header Location mit einer URL zum Abfragen des Anfragestatus enthält, und die Ressource behält den Status BUSY bei, bis die Bereitstellung abgeschlossen ist.

3.2 Abfragen bis DONE

Der Status-Endpunkt meldet den Zustand der Anfrage. Sie fragen diesen ab, bis der Zustand DONE ist (ein fehlgeschlagene Bereitstellung wird als FAILED angezeigt). Erst dann können Sie zu abhängigen Operationen übergehen.

Die genaue Struktur der Anfragestatus-Payload und die empfohlene Abfragetaktik unten spiegeln gängige IONOS CLOUD-Automatisierungspraktiken wider, statt einen wörtlichen Dokumentationsauszug darzustellen. Die Zustandswerte BUSY, DONE und FAILED sind in der Dokumentation verankert; die Schleifenstruktur ist eine Standardimplementierung.

# Poll the status URL until the request reports DONE
STATUS_URL="https://api.ionos.com/cloudapi/v6/requests/<request-id>/status"

until [ "$(curl -s -H "Authorization: Bearer $IONOS_TOKEN" "$STATUS_URL" \
  | python3 -c 'import sys,json; print(json.load(sys.stdin)["metadata"]["status"])')" = "DONE" ]; do
  echo "still provisioning..."
  sleep 5
done
echo "resource ready"

Die SDKs kapseln diese Schleife für Sie. Übergeben Sie die SDK-Option, die auf den Abschluss wartet, und der Client führt intern Abfragen durch, sodass Ihr Anwendungscode so wirkt, als wäre der Aufruf synchron, während das zugrunde liegende asynchrone Modell dennoch eingehalten wird.

4. SDKs und die ionosctl CLI

Sie werden keine rohe curl für die Anwendungslogik schreiben. IONOS CLOUD stellt SDKs für Python (ionoscloud), Go (sdk-go), Java und JavaScript sowie das ionosctl-Befehlszeilenwerkzeug bereit. Alle authentifizieren sich mit demselben Bearer-Token und alle müssen das asynchrone Modell einhalten.

4.1 Das Python-SDK

Das Python-SDK verwendet ein Configuration-Objekt (das Ihr Token enthält), das in einem ApiClient-Objekt gekapselt ist, welches Sie dann den dienstspezifischen API-Klassen übergeben.

Die unten aufgeführten SDK-Klassen- und Methodennamen (Configuration, ApiClient, DataCentersApi, ServersApi und die datacenters_servers_post-Methode) spiegeln die veröffentlichte Schnittstelle des ionoscloud Python-SDKs auf Basis allgemeiner Kenntnisse wider; prüfen Sie die genauen Signaturen anhand der von Ihnen festgelegten SDK-Version.

import os
import ionoscloud
from ionoscloud.api import data_centers_api, servers_api
from ionoscloud.models import Server, ServerProperties

config = ionoscloud.Configuration(token=os.environ["IONOS_TOKEN"])

with ionoscloud.ApiClient(config) as api_client:
    servers = servers_api.ServersApi(api_client)
    server = Server(properties=ServerProperties(
        name="taskboard-api",
        cores=4,
        ram=8192,            # MB; 8 GB
        cpu_family="INTEL_SKYLAKE",
    ))
    # The SDK can wait for the async request to finish for you
    created = servers.datacenters_servers_post(
        datacenter_id=os.environ["TASKBOARD_DC_ID"],
        server=server,
    )
    print("server id:", created.id)

Das SDK liest Ihr Token aus dem Configuration-Objekt. Binden Sie die Lebensdauer dieses Objekts an die TTL des Tokens und aktualisieren Sie es, wenn Sie das Token rotieren.

4.2 Die ionosctl-CLI

ionosctl ist die schnellste Schnittstelle für Einmalaufgaben, Skripte und Inspektionen. Authentifizieren Sie sich einmal und führen Sie anschließend Befehle aus.

Die unten aufgeführte Befehlssyntax für ionosctl spiegelt die veröffentlichte Befehlsstruktur des Tools auf der Grundlage allgemeiner Kenntnisse wider; prüfen Sie die Schalter anhand Ihrer installierten CLI-Version mit ionosctl <command> --help.

# Authenticate the CLI with a token
ionosctl login --token "$IONOS_TOKEN"

# List datacenters
ionosctl datacenter list

# Create a server (ionosctl waits for the request by default)
ionosctl server create \
  --datacenter-id "$TASKBOARD_DC_ID" \
  --name taskboard-api --cores 4 --ram 8192

4.3 Auswahl einer Schnittstelle

Die folgende Tabelle vergleicht die vier Möglichkeiten, mit der IONOS CLOUD API zu interagieren, damit Sie bewusst und nicht aus Gewohnheit wählen können.

Schnittstelle Am besten geeignet für Asynchrone Verarbeitung Wann Sie sie verwenden sollten
curl / rohes HTTP Debugging, Erlernen des Wire-Formats Sie pollen manuell Reproduzieren eines Problems, Scripting in einer Sprache ohne SDK
SDK (Python/Go/Java/JS) Anwendungscode Eingebaute Warteoption Alles innerhalb der TaskBoard-Dienste
ionosctl Einmalige Aufgaben, Shell-Skripte Wartet standardmäßig Schnelle Inspektion, Klebe-Skripte, CI-Schritte
Terraform Deklarative Infrastruktur Provider pollt intern Dauerhafte Infrastruktur (in Einheit 1.2 behandelt)

Wie oben gezeigt, verwenden Sie das SDK für Anwendungslogik, ionosctl für schnelle Aufgaben und CI-Klebstoff, rohes HTTP, wenn Sie das Protokoll selbst debuggen, und Terraform (nächste Einheit) für alles, was als deklarativer Zustand vorliegen sollte.

5. Rate Limiting, Paginierung und Fehlerbehandlung

Produktionsautomatisierung stößt auf drei Realitäten, die die Beispiele für den Normalfall überspringen: Die API begrenzt Ihre Anfragefrequenz, Sammlungen werden paginiert, und einige Fehlercodes bedeuten etwas anderes als erwartet.

5.1 Rate Limiting mit exponentiellem Backoff

Wenn Sie die Anfragefrequenz überschreiten, antwortet die API mit 429. Die korrekte Reaktion besteht darin, exponentiell zurückzufahren und erneut zu versuchen, nicht das Endpunkt zu überlasten.

Die untenstehende Implementierung des exponentiellen Backoffs ist ein Standardmuster für clientseitige Wiederholungsversuche; die Semantik des Statuscodes 429 basiert auf der Dokumentation, während die konkreten Verzögerungen und Jitter eine Implementierungsentscheidung darstellen.

import time, random, requests

def get_with_backoff(url, headers, max_retries=6):
    for attempt in range(max_retries):
        resp = requests.get(url, headers=headers)
        if resp.status_code != 429:
            resp.raise_for_status()
            return resp
        # Honor Retry-After if present, else exponential backoff with jitter
        wait = int(resp.headers.get("Retry-After", 2 ** attempt))
        time.sleep(wait + random.uniform(0, 1))
    raise RuntimeError("rate limit: retries exhausted")

5.2 Paginierung mit offset und limit

List-Endpunkte geben paginierte Sammlungen zurück, die durch offset und limit gesteuert werden. Der Parameter limit begrenzt die Anzahl der Elemente pro Seite, und offset setzt den Startpunkt innerhalb der Sammlung. Bei Sammel-Endpunkten ist der Standardwert für limit 1000 und der Standardwert für offset ist 0.

# Iterate every page of a collection
def list_all(url, headers, page_size=1000):
    offset, items = 0, []
    while True:
        page = get_with_backoff(
            f"{url}?offset={offset}&limit={page_size}", headers
        ).json()
        batch = page.get("items", [])
        items.extend(batch)
        if len(batch) < page_size:
            break
        offset += page_size
    return items

Gehen Sie niemals davon aus, dass ein einzelner Aufruf alles zurückgeliefert hat. Wenn Sie genau limit Einträge erhalten haben, liegt mit hoher Wahrscheinlichkeit eine weitere Seite vor.

5.3 Fehlerbehandlung und die 404-Falle

Der Fehler, den Sie zuerst falsch deuten werden, ist 404 während der Bereitstellung. Ein 404 unmittelbar nach der Erstellung einer Ressource bedeutet in der Regel, dass die Ressource noch nicht bereit ist, und nicht, dass sie fehlt. Dies ist der asynchrone Modellansatz, der Sie trifft: Sie haben das Abfragen übersprungen und eine Kindressource abgefragt, bevor ihre Elternressource den Status DONE erreicht hatte.

# WRONG: create then immediately use -> intermittent 404
created = servers.datacenters_servers_post(datacenter_id=dc_id, server=server)
volumes.datacenters_volumes_post(datacenter_id=dc_id, volume=vol)  # may 404

# RIGHT: wait for DONE, then proceed (SDK wait option, or poll the status URL)

Lesen Sie Antwortkörper bei Fehlern. Die Fehlerantworten von IONOS CLOUD enthalten eine strukturierte Nutzlast mit dem HTTP-Code und einer menschenlesbaren Meldung; protokollieren Sie diese, anstatt die Ausnahme zu unterdrücken, damit ein 429, ein fehlerhafter Körper (422) und ein Authentifizierungsfehler (401) in der Ausgabe Ihrer Pipeline sofort unterscheidbar sind.

API-Referenz Schnellkarte

Wichtige API-Endpunkte für die Authentifizierung und das asynchrone Modell:

Methode Endpunkt Beschreibung
GET /auth/v1/tokens/generate Bearer-Token generieren
GET /cloudapi/v6/datacenters Datenzentren auflisten (Authentifizierungstest)
POST /cloudapi/v6/datacenters/{dcId}/servers Server erstellen (gibt 202 zurück)
GET /cloudapi/v6/requests/{requestId}/status Status der asynchronen Anfrage abfragen, bis DONE
GET /cloudapi/v6/datacenters/{dcId}/servers/{serverId} Serverdetails abrufen

Basis-URL: https://api.ionos.com/cloudapi/v6 Token-Host: https://api.ionos.com/auth/v1 Authentifizierung: Authorization: Bearer <token>

Code Lab

Ziel: Einen Server auf drei Wegen bereitstellen (curl, Python SDK, ionosctl) und bei jedem Durchgang die asynchrone Fertigstellung überprüfen.

Voraussetzungen:

  • IONOS CLOUD Konto mit API-Zugriff
  • curl, python3 und ionosctl lokal installiert
  • Das ionoscloud Python SDK: pip install ionoscloud

Schritt 1: Token generieren und exportieren

export IONOS_TOKEN=$(curl -s -u "$IONOS_USERNAME:$IONOS_PASSWORD" \
  -X GET 'https://api.ionos.com/auth/v1/tokens/generate' \
  | python3 -c 'import sys,json; print(json.load(sys.stdin)["token"])')

Erwartete Ausgabe:

(no output; verify with: echo ${IONOS_TOKEN:0:8}...)

Schritt 2: Erstellen eines Datacenters und Erfassen der Request-Status-URL

curl -s -D /tmp/hdr -o /tmp/dc.json \
  -X POST 'https://api.ionos.com/cloudapi/v6/datacenters' \
  -H "Authorization: Bearer $IONOS_TOKEN" -H 'Content-Type: application/json' \
  -d '{"properties":{"name":"taskboard-dc","location":"de/fra"}}'
grep -i '^location:' /tmp/hdr
export DC_ID=$(python3 -c 'import json;print(json.load(open("/tmp/dc.json"))["id"])')

Erwartete Ausgabe:

location: https://api.ionos.com/cloudapi/v6/requests/<id>/status

Schritt 3: Abfragen, bis das Datacenter DONE ist

STATUS=$(grep -i '^location:' /tmp/hdr | awk '{print $2}' | tr -d '\r')
until [ "$(curl -s -H "Authorization: Bearer $IONOS_TOKEN" "$STATUS" \
  | python3 -c 'import sys,json;print(json.load(sys.stdin)["metadata"]["status"])')" = "DONE" ]; do sleep 5; done
echo done

Erwartete Ausgabe:

done

Schritt 4: Erstellen eines Servers mit curl

curl -s -X POST "https://api.ionos.com/cloudapi/v6/datacenters/$DC_ID/servers" \
  -H "Authorization: Bearer $IONOS_TOKEN" -H 'Content-Type: application/json' \
  -d '{"properties":{"name":"srv-curl","cores":2,"ram":4096,"cpuFamily":"INTEL_SKYLAKE"}}'

Erwartete Ausgabe:

{"id":"<server-id>","type":"server", ... }

Schritt 5: Erstellen eines Servers über das Python SDK

import os, ionoscloud
from ionoscloud.api import servers_api
from ionoscloud.models import Server, ServerProperties
cfg = ionoscloud.Configuration(token=os.environ["IONOS_TOKEN"])
with ionoscloud.ApiClient(cfg) as c:
    s = servers_api.ServersApi(c).datacenters_servers_post(
        datacenter_id=os.environ["DC_ID"],
        server=Server(properties=ServerProperties(
            name="srv-sdk", cores=2, ram=4096, cpu_family="INTEL_SKYLAKE")))
    print("sdk server:", s.id)

Erwartete Ausgabe:

sdk server: <server-id>

Schritt 6: Erstellen eines Servers mit ionosctl

ionosctl login --token "$IONOS_TOKEN"
ionosctl server create --datacenter-id "$DC_ID" --name srv-cli --cores 2 --ram 4096

Erwartete Ausgabe:

ServerId   Name      Cores   Ram     State
<id>       srv-cli   2       4096    BUSY -> AVAILABLE

Schritt 7: Alle Server auflisten und bestätigen, dass drei vorhanden sind

ionosctl server list --datacenter-id "$DC_ID"

Erwartete Ausgabe:

srv-curl, srv-sdk, srv-cli all AVAILABLE

Prüfliste:

  • [ ] Token generiert und exportiert, niemals hartkodiert
  • [ ] Rechenzentrum erreicht DONE, bevor ein Server erstellt wurde
  • [ ] Drei Server über drei verschiedene Schnittstellen erstellt
  • [ ] Alle drei Server erreichen den Zustand AVAILABLE

Aufräumarbeiten:

# Deleting the datacenter removes its child servers; avoids ongoing charges
ionosctl datacenter delete --datacenter-id "$DC_ID" --force

Häufige Fehler

  1. Provisionierung als synchron behandeln

    • Problem: Ihr Skript erstellt einen Server und hängt sofort ein Volume an, wodurch ein intermittierender 404 oder ein Konfliktfehler auftritt.
    • Ursache: Die POST hat 202 Accepted zurückgegeben, wobei die Ressource im Zustand BUSY ist; die Ressource ist noch nicht bereit.
    • Lösung: Abfragen Sie die Status-URL aus dem Location-Header, bis DONE, oder nutzen Sie die Warte-bis-vollendet-Option des SDK, bevor Sie einen abhängigen Aufruf ausführen.
  2. Bei jedem Lauf ein neues Token generieren

    • Problem: Ein geplanter Job funktioniert nach einer Weile nicht mehr und meldet Authentifizierungsfehler; Sie finden Dutzende von Tokens im Token Manager.
    • Ursache: Jeder Benutzer ist auf 100 Tokens begrenzt; ein Skript, das bei jedem Lauf ein Token generiert, erschöpft die Quote und verliert den Überblick darüber, welches Token aktiv ist.
    • Lösung: Generieren Sie ein Token mit begrenztem Geltungsbereich pro Service/Umgebung, speichern Sie es in einem Secret Store, wiederverwenden Sie es, bis seine TTL abläuft, und rotieren Sie es anschließend. Der Tokenwert wird nur einmal angezeigt, daher muss er bei der Erstellung erfasst werden.
  3. Nur die erste Seite einer Sammlung lesen

    • Problem: Eine List-Operation übersieht stillschweigend Ressourcen jenseits der ersten 1000 Einträge.
    • Ursache: Sammel-Endpunkte paginieren mit einem Standard-limit von 1000; Code, der offset/limit ignoriert, sieht nur eine Seite.
    • Lösung: Iterieren Sie mit steigendem offset, bis eine Seite weniger als limit Einträge zurückgibt (siehe Abschnitt 5.2).

Zusammenfassung

Sie besitzen nun den Vertrag, von dem jede spätere Einheit abhängt. Sie können sich mit einem Bearer-Token aus dem Token Manager authentifizieren, das asynchrone Bereitstellungsmodell einhalten, indem Sie requests/{id}/status abfragen, bis DONE erreicht ist, und dieselbe Ressource über curl, das Python SDK und ionosctl bereitstellen. Sie können auch die Automatisierung unter Last am Leben erhalten, indem Sie bei 429 einen Rückzug (Backoff) vornehmen und große Sammlungen paginieren. Mit diesem Fundament wird die Infrastrukturarbeit von TaskBoard in Einheit 1.2 zu einer Frage der deklarativen Darstellung dieser gleichen Operationen in Terraform.

Wichtige Punkte:

  • Die Basis-URL der CloudAPI ist https://api.ionos.com/cloudapi/v6; Tokens werden unter https://api.ionos.com/auth/v1/tokens/generate generiert.
  • Die Bereitstellung ist asynchron: POST gibt 202 Accepted zurück, die Ressource wechselt in den Zustand BUSY, und Sie fragen die Status-URL Location ab, bis DONE erreicht ist, bevor Sie abhängige Operationen ausführen.
  • Verwenden Sie Bearer-Tokens (Basic Auth wird eingestellt, und 2FA-Konten müssen Bearer verwenden); ein Benutzer kann bis zu 100 Tokens halten, jeweils mit einer festen TTL von 1 Stunde bis 365 Tage.
  • Ein Tokenwert wird genau einmal angezeigt und ist nicht wiederherstellbar, daher sollten Sie ihn bei der Erstellung erfassen; zu diesem Zeitpunkt können Sie ihn als Datei herunterladen.
  • Ein 404 direkt nach der Erstellung bedeutet in der Regel „noch nicht bereit", nicht „fehlt"; behandeln Sie 429 mit exponentiellem Backoff und paginieren Sie Sammlungen mit offset/limit (Standardgrenzwert 1000).

Wichtige Begriffe:

  • Bearer-Token: Eine Zeichenkettenanmeldung, die vom Token Manager ausgestellt wird, im Header Authorization: Bearer gesendet wird und die primäre Authentifizierungsmethode für die IONOS CLOUD API ist.
  • Asynchrones Bereitstellungsmodell: Das Plattformverhalten, bei dem Erstellungs- und Aktualisierungsaufrufe 202 und eine Status-URL Location zurückgeben; die Ressource ist BUSY, bis die Bereitstellung DONE erreicht.
  • Endpunkt für den Status der Anfrage: /cloudapi/v6/requests/{id}/status, abgefragt, um festzustellen, ob eine asynchrone Operation BUSY, DONE oder FAILED ist.
  • Token-TTL: Die feste Lebensdauer, die bei der Token-Erstellung gewählt wird (1 Stunde bis 365 Tage), die Ihren Rotationsplan steuert.
  • Paginierung (offset/limit): Parameter von Sammelendpunkten, bei denen limit die Anzahl der Einträge pro Seite begrenzt (Standard 1000) und offset den Startindex festlegt.

Nächste Schritte

Weiter lernen: Einheit 1.2: Terraform Provider and Core Patterns

Verwandte Themen: