Unidad 2.5: Provisionamiento de base de datos y servicio de transmisión

Introducción

TaskBoard ahora tiene cómputo, redes y almacenamiento en código. La aplicación todavía necesita un lugar para mantener el estado. Tareas, tableros y usuarios pertenecen a un almacenamiento relacional con TLS y copias de seguridad automatizadas. Los datos de sesión y los caminos de lectura calientes pertenecen a una caché en memoria. Los eventos de cambio de tarea que consume el servicio de trabajador pertenecen a una secuencia.

Esta unidad proporciona los tres como recursos de Terraform. Usted define el PostgreSQL Cluster (almacenamiento transaccional) y el conjunto de réplicas de In-Memory DB (caché de sesión y lectura) que TaskBoard depende, luego ve el mismo patrón de aprovisionamiento aplicado a MongoDB, MariaDB y Kafka. La regla estricta que se aplica a cada ejemplo: las bases de datos gestionadas por IONOS se ejecutan como una primaria única writable. No hay réplicas de lectura legibles para escalar las lecturas. Usted aprovisiona un Cluster y escala las lecturas con la caché, no con la base de datos. Cada ejemplo marca las credenciales sensitive para que el material de conexión nunca llegue a la salida del plan o a los registros de CI.

1. Provisionar PostgreSQL con Terraform

PostgreSQL es el sistema de registro de TaskBoard. El recurso ionoscloud_pg_cluster crea una Cluster gestionada: usted especifica la versión del motor, el número de instancias, el tamaño de los recursos, el almacenamiento, la conexión LAN, la ventana de mantenimiento y las credenciales iniciales. La provisionamiento es asíncrono, y una nueva Cluster puede tardar 20 a 30 minutos en alcanzar AVAILABLE porque la plataforma provisiona nodos frescos para cada instancia solicitada.

La Cluster se conecta a una LAN privada (el nivel de base de datos de la Unidad 2.2), por lo que nunca se expone directamente a Internet. El puerto predeterminado es 5432 y no es configurable.

1.1 El recurso pg_cluster

Las versiones de PostgreSQL admitidas son 14, 15 y 16. Los tipos de almacenamiento son SSD Premium, SSD y HDD. El bloque connections enlaza la Cluster a una LAN existente y le asigna un CIDR dentro de esa 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"
}

El valor de instances es el recuento total de Node, no un recuento de réplica de lectura. El rango admitido es de 1 a 5 instancias por Cluster. Las instancias adicionales son de respaldo de alta disponibilidad, no puntos de conexión desde los que su aplicación lee. PostgreSQL admite dos modos de replicación: ASYNCHRONOUS (el predeterminado) y STRICTLY_SYNCHRONOUS. El modo de sincronización estricta requiere un mínimo de 3 instancias. Para TaskBoard, usted provisiona una instancia principal (instances = 1) y escala las lecturas con In-Memory DB en la Sección 2.

1.2 Copias de seguridad, mantenimiento y anclaje de versiones

Managed PostgreSQL mantiene copias de seguridad automatizadas con una retención de 7 días por defecto y admite la recuperación en un momento específico dentro de esa ventana, pero en la versión 2 de API, la retención es configurable desde 1 hasta 365 días a través de backup.retentionDays en el momento de creación o actualización de Cluster. Tenga en cuenta que la Backup Service general no realiza copias de seguridad de bases de datos gestionadas, así que no planee apuntar a la Cluster. La recuperación es PITR (recuperación en un momento específico) más sus own volcados programados, que se cubren en el Módulo 4.

Anclaje el postgres_version explícitamente en lugar de dejar que flote. Las actualizaciones importantes cambian el comportamiento y no son algo que desee que una diferencia de plan active silenciosamente.

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

El maintenance_window controla cuándo la plataforma aplica parches. Cada ventana tiene una duración de hasta 4 horas. Elija un espacio de baja actividad para que el failover de alta disponibilidad durante el parcheo se produzca en un momento de baja demanda.

2. Provisionamiento de In-Memory DB para caché

TaskBoard utiliza In-Memory DB para el almacenamiento de sesiones y para cachear listas de tareas. Dado que PostgreSQL no tiene réplicas legibles, la caché es la capa de escalabilidad de lectura, no una optimización opcional. El recurso ionoscloud_inmemorydb_replicaset provisiona un conjunto de réplicas compatible con Redis. El motor es la versión estable 7.2 de Redis OSS y el puerto predeterminado es 6379.

Ahora, In-Memory DB expone dos versiones de API. La versión v2 de API (versión 2.0.0), cuyo recurso principal es Cluster, está disponible y es la versión de API recomendada para producción. La versión v1 de API (versión 1.0.0), cuyo recurso principal es ReplicaSet, es la implementación heredada y tiene un anuncio de deprecación para una próxima versión; la migración de v1 a v2 es iniciada por el cliente, no automática, por lo que los clústeres v1 existentes deben migrarse manualmente al recurso Cluster de v2 antes de que v1 sea eliminado. Los ejemplos de Terraform a continuación provisionan el conjunto de réplicas de In-Memory DB, y el modelo de conexión que producen (motor, puerto, TLS, techo de conexión fijo) es el mismo independientemente de la versión de API que respalde el recurso. Para el nuevo desarrollo directo de API o SDK, diríjase a los puntos de conexión v2 Cluster.

El conjunto de réplicas consta de un nodo activo Node y n-1 nodos pasivos. Los nodos pasivos proporcionan conmutación por error, no un rendimiento de lectura adicional desde la perspectiva del cliente, ya que los clientes se conectan a través del punto de conexión activo.

2.1 El recurso inmemorydb_replicaset

Una restricción crítica: las credenciales se establecen solo en la creación. No puede cambiar la contraseña a través de una actualización posterior, así que genérela una vez y guárdela donde su aplicación pueda leerla. El almacenamiento mínimo es de 10 GB por Node. La política de expulsión predeterminada es allkeys-lru. El modo de persistencia predeterminado es None; la versión API acepta None, AOF, RDB y 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 para la conexión de caché

El punto de conexión de caché admite TLS, pero está cifrado solo si usted habilita TLS en la instancia durante su creación; no está habilitado de forma predeterminada. Una vez habilitado, la autoridad de certificación es Let's Encrypt, por lo que un paquete de CA de sistema estándar valida la conexión sin que usted tenga que proporcionar un root personalizado. Su cliente Redis se conecta con TLS habilitado contra el punto de conexión activo: TLS

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)

Debido a que la contraseña no se puede rotar en su lugar, trate una rotación como un reemplazo: aprovisione un nuevo conjunto de réplicas, corte el tráfico, luego destruya el antiguo.

3. Provisioning Kafka, MongoDB, and MariaDB (mismo patrón)

PostgreSQL y In-Memory DB cubren las necesidades de TaskBoard, pero el patrón de aprovisionamiento se generaliza. Kafka, MongoDB, y MariaDB siguen todos la misma forma: un recurso Cluster, un bloque de conexiones que se vincula a un LAN, una ventana de mantenimiento y credenciales, todo de manera asíncrona. A continuación, se presentan los nombres de los recursos y las diferencias que importan cuando los utilice.

3.1 Clústeres y temas de Kafka

La secuencia de eventos de TaskBoard (eventos de cambio de tarea consumidos por el trabajador) se ejecuta en Kafka. El aprovisionamiento consta de dos recursos: el Cluster, y luego un recurso por tema. La versión de Kafka compatible es la 4.0.0. Las versiones 3.9.0 y 3.9.1 están en desuso; los clústeres existentes en ellas siguen funcionando, pero los nuevos clústeres deben utilizar la versión 4.0.0. Un Cluster ejecuta 3 corredores, y IONOS recomienda (aunque no es el valor predeterminado) un factor de replicación de 3 para los temas, que coincide con el diseño de 3 corredores. La autenticación es mTLS para el plano de datos y un token Bearer para el plano de gestión API. El cifrado en tránsito es 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
}

El recuento de particiones es el límite de paralelismo para los consumidores, así que ajuste su tamaño según su fan-out de consumidor esperado (el Módulo 4 cubre la escalabilidad del consumidor). El factor de replicación de 3 coincide con el diseño de 3 brokers. Los certificados de cliente emitidos para mTLS son válidos durante 365 días, así que planee la rotación antes de que expiren.

3.2 MongoDB y MariaDB

MongoDB utiliza ionoscloud_mongo_cluster. Las versiones compatibles son 6.0 y 7.0. La cadena de conexión sigue el formato mongodb+srv://m-<id>.mongodb.<region>.ionos.com, por lo que su controlador obtiene un registro SRV en lugar de una lista de hosts sin procesar.

MariaDB utiliza ionoscloud_mariadb_cluster. Sólo admite versiones LTS, a partir de 10.6 (por ejemplo, 10.6, 10.11), el puerto predeterminado es 3306 y la replicación es asíncrona solo. La autoridad de certificación es 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
  }
}

La tabla de decisión para determinar qué motor provisionar:

Elija PostgreSQL o MariaDB para datos transaccionales relacionales, MongoDB para datos de documentos, In-Memory DB para almacenamiento en caché, y Kafka para flujos de eventos. Ninguno de los motores relacionales le proporciona réplicas legibles, por lo que la respuesta para escalar la lectura es siempre la caché.

4. Salidas de conexión y la restricción de único primario

La provisión solo es útil si la aplicación puede conectarse. Terraform conoce el nombre y las credenciales de Cluster después de aplicar, así que expónlos como salidas, cada uno de ellos marcado sensitive para que no aparezcan en la salida del plan, los registros de CI o terraform output sin -raw.

4.1 Salidas sensibles

El PostgreSQL Cluster expone un nombre de host DNS estable, por ejemplo pg-010203.postgresql.de-fra.ionos.com, que su aplicación utiliza en lugar de un IP. Construya la cadena de conexión a partir del nombre DNS de Cluster más las credenciales que proporcionó.

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
}

El modo SSL predeterminado para PostgreSQL es prefer y no se puede deshabilitar en el lado del cliente, así que siempre establezca sslmode=require (o más estricto) en el lado de la aplicación. El certificado raíz TLS para PostgreSQL es ISRG Root X1, que se encuentra en cualquier paquete de certificados de autoridad de sistema moderno.

4.2 Por qué no hay una réplica de lectura a la que apuntar

Esta es la restricción que rompe los planes de escalado ingenuos. No hay salida read_endpoint que crear, porque no hay réplica de lectura. El conjunto de réplicas de In-Memory DB consta de un nodo activo y n-1 nodos pasivos, y los pasivos son objetivos de conmutación por error, no puntos de conexión de lectura. PostgreSQL instances > 1 le da puntos de espera de alta disponibilidad, no objetivos de consulta.

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

Conecte la aplicación de modo que cada escritura y cada lectura coherente vaya al primario, y cada lectura caliente pase por In-Memory DB con un patrón de caché. Esa integración es el tema del Módulo 4, pero la decisión de provisión se toma aquí: un primario, una caché.

API Tarjeta de referencia rápida

Puntos de conexión clave de API para la provisión de bases de datos y transmisión en streaming:

URL base (Nube DBaaS): https://api.ionos.com/databases/postgresql In-Memory DB / Kafka: hosts específicos de la región (por ejemplo https://in-memory-db.de-fra.ionos.com) Autenticación: Authorization: Bearer <token> para las API de administración; mTLS para el plano de datos de Kafka

Laboratorio de código

Objetivo: Implementar la capa de base de datos de TaskBoard con Terraform: un PostgreSQL Cluster de único primario y un conjunto de réplicas In-Memory DB, luego salida sus detalles de conexión como valores sensibles.

Requisitos previos:

• Cuenta de IONOS Cloud con token API (IONOS_TOKEN exportado)
• Terraform >= 1.5 con el proveedor ionoscloud
• Un centro de datos y base de datos LAN existente de las Unidades 2.1 y 2.2

Paso 1: Declarar variables sensibles

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

Paso 2: Agregar el PostgreSQL Cluster (de la Sección 1.1), luego validar:

terraform validate

Salida esperada:

Success! The configuration is valid.

Paso 3: Agregar el conjunto de réplicas In-Memory DB (de la Sección 2.1) y las salidas sensibles (de la Sección 4.1). Luego planificar:

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

Salida esperada:

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

Paso 4: Aplicar (la provisión es asíncrona y puede tardar 20 a 30 minutos para PostgreSQL):

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

Salida esperada:

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.

Paso 5: Leer la cadena de conexión sensible (nota -raw, requerido porque es sensible):

terraform output -raw pg_connection_string

Salida esperada:

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

Paso 6: Verificar la conexión PostgreSQL sobre TLS desde un host en la base de datos LAN:

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

Salida esperada:

PostgreSQL 16.x ...

Paso 7: Verificar la caché con un conjunto rápido de configuración y recuperación sobre TLS:

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

Salida esperada:

PONG

Lista de verificación:

• [ ] PostgreSQL Cluster alcanzó AVAILABLE y acepta una conexión TLS
• [ ] El conjunto de réplicas In-Memory DB responde a PING sobre TLS
• [ ] Todas las salidas de conexión están marcadas como sensibles y requieren -raw para leer
• [ ] No aparece ninguna contraseña en la salida del plan o en los registros de aplicación

Limpieza:

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

Errores comunes

1. Tratar instancias de Cluster como réplicas de solo lectura

   • Problema: Usted establece instances = 3 en el PostgreSQL Cluster y trata de enviar consultas de lectura a una segunda Node para descargar la primaria. Las conexiones todavía aterrizan en el mismo punto de conexión writable, y usted nunca obtiene escalado de lectura.
   • Por qué sucede: Las bases de datos gestionadas por IONOS ejecutan una primaria writable única. Las instancias adicionales son standbys de alta disponibilidad, no réplicas legibles, y no hay un punto de conexión de lectura separado.
   • Solución: Proporcionar una primaria y enrutrar lecturas calientes a través de In-Memory DB:

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

2. Filtrar credenciales a través de salidas de Terraform

   • Problema: Sus registros de CI imprimen la contraseña de la base de datos porque una salida no se marcó como sensible, y terraform apply la devuelve en la ejecución.
   • Por qué sucede: Las salidas predeterminadas son visibles. Cualquier cadena de conexión construida a partir de credenciales es de texto plano a menos que se indique.
   • Solución: Marcar cada salida que contenga credenciales sensitive = true y leer con -raw solo cuando sea necesario:

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

3. Intentar cambiar la contraseña de In-Memory DB más tarde

   • Problema: Usted ejecuta una actualización para rotar la contraseña de la caché y la aplicación falla o el cambio es ignorado.
   • Por qué sucede: Las credenciales de In-Memory DB se establecen solo en la creación y no se pueden modificar después.
   • Solución: Tratar la rotación como un reemplazo. Proporcionar un nuevo conjunto de réplicas, migrar el tráfico, y luego destruir el antiguo. Generar la contraseña una vez en la creación:

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

Resumen

Ahora puede aprovisionar todo el nivel de datos de TaskBoard como código: un PostgreSQL Cluster primario único para transacciones, un conjunto de réplicas In-Memory DB para sesiones y caché de lectura, y (utilizando el mismo patrón de recursos) Kafka, MongoDB, o MariaDB cuando un Workload los necesita. Sabe cómo enlazar cada Cluster a una LAN privada, establecer una ventana de mantenimiento, proporcionar credenciales de manera segura y exponer detalles de conexión como salidas sensibles Terraform. Lo más importante, es que aprovisiona alrededor del modelo de primario único: un Cluster writable único, con escalado de lectura manejado por la caché en lugar de por réplicas que no existen.

Puntos clave:

• ionoscloud_pg_cluster aprovisiona PostgreSQL (versiones 14, 15, 16; puerto 5432); instances son nodos de alta disponibilidad, no réplicas de lectura, y el rango es 1 a 5
• ionoscloud_inmemorydb_replicaset aprovisiona Redis 7.2 en el puerto 6379; las credenciales se establecen solo en la creación y no se pueden cambiar en su lugar
• ionoscloud_kafka_cluster más ionoscloud_kafka_cluster_topic aprovisionan Kafka 4.0.0 con 3 brokers y factor de replicación 3; el plano de datos se autentica con mTLS
• Cada salida de conexión debe estar marcada sensitive; el modo de SSL predeterminado de PostgreSQL es prefer y no se puede deshabilitar, por lo que la aplicación establece sslmode=require
• No hay réplicas de lectura legibles en ningún motor gestionado; aprovisione un primario único y escale las lecturas a través de In-Memory DB

Terminología importante:

• Modelo de primario único: La restricción de aprovisionamiento que las bases de datos gestionadas ejecutan un Cluster writable único sin réplicas legibles; las lecturas se escalan en la capa de caché.
• Conjunto de réplicas (In-Memory DB): Un Node activo más n-1 nodos de failover pasivos; los clientes se conectan a través del punto de conexión activo.
• Ventana de mantenimiento: Un intervalo de tiempo configurable semanal (hasta 4 horas) cuando la plataforma aplica parches y puede activar el failover de alta disponibilidad.
• Salida sensible: Una salida Terraform marcada sensitive = true para que esté oculta de los registros de plan, aplicación y CI, y requiere -raw para leer.
• Factor de replicación (Kafka): El número de copias de broker de cada partición; predeterminado en 3, coincidiendo con el Cluster de 3 brokers.

Próximos pasos

Continúe aprendiendo: Unidad 2.6: Verificación de conocimientos - Infraestructura como código

Temas relacionados:

• Unidad 2.4: Provisionamiento de almacenamiento como código
• Unidad 4.1: Integración de base de datos y caché