Skip to main content
El aprovisionamiento automático se guía por el registro de servicio de un tenant. Puede crear los recursos subyacentes declarados para ese servicio, registrar sus credenciales y ejecutar la inicialización específica del producto que hace falta antes de que el servicio acepte tráfico. Los recursos exactos y el ciclo de vida son específicos de cada servicio. No supongas que cada producto multi-tenant aprovisiona PostgreSQL, MongoDB, RabbitMQ o las migraciones de la misma manera.

​
Ciclo de vida

  1. Crea una identidad de tenant. El tenant existe antes de que se le adjunte un servicio de producto.
  2. Registra un servicio de tenant. El registro identifica el servicio de producto, su entorno, el modo de aislamiento y la información de conexión y aprovisionamiento. Tenant Manager usa dedicated y shared para los modos de almacenamiento descritos en otro lugar como DATABASE y SCHEMA.
  3. Aprovisiona los recursos subyacentes admitidos. Tenant Manager invoca los adaptadores que requieren el servicio registrado y el modo.
  4. Inicializa el producto. Las migraciones de esquema y el trabajo de readiness siguen el contrato de aprovisionamiento propio de ese producto.
  5. Opera el servicio. El producto usa su propio contrato de autenticación y enrutamiento para servir al tenant.
Un registro exitoso de servicio de tenant no es una garantía general de que el ciclo de vida de base de datos, broker y migraciones de cada producto sea idéntico. Verifica los requisitos de aprovisionamiento específicos del producto antes de incorporar tenants de producción.

​
Recursos de almacenamiento

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

Un servicio de tenant puede declarar un mapa baseUrls opcional para los entornos staging y production. Tenant Manager selecciona la URL del entorno del tenant como targetBaseUrl cuando crea, rota o recrea una credencial máquina a máquina. Cada valor debe ser una URL HTTP o HTTPS absoluta con un host. No puede incluir una ruta distinta de /, query string, fragmento ni credenciales de usuario. HTTPS es obligatorio fuera de los servicios locales del cluster de Kubernetes (*.svc.cluster.local) y del 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 debe cambiar.

​
Verificaciones del operador

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

​
Páginas relacionadas

Multi-tenancy

Cómo los productos acotan las solicitudes y en qué difieren los modos de aislamiento de PostgreSQL.

Casos de uso

Elegir el aislamiento de PostgreSQL dedicado o compartido para un servicio.