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,python3undionosctllokal installiert- Das
ionoscloudPython 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
-
Provisionierung als synchron behandeln
- Problem: Ihr Skript erstellt einen Server und hängt sofort ein Volume an, wodurch ein intermittierender
404oder ein Konfliktfehler auftritt. - Ursache: Die
POSThat202 Acceptedzurückgegeben, wobei die Ressource im ZustandBUSYist; die Ressource ist noch nicht bereit. - Lösung: Abfragen Sie die Status-URL aus dem
Location-Header, bisDONE, oder nutzen Sie die Warte-bis-vollendet-Option des SDK, bevor Sie einen abhängigen Aufruf ausführen.
- Problem: Ihr Skript erstellt einen Server und hängt sofort ein Volume an, wodurch ein intermittierender
-
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.
-
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-
limitvon1000; Code, deroffset/limitignoriert, sieht nur eine Seite. - Lösung: Iterieren Sie mit steigendem
offset, bis eine Seite weniger alslimitEinträ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 unterhttps://api.ionos.com/auth/v1/tokens/generategeneriert. - Die Bereitstellung ist asynchron:
POSTgibt202 Acceptedzurück, die Ressource wechselt in den ZustandBUSY, und Sie fragen die Status-URLLocationab, bisDONEerreicht 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
404direkt nach der Erstellung bedeutet in der Regel „noch nicht bereit", nicht „fehlt"; behandeln Sie429mit exponentiellem Backoff und paginieren Sie Sammlungen mitoffset/limit(Standardgrenzwert1000).
Wichtige Begriffe:
- Bearer-Token: Eine Zeichenkettenanmeldung, die vom Token Manager ausgestellt wird, im Header
Authorization: Bearergesendet wird und die primäre Authentifizierungsmethode für die IONOS CLOUD API ist. - Asynchrones Bereitstellungsmodell: Das Plattformverhalten, bei dem Erstellungs- und Aktualisierungsaufrufe
202und eine Status-URLLocationzurückgeben; die Ressource istBUSY, bis die BereitstellungDONEerreicht. - Endpunkt für den Status der Anfrage:
/cloudapi/v6/requests/{id}/status, abgefragt, um festzustellen, ob eine asynchrone OperationBUSY,DONEoderFAILEDist. - 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
limitdie Anzahl der Einträge pro Seite begrenzt (Standard1000) undoffsetden Startindex festlegt.
Nächste Schritte
Weiter lernen: Einheit 1.2: Terraform Provider and Core Patterns
Verwandte Themen: