Skip to main content
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.
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.

​
Recursos de armazenamento

​
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

Multi-tenancy

Como os produtos definem o escopo das requisições e como os modos de isolamento do PostgreSQL diferem.

Casos de uso

Escolher o isolamento dedicado ou compartilhado no PostgreSQL para um serviço.