Unité 2.5 : Provisionnement de services de base de données et de diffusion en continu

Introduction

TaskBoard dispose désormais de calcul, de réseau et de stockage en code. L'application a toujours besoin d'un endroit pour conserver l'état. Les tâches, les tableaux et les utilisateurs appartiennent à un magasin relationnel avec TLS et des sauvegardes automatisées. Les données de session et les chemins de lecture chauds appartiennent à un cache en mémoire. Les événements de modification de tâche que le service worker consomme appartiennent à un flux.

Cette unité provisionne les trois en tant que ressources Terraform. Vous définissez le PostgreSQL Cluster (stockage transactionnel) et l'ensemble de réplicas In-Memory DB (cache de session et de lecture) dont TaskBoard dépend, puis voyez le même modèle de provisionnement appliqué à MongoDB, MariaDB et Kafka. La règle stricte qui traverse chaque exemple : les bases de données gérées par IONOS s'exécutent en tant que primaire unique writable. Il n'y a pas de réplicas de lecture lisibles pour mettre à l'échelle les lectures. 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 informations d'identification sensitive afin que le matériel de connexion ne figure jamais dans la sortie du plan ou les journaux CI.

1. Provisionnement de PostgreSQL avec Terraform

PostgreSQL est le système d'enregistrement 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 de la ressource, le stockage, la connexion LAN, la fenêtre de maintenance et les informations d'identification initiales. Le provisionnement est asynchrone, et un nouveau Cluster peut prendre 20 à 30 minutes pour atteindre AVAILABLE, car la plateforme provisionne des nœuds frais pour chaque instance demandée.

Le Cluster est attaché à un LAN privé (le niveau de base de données de l'unité 2.2), il n'est donc jamais directement exposé à 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 relie le Cluster à un LAN existant et lui attribue un CIDR à l'intérieur 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 est le décompte total de Node, et non un décompte de réplique en lecture. La plage prise en charge est de 1 à 5 instances par Cluster. Les instances supplémentaires sont des secours HA, et non des points de terminaison que votre application lit. PostgreSQL prend en charge deux modes de réplication : ASYNCHRONOUS (par défaut) et STRICTLY_SYNCHRONOUS. Le mode synchrone strict nécessite un minimum de 3 instances. Pour TaskBoard, vous provisionnez une instance principale unique (instances = 1) et mettez à l'échelle les lectures avec In-Memory DB dans la section 2.

1.2 Sauvegardes, maintenance et fixation de version

Managed PostgreSQL conserve des sauvegardes automatisées avec une rétention de 7 jours par défaut et prend en charge la récupération à un moment donné dans cette fenêtre, mais sur la v2 API, la rétention est configurable de 1 à 365 jours via backup.retentionDays au moment de la création ou de la mise à jour de Cluster. Notez que la Backup Service générale ne sauvegarde pas les bases de données gérées, donc ne prévoyez pas de la pointer vers la Cluster. La récupération est PITR plus vos propres dumps planifiés, couverts dans le Module 4.

Fixez explicitement la postgres_version plutôt que de la laisser flotter. Les mises à niveau majeures modifient le comportement et ne sont pas quelque chose que vous voulez déclencher 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 quand la plateforme applique les correctifs. Chaque fenêtre peut durer jusqu'à 4 heures. Choisissez un créneau de faible trafic afin que le basculement HA pendant la correction se produise en dehors des heures de pointe.

2. Provisionnement de In-Memory DB pour le cache

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

In-Memory DB expose maintenant deux versions de API. La version v2 de API (version 2.0.0), dont la ressource principale est Cluster, est GA et est la version de API recommandée pour la production. La version v1 de API (version 1.0.0), dont la ressource principale est ReplicaSet, est la mise en œuvre héritée et a une obsolescence annoncée pour une prochaine version ; la migration de v1 à v2 est initiée par le client, et non automatique, donc les clusters v1 existants doivent être migrés manuellement vers la ressource Cluster v2 avant que v1 ne soit supprimé. Les exemples de Terraform ci-dessous provisionnent le jeu de répliques In-Memory DB, et le modèle de connexion qu'ils produisent (moteur, port, TLS, plafond de connexion fixe) est le même, quel que soit la version de API qui prend en charge la ressource. Pour le développement direct de nouvelles versions de API ou SDK, ciblez les points de terminaison v2 Cluster.

Le jeu de répliques est composé d'un nœud actif Node et de n-1 nœuds passifs. Les nœuds passifs fournissent une bascule automatique, et non un débit de lecture supplémentaire du point de vue du client, puisque les clients se connectent via le point de terminaison actif.

2.1 La ressource inmemorydb_replicaset

Une contrainte critique : les informations d'identification sont définies uniquement lors de la création. Vous ne pouvez pas modifier le mot de passe via une mise à jour ultérieure, donc générez-le une fois et stockez-le où votre application peut le lire. Le stockage minimum est de 10 Go par Node. La politique d'éviction par défaut est allkeys-lru. Le mode de persistance par défaut est None ; la version 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 de terminaison du cache prend en charge TLS, mais il est chiffré uniquement si vous activez TLS sur l'instance lors de sa création ; il n'est pas activé par défaut. Une fois activé, l'autorité de certification est Let's Encrypt, donc un bundle CA système standard valide la connexion sans que vous ayez à fournir un Root personnalisé. Votre client Redis se connecte avec TLS activé contre le point de terminaison 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)

Parce que le mot de passe ne peut pas être rotatif en place, traitez une rotation comme un remplacement : provisionnez un nouvel ensemble de répliques, coupez le trafic, puis détruisez l'ancien.

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

PostgreSQL et In-Memory DB couvrent les besoins de TaskBoard, mais le modèle de provisionnement se généralise. Kafka, MongoDB et MariaDB suivent tous la même forme : une ressource Cluster, un bloc de connexions lié à un LAN, une fenêtre de maintenance et des informations d'identification, le tout de manière asynchrone. Ci-dessous figurent les noms de ressources et les différences qui comptent lorsque vous y accédez.

3.1 Cluster et sujets Kafka

Le flux d'événements de TaskBoard (événements de modification de tâches consommés par le worker) s'exécute sur Kafka. Le provisionnement consiste en deux ressources : la Cluster, puis une ressource par sujet. La version Kafka prise en charge est 4.0.0. Les versions 3.9.0 et 3.9.1 sont obsolètes ; les clusters existants continuent de fonctionner, mais les nouveaux clusters doivent utiliser 4.0.0. Une Cluster exécute 3 courtiers, et IONOS recommande (bien qu'il ne soit pas paramétré par défaut) un facteur de réplication de 3 pour les sujets, correspondant au layout de 3 courtiers. L'authentification est mTLS pour le plan de données et un jeton Bearer pour la gestion API. Le chiffrement en transit est 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 est le plafond de parallélisme pour les consommateurs, donc dimensionnez-le en fonction de votre éventail de consommateurs attendu (le module 4 couvre la mise à l'échelle des consommateurs). Le facteur de réplication de 3 correspond au layout de 3 courtiers. Les certificats clients émis pour mTLS sont valables pendant 365 jours, donc planifiez la rotation avant qu'ils n'expirent.

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, donc votre pilote obtient un enregistrement SRV plutôt qu'une liste d'hôtes brute.

MariaDB utilise ionoscloud_mariadb_cluster. Il prend en charge uniquement les versions LTS, à partir de 10.6 (par exemple 10.6, 10.11), le port par défaut est 3306, et la réplication est asynchrone uniquement. 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 savoir quel moteur provisionner :

Choisissez PostgreSQL ou MariaDB pour les données transactionnelles relationnelles, MongoDB pour les données de documents, In-Memory DB pour la mise en cache, et Kafka pour les flux d'événements. Aucun des moteurs relationnels ne vous donne des réplicas lisibles, donc la réponse pour la mise à l'échelle de la lecture est toujours le cache. Pour les données relationnelles transactionnelles, vous pouvez également utiliser PostgreSQL ou MariaDB, et pour les données de documents, vous pouvez utiliser MongoDB. De plus, pour la mise en cache, vous pouvez utiliser In-Memory DB, et pour les flux d'événements, vous pouvez utiliser Kafka.

4. Sorties de connexion et contrainte de single-primary

La mise à disposition n'est utile que si l'application peut se connecter. Terraform connaît le nom d'hôte et les informations d'identification de Cluster après application, exposez-les donc comme sorties, chacune marquée sensitive pour qu'elles n'apparaissent pas dans la sortie de plan, les journaux CI ou terraform output sans -raw.

4.1 Sorties sensibles

Le PostgreSQL Cluster expose un nom d'hôte DNS stable, par exemple pg-010203.postgresql.de-fra.ionos.com, que votre application utilise au lieu d'un IP. Construisez la chaîne de connexion à partir du nom DNS de Cluster et des informations d'identification que vous avez fournies.

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 par défaut de SSL pour PostgreSQL est prefer et il ne peut pas être désactivé par le client, vous devez donc toujours définir sslmode=require (ou plus strict) du côté de l'application. Le certificat TLS Root pour PostgreSQL est ISRG Root X1, qui se trouve dans n'importe quel bundle de système d'exploitation moderne CA.

4.2 Pourquoi il n'y a pas de réplica de lecture à pointer

C'est la contrainte qui brise 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éplica de lecture. L'ensemble de réplicas de 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, et non des points de terminaison de lecture. PostgreSQL instances > 1 vous donne des secours HA, et non des cibles de requête.

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

Branchez l'application de telle sorte que chaque écriture et chaque lecture cohérente aille au primaire, et chaque lecture à chaud passe par In-Memory DB avec un modèle de cache-aside. Cette intégration est l'objet du Module 4, mais la décision de mise à disposition est prise ici : un primaire, un cache.

API Référence Carte Rapide

Points de terminaison clés API pour la provision de bases de données et de diffusion en continu :

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

Laboratoire de code

Objectif : Déployer le niveau de base de données de TaskBoard avec Terraform : une base de données PostgreSQL Cluster à primary unique et un jeu de réplicas In-Memory DB, puis afficher leurs détails de connexion comme des valeurs sensibles.

Prérequis :

• Compte IONOS Cloud avec jeton API (IONOS_TOKEN exporté)
• Terraform >= 1.5 avec le fournisseur ionoscloud
• Un centre de données et une base de données LAN existants à partir des unités 2.1 et 2.2

Étape 1 : Déclarer des variables sensibles

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

Étape 2 : Ajouter la base de données PostgreSQL Cluster (à partir de 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 (à partir de la section 2.1) et les sorties sensibles (à partir de la section 4.1). Ensuite, 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 (la mise en service est asynchrone et peut prendre 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, requis car il s'agit d'une information 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 sur TLS à partir d'un hôte sur la base de données LAN :

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

Sortie attendue :

PostgreSQL 16.x ...

Étape 7 : Vérifier le cache avec un ensemble rapide de définitions et de récupérations sur TLS :

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

Sortie attendue :

PONG

Liste de validation :

• [ ] La base de données PostgreSQL Cluster a atteint AVAILABLE et accepte une connexion TLS
• [ ] Le jeu de réplicas In-Memory DB répond à PING sur TLS
• [ ] Toutes les sorties de connexion sont marquées comme sensibles et nécessitent -raw pour les lire
• [ ] Aucun mot de passe n'apparaît dans la sortie de planification ou les journaux d'application

Nettoyage :

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

Pièges courants

1. Traiter les instances Cluster comme des réplicas en lecture

   • Problème : Vous définissez instances = 3 sur le PostgreSQL Cluster et essayez d'envoyer des requêtes de lecture à un second Node pour décharger le principal. Les connexions atterrissent toujours sur le même point de terminaison writable, et vous n'obtenez jamais de mise à l'échelle en lecture.
   • Pourquoi cela se produit-il : Les bases de données gérées par IONOS fonctionnent avec un seul principal writable. Les instances supplémentaires sont des secours haute disponibilité, et non des réplicas lisibles, et il n'y a pas de point de terminaison de lecture séparé.
   • Correction : Mettre à disposition un principal et acheminer les lectures à chaud 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 impriment le mot de passe de la base de données parce qu'une sortie n'a pas été marquée comme sensible, et terraform apply l'affiche lors de l'exécution.
   • Pourquoi cela se produit-il : Les sorties sont par défaut visibles. Toute chaîne de connexion construite à partir de données d'identification est en texte brut, à moins d'être signalée.
   • Correction : Marquer chaque sortie contenant des données d'identification sensitive = true et lire avec -raw uniquement lorsqu'elle est nécessaire :

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

3. Essayer de modifier le mot de passe In-Memory DB plus tard

   • Problème : Vous exécutez une mise à jour pour faire pivoter le mot de passe du cache et l'application échoue ou le changement est ignoré.
   • Pourquoi cela se produit-il : Les données d'identification In-Memory DB sont définies uniquement lors de la création et ne peuvent pas être modifiées par la suite.
   • Correction : Traiter la rotation comme un remplacement. Mettre à disposition un nouveau jeu de réplicas, migrer le trafic, puis détruire l'ancien. Générer 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 maintenant provisionner l'ensemble du niveau de données de TaskBoard sous forme de code : une instance principale unique PostgreSQL Cluster pour les transactions, un ensemble de réplicas In-Memory DB pour les sessions et le cache de lecture, et (en utilisant le même modèle de ressource) Kafka, MongoDB, ou MariaDB lorsque la charge de travail en a besoin. Vous savez comment lier chaque Cluster à un LAN privé, définir une fenêtre de maintenance, fournir des informations d'identification de manière sécurisée, et exposer les détails de connexion sous forme de sorties Terraform sensibles. Le plus important, vous provisionnez autour du modèle à instance principale unique : une instance Cluster writable, avec la mise à l'échelle de la lecture gérée par le cache plutôt que par des réplicas qui n'existent pas.

Points clés :

• ionoscloud_pg_cluster provisionne PostgreSQL (versions 14, 15, 16 ; port 5432) ; instances sont des nœuds haute disponibilité, 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 informations d'identification sont définies uniquement lors de la création et ne peuvent pas être modifiées à posteriori
• ionoscloud_kafka_cluster plus ionoscloud_kafka_cluster_topic provisionnent Kafka 4.0.0 avec 3 courtiers et un facteur de réplication 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é, donc l'application définit sslmode=require
• Il n'y a pas de réplicas de lecture lisibles sur aucun moteur géré ; provisionnez une instance principale unique et mettez à l'échelle les lectures à travers In-Memory DB

Terminologie importante :

• Modèle à instance principale unique : La contrainte de provisionnement selon laquelle les bases de données gérées utilisent une instance Cluster writable avec aucun réplica lisible ; les lectures sont mises à l'échelle au niveau du cache.
• Ensemble de réplicas (In-Memory DB) : Un nœud actif Node plus n-1 nœuds de basculement passifs ; 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 des correctifs et peut déclencher un basculement haute disponibilité.
• 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 la lire.
• Facteur de réplication (Kafka) : Le nombre de copies de courtiers de chaque partition ; par défaut, il est égal à 3, ce qui correspond au Cluster à 3 courtiers.

Prochaines étapes

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

Sujets connexes :

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