Unité 2.4 : Provisionnement du stockage en tant que code

Introduction

Vous êtes en train de construire la couche de stockage de TaskBoard, et chaque élément d'état est stocké à un endroit différent. Le serveur API a besoin d'un volume de données persistant qui survit aux redémarrages et qui se comporte comme un disque local. Les pièces jointes de fichiers téléversées par les utilisateurs doivent être stockées dans un store d'objets accessible via HTTP avec des identifiants S3, et non rattachées à une seule VM. Et si vous exécutez ultérieurement plusieurs workers qui lisent tous le même ensemble de fichiers, vous souhaitez 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 via l'API IONOS CLOUD, avec le même modèle asynchrone de création et d'attente que vous utilisez depuis l'Unité 1.1. Les différences qui posent problème sont les contraintes. Block Storage et Compute ne partagent pas les mêmes zones de disponibilité. Object Storage n'utilise pas du tout votre jeton bearer. NFS ne prend en charge qu'une seule version de protocole. Cette unité examine chaque type de stockage au niveau du code et montre où ces contraintes modifient ce que vous écrivez.

1. Volumes de Block Storage avec Terraform

Block Storage est provisionné sous forme de ionoscloud_volume et se comporte comme un périphérique bloc iSCSI attaché à un serveur. Vous déclarez la taille, le type de stockage et la zone de disponibilité, et Terraform gère le provisionnement asynchrone et l'attachement. Un volume est créé à l'intérieur d'un datacenter et lié à un serveur unique via l'attribut server_id.

La taille minimale d'un volume est de 1 GiB et la taille maximale est de 4096 GiB (4 TiB) pour tous les types de Block Storage. Des volumes plus grands peuvent être demandés auprès du support IONOS CLOUD. Le type de stockage ne peut pas être modifié après le provisionnement, il convient donc de le choisir correctement au moment de la création plutôt que de prévoir 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 attributs image_name et image_password (ou ssh_key_path) sont requis lorsque le volume est amorçable ; pour un disque de données pur, vous fournissez à la place un licence_type et 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 haut débit IOPS par volume, SSD Standard sacrifie les performances au profit du coût, et HDD est l'option à disques rotatifs la moins chère. Les trois plafonnent à 4 TiB (4096 GiB) par volume, avec un minimum de 1 GiB.

1.2 Le piège des zones de disponibilité

Les zones de disponibilité de Block Storage ne sont pas le même ensemble que les zones de disponibilité de Compute, et c'est l'erreur de provisionnement la plus courante dans la couche 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.

C'est important car un volume et le serveur auquel il est rattaché se trouvent dans le même datacenter, mais sont placés par des paramètres de zone indépendants. Si vous fixez un volume à une zone qui ne correspond pas à votre stratégie de placement des serveurs, vous restreignez l'ordonnancement sans aucun avantage. La valeur par défaut sûre est AUTO à la fois sur le serveur et sur 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 combinés entre différents types sur une seule VM. Un serveur peut porter à la fois des volumes SSD et HDD. Une VM prend en charge jusqu'à 24 volumes attachés, quelle que soit la combinaison de types de stockage ; ce nombre est partagé entre tous les types, et non par type. Planifiez les configurations à plusieurs volumes en tenant compte de cette limite de 24 volumes.

1.3 Contexte du chiffrement et de la durabilité

Block Storage offre un stockage à double redondance : les données sont écrites sur deux serveurs de stockage, chacun protégé par RAID, pour assurer 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 volume ; les deux sont des propriétés de la couche de stockage de la plateforme, de sorte que votre configuration Terraform reste centrée sur la taille, le type et le placement.

2. Bacs Object Storage et clés d'accès

Object Storage est provisionné avec ionoscloud_s3_bucket, et ses identifiants d'accès sont générés avec ionoscloud_s3_key. La différence fondamentale par rapport à toutes les autres ressources de ce cours : Object Storage ne s'authentifie pas avec votre jeton bearer IONOS CLOUD. Il implémente l'API AWS S3 et s'authentifie à l'aide d'une Access Key et d'une Secret Key. Votre application, votre pipeline CI et tout client S3 utilisent ces clés, jamais 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 buckets doivent être uniques au niveau mondial pour tous les locataires Object Storage et doivent comporter 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à utilisés. Un conflit de nom se manifeste par un échec de création lors de l'application, et non lors de la planification.

2.1 Sortie des identifiants en tant que valeurs sensibles

La ressource ionoscloud_s3_key génère une clé d'accès et une clé secrète. La clé secrète ne doit jamais apparaître dans les journaux ou dans la sortie en clair. Marquez les sorties sensitive = true afin que Terraform les masque dans la sortie de l'interface en ligne de commande et dans les journaux CI ; les valeurs restent présentes dans l'état, protégez donc 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 comporte 92 caractères et une clé secrète en comporte 64. Chaque utilisateur peut détenir jusqu'à 5 clés d'accès, ce qui est suffisant pour effectuer une rotation sans interruption de service : créez la nouvelle clé, mettez à jour la configuration de votre application, puis supprimez l'ancienne clé. Les identifiants ne sont pas liés à une région ou à un seau spécifique ; une paire de clés fonctionne sur tous les seaux accessibles par l'utilisateur.

2.2 Points d'accès et régions

Object Storage expose l'API S3 v2 standard, et vous y accédez via un point d'accès spécifique à une région. Contrairement à AWS, vous devez définir explicitement le point d'accès dans chaque client, car les points d'accès par défaut d'AWS ne se résolvent pas. Le tableau suivant répertorie les points d'accès du service que votre code et votre backend Terraform référenceront.

Choisissez le point d'accès correspondant à la région où vous créez le seau et réutilisez-le partout : dans boto3, dans le bloc de backend S3 ci-dessous, et dans toute génération d'URL présignées. Les connexions utilisent TLS, avec prise en charge de TLS 1.2 et 1.3. La taille maximale d'un objet est de 5 To. Object Storage propose une seule classe de stockage, STANDARD, et un seau 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 transférer les objets vers une autre classe de stockage (il n'existe pas de niveau froid ou d'archivage).

3. Object Storage en tant qu'arrière-plan d'état Terraform

Étant donné qu'Object Storage est compatible avec S3, il sert également d'arrière-plan d'état distant pour Terraform. Cela résout le problème rencontré dans l'Unité 1.2 : l'état local ne survit pas au sein d'une équipe ou d'un exécuteur CI. Le stockage de l'état dans un seau offre à chaque exécution de pipeline une source de vérité partagée et durable.

3.1 Configuration de l'arrière-plan

L'arrière-plan s3 nécessite le point de terminaison IONOS CLOUD et les mêmes drapeaux de saut que ceux utilisés pour toute implémentation S3 non AWS, car l'arrière-plan tente sinon de valider 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, il faut donc le provisionner une seule fois avec une configuration de démarrage minimale ou avec ionosctl, puis orienter 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 vos chaînes de connexion à la base de données dans le fichier d'état. Restreignez les personnes pouvant le lire. Un modèle pratique consiste à utiliser un bucket par environnement, avec des préfixes de clés distincts par pile, afin qu'un pipeline de développement ne puisse pas lire l'état de production. Cela se transpose directement dans le travail CI/CD du Module 3, où les mêmes identifiants deviennent des secrets de pipeline.

4. Stockage partagé NFS

Lorsque plusieurs serveurs doivent lire et écrire les mêmes fichiers, ni un volume Block Storage à attachement unique ni un magasin d'objets ne convient parfaitement. NFS vous offre un système de fichiers POSIX monté simultanément sur des clients Linux. Il est provisionné via 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 le nettoyage 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 CLOUD prend uniquement en charge NFSv4.2. NFSv3 n'est pas pris en charge, de sorte que tout outil client ou entrée fstab configuré pour la version 3 échouera lors de la montée du système de fichiers. La taille du Cluster varie d'un minimum de 2 TiB à un maximum de 42 TiB, et toute la capacité provisionnée est 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, il est donc recommandé, pour les données sensibles, de maintenir le partage sur un LAN privé et de compter sur l'isolation réseau plutôt que d'attendre un chiffrement TLS sur le montage. Le Cluster fonctionne en mode haute disponibilité actif/passif et est accessible via une IP privée que vous assignez dans le bloc connections.

4.2 Montage du partage

Après l'application, le partage est monté depuis un client Linux en utilisant l'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. Il convient donc de mapper les UID et GID sur le partage afin qu'ils correspondent à l'utilisateur de l'application qui lit et écrit les fichiers, comme l'indiquent les arguments uid et gid ci-dessus. Une non-conformité de la propriété est la cause habituelle des erreurs d'accès refusé immédiatement après un montage réussi.

5. Choisir le bon stockage dans le code

Chaque type de stockage correspond à un modèle d'accès différent, et un mauvais choix se manifeste soit par une contrainte à laquelle on doit lutter, soit par une facture inattendue. Le Block Storage est attaché à exactement un seul serveur et se comporte comme un disque local : utilisez-le pour les bases de données, les volumes système d'exploitation et toute charge de travail à un seul rédacteur. L'Object Storage est accessible via HTTP avec des identifiants S3 et se dimensionne indépendamment de toute VM : utilisez-le pour les téléversements d'utilisateurs, les sauvegardes, les ressources statiques et l'état Terraform. NFS offre un accès POSIX concurrentiel à partir 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 proprement. Le volume de données du serveur API est du Block Storage, attaché à un seul serveur et dimensionné pour le jeu de travail. Les pièces jointes sont envoyées vers l'Object Storage, car le navigateur téléverse directement avec des URL présignées et l'API ne fait jamais de proxy des octets. NFS n'est pas utilisé dans la construction de base de TaskBoard ; c'est le modèle à adopter plus tard si vous ajoutez une flotte de travailleurs qui doivent partager un répertoire de contenu.

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

Points de terminaison API clés pour le provisionnement du stockage :

URL de base de l'API Cloud : https://api.ionos.com/cloudapi/v6 Point de terminaison S3 du 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> ; le Object Storage utilise Access Key + Secret Key (signature AWS)

Atelier de code

Objectif : Déployer la couche de stockage de TaskBoard avec Terraform : un volume de données Block Storage attaché au serveur API et un seau Object Storage dont les identifiants d'accès sont sortis en tant que valeurs sensibles.

Prérequis :

• Compte IONOS CLOUD avec jeton API (IONOS_TOKEN exporté)
• Terraform 1.5 ou supérieur avec le fournisseur ionos-cloud/ionoscloud
• Un centre de données et un serveur API existants (depuis l'atelier de l'unité 2.1) ou les créer en ligne

Étape 1 : Fixer 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 le volume de données 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 et la clé Object Storage

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 : Initialiser et planifier

terraform init
terraform plan -out=storage.plan

Sortie attendue :

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

Sortie attendue :

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

Liste de contrôle de validation :

• [ ] Le 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 liste le bucket en utilisant Access Key + Secret Key, et non le jeton bearer

Nettoyage :

terraform destroy -auto-approve

Erreurs courantes

Erreurs de développement à éviter lors de la provision de stockage sur IONOS CLOUD :

1. Épingler un volume sur la zone 3 alors que le serveur se trouve dans la 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 ne dispose pas de la zone 3.
   • Cause : 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 à tort que les ensembles de zones sont identiques.
   • Correction : Utilisez availability_zone = "AUTO" à la fois sur le serveur et sur le volume, sauf si vous avez un plan délibéré d'épinglage de zone, et ne définissez jamais ZONE_3 sur un serveur.

2. Envoyer le jeton bearer IONOS CLOUD à Object Storage

   • Problème : Les requêtes S3 renvoient 403 SignatureDoesNotMatch ou AccessDenied, même si votre jeton d'API cloud est valide.
   • Cause : Object Storage implémente l'API AWS S3 et s'authentifie à l'aide d'une Access Key et d'une Secret Key. Le jeton bearer utilisé pour api.ionos.com n'est pas accepté par le point d'entrée S3.
   • Correction : Générez des identifiants avec ionoscloud_s3_key, définissez AWS_ACCESS_KEY_ID et AWS_SECRET_ACCESS_KEY, et transmettez toujours l'URL explicite du point d'entrée S3 d'IONOS CLOUD.

3. Monter un partage NFS avec NFSv3

   • Problème : mount -t nfs -o vers=3 ... reste suspendu ou échoue ; le partage refuse la connexion.
   • Cause : IONOS CLOUD NFS ne prend en charge que NFSv4.2. NFSv3 n'est pas disponible, de sorte qu'une option de montage épinglée sur v3 ou une entrée fstab héritée ne parviendra pas à négocier.
   • Correction : Montez sans option v3 (NFSv4.2 est négocié par défaut) et alignez le uid/gid du partage sur l'utilisateur de l'application, car le root squash est en vigueur :

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

Résumé

Vous pouvez désormais provisionner les trois niveaux de stockage IONOS CLOUD entièrement dans Terraform et les intégrer à une application. Les volumes Block Storage sont attachés à un serveur unique via ionoscloud_volume, avec une taille comprise entre 1 GiB et 4 TiB, le type de stockage et la zone étant 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 par Access Key et Secret Key plutôt que par votre jeton bearer, et les mêmes buckets servent de support à l'état distant Terraform. Les clusters et partages NFS offrent un accès concurrent NFSv4.2 pour les cas où de nombreux clients Linux doivent partager un système de fichiers. La leçon récurrente est que ce sont les contraintes, et non la syntaxe des ressources, qui déterminent votre conception : les incompatibilités de zone, le modèle d'authentification S3 et la version du protocole NFS sont les points où le temps en production est perdu.

Points clés :

• ionoscloud_volume provisionne le 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 les zones 1, 2, 3 et Auto, mais Compute n'a pas de zone 3 ; par défaut, les deux sont définis sur AUTO
• Object Storage s'authentifie par Access Key + Secret Key via un endpoint S3 spécifique à la région, jamais par le jeton bearer IONOS CLOUD
• Les buckets Object Storage fonctionnent comme un backend d'état distant Terraform compatible S3 avec les drapeaux de validation ignorés
• NFS fournit un stockage partagé NFSv4.2 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 seul serveur.
• ionoscloud_s3_key : ressource Terraform qui génère une paire Access Key et Secret Key pour Object Storage ; sortie marquée comme sensible.
• Endpoint 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 : magasin partagé et durable pour l'état Terraform ; un bucket Object Storage configuré avec le type de backend s3.
• Root squash : comportement NFS qui mappe le root du client vers une identité non privilégiée ; nécessite d'aligner le uid/gid du partage avec l'utilisateur de l'application.

Prochaines étapes

Continuer l'apprentissage : Unité 2.5 : Provisionnement de la base de données et du service de streaming

Sujets connexes :

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