Observação
O acesso a essa página exige autorização. Você pode tentar entrar ou alterar diretórios.
O acesso a essa página exige autorização. Você pode tentar alterar os diretórios.
Você pode usar os Aplicativos de Contêiner do Azure para executar microsserviços e aplicativos em contêineres em uma plataforma sem servidor. Este artigo descreve vários recursos de Aplicativos de Contêiner que são úteis para soluções multilocatários. Ele também fornece recursos que podem ajudá-lo durante sua fase de planejamento.
Modelos de isolamento
Quando você trabalha com um sistema multilocatário que usa Aplicativos de Contêiner, você precisa determinar o nível necessário de isolamento. Os Aplicativos de Contêiner dão suporte a diferentes modelos de multilocação:
Você pode implementar a multilocação confiável usando um ambiente compartilhado. Por exemplo, esse modelo pode ser adequado quando seus locatários são todos de dentro de sua organização.
Você pode implementar a multilocação hostil implantando ambientes separados para cada locatário. Por exemplo, esse modelo pode ser adequado quando você não confia no código executado pelos locatários.
A tabela a seguir resume as diferenças entre os principais modelos de isolamento de locação para Aplicativos de Contêiner. Os modelos são descritos posteriormente neste artigo.
| Consideração | Um ambiente para cada locatário | Aplicativos de contêiner específicos do locatário | Aplicativos de contêiner compartilhados |
|---|---|---|---|
| Isolamento de dados | Alto | Baixo | Baixo |
| Isolamento de desempenho | Alto | Médio, sem isolamento de rede | Baixo |
| Complexidade da implantação | Médio | Baixo a médio | Baixo |
| Complexidade operacional | Médio | Baixo | Baixo |
| Custo de recurso | Alto | Baixo | Baixo |
| Cenário de exemplo | Executa cargas de trabalho multilocatários hostis em ambientes isolados para segurança e conformidade. | Otimiza o custo, os recursos de rede e as operações para aplicativos multilocatários confiáveis. | Implementa uma solução multilocatário no nível de lógica de negócios. |
Aplicativos de contêiner compartilhados
Considere implantar aplicativos de contêiner compartilhados em um único ambiente de Aplicativos de Contêiner que todos os seus locatários usam.
Essa abordagem normalmente é econômica e requer a menor sobrecarga operacional porque há menos recursos para gerenciar.
No entanto, se você quiser usar esse modelo de isolamento, o código do aplicativo deverá ser compatível com multilocação. Esse modelo de isolamento não garante isolamento no nível de rede, computação, monitoramento ou dados. O código do aplicativo deve lidar com o isolamento do locatário. Esse modelo não é adequado para cargas de trabalho hostis de multilocação nas quais você não confia no código que está em execução.
Esse modelo está potencialmente sujeito a preocupações de vizinhos barulhentos, o que significa que a carga de trabalho de um locatário pode afetar o desempenho da carga de trabalho de outro locatário. Se você precisar fornecer a taxa de transferência dedicada para atenuar essa preocupação, o modelo de aplicativos de contêiner compartilhado poderá não ser adequado.
Observação
O Padrão de Selos de implantação é útil quando os locatários estão em diferentes modelos de preços. Por exemplo, os locatários podem ser atribuídos a ambientes de Aplicativos de Contêiner compartilhados ou dedicados, dependendo do tipo de preço. Essa estratégia de implantação permite que você vá além do limite dos Aplicativos de Contêiner para uma assinatura única para cada região e dimensione linearmente à medida que o número de locatários aumenta.
Aplicativos de contêiner específicos do locatário
Outra abordagem que você pode considerar é isolar seus locatários implantando aplicativos de contêiner específicos do locatário em um ambiente compartilhado.
Esse modelo de isolamento garante a separação lógica entre locatários, fornecendo várias vantagens:
Eficiência de custo: Ao compartilhar um ambiente de Aplicativos de Contêiner, uma rede virtual e outros recursos anexados, como um workspace do Log Analytics, você geralmente pode reduzir sua complexidade geral de custo e gerenciamento para cada locatário.
Separação de atualizações e implantações: Os binários de aplicativo de cada locatário podem ser implantados e atualizados independentemente dos binários de outros aplicativos de contêiner no mesmo ambiente. Essa abordagem pode ser útil se você precisar atualizar diferentes locatários para versões específicas do código em momentos diferentes.
Isolamento de recursos: Cada aplicativo de contêiner em seu ambiente é alocado seus próprios recursos de CPU e memória. Se um locatário específico exigir mais recursos, você poderá alocar mais CPU e memória para o aplicativo de contêiner específico desse locatário. Tenha em mente que há limites no total de alocações de CPU e memória em aplicativos de contêiner.
No entanto, essa abordagem não fornece nenhum isolamento de hardware ou rede entre locatários. Todos os aplicativos de contêiner em um único ambiente compartilham a mesma rede virtual. Você deve ser capaz de confiar que as cargas de trabalho implantadas nos aplicativos não usam indevidamente os recursos compartilhados.
Os Aplicativos de Contêiner têm suporte interno para o Dapr, que usa um design modular para fornecer funcionalidade como componentes. Em Aplicações em Contêineres, os componentes Dapr são recursos de nível de ambiente. Ao compartilhar um único ambiente entre vários inquilinos, verifique se os componentes Dapr estão devidamente atribuídos ao aplicativo de contêiner específico de cada inquilino para garantir o isolamento e evitar o vazamento de dados.
Observação
Não use revisões para criar versões diferentes do seu aplicativo para locatários diferentes. As revisões não fornecem isolamento de recursos. Eles foram projetados para cenários de implantação em que várias versões de um aplicativo devem ser executadas durante uma distribuição de atualização. Essa abordagem inclui estratégias como implantações azul-verde e testes A/B.
Um ambiente para cada locatário
Considere implantar um ambiente de Aplicativos de Contêiner para cada um de seus locatários. Um ambiente de Aplicativos de Contêiner é o limite de isolamento em torno de um grupo de aplicativos de contêiner. Um ambiente fornece computação e isolamento de rede no plano de dados. Cada ambiente é implantado em sua própria rede virtual. Todos os aplicativos dentro do ambiente compartilham essa rede virtual. Cada ambiente tem sua própria configuração de Dapr e monitoramento.
Essa abordagem fornece o nível mais forte de isolamento de dados e desempenho porque os dados e o tráfego de cada locatário são isolados para um ambiente específico. Esse modelo não exige que seus aplicativos sejam com reconhecimento multilocatário. Ao usar essa abordagem, você tem um controle mais granular sobre como aloca recursos para aplicativos de contêiner dentro do ambiente. Você pode determinar alocações com base nos requisitos do locatário. Por exemplo, alguns locatários podem exigir mais recursos de CPU e memória do que outros. Você pode oferecer mais recursos aos aplicativos desses locatários, enquanto se beneficia do isolamento que os ambientes específicos para locatários proporcionam.
No entanto, há limites baixos no número de ambientes que você pode implantar em uma assinatura para cada região. Em alguns cenários, você pode aumentar essas cotas criando um tíquete de suporte do Azure.
Verifique se você sabe o crescimento esperado no número de locatários antes de implementar esse modelo de isolamento. Essa abordagem geralmente incorre em um TCO (custo total de propriedade) mais alto e níveis mais altos de implantação e complexidade operacional devido aos recursos extras que você precisa implantar e gerenciar.
Recursos de Aplicativos de Contêiner que dão suporte à multilocação
Os seguintes recursos de Aplicativos de Contêiner dão suporte à multilocação.
Nomes de domínio personalizados
Os Aplicativos de Contêiner permitem que você use DNS (Sistema de Nomes de Domínio) curinga e adicione seus próprios certificados TLS (Segurança de Camada de Transporte) curinga. Ao usar subdomínios específicos do locatário, ambos os certificados DNS e TLS curinga permitem dimensionar facilmente a solução para um grande número de locatários, sem precisar de uma reconfiguração manual para cada novo locatário.
Em Aplicativos de Contêiner, você gerencia certificados no nível do ambiente. A entrada também deve ser habilitada para o aplicativo de contêiner antes de associar um domínio personalizado a ele.
Solicitar autenticação e autorização
Os Aplicativos de Contêiner podem validar tokens de autenticação em nome do seu aplicativo. Se uma solicitação não contiver um token, o token não for válido ou a solicitação não estiver autorizada, você poderá configurar os Aplicativos de Contêiner para bloquear a solicitação ou redirecionar a solicitação para o provedor de identidade para que o usuário possa entrar.
Se os locatários usarem o Microsoft Entra ID como provedor de identidade, você poderá configurar os Aplicativos de Contêiner para usar o /ponto de extremidade comum para validar tokens de usuário. Essa abordagem garante que os tokens dos usuários sejam validados e aceitos, independentemente do locatário do Microsoft Entra do usuário.
Você também pode integrar os Aplicativos de Contêiner ao ID Externo do Microsoft Entra para autenticação de usuário por meio de provedores de identidade de parceiros.
Para obter mais informações, consulte os seguintes recursos:
- Autorização de Aplicativos de Contêiner
- Habilitar autenticação e autorização em Aplicativos de Contêiner com a ID do Microsoft Entra
Observação
Os recursos de autenticação e autorização em Aplicativos de Contêiner são semelhantes aos recursos no Serviço de Aplicativo do Azure. No entanto, há algumas diferenças. Para obter mais informações, consulte Considerações sobre como usar a autenticação interna.
Identidades gerenciadas
Você pode usar identidades gerenciadas da ID do Microsoft Entra para permitir que seu aplicativo de contêiner acesse outros recursos autenticados pelo Microsoft Entra ID. Quando você usa identidades gerenciadas, seu aplicativo de contêiner não precisa gerenciar credenciais para comunicação serviço a serviço. Você pode conceder permissões específicas à identidade do aplicativo de contêiner para o controle de acesso baseado em função do Azure (Azure RBAC).
Ao usar identidades gerenciadas, tenha em mente sua escolha de modelo de isolamento. Por exemplo, suponha que você compartilhe seus aplicativos de contêiner entre todos os seus locatários e implante bancos de dados específicos do locatário. Você precisa garantir que o aplicativo de um locatário não possa acessar o banco de dados de um locatário diferente.
Para obter mais informações, consulte Identidades gerenciadas em Aplicativos de Contêiner.
Perfis de carga de trabalho na computação dedicada
Os Aplicativos de Contêiner fornecem um plano dedicado que permite reservar recursos dedicados para um locatário. Esse plano é útil para limitar os recursos disponíveis para um locatário, que pode ser compartilhado em vários aplicativos de contêiner. Ele também ajuda a atender a requisitos de locatário específicos, como maiores taxas de memória para CPU ou disponibilidade de GPU.
Para obter mais informações, consulte perfis de carga de trabalho em Aplicativos de Contêiner.
Roteamento baseado em regra
O roteamento baseado em regra permite direcionar o tráfego de entrada para aplicativos de contêiner específicos ou revisões de aplicativo de contêiner. As solicitações podem ser roteadas com base no caminho da solicitação HTTP, e você pode reescrever esse caminho na URL. Esse recurso é útil para sistemas multilocatários que precisam mapear solicitações para aplicativos de contêiner específicos do locatário ou revisões que utilizam o caminho na solicitação. Esse recurso é normalmente usado com o modelo de isolamento de aplicativos de contêiner específicos do locatário.
Para obter mais informações, consulte Usar o roteamento baseado em regra com Aplicativos de Contêiner.
Contribuidores
A Microsoft mantém este artigo. Os colaboradores a seguir escreveram este artigo.
Autores principais:
- Daniel Larsen | Engenheiro de Cliente Principal, FastTrack para Azure
- Will Velida | Engenheiro do Cliente 2, FastTrack for Azure
Outros colaboradores:
- John Downs | Principal Engenheiro de Software, Padrões do Azure & Práticas
- Chad Kittel | Principal Engenheiro de Software, Padrões do Azure & Práticas
- Xuhong Liu | Engenheiro de Serviço Sênior, FastTrack para Azure
- Aarthi Murugan | Gerente Sênior de Programas, Estratégia Técnica de Inovação em Aplicativos CS
- Kendall Roden | Gerenciador de Programas Sênior, Aplicativos de Contêiner
- Paolo Salvatori | Engenheiro de Cliente Principal, FastTrack for Azure
- Daniel Scott-Raynsford | Arquiteto de Soluções de Parceiro, Dados &AI
- Arsen Vladimirskiy | Engenheiro principal de atendimento ao cliente, FastTrack for Azure
Para ver perfis não públicos no LinkedIn, entre no LinkedIn.