> ## 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 os serviços de tenant com suporte e valida os endpoints de serviço usados para credenciais máquina a máquina.

O provisionamento automático é conduzido pelo registro de serviço de um tenant. Ele pode criar os recursos de apoio declarados para esse serviço, gravar as credenciais deles e rodar a inicialização específica do produto necessária antes que o serviço aceite tráfego.

Os recursos exatos e o ciclo de vida são específicos de cada serviço. Não suponha que cada produto multi-tenant provisiona 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 anexado a ele.
2. **Registre um serviço de tenant.** O registro identifica o serviço do produto, o ambiente dele, o modo de isolamento e as informações de conexão/provisionamento. O Tenant Manager usa `dedicated` e `shared` para os modos de armazenamento descritos em outros pontos como `DATABASE` e `SCHEMA`.
3. **Provisione os recursos de apoio com suporte.** O Tenant Manager invoca os adaptadores que o serviço e o modo registrados exigem.
4. **Inicialize o produto.** As 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 o próprio contrato de autenticação e roteamento para servir o tenant.

<Note>
  Um registro de serviço de tenant bem-sucedido não é uma garantia geral de que o ciclo de vida de banco de dados, broker e migrações de cada produto é idêntico. Verifique os requisitos de provisionamento específicos do produto antes de fazer o onboarding de tenants de produção.
</Note>

## Recursos de armazenamento

***

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

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

***

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

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

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

## Verificações do operador

***

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

* Confirme que o produto e o direito de uso oferecem suporte a multi-tenancy.
* Selecione `dedicated` ou `shared` conforme a configuração de armazenamento com suporte do produto.
* Valide os recursos de apoio, as credenciais, o caminho de rede e o processo de migração do produto.
* Registre `baseUrls` apenas para URLs de endpoint válidas para o ambiente do tenant.
* Teste o provisionamento, a autenticação e o rollback com o guia operacional do próprio produto.

## Páginas relacionadas

***

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

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