Suporte por produto
O escopo e a configuração de tenants dependem do produto. A documentação de produto descreve atualmente operação multi-tenant para:
Use o guia de autenticação e configuração do produto que você vai implantar. Não presuma que uma variável de ambiente, um claim de JWT ou um comportamento de API documentado para um produto se aplica a outro.
Autenticação e escopo de requisições
Cada produto valida a identidade de quem chama e obtém seu contexto de tenant conforme o contrato de autenticação desse produto. Em uma implantação multi-tenant, use o fluxo compatível do Access Manager e inclua o token Bearer exigido pelo produto. A plataforma não define um claim universal
tenantId nem um header de tenant universal para todos os produtos. Uma integração deve seguir o claim e o comportamento de roteamento documentados para seu produto; não adicione um identificador de tenant a uma requisição a menos que esse produto o exija explicitamente.
Multi-tenancy é uma capacidade operacional, não uma promessa de que todos os produtos Lerian tenham o mesmo middleware de autenticação ou a mesma superfície de configuração.
Isolamento de armazenamento
Os registros de serviço do Tenant Manager usam os valores
dedicated e shared. Esta documentação usa os conceitos de deployment correspondentes:
DATABASE(dedicated) — um tenant recebe um banco PostgreSQL dedicado.SCHEMA(shared) — os tenants compartilham um banco PostgreSQL e cada um recebe um schema dedicado.
DATABASE / SCHEMA é específica do PostgreSQL. Os demais datastores usam suas próprias regras de roteamento e provisionamento conforme o modo; não infira comportamento de schemas PostgreSQL para MongoDB ou RabbitMQ.
Escolha o modo por serviço conforme sua configuração suportada, obrigações regulatórias, carga esperada e requisitos de recuperação.
Movendo um tenant entre modos
Mover um tenant de armazenamento compartilhado para dedicado é uma migração planejada pelo operador, não um fluxo automático genérico da plataforma. Valide o caminho de migração do produto alvo, requisitos de consistência de dados, janela de manutenção, plano de backup/restauração e rollback antes de alterar o registro de serviço do tenant. A identidade do tenant pode permanecer estável, mas não presuma que todos os produtos conseguem mover dados entre modos sem uma migração específica da implementação.
Operando cada modelo de deployment
Lerian Cloud
A Lerian opera a infraestrutura multi-tenant. Siga a documentação de API e autenticação do produto; seu token e o contrato de roteamento do produto determinam o escopo da requisição.BYOC Multi-Tenant
O operador configura os produtos compatíveis, serviços de tenant, modo de armazenamento, recursos de apoio e autenticação. Trate a referência de configuração de cada produto como autoritativa.BYOC Single-Tenant ou desenvolvimento local
Multi-tenancy não é habilitada automaticamente. Os requisitos de autenticação dependem do produto e do ambiente; para o Midaz, implantações de produção e multi-tenant exigem autenticação, enquanto uma implantação single-tenant não produtiva permitida pode desabilitá-la.Configuração
Não existe um contrato de variáveis de ambiente multi-tenant compartilhado entre produtos. Não copie uma lista genérica de variáveis
MULTI_TENANT_* entre Midaz, Tracer, Reporter e Matcher.
Para o Midaz, a operação multi-tenant requer sua configuração específica de produto, incluindo MULTI_TENANT_ENABLED, PLUGIN_AUTH_ENABLED e APPLICATION_NAME. Confirme os valores atuais, padrões e dependências na referência de configuração do Midaz antes de implantar. Os demais produtos têm seus próprios contratos de configuração.
Páginas relacionadas
Provisionamento automático
Como serviços de tenant e seus recursos de apoio são provisionados.
Casos de uso
Como escolher isolamento PostgreSQL dedicado ou compartilhado.
Modelos de deployment
Compare Lerian Cloud, BYOC Single-Tenant e configurações BYOC Multi-Tenant compatíveis.
Access Manager
Entenda os fluxos de autenticação compatíveis com os produtos que você implanta.