Skip to main content
El aprovisionamiento automático se ejecuta a partir del registro de servicio de un tenant. Puede crear los recursos de respaldo declarados para ese servicio, registrar sus credenciales y ejecutar la inicialización específica del producto antes de que el servicio atienda tráfico. Los recursos exactos y el ciclo de vida dependen del servicio. No supongas que todos los productos multi-tenant aprovisionan PostgreSQL, MongoDB, RabbitMQ o migraciones de la misma forma.

​
Ciclo de vida

  1. Crea una identidad de tenant. El tenant existe antes de asociarle un servicio de producto.
  2. Registra un servicio de tenant. El registro identifica el servicio de producto, su entorno, modo de aislamiento e información de conexión/aprovisionamiento. Tenant Manager usa dedicated y shared para los modos descritos en otros lugares como DATABASE y SCHEMA.
  3. Aprovisiona los recursos de respaldo compatibles. Tenant Manager invoca los adaptadores requeridos por el servicio registrado y su modo.
  4. Inicializa el producto. Las migraciones de esquema y el trabajo de readiness siguen el contrato de aprovisionamiento propio del producto.
  5. Opera el servicio. El producto usa su propio contrato de autenticación y enrutamiento para atender al tenant.
Un registro exitoso de servicio de tenant no garantiza que el ciclo de vida de base de datos, broker y migraciones sea idéntico para todos los productos. Verifica los requisitos de aprovisionamiento del producto antes de incorporar tenants de producción.

​
Recursos de almacenamiento

​
Base URLs para credenciales máquina a máquina

Un servicio de tenant puede declarar un mapa opcional baseUrls para los entornos staging y production. Tenant Manager selecciona la URL del entorno del tenant como targetBaseUrl al crear, rotar o recrear una credencial máquina a máquina. Cada valor debe ser una URL HTTP o HTTPS absoluta con host. No puede incluir una ruta diferente de /, query string, fragmento ni credenciales de usuario. HTTPS es obligatorio fuera de servicios locales al clúster Kubernetes (*.svc.cluster.local) y desarrollo local (localhost o 127.0.0.1). Actualizar baseUrls reemplaza el mapa del servicio. No reescribe las credenciales máquina a máquina existentes; rota o recrea la credencial cuando el endpoint deba cambiar.

​
Comprobaciones del operador

Antes de registrar un servicio de tenant en producción:
  • Confirma que el producto y el derecho admiten multi-tenancy.
  • Elige dedicated o shared según la configuración de almacenamiento compatible con el producto.
  • Valida recursos de respaldo, credenciales, ruta de red y proceso de migración del producto.
  • Registra baseUrls solo para URLs de endpoint válidas en el entorno del tenant.
  • Prueba aprovisionamiento, autenticación y rollback con la guía operativa del producto.

​
Páginas relacionadas

Multi-tenancy

Cómo los productos limitan solicitudes y cómo difieren los modos de aislamiento PostgreSQL.

Casos de uso

Elegir aislamiento PostgreSQL dedicado o compartido para un servicio.