Unité 2.5 : Provisionnement de services de base de données et de streaming

Introduction

TaskBoard dispose désormais du calcul, du réseau et du stockage définis dans le code. L'application a toujours besoin d'un emplacement pour conserver l'état. Les tâches, les tableaux et les utilisateurs doivent être stockés dans un magasin relationnel avec TLS et des sauvegardes automatisées. Les données de session et les chemins de lecture fréquents doivent être placés dans un cache en mémoire. Les événements de modification de tâches consommés par le service de travail doivent être placés sur un flux.

Cette unité provisionne les trois composants en tant que ressources Terraform. Vous définissez le cluster PostgreSQL (stockage transactionnel) et le jeu de répliques In-Memory DB (cache de session et de lecture) dont TaskBoard dépend, puis vous observez le même modèle de provisionnement appliqué à MongoDB, MariaDB et Kafka. La règle stricte qui traverse chaque exemple : les moteurs relationnels (PostgreSQL, MariaDB) fonctionnent comme un primaire unique en écriture, sans répliques de lecture lisibles pour mettre à l'échelle les lectures ; seul MongoDB Enterprise peut ajouter des secondaires lisibles. Vous provisionnez un cluster et vous mettez à l'échelle les lectures avec le cache, et non avec la base de données. Chaque exemple marque les identifiants sensitive afin que les informations de connexion ne figurent jamais dans la sortie du plan ou dans les journaux CI.

1. Provisionnement de PostgreSQL avec Terraform

PostgreSQL est le système de référence de TaskBoard. La ressource ionoscloud_pg_cluster crée un cluster géré : vous spécifiez la version du moteur, le nombre d'instances, la taille des ressources, le stockage, la connexion LAN, la fenêtre de maintenance et les identifiants initiaux. Le provisionnement est asynchrone, et un nouveau cluster peut mettre de 20 à 30 minutes pour atteindre AVAILABLE, car la plateforme provisionne des nœuds neufs pour chaque instance demandée.

Le cluster est rattaché à un LAN privé (la couche base de données de l'unité 2.2), il n'est donc jamais exposé directement à Internet. Le port par défaut est 5432 et il n'est pas configurable.

1.1 La ressource pg_cluster

Les versions PostgreSQL prises en charge sont 14, 15 et 16. Les types de stockage sont SSD Premium, SSD et HDD. Le bloc connections associe le cluster à un LAN existant et lui attribue un CIDR au sein de ce LAN.

resource "ionoscloud_pg_cluster" "taskboard" {
  postgres_version = "16"
  instances        = 1
  cores            = 4
  ram              = 8192
  storage_size     = 50
  storage_type     = "SSD Premium"
  location         = ionoscloud_datacenter.taskboard.location
  display_name     = "taskboard-pg"

  connections {
    datacenter_id = ionoscloud_datacenter.taskboard.id
    lan_id        = ionoscloud_lan.db.id
    cidr          = "10.20.30.4/24"
  }

  maintenance_window {
    day_of_the_week = "Sunday"
    time            = "03:00:00"
  }

  credentials {
    username = "taskboard_admin"
    password = var.pg_admin_password
  }

  synchronization_mode = "ASYNCHRONOUS"
}

La valeur instances correspond au nombre total de nœuds, et non au nombre de répliques de lecture. La plage prise en charge est de 1 à 5 instances par cluster. Les instances supplémentaires sont des nœuds de secours HA, et non des points d'accès à partir desquels votre application effectue des lectures. PostgreSQL prend en charge deux modes de réplication : ASYNCHRONOUS (le mode par défaut) et STRICTLY_SYNCHRONOUS. Le mode strictement synchrone nécessite un minimum de 3 instances. Pour TaskBoard, vous provisionnez une instance primaire unique (instances = 1) et vous scalez les lectures avec In-Memory DB dans la section 2.

1.2 Sauvegardes, maintenance et verrouillage de version

Managed PostgreSQL conserve des sauvegardes automatisées avec une rétention de 7 jours par défaut et prend en charge la restauration à un instant donné (point-in-time recovery) dans cette fenêtre. Toutefois, sur l'API v2, la rétention est configurable de 1 à 365 jours via backup.retentionDays lors de la création ou de la mise à jour du cluster. Notez que le Backup Service général ne sauvegarde pas les bases de données managées ; ne prévoyez donc pas de le diriger vers le cluster. La restauration combine PITR et vos propres déchargements planifiés, traités dans le Module 4.

Verrouillez explicitement postgres_version au lieu de laisser la version flotter. Les mises à niveau majeures modifient le comportement et ne doivent pas être déclenchées silencieusement par une différence de plan.

variable "pg_admin_password" {
  type      = string
  sensitive = true
}

# Pass at apply time or via TF_VAR_pg_admin_password, never hardcode:
#   terraform apply -var="pg_admin_password=$(openssl rand -base64 24)"

Le maintenance_window contrôle le moment où la plateforme applique les correctifs. Chaque fenêtre a une durée maximale de 4 heures. Choisissez une plage horaire à faible trafic afin que le basculement HA lors de l'application des correctifs ait lieu en dehors des heures de pointe.

2. Provisionnement d'In-Memory DB pour la mise en cache

TaskBoard utilise In-Memory DB pour le stockage des sessions et pour la mise en cache des listes de tâches. Comme PostgreSQL ne dispose pas de répliques lisibles, la mise en cache constitue la couche de mise à l'échelle en lecture, et non une optimisation facultative. La ressource ionoscloud_inmemorydb_replicaset provisionne un ensemble de répliques compatible Redis. Le moteur est Redis OSS version stable 7.2 et le port par défaut est 6379.

In-Memory DB expose désormais deux versions d'API. L'API v2 (version 2.0.0), dont la ressource principale est Cluster, est disponible en version générale (GA) et est l'API recommandée pour la production. L'API v1 (version 1.0.0), dont la ressource principale est ReplicaSet, est l'implémentation héritée et une dépréciation est annoncée pour une prochaine version ; la migration de v1 à v2 est initiée par le client, et non automatique, de sorte que les clusters v1 existants doivent être migrés manuellement vers la ressource Cluster de v2 avant le retrait de v1. Les exemples Terraform ci-dessous provisionnent l'ensemble de répliques In-Memory DB, et le modèle de connexion qu'ils produisent (moteur, port, TLS, plafond de connexions fixe) est identique, quel que soit le version d'API sous-jacente à la ressource. Pour tout nouveau développement direct d'API ou de SDK, ciblez les points d'accès Cluster de v2.

L'ensemble de répliques comprend un nœud actif et n-1 nœuds passifs. Les nœuds passifs assurent la bascule en cas de défaillance, et non un débit de lecture supplémentaire du point de vue du client, car les clients se connectent via le point d'accès actif.

2.1 La ressource inmemorydb_replicaset

Une contrainte essentielle : les identifiants sont définis uniquement lors de la création. Vous ne pouvez pas modifier le mot de passe lors d'une mise à jour ultérieure, il convient donc de le générer une seule fois et de le stocker à un endroit où votre application peut y accéder. Le stockage minimal est de 10 Go par nœud. La politique d'éviction par défaut est allkeys-lru. Le mode de persistance par défaut est None ; l'API accepte None, AOF, RDB et RDB_AOF.

resource "ionoscloud_inmemorydb_replicaset" "taskboard_cache" {
  display_name    = "taskboard-cache"
  location        = ionoscloud_datacenter.taskboard.location
  version         = "7.2"
  replicas        = 2
  persistence_mode = "RDB"
  eviction_policy  = "allkeys-lru"

  resources {
    cores = 2
    ram   = 4
  }

  connections {
    datacenter_id = ionoscloud_datacenter.taskboard.id
    lan_id        = ionoscloud_lan.db.id
    cidr          = "10.20.30.5/24"
  }

  credentials {
    username = "default"
    plain_text_password = var.cache_password
  }

  maintenance_window {
    day_of_the_week = "Sunday"
    time            = "04:00:00"
  }
}

2.2 TLS pour la connexion au cache

Le point d'accès du cache prend en charge TLS, mais le chiffrement n'est actif que si vous avez activé TLS sur l'instance lors de sa création ; cette option n'est pas activée par défaut. Une fois activée, l'autorité de certification est Let's Encrypt, de sorte qu'un bundle CA système standard valide la connexion sans que vous ayez à fournir une racine personnalisée. Votre client Redis se connecte avec TLS activé sur le point d'accès actif :

import redis

# host comes from the Terraform output (Section 4); password set at creation
r = redis.Redis(
    host=cache_host,
    port=6379,
    username="default",
    password=cache_password,
    ssl=True,
    ssl_cert_reqs="required",
)
r.set("session:abc123", "user-42", ex=3600)

Comme le mot de passe ne peut pas être renouvelé sur place, considérez un renouvellement comme un remplacement : provisionnez un nouveau jeu de répliques, basculez le trafic, puis détruisez l'ancien.

3. Provisioning de Kafka, MongoDB et MariaDB (même modèle)

PostgreSQL et In-Memory DB couvrent les besoins de TaskBoard, mais le modèle de provisioning est généralisable. Kafka, MongoDB et MariaDB suivent tous la même structure : une ressource de cluster, un bloc de connexions lié à un LAN, une fenêtre de maintenance et des identifiants, le tout de manière asynchrone. Ci-dessous figurent les noms des ressources et les différences importantes à prendre en compte lors de leur utilisation.

3.1 Clusters et sujets Kafka

Le flux d'événements de TaskBoard (événements de modification de tâches consommés par le worker) fonctionne sur Kafka. Le provisioning comprend deux ressources : le cluster, puis une ressource par sujet. La version Kafka prise en charge est la 4.0.0. Les versions 3.9.0 et 3.9.1 sont obsolètes ; les clusters existants utilisant ces versions continuent de fonctionner, mais les nouveaux clusters doivent utiliser la version 4.0.0. Un cluster comporte 3 brokers, et IONOS CLOUD recommande (sans en faire le paramètre par défaut) un facteur de réplication de 3 pour les sujets, ce qui correspond à la configuration à 3 brokers. L'authentification est assurée par mTLS pour le plan de données et par un jeton Bearer pour l'API de gestion. Le chiffrement en transit est assuré par TLS.

resource "ionoscloud_kafka_cluster" "events" {
  name    = "taskboard-events"
  version = "4.0.0"
  size    = "S"
  location = ionoscloud_datacenter.taskboard.location

  connections {
    datacenter_id   = ionoscloud_datacenter.taskboard.id
    lan_id          = ionoscloud_lan.app.id
    broker_addresses = ["10.20.20.10/24", "10.20.20.11/24", "10.20.20.12/24"]
  }
}

resource "ionoscloud_kafka_cluster_topic" "task_changes" {
  cluster_id          = ionoscloud_kafka_cluster.events.id
  location            = ionoscloud_kafka_cluster.events.location
  name                = "task-changes"
  number_of_partitions = 6
  replication_factor   = 3
  retention_time       = 604800000
}

Le nombre de partitions constitue la limite de parallélisme pour les consommateurs. Dimensionnez-le en fonction de l'éventail de consommateurs prévu (le Module 4 aborde la mise à l'échelle des consommateurs). Le facteur de réplication de 3 correspond à la configuration à 3 brokers. Les certificats client émis pour mTLS sont valides pendant 365 jours. Planifiez leur rotation avant leur expiration.

3.2 MongoDB et MariaDB

MongoDB utilise ionoscloud_mongo_cluster. Les versions prises en charge sont 6.0 et 7.0. La chaîne de connexion suit le format mongodb+srv://m-<id>.mongodb.<region>.ionos.com. Votre pilote reçoit ainsi un enregistrement SRV au lieu d'une liste brute d'hôtes.

MariaDB utilise ionoscloud_mariadb_cluster. Il ne prend en charge que les versions LTS, à partir de 10.6 (par exemple 10.6, 10.11). Le port par défaut est 3306. La réplication est uniquement asynchrone. L'autorité de certification est Let's Encrypt.

resource "ionoscloud_mariadb_cluster" "reporting" {
  mariadb_version = "10.11"
  instances       = 1
  cores           = 2
  ram             = 4
  storage_size    = 20
  display_name    = "taskboard-reporting"
  location        = ionoscloud_datacenter.taskboard.location

  connections {
    datacenter_id = ionoscloud_datacenter.taskboard.id
    lan_id        = ionoscloud_lan.db.id
    cidr          = "10.20.30.6/24"
  }

  maintenance_window {
    day_of_the_week = "Sunday"
    time            = "05:00:00"
  }

  credentials {
    username = "reporting_admin"
    password = var.maria_password
  }
}

Le tableau de décision pour le moteur à provisionner :

Choisissez PostgreSQL ou MariaDB pour les données transactionnelles relationnelles, MongoDB pour les données documentaires, In-Memory DB pour la mise en cache, et Kafka pour les flux d'événements. Aucun des moteurs relationnels ne vous offre de répliques lisibles, donc la réponse à la mise à l'échelle en lecture est toujours le cache.

4. Sorties de connexion et contrainte d'un unique primaire

Le provisionnement n'est utile que si l'application peut se connecter. Terraform connaît le nom DNS du cluster et les identifiants après l'application, il convient donc de les exposer en tant que sorties, chacune étant marquée sensitive afin qu'elles n'apparaissent pas dans la sortie du plan, les journaux CI, ou terraform output sans -raw.

4.1 Sorties sensibles

Le cluster PostgreSQL expose un nom d'hôte DNS stable, par exemple pg-010203.postgresql.de-fra.ionos.com, que votre application utilise à la place d'une adresse IP. Construisez la chaîne de connexion à partir du nom DNS du cluster et des identifiants que vous avez fournis.

output "pg_connection_string" {
  value     = "postgresql://${ionoscloud_pg_cluster.taskboard.credentials[0].username}@${ionoscloud_pg_cluster.taskboard.dns_name}:5432/postgres?sslmode=require"
  sensitive = true
}

output "cache_host" {
  value     = ionoscloud_inmemorydb_replicaset.taskboard_cache.dns_name
  sensitive = true
}

output "kafka_broker_addresses" {
  value     = ionoscloud_kafka_cluster.events.connections[0].broker_addresses
  sensitive = true
}

Le mode SSL par défaut pour PostgreSQL est prefer et il ne peut pas être désactivé par le client, il faut donc toujours définir sslmode=require (ou un mode plus strict) côté application. Le certificat racine TLS pour PostgreSQL est ISRG Root X1, qui est présent dans tout bundle CA de système moderne.

4.2 Pourquoi il n'y a pas de réplique de lecture à utiliser

C'est la contrainte qui fait échouer les plans de mise à l'échelle naïfs. Il n'y a pas de sortie read_endpoint à créer, car il n'y a pas de réplique de lecture. Le jeu de répliques d'In-Memory DB est composé d'un nœud actif et de n-1 nœuds passifs, et les passifs sont des cibles de basculement, pas des points d'accès en lecture. PostgreSQL instances > 1 vous fournit des serveurs de secours HA, pas des cibles de requêtes.

# WRONG: there is no separate read endpoint to expose
# output "pg_read_endpoint" { value = ... }  # does not exist

# RIGHT: reads scale through the cache, writes go to the single primary
output "pg_primary_dns" {
  value     = ionoscloud_pg_cluster.taskboard.dns_name
  sensitive = true
}

Configurez l'application de sorte que chaque écriture et chaque lecture cohérente soit dirigée vers l'instance principale, et que chaque lecture fréquente passe par In-Memory DB selon un motif cache-aside. Cette intégration fait l'objet du Module 4, mais la décision de provisionnement est prise ici : une instance principale, un cache.

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

Points d'entrée API principaux pour le provisionnement de bases de données et de flux :

URL de base (Cloud DBaaS) : https://api.ionos.com/databases/postgresql In-Memory DB / Kafka : hôtes spécifiques à la région (par exemple https://in-memory-db.de-fra.ionos.com) Authentification : Authorization: Bearer <token> pour les API de gestion ; mTLS pour le plan de données Kafka

Atelier de code

Objectif : Déployer la couche de base de données de TaskBoard avec Terraform : un cluster PostgreSQL à primaire unique et un ensemble de répliques In-Memory DB, puis afficher leurs détails de connexion en tant que valeurs sensibles.

Prérequis :

• Compte IONOS CLOUD avec jeton API (IONOS_TOKEN exporté)
• Terraform >= 1.5 avec le fournisseur ionoscloud
• Un datacenter et un LAN de base de données existants, issus des Unités 2.1 et 2.2

Étape 1 : Déclarer les variables sensibles

variable "pg_admin_password" {
  type      = string
  sensitive = true
}
variable "cache_password" {
  type      = string
  sensitive = true
}

Étape 2 : Ajouter le cluster PostgreSQL (depuis la section 1.1), puis valider :

terraform validate

Sortie attendue :

Success! The configuration is valid.

Étape 3 : Ajouter le jeu de réplicas In-Memory DB (depuis la section 2.1) et les sorties sensibles (depuis la section 4.1). Puis planifier :

terraform plan \
  -var="pg_admin_password=$(openssl rand -base64 24)" \
  -var="cache_password=$(openssl rand -base64 24)"

Sortie attendue :

Plan: 2 to add, 0 to change, 0 to destroy.
Changes to Outputs:
  + cache_host           = (sensitive value)
  + pg_connection_string = (sensitive value)

Étape 4 : Appliquer (le provisionnement est asynchrone et peut prendre de 20 à 30 minutes pour PostgreSQL) :

terraform apply -auto-approve \
  -var="pg_admin_password=$PG_PW" \
  -var="cache_password=$CACHE_PW"

Sortie attendue :

ionoscloud_pg_cluster.taskboard: Creation complete after 24m12s
ionoscloud_inmemorydb_replicaset.taskboard_cache: Creation complete after 6m41s
Apply complete! Resources: 2 added, 0 changed, 0 destroyed.

Étape 5 : Lire la chaîne de connexion sensible (notez -raw, requise car elle est sensible) :

terraform output -raw pg_connection_string

Sortie attendue :

postgresql://taskboard_admin@pg-010203.postgresql.de-fra.ionos.com:5432/postgres?sslmode=require

Étape 6 : Vérifier la connexion PostgreSQL via TLS depuis un hôte du LAN de la base de données :

psql "$(terraform output -raw pg_connection_string)" -c "SELECT version();"

Sortie attendue :

PostgreSQL 16.x ...

Étape 7 : Vérifier le cache avec une opération rapide de configuration/récupération via TLS :

redis-cli -h "$(terraform output -raw cache_host)" -p 6379 \
  --tls --user default -a "$CACHE_PW" PING

Sortie attendue :

PONG

Liste de contrôle de validation :

• [ ] Le cluster PostgreSQL a atteint AVAILABLE et accepte une connexion TLS
• [ ] Le jeu de répliques In-Memory DB répond à PING via TLS
• [ ] Toutes les sorties de connexion sont marquées comme sensibles et nécessitent -raw pour être lues
• [ ] Aucun mot de passe n'apparaît dans la sortie du plan ni dans les journaux d'application

Nettoyage :

terraform destroy -auto-approve \
  -var="pg_admin_password=$PG_PW" \
  -var="cache_password=$CACHE_PW"

Erreurs courantes

1. Considérer les instances du cluster comme des répliques en lecture

   • Problème : Vous définissez instances = 3 sur le cluster PostgreSQL et essayez d'envoyer des requêtes de lecture vers un second nœaf afin de soulager le nœud principal. Les connexions aboutissent toutes sur le même point d'accès en écriture, et vous n'obtenez jamais de mise à l'échelle en lecture.
   • Pourquoi cela se produit : Les bases de données gérées IONOS CLOUD exécutent un unique nœud principal en écriture. Les instances supplémentaires sont des répliques de redondance (HA), et non des répliques en lecture, et il n'existe pas de point d'accès de lecture distinct.
   • Solution : Provisionnez un nœud principal et acheminez les lectures fréquentes via In-Memory DB :

   resource "ionoscloud_pg_cluster" "taskboard" {
     instances = 1   # single primary; cache handles read scaling
   }
   

2. Fuite de données d'identification via les sorties Terraform

   • Problème : Vos journaux CI affichent le mot de passe de la base de données, car une sortie n'a pas été marquée comme sensible, et terraform apply l'affiche pendant l'exécution.
   • Pourquoi cela se produit : Les sorties sont visibles par défaut. Toute chaîne de connexion construite à partir de données d'identification est en texte brut, sauf si elle est marquée.
   • Correction : Marquez chaque sortie contenant des données d'identification comme sensitive = true et lisez-la avec -raw uniquement en cas de besoin :

   output "pg_connection_string" {
     value     = local.pg_conn
     sensitive = true
   }
   

3. Tentative de modification ultérieure du mot de passe de la base de données In-Memory DB

   • Problème : Vous exécutez une mise à jour pour faire pivoter le mot de passe du cache et l'application échoue ou la modification est ignorée.
   • Cause : Les identifiants de la base de données In-Memory DB sont définis uniquement lors de la création et ne peuvent pas être modifiés par la suite.
   • Solution : Considérez la rotation comme un remplacement. Approvisionnez un nouvel ensemble de répliques, migrez le trafic, puis supprimez l'ancien ensemble. Générez le mot de passe une seule fois lors de la création :

   credentials {
     username            = "default"
     plain_text_password = var.cache_password  # set once, immutable
   }
   

Résumé

Vous pouvez désormais provisionner l'intégralité de la couche de données de TaskBoard sous forme de code : un cluster PostgreSQL à primaire unique pour les transactions, un ensemble de réplicas In-Memory DB pour les sessions et la mise en cache en lecture, et (en utilisant le même modèle de ressources) Kafka, MongoDB ou MariaDB lorsqu'une charge de travail en a besoin. Vous savez comment associer chaque cluster à un LAN privé, définir une fenêtre de maintenance, fournir les identifiants de manière sécurisée et exposer les détails de connexion en tant que sorties sensibles de Terraform. Plus important encore, vous effectuez le provisionnement autour du modèle à primaire unique : un cluster écriture unique, la mise à l'échelle en lecture étant gérée par le cache ; les moteurs relationnels n'offrent pas de réplicas de lecture (MongoDB Enterprise le permet, mais la couche de TaskBoard est relationnelle).

Points clés :

• ionoscloud_pg_cluster provisionne PostgreSQL (versions 14, 15, 16 ; port 5432) ; instances sont des nœuds HA, et non des réplicas de lecture, et la plage est de 1 à 5
• ionoscloud_inmemorydb_replicaset provisionne Redis 7.2 sur le port 6379 ; les identifiants sont définis uniquement à la création et ne peuvent pas être modifiés sur place
• ionoscloud_kafka_cluster et ionoscloud_kafka_cluster_topic provisionnent Kafka 4.0.0 avec 3 brokers et un facteur de réplication de 3 ; le plan de données s'authentifie avec mTLS
• Chaque sortie de connexion doit être marquée sensitive ; le mode SSL par défaut de PostgreSQL est prefer et ne peut pas être désactivé, de sorte que l'application définit sslmode=require
• Les moteurs relationnels (PostgreSQL, MariaDB) n'exposent aucun réplica de lecture lisible ; MongoDB Enterprise prend en charge jusqu'à cinq secondaires lisibles. Pour la couche relationnelle de TaskBoard, provisionnez un primaire unique et mettez à l'échelle les lectures via In-Memory DB

Terminologie importante :

• Modèle à primaire unique : La contrainte de provisionnement selon laquelle les moteurs relationnels exécutent un cluster écriture unique sans réplicas lisibles ; les lectures sont mises à l'échelle au niveau de la couche de cache. (MongoDB Enterprise fait exception : il peut ajouter jusqu'à cinq secondaires lisibles.)
• Ensemble de réplicas (In-Memory DB) : Un nœud actif plus n-1 nœuds passifs de basculement ; les clients se connectent via le point de terminaison actif.
• Fenêtre de maintenance : Un créneau hebdomadaire configurable (jusqu'à 4 heures) pendant lequel la plateforme applique les correctifs et peut déclencher un basculement HA.
• Sortie sensible : Une sortie Terraform marquée sensitive = true afin qu'elle soit masquée des journaux de plan, d'application et de CI, et nécessite -raw pour être lue.
• Facteur de réplication (Kafka) : Le nombre de copies de chaque partition sur les brokers ; la valeur par défaut est 3, correspondant au cluster de 3 brokers.

Prochaines étapes

Continuer l'apprentissage : Unité 2.6 : Vérification des connaissances - Infrastructure as Code

Sujets connexes :

• Unité 2.4 : Provisionnement du stockage en tant que code
• Unité 4.1 : Intégration de la base de données et de la mise en cache