Unité 2.4 : Provisionnement de stockage en tant que code

Introduction

Vous êtes en train de développer le niveau de stockage de TaskBoard, et chaque pièce d'état se trouve dans un endroit différent. Le serveur API a besoin d'un stockage de données persistant Volume 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 à un seul 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 Node.

Les trois sont provisionnés de la même manière : des ressources de Terraform déclaratives contre l'IONOS API, 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. Block Storage et Compute n'ont pas les mêmes zones de disponibilité. Object Storage n'utilise pas du tout votre jeton porteur. NFS parle uniquement d'une 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. Block Storage Volumes avec Terraform

Block Storage est provisionné en tant que 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 asynchrones. 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 minimale de Volume est de 1 GiB et la taille maximale est de 4096 GiB (4 To) pour chaque type de Block Storage. Des volumes plus grands peuvent être demandés via le support 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éclarer et attacher un Volume

La configuration suivante crée un disque de données Premium SSD Volume et l'attache au serveur TaskBoard API. 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 pouvez ignorer 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. Le SSD Premium offre le plus haut IOPS par Volume, le SSD Standard échange les performances pour le coût, et le HDD est l'option de disque rotatif 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. Le 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, car un Volume et le serveur auquel il est connecté se trouvent dans le même centre de données, mais sont placés par des paramètres de zone indépendants. Si vous attribuez une zone à un Volume 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écurisée est AUTO sur le serveur et le Volume, sauf si vous avez une exigence spécifique de fixation 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 un seul VM. Un serveur peut transporter à la fois des volumes SSD et HDD en même temps. La limite par VM Volume dépend du type : SSD Premium permet d'attacher jusqu'à 4 volumes à un VM, tandis que HDD et SSD Standard permettent jusqu'à 24. Planifiez des dispositions multi-Volume contre la limite du type que vous choisissez.

1.3 Contexte de chiffrement et de durabilité

Block Storage offre un stockage à double redondance : les données sont écrites sur deux serveurs de stockage, chacun protégé par RAID, pour une redondance au niveau de la plateforme. Le chiffrement au niveau REST pour les volumes logiques utilise l'algorithme AES-XTS. Vous ne configurez ni l'un ni l'autre dans la ressource 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. Object Storage Buckets et clés d'accès

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 : Object Storage n'authentifie pas avec votre jeton IONOS. Il met en œuvre l'AWS S3 API 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 cloud API.

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 Object Storage locataires 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 afin que Terraform masque les valeurs de la sortie CLI et des journaux CI ; les valeurs sont toujours stockées dans l'état, donc protégez le backend de l'é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 détruisez 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 de 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 d'objet maximale 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 transiter les objets vers une autre classe de stockage (il n'y a pas de niveau froid ou d'archive). S3, S3, et Object Storage sont utilisés pour assurer la haute disponibilité :

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

Puisque Object Storage est compatible avec 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 et les mêmes flags de saut 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. Object Storage, Terraform et S3 sont essentiels à cette configuration.

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 configurez-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, de sorte qu'un pipeline de développement ne puisse pas lire l'état de production. Cela se poursuit directement dans le travail CI/CD dans le Module 3, où les mêmes informations d'identification deviennent des secrets de pipeline.

4. NFS Stockage partagé

Lorsque plusieurs serveurs doivent lire et écrire les mêmes fichiers, ni un Block Storage Volume à attachement unique ni un magasin d'objets ne convient parfaitement. NFS vous offre un système de fichiers POSIX monté de manière concurrente sur des clients Linux. Il est provisionné en deux ressources : ionoscloud_nfs_cluster définit le Cluster, et ionoscloud_nfs_share définit un partage à l'intérieur de celui-ci. Le même cycle de vie asynchrone et la suppression terraform destroy 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 parle uniquement NFSv4.2. NFSv3 n'est pas pris en charge, donc tout outil de client ou entrée fstab fixée sur v3 échouera lors du montage. La taille de 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 niveau de REST 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 LAN privé et comptez sur l'isolement réseau plutôt que sur le chiffrement TLS sur le montage. Le Cluster fonctionne en mode haute disponibilité actif-passif et est accessible via un IP privé 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 le Cluster IP et l'UUID de 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

Le squash Root est pris en charge, vous pouvez donc mapper l'UID et le GID sur le partage pour qu'ils correspondent à l'utilisateur de l'application qui lit et écrit les fichiers, comme le montrent les arguments uid et gid ci-dessus. La propriété non correspondante est la cause la plus courante des erreurs de refus d'accès 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 à laquelle vous devez faire face, soit par une facture que vous n'avez pas prévue. 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. Le Object Storage est accessible via le HTTP avec des informations d'identification S3 et est mis à l'échelle de manière indépendante de tout 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 sur de nombreux 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. La sauvegarde de données du serveur API est Block Storage, attachée à un serveur, dimensionnée pour l'ensemble de travail. Les pièces jointes vont à Object Storage car le navigateur télécharge directement avec des URL pré-signées et le API n'intercepte jamais 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.

API Référence Carte Rapide

Points de terminaison clés API pour la mise à l'échelle du stockage :

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

Laboratoire de code

Objectif : Déployer le niveau de stockage de TaskBoard avec Terraform : un centre de données Block Storage avec un stockage Volume attaché au serveur API et un seau 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 fournisseur ionos-cloud/ionoscloud
• Un centre de données existant et un serveur API (à partir 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" {}

Sortie attendue :

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

Étape 2 : Déclarer les données Block Storage 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"
}

Étape 3 : Déclarer le Object Storage bucket 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

terraform init
terraform plan -out=storage.plan

Le texte à traduire est vide, veuillez fournir le texte à traduire.

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

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

terraform output -raw s3_access_key
terraform output -raw s3_secret_key

Sortie attendue :

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

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

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 texte à traduire est vide, veuillez fournir le texte à traduire.

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

Liste de validation :

• [ ] Volume affiche Creation complete et est attaché au serveur API
• [ ] terraform output renvoie des entrées (sensitive value) masqué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 porteur

Nettoyage :

terraform destroy -auto-approve

Erreurs courantes

Erreurs de développement à éviter lors de la mise à disposition de 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é de 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 : Utiliser availability_zone = "AUTO" sur le serveur et le Volume, à moins d'avoir un plan d'épinglage de zone délibéré, et ne jamais définir ZONE_3 sur un serveur.

2. Envoyer le jeton IONOS bearer à Object Storage

   • Problème : Les requêtes S3 renvoient 403 SignatureDoesNotMatch ou AccessDenied, même si votre jeton de cloud API est valide.
   • Pourquoi cela se produit-il : Object Storage met en œuvre l'AWS S3 API 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érer des informations d'identification avec ionoscloud_s3_key, définir AWS_ACCESS_KEY_ID et AWS_SECRET_ACCESS_KEY, et passer toujours l'URL du point de terminaison IONOS S3 explicite.

3. Monter un partage NFS avec NFSv3

   • Problème : mount -t nfs -o vers=3 ... est suspendu ou échoue ; le partage refuse la connexion.
   • Pourquoi cela se produit-il : IONOS NFS prend en charge NFSv4.2 uniquement. NFSv3 n'est pas disponible, donc toute option de montage v3 ou toute entrée fstab héritée ne négociera pas.
   • Correction : Monter sans option v3 (NFSv4.2 négocie par défaut) et aligner les informations d'identification du partage uid/gid avec l'utilisateur de l'application, puisque la mise en squash de Root 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 entièrement dans Terraform et les connecter à une application. Les volumes Block Storage sont attachés à un seul serveur avec ionoscloud_volume, de 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 Object Storage et les clés S3 sont déclarés avec ionoscloud_s3_bucket et ionoscloud_s3_key, authentifiés avec une clé d'accès et une clé secrète plutôt qu'avec votre jeton porteur, et les mêmes buckets supportent votre état distant Terraform. Les grappes NFS et les partages 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 incompatibilités 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 de 1 GiB à 4 TiB ; le type de stockage et la zone sont immuables après la création
• Block Storage prend en charge la zone 1, 2, 3 et Auto, mais Compute n'a pas de zone 3 ; défaut les deux sur AUTO
• Object Storage s'authentifie avec une clé d'accès + une clé secrète sur un point de terminaison S3 spécifique à la région, et non le jeton porteur IONOS
• Les buckets Object Storage fonctionnent comme un backend d'état distant Terraform compatible avec S3 avec les flags de 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 Block Storage iSCSI Volume attaché à un serveur.
• ionoscloud_s3_key : ressource Terraform qui crée une paire de clé d'accès et de clé secrète 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 Object Storage configuré avec le type de backend s3.
• Squash Root : comportement NFS qui mappe le Root client à une identité non privilégiée ; nécessite d'aligner les partages uid/gid avec l'utilisateur de l'application.

Prochaines étapes

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

Sujets connexes :

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