> ## Documentation Index
> Fetch the complete documentation index at: https://docs.lerian.studio/llms.txt
> Use this file to discover all available pages before exploring further.

# Aprovisionamiento automático

> Cómo Tenant Manager aprovisiona servicios de tenant compatibles y valida los endpoints usados para credenciales máquina a máquina.

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.

<Note>
  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.
</Note>

## Recursos de almacenamiento

***

| Recurso          | Comportamiento de Tenant Manager                                                                                                                                                           |
| :--------------- | :----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **PostgreSQL**   | Usa una base dedicada en modo `dedicated` o un esquema de tenant en una base compartida en modo `shared`.                                                                                  |
| **MongoDB**      | Usa una base de tenant en modo `dedicated` o un prefijo de colección de tenant en modo `shared`.                                                                                           |
| **RabbitMQ**     | Aprovisiona recursos de mensajería según el modo; no dependas de una convención universal de nombres de vhost o colas.                                                                     |
| **Credenciales** | Las credenciales de servicio se almacenan y resuelven mediante la ruta de credenciales del servicio registrado. Trata la rotación y los controles de acceso como específicos del servicio. |

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

***

<CardGroup cols={2}>
  <Card title="Multi-tenancy" icon="layer-group" href="/es/multi-tenancy" cta="Ver descripción general">
    Cómo los productos limitan solicitudes y cómo difieren los modos de aislamiento PostgreSQL.
  </Card>

  <Card title="Casos de uso" icon="lightbulb" href="/es/multi-tenancy/use-cases" cta="Ver ejemplos">
    Elegir aislamiento PostgreSQL dedicado o compartido para un servicio.
  </Card>
</CardGroup>