Wissensprüfung - Programmatische Grundlagen
Ein Skript einer Entwicklerin oder eines Entwicklers erstellt einen Server mit POST bis /cloudapi/v6/datacenters/{dcId}/servers und gibt anschließend sofort einen zweiten Aufruf aus, um ein Volume an diesen Server anzuhängen. Der Aufruf für das Volume schlägt intermittierend mit einem 404 fehl. Was ist die korrekte Lösung?
Die Provisionierung in IONOS CLOUD ist asynchron: Eine POST gibt 202 Accepted zurück, wobei die Ressource im Zustand BUSY ist, und eine 404 unmittelbar nach der Erstellung bedeutet „noch nicht bereit", nicht „fehlt". Sie müssen die Status-URL der Anfrage aus dem Location-Header abfragen, bis DONE, bevor ein abhängiger Aufruf erfolgt. Engmaschige Wiederholungen verschwenden das Kontingent der Ratenbegrenzung, ohne die Ursache zu beheben, und depth steuert nur die Größe des Antwort-Payloads.
Ein geplanter Job, der bei jedem Lauf ein neues Bearer-Token erzeugt, beginnt nach einigen Wochen mit Authentifizierungsfehlern, und der Token Manager zeigt Dutzende von Tokens. Was ist das zugrunde liegende Limit und das korrekte Muster?
Ein Benutzer kann bis zu 100 Authentifizierungstokens erzeugen, sodass ein Skript, das bei jedem Lauf ein neues Token ausgibt, das Kontingent schließlich erschöpft. Das korrekte Muster besteht darin, ein Token mit begrenztem Geltungsbereich und kurzer TTL pro Dienst oder Umgebung auszustellen, es bei der Erstellung aufzuzeichnen (der Wert wird nur einmal angezeigt) und es bis zum Ablauf wiederzuverwenden, danach zu rotieren. Ein einzelnes geteiltes langlebiges Token verstößt gegen das Prinzip der geringsten Berechtigung, und die TTLs von Tokens werden aus einem festen Satz gewählt, der von 1 Stunde bis 365 Tage reicht, nicht ein fester Wert von 1 Stunde.
Eine Entwicklerin oder ein Entwickler ruft Ressourcen mit GET /cloudapi/v6/datacenters ab und verarbeitet die zurückgegebenen Einträge, stellt aber später fest, dass einige Ressourcen vom Skript nie erfasst wurden. Die Sammlung enthält mehr als 1000 Einträge. Was ist passiert und wie sollte dies behandelt werden?
List-Endpunkte geben paginierte Sammlungen mit einer Standardgröße von limit von 1000 und einem Standardwert von offset von 0 zurück, sodass ein einzelner Aufruf nur die erste Seite einseht. Die Lösung besteht darin zu iterieren und offset um die Seitengröße zu erhöhen, bis eine Seite weniger als limit Einträge zurückgibt. Der Parameter depth steuert, wie viel des verschachtelten Ressourcenbaums pro Eintrag inline dargestellt wird, nicht wie viele Einträge zurückgegeben werden, und 429 ist die Antwort bei einer Ratenbegrenzung, die nichts mit der Paginierung zu tun hat.
Eine Entwicklerin oder ein Entwickler fügt einen IONOS CLOUD Object Storage-Bucket als Terraform-Remote-State-Backend hinzu, doch terraform init schlägt mit Fehlern zum Security Token Service und einer fehlenden Account-ID fehl. Welche Änderung behebt den Backend-Block?
Das S3-Backend setzt AWS voraus und versucht AWS-spezifische Aufrufe (STS, Account-ID-Suche), die IONOS CLOUD Object Storage nicht implementiert. Daher sind die Flags skip_* sowie ein expliziter IONOS CLOUD-Endpunkt (zum Beispiel https://s3.eu-central-1.ionoscloud.com) erforderlich. IONOS CLOUD Object Storage ist S3-kompatibel und funktioniert einwandfrei als Backend, authentifiziert sich jedoch mit Access Key und Secret Key, nicht mit einem Bearer-Token. IONOS CLOUD stellt keine DynamoDB-Sperrentabelle bereit, daher ist das Hinzufügen einer solchen keine Option.
Eine Entwicklerin möchte einen Server, der zuvor mit einem curl-Skript erstellt wurde, unter die Verwaltung von Terraform stellen, ohne ihn neu zu erstellen. Welcher Ansatz ist korrekt?
Die Import-Funktion von IONOS CLOUD verwendet eine zusammengesetzte ID, die die Datacenter-ID und die Ressourcen-ID verbindet (dc_id/server_id). Der Workflow besteht darin, einen passenden ionoscloud_server-Block zu schreiben, den Import durchzuführen und anschließend das HCL anzupassen, bis terraform plan keine Änderungen mehr meldet. Terraform übernimmt vorhandene Ressourcen nicht automatisch bei apply, und terraform refresh aktualisiert nur den Status bereits verwalteter Ressourcen. Das Löschen und Neuanlegen widerspricht dem Ziel, den bestehenden Server zu erhalten.