Redes de App Service Environment
App Service Environment (ASE) es una implementación de inquilino único de Azure App Service que hospeda contenedores de Windows y Linux, aplicaciones web, aplicaciones de API, aplicaciones lógicas y aplicaciones de funciones. Cuando se instala ASE, se elige la red virtual de Azure en la que quiere que se implemente. Todo el tráfico entrante y saliente de la aplicación estará dentro de la red virtual que especifique. Se implementa en una sola subred de la red virtual y no se puede implementar nada más en esa subred.
Nota
Este artículo trata sobre App Service Environment v3, que se usa con planes de App Service v2 aislados.
Requisitos de subred
A continuación se muestra el conjunto mínimo de requisitos para la subred en la que se encuentra App Service Environment.
- La subred deberá estar delegada a
Microsoft.Web/hostingEnvironments. - La subred debe estar vacía.
- La propiedad
addressPrefixde la subred debe tener el formato de una cadena, no como una matriz.
El tamaño de la subred puede afectar a los límites de escalado de las instancias del plan de App Service en ASE. Para la escala de producción, se recomienda un espacio de direcciones /24 (256 direcciones) para la subred. Si planea escalar casi la capacidad máxima de 200 instancias en App Service Environment y planea realizar operaciones frecuentes de escalado vertical o descendente, se recomienda un espacio de direcciones /23 (512 direcciones) para la subred.
Si usa una subred más pequeña, tenga en cuenta las limitaciones siguientes:
- Cualquier subred tiene cinco direcciones reservadas para fines de administración. Además de las direcciones de administración, App Service Environment escala dinámicamente la infraestructura de apoyo y usa entre 7 y 27 direcciones, según la configuración y la carga. Las direcciones restantes se pueden usar para las instancias del plan de App Service. El tamaño mínimo de la subred es un espacio de direcciones
/27(32 direcciones). - Para cualquier combinación de SO/SKU del plan de App Service usada en App Service Environment, como I1v2 Windows, se crea una instancia en espera para cada 20 instancias activas. Las instancias en espera también requieren direcciones IP.
- Al escalar planes de App Service en App Service Environment hacia arriba y hacia abajo, la cantidad de direcciones IP usadas por el plan de App Service se duplica temporalmente mientras se completa la operación de escalado. Las nuevas instancias deben estar totalmente operativas antes de desaprovisionar las instancias existentes.
- Las actualizaciones de la plataforma necesitan direcciones IP gratuitas para asegurarse de que las actualizaciones pueden producirse sin interrupciones en el tráfico saliente.
- Después de escalar verticalmente, reducir verticalmente o reducir verticalmente las operaciones, puede haber un breve período de tiempo antes de que se libere la dirección IP. En raras ocasiones, esta operación puede durar hasta 12 horas.
- Si se queda sin direcciones dentro de la subred, se le puede restringir el escalado horizontal de los planes de App Service en App Service Environment. Otra posibilidad es que pueda experimentar una mayor latencia durante una carga de tráfico intensiva, si Microsoft no puede escalar la infraestructura de apoyo.
Nota:
Los contenedores de Windows usan una dirección IP adicional por aplicación para cada instancia de plan de App Service; debe ajustar el tamaño de la subred según corresponda. Si la instancia de App Service Environment tiene, por ejemplo, 2 planes de App Service en contenedores de Windows, cada uno con 25 instancias y 5 aplicaciones en ejecución, necesitará 300 direcciones IP y direcciones adicionales para admitir el escalado horizontal (entrada/salida).
Cálculo de ejemplo:
Para cada instancia de plan de App Service, necesita: 5 aplicaciones contenedoras de Windows = 5 direcciones IP, 1 dirección IP por instancia de plan de App Service, 5 + 1 = 6 direcciones IP
Para 25 instancias: 6 x 25 = 150 direcciones IP por plan de App Service
Puesto que tiene 2 planes de App Service, 2 x 150 = 300 direcciones IP.
Direcciones
App Service Environment tiene la siguiente información de red en la creación:
| Tipo de dirección | Descripción |
|---|---|
| Red virtual de App Service Environment | La red virtual en la que se implementa. |
| Subred de App Service Environment | La subred en la que se implementa. |
| Sufijo del dominio | El sufijo de dominio predeterminado que usan las aplicaciones. |
| Sufijo de dominio personalizado | (Opcional) El sufijo de dominio personalizado que usan las aplicaciones. |
| IP virtual (VIP) | Tipo de VIP usado. Los dos valores posibles son interno y externo. |
| Dirección de entrada | La dirección de entrada es la dirección desde la que se llega a las aplicaciones. Si tiene una DIRECCIÓN VIP interna, es una dirección en la subred App Service Environment local. Si la dirección es externa, será una dirección de acceso público. |
| Direcciones de salida de trabajo | Las aplicaciones usarán estas direcciones al realizar llamadas salientes a Internet. |
| Direcciones de salida de plataforma | La plataforma usará esta dirección al realizar llamadas salientes a Internet. Un ejemplo es extraer certificados para un sufijo de dominio personalizado del Key Vault si no se usa un punto de conexión privado. |
Puede encontrar detalles en la parte Direcciones IP del portal, como se muestra en la captura de pantalla siguiente:
A medida que escale los planes de App Service en App Service Environment, usará más direcciones fuera de la subred. El número de direcciones que use varía en función del número de instancias del plan de App Service que tenga y de la cantidad de tráfico que haya. Las aplicaciones de App Service Environment no tienen direcciones dedicadas en la subred. Las direcciones específicas que usa una aplicación en la subred cambiarán con el tiempo.
Traiga su propia dirección de entrada
Puede traer su propia dirección de entrada a App Service Environment. Si crea una instancia de App Service Environment con una dirección VIP interna, puede especificar una dirección IP estática en la subred. Si crea una instancia de App Service Environment con una dirección VIP externa, puede usar su propia dirección IP pública de Azure especificando el identificador de recurso de la dirección IP pública. Las siguientes son limitaciones a traer su propia dirección de entrada:
- Para una instancia de App Service Environment con dirección VIP externa, el recurso de dirección IP pública de Azure debe estar en la misma suscripción que la instancia de App Service Environment.
- La dirección de entrada no se puede cambiar una vez que se ha creado la instancia de App Service Environment.
Puertos y restricciones de red
Para que la aplicación reciba tráfico hay que asegurarse de que las reglas de grupos de seguridad de red (NSG) entrantes permiten que la subred de ASE reciba tráfico de los puertos necesarios. Además de los puertos en los que desee recibir tráfico, hay que asegurarse de que Azure Load Balancer puede conectarse a la subred en el puerto 80. Este puerto se usa para las comprobaciones de estado de la máquina virtual interna. Todavía puede controlar el tráfico del puerto 80 desde la red virtual a la subred.
Nota:
Los cambios en las reglas de NSG pueden tardar hasta 14 días en surtir efecto debido a la persistencia de la conexión HTTP. Si realiza un cambio que bloquea el tráfico de plataforma/administración, el impacto puede tardar hasta 14 días en notarse.
Es buena idea configurar la siguiente regla de NSG entrante:
| Puertos de origen/destino | Dirección | Source | Destination | Propósito |
|---|---|---|---|---|
| * / 80,443 | Entrada | VirtualNetwork | Rango de subred de App Service Environment | Permita el tráfico de la aplicación y tráfico de ping de estado interno |
El requisito mínimo para que App Service Environment esté operativo es:
| Puertos de origen/destino | Dirección | Source | Destination | Propósito |
|---|---|---|---|---|
| * / 80 | Entrada | AzureLoadBalancer | Rango de subred de App Service Environment | Permita el tráfico de ping de mantenimiento interno |
Si aplica el filtro de requisitos mínimos es posible que necesite una o varias reglas para el tráfico de la aplicación. Si usa cualquiera de las opciones de implementación o depuración, también debe permitir este tráfico a la subred de App Service Environment. El origen de estas reglas puede ser la red virtual o bien una o varias direcciones IP o intervalos IP de cliente específicos. El destino siempre es el intervalo de subred de App Service Environment.
El tráfico de ping de mantenimiento interno en el puerto 80 está aislado entre el equilibrador de carga y los servidores internos. Ningún tráfico externo puede llegar al punto de conexión de ping de estado.
Los puertos de acceso a aplicaciones normales son los siguientes:
| Uso | Puertos |
|---|---|
| HTTP/HTTPS | 80, 443 |
| FTP/FTPS | 21, 990, 10001-10020 |
| Depuración remota en Visual Studio | 4022, 4024, 4026 |
| Servicio Web Deploy | 8172 |
Nota
Para el acceso FTP, incluso si quiere no permitir FTP estándar en el puerto 21, todavía debe permitir el tráfico desde LoadBalancer al intervalo de subredes de App Service Environment en el puerto 21, ya que se usa para el tráfico de ping de estado interno para el servicio FTP específicamente.
Enrutamiento de red
Puede establecer tablas de rutas sin restricciones. Puede tunelar todo el tráfico saliente de la aplicación desde App Service Environment a un dispositivo de firewall de salida, como Azure Firewall. En este escenario, de lo único que tiene que preocuparse es de las dependencias de la aplicación.
Las dependencias de la aplicación incluyen puntos de conexión que la aplicación necesita durante el tiempo de ejecución. Además de las API y los servicios a los que llama la aplicación, las dependencias también podrían derivarse de puntos de conexión, como la lista de revocación de certificados (CRL), los puntos de conexión de comprobación y el punto de conexión de identidad o autenticación, por ejemplo, Microsoft Entra ID. Si usa la implementación continua en App Service, es posible que también deba permitir puntos de conexión en función del tipo y el idioma. Específicamente para la implementación continua de Linux, debe permitir oryx-cdn.microsoft.io:443.
Puede colocar los dispositivos de firewall de aplicaciones web, como Azure Application Gateway, delante del tráfico entrante. Si lo hace, podrá exponer aplicaciones específicas en esa instancia de App Service Environment.
La aplicación usa una de las direcciones salientes predeterminadas para el tráfico de salida a los puntos de conexión públicos. Si desea personalizar la dirección saliente de las aplicaciones en un App Service Environment, puede agregar una puerta de enlace de traducción de direcciones de red (NAT) a la subred.
Nota
La conectividad SMTP saliente (puerto 25) se admite para App Service Environment v3. La compatibilidad viene determinada por una configuración en la suscripción donde se implementa la red virtual. Para redes virtuales o subredes que se hayan creado antes de la 1. En agosto de 2022 debe iniciar un cambio de configuración temporal en la red virtual o subred para que la configuración se sincronice desde la suscripción. Un ejemplo sería agregar una subred temporal, asociar o desasociar temporalmente un grupo de seguridad de red o configurar un punto de conexión de servicio temporalmente. Para más información y solución de problemas, consulte Solución de problemas de conectividad SMTP saliente en Azure.
Punto de conexión privado
Para habilitar puntos de conexión privados para aplicaciones hospedadas en App Service Environment, primero debe habilitar esta característica en el nivel de App Service Environment.
Se puede activar mediante Azure Portal. En el panel de configuración de App Service Environment, active el valor Allow new private endpoints.
Como alternativa, la siguiente CLI puede habilitarla:
az appservice ase update --name myasename --allow-new-private-endpoint-connections true
Para obtener más información sobre los puntos de conexión privados y la aplicación web, consulte Punto de conexión privado de aplicación web de Azure
DNS
En las secciones siguientes se describen las consideraciones y la configuración de DNS que se aplican tanto a la entrada como a la salida de App Service Environment. En los ejemplos se usa el sufijo de dominio appserviceenvironment.net de la nube pública de Azure. Si usa otras nubes como Azure Government, debe usar su sufijo de dominio respectivo. En el caso de los dominios de App Service Environment, el nombre del sitio se trunca en 40 caracteres debido a los límites de DNS. Si tiene una ranura, el nombre de la ranura se trunca en 19 caracteres.
Configuración de DNS en App Service Environment
Si el App Service Environment se realiza con una VIP externa, las aplicaciones se colocarán automáticamente en DNS público. Si una app Service Environment se crea con una VIP interna, tiene dos opciones al crear la app Service Environment. Si selecciona que se configuren automáticamente zonas privadas de Azure DNS, el DNS se configura en la red virtual. Si prefiere configurar manualmente el DNS, es necesario que use su propio servidor DNS o que configure las zonas privadas de Azure DNS. Para buscar la dirección de entrada, vaya al portal App Service Environment y seleccione Direcciones IP.
Si desea usar su propio servidor DNS, agregue los siguientes registros:
- Cree una zona para
<App Service Environment-name>.appserviceenvironment.net. - Cree un registro A en esa zona que apunte * a la dirección IP de entrada que usa el App Service Environment.
- Cree un registro A en esa zona que señala @ a la dirección IP de entrada que usa el App Service Environment.
- Cree una zona en
<App Service Environment-name>.appserviceenvironment.netllamadascm. - Cree un registro A en esa zona
scmque apunte * a la dirección IP que usa el punto de conexión privado del App Service Environment.
Para configurar el DNS en las zonas privadas de Azure DNS:
- Cree una zona privada de Azure DNS denominada
<App Service Environment-name>.appserviceenvironment.net. - Cree un registro A en esa zona que apunte * a la dirección IP de entrada.
- Cree un registro A en esa zona que apunte @ a la dirección IP de entrada.
- Cree un registro A en esa zona que apunte *.scm a la dirección IP de entrada.
Además del dominio predeterminado proporcionado cuando se crea una aplicación, también puede agregar un dominio personalizado a la aplicación. Puede establecer un nombre de dominio personalizado sin ninguna validación en las aplicaciones. Si usa dominios personalizados, asegúrese de que tienen registros DNS configurados. Puede seguir las instrucciones anteriores para configurar las zonas DNS y los registros para un nombre de dominio personalizado. Para ello, reemplace el nombre de dominio predeterminado por el nombre de dominio personalizado. El nombre de dominio personalizado funciona para las solicitudes de aplicación, pero no para el sitio scm. El sitio scm solo está disponible en <appname>.scm.<asename>.appserviceenvironment.net.
Configuración de DNS para el acceso FTP
Para el acceso FTP al equilibrador de carga interno (ILB) App Service Environment v3 específicamente, debe asegurarse de que DNS esté configurado. Configure una zona privada de Azure DNS o un DNS personalizado equivalente con la siguiente configuración:
- Cree una zona privada de Azure DNS denominada
ftp.appserviceenvironment.net. - Cree un registro D en esa zona que apunte
<App Service Environment-name>a la dirección IP de entrada.
Además de configurar DNS, también debe habilitarlo en la configuración de App Service Environment y en el nivel de aplicación.
Configuración del DNS desde la App Service Environment
Las aplicaciones de la instancia de App Service Environment usan el DNS con el que está configurada la red virtual. Si desea que algunas aplicaciones usen un servidor DNS distinto, puede establecerlo manualmente en cada aplicación con las configuraciones de aplicación WEBSITE_DNS_SERVER y WEBSITE_DNS_ALT_SERVER. WEBSITE_DNS_ALT_SERVER configura el servidor DNS secundario. El servidor DNS secundario solo se usa cuando no hay ninguna respuesta del servidor DNS principal.