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

​
Recursos de armazenamento

​
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

Multi-tenancy

Como os produtos escopam requisições e como os modos de isolamento PostgreSQL diferem.

Casos de uso

Como escolher isolamento PostgreSQL dedicado ou compartilhado para um serviço.