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

# Provisionamento automático

> Como o Tenant Manager provisiona serviços de tenant compatíveis e valida os endpoints usados para credenciais máquina a máquina.

O provisionamento automático é acionado pelo registro de serviço de um tenant. Ele pode criar os recursos de apoio declarados para esse serviço, registrar suas credenciais e executar a inicialização específica do produto antes de o serviço atender tráfego.

Os recursos exatos e o ciclo de vida dependem do serviço. Não presuma que todos os produtos multi-tenant provisionam PostgreSQL, MongoDB, RabbitMQ ou migrações da mesma forma.

## Ciclo de vida

***

1. **Crie uma identidade de tenant.** O tenant existe antes de um serviço de produto ser associado a ele.
2. **Registre um serviço de tenant.** O registro identifica o serviço de produto, seu ambiente, modo de isolamento e informações de conexão/provisionamento. O Tenant Manager usa `dedicated` e `shared` para os modos descritos em outros lugares como `DATABASE` e `SCHEMA`.
3. **Provisione os recursos de apoio compatíveis.** O Tenant Manager invoca os adaptadores exigidos pelo serviço registrado e seu modo.
4. **Inicialize o produto.** Migrações de schema e o trabalho de readiness seguem o contrato de provisionamento do próprio produto.
5. **Opere o serviço.** O produto usa seu próprio contrato de autenticação e roteamento para atender o tenant.

<Note>
  Um registro de serviço de tenant bem-sucedido não garante que o ciclo de vida de banco, broker e migrações seja idêntico para todos os produtos. Verifique os requisitos de provisionamento do produto antes de onboardar tenants de produção.
</Note>

## Recursos de armazenamento

***

| Recurso         | Comportamento do Tenant Manager                                                                                                                                         |
| :-------------- | :---------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **PostgreSQL**  | Usa um banco dedicado no modo `dedicated` ou um schema de tenant em um banco compartilhado no modo `shared`.                                                            |
| **MongoDB**     | Usa um banco de tenant no modo `dedicated` ou um prefixo de coleção de tenant no modo `shared`.                                                                         |
| **RabbitMQ**    | Provisiona recursos de mensageria conforme o modo; não dependa de uma convenção universal de nomes de vhost ou filas.                                                   |
| **Credenciais** | Credenciais de serviço são armazenadas e resolvidas pelo caminho de credenciais do serviço registrado. Trate rotação e controles de acesso como específicos do serviço. |

## Base URLs para credenciais máquina a máquina

***

Um serviço de tenant pode declarar um mapa opcional `baseUrls` para os ambientes `staging` e `production`. O Tenant Manager seleciona a URL do ambiente do tenant como `targetBaseUrl` ao criar, rotacionar ou recriar uma credencial máquina a máquina.

Cada valor deve ser uma URL HTTP ou HTTPS absoluta com host. Não pode incluir caminho diferente de `/`, query string, fragmento ou credenciais de usuário. HTTPS é obrigatório fora de serviços Kubernetes locais ao cluster (`*.svc.cluster.local`) e desenvolvimento local (`localhost` ou `127.0.0.1`).

Atualizar `baseUrls` substitui o mapa do serviço. Isso não reescreve credenciais máquina a máquina existentes; rotacione ou recrie a credencial quando o endpoint precisar mudar.

## Verificações do operador

***

Antes de registrar um serviço de tenant em produção:

* Confirme que o produto e o direito de uso contratado suportam multi-tenancy.
* Escolha `dedicated` ou `shared` conforme a configuração de armazenamento suportada pelo produto.
* Valide recursos de apoio, credenciais, caminho de rede e processo de migração do produto.
* Registre `baseUrls` apenas para URLs de endpoint válidas para o ambiente do tenant.
* Teste provisionamento, autenticação e rollback usando o guia operacional do produto.

## Páginas relacionadas

***

<CardGroup cols={2}>
  <Card title="Multi-tenancy" icon="layer-group" href="/pt/multi-tenancy" cta="Ver visão geral">
    Como os produtos escopam requisições e como os modos de isolamento PostgreSQL diferem.
  </Card>

  <Card title="Casos de uso" icon="lightbulb" href="/pt/multi-tenancy/use-cases" cta="Ver exemplos">
    Como escolher isolamento PostgreSQL dedicado ou compartilhado para um serviço.
  </Card>
</CardGroup>