Einheit 2.4: Storage-Bereitstellung 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 einen persistenten Daten-Volume, der Neustarts übersteht und sich wie eine lokale Festplatte verhält. Benutzer hochgeladene Dateianhänge gehören in einen Objektspeicher, der über HTTP mit S3-Anmeldeinformationen erreicht wird, und nicht an einen einzelnen VM angehängt wird. Und wenn Sie später mehrere Worker ausführen, die alle dieselbe Menge an Dateien lesen, möchten Sie ein gemeinsames Dateisystem anstelle von Kopien auf jedem Node.

Alle drei werden auf die gleiche Weise bereitgestellt: deklarative Terraform-Ressourcen gegen die IONOS-API, mit dem gleichen asynchronen Erstellungs- und Wartemodell, das Sie seit Einheit 1.1 verwendet haben. 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 ändern, was Sie schreiben.

1. Block Storage-Volumen 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 deklarieren 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 Mindestgröße für ein Volume beträgt 1 GiB und die Maximalgröße 4096 GiB (4 TiB) für jeden Block Storage-Typ. Größere Volumen können über den IONOS Cloud-Support angefordert werden. Der Speichertyp kann nach der Bereitstellung nicht geändert werden, daher sollten Sie ihn bei der Erstellung richtig auswählen, anstatt später zu planen, ihn zu konvertieren.

1.1 Deklaration und Anbindung eines Volume

Die folgende Konfiguration erstellt ein SSD Premium-Daten-Volume 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 Bild.

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"
}

Das disk_type akzeptiert die Speichertechnologie-Varianten, die von Block Storage bereitgestellt werden: HDD, SSD Premium und SSD Standard. SSD Premium liefert die höchste IOPS pro Volume, SSD Standard tauscht Leistung gegen Kosten und HDD ist die günstigste Option mit rotierenden Speichern. Alle drei haben eine Obergrenze von 4 TiB (4096 GiB) pro Volume 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 Volume und der Server, an den es angebunden ist, im gleichen Rechenzentrum leben, aber durch unabhängige Zoneneinstellungen platziert werden. Wenn Sie ein Volume an eine Zone binden, die nicht mit Ihrer Server-Platzierungsstrategie übereinstimmt, beschränken Sie die Planung ohne Vorteil. Der sichere Standard ist AUTO auf beiden Servern und Volume, 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 VM über Typen hinweg gemischt werden. Ein Server kann sowohl SSD- als auch HDD-Volumen gleichzeitig tragen. Die pro-VM-Volume-Grenze hängt vom Typ ab: SSD-Premium ermöglicht bis zu 4 Volumen, die an einen VM angehängt sind, während HDD und SSD-Standard bis zu 24 zulassen. Planen Sie mehrere Volume-Layouts gegen die Grenze des von Ihnen gewählten Typs.

1.3 Verschlüsselung und Kontext der Haltbarkeit

Block Storage bietet doppelt redundante Speicherung: Daten werden auf zwei Speicher-Servern geschrieben, die jeweils durch RAID geschützt sind, um Redundanz auf Plattform-Ebene zu gewährleisten. Die Verschlüsselung auf REST für logische Volumen verwendet den AES-XTS-Algorithmus. Sie konfigurieren weder das eine noch das andere in der Volume-Ressource; beide sind Eigenschaften der Plattform-Speicherschicht, sodass sich Ihre 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-Bearer-Token. Es implementiert den 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-Mandanten 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 auf, nicht bei der Planung.

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 plainem Ausgabe erscheinen. Markieren Sie die Ausgaben als 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 in allen Buckets, auf die der Benutzer zugreifen kann.

2.2 Endpunkte und Regionen

Object Storage unterstützt 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-Referenz 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 Ablaufdatum von Objekten; Lebenszyklusregeln können Objekte nicht in eine andere Speicherklasse überführen (es gibt keine kalte oder Archivschicht). S3, S3, Object Storage.

3. Object Storage als Terraform-Zustand-Backend

Da Object Storage mit S3 kompatibel ist, dient es als Remote-State-Backend für Terraform. Dies löst das Problem, das Sie in Einheit 1.2 getroffen 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 Quelle der Wahrheit.

3.1 Backend-Konfiguration

Das s3-Backend benötigt den IONOS-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 Zustandsbucket 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 Hauptstacks darauf.

3.2 Warum dies für die Pipeline wichtig ist

Der Zustandsbucket enthält Ihre S3-Geheimschlüssel und Datenbankverbindungsstrings innerhalb der Zustandsdatei. Beschränken Sie, wer ihn lesen kann. Ein praktisches Muster ist ein Bucket pro Umgebung, mit separaten Schlüsselprefixen pro Stack, so dass eine Dev-Pipeline den Prod-Zustand nicht lesen kann. Dies geht direkt in die CI/CD-Arbeit im Modul 3 über, wo die gleichen Anmeldedaten zu Pipeline-Geheimnissen werden.

4. NFS gemeinsames Speichermedium

Wenn mehrere Server dieselben Dateien lesen und schreiben müssen, passt weder ein einzelnes Block Storage Volume noch ein Objekt-Speicher sauber. NFS bietet ein POSIX-Dateisystem, das gleichzeitig auf mehreren Linux-Clients gemountet wird. Es wird in zwei Ressourcen bereitgestellt: ionoscloud_nfs_cluster definiert die Cluster, und ionoscloud_nfs_share definiert einen Anteil 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 bei IONOS spricht nur NFSv4.2. NFSv3 wird nicht unterstützt, sodass alle Client-Tools oder fstab-Einträge, die auf v3 festgelegt sind, nicht gemountet werden können. Die Größe der Cluster reicht von einem Minimum von 2 TiB bis zu einem Maximum von 42 TiB, wobei die gesamte bereitgestellte Kapazität vollständig nutzbar ist. Anteilsquoten werden in MiB ausgedrückt.

Die Verschlüsselung bei REST wird von der Plattform bereitgestellt. Die Verschlüsselung während der Übertragung ist für NFS nicht dokumentiert, sodass für sensible Daten der Anteil auf einem privaten LAN bleiben und auf Netzwerkisolierung anstelle von TLS auf dem Mount vertrauen sollte. Die Cluster läuft im Active-Passive-Modus mit hoher Verfügbarkeit und ist über ein privates IP erreichbar, das im connections-Block zugewiesen wird.

4.2 Mounten des Anteils

Nach der Anwendung wird der Anteil von einem Linux-Client mithilfe der Cluster IP und der Anteils-UUID, die in der nfs_path-Ausgabe der Ressource 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 UID und GID auf dem Anteil dem Anwendungsbenutzer zugeordnet werden, der die Dateien liest und schreibt, wie durch die uid- und gid-Argumente oben gezeigt. Falsche Besitzverhältnisse sind der übliche Grund für Fehler, die nach einem erfolgreichen Mount auftreten.

5. Auswahl des richtigen Speichers im Code

Jeder Speichertyp entspricht einem anderen Zugriffsmuster, und die falsche Auswahl zeigt sich entweder als Einschränkung, mit der Sie kämpfen, oder als Rechnung, die Sie nicht erwartet haben. Block Storage ist genau einem Server zugeordnet und verhält sich wie eine lokale Festplatte: verwenden Sie es für Datenbanken, Betriebssystem-Volumes und jede einzelne Workload mit einem einzelnen Schreiber. Object Storage ist über HTTP mit S3-Anmeldeinformationen erreichbar und skaliert unabhängig von jedem VM: verwenden Sie es für Benutzeruploads, Sicherungen, statische Assets und den Zustand von Terraform. NFS bietet gleichzeitigen POSIX-Zugriff über 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. Der Datenspeicher des API-Servers ist Block Storage, der an einen Server angebunden ist und für den Arbeitsbereich dimensioniert ist. Dateianhänge werden an Object Storage gesendet, da der Browser direkt mit vorab unterzeichneten URLs hochlädt und der API-Server die Bytes nie zwischenspeichert. NFS wird im Basis-TaskBoard-Build nicht verwendet; es ist das Muster, auf das Sie später zurückgreifen, 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-Basis-URL: https://api.ionos.com/cloudapi/v6 Object Storage-S3-Endpunkt: https://s3.eu-central-4.ionoscloud.com (regionspezifisch) NFS-API-Basis-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 Speicherebene von TaskBoard mit Terraform: ein Block Storage-Datenspeicher Volume, der 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" {}

Das erwartete Ergebnis:

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

Schritt 2: Deklarieren der Block Storage Daten Volume

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-Bereichs 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

Die Erwarteten Ausgaben:

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 sensitiven Anmeldeinformationen

terraform output -raw s3_access_key
terraform output -raw s3_secret_key

Die erwartete Ausgabe:

(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

Die Erwartete Ausgabe:

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

Validierungs-Checkliste:

• [ ] Volume zeigt Creation complete an und ist an den API-Server angehängt
• [ ] terraform output gibt gelöschte (sensitive value)-Einträge ohne -raw zurück
• [ ] Der S3-Client listet den Bucket mithilfe von Zugriffsschlüssel + Geheimschlüssel auf, nicht des Bearer-Tokens

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 von Block Storage sind Zone 1, Zone 2, Zone 3, Auto, aber Compute unterstützt nur Zone 1, Zone 2, Auto. Entwickler nehmen an, dass die Zonenmengen übereinstimmen.
   • Lösung: Verwenden Sie availability_zone = "AUTO" auf beiden Servern und Volume, es sei denn, Sie haben einen bewussten Zonen-Bindungsplan, und setzen Sie nie ZONE_3 auf einem Server.

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

   • Problem: S3-Anfragen geben 403 SignatureDoesNotMatch oder AccessDenied zurück, obwohl Ihr Cloud-API-Token gültig ist.
   • Warum es passiert: Object Storage implementiert das 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-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-NFS unterstützt nur NFSv4.2. NFSv3 ist nicht verfügbar, sodass jede v3-gesperrte Montageoption oder Legacy-Fstab-Eintrag nicht verhandelt.
   • Lösung: Binden Sie ohne eine v3-Option (NFSv4.2 verhandelt standardmäßig) und stimmen Sie die 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-Speicherstufen vollständig in Terraform bereitstellen und sie in eine Anwendung integrieren. Block Storage-Volumen werden einem einzelnen Server mit ionoscloud_volume zugeordnet, wobei die Größe zwischen 1 GiB und 4 TiB liegt und 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 Access Key und Secret Key anstelle des Bearer-Tokens, und die gleichen Buckets unterstützen den Remote-Zustand von Terraform. NFS-Cluster und -Freigaben bieten 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 Ihr Design bestimmen: Zonenfehler, 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 werden beide auf AUTO gesetzt
• Object Storage authentifiziert sich mit Access Key + Secret Key über einen regionsspezifischen S3-Endpunkt, niemals mit dem IONOS-Bearer-Token
• Object Storage-Buckets funktionieren als S3-kompatibler Terraform-Remote-State-Backend mit den Skip-Validation-Flags
• NFS bietet gemeinsame 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 Access Key- und Secret Key-Paar für Object Storage generiert; Ausgabe als sensitiv.
• S3-Endpunkt: Regionsspezifische URL (zum Beispiel s3.eu-central-1.ionoscloud.com), die alle Object Storage-Clients explizit setzen müssen.
• Remote-State-Backend: Ein gemeinsamer, dauerhafter Speicher für den Terraform-Zustand; ein Object Storage-Bucket, der mit dem s3-Backend-Typ konfiguriert ist.
• Root-Squash: NFS-Verhalten, das den Client-Root auf eine nicht-privilegierte Identität abbildet; erfordert die Ausrichtung der Share-uid/gid mit dem Anwendungsbenutzer.

Nächste Schritte

Weiterlernen: Einheit 2.5: Bereitstellung von Datenbank- und Streamingdiensten

Verwandte Themen:

• Einheit 1.2: Terraform-Anbieter und Kernmuster
• Einheit 4.2: Object Storage-Integration