Rede do Ambiente do Serviço de Aplicações
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 do Windows e Linux, aplicativos Web, aplicativos de API, aplicativos lógicos e aplicativos de função. Ao instalar um Ambiente do Serviço de Aplicativo, você escolhe a rede virtual do Azure na qual deseja que ele seja implantado. Todo o tráfego de entrada e saída do aplicativo está dentro da rede virtual que você especificar. Você implanta em uma única sub-rede em sua rede virtual e nada mais pode ser implantado nessa sub-rede.
Nota
Este artigo é sobre o Ambiente do Serviço de Aplicativo v3, que é usado com os planos do Serviço de Aplicativo Isolado v2.
Requisitos de sub-rede
Você deve delegar a sub-rede ao Microsoft.Web/hostingEnvironments, e a sub-rede deve estar vazia.
O tamanho da sub-rede pode afetar os limites de dimensionamento das instâncias do plano do Serviço de Aplicativo no Ambiente do Serviço de Aplicativo. Para escala de produção, recomendamos um espaço de /24 endereçamento (256 endereços) para sua sub-rede. Se você planeja dimensionar quase a capacidade máxima de 200 instâncias em nosso Ambiente do Serviço de Aplicativo e planeja operações frequentes de escala/subida, recomendamos um /23 espaço de endereçamento (512 endereços) para sua sub-rede.
Se você usar uma sub-rede menor, esteja ciente das seguintes limitações:
- Qualquer sub-rede em particular tem cinco endereços reservados para fins de gestão. 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 sua sub-rede é um
/27espaço de endereço (32 endereços). - Para qualquer combinação de OS/SKU do plano do 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 os planos do Serviço de Aplicativo no Ambiente do Serviço de Aplicativo para cima/para baixo, a quantidade de endereços IP usados pelo plano do 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 sejam desprovisionadas.
- As atualizações de plataforma precisam de endereços IP gratuitos para garantir que as atualizações possam acontecer sem interrupções no tráfego de saída.
- Após a expansão, redução ou conclusão das operações, pode haver um curto período de tempo antes que os endereços IP sejam liberados. Em casos raros, esta operação pode ser de até 12 horas.
- Se você ficar sem endereços em sua sub-rede, poderá ser impedido de expandir seus planos do Serviço de Aplicativo no Ambiente do Serviço de Aplicativo. Outra possibilidade é que você possa experimentar maior latência durante a carga de tráfego intensivo, se a Microsoft não for capaz de dimensionar a infraestrutura de suporte.
Nota
Os Contêineres do Windows usam um endereço IP adicional por aplicativo para cada instância do plano do Serviço de Aplicativo e você precisa dimensionar a sub-rede de acordo. Se o seu Ambiente do 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 dar suporte à escala horizontal (entrada/saída).
Cálculo da amostra:
Para cada instância do plano do Serviço de Aplicativo, você precisa: 5 aplicativos de contêiner do Windows = 5 endereços IP 1 endereço IP por instância do plano do Serviço de Aplicativo 5 + 1 = 6 endereços IP
Para 25 instâncias: 6 x 25 = 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 na criação:
| Tipo de endereço | Description |
|---|---|
| Rede virtual do Ambiente do Serviço de Aplicativo | A rede virtual implantada em. |
| Sub-rede do Ambiente do Serviço de Aplicativo | A sub-rede implantada em. |
| Sufixo de domínio | O sufixo de domínio padrão usado pelos aplicativos. |
| Sufixo de domínio personalizado | (facultativo) O sufixo de domínio personalizado usado pelos aplicativos. |
| 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 você tiver um VIP interno, ele será um endereço na sub-rede do Ambiente do Serviço de Aplicativo. Se o endereço for externo, é um endereço voltado para o público. |
| Endereços de saída do trabalhador | Os aplicativos usam este ou esses endereços, ao fazer chamadas de saída para a internet. |
| Endereços de saída da plataforma | A plataforma utiliza este endereço, ao fazer chamadas de saída para a internet. Um exemplo é extrair certificados para sufixo de domínio personalizado do Cofre da Chave 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:
À medida que você dimensiona seus planos do Serviço de Aplicativo em seu Ambiente do Serviço de Aplicativo, você usa mais endereços fora 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 quanto tráfego existe. 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 serão alterados ao longo do tempo.
Traga o seu próprio endereço de entrada
Você pode trazer seu próprio endereço de entrada para seu 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. A seguir estão 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 a criação do Ambiente do Serviço de Aplicativo.
Portas e restrições de rede
Para que seu aplicativo receba tráfego, verifique se as regras do NSG (grupo de segurança de rede) de entrada permitem que a sub-rede Ambiente do Serviço de Aplicativo receba tráfego das portas necessárias. Além de todas as portas nas quais você gostaria de receber tráfego, você deve garantir que o Balanceador de Carga do Azure seja capaz de se conectar à sub-rede na porta 80. Essa 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 sua sub-rede.
Nota
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, pode levar até 14 dias para que o impacto seja visto.
É uma boa idéia configurar a seguinte regra NSG de entrada:
| Porta(s) de Origem/Destino | Direção | Origem | Destino | Propósito |
|---|---|---|---|---|
| * / 80,443 | Interna | VirtualNetwork | Intervalo de sub-redes do Ambiente do Serviço de Aplicativo | Permitir tráfego de aplicativo e tráfego de ping de integridade interna |
O requisito mínimo para que o Ambiente do Serviço de Aplicativo esteja operacional é:
| Porta(s) de Origem/Destino | Direção | Origem | Destino | Propósito |
|---|---|---|---|---|
| * / 80 | Interna | AzureLoadBalancer | Intervalo de sub-redes do Ambiente do Serviço de Aplicativo | Permitir tráfego de ping de integridade interna |
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 a rede virtual ou um ou mais IPs de cliente específicos ou intervalos de IP. O destino é sempre o intervalo de sub-redes do Ambiente do Serviço de Aplicativo.
O tráfego de ping de integridade interna na porta 80 é isolado entre o balanceador de carga e os servidores internos. Nenhum tráfego externo pode atingir o ponto de extremidade de ping de integridade.
As portas normais de acesso ao aplicativo de entrada são as seguintes:
| Utilizar | Portas |
|---|---|
| HTTP/HTTPS | 80, 443 |
| FTP/FTPS | 21, 990, 10001-10020 |
| Depuração remota do Visual Studio | 4022, 4024, 4026 |
| Serviço de implantação da Web | 8172 |
Nota
Para acesso FTP, mesmo se você quiser não 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 interno para o serviço ftp especificamente.
Encaminhamento de rede
Você pode definir tabelas de rotas sem restrições. Você pode encapsular todo o tráfego de aplicativo de saída do seu Ambiente do Serviço de Aplicativo para um dispositivo de firewall de saída, como o Firewall do Azure. Nesse cenário, a única coisa com a qual você precisa se preocupar são as dependências do aplicativo.
As dependências do aplicativo incluem pontos de extremidade de que seu aplicativo precisa durante o tempo de execução. Além de APIs e serviços que o aplicativo está chamando, as dependências também podem ser pontos de extremidade derivados, como pontos de extremidade de verificação de lista de revogação de certificados (CRL) e ponto de extremidade de identidade/autenticação, por exemplo, Microsoft Entra ID. Se você estiver usando a implantação contínua no Serviço de Aplicativo, também precisará permitir pontos de extremidade, dependendo do tipo e do idioma. Especificamente para implantação contínua do Linux, você precisa permitir oryx-cdn.microsoft.io:443o .
Você pode colocar seus dispositivos de firewall de aplicativo Web, como o 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.
Seu aplicativo usa 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ê pode adicionar um gateway NAT à sua sub-rede.
Nota
A conectividade SMTP de saída (porta 25) é suportada para o 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/sub-redes virtuais criadas antes de 1. Agosto de 2022 você precisa iniciar uma alteração de configuração temporária na rede/sub-rede virtual para que a configuração seja sincronizada a partir da assinatura. Um exemplo poderia ser adicionar uma sub-rede temporária, associar/dissociar um NSG temporariamente ou configurar um ponto de extremidade de serviço temporariamente. Para obter mais informações e solução de problemas, consulte Solucionar problemas de conectividade SMTP de saída no Azure.
Ponto final privado
Para habilitar Pontos de Extremidade Privados para aplicativos hospedados em seu Ambiente do Serviço de Aplicativo, você deve primeiro habilitar esse recurso no nível do Ambiente do Serviço de Aplicativo.
Você pode ativá-lo por meio do portal do Azure. No painel de configuração Ambiente do Serviço de Aplicativo, ative 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 obter mais informações sobre o Ponto de Extremidade Privado e o Aplicativo Web, consulte Ponto de Extremidade Privado do Aplicativo Web do Azure
DNS
As seções a seguir descrevem as considerações e a configuração de DNS que se aplicam de entrada e saída do seu Ambiente do Serviço de Aplicativo. Os exemplos usam o sufixo appserviceenvironment.net de domínio da Nuvem Pública do Azure. Se você estiver usando outras nuvens, como o Azure Government, precisará usar o respetivo sufixo de domínio. Para domínios de 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 será truncado em 19 caracteres.
Configuração de DNS para seu Ambiente do Serviço de Aplicativo
Se o seu Ambiente do Serviço de Aplicativo for feito com um VIP externo, seus aplicativos serão automaticamente colocados em 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 ter zonas privadas do DNS do Azure configuradas automaticamente, o DNS será configurado em sua rede virtual. Se você optar por configurar o DNS manualmente, precisará usar seu próprio servidor DNS ou configurar zonas privadas do DNS do Azure. Para localizar o endereço de entrada, vá para o portal do Ambiente do Serviço de Aplicativo e selecione Endereços IP.
Se você quiser usar seu próprio servidor DNS, adicione os seguintes registros:
- Crie uma zona para
<App Service Environment-name>.appserviceenvironment.net. - Crie um registro A nessa zona que aponte * para o endereço IP de entrada usado pelo seu Ambiente do Serviço de Aplicativo.
- Crie um registro A nessa zona que aponte @ para o endereço IP de entrada usado pelo seu Ambiente do Serviço de Aplicativo.
- Crie uma zona com
<App Service Environment-name>.appserviceenvironment.neto nomescm. - Crie um registro A na
scmzona que aponte * para o endereço IP usado pelo ponto de extremidade privado do seu Ambiente do Serviço de Aplicativo.
Para configurar o DNS em zonas privadas do DNS do Azure:
- Crie uma zona privada do DNS do Azure chamada
<App Service Environment-name>.appserviceenvironment.net. - Crie um registo A nessa zona que aponte * para o endereço IP de entrada.
- Crie um registro A nessa zona que aponte @ para o endereço IP de entrada.
- Crie um registro A nessa zona que aponte *.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. Pode definir um nome de domínio personalizado sem qualquer validação nas suas aplicações. Se você estiver usando domínios personalizados, precisará garantir que eles tenham registros DNS configurados. Você pode seguir as orientações anteriores para configurar zonas e registros 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 aplicativos, mas não funciona para o scm site. O scm site só está disponível em <appname.scm>.<asename.appserviceenvironment.net>.
Configuração de DNS para acesso FTP
Para acesso FTP ao Ambiente do Serviço de Aplicativo ILB (Balanceador de Carga Interno) v3 especificamente, você precisa garantir que o DNS esteja configurado. Configure uma zona privada do DNS do Azure ou DNS personalizado equivalente com as seguintes configurações:
- Crie uma zona privada do DNS do Azure chamada
ftp.appserviceenvironment.net. - Crie um registro A nessa zona que aponte
<App Service Environment-name>para o endereço IP de entrada.
Além de configurar o DNS, você também precisa habilitá-lo na configuração do Ambiente do Serviço de Aplicativo e no nível do aplicativo.
Configuração de DNS do seu Ambiente do Serviço de Aplicativo
Os aplicativos em seu Ambiente do Serviço de Aplicativo usam o DNS com o qual sua rede virtual está configurada. Se pretender que algumas aplicações utilizem um servidor DNS diferente, pode defini-lo manualmente por aplicação, com as definições WEBSITE_DNS_SERVER da aplicação e WEBSITE_DNS_ALT_SERVER. WEBSITE_DNS_ALT_SERVER configura o servidor DNS secundário. O servidor DNS secundário só é usado quando não há resposta do servidor DNS primário.