Einheit 2.4: Speicherbereitstellung als Code

Einführung

Sie bauen die Speicherebene von TaskBoard aus, und jeder Teil des Zustands landet an einem anderen Ort. Der API-Server benötigt ein persistentes Datenvolumen, das Neustarts übersteht und sich wie eine lokale Festplatte verhält. Benutzeruploadete Dateianhänge gehören in einen Object Storage, der über HTTP mit S3-Zugangsdaten erreicht wird, und nicht an eine einzelne VM angebunden ist. Und wenn Sie später mehrere Worker ausführen, die alle dieselben Dateien lesen, möchten Sie ein gemeinsames Dateisystem anstelle von Kopien auf jedem Knoten.

Alle drei werden auf die gleiche Weise bereitgestellt: deklarative Terraform-Ressourcen gegen die IONOS CLOUD API, mit dem gleichen asynchronen Erstellungs- und Wartemodell, das Sie seit Einheit 1.1 verwenden. Die Unterschiede, die Sie beeinträchtigen, sind die Einschränkungen. Block Storage und Compute teilen nicht die gleichen Verfügbarkeitszonen. Object Storage verwendet Ihren Bearer-Token überhaupt nicht. NFS spricht nur eine Protokollversion. Diese Einheit behandelt jeden Speichertyp auf Code-Ebene und zeigt, wo diese Einschränkungen das Geschriebene ändern.

1. Block Storage-Volumes mit Terraform

Block Storage wird als ionoscloud_volume bereitgestellt und verhält sich wie ein iSCSI-Blockgerät, das an einen Server angehängt ist. Sie erklären die Größe, den Speichertyp und die Verfügbarkeitszone, und Terraform übernimmt die asynchrone Bereitstellung und Anbindung. Ein Volume wird innerhalb eines Rechenzentrums erstellt und über das server_id-Attribut an einen einzelnen Server gebunden.

Die Mindestvolumengröße beträgt 1 GiB und die Maximalgröße 4096 GiB (4 TiB) für jeden Block Storage-Typ. Größere Volumes können über den IONOS CLOUD-Support angefordert werden. Der Speichertyp kann nach der Bereitstellung nicht geändert werden, daher sollten Sie ihn korrekt beim Erstellen auswählen, anstatt später zu konvertieren.

1.1 Deklaration und Anbindung eines Volumes

Die folgende Konfiguration erstellt ein SSD-Premium-Datenvolume und bindet es an den TaskBoard-API-Server. Die image_name und image_password (oder ssh_key_path) sind erforderlich, wenn das Volume bootfähig ist; für eine reine Datendiskette stellen Sie stattdessen ein licence_type bereit und überspringen das Image.

resource "ionoscloud_datacenter" "taskboard" {
  name     = "taskboard"
  location = "de/txl"
}

resource "ionoscloud_volume" "api_data" {
  datacenter_id = ionoscloud_datacenter.taskboard.id
  server_id     = ionoscloud_server.api.id
  name          = "taskboard-api-data"
  size          = 50
  disk_type     = "SSD Premium"
  licence_type  = "LINUX"
  availability_zone = "AUTO"
}

Der disk_type akzeptiert die Speichertechnologie-Varianten, die von Block Storage bereitgestellt werden: HDD, SSD Premium und SSD Standard. SSD Premium liefert die höchste Anzahl an IOPS pro Volumen, SSD Standard tauscht Leistung gegen Kosten und HDD ist die günstigste Option mit sich drehenden Scheiben. Alle drei haben eine Obergrenze von 4 TiB (4096 GiB) pro Volumen mit einer Untergrenze von 1 GiB.

1.2 Die Verfügbarkeitszone-Falle

Die Verfügbarkeitszonen von Block Storage sind nicht dieselbe Menge wie die Verfügbarkeitszonen von Compute, und dies ist der häufigste Bereitstellungsfehler in der Speicherebene. Block Storage unterstützt Zone 1, Zone 2, Zone 3 und Auto. Compute-Server unterstützen nur die Zonen 1, 2 und Auto. Zone 3 existiert für den Speicher, aber es gibt keine Zone 3 für die Rechenleistung.

Dies ist wichtig, weil ein Volumen und der Server, an den es angehängt ist, im gleichen Rechenzentrum leben, aber durch unabhängige Zoneneinstellungen platziert werden. Wenn Sie ein Volumen an eine Zone binden, die nicht mit Ihrer Server-Platzierungsstrategie übereinstimmt, beschränken Sie die Planung ohne Vorteil. Der sichere Standard ist AUTO sowohl für den Server als auch für das Volumen, es sei denn, Sie haben eine spezifische Anforderung für die Zonenbindung.

// Safe default: let the platform place both
resource "ionoscloud_server" "api" {
  datacenter_id     = ionoscloud_datacenter.taskboard.id
  name              = "taskboard-api"
  cores             = 4
  ram               = 8192
  availability_zone = "AUTO" // Zone 1, 2, or AUTO only - never Zone 3
}

resource "ionoscloud_volume" "api_data" {
  # ...
  availability_zone = "AUTO"   # Zone 1, 2, 3, or AUTO permitted for storage
}

Volumen können auf einem einzelnen virtuellen Computer (VM) gemischt werden. Ein Server kann sowohl SSD- als auch HDD-Volumen gleichzeitig tragen. Ein virtueller Computer unterstützt bis zu 24 angehängte Volumen von beliebigem Mix an Speichertypen, die Anzahl wird über alle Typen hinweg gemeinsam genutzt und nicht pro Typ. Planen Sie Multi-Volumen-Layouts gegen diese 24-Volumen-Obergrenze.

1.3 Verschlüsselung und Kontext der Haltbarkeit

Block Storage bietet doppelt redundante Speicherung: Daten werden auf zwei Speicher-Server geschrieben, die jeweils durch RAID geschützt sind, um Redundanz auf Plattformebene zu gewährleisten. Die Verschlüsselung von logischen Volumen im Ruhezustand verwendet den AES-XTS-Algorithmus. Sie konfigurieren weder das eine noch das andere im Volumen-Ressourcen-Objekt, da beide Eigenschaften der Plattform-Speicher-Schicht sind, sodass sich Ihr Terraform auf Größe, Typ und Platzierung konzentrieren kann.

2. Object-Storage-Buckets und Zugriffsschlüssel

Object Storage wird mit ionoscloud_s3_bucket bereitgestellt, und seine Zugriffsberechtigungen werden mit ionoscloud_s3_key erstellt. Der kritische Unterschied zu allen anderen Ressourcen in diesem Kurs: Object Storage authentifiziert sich nicht mit Ihrem IONOS CLOUD-Bearer-Token. Es implementiert die AWS-S3-API und authentifiziert sich mit einem Zugriffsschlüssel und einem geheimen Schlüssel. Ihre Anwendung, Ihre CI-Pipeline und jeder S3-Client verwenden diese Schlüssel, niemals das Cloud-API-Token.

resource "ionoscloud_s3_key" "taskboard" {
  user_id = var.user_id
}

resource "ionoscloud_s3_bucket" "attachments" {
  name = "taskboard-attachments-prod"
}

Bucket-Namen müssen global eindeutig sein, über alle Object-Storage-Mieter hinweg, und müssen zwischen 3 und 63 Zeichen lang sein. Behandeln Sie den Namen wie ein DNS-Label, in Kleinbuchstaben mit Bindestrichen, und nehmen Sie an, dass die offensichtlichen Namen bereits vergeben sind. Eine Namenskollision tritt als Erstellungsfehler bei der Anwendung, nicht bei der Planung, auf.

2.1 Ausgeben von Anmeldeinformationen als sensible Werte

Die ionoscloud_s3_key-Ressource produziert einen Zugriffsschlüssel und einen geheimen Schlüssel. Der geheime Schlüssel darf niemals in Protokollen oder einfacher Ausgabe erscheinen. Markieren Sie die Ausgaben sensitive = true, damit Terraform sie aus der CLI-Ausgabe und den CI-Protokollen schwärzt; die Werte leben immer noch im Zustand, daher schützen Sie den Zustand-Backend entsprechend.

output "s3_access_key" {
  value     = ionoscloud_s3_key.taskboard.id
  sensitive = true
}

output "s3_secret_key" {
  value     = ionoscloud_s3_key.taskboard.secret_key
  sensitive = true
}

output "s3_bucket_name" {
  value = ionoscloud_s3_bucket.attachments.name
}

Ein Zugriffsschlüssel ist 92 Zeichen lang und ein geheimer Schlüssel 64 Zeichen. Jeder Benutzer kann bis zu 5 Zugriffsschlüssel halten, was ausreichend ist, um ohne Ausfallzeit zu rotieren: Erstellen Sie den neuen Schlüssel, rollen Sie die Anwendungskonfiguration und zerstören Sie dann den alten Schlüssel. Die Anmeldedaten sind nicht an eine bestimmte Region oder einen bestimmten Bucket gebunden, ein Schlüsselpaar funktioniert über alle Bucket, die der Benutzer erreichen kann.

2.2 Endpunkte und Regionen

Object Storage bietet den S3-API-v2-Standard und Sie können ihn über einen regionsspezifischen Endpunkt ansprechen. Im Gegensatz zu AWS müssen Sie den Endpunkt in jedem Client explizit festlegen, da die Standard-AWS-Endpunkte nicht aufgelöst werden. Die folgende Tabelle listet die Dienstendpunkte auf, auf die Ihr Code und die Terraform-Backend-Verbindung verweisen.

Wählen Sie den Endpunkt, der der Region entspricht, in der Sie den Bucket erstellen, und verwenden Sie ihn überall wieder: in boto3, im S3-Backend-Block unten und bei der Generierung von presigned-URLs. Verbindungen verwenden TLS, wobei TLS 1.2 und 1.3 unterstützt werden. Die maximale Objektgröße beträgt 5 TB. Object Storage bietet eine einzelne Speicherklasse, STANDARD, und ein Bucket unterstützt bis zu 1000 Lebenszyklusregeln für das Objektablauf; Lebenszyklusregeln können Objekte nicht in eine andere Speicherklasse übertragen (es gibt keine kalte oder Archivschicht).

3. Object Storage als Terraform-State-Backend

Da Object Storage S3-kompatibel ist, dient es auch als Remote-State-Backend für Terraform. Dies löst das Problem, das Sie in Einheit 1.2 kennengelernt haben: Der lokale Zustand überlebt nicht über ein Team oder einen CI-Runner hinweg. Durch die Speicherung des Zustands in einem Bucket erhält jeder Pipeline-Lauf eine gemeinsame, dauerhafte Wahrheitsquelle.

3.1 Backend-Konfiguration

Das s3-Backend benötigt den IONOS CLOUD-Endpunkt und die gleichen Skip-Flags, die Sie für jede nicht-AWS-S3-Implementierung verwenden, da das Backend ansonsten versucht, gegen AWS-Konten- und Regionenregeln zu validieren, die nicht anwendbar sind.

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

Stellen Sie den Zugriffsschlüssel und den geheimen Schlüssel dem Backend über Umgebungsvariablen (AWS_ACCESS_KEY_ID und AWS_SECRET_ACCESS_KEY) zur Verfügung, anstatt sie hart zu codieren. Der Status-Bucket muss bereits vor terraform init existieren, also bereiten Sie ihn einmal mit einer kleinen Bootstrap-Konfiguration oder mit ionosctl vor, und verweisen Sie dann das Backend Ihres Haupt-Stacks darauf.

3.2 Warum dies für die Pipeline wichtig ist

Der Status-Bucket enthält Ihre S3-Geheimschlüssel und Datenbank-Verbindungsstringe innerhalb der Status-Datei. Beschränken Sie, wer ihn lesen kann. Ein praktisches Muster ist ein Bucket pro Umgebung, mit separaten Schlüsselprefixen pro Stack, sodass eine Dev-Pipeline den Prod-Status nicht lesen kann. Dies wirkt sich direkt auf die CI/CD-Arbeit in Modul 3 aus, wo die gleichen Anmeldedaten zu Pipeline-Geheimnissen werden.

4. NFS-Shared-Speicher

Wenn mehrere Server dieselben Dateien lesen und schreiben müssen, passt weder ein einzelnes Block Storage-Volume noch ein Object Storage sauber. NFS bietet Ihnen ein POSIX-Dateisystem, das gleichzeitig auf Linux-Clients gemountet wird. Es wird in zwei Ressourcen bereitgestellt: ionoscloud_nfs_cluster definiert den Cluster, und ionoscloud_nfs_share definiert einen Shared-Speicher innerhalb davon. Der gleiche asynchrone Lebenszyklus und terraform destroy-Bereinigung gelten.

resource "ionoscloud_nfs_cluster" "shared" {
  name     = "taskboard-shared"
  location = "de/txl"
  size     = 2

  nfs {
    min_version = "4.2"
  }

  connections {
    datacenter_id = ionoscloud_datacenter.taskboard.id
    ip_address    = "10.7.222.100/24"
    lan           = ionoscloud_lan.app.id
  }
}

resource "ionoscloud_nfs_share" "uploads" {
  cluster_id = ionoscloud_nfs_cluster.shared.id
  location   = ionoscloud_nfs_cluster.shared.location
  name       = "uploads"
  quota      = 1024
  gid        = 1000
  uid        = 1000
}

4.1 Protokoll- und Kapazitätsbeschränkungen

NFS auf IONOS CLOUD spricht nur NFSv4.2. NFSv3 wird nicht unterstützt, sodass alle Client-Tools oder fstab-Einträge, die auf v3 festgelegt sind, nicht montiert werden können. Die Clustergröße reicht von einem Minimum von 2 TiB bis zu einem Maximum von 42 TiB, wobei die gesamte bereitgestellte Kapazität vollständig nutzbar ist. Share-Quotas werden in MiB ausgedrückt.

Die Verschlüsselung bei ruhenden Daten wird von der Plattform bereitgestellt. Die Verschlüsselung während der Übertragung ist für NFS nicht dokumentiert, daher sollten Sie für sensible Daten den Share in einem privaten LAN halten und sich auf die Netzwerkisolierung verlassen, anstatt TLS auf dem Mount zu erwarten. Der Cluster läuft im Active-Passive-Modus mit hoher Verfügbarkeit und ist über eine private IP erreichbar, die Sie im connections-Block zuweisen.

4.2 Mounten des Shares

Nach dem Anwenden wird der Share von einem Linux-Client mithilfe der Cluster-IP und der Share-UUID, die im Ausgabebereich des Ressourcen-nfs_path zurückgegeben wird, gemountet. Linux ist das unterstützte Client-Betriebssystem.

sudo mount -t nfs 10.7.222.100:/<share-uuid> /mnt/uploads

Root-Squash wird unterstützt, sodass die UID und GID auf dem Share so gemappt werden müssen, dass sie dem Anwendungsbenutzer entsprechen, der die Dateien liest und schreibt, wie durch die uid- und gid-Argumente oben gezeigt wird. Eine nicht übereinstimmende Besitzstruktur ist normalerweise die Ursache für Permission-denied-Fehler direkt nach einem erfolgreichen Mount.

5. Auswahl des richtigen Speichers im Code

Jeder Speichertyp entspricht einem anderen Zugriffsmuster, und die falsche Auswahl zeigt sich entweder als Einschränkung, gegen die man ankämpft, oder als unerwartete Rechnung. Block Storage wird genau einem Server zugeordnet und verhält sich wie eine lokale Festplatte: verwenden Sie es für Datenbanken, Betriebssystemvolumes und jede Single-Writer-Workload. Object Storage kann über HTTP mit S3-Anmeldeinformationen erreicht werden und skaliert unabhängig von jeder VM: verwenden Sie es für Benutzeruploads, Sicherungen, statische Assets und Terraform-Zustand. NFS bietet gleichzeitigen POSIX-Zugriff auf viele Linux-Clients: verwenden Sie es nur, wenn mehrere Server tatsächlich eine Dateisystemfreigabe benötigen.

Die folgende Tabelle fasst die Entscheidung auf der Ebene zusammen, die Sie benötigen, während Sie Terraform schreiben.

Für TaskBoard wird dies sauber gelöst. Das Datenvolumen des API-Servers ist Block Storage, das an einen Server angebunden ist und für den Arbeitsbereich dimensioniert ist. Dateianhänge werden in Object Storage gespeichert, da der Browser direkt mit vorab unterzeichneten URLs hochlädt und der API nie die Bytes vermittelt. NFS wird im Basis-TaskBoard-Build nicht verwendet; es ist das Muster, das Sie später erreichen, wenn Sie eine Flotte von Arbeitern hinzufügen, die ein Inhaltsverzeichnis freigeben müssen.

API-Referenz-Quick-Card

Wichtige API-Endpunkte für die Speicherbereitstellung:

Cloud-API-Grund-URL: https://api.ionos.com/cloudapi/v6 Object Storage-S3-Endpunkt: https://s3.eu-central-4.ionoscloud.com (regionspezifisch) NFS-API-Grund-URL: https://nfs.{region}.ionos.com Authentifizierung: Cloud-API verwendet Authorization: Bearer <token>; Object Storage verwendet Zugriffsschlüssel + Geheimschlüssel (AWS-Signatur)

Code-Labor

Ziel: Bereitstellung der Speicher-Ebene von TaskBoard mit Terraform: ein Block-Storage-Datenvolumen, das an den API-Server angehängt ist, und ein Object-Storage-Bucket mit Zugriffsanmeldeinformationen, die als sensible Werte ausgegeben werden.

Voraussetzungen:

• IONOS CLOUD-Konto mit API-Token (IONOS_TOKEN exportiert)
• Terraform 1.5+ mit dem ionos-cloud/ionoscloud-Anbieter
• Ein vorhandenes Rechenzentrum und API-Server (aus dem Labor 2.1) oder Erstellung inline

Schritt 1: Anbieter festlegen

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

provider "ionoscloud" {}

Die Erwarteten Ausgaben:

(no output; init resolves the provider in Step 4)

Schritt 2: Deklaration des Block Storage-Datenvolumens

variable "user_id" { type = string }

resource "ionoscloud_volume" "api_data" {
  datacenter_id     = var.datacenter_id
  server_id         = var.server_id
  name              = "taskboard-api-data"
  size              = 50
  disk_type         = "SSD Premium"
  licence_type      = "LINUX"
  availability_zone = "AUTO"
}

Schritt 3: Deklarieren des Object Storage-Buckets und des Schlüssels

resource "ionoscloud_s3_key" "taskboard" {
  user_id = var.user_id
}

resource "ionoscloud_s3_bucket" "attachments" {
  name = "taskboard-attachments-${var.user_id}"
}

output "s3_access_key" {
  value     = ionoscloud_s3_key.taskboard.id
  sensitive = true
}

output "s3_secret_key" {
  value     = ionoscloud_s3_key.taskboard.secret_key
  sensitive = true
}

Schritt 4: Initialisieren und Planen

terraform init
terraform plan -out=storage.plan

Die Erwartete Ausgabe:

Plan: 3 to add, 0 to change, 0 to destroy.
Changes to Outputs:
  + s3_access_key = (sensitive value)
  + s3_secret_key = (sensitive value)

Schritt 5: Anwenden

terraform apply storage.plan

Das erwartete Ergebnis:

ionoscloud_s3_key.taskboard: Creation complete
ionoscloud_s3_bucket.attachments: Creation complete
ionoscloud_volume.api_data: Creation complete after 1m12s
Apply complete! Resources: 3 added, 0 changed, 0 destroyed.

Schritt 6: Lesen der sensiblen Anmeldedaten

terraform output -raw s3_access_key
terraform output -raw s3_secret_key

Das erwartete Ergebnis:

(a 92-character access key, then a 64-character secret key)

Schritt 7: Überprüfen des Buckets mit einem S3-Client

export AWS_ACCESS_KEY_ID=$(terraform output -raw s3_access_key)
export AWS_SECRET_ACCESS_KEY=$(terraform output -raw s3_secret_key)

aws --endpoint-url https://s3.eu-central-4.ionoscloud.com s3 ls

Das erwartete Ergebnis:

2026-06-05 12:01:33 taskboard-attachments-<user_id>

Validierungs-Checkliste:

• [ ] Das Volume zeigt Creation complete und ist an den API-Server angehängt
• [ ] terraform output gibt redigierte (sensitive value)-Einträge ohne -raw zurück
• [ ] Der S3-Client listet den Bucket mithilfe von Access Key + Secret Key auf, nicht mit dem Bearer-Token

Aufräumen:

terraform destroy -auto-approve

Häufige Fehlerquellen

Entwicklerfehler, die beim Bereitstellen von Speicher auf IONOS CLOUD vermieden werden sollten:

1. Ein Volume an Zone 3 binden, während der Server in Zone 1 oder 2 ist

   • Problem: Ein Volume, das in ZONE_3 erstellt wurde, kann nicht mit einem Compute-Server zusammengelegt werden, da Compute keine Zone 3 hat.
   • Warum es passiert: Die Verfügbarkeitszonen für Block Storage sind Zone 1, Zone 2, Zone 3, Auto, aber Compute unterstützt nur Zone 1, Zone 2, Auto. Entwickler gehen davon aus, dass die Zonenmengen übereinstimmen.
   • Lösung: Verwenden Sie availability_zone = "AUTO" sowohl auf dem Server als auch auf dem Volume, es sei denn, Sie haben einen bewussten Zonen-Bindungsplan, und setzen Sie nie ZONE_3 auf einem Server.

2. Das IONOS CLOUD-Bearer-Token an Object Storage senden

   • Problem: S3-Anfragen returnieren 403 SignatureDoesNotMatch oder AccessDenied, obwohl Ihr Cloud-API-Token gültig ist.
   • Warum es passiert: Object Storage implementiert die AWS S3-API und authentifiziert sich mit einem Access Key und einem Secret Key. Das Bearer-Token, das für api.ionos.com verwendet wird, wird vom S3-Endpunkt nicht akzeptiert.
   • Lösung: Generieren Sie Anmeldeinformationen mit ionoscloud_s3_key, setzen Sie AWS_ACCESS_KEY_ID und AWS_SECRET_ACCESS_KEY, und übergeben Sie immer die explizite IONOS CLOUD S3-Endpunkt-URL.

3. Ein NFS-Share mit NFSv3 einbinden

   • Problem: mount -t nfs -o vers=3 ... hängt oder schlägt fehl; der Share lehnt die Verbindung ab.
   • Warum es passiert: IONOS CLOUD NFS unterstützt nur NFSv4.2. NFSv3 ist nicht verfügbar, sodass jede v3-gesteuerte Montageoption oder Legacy-FSTAB-Eintrag nicht verhandelt wird.
   • Lösung: Binden Sie ohne eine v3-Option (NFSv4.2 verhandelt standardmäßig) und stimmen Sie den Share uid/gid mit dem Anwendungsbenutzer ab, da Root-Squash in Kraft ist:

   sudo mount -t nfs 10.7.222.100:/<share-uuid> /mnt/uploads
   

Zusammenfassung

Sie können nun alle drei IONOS CLOUD-Speicherstufen vollständig in Terraform bereitstellen und sie in eine Anwendung integrieren. Block Storage-Volumes werden mit ionoscloud_volume an einen einzelnen Server angehängt, der zwischen 1 GiB und 4 TiB groß ist, wobei der Speichertyp und die Zone bei der Erstellung festgelegt werden. Object Storage-Buckets und S3-Schlüssel werden mit ionoscloud_s3_bucket und ionoscloud_s3_key deklariert, authentifiziert mit Zugriffsschlüssel und Geheimschlüssel anstelle Ihres Bearer-Tokens, und die gleichen Buckets unterstützen Ihren Terraform-Fernstatus. NFS-Cluster und -Freigaben liefern gleichzeitigen NFSv4.2-Zugriff für Fälle, in denen viele Linux-Clients eine Dateisystemfreigabe teilen müssen. Die wiederkehrende Lektion ist, dass die Einschränkungen und nicht die Ressourcensyntax Ihre Konstruktion entscheiden: Zonenunverträglichkeiten, das S3-Authentifizierungsmodell und die NFS-Protokollversion sind die Punkte, an denen Produktionszeit verloren geht.

Wichtige Punkte:

• ionoscloud_volume stellt Block Storage von 1 GiB bis 4 TiB bereit; Speichertyp und Zone sind nach der Erstellung unveränderlich
• Block Storage unterstützt Zone 1, 2, 3 und Auto, aber Compute hat keine Zone 3; Standardmäßig beides auf AUTO
• Object Storage authentifiziert sich mit Zugriffsschlüssel + Geheimschlüssel über einen regionspezifischen S3-Endpunkt, nie das IONOS CLOUD-Bearer-Token
• Object Storage-Buckets funktionieren als S3-kompatibler Terraform-Fernstatus-Hintergrund mit den skip-validation-Flags gesetzt
• NFS bietet gemeinsames NFSv4.2-Speicher von 2 TiB bis 42 TiB; NFSv3 wird nicht unterstützt

Wichtige Begriffe:

• ionoscloud_volume: Terraform-Ressource für ein Block Storage-iSCSI-Volume, das an einen Server angehängt ist.
• ionoscloud_s3_key: Terraform-Ressource, die ein Zugriffsschlüssel- und Geheimschlüsselpaar für Object Storage erstellt; Ausgabe als sensibel.
• S3-Endpunkt: Regionspezifische URL (zum Beispiel s3.eu-central-1.ionoscloud.com), die alle Object Storage-Clients explizit setzen müssen.
• Fernstatus-Hintergrund: Ein gemeinsamer, dauerhafter Speicher für Terraform-Zustand; ein Object Storage-Bucket, der mit dem s3-Hintergrundtyp konfiguriert ist.
• Root-Squash: NFS-Verhalten, das den Client-Root auf eine nicht privilegierte Identität abbildet; erfordert die Ausrichtung von Share uid/gid mit dem Anwendungsbenutzer.

Nächste Schritte

Weiterlernen: Einheit 2.5: Bereitstellung von Datenbank- und Streamingdiensten

Verwandte Themen:

• Einheit 1.2: Terraform-Provider und Core-Muster
• Einheit 4.2: Integration von Object Storage