Einheit 2.4: Speicherbereitstellung als Code

Einführung

Sie bauen den Speicherausschuss von TaskBoard aus, und jeder Bestandteil des Zustands wird an einem anderen Ort abgelegt. Der API-Server benötigt ein persistentes Datenvolumen, das Neustarts übersteht und sich wie eine lokale Festplatte verhält. Von Benutzern hochgeladene Dateianhänge gehören in einen Objektspeicher, der über HTTP mit S3-Zugangsdaten erreicht wird, nicht an eine einzelne VM angehängt. Und wenn Sie später mehrere Worker ausführen, die alle dieselbe Gruppe von Dateien lesen, möchten Sie ein gemeinsames Dateisystem, statt Kopien auf jedem Knoten zu haben.

Alle drei werden auf dieselbe Weise bereitgestellt: deklarative Terraform-Ressourcen gegenüber der IONOS CLOUD API, mit dem gleichen asynchronen Erstellen-und-Warten-Modell, das Sie seit Einheit 1.1 verwenden. Die Unterschiede, die Sie treffen, sind die Einschränkungen. Block Storage und Compute teilen sich nicht dieselben Verfügbarkeitszonen. Object Storage verwendet Ihren Bearer-Token überhaupt nicht. NFS spricht nur eine Protokollversion. Diese Einheit behandelt jeden Speichertyp auf Codeebene und zeigt, wo diese Einschränkungen das, was Sie schreiben, verä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 angeschlossen ist. Sie deklarieren die Größe, den Speichertyp und die Verfügbarkeitszone, und Terraform übernimmt die asynchrone Bereitstellung und den Anschluss. Ein Volume wird innerhalb eines Datacenters erstellt und über das Attribut server_id an einen einzelnen Server gebunden.

Die minimale Volumengröße beträgt 1 GiB und die maximale 4096 GiB (4 TiB) für jeden Block Storage-Typ. Größere Volumes können über IONOS CLOUD Support angefordert werden. Der Speichertyp kann nach der Bereitstellung nicht geändert werden, wählen Sie ihn daher beim Erstellen korrekt aus, anstatt eine spätere Umwandlung zu planen.

1.1 Deklaration und Anschluss eines Volumes

Die folgende Konfiguration erstellt ein SSD Premium-Datenvolume und verbindet es mit dem TaskBoard API-Server. image_name und image_password (oder ssh_key_path) sind erforderlich, wenn das Volume bootfähig ist; für eine reine Datendiskette geben Sie stattdessen ein licence_type an 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"
}

Das disk_type akzeptiert die von Block Storage bereitgestellten Varianten der Speichertechnologie: HDD, SSD Premium und SSD Standard. SSD Premium liefert die höchsten IOPS pro Volume, SSD Standard opfert Leistung zugunsten der Kosten, und HDD ist die kostengünstigste rotierende Option. Alle drei Varianten sind auf 4 TiB (4096 GiB) pro Volume begrenzt, mit einem Mindestwert von 1 GiB.

1.2 Die Falle der Verfügbarkeitszone

Die Verfügbarkeitszonen von Block Storage sind nicht identisch mit den Verfügbarkeitszonen von Compute, und dies ist der häufigste Bereitstellungsfehler in der Storage-Ebene. 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 Storage, es gibt jedoch keine Zone 3 für Compute.

Dies ist relevant, weil ein Volume und der Server, an den es angehängt wird, sich im selben Datacenter befinden, aber durch unabhängige Zoneneinstellungen platziert werden. Wenn Sie ein Volume an eine Zone binden, die nicht mit Ihrer Serverplatzierungsstrategie übereinstimmt, beschränken Sie die Planung ohne Nutzen. Der sichere Standardwert ist AUTO sowohl für den Server als auch für das Volume, es sei denn, Sie haben eine spezifische Anforderung an 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
}

Volumes können auf einer einzelnen VM gemischt über verschiedene Typen hinweg verwendet werden. Ein Server kann gleichzeitig sowohl SSD- als auch HDD-Volumes tragen. Eine VM unterstützt bis zu 24 angehängte Volumes in beliebiger Kombination von Speichertypen; die Anzahl wird über alle Typen hinweg gemeinsam gezählt, nicht pro Typ. Planen Sie Mehrvolumen-Layouts entsprechend dieser Obergrenze von 24 Volumes.

1.3 Kontext zu Verschlüsselung und Ausdauer

Block Storage bietet redundanten Speicher mit doppelter Redundanz: Daten werden auf zwei Speicherservern geschrieben, die jeweils durch RAID geschützt sind, für Redundanz auf Plattformebene. Die Verschlüsselung ruhender Daten für logische Volumes verwendet den AES-XTS-Algorithmus. Weder die Redundanz noch die Verschlüsselung werden im Volume-Ressourcenobjekt konfiguriert; beide sind Eigenschaften der Plattenspeicher-Ebene der Plattform, sodass Ihr Terraform sich auf Größe, Typ und Platzierung konzentrieren kann.

2. Object Storage Buckets und Access Keys

Object Storage wird mit ionoscloud_s3_bucket bereitgestellt, und seine Zugangsdaten werden mit ionoscloud_s3_key erstellt. Der entscheidende 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 Access Key und einem Secret Key. 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 über alle Object Storage-Tenants hinweg sein und dürfen zwischen 3 und 63 Zeichen lang sein. Behandeln Sie den Namen wie ein DNS-Label, also in Kleinschreibung mit Bindestrichen, und gehen Sie davon aus, dass offensichtliche Namen bereits vergeben sind. Eine Namenskollision zeigt sich als Fehlschlag bei der Erstellung während der apply-Phase, nicht während der plan-Phase.

2.1 Ausgeben von Zugangsdaten als sensible Werte

Die ionoscloud_s3_key-Ressource erzeugt einen Access Key und einen Secret Key. Der Secret Key darf niemals in Logs oder in Klartext-Ausgaben erscheinen. Markieren Sie die Outputs als sensitive = true, damit Terraform sie in der CLI-Ausgabe und in CI-Logs maskiert; die Werte befinden sich weiterhin im State, daher ist das State-Backend entsprechend zu schützen.

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 Access Key ist 92 Zeichen lang und ein Secret Key ist 64 Zeichen lang. Jeder Benutzer kann bis zu 5 Access Keys besitzen, was ausreicht, um ohne Ausfallzeit zu rotieren: den neuen Key erstellen, die Anwendungskonfiguration aktualisieren und dann den alten Key löschen. Die Zugangsdaten sind nicht an eine bestimmte Region oder ein bestimmtes Bucket gebunden; ein Schlüsselpaar funktioniert in allen Buckets, auf die der Benutzer zugreifen kann.

2.2 Endpoints und Regionen

Object Storage stellt die S3 API v2 Standard bereit, und Sie adressieren sie über einen regionsspezifischen Endpoint. Im Gegensatz zu AWS müssen Sie den Endpoint in jedem Client explizit festlegen, da die Standard-AWS-Endpoints nicht aufgelöst werden. Die folgende Tabelle listet die Service-Endpoints auf, auf die Ihr Code und das Terraform-Backend verweisen.

Wählen Sie den Endpoint, der zur Region passt, in der Sie das Bucket erstellen, und verwenden Sie ihn überall: in boto3, im S3-Backend-Block unten und bei jeder 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 Lifecycle-Regeln für die Ablaufzeit von Objekten; Lifecycle-Regeln können Objekte nicht in eine andere Speicherklasse überführen (es gibt keine kalte oder Archiv-Ebene).

3. Object Storage als Terraform State Backend

Da Object Storage S3-kompatibel ist, eignet es sich auch als Remote-State-Backend für Terraform. Dies löst das Problem aus Einheit 1.2: Der lokale Zustand übersteht weder den Wechsel zwischen Teammitgliedern noch den Einsatz eines CI-Runners. Die Speicherung des Zustands in einem Bucket stellt für jeden Pipeline-Lauf eine gemeinsame und dauerhafte Datenquelle bereit.

3.1 Backend-Konfiguration

Das s3-Backend benötigt den IONOS CLOUD-Endpunkt sowie dieselben Skip-Flags, die Sie für jede nicht-AWS-S3-Implementierung verwenden, da das Backend andernfalls versucht, die Konfiguration anhand von AWS-Konto- und Regionsregeln zu validieren, die hier nicht gelten.

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

Übergeben Sie den Access Key und den Secret Key an das Backend über Umgebungsvariablen (AWS_ACCESS_KEY_ID und AWS_SECRET_ACCESS_KEY), anstatt sie hart zu codieren. Der State-Bucket muss vor terraform init bereits existieren. Erstellen Sie ihn daher einmalig mit einer kleinen Bootstrap-Konfiguration oder mit ionosctl und verweisen Sie anschließend das Backend Ihres Haupt-Stacks darauf.

3.2 Warum dies für die Pipeline wichtig ist

Der State-Bucket enthält Ihre S3-Schlüssel und Datenbankverbindungszeichenketten innerhalb der Zustandsdatei. Beschränken Sie, wer darauf zugreifen kann. Ein praktisches Muster ist ein Bucket pro Umgebung, mit separaten Schlüsselpräfixen pro Stack, sodass eine Dev-Pipeline den Prod-Zustand nicht lesen kann. Dies fließt direkt in die CI/CD-Arbeit in Modul 3 ein, wo dieselben Anmeldeinformationen zu Pipeline-Secrets werden.

4. NFS Shared Storage

Wenn mehrere Server dieselben Dateien lesen und schreiben müssen, ist weder ein Block Storage-Volumen mit einzelner Zuordnung noch ein Object Store die passende Lösung. NFS bietet ein POSIX-Dateisystem, das parallel auf Linux-Clients eingehängt wird. Es wird über zwei Ressourcen bereitgestellt: ionoscloud_nfs_cluster definiert den Cluster, und ionoscloud_nfs_share definiert einen Share innerhalb dieses Clusters. Der gleiche asynchrone Lebenszyklus und die terraform destroy-Bereinigung gelten entsprechend.

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 in IONOS CLOUD unterstützt ausschließlich NFSv4.2. NFSv3 wird nicht unterstützt, daher werden Client-Tools oder Einträge in der fstab, die auf v3 festgelegt sind, beim Einhängen fehlschlagen. Die Clustergröße reicht von einem Minimum von 2 TiB bis zu einem Maximum von 42 TiB, wobei die gesamte bereitgestellte Kapazität voll nutzbar ist. Kontingente für Shares werden in MiB angegeben.

Verschlüsselung im Ruhezustand wird von der Plattform bereitgestellt. Verschlüsselung während der Übertragung ist für NFS nicht dokumentiert. Daher sollten sensible Daten auf einem privaten LAN platziert und auf Netzwerkisolierung statt auf TLS beim Einhängen vertraut werden. Das Cluster läuft im Active-Passive-Modus für hohe Verfügbarkeit und wird über eine private IP erreicht, die Sie im connections-Block zuweisen.

4.2 Einhängen des Shares

Nach dem Anwenden wird der Share von einem Linux-Client unter Verwendung der Cluster-IP und der Share-UUID eingehängt, die in der nfs_path-Ausgabe der Ressource zurückgegeben wird. Linux ist das unterstützte Client-Betriebssystem.

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

Root Squash wird unterstützt. Mappen Sie daher die UID und GID auf dem Share so, dass sie mit dem Anwendungsbenutzer übereinstimmen, der die Dateien liest und schreibt, wie durch die Argumente uid und gid oben gezeigt wird. Nicht übereinstimmende Berechtigungen sind die übliche Ursache für Fehler wegen verweigerter Berechtigungen unmittelbar nach einem erfolgreichen Mount.

5. Die richtige Speicherart im Code auswählen

Jede Speicherart entspricht einem anderen Zugriffsmuster. Eine falsche Wahl zeigt sich entweder als Einschränkung, gegen die Sie ankämpfen müssen, oder als eine Rechnung, die Sie nicht erwartet haben. Block Storage wird an genau einen Server angehängt und verhält sich wie eine lokale Festplatte: Verwenden Sie ihn für Datenbanken, Betriebssystemvolumes und jede Arbeitslast mit einem einzelnen Schreibzugriff. Object Storage wird über HTTP mit S3-Zugangsdaten erreicht und skaliert unabhängig von jeder VM: Verwenden Sie ihn für Benutzeruploads, Sicherungen, statische Assets und den Terraform-Zustand. NFS bietet gleichzeitigen POSIX-Zugriff über viele Linux-Clients: Verwenden Sie ihn nur, wenn mehrere Server tatsächlich ein Dateisystem teilen müssen.

Die folgende Tabelle fasst die Entscheidung auf der Ebene zusammen, die Sie beim Schreiben von Terraform benötigen.

Für TaskBoard lässt sich dies sauber auflösen. Das Datenvolumen des API-Servers ist Block Storage, an einen einzelnen Server angehängen und für den Arbeitsspeicherbereich dimensioniert. Dateianhänge werden in Object Storage abgelegt, da der Browser direkt mit vorab signierten URLs hochlädt und die API die Bytes nie weiterleitet. NFS wird im Basisaufbau von TaskBoard nicht verwendet; es ist das Muster, auf das Sie später zurückgreifen, wenn Sie eine Flotte von Workern hinzufügen, die ein Inhaltsverzeichnis teilen muss.

API-Referenz-Schnellkarte

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 (regionsspezifisch) NFS API Basis-URL: https://nfs.{region}.ionos.com Authentifizierung: Die Cloud API verwendet Authorization: Bearer <token>; Object Storage verwendet Access Key + Secret Key (AWS Signature)

Code Lab

Ziel: Deployment der Storage-Ebene von TaskBoard mit Terraform: ein Block Storage-Datenvolumen, das an den API-Server angehängt wird, und ein Object Storage-Bucket, dessen Zugangsdaten als sensible Werte ausgegeben werden.

Voraussetzungen:

• IONOS CLOUD-Konto mit API-Token (IONOS_TOKEN exportiert)
• Terraform 1.5+ mit dem ionos-cloud/ionoscloud-Provider
• Ein vorhandenes Rechenzentrum und ein API-Server (aus dem Labor der Einheit 2.1) oder diese werden inline erstellt

Schritt 1: Provider festpinnen

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

provider "ionoscloud" {}

Erwartete Ausgabe:

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

Schritt 2: Das Block Storage-Datenvolumen deklarieren

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: Den Object Storage-Bucket und den Schlüssel deklarieren

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

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

Erwartete Ausgabe:

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: Die sensiblen Zugangsdaten lesen

terraform output -raw s3_access_key
terraform output -raw s3_secret_key

Erwartete Ausgabe:

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

Schritt 7: Den Bucket mit einem S3-Client überprüfen

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

Erwartete Ausgabe:

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

Prüfliste:

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

Aufräumarbeiten:

terraform destroy -auto-approve

Häufige Fehler

Fehler von Entwicklerinnen und Entwicklern, die bei der Bereitstellung von Speicher auf IONOS CLOUD zu vermeiden sind:

1. Festpinnen eines Volumes an Zone 3, während der Server in Zone 1 oder 2 liegt

   • Problem: Ein in ZONE_3 erstelltes Volume kann nicht mit einem Compute-Server zusammengefasst werden, da Compute keine Zone 3 besitzt.
   • Ursache: Die Verfügbarkeitszonen von Block Storage sind Zone 1, Zone 2, Zone 3, Auto, aber Compute unterstützt nur Zone 1, Zone 2, Auto. Entwicklerinnen und Entwickler gehen davon aus, dass die Zonensätze übereinstimmen.
   • Lösung: Verwenden Sie availability_zone = "AUTO" sowohl auf dem Server als auch auf dem Volume, es sei denn, Sie haben einen bewussten Plan zum Festpinnen an eine Zone. Setzen Sie niemals ZONE_3 auf einem Server.

2. Senden des IONOS CLOUD Bearer Tokens an Object Storage

   • Problem: S3-Anfragen liefern 403 SignatureDoesNotMatch oder AccessDenied zurück, obwohl Ihr Cloud-API-Token gültig ist.
   • Ursache: 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: Erzeugen Sie Zugangsdaten 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. Einhängen eines NFS-Teils mit NFSv3

   • Problem: mount -t nfs -o vers=3 ... hängt oder schlägt fehl; der Share lehnt die Verbindung ab.
   • Ursache: IONOS CLOUD NFS unterstützt nur NFSv4.2. NFSv3 ist nicht verfügbar, daher werden keine v3-festgelegten Einhängeoptionen oder veraltete fstab-Einträge verhandelt.
   • Lösung: Hängen Sie ohne eine v3-Option ein (NFSv4.2 wird standardmäßig verhandelt) und richten Sie den Share uid/gid auf den Anwendungsnutzer ein, da root squash aktiv 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 einem einzelnen Server angehängt, haben eine Größe zwischen 1 GiB und 4 TiB, wobei der Speichertyp und die Zone zum Erstellungszeitpunkt festgelegt werden. Object Storage-Buckets und S3-Keys werden mit ionoscloud_s3_bucket und ionoscloud_s3_key deklariert, authentifiziert mit Access Key und Secret Key statt mit Ihrem Bearer Token, und dieselben Buckets dienen als Speicher für Ihren Terraform Remote State. NFS-Cluster und -Shares bieten gleichzeitigen NFSv4.2-Zugriff für Fälle, in denen viele Linux-Clients ein Dateisystem gemeinsam nutzen müssen. Die wiederkehrende Erkenntnis ist, dass die Einschränkungen, nicht die Ressourcen-Syntax, Ihr Design bestimmen: Zonen-Mismatches, das S3-Authentifizierungsmodell und die NFS-Protokollversion sind die Stellen, an denen in der Produktion Zeit 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; setzen Sie beide standardmäßig auf AUTO
• Object Storage authentifiziert mit Access Key + Secret Key über einen regionsspezifischen S3-Endpunkt, niemals mit dem IONOS CLOUD Bearer Token
• Object Storage-Buckets funktionieren als S3-kompatibles Terraform Remote-State-Backend, wenn die Validierungsskipp-Flags gesetzt sind
• NFS bietet geteilten 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 erstellt; Ausgabe als sensibel markiert.
• S3-Endpunkt: Regionsspezifische URL (zum Beispiel s3.eu-central-1.ionoscloud.com), die alle Object Storage-Clients explizit festlegen müssen.
• Remote-State-Backend: Ein geteilter, 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 Anpassung der Share uid/gid an den Anwendungsnutzer.

Nächste Schritte

Weiter lernen: Einheit 2.5: Bereitstellung von Datenbank- und Streaming-Diensten

Verwandte Themen:

• Einheit 1.2: Terraform Provider und Kernmuster
• Einheit 4.2: Object Storage Integration