Unité 2.4 : Provisionnement de stockage en tant que code

Introduction

Vous construisez le niveau de stockage de TaskBoard, et chaque pièce d'état atterrit dans un endroit différent. Le serveur API a besoin d'un volume de données persistant qui survive aux redémarrages et se comporte comme un disque local. Les pièces jointes de fichiers téléchargées par les utilisateurs appartiennent à un magasin d'objets accessible via HTTP avec des informations d'identification S3, et non fixées à une seule VM. Et si vous exécutez plus tard plusieurs workers qui lisent tous le même ensemble de fichiers, vous voulez un système de fichiers partagé plutôt que des copies sur chaque nœud.

Les trois sont provisionnés de la même manière : des ressources Terraform déclaratives contre l'API IONOS CLOUD, avec le même modèle d'exécution asynchrone et d'attente que vous avez utilisé depuis l'Unité 1.1. Les différences qui vous posent problème sont les contraintes. Le Block Storage et le Compute n'ont pas les mêmes zones de disponibilité. L'Object Storage n'utilise pas du tout votre jeton porteur. Le NFS ne parle qu'une seule version de protocole. Cette unité présente chaque type de stockage au niveau du code et montre où ces contraintes modifient ce que vous écrivez.

1. Volumes de stockage en bloc avec Terraform

Le stockage en bloc est provisionné sous la forme de ionoscloud_volume et se comporte comme un périphérique de bloc iSCSI attaché à un serveur. Vous déclarez la taille, le type de stockage et la zone de disponibilité, et Terraform gère la mise en service et l'attachement asynchromes. Un volume est créé à l'intérieur d'un centre de données et lié à un seul serveur via l'attribut server_id.

La taille de volume minimale est de 1 GiB et la taille maximale est de 4096 GiB (4 To) pour chaque type de stockage en bloc. Des volumes plus grands peuvent être demandés via le support d'IONOS CLOUD. Le type de stockage ne peut pas être modifié après la mise en service, donc choisissez-le correctement au moment de la création plutôt que de planifier une conversion ultérieure.

1.1 Déclaration et attachement d'un volume

La configuration suivante crée un volume de données SSD Premium et l'attache au serveur API TaskBoard. Les image_name et image_password (ou ssh_key_path) sont obligatoires lorsque le volume est amorçable ; pour un disque de données pur, vous fournissez un licence_type à la place et vous omettez l'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"
}

Le disk_type accepte les variantes de technologie de stockage exposées par Block Storage : HDD, SSD Premium, et SSD Standard. SSD Premium offre le plus grand nombre d'IOPS par volume, SSD Standard échange les performances pour le coût, et HDD est l'option tournante la moins chère. Les trois ont une limite de 4 To (4096 Gio) par volume avec un plancher de 1 Gio.

1.2 Le piège de la zone de disponibilité

Les zones de disponibilité de Block Storage ne sont pas les mêmes que les zones de disponibilité de Compute, et c'est l'erreur de provisionnement la plus courante dans le niveau de stockage. Block Storage prend en charge Zone 1, Zone 2, Zone 3, et Auto. Les serveurs Compute ne prennent en charge que les zones 1, 2, et Auto. La zone 3 existe pour le stockage, mais il n'y a pas de zone 3 pour le calcul.

Cela est important parce qu'un volume et le serveur auquel il est attaché se trouvent dans le même centre de données, mais sont placés par des paramètres de zone indépendants. Si vous attachez un volume à une zone qui ne correspond pas à votre stratégie de placement de serveur, vous restreignez la planification sans bénéfice. La valeur par défaut sûre est AUTO sur le serveur et le volume, à moins que vous n'ayez une exigence spécifique d'attache de zone.

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

Les volumes peuvent être mélangés à travers les types sur une seule VM. Un serveur peut transporter à la fois des volumes SSD et HDD en même temps. Une VM prend en charge jusqu'à 24 volumes attachés de n'importe quel mélange de types de stockage ; le décompte est partagé entre tous les types, et non par type. Planifiez des dispositions multi-volumes contre ce plafond de 24 volumes.

1.3 Contexte de chiffrement et de durabilité

Le Block Storage offre un stockage redondant double : les données sont écrites sur deux serveurs de stockage, chacun protégé par RAID, pour la redondance au niveau de la plateforme. Le chiffrement au repos pour les volumes logiques utilise l'algorithme AES-XTS. Vous ne configurez ni l'un ni l'autre dans la ressource de volume ; les deux sont des propriétés de la couche de stockage de la plateforme, donc votre Terraform se concentre sur la taille, le type et le placement.

2. Objets Stockage et clés d'accès

Le Object Storage est provisionné avec ionoscloud_s3_bucket, et ses informations d'accès sont créées avec ionoscloud_s3_key. La différence critique par rapport à toutes les autres ressources de ce cours : le Object Storage n'authentifie pas avec votre jeton IONOS CLOUD. Il met en œuvre l'API AWS S3 et s'authentifie avec une clé d'accès et une clé secrète. Votre application, votre pipeline CI, et tout client S3 utilisent ces clés, et non le jeton d'API cloud.

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

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

Les noms de bucket doivent être uniques à l'échelle mondiale dans tous les locataires d'Object Storage et doivent être compris entre 3 et 63 caractères. Traitez le nom comme une étiquette DNS, en minuscules avec des tirets, et supposez que les noms évidents sont déjà pris. Une collision de nom apparaît comme une erreur de création au moment de l'application, et non au moment de la planification.

2.1 Sortie des informations d'identification en tant que valeurs sensibles

La ressource ionoscloud_s3_key produit une clé d'accès et une clé secrète. La clé secrète ne doit jamais apparaître dans les journaux ou la sortie en clair. Marquez les sorties sensitive = true pour que Terraform les masque de la sortie CLI et des journaux CI ; les valeurs vivent toujours dans l'état, donc protégez le backend d'état en conséquence.

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
}

Une clé d'accès est de 92 caractères et une clé secrète est de 64 caractères. Chaque utilisateur peut détenir jusqu'à 5 clés d'accès, ce qui est suffisant pour les faire pivoter sans temps d'arrêt : créez la nouvelle clé, mettez à jour la configuration de votre application, puis supprimez l'ancienne clé. Les informations d'identification ne sont pas liées à une région ou un bucket spécifique ; une paire de clés fonctionne sur tous les buckets que l'utilisateur peut atteindre.

2.2 Points de terminaison et régions

Object Storage expose la norme S3 API v2, et vous y accédez par l'intermédiaire d'un point de terminaison spécifique à une région. Contrairement à AWS, vous devez définir explicitement le point de terminaison dans chaque client, car les points de terminaison AWS par défaut ne seront pas résolus. Le tableau suivant répertorie les points de terminaison du service que votre code et le backend Terraform référenceront.

Sélectionnez le point de terminaison correspondant à la région où vous créez le bucket et réutilisez-le partout : dans boto3, dans le bloc backend S3 ci-dessous, et dans toute génération d'URL pré-signée. Les connexions utilisent TLS, avec TLS 1.2 et 1.3 pris en charge. La taille maximale d'un objet est de 5 To. Object Storage offre une seule classe de stockage, STANDARD, et un bucket prend en charge jusqu'à 1000 règles de cycle de vie pour l'expiration des objets ; les règles de cycle de vie ne peuvent pas transmettre des objets à une autre classe de stockage (il n'y a pas de niveau froid ou d'archive).

3. Object Storage en tant que backend d'état Terraform

Puisque Object Storage est compatible S3, il sert également de backend d'état distant pour Terraform. Cela résout le problème que vous avez rencontré dans l'Unité 1.2 : l'état local ne survit pas à travers une équipe ou un exécuteur CI. Le stockage de l'état dans un bucket donne à chaque exécution de pipeline une source de vérité partagée et durable.

3.1 Configuration du backend

Le backend s3 nécessite le point de terminaison IONOS CLOUD et les mêmes flags de skip que vous utilisez pour toute implémentation S3 non-AWS, car le backend tente sinon de valider contre les règles de compte et de région AWS qui ne s'appliquent pas.

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

Fournissez la clé d'accès et la clé secrète au backend via des variables d'environnement (AWS_ACCESS_KEY_ID et AWS_SECRET_ACCESS_KEY) plutôt que de les coder en dur. Le bucket d'état doit déjà exister avant terraform init, donc provisionnez-le une fois avec une petite configuration de démarrage ou avec ionosctl, puis pointez le backend de votre pile principale vers celui-ci.

3.2 Pourquoi cela est important pour le pipeline

Le bucket d'état contient vos clés secrètes S3 et les chaînes de connexion de base de données à l'intérieur du fichier d'état. Restreignez qui peut le lire. Un modèle pratique est un bucket par environnement, avec des préfixes de clé séparés par pile, afin qu'un pipeline de développement ne puisse pas lire l'état de production. Cela se poursuit directement dans le travail CI/CD du Module 3, où les mêmes informations d'identification deviennent des secrets de pipeline.

4. Stockage partagé NFS

Lorsque plusieurs serveurs doivent lire et écrire les mêmes fichiers, ni un volume de stockage Block Storage à attachement unique ni un magasin d'objets ne convient parfaitement. NFS vous offre un système de fichiers POSIX monté de manière concurrentielle sur des clients Linux. Il est provisionné en deux ressources : ionoscloud_nfs_cluster définit le Cluster, et ionoscloud_nfs_share définit une partage à l'intérieur de celui-ci. Le même cycle de vie asynchrone et terraform destroy nettoyage s'appliquent.

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 Contraintes de protocole et de capacité

NFS sur IONOS CLOUD parle uniquement NFSv4.2. NFSv3 n'est pas pris en charge, donc tout outil client ou entrée fstab fixée sur la version 3 échouera au montage. La taille du Cluster va d'un minimum de 2 To à un maximum de 42 To, avec une capacité entièrement utilisable. Les quotas de partage sont exprimés en MiB.

Le chiffrement au repos est fourni par la plateforme. Le chiffrement en transit n'est pas documenté pour NFS, donc pour les données sensibles, gardez le partage sur un réseau LAN privé et comptez sur l'isolement réseau plutôt que sur TLS pour le montage. Le Cluster s'exécute en mode haute disponibilité actif-passif et est accessible via une adresse IP privée que vous attribuez dans le bloc connections.

4.2 Montage du partage

Après application, le partage est monté à partir d'un client Linux en utilisant l'adresse IP du Cluster et l'UUID du partage renvoyé dans la sortie nfs_path de la ressource. Linux est le système d'exploitation client pris en charge.

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

La compression de Root est prise en charge, donc mappez l'UID et le GID sur le partage pour correspondre à l'utilisateur de l'application qui lit et écrit les fichiers, comme indiqué par les arguments uid et gid ci-dessus. La propriété non correspondante est la cause habituelle des erreurs de refus de permission immédiatement après un montage réussi.

5. Choix du stockage approprié dans le code

Chaque type de stockage correspond à un modèle d'accès différent, et le choix erroné se manifeste soit par une contrainte avec laquelle vous devez lutter, soit par une facture que vous n'attendiez pas. Le Block Storage est attaché à exactement un serveur et se comporte comme un disque local : utilisez-le pour les bases de données, les volumes du système d'exploitation et toute charge de travail à un seul auteur. L'Object Storage est accessible via HTTP avec des informations d'identification S3 et peut être mis à l'échelle de manière indépendante de toute VM : utilisez-le pour les téléchargements d'utilisateurs, les sauvegardes, les ressources statiques et l'état de Terraform. Le NFS offre un accès POSIX concurrent à plusieurs clients Linux : utilisez-le uniquement lorsque plusieurs serveurs doivent réellement partager un système de fichiers.

Le tableau suivant résume la décision au niveau dont vous avez besoin lors de l'écriture de Terraform.

Pour TaskBoard, cela se résout de manière claire. Le volume de données du serveur API est un Block Storage, attaché à un serveur, dimensionné pour l'ensemble de travail. Les pièces jointes sont stockées dans l'Object Storage car le navigateur télécharge directement avec des URL pré-signées et l'API ne proxy les octets. Le NFS n'est pas utilisé dans la version de base de TaskBoard ; c'est le modèle que vous atteignez plus tard si vous ajoutez une flotte de travailleurs qui doivent partager un répertoire de contenu.

Carte rapide de référence de l'API

Points de terminaison API clés pour la provision de stockage :

URL de base de l'API Cloud : https://api.ionos.com/cloudapi/v6 Point de terminaison S3 d'Object Storage : https://s3.eu-central-4.ionoscloud.com (spécifique à la région) URL de base de l'API NFS : https://nfs.{region}.ionos.com Authentification : L'API Cloud utilise Authorization: Bearer <token> ; Object Storage utilise Access Key + Secret Key (signature AWS)

Laboratoire de code

Objectif : Déployer le niveau de stockage de TaskBoard avec Terraform : un volume de données de stockage en bloc attaché au serveur API et un seau de Object Storage avec des informations d'accès en tant que valeurs sensibles.

Prérequis :

• Compte IONOS CLOUD avec jeton API (IONOS_TOKEN exporté)
• Terraform 1.5+ avec le ionos-cloud/ionoscloud fournisseur
• Un centre de données existant et un serveur API (du laboratoire 2.1) ou créez-les en ligne

Étape 1 : Épingler le fournisseur

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

provider "ionoscloud" {}

Le texte attendu est le suivant :

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

Étape 2 : Déclarer le volume de données de Block Storage

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

Étape 3 : Déclarer le bucket Object Storage et la clé

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
}

Étape 4 : Initialisation et planification

Pour initialiser et planifier votre infrastructure informatique, vous devez prendre en compte plusieurs facteurs importants. Tout d'abord, vous devez déterminer vos besoins en termes de stockage, de calcul et de mise à l'échelle. Ensuite, vous devez choisir le modèle de cloud computing qui convient le mieux à vos besoins, qu'il s'agisse d'un centre de données virtuel, d'un serveur cloud ou d'un serveur dédié.

Il est également important de considérer la haute disponibilité et la disponibilité de la plateforme lors de la planification de votre infrastructure. Cela signifie que vous devez prendre en compte les mécanismes de sauvegarde, de protection des données et de reprise après sinistre pour garantir que vos données soient en sécurité et accessibles en tout temps.

En outre, vous devez réfléchir à l'évolutivité et à la mise à l'échelle en temps réel pour répondre aux fluctuations de la charge de travail. Cela peut être réalisé en utilisant des conteneurs, des images Docker et une orchestration de conteneurs pour garantir une mise à l'échelle efficace.

Enfin, il est essentiel de prendre en compte la sécurité et le contrôle d'accès pour protéger vos données et votre infrastructure. Cela peut être réalisé en utilisant des mécanismes d'authentification, d'autorisation et de chiffrement pour garantir que seules les personnes autorisées aient accès à vos ressources.

En suivant ces étapes, vous pouvez créer une infrastructure informatique solide et évolutivité qui répond à vos besoins spécifiques et garantit une haute disponibilité et une sécurité optimales.

terraform init
terraform plan -out=storage.plan

Le texte attendu est le suivant :

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

Étape 5 : Appliquer

Pour appliquer les modifications, vous devez suivre les étapes suivantes :

1. Assurez-vous d'avoir sauvegardé vos données avant de procéder à l'application des modifications.
2. Mettez à jour votre système pour vous assurer que vous utilisez la dernière version.
3. Réinitialisez les paramètres par défaut si nécessaire.

L'application des modifications peut prendre quelques minutes, veuillez patienter. Les étapes ci-dessus sont cruciales pour une mise à jour réussie. Il est important de noter que la mise à l'échelle en temps réel et la haute disponibilité sont essentielles pour une infrastructure informatique solide.

terraform apply storage.plan

Sortie attendue :

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.

Étape 6 : Lire les informations d'identification sensibles

Lisez attentivement les informations d'identification sensibles pour vous assurer que vous avez compris les étapes suivantes. Il est essentiel de gérer ces informations avec soin pour éviter toute faille de sécurité.

terraform output -raw s3_access_key
terraform output -raw s3_secret_key

Le texte attendu est le suivant :

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

Étape 7 : Vérifier le bucket avec un client S3

Pour vérifier le bucket, vous pouvez utiliser un client S3. Il est important de s'assurer que le bucket est correctement configuré et accessible. Vous pouvez utiliser des outils tels que les API ou des interfaces de ligne de commande pour interagir avec le bucket et vérifier son contenu. Assurez-vous de suivre les meilleures pratiques de sécurité pour protéger vos données et votre bucket.

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

Le résultat attendu :

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

Liste de vérification de validation :

• [ ] Le Volume affiche Creation complete et est attaché au serveur API
• [ ] terraform output renvoie des entrées (sensitive value) rédigées sans -raw
• [ ] Le client S3 répertorie le bucket en utilisant la clé d'accès + la clé secrète, et non le jeton bearer

Nettoyage :

terraform destroy -auto-approve

Erreurs courantes

Les erreurs des développeurs à éviter lors de la mise à disposition du stockage sur IONOS CLOUD :

1. Épingler un volume à la zone 3 alors que le serveur est en zone 1 ou 2

   • Problème : Un volume créé dans ZONE_3 ne peut pas être co-localisé avec un serveur de calcul, car Compute n'a pas de zone 3.
   • Pourquoi cela se produit-il : Les zones de disponibilité du Block Storage sont Zone 1, Zone 2, Zone 3, Auto, mais Compute ne prend en charge que Zone 1, Zone 2, Auto. Les développeurs supposent que les ensembles de zones correspondent.
   • Correction : Utilisez availability_zone = "AUTO" sur le serveur et le volume, à moins que vous n'ayez un plan d'épinglage de zone délibéré, et ne définissez jamais ZONE_3 sur un serveur.

2. Envoyer le jeton IONOS CLOUD bearer à Object Storage

   • Problème : Les requêtes S3 renvoient 403 SignatureDoesNotMatch ou AccessDenied même si votre jeton d'API cloud est valide.
   • Pourquoi cela se produit-il : Object Storage met en œuvre l'API AWS S3 et s'authentifie avec une clé d'accès et une clé secrète. Le jeton bearer utilisé pour api.ionos.com n'est pas accepté par le point de terminaison S3.
   • Correction : Générez des informations d'identification avec ionoscloud_s3_key, définissez AWS_ACCESS_KEY_ID et AWS_SECRET_ACCESS_KEY, et transmettez toujours l'URL du point de terminaison S3 IONOS CLOUD explicite.

3. Monter une partage NFS avec NFSv3

   • Problème : mount -t nfs -o vers=3 ... se bloque ou échoue ; le partage refuse la connexion.
   • Pourquoi cela se produit-il : IONOS CLOUD NFS prend en charge NFSv4.2 uniquement. NFSv3 n'est pas disponible, donc toute option de montage épinglée v3 ou toute entrée fstab héritée ne négociera pas.
   • Correction : Montez sans option v3 (NFSv4.2 négocie par défaut) et alignez le partage uid/gid avec l'utilisateur de l'application, puisque la réduction des privilèges racine est en vigueur :

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

Résumé

Vous pouvez maintenant provisionner les trois niveaux de stockage IONOS CLOUD entièrement dans Terraform et les intégrer à une application. Les volumes de Block Storage sont attachés à un seul serveur avec ionoscloud_volume, taille comprise entre 1 GiB et 4 TiB, avec le type de stockage et la zone fixés au moment de la création. Les buckets d'Object Storage et les clés S3 sont déclarés avec ionoscloud_s3_bucket et ionoscloud_s3_key, authentifiés avec Access Key et Secret Key plutôt qu'avec votre jeton bearer, et les mêmes buckets supportent l'état distant de Terraform. Les clusters et partages NFS offrent un accès NFSv4.2 concurrent pour les cas où de nombreux clients Linux doivent partager un système de fichiers. La leçon récurrente est que les contraintes, et non la syntaxe des ressources, décident de votre conception : les erreurs de zone, le modèle d'authentification S3 et la version du protocole NFS sont où le temps de production est perdu.

Points clés :

• ionoscloud_volume provisionne Block Storage à partir de 1 GiB à 4 TiB ; le type de stockage et la zone sont immuables après création
• Block Storage prend en charge la zone 1, 2, 3 et Auto, mais Compute n'a pas de zone 3 ; définissez les deux sur AUTO par défaut
• Object Storage s'authentifie avec Access Key + Secret Key sur un point de terminaison S3 spécifique à la région, jamais le jeton bearer IONOS CLOUD
• Les buckets d'Object Storage fonctionnent comme un backend d'état distant Terraform compatible S3 avec les flags skip-validation définis
• NFS fournit un stockage partagé NFSv4.2 allant de 2 TiB à 42 TiB ; NFSv3 n'est pas pris en charge

Terminologie importante :

• ionoscloud_volume : Ressource Terraform pour un volume iSCSI Block Storage attaché à un serveur.
• ionoscloud_s3_key : Ressource Terraform qui crée une paire de clés Access Key et Secret Key pour Object Storage ; sortie comme sensible.
• Point de terminaison S3 : URL spécifique à la région (par exemple s3.eu-central-1.ionoscloud.com) que tous les clients Object Storage doivent définir explicitement.
• Backend d'état distant : Un magasin partagé et durable pour l'état Terraform ; un bucket d'Object Storage configuré avec le type de backend s3.
• Root squash : Comportement NFS qui mappe la racine du client à une identité non privilégiée ; nécessite d'aligner le partage uid/gid avec l'utilisateur de l'application.

Prochaines étapes

Continuer l'apprentissage : Unité 2.5 : Provisionnement de bases de données et de services de diffusion

Sujets connexes :

• Unité 1.2 : Fournisseur Terraform et modèles de base
• Unité 4.2 : Intégration d'Object Storage