Einheit 3.1: Container Registry und Image-Pipelines

Einführung

Sie sind dabei, den API-Dienst und das Web-Frontend von TaskBoard zu containerisieren, und benötigen ein Registry, um die Images hochzuladen, bevor Managed Kubernetes sie abrufen kann. IONOS CLOUD Container Registry stellt Ihnen ein oder mehrere dedizierte, authentifizierte Registries bereit, die die Docker Registry HTTP API V2 sprechen und jedes OCI-konforme Artefakt akzeptieren. Alles, was Sie damit tun, also Provisionierung, Token-Erstellung, Anmeldung, Hochladen und Aufräumen, wird über Terraform, die REST API und die Docker CLI gesteuert.

Diese Einheit beginnt auf Code-Ebene. Sie provisionieren ein Registry als Infrastructure as Code, erstellen ein Token mit eingeschränktem Geltungsbereich, authentifizieren Docker und bauen die Build-Tag-Push-Pipeline auf, von der der Rest von Modul 3 abhängt. Zwei IONOS CLOUD-spezifische Einschränkungen prägen jedes Beispiel in diesem Dokument: Die Authentifizierung erfolgt ausschließlich tokenbasiert, ohne rollenbasierte Zugriffskontrolle und ohne ACLs pro Repository, und der Hostname des Registry existiert erst, wenn das Registry den Zustand Running erreicht. Beide Punkte werden Sie in CI-Systemen treffen, wenn Sie sie ignorieren, daher sind sie in den untenstehenden Code-Mustern fest verankert.

1. Bereitstellung der Registry mit Terraform

Die Registry ist eine erste-Klasse-Terraform-Ressource. Sie deklarieren einen Namen und einen Standort, wenden die Konfiguration an und warten, bis die asynchrone Bereitstellung abgeschlossen ist, bevor der Hostname zugewiesen wird. Die Attribute name und location sind nach der Erstellung unveränderlich, daher ist die Auswahl dieser Werte eine einwegige Entscheidung pro Registry.

Der Registry-Name darf höchstens 63 Zeichen lang sein. Wenn Sie versuchen, eine Registry mit einem Namen zu erstellen, der bereits auf der gesamten Plattform vergeben ist, gibt die API HTTP 409 Conflict mit der Meldung already exists: name is not available zurück. Behandeln Sie den Namen als globalen Bezeichner und nicht als einen pro Konto, und setzen Sie Ihr Projekt als Präfix vor, um Kollisionen zu vermeiden.

1.1 Die ionoscloud_container_registry-Ressource

Der Standort muss ein unterstützter Container Registry-Standort sein. Container Registry ist in de/fra (DE/FRA) verfügbar, daher ist Ihr location-Wert de/fra.

terraform {
  required_providers {
    ionoscloud = {
      source  = "ionos-cloud/ionoscloud"
      version = ">= 6.0.0"
    }
  }
}

provider "ionoscloud" {
  # token read from IONOS_TOKEN env var
}

resource "ionoscloud_container_registry" "taskboard" {
  name     = "taskboard-prod"
  location = "de/fra"

  garbage_collection_schedule {
    days = ["Saturday", "Sunday"]
    time = "19:30:00+00:00"
  }
}

output "registry_hostname" {
  value = ionoscloud_container_registry.taskboard.hostname
}

Die Ausgabe von hostname folgt dem Muster {registry-name}.cr.{location-with-dash}.ionos.com. Sie ist leer, bis die Registry den Zustand Running erreicht. Daher muss jeder nachgelagerte Schritt, der darauf zugreift, erst nach vollständiger Beendigung von apply ausgeführt werden. Die Registry weist nur zwei Lebenszykluszustände auf, nämlich New und Running, wobei nur Running verwendbar ist.

1.2 Provisionierung über die REST API

Wenn Sie die Provisionierung außerhalb von Terraform durchführen, wird die Registry über eine POST an den Endpunkt für Registries erstellt. Die gleichen Eigenschaften garbageCollectionSchedule, location und name gelten auch hier.

curl --location \
  --request POST 'https://api.ionos.com/containerregistries/registries' \
  --header "Authorization: Bearer ${IONOS_TOKEN}" \
  --header 'Content-Type: application/json' \
  --data-raw '{
    "properties": {
      "garbageCollectionSchedule": {
        "days": ["Saturday", "Sunday"],
        "time": "19:30:00+00:00"
      },
      "location": "de/fra",
      "name": "taskboard-prod"
    }
  }'

Die Antwort mit dem Statuscode 202 enthält keinen Hostnamen, da der Host noch nicht zugewiesen wurde. Rufen Sie GET /containerregistries/registries/{registryId} wiederholt ab, bis der Status Running ist, bevor Sie den Hostnamen lesen. Aufrufe zur Auflistung sind tokenbasiert paginiert: Übergeben Sie limit als Abfrageparameter und folgen Sie nextPageToken, um große Sammlungen durchzublättern.

2. Tokens and Authentication

Die Authentifizierung erfolgt ausschließlich tokenbasiert docker login. Es gibt kein RBAC, keine teambasierten Repositories und keinen anonymen oder öffentlichen Repository-Zugriff. Ein Token ist die zugriffsbasierte Einheit, und Sie legen dessen Geltungsbereich pro Registry oder pro Repository-Pfad mit einem Satz erlaubter Aktionen fest.

2.1 Erstellen eines Tokens mit Terraform

Ein Token hat einen Namen, einen Status, ein optionales Ablaufdatum und einen oder mehrere Geltungsbereiche. Jeder Geltungsbereich hat einen Typ von Registry oder Repository, einen Pfad und eine Aktionsliste, die aus pull, push und delete besteht. Der Tokenname muss 3 bis 63 Zeichen lang sein, mit a-z beginnen, mit einem alphanumerischen Zeichen enden und nur alphanumerische Zeichen und Bindestriche enthalten. Er ist nach der Erstellung unveränderlich.

resource "ionoscloud_container_registry_token" "ci_push" {
  container_registry_id = ionoscloud_container_registry.taskboard.id
  name                  = "ci-push"
  status                = "enabled"

  # minimum expiry is 1 hour in the future; on expiry the token is DELETED
  expiry_date = "2027-01-01T00:00:00Z"

  scopes {
    type    = "Repository"
    name    = "taskboard/*"
    actions = ["push", "pull"]
  }
}

output "ci_push_password" {
  value     = ionoscloud_container_registry_token.ci_push.password
  sensitive = true
}

Zwei Verhaltensweisen sind für die Automatisierung relevant. Das Token-Passwort wird nur einmal angezeigt. Erfassen Sie es daher unmittelbar aus dem Terraform-Zustand oder der API-Antwort und speichern Sie es in Ihrem Secret Manager. Wenn das Ablaufdatum erreicht ist, wird das Token gelöscht und nicht deaktiviert. Ein Rotationsjob muss daher den Ersatz vor Ablauf des alten Tokens erstellen, da andernfalls Ihre Pipeline während des Deploys den Zugriff verliert.

2.2 Erstellen eines Tokens über die API und Anmeldung

Der Token-Endpunkt ist POST /containerregistries/registries/{registryId}/tokens. Es gibt zwei Token-Typen: ein dauerhaftes Registry-Zugriffstoken und ein temporäres, das durch expiryDate begrenzt ist. Die minimale Gültigkeitsdauer beträgt eine Stunde in die Zukunft.

curl --location \
  --request POST "https://api.ionos.com/containerregistries/registries/${REGISTRY_ID}/tokens" \
  --header "Authorization: Bearer ${IONOS_TOKEN}" \
  --header 'Content-Type: application/json' \
  --data-raw '{
    "properties": {
      "name": "ci-push",
      "status": "enabled",
      "scopes": [
        { "type": "Repository", "name": "taskboard/*", "actions": ["push", "pull"] }
      ]
    }
  }'

Die Antwort enthält die Anmelddaten nur einmal. Verwenden Sie den Token-Namen als Benutzernamen und das Token-Passwort als Passwort für docker login gegenüber dem Hostnamen des Registries.

echo "${CR_TOKEN_PASSWORD}" | docker login taskboard-prod.cr.de-fra.ionos.com \
  --username ci-push \
  --password-stdin

Ein Token befindet sich in einem von drei Zuständen: enabled, disabled oder deleted. Deaktivieren Sie ein Token, um den Zugriff sofort zu entziehen, ohne es zu löschen; löschen Sie es, wenn es nicht mehr benötigt wird.

2.3 Auswahl der Methode zum Erstellen und Verwenden von Zugangsdaten

Die folgende Tabelle vergleicht die Zugriffswege für Registry-Zugangsdaten, damit Sie den passenden Weg für jeden Workflow auswählen können.

Da Berechtigungen (Scopes) pro Registry oder pro Repository-Pfad vergeben werden und kein RBAC vorhanden ist, modellieren Sie ein Token pro CI-Pipeline und ein Token pro Entwickler, anstatt ein einzelnes, weitreichendes Token zu teilen. Beschränken Sie CI-Tokens auf push sowie pull auf den Repository-Pfaden, die sie besitzen, und beschränken Sie nur lesende Deployment-Tokens ausschließlich auf pull.

3. Erstellen und Hochladen von Images

Wenn eine Registry läuft und ein Token vorliegt, folgt der Image-Ablauf dem Standard-Docker-Verfahren gegen den Hostnamen der Registry. Die Disziplin, die ihn produktionsreif macht, sind Multi-Stage-Builds für kleine Images und immutable Git-SHA-Tags für nachvollziehbare Deployments.

3.1 Multi-Stage-Dockerfile für die TaskBoard API

Ein Multi-Stage-Build kompiliert oder installiert Abhängigkeiten in einer großen Builder-Stage und kopiert nur die Laufzeit-Artefakte in ein schlankes finales Image. Kleinere Images werden auf Kubernetes schneller abgerufen und enthalten weniger Pakete, die der Vulnerability Scanner als problematisch kennzeichnet.

FROM python:3.12 AS builder
WORKDIR /app
COPY requirements.txt .
RUN pip install --prefix=/install --no-cache-dir -r requirements.txt

FROM python:3.12-slim
WORKDIR /app
COPY --from=builder /install /usr/local
COPY . .
EXPOSE 8080
CMD ["gunicorn", "--bind", "0.0.0.0:8080", "taskboard.api:app"]

3.2 Mit dem Git-SHA taggen und pushen

Vergeben Sie für jeden Build ein Tag mit dem unveränderlichen Git-SHA, damit ein deploytes Image auf einen exakten Commit zurückverfolgt werden kann. Ein latest-Tag ist als bequemer Zeiger in Ordnung, aber deployen Sie niemals von diesem Tag; deployen Sie vom SHA.

REGISTRY=taskboard-prod.cr.de-fra.ionos.com
GIT_SHA=$(git rev-parse --short HEAD)

docker build -t "${REGISTRY}/taskboard/api:${GIT_SHA}" \
             -t "${REGISTRY}/taskboard/api:latest" .

docker push "${REGISTRY}/taskboard/api:${GIT_SHA}"
docker push "${REGISTRY}/taskboard/api:latest"

Das Pipeline-Muster besteht aus dem Erstellen, dem Vergeben eines Tags mit dem Git-SHA, dem Pushen in das Registry und der anschließenden Referenzierung des SHA-Tags im Kubernetes-Manifest (dargestellt in Einheit 3.2). Beachten Sie, dass ein Token, das push gewährt, auch pull benötigt: Das Pushen eines Images erfordert das Lesen vorhandener Ebenen, daher ist ein rein push-basierter Bereich nicht ausreichend, und ein push-Token muss auch pull enthalten.

4. Garbage Collection und Vulnerability Scanning

Zwei Registry-Funktionen werden serverseitig ausgeführt und sollten frühzeitig konfiguriert werden. Garbage Collection stellt Speicherplatz aus nicht mehr referenzierten Layern wieder her, und Vulnerability Scanning macht CVEs in Ihren hochgeladenen Artefakten sichtbar.

4.1 Garbage Collection

Garbage Collection befreit Speicherplatz, der von Layerdaten belegt wird, die von keinem Tag mehr referenziert werden. Standardmäßig ist sie deaktiviert, da der richtige Zeitplan von Ihrem Rhythmus für Uploads und Löschungen abhängt. Daher müssen Sie sie explizit festlegen. Sie haben sie bereits im Terraform-Ressourcen in Abschnitt 1.1 über den garbage_collection_schedule-Block mit days und einem time konfiguriert.

garbage_collection_schedule {
  days = ["Saturday", "Sunday"]
  time = "19:30:00+00:00"
}

Während der Müllsammlung (Garbage Collection) befindet sich die Registry im schreibgeschützten Zustand: Pulls funktionieren weiterhin, Pushes werden jedoch blockiert, bis der Vorgang abgeschlossen ist. Planen Sie die Ausführung daher für ein Zeitfenster mit geringem Verkehr ein, um CI/CD-Pushes und Deployments nicht zu unterbrechen. Beachten Sie, dass die Docker Registry V2 API es nicht ermöglicht, ein gesamtes Repository zu löschen. Um ein Repository zu entfernen, rufen Sie die IONOS CLOUD Container Registry API direkt mit DELETE /containerregistries/registries/{id}/repositories/{url-encoded-name} auf. Der Repository-Name in der URL muss URL-kodiert sein, beispielsweise wird taskboard/api zu taskboard%2Fapi, andernfalls wird ein Fehler 404 zurückgegeben.

4.2 Schwachstellenanalyse

Die Schwachstellenanalyse untersucht hochgeladene Artefakte auf bekannte CVEs. Es handelt sich um eine Zusatzfunktion, die nach der Aktivierung in einer Registry nicht mehr deaktiviert werden kann. Aktivieren Sie diese Funktion daher bewusst. Die Scan-Ergebnisse werden pro Artefakt und pro Repository gemeldet, einschließlich der Angabe, welche Befunde bekannte Korrekturen haben. So können Sie die Freigabe eines Images in CI an dessen Scan-Ergebnissen ausrichten.

Behandeln Sie den Scan als Qualitätskontrolle: Nach dem Push-Schritt fragen Sie die Scan-Ergebnisse für das mit SHA getaggte Artefakt ab und lassen die Pipeline fehlschlagen, wenn die Befunde Ihren Schwellenwert überschreiten, bevor der Deployment-Schritt fortgesetzt wird.

5. CI-Integration

In CI führen Sie keinen interaktiven docker login aus. Sie speichern die Token-Anmeldeinformationen als Pipeline-Secrets und übergeben sie an docker login --password-stdin. Der Registry-Hostname, der Token-Name und das Token-Passwort sind die drei Werte, die Ihre Pipeline benötigt.

5.1 GitHub Actions

Speichern Sie CR_HOSTNAME, CR_USERNAME und CR_PASSWORD als Repository- oder Umgebungs-Secrets, melden Sie sich anschließend im Workflow an und führen Sie den Push durch.

name: build-and-push
on:
  push:
    branches: [main]

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Log in to IONOS CLOUD Container Registry
        run: |
          echo "${{ secrets.CR_PASSWORD }}" | docker login "${{ secrets.CR_HOSTNAME }}" \
            --username "${{ secrets.CR_USERNAME }}" --password-stdin

      - name: Build and push
        run: |
          SHA=$(git rev-parse --short HEAD)
          IMG="${{ secrets.CR_HOSTNAME }}/taskboard/api:${SHA}"
          docker build -t "$IMG" .
          docker push "$IMG"

5.2 GitLab CI

Die entsprechende GitLab-Pipeline verwendet CI/CD-Variablen für dieselben drei Werte sowie den Docker-in-Docker-Dienst für den Build.

build-and-push:
  image: docker:24
  services:
    - docker:24-dind
  variables:
    DOCKER_HOST: tcp://docker:2376
  script:
    - echo "$CR_PASSWORD" | docker login "$CR_HOSTNAME" --username "$CR_USERNAME" --password-stdin
    - SHA=$(echo "$CI_COMMIT_SHA" | cut -c1-7)
    - docker build -t "$CR_HOSTNAME/taskboard/api:$SHA" .
    - docker push "$CR_HOSTNAME/taskboard/api:$SHA"
  only:
    - main

Da Tokens das einzige Authentifizierungsmodell darstellen, sollten Sie das CI-Token regelmäßig rotieren und das zugehörige Geheimnis synchron aktualisieren. Jeder Client ist auf 60 Anfragen pro Sekunde und 100 gleichzeitige Verbindungen begrenzt. Dies ist für eine einzelne Pipeline großzügig bemessen, sollte jedoch berücksichtigt werden, wenn parallele Matrix-Builds ausgeführt werden, die gleichzeitig Daten hochladen.

Schnellreferenz für die API

Wichtige API-Endpunkte für Container Registry:

Basis-URL: https://api.ionos.com Authentifizierung: Authorization: Bearer <token>

Code Lab

Ziel: Eine Container Registry bereitstellen, ein Token mit begrenztem Geltungsbereich erstellen, das TaskBoard API-Image bauen und es mit einem Git-SHA-Tag hochladen.

Voraussetzungen:

• IONOS CLOUD-Konto, bei dem das API-Token als IONOS_TOKEN exportiert wurde
• Lokal installierte Terraform- und Docker-Umgebung
• Ein Dockerfile für die TaskBoard API (siehe Abschnitt 3.1)

Schritt 1: Registry und Token bereitstellen

export IONOS_TOKEN="your-api-token"
terraform init
terraform apply -auto-approve

Erwartete Ausgabe:

ionoscloud_container_registry.taskboard: Creation complete
Outputs:
registry_hostname = "taskboard-prod.cr.de-fra.ionos.com"

Schritt 2: Hostname und Token-Passwort des Registry lesen

REGISTRY=$(terraform output -raw registry_hostname)
CR_PASSWORD=$(terraform output -raw ci_push_password)
echo "$REGISTRY"

Erwartete Ausgabe:

taskboard-prod.cr.de-fra.ionos.com

Schritt 3: Anmeldung an der Registry

echo "$CR_PASSWORD" | docker login "$REGISTRY" --username ci-push --password-stdin

Erwartete Ausgabe:

Login Succeeded

Schritt 4: Das Image erstellen

docker build -t "${REGISTRY}/taskboard/api:$(git rev-parse --short HEAD)" .

Erwartete Ausgabe:

=> exporting to image
=> => naming to taskboard-prod.cr.de-fra.ionos.com/taskboard/api:a1b2c3d

Schritt 5: Das Image hochladen

docker push "${REGISTRY}/taskboard/api:$(git rev-parse --short HEAD)"

Erwartete Ausgabe:

a1b2c3d: digest: sha256:... size: 1786

Schritt 6: Über die API überprüfen

REGISTRY_ID=$(terraform output -raw registry_id)
curl -s --request GET \
  "https://api.ionos.com/containerregistries/registries/${REGISTRY_ID}/repositories" \
  --header "Authorization: Bearer ${IONOS_TOKEN}" | jq '.items[].id'

Erwartete Ausgabe:

"taskboard/api"

Prüfliste:

• [ ] Registry erreicht Running und einen Hostnamen offengelegt
• [ ] docker login hat Login Succeeded zurückgegeben
• [ ] Image mit einem Git-SHA-Tag hochgeladen und über die Repositories-API sichtbar

Aufräumarbeiten:

terraform destroy -auto-approve

Häufige Fehler

Fehler von Entwicklerinnen und Entwicklern, die bei der Container Registry zu vermeiden sind:

1. Hostname lesen, bevor die Registry den Zustand „Running“ erreicht hat

   • Problem: Der docker login Ihrer Pipeline schlägt mit einem DNS-Auflösungsfehler fehl, unmittelbar nachdem terraform apply ausgeführt wurde.
   • Ursache: Der Hostname bleibt leer, bis die Registry den Zustand New verlässt und den Zustand Running erreicht. Ein zu frühes Lesen liefert einen leeren oder nicht auflösbaren Wert.
   • Lösung: Das Login-Schritt an den Zustand Running koppeln. Die Registry abfragen, bis sie bereit ist, und erst dann die Anmeldung durchführen:

   until [ "$(curl -s -H "Authorization: Bearer $IONOS_TOKEN" \
     https://api.ionos.com/containerregistries/registries/$REGISTRY_ID \
     | jq -r '.metadata.state')" = "Running" ]; do sleep 5; done
   

2. Push-Token ohne Pull-Berechtigung

   • Problem: docker push schlägt mit einem Autorisierungsfehler fehl, obwohl das Token über die push-Aktion verfügt.
   • Ursache: Beim Push werden vorhandene Ebenen gelesen, um Duplikate zu vermeiden, daher erfordert der Push auch ein Pull. Ein ausschließliches push-Scope wird abgelehnt.
   • Lösung: Fügen Sie pull immer neben push in den Scope ein:

   actions = ["push", "pull"]
   

3. Ablauf eines Tokens während der Bereitstellung

   • Problem: Eine CI-Bereitstellung, die gestern noch funktioniert hat, schlägt jetzt bei der Authentifizierung fehl, und das Token ist einfach verschwunden.
   • Ursache: Wenn das Ablaufdatum eines Tokens erreicht wird, wird es gelöscht und nicht deaktiviert. Es gibt daher keine Übergangsfrist und keinen Weg, es wieder zu aktivieren.
   • Lösung: Vor Ablauf des Tokens rotieren. Das Ersatztoken erstellen, das CI-Geheimnis aktualisieren und dann das alte Token ablaufen lassen. Setzen Sie niemals ein Ablaufdatum, das kürzer ist als Ihr Release-Takt. Beachten Sie, dass das minimale Ablaufdatum eine Stunde in der Zukunft liegen muss.

Zusammenfassung

Sie können jetzt eine IONOS CLOUD Container Registry als Infrastructure as Code provisionieren, bereichseingegrenzte Zugriffstoken ausstellen, die Docker CLI und CI-Pipelines dagegen authentifizieren und produktionsreife, mehrstufige Images mit Git-SHA-Tags pushen. Sie wissen auch, wie Sie die Müllsammlung konfigurieren, um Speicher freizugeben, und das Schwachstellen-Scanning als Freigabe-Schranke aktivieren. Dieses Repository ist die einzige Quelle der Wahrheit für die Images, die Einheit 3.2 zu Managed Kubernetes deployen wird.

Das rein tokenbasierte Zugriffsmodell des Repositories ohne RBAC und ohne ACLs pro Repository bestimmt, wie Sie Berechtigungen organisieren: ein bereichseingegrenztes Token pro Pipeline und pro Entwickler, rotiert vor Ablauf, da abgelaufene Token vollständig gelöscht werden. Beachten Sie die Einschränkung, dass der Hostname erst nach dem Status „Running" gesetzt wird, für jeden automatisierten Workflow. Die hier aufgebaute Build-Tag-Push-Pipeline wird die erste Stufe des vollständigen CI/CD-Flusses in Einheit 3.3.

Wichtige Punkte:

• Provisionieren Sie Repositories mit ionoscloud_container_registry; name und location sind unveränderlich, und der Name ist global eindeutig (ein Duplikat liefert HTTP 409)
• Der Hostname folgt {name}.cr.{location-with-dash}.ionos.com und ist leer, bis das Repository Running ist
• Die Authentifizierung ist rein tokenbasiert docker login, mit Bereichen Registry oder Repository und Aktionen pull, push, delete; push erfordert pull
• Token-Passwörter werden nur einmal angezeigt, und abgelaufene Token werden gelöscht, nicht deaktiviert; erfassen und rotieren Sie sie daher proaktiv
• Die Müllsammlung ist standardmäßig deaktiviert und wird nach Zeitplan konfiguriert; das Schwachstellen-Scanning ist ein Add-on, das nach der Aktivierung nicht deaktiviert werden kann

Wichtige Begriffe:

• Repository-Zugriffstoken: Die Berechtigung für docker login, bereichseingegrenzt pro Repository oder pro Repository-Pfad; verfügbar als dauerhafte und temporäre (mit Ablaufdatum) Typen
• Bereich: Die Berechtigungsvergabe eines Tokens, bestehend aus einem Typ (Registry oder Repository), einem Pfad und einem Aktionsset aus pull, push, delete
• Müllsammlung: Serverseitige Freigabe nicht referenzierter Image-Ebenen, standardmäßig deaktiviert und nach konfigurierbarem Tages-/Zeitplan ausgeführt
• Schwachstellen-Scanning: Ein Add-on, das hochgeladene Artefakte auf CVEs pro Artefakt und pro Repository analysiert; nach der Aktivierung nicht rückgängig machbar
• Git-SHA-Tag: Ein unveränderliches Image-Tag, das auf die Commit-SHA gesetzt wird, sodass ein deploytes Image einem exakten Commit zugeordnet werden kann

Nächste Schritte

Weiter lernen: Einheit 3.2: Kubernetes Deployment und Betrieb

Verwandte Themen:

• Einheit 1.1: IONOS CLOUD API, Authentifizierung und Async-Modell
• Einheit 3.3: CI/CD-Pipelines für IONOS CLOUD