Descrição Geral da Arquitetura de Rede de Ambientes de Serviço de Aplicações

Importante

Este artigo é sobre o Ambiente do Serviço de Aplicativo v1. O Ambiente do Serviço de Aplicativo v1 será desativado em 31 de agosto de 2024. Há uma nova versão do Ambiente do Serviço de Aplicativo que é mais fácil de usar e é executada em uma infraestrutura mais poderosa. Para saber mais sobre a nova versão, comece com a Introdução ao Ambiente do Serviço de Aplicativo. Se você estiver usando o Ambiente do Serviço de Aplicativo v1, siga as etapas neste artigo para migrar para a nova versão.

A partir de 29 de janeiro de 2024, você não poderá mais criar novos recursos do Ambiente do Serviço de Aplicativo v1 usando qualquer um dos métodos disponíveis, incluindo modelos ARM/Bicep, Portal do Azure, CLI do Azure ou API REST. Você deve migrar para o Ambiente do Serviço de Aplicativo v3 antes de 31 de agosto de 2024 para evitar a exclusão de recursos e a perda de dados.

Os Ambientes do Serviço de Aplicativo são sempre criados em uma sub-rede de uma rede virtual - os aplicativos executados em um Ambiente do Serviço de Aplicativo podem se comunicar com pontos de extremidade privados localizados na mesma topologia de rede virtual. Como os clientes podem bloquear partes de sua infraestrutura de rede virtual, é importante entender os tipos de fluxos de comunicação de rede que ocorrem com um Ambiente do Serviço de Aplicativo.

Fluxo geral da rede

Quando um Ambiente de Serviço de Aplicativo (ASE) usa um endereço IP virtual (VIP) público para aplicativos, todo o tráfego de entrada chega a esse VIP público. Isso inclui tráfego HTTP e HTTPS para aplicativos e outro tráfego para FTP, funcionalidade de depuração remota e operações de gerenciamento do Azure. Para obter uma lista completa das portas específicas (obrigatórias e opcionais) disponíveis no VIP público, consulte o artigo sobre como controlar o tráfego de entrada para um Ambiente do Serviço de Aplicativo.

Os Ambientes do Serviço de Aplicativo também oferecem suporte à execução de aplicativos vinculados apenas a um endereço interno de rede virtual, também conhecido como endereço ILB (balanceador de carga interno). Em um ASE habilitado para ILB, o tráfego HTTP e HTTPS para aplicativos e chamadas de depuração remota, chegue ao endereço ILB. Para as configurações ILB-ASE mais comuns, o tráfego FTP/FTPS também chegará ao endereço ILB. No entanto, as operações de gerenciamento do Azure ainda fluirão para as portas 454/455 no VIP público de um ASE habilitado para ILB.

O diagrama abaixo mostra uma visão geral dos vários fluxos de rede de entrada e saída para um Ambiente do Serviço de Aplicativo em que os aplicativos estão vinculados a um endereço IP virtual público:

Um Ambiente do Serviço de Aplicativo pode se comunicar com pontos de extremidade de clientes particulares. Por exemplo, os aplicativos executados no Ambiente do Serviço de Aplicativo podem se conectar ao(s) servidor(es) de banco de dados em execução em máquinas virtuais IaaS na mesma topologia de rede virtual.

Importante

Observando o diagrama de rede, os "Outros Recursos de Computação" são implantados em uma Sub-rede diferente do Ambiente do Serviço de Aplicativo. A implantação de recursos na mesma sub-rede com o ASE bloqueará a conectividade do ASE com esses recursos (exceto para roteamento intra-ASE específico). Em vez disso, implante em uma sub-rede diferente (na mesma VNET). O Ambiente do Serviço de Aplicativo poderá se conectar. Nenhuma configuração adicional é necessária.

Os Ambientes do Serviço de Aplicativo também se comunicam com o Banco de Dados SQL e os recursos de Armazenamento do Azure necessários para gerenciar e operar um Ambiente do Serviço de Aplicativo. Alguns dos recursos de Sql e Armazenamento com os quais um Ambiente do Serviço de Aplicativo se comunica estão localizados na mesma região do Ambiente do Serviço de Aplicativo, enquanto outros estão localizados em regiões remotas do Azure. Como resultado, a conectividade de saída com a Internet é sempre necessária para que um Ambiente do Serviço de Aplicativo funcione corretamente.

Como um Ambiente do Serviço de Aplicativo é implantado em uma sub-rede, os grupos de segurança de rede podem ser usados para controlar o tráfego de entrada para a sub-rede. Para obter detalhes sobre como controlar o tráfego de entrada para um Ambiente do Serviço de Aplicativo, consulte o artigo a seguir.

Para obter detalhes sobre como permitir a conectividade de saída com a Internet a partir de um Ambiente do Serviço de Aplicativo, consulte o seguinte artigo sobre como trabalhar com a Rota Expressa. A mesma abordagem descrita no artigo se aplica ao trabalhar com conectividade Site a Site e ao usar tunelamento forçado.

Endereços de rede de saída

Quando um Ambiente do Serviço de Aplicativo faz chamadas de saída, um Endereço IP é sempre associado às chamadas de saída. O endereço IP específico usado depende se o ponto de extremidade que está sendo chamado está localizado dentro da topologia de rede virtual ou fora da topologia de rede virtual.

Se o ponto de extremidade que está sendo chamado estiver fora da topologia de rede virtual, o endereço de saída (também conhecido como endereço NAT de saída) usado será o VIP público do Ambiente do Serviço de Aplicativo. Esse endereço pode ser encontrado na interface do usuário do portal para o Ambiente do Serviço de Aplicativo na seção Propriedades.

Esse endereço também pode ser determinado para ASEs que só têm um VIP público criando um aplicativo no Ambiente do Serviço de Aplicativo e, em seguida, executando um nslookup no endereço do aplicativo. O endereço IP resultante é o VIP público, bem como o endereço NAT de saída do Ambiente do Serviço de Aplicativo.

Se o ponto de extremidade que está sendo chamado estiver dentro da topologia de rede virtual, o endereço de saída do aplicativo chamador será o endereço IP interno do recurso de computação individual que executa o aplicativo. No entanto, não há um mapeamento persistente de endereços IP internos da rede virtual para aplicativos. Os aplicativos podem se mover entre diferentes recursos de computação, e o pool de recursos de computação disponíveis em um Ambiente do Serviço de Aplicativo pode mudar devido a operações de dimensionamento.

No entanto, como um Ambiente do Serviço de Aplicativo está sempre localizado em uma sub-rede, você tem a garantia de que o endereço IP interno de um recurso de computação que executa um aplicativo sempre estará dentro do intervalo CIDR da sub-rede. Como resultado, quando ACLs refinadas ou grupos de segurança de rede são usados para proteger o acesso a outros pontos de extremidade dentro da rede virtual, o intervalo de sub-redes que contém o Ambiente do Serviço de Aplicativo precisa ter acesso concedido.

O diagrama a seguir mostra esses conceitos com mais detalhes:

No diagrama acima:

• Como o VIP público do Ambiente do Serviço de Aplicativo é 192.23.1.2, esse é o endereço IP de saída usado ao fazer chamadas para pontos de extremidade "Internet".
• O intervalo CIDR da sub-rede que contém para o Ambiente do Serviço de Aplicativo é 10.0.1.0/26. Outros pontos de extremidade dentro da mesma infraestrutura de rede virtual verão chamadas de aplicativos como originadas de algum lugar dentro desse intervalo de endereços.

Chamadas entre ambientes do Serviço de Aplicativo

Um cenário mais complexo pode ocorrer se você implantar vários Ambientes do Serviço de Aplicativo na mesma rede virtual e fizer chamadas de saída de um Ambiente do Serviço de Aplicativo para outro Ambiente do Serviço de Aplicativo. Esses tipos de chamadas entre o Ambiente do Serviço de Aplicativo também serão tratadas como chamadas "Internet".

O diagrama a seguir mostra um exemplo de uma arquitetura em camadas com aplicativos em um Ambiente do Serviço de Aplicativo (por exemplo, aplicativos Web "porta frontal") chamando aplicativos em um segundo Ambiente do Serviço de Aplicativo (por exemplo, aplicativos de API back-end internos não destinados a serem acessíveis pela Internet).

No exemplo acima, o Ambiente do Serviço de Aplicativo "ASE One" tem um endereço IP de saída de 192.23.1.2. Se um aplicativo em execução neste Ambiente do Serviço de Aplicativo fizer uma chamada de saída para um aplicativo em execução em um segundo Ambiente do Serviço de Aplicativo ("ASE Dois") localizado na mesma rede virtual, a chamada de saída será tratada como uma chamada "Internet". Como resultado, o tráfego de rede que chega ao segundo Ambiente do Serviço de Aplicativo será exibido como originário de 192.23.1.2 (ou seja, não o intervalo de endereços de sub-rede do primeiro Ambiente do Serviço de Aplicativo).

Embora as chamadas entre diferentes Ambientes do Serviço de Aplicativo sejam tratadas como chamadas "Internet", quando ambos os Ambientes do Serviço de Aplicativo estiverem localizados na mesma região do Azure, o tráfego de rede permanecerá na rede regional do Azure e não fluirá fisicamente pela Internet pública. Como resultado, você pode usar um grupo de segurança de rede na sub-rede do segundo Ambiente do Serviço de Aplicativo para permitir apenas chamadas de entrada do primeiro Ambiente do Serviço de Aplicativo (cujo endereço IP de saída é 192.23.1.2), garantindo assim uma comunicação segura entre os Ambientes do Serviço de Aplicativo.

Links e Informações Adicionais

Detalhes sobre as portas de entrada usadas pelos Ambientes do Serviço de Aplicativo e o uso de grupos de segurança de rede para controlar o tráfego de entrada estão disponíveis aqui.

Detalhes sobre como usar rotas definidas pelo usuário para conceder acesso de saída à Internet aos Ambientes do Serviço de Aplicativo estão disponíveis neste artigo.