Considerações sobre o uso de aplicativos de contêiner em uma solução multilocatária

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 alguns dos recursos de aplicativos de contêiner que são úteis para soluções multilocatário. Ele também fornece links para orientações que podem ajudá-lo durante a fase de planejamento.

Modelos de isolamento

Ao trabalhar com um sistema multilocatário que usa Aplicativos de Contêiner, você precisa determinar o nível necessário de isolamento. O Container Apps suporta diferentes modelos de multilocação:

• Você pode implementar multilocação confiável usando um ambiente compartilhado. Por exemplo, esse modelo pode ser apropriado quando seus locatários são todos de dentro da sua organização.
• Você pode implementar multilocação hostil implantando ambientes separados para cada locatário. Por exemplo, esse modelo pode ser apropriado quando você não confia no código que seus locatários executam.

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 mais adiante neste artigo.

Consideração	Um ambiente por inquilino	Aplicativos de contêiner específicos do locatário	Aplicativos de contêiner compartilhado
Isolamento de dados	Alto	Baixo	Baixo
Isolamento de desempenho	Alto	Média. Sem isolamento de rede.	Baixo
Complexidade da implantação	Médio	Baixo a médio	Baixo
Complexidade operacional	Médio	Baixo	Baixo
Custo dos recursos	Alto	Baixo	Baixo
Cenário de exemplo	Execução de cargas de trabalho multilocatárias hostis em ambientes isolados para segurança e conformidade	Otimizando custos, recursos de rede e operações para aplicativos multilocatários confiáveis	Implementando uma solução multilocatária no nível da lógica de negócios

Aplicativos de contêiner compartilhado

Talvez você queira considerar a implantação de aplicativos de contêiner compartilhados em um único ambiente de Aplicativos de Contêiner usado para todos os seus locatários.

Essa abordagem é geralmente eficiente em termos de custos 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 deve estar ciente de 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 é apropriado para cargas de trabalho hostis de multilocação nas quais você não confia no código em execução.

Além disso, esse modelo está potencialmente sujeito a preocupações barulhentas com vizinhos: a carga de trabalho de um locatário pode afetar o desempenho da carga de trabalho de outro locatário. Se você precisar fornecer taxa de transferência dedicada para mitigar essa preocupação, o modelo de aplicativos de contêiner compartilhado pode não ser apropriado.

Nota

O padrão Selos de Implantação é útil quando os locatários estão em modelos de cálculo de custos diferentes. Por exemplo, os locatários podem ser atribuídos a ambientes de Aplicativos de Contêiner compartilhados ou dedicados, dependendo de sua camada de preço. Essa estratégia de implantação permite que você ultrapasse os limites dos Aplicativos de Contêiner para uma única assinatura por região e dimensione linearmente à medida que o número de locatários cresce.

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 fornece isolamento lógico entre cada locatário. Proporciona as seguintes vantagens:

• Eficiência de custo. Ao compartilhar um ambiente de Aplicativos de Contêiner, rede virtual e outros recursos anexados, como um espaço de trabalho do Log Analytics, você geralmente pode reduzir o custo geral e a complexidade de gerenciamento por locatário.
• Separação de upgrades e implantações. Os binários de aplicativos de cada locatário podem ser implantados e atualizados independentemente daqueles de outros aplicativos de contêiner no mesmo ambiente. Essa abordagem pode ser útil se você precisar atualizar locatários diferentes para versões específicas do seu código em momentos diferentes.
• Isolamento de recursos. Cada aplicativo de contêiner em seu ambiente recebe seus próprios recursos de CPU e memória. Se um locatário específico precisar de mais recursos, você poderá alocar mais CPU e memória para o aplicativo de contêiner específico desse locatário. Lembre-se de que há limites para as alocações totais de CPU e memória em aplicativos de contêiner.

No entanto, essa abordagem não fornece isolamento de hardware ou rede entre locatários. Todos os aplicativos de contêiner em um único ambiente compartilham a mesma rede virtual. Você precisa ser capaz de confiar que as cargas de trabalho implantadas nos aplicativos não usarão indevidamente os recursos compartilhados.

O Container Apps tem suporte integrado para Dapr, que usa um design modular para fornecer funcionalidade como componentes. Em Aplicativos de Contêiner, os componentes do Dapr são recursos no nível do ambiente. Ao compartilhar um único ambiente entre vários locatários, certifique-se de definir corretamente o escopo dos componentes do Dapr para o aplicativo de contêiner específico do locatário correto para garantir o isolamento e evitar o risco de vazamento de dados.

Nota

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 são projetados para cenários de implantação nos quais você precisa ter várias versões do seu aplicativo em execução como parte de um processo de distribuição de atualização, como em implantações azuis/verdes e testes A/B.

Um ambiente por inquilino

Você pode considerar a implantação de 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, que é compartilhada por todos os aplicativos dentro do ambiente. Cada ambiente tem seu próprio Dapr e configuração de monitoramento.

Essa abordagem fornece o nível mais forte de dados e isolamento de desempenho porque os dados e o tráfego de cada locatário são isolados em um ambiente específico. E quando você usa esse modelo, seus aplicativos não precisam estar cientes de multilocação. Ao usar essa abordagem, você tem um controle mais granular sobre como aloca recursos para aplicativos de contêiner no ambiente. Você pode determinar alocações com base nos requisitos do seu locatário. Por exemplo, alguns locatários podem exigir mais recursos de CPU e memória do que outros, para que você possa fornecer mais recursos aos aplicativos desses locatários enquanto se beneficia do isolamento que os ambientes específicos do locatário oferecem.

No entanto, há limites baixos para quantos ambientes você pode implantar em uma assinatura por região. Em algumas situações, você pode aumentar essas cotas criando um tíquete de suporte do Azure.

Certifique-se de saber o crescimento esperado no número de locatários antes de implementar esse modelo de isolamento. Lembre-se de que essa abordagem geralmente incorre em um custo total de propriedade mais alto e em níveis mais altos de implantação e complexidade operacional, devido aos recursos extras necessários para implantar e gerenciar.

Recursos de aplicativos de contêiner que suportam multilocação

Nomes de domínio personalizados

Os Aplicativos de Contêiner permitem que você use DNS curinga e adicione seus próprios certificados TLS curinga. Quando você usa subdomínios específicos do locatário, os certificados DNS e TLS curinga permitem que você dimensione facilmente sua solução para um grande número de locatários sem a necessidade de reconfigurar manualmente 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 que você possa vincular 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, se o token não for válido ou se a solicitação não for autorizada, você poderá configurar Aplicativos de Contêiner para bloquear a solicitação ou redirecioná-la para seu provedor de identidade para que o usuário possa entrar.

Se seus locatários usarem o Microsoft Entra ID como o provedor de identidade, você poderá configurar os Aplicativos de Contêiner para usar o ponto de extremidade /common para validar tokens de usuário. Isso garante que, independentemente do locatário do Microsoft Entra do usuário, seus tokens sejam validados e aceitos.

Você também pode integrar Aplicativos de Contêiner com o Azure Ative Directory B2C para autenticação de usuário por meio de provedores de identidade de parceiros.

Para obter mais informações, veja estes recursos:

• Autorização de Aplicativos de Contêiner do Azure
• Habilitar autenticação e autorização em Aplicativos de Contêiner do Azure com a ID do Microsoft Entra

Nota

Os recursos de autenticação e autorização em Aplicativos de Contêiner são semelhantes aos do Serviço de Aplicativo do Azure. No entanto, existem algumas diferenças. Para obter mais informações, consulte Considerações sobre o uso da autenticação interna.

Identidades geridas

Você pode usar identidades gerenciadas do Microsoft Entra ID 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 de serviço a serviço. Você pode conceder permissões específicas à identidade do seu aplicativo contêiner para controle de acesso baseado em função.

Ao usar identidades gerenciadas, tenha em mente a escolha do 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 do Azure.

Contribuidores

Este artigo é mantido pela Microsoft. Foi originalmente escrito pelos seguintes contribuidores.

Principais autores:

• Daniel Larsen - Brasil | Engenheiro de Clientes Principal, FastTrack for Azure
• Will Velida - Brasil | Engenheiro de Clientes 2, FastTrack para Azure

Outros contribuidores:

• John Downs - Brasil | Engenheiro de Software Principal
• Chade Kittel - Brasil | Engenheiro de Software Principal, Microsoft
• Xuhong Liu - Brasil | Engenheiro de Serviços Sênior, FastTrack for Azure
• Aarthi Murugan - Brasil | Gerente de Programa Sênior, CS Tech Strategy App Innovation
• Kendall Roden - Brasil | Gerente de Programa Sênior, Aplicativos de Contêiner do Azure
• Paolo Salvatori - Brasil | Engenheiro de Clientes Principal, FastTrack for Azure
• Arsen Vladimirskiy - Brasil | Engenheiro de Clientes Principal, FastTrack for Azure

Para ver perfis não públicos do LinkedIn, inicie sessão no LinkedIn.

Próximos passos

• Visão geral do produto Container Apps
• Documentação de aplicativos de contêiner

Recursos relacionados

• Recursos para arquitetos e desenvolvedores de soluções multilocatárias
• Arquitete soluções multilocatárias no Azure
• Lista de verificação para arquitetar e criar soluções multilocatárias no Azure