Rede do Ambiente do Serviço de Aplicativo
O Ambiente do Serviço de Aplicativo é uma implantação de locatário único do Serviço de Aplicativo do Azure que hospeda contêineres Windows e Linux, aplicativos Web, aplicativos de API, aplicativos lógicos e aplicativos de funções. Ao instalar um Ambiente do Serviço de Aplicativo, você escolhe a rede virtual do Azure em que deseja que ele seja implantado. Todo o tráfego de entrada e de saída de aplicativo fica dentro da rede virtual especificada. Você implanta em uma única sub-rede em sua rede virtual e nada mais pode ser implantado naquela sub-rede.
Observação
Este artigo aborda o Ambiente do Serviço de Aplicativo v3, que é usado com Planos do Serviço de Aplicativo v2 Isolado.
Requisitos de sub-rede
Veja a seguir o conjunto mínimo de requisitos para a sub-rede em que o Ambiente do Serviço de Aplicativo está.
- A sub-rede deve ser delegada a
Microsoft.Web/hostingEnvironments. - A sub-rede deve estar vazia.
- A propriedade
addressPrefixda sub-rede deve ser formatada como uma cadeia de caracteres, não como uma matriz.
O tamanho da sub-rede pode afetar os limites de escala das instâncias do Plano do Serviço de Aplicativo no Ambiente do Serviço de Aplicativo. Para a escala de produção, recomendamos um espaço de endereço /24 (256 endereços) para sua sub-rede. Se você planeja dimensionar quase a capacidade máxima de 200 instâncias no nosso Ambiente do Serviço de Aplicativo e planeja as operações de escala vertical/inferior frequentes, recomendamos um espaço de endereço /23 (512 endereços) para sua sub-rede.
Se você usar uma sub-rede menor, fique ciente das limitações a seguir:
- Qualquer sub-rede específica tem cinco endereços reservados para fins de gerenciamento. Além dos endereços de gerenciamento, o Ambiente do Serviço de Aplicativo dimensiona dinamicamente a infraestrutura de suporte e usa entre 7 e 27 endereços, dependendo da configuração e da carga. Você pode usar os endereços restantes para instâncias no Plano do Serviço de Aplicativo. O tamanho mínimo da sub-rede é um espaço de endereço
/27(32 endereços). - Para qualquer combinação de sistema operacional/SKU do plano de Serviço de Aplicativo usada em seu Ambiente do Serviço de Aplicativo como o Windows I1v2, uma instância em espera é criada para cada 20 instâncias ativas. As instâncias em espera também exigem endereços IP.
- Ao dimensionar planos de Serviço de Aplicativo no Ambiente do Serviço de Aplicativo para cima/para baixo, a quantidade de endereços IP usados pelo plano de Serviço de Aplicativo é temporariamente dobrada enquanto a operação de escala é concluída. As novas instâncias precisam estar totalmente operacionais antes que as instâncias existentes deixem de ser provisionadas.
- As atualizações da plataforma precisam de endereços IP gratuitos para garantir que as atualizações possam ocorrer sem interrupções no tráfego de saída.
- Depois de escalar verticalmente, para baixo ou nas operações concluídas, pode haver um curto período de tempo antes que os endereços de IP sejam liberados. Em casos raros, esta operação pode ser de até 12 horas.
- Se ficar sem endereços na sub-rede, você poderá ser impedido de dimensionar os Planos do Serviço de Aplicativo no Ambiente do Serviço de Aplicativo. Outra possibilidade é que você experimente maior latência durante uma carga de tráfego intensiva, se a Microsoft não conseguir dimensionar a infraestrutura de suporte.
Observação
Os Contêineres do Windows usam um endereço IP adicional por aplicativo para cada instância de Plano do Serviço de Aplicativo e você precisa dimensionar a sub-rede adequadamente. Se o seu Ambiente de Serviço de Aplicativo tiver, por exemplo, 2 planos do Serviço de Aplicativo de Contêiner do Windows, cada um com 25 instâncias e cada um com 5 aplicativos em execução, você precisará de 300 endereços IP e endereços adicionais para suportar a escala horizontal (entrada/saída).
Exemplo de cálculo:
Para cada instância de plano de Serviço de Aplicativo, você precisa de: 5 aplicativos de contêiner do Windows = 5 endereços IP 1 endereço IP por Serviço de Aplicativo instância de plano 5 + 1 = 6 endereços IP
Para 25 instâncias: 25 x 6 = 150 endereços IP por Plano do Serviço de Aplicativo
Como você tem 2 planos do Serviço de Aplicativo, 2 x 150 = 300 endereços IP.
Endereços
O Ambiente do Serviço de Aplicativo tem as seguintes informações de rede ao ser criado:
| Tipo de endereço | Descrição |
|---|---|
| Rede virtual do Ambiente do Serviço de Aplicativo | A rede virtual implantada. |
| A sub-rede do Ambiente do Serviço de Aplicativo | A sub-rede implantada. |
| Sufixo do Domínio | O sufixo de domínio padrão usado pelos aplicativos. |
| Sufixo do Custom Domain | (opcional) O sufixo de domínio personalizado usado pelos aplicativos. |
| O IP virtual (VIP) | O tipo VIP usado. Os dois valores possíveis são interno e externo. |
| Endereço de entrada | O endereço de entrada é o endereço no qual seus aplicativos são alcançados. Se tiver um VIP interno, ele será um endereço na sub-rede do Ambiente do Serviço de Aplicativo rede. Se o endereço for externo, ele será um endereço voltado para o público. |
| Endereços da saída de trabalho | Os aplicativos usam esse ou esses endereços ao fazer chamadas de saída para a Internet. |
| Endereços de saída da plataforma | A plataforma usa esse endereço ao fazer chamadas de saída para a Internet. Um exemplo é extrair certificados para o sufixo de domínio personalizado do Key Vault se um ponto de extremidade privado não for usado. |
Você pode encontrar detalhes na parte Endereços IP do portal, conforme mostrado na captura de tela a seguir:
Ao dimensionar os planos do Serviço de Aplicativo no Ambiente do Serviço de Aplicativo, você usará mais endereços de sua sub-rede. O número de endereços que você usa varia com base no número de instâncias do Plano do Serviço de Aplicativo que você tem e na quantidade de tráfego existente. Os aplicativos no Ambiente do Serviço de Aplicativo não têm endereços dedicados na sub-rede. Os endereços específicos usados por um aplicativo na sub-rede mudarão com o passar do tempo.
Traga seu próprio endereço de entrada
Você pode trazer seu próprio endereço de entrada para o Ambiente do Serviço de Aplicativo. Se você criar um Ambiente do Serviço de Aplicativo com um VIP interno, poderá especificar um endereço IP estático na sub-rede. Se você criar um Ambiente do Serviço de Aplicativo com um VIP externo, poderá usar seu próprio endereço IP público do Azure especificando a ID do recurso do endereço IP público. Veja a seguir as limitações para trazer seu próprio endereço de entrada:
- Para o Ambiente do Serviço de Aplicativo com VIP externo, o recurso de endereço IP público do Azure deve estar na mesma assinatura que o Ambiente do Serviço de Aplicativo.
- O endereço de entrada não pode ser alterado após o Ambiente do Serviço de Aplicativo ser criado.
Restrições de portas e rede
Para que seu aplicativo receba tráfego, garanta que as regras do NSG (grupo de segurança de rede) de entrada permitam que a sub-rede do Ambiente do Serviço de Aplicativo receba tráfego das portas necessárias. Além das portas em que você gostaria de receber tráfego, verifique se o Azure Load Balancer consegue se conectar à sub-rede na porta 80. Esta porta é usada para verificações de integridade da máquina virtual interna. Você ainda pode controlar o tráfego da porta 80 da rede virtual para a sub-rede.
Observação
As alterações nas regras do NSG podem levar até 14 dias para entrar em vigor devido à persistência da conexão HTTP. Se você fizer uma alteração que bloqueie o tráfego da plataforma/gerenciamento, o impacto poderá levar até 14 dias para ser percebido.
É uma boa ideia configurar a seguinte regra de NSG de entrada:
| Porta(s) de Origem/Destino | Direção | Fonte | Destino | Finalidade |
|---|---|---|---|---|
| * / 80.443 | Entrada | VirtualNetwork | Intervalo da sub-rede do Ambiente do Serviço de Aplicativo | Permitir tráfego de aplicativo e tráfego de ping de integridade interno |
O requisito mínimo para Ambiente do Serviço de Aplicativo ser operacional é:
| Porta(s) de Origem/Destino | Direção | Fonte | Destino | Finalidade |
|---|---|---|---|---|
| * / 80 | Entrada | AzureLoadBalancer | Intervalo da sub-rede do Ambiente do Serviço de Aplicativo | Permitir tráfego de ping de integridade interno |
Se você usar a regra mínima necessária, talvez precise de uma ou mais regras para o tráfego do aplicativo. Se você estiver usando qualquer uma das opções de implantação ou depuração, também deverá permitir esse tráfego para a sub-rede do Ambiente do Serviço de Aplicativo. A origem dessas regras pode ser rede virtual ou um ou mais IPs de cliente ou intervalos de IP específicos. O destino é sempre o intervalo da sub-rede do Ambiente do Serviço de Aplicativo.
O tráfego de ping de integridade interno na porta 80 é isolado entre o balanceador de carga e os servidores internos. Nenhum tráfego externo pode alcançar o ponto de extremidade de ping de integridade.
As portas de entrada para acesso normais do aplicativo são as seguintes:
| Uso | Portas |
|---|---|
| HTTP/HTTPS | 80, 443 |
| FTP/FTPS | 21, 990, 10001-10020 |
| Depuração remota no Visual Studio | 4022, 4024, 4026 |
| Serviço de Implantação da Web | 8172 |
Observação
Para acesso FTP, mesmo que você não queira permitir FTP padrão na porta 21, você ainda precisa permitir o tráfego do LoadBalancer para o intervalo de sub-rede do Ambiente do Serviço de Aplicativo na porta 21, pois isso é usado para o tráfego de ping de integridade interna especificamente para o serviço ftp.
Roteamento de rede
Você pode definir tabelas de rotas sem restrição. Você pode canalizar todo o tráfego de aplicativo de saída do Ambiente do Serviço de Aplicativo para um dispositivo de firewall de saída, como Firewall do Azure. Nesse cenário, a única coisa com que você precisa se preocupar é com as dependências do aplicativo.
As dependências do aplicativo incluem os pontos de extremidade que seu aplicativo precisa durante o runtime. Além de APIs e serviços que o aplicativo está chamando, as dependências também poderiam ser pontos de extremidade derivados, como pontos de extremidade de verificação da ista de revogação de certificados (CRL) e ponto de extremidade de identidade/autenticação, por exemplo, Microsoft Entra ID. Ao usar a implantação contínua no Serviço de Aplicativo, também pode ser preciso permitir pontos de extremidade dependendo do tipo e do idioma. Especificamente para a implantação contínua do Linux, é necessário permitir oryx-cdn.microsoft.io:443.
Você pode colocar dispositivos de firewall do aplicativo Web, como Gateway de Aplicativo do Azure, na frente do tráfego de entrada. Isso permite que você exponha aplicativos específicos nesse Ambiente do Serviço de Aplicativo do Azure.
Seu aplicativo usará um dos endereços de saída padrão para o tráfego de saída para pontos de extremidade públicos. Se quiser personalizar o endereço de saída de seus aplicativos em um Ambiente do Serviço de Aplicativo, você poderá adicionar um Gateway da NAT à sua sub-rede.
Observação
Há suporte para conectividade SMTP de saída (porta 25) para Ambiente do Serviço de Aplicativo v3. A capacidade de suporte é determinada por uma configuração na assinatura em que a rede virtual é implantada. Para redes virtuais/sub-redes criadas antes de 1. Em agosto de 2022, você precisa iniciar uma alteração temporária de configuração na rede virtual/sub-rede para que a configuração da assinatura seja sincronizada. Um exemplo seria adicionar uma sub-rede temporária, associar/dissociar um NSG temporariamente ou configurar um ponto de extremidade de serviço provisoriamente. Para saber mais informações e como solucionar problemas, confira Solucionar problemas de conectividade de SMTP de saída no Azure.
Ponto de extremidade privado
Para habilitar os pontos de extremidade privados para os aplicativos hospedados no Ambiente do Serviço de Aplicativo, primeiro, você precisa habilitar esse recurso no Ambiente do Serviço de Aplicativo.
Você pode ativá-lo pelo portal do Microsoft Azure. No painel de configuração do Ambiente do Serviço de Aplicativo, ative em a configuração Allow new private endpoints.
Como alternativa, a seguinte CLI pode habilitá-lo:
az appservice ase update --name myasename --allow-new-private-endpoint-connections true
Para saber mais sobre o ponto de extremidade privado e o aplicativo Web, confira Ponto de extremidade privado do aplicativo Web do Azure
DNS
As seções a seguir descrevem as considerações de DNS e a configuração que se aplicam à entrada e à saída do seu Ambiente do Serviço de Aplicativo. Os exemplos usam o sufixo de domínio appserviceenvironment.net da Nuvem Pública do Azure. Se você estiver usando outras nuvens como o Microsoft Azure Governamental, precisará usar o respectivo sufixo de domínio. Para domínios do Ambiente do Serviço de Aplicativo, o nome do site é truncado em 40 caracteres devido aos limites de DNS. Se você tiver um slot, o nome do slot é truncado em 19 caracteres.
Configuração de DNS para seu Ambiente do Serviço de Aplicativo
Se seu Ambiente do Serviço de Aplicativo for feito com um VIP externo, os aplicativos serão colocados automaticamente no DNS público. Se o Ambiente do Serviço de Aplicativo for feito com um VIP interno, você terá duas opções ao criar o Ambiente do Serviço de Aplicativo. Se você selecionar a configuração automática das zonas privadas do DNS do Azure, o DNS será configurado na sua rede virtual. Se você optar por configurar o DNS manualmente, precisará usar seu próprio servidor DNS ou configurar zonas privadas DNS do Azure. Para encontrar o endereço de entrada, acesse o portal Ambiente do Serviço de Aplicativo e selecione Endereços IP.
Se quiser usar seu próprio servidor DNS, adicione os registros a seguir:
- Crie uma zona para
<App Service Environment-name>.appserviceenvironment.net. - Crie um registro A na zona indicada com * para o endereço IP de entrada usado pelo Ambiente do Serviço de Aplicativo.
- Crie um registro A na zona indicada com @ para o endereço IP de entrada usado pelo Ambiente do Serviço de Aplicativo.
- Crie uma zona em
<App Service Environment-name>.appserviceenvironment.netchamadascm. - Crie um registro A na zona
scmindicada com * para o endereço IP usado pelo ponto de extremidade privado do Ambiente do Serviço de Aplicativo.
Para configurar o DNS em zonas privadas do DNS do Azure:
- Crie uma zona privada de DNS do Azure chamada
<App Service Environment-name>.appserviceenvironment.net. - Crie um registro A na zona indicada com * para o endereço IP de entrada.
- Crie um registro A na zona indicada com @ para o endereço IP de entrada.
- Crie um registro A nessa zona indicada com *.scm para o endereço IP de entrada.
Além do domínio padrão fornecido quando um aplicativo é criado, você também pode adicionar um domínio personalizado ao seu aplicativo. Você pode definir um nome de domínio personalizado sem nenhuma validação em seus aplicativos. Se você estiver usando domínios personalizados, precisará garantir que eles tenham registros DNS configurados. Você pode seguir as diretrizes precedentes para configurar registros e zonas DNS para um nome de domínio personalizado (substitua o nome de domínio padrão pelo nome de domínio personalizado). O nome de domínio personalizado funciona para solicitações de aplicativo, mas não para o site do scm. O site do scm só está disponível em <appname>.scm <asename>.appserviceenvironment.net.
Configuração de DNS para acesso de FTP
Para acesso FTP ao Ambiente do Serviço de Aplicativo v3 do ILB (Balanceador de Carga Interno) especificamente, você precisa garantir que o DNS está configurado. Configure uma zona privada do DNS do Azure ou DNS personalizado equivalente com as seguintes configurações:
- Crie uma zona privada de DNS do Azure chamada
ftp.appserviceenvironment.net. - Crie um registro A nessa zona indicada com
<App Service Environment-name>para o endereço IP de entrada.
Além de configurar o DNS, também é necessário habilitá-lo na configuração do Ambiente do Serviço de Aplicativo e no nível do aplicativo.
Configuração de DNS para o Ambiente do Serviço de Aplicativo
Os aplicativos no Ambiente do Serviço de Aplicativo usam o DNS com o qual sua rede virtual está configurada. Se quiser que alguns aplicativos usem um servidor DNS diferente, você poderá definir manualmente por aplicativo com as configurações de aplicativo WEBSITE_DNS_SERVER e WEBSITE_DNS_ALT_SERVER. WEBSITE_DNS_ALT_SERVER configura o servidor DNS secundário. O servidor DNS secundário é usado somente quando não há resposta do servidor DNS primário.