Administración de un entorno de App Service Environment

Importante

En este artículo se aborda App Service Environment v2, que se usa con planes de App Service aislado. App Service Environment v1 y v2 se retiran a partir del 31 de agosto de 2024. Hay una nueva versión de App Service Environment que resulta más fácil de usar y se ejecuta en una infraestructura más eficaz. Para aprender más sobre la nueva versión, empiece por consultar la Introducción a App Service Environment. Si actualmente usa App Service Environment v1, siga los pasos descritos en este artículo para migrar a la nueva versión.

A partir del 31 de agosto de 2024, el Acuerdo de Nivel de Servicio (SLA) y los créditos de servicio ya no se aplican a las cargas de trabajo de App Service Environment v1 y v2 que siguen en producción, ya que son productos retirados. Se ha iniciado la retirada del hardware de App Service Environment v1 y v2, lo que puede afectar a la disponibilidad y el rendimiento de las aplicaciones y los datos.

Debe completar la migración a App Service Environment v3 inmediatamente o las aplicaciones y los recursos podrían ser eliminados. Intentaremos migrar automáticamente cualquier instancia restante de App Service Environment v1 y v2 en la medida de lo posible mediante la característica de migración local, pero Microsoft no ofrece ninguna garantía sobre la disponibilidad de la aplicación después de la migración automática. Es posible que tenga que realizar la configuración manual para completar la migración y optimizar la opción de SKU del plan de App Service para satisfacer sus necesidades. Si la migración automática no es factible, se eliminarán los recursos y los datos de la aplicación asociados. Le instamos encarecidamente a que actúe ahora para evitar cualquiera de estos escenarios extremos.

Si necesita más tiempo, podemos ofrecerle un único periodo de gracia de 30 días para que complete la migración. Para obtener más información y solicitar este período de gracia, consulte la información general del período de gracia, y a continuación, vaya a Azure Portal y visite la hoja Migración para cada uno de los entornos de App Service.

Para obtener la información más actualizada sobre la retirada de App Service Environment v1/v2, consulte el Actualización de retirada de App Service Environment v1 y v2.

Un entorno App Service Environment (ASE) es una implementación de Azure App Service en una subred de una instancia de Azure Virtual Network (VNet) de un cliente. Una instancia de ASE se compone de:

• Servidores front-end: donde las solicitudes HTTP o HTTPS finalizan en App Service Environment.
• Trabajos: los recursos que hospedan las aplicaciones.
• Base de datos: contiene información que define el entorno.
• Almacenamiento: se usa para hospedar las aplicaciones publicadas del cliente.

Puede implementar una instancia de ASE con una IP virtual (VIP) externa o interna que permita el acceso de las aplicaciones. Una implementación con una VIP externa suele llamarse ASE externo. Una implementación con una VIP interna se llama ASE con un ILB porque usa un equilibrador de carga interno (ILB). Para más información sobre ASE con un ILB, consulte Creación y uso de un ASE con un ILB.

Creación de una aplicación en un entorno ASE

Para crear una aplicación en un entorno ASE, se usa el mismo proceso que al crearla normalmente, pero con pequeñas diferencias. Al crear un nuevo plan de App Service:

• En lugar de elegir una ubicación geográfica en la que implementar la aplicación, elija un entorno ASE como su ubicación.
• Todos los planes de App Service que se creen en una instancia de ASE solamente deberán tener un plan de tarifa Aislado.

Si no tiene un entorno ASE, puede crear uno según las instrucciones que aparecen en Creación de un entorno en App Service Environment.

Para crear una aplicación en un entorno ASE:

1. Seleccione Crear un recurso>Web y móvil>Aplicación web.

2. Escriba un nombre para la aplicación. Si ya seleccionó un plan de App Service en ASE, el nombre de dominio de la aplicación refleja el nombre de dominio del entorno ASE:

   

3. Seleccione una suscripción.

4. Especifique un nombre para un grupo de recursos nuevo o seleccione Usar existente y seleccione uno en la lista desplegable.

5. Seleccione el sistema operativo.

6. Seleccione un plan de App Service existente en ASE o cree uno nuevo siguiendo estos pasos:

   a. En el menú de la izquierda de Azure Portal, seleccione Crear un recurso > Aplicación web.

   b. Seleccione la suscripción.

   c. Seleccione o cree el grupo de recursos.

   d. Escriba el nombre de la aplicación web.

   e. Seleccione Código o DockerContainer.

   f. Seleccione una pila del entorno en tiempo de ejecución.

   g. Seleccione Linux o Windows.

   h. Seleccione la instancia de ASE en la lista desplegable Región.

   i. Seleccione o cree un nuevo plan de App Service. Si va a crear un nuevo plan de App Service, seleccione el tamaño del plan de tarifa Aislado que corresponda.

   

   Nota

   Las aplicaciones Windows y Linux no pueden estar en el mismo plan de App Service, pero sí que pueden estar en el mismo entorno de App Service Environment.

7. Seleccione Revisar y crear, asegúrese de que la información es correcta y luego seleccione Crear.

Cómo funciona escalar

Cada aplicación de App Service se ejecuta en un plan de App Service. Las instancias de App Service Environment contienen planes de App Service, y estos incluyen aplicaciones. Cuando escala una aplicación, también escala el plan de App Service y todas las aplicaciones de ese mismo plan.

Cuando se escala horizontalmente un plan de App Service, se agrega la infraestructura necesaria de forma automática. Hay un retraso para escalar las operaciones mientras se agrega la infraestructura. Si realiza varias operaciones de escalado una detrás de otra, se atenderá a la primera solicitud de escalado de la infraestructura y las demás se podrán en cola. Cuando finaliza la primera operación de escalado, el resto de las solicitudes de infraestructura se realizarán a la vez. Cuando se agregue la infraestructura, los planes de App Service se asignarán según corresponda. La propia acción de crear un nuevo plan de App Service es ya una operación de escalado porque requiere hardware adicional. Una operación de escalado suele tardar entre 30 y 60 minutos en completarse. Las actualizaciones también son operaciones que bloquean el escalado mientras están en curso.

En las instancias multiinquilino de App Service, el escalado es inmediato, ya que hay un grupo de destino disponible al instante para realizarlo. En un entorno ASE, no hay ningún búfer de este tipo y los recursos se asignan según sea necesario.

En ASE, un plan de App Service se puede escalar hasta en 100 instancias. Un entorno de ASE puede tener como máximo un total de 201 instancias entre todos los planes de App Service de ese entorno.

Direcciones IP

App Service puede asignar una dirección IP dedicada a una aplicación. Esta funcionalidad está disponible después de configurar un enlace TLS/SSL basado en dirección IP, tal como se describe en Incorporación de un certificado TLS/SSL en Azure App Service. En las instancias de ASE con ILB, no se pueden agregar más direcciones IP para usarlas en el enlace de TLS/SSL basado en IP.

Con un entorno ASE externo, puede configurar un enlace TLS/SSL basado en IP para la aplicación de la misma manera que en una instancia de App Service con varios inquilinos. En ASE siempre hay una dirección de reserva, hasta un máximo de treinta direcciones IP. Cada vez que usa una, se agrega otra, para que siempre haya una dirección disponible lista para su uso. Se requiere un retraso de tiempo para asignar otra dirección IP. Ese retraso evita la incorporación de direcciones IP en una sucesión rápida.

Escalado de front-end

Cuando se escala un plan de App Service, se agregan automáticamente trabajos que contribuyen a la operación de escalado. Cada ASE se crea con dos servidores front-end. Los servidores front-end se escalan horizontalmente a un ritmo de un servidor front-end por cada grupo de quince instancias de planes de App Service. Por ejemplo, si tiene tres planes de App Service con cinco instancias cada uno, tendría un total de quince instancias y tres servidores front-end. Si escala a un total treinta instancias, tendrá cuatro servidores front-end. Este patrón continúa a medida que se escala horizontalmente.

El número de servidores front-end que se asignan de forma predeterminada es el adecuado para una carga moderada. Puede reducir la ratio de modo que sea tan pequeña como un servidor front-end por cada cinco instancias. También puede cambiar el tamaño de los servidores front-end. De forma predeterminada, tienen un solo núcleo. En Azure Portal, puede cambiar su tamaño a dos o cuatro núcleos.

Se aplican cargos por cambiar la ratio o el tamaño de los servidores front-end. Para más información, consulte Precios de Azure App Service. Si quiere mejorar la capacidad de carga de la instancia de ASE, disfrutará de un mejor rendimiento si escala primero a servidores front-end de dos núcleos antes de ajustar ratio de escalado. Al cambiar el tamaño de núcleo de los servidores front-end, se actualizará la instancia de ASE, lo que debe hacerse fuera del horario comercial normal.

Los recursos de Front-End son el punto de conexión HTTP/HTTPS para el entorno ASE. Con la configuración predeterminada de Front-End, el uso de memoria por Front-End se sitúa sistemáticamente en torno al 60 %. La razón principal para escalar los servidores front-end es el uso de CPU, lo que normalmente viene determinado por el tráfico HTTPS.

Acceso a las aplicaciones

En las instancias externas de ASE, el sufijo del dominio que se utiliza para crear aplicaciones es .<nombreASE>.p.azurewebsites.net. Por ejemplo, si la instancia de ASE se llama external-ase y la aplicación contoso se hospeda en ese ASE, puede alcanzarla utilizando las siguientes direcciones URL:

• contoso.external-ase.p.azurewebsites.net
• contoso.scm.external-ase.p.azurewebsites.net

Para información sobre cómo crear un entorno ASE externo, consulte Creación de una instancia externa de App Service Environment.

En una instancia de ASE con ILB, el sufijo del dominio que se utiliza para crear aplicaciones es .<nombreASE>.appserviceenvironment.net. Si la instancia de ASE se llama ilb-ase y la aplicación contoso se hospeda en ese ASE, puede alcanzarla en las siguientes direcciones URL:

• contoso.ilb-ase.appserviceenvironment.net
• contoso.scm.ilb-ase.appserviceenvironment.net

Para información sobre cómo crear una instancia de ASE con un ILB, consulte Creación y uso de una instancia de ASE con un ILB.

La dirección URL del SCM se utiliza para obtener acceso a la consola de Kudu o para publicar la aplicación mediante Web Deploy. La consola Kudu ofrece una UI web para depurar, cargar archivos, editar archivos y mucho más.

Configuración de DNS

Cuando se usa un ASE externo, las aplicaciones realizadas en el ASE se registran con Azure DNS. En un ASE externo, no hay pasos adicionales para que las aplicaciones estén disponibles públicamente. En un ASE con un ILB tiene que administrar su propio DNS. Puede hacer esto en su propio servidor DNS o con las zonas privadas de Azure DNS.

Para configurar DNS en su propio servidor DNS con el ASE de ILB:

1. Cree una zona para el <nombre de ASE>.appserviceenvironment.net.
2. Cree un registro D en esa zona que apunte * a la dirección IP de ILB.
3. Cree un registro D en esa zona que apunte a la dirección IP de ILB.
4. Cree una zona en el <nombre de ASE>.appserviceenvironment.net denominada SCM.
5. Cree un registro D en la zona SCM que apunte * a la dirección IP de ILB.

Para configurar DNS en las zonas privadas de Azure DNS:

1. Cree una zona privada de Azure DNS denominada <ASE name>.appserviceenvironment.net.
2. Cree un registro D en esa zona que apunte * a la dirección IP de ILB.
3. Cree un registro D en esa zona que apunte a la dirección IP de ILB.
4. cree un registro A en esa zona que apunte *.scm a la dirección IP de ILB.

La configuración de DNS para el sufijo de dominio predeterminado de ASE no restringe las aplicaciones para que solo puedan acceder a ellas esos nombres. Puede establecer un nombre de dominio personalizado sin ninguna validación en las aplicaciones de un ASE con un ILB. Si desea crear una zona denominada contoso.net, puede hacerlo y hacer que apunte a la dirección IP de ILB. 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.

La zona denominada .<asename>.appserviceenvironment.net es globalmente única. Antes de mayo de 2019, los clientes podían especificar el sufijo de dominio del ASE con ILB. Si quería usar .contoso.com como sufijo de dominio, podía hacerlo y eso incluiría el sitio SCM. Había problemas con ese modelo, entre los que se incluían la administración del certificado TLS/SSL predeterminado, la falta de inicio de sesión único con el sitio SCM y la obligatoriedad de usar un certificado comodín. El proceso de actualización de certificados predeterminados del ASE con ILB también se ha interrumpido y ha provocado el reinicio de la aplicación. Para solucionar estos problemas, el comportamiento del ASE con ILB se ha modificado para que use un sufijo de dominio basado en el nombre del ASE y un sufijo propiedad de Microsoft. El cambio en el comportamiento del ASE con ILB solo afecta a aquellos ASE creados después de mayo de 2019. Los ASE con ILB existentes anteriormente deben todavía administrar el certificado predeterminado del ASE y su configuración de DNS. Si su instancia de ASE V2 de ILB se creó después de mayo de 2019, no es necesario administrar el certificado predeterminado de ILB, ya que lo administra Microsoft.

Publicación

En una instancia de ASE, al igual que lo que ocurre con App Service multiinquilino, puede publicar con estos métodos:

• Implementación web
• FTP
• Integración continua (CI)
• Operación de arrastrar y soltar en la consola Kudu
• Un IDE, como Visual Studio, Eclipse o IntelliJ IDEA

Con un entorno ASE externo, todas estas opciones de publicación trabajan del mismo modo. Para más información, consulte Implementación en Azure App Service.

Con un ASE con un ILB, los puntos de conexión de publicación solo están disponibles a través de ILB. El ILB está en una dirección IP privada en la subred de ASE en la red virtual. Si no tiene acceso de red al ILB, no puede publicar ninguna aplicación en ese entorno ASE. Tal como se indica en Creación y uso de un ASE con un ILB, debe configurar DNS para las aplicaciones del sistema. Ese requisito incluye el punto de conexión de SCM. Si los puntos de conexión no se han definido correctamente, no puede llevar a cabo la publicación. Los IDE también deben tener acceso de red al ILB para publicar directamente en él.

Sin cambios adicionales, los sistemas de CI basados en Internet, como GitHub y Azure DevOps, no funcionan con una instancia de ASE con ILB, ya que el punto de conexión de publicación no es accesible desde Internet. Puede habilitar la publicación en una instancia de ASE con ILB desde Azure DevOps instalando un agente de versiones autohospedado en la red virtual que contiene la instancia de ASE con ILB. También puede utilizar un sistema de CI que use un modelo de extracción, como Dropbox.

Los puntos de conexión de publicación para las aplicaciones en un ASE con un ILB usan el dominio con el que se creó el ASE con un ILB. Puede verlo en el perfil de publicación de la aplicación y en el panel del portal de la aplicación (en Información general>Información esencial y también en Propiedades).

Storage

Una instancia de ASE dispone de 1 TB de almacenamiento para todas las aplicaciones que contiene. El plan de App Service de la SKU del plan de tarifa Aislado tiene un límite de 250 GB. En un ASE, se agregan 250 GB de almacenamiento por plan de App Service hasta el límite de 1 TB. Puede tener más de cuatro planes de App Service, pero no se agregará más espacio de almacenamiento más allá del límite de 1 TB.

Supervisión

Como cliente, debe supervisar los planes de App Service y las aplicaciones individuales que se ejecutan y realizar las acciones adecuadas. Para App Service Environment v2, también debe prestar atención a las métricas en torno a la infraestructura de la plataforma. Estas métricas le proporcionan información sobre cómo funcionan la infraestructura de la plataforma y los servidores front-end (multiRole), y puede tomar medidas si se usan mucho y no se está obteniendo el máximo rendimiento.

A través de Azure Portal y la CLI, puede configurar la relación de escala de los servidores front-end entre 5 y 15 (valor predeterminado: 15) instancias de plan de App Service por servidor front-end. Un App Service Environment siempre tendrá un mínimo de dos servidores front-end. También puede aumentar el tamaño de los servidores front-end.

El ámbito de métricas usado para supervisar la infraestructura de la plataforma se denomina Microsoft.Web/hostingEnvironments/multiRolePools.

Verá un ámbito denominado Microsoft.Web/hostingEnvironments/workerPools. Las métricas aquí solo se aplican a App Service Environment v1.

Registro

Puede integrar la instancia de ASE con Azure Monitor para enviar registros sobre esta instancia de ASE a Azure Storage, Azure Event Hubs o Log Analytics. Estos elementos se registran hoy:

Situación	Message
ASE no tiene un estado correcto	La instancia de ASE especificada no tiene un estado correcto porque la configuración de la red virtual no es válida. La instancia de ASE se suspenderá si se mantiene un estado que no es correcto. Asegúrese de que se siguen las directrices definidas aquí: Consideraciones de red para una instancia de App Service Environment.
La subred de ASE casi no tiene espacio	La instancia de ASE especificada está en una subred que casi no tiene espacio. Quedan {0} direcciones. Una vez que se agoten estas direcciones, la instancia de ASE no se podrá escalar.
ASE está a punto de alcanzar el límite total de instancias	La instancia de ASE especificada está a punto de alcanzar al límite total de instancias. Actualmente contiene {0} instancias de planes de App Service, de un máximo de 201 instancias.
ASE no puede obtener acceso a una dependencia	La instancia de ASE especificada no puede comunicarse con {0}. Asegúrese de que se siguen las directrices definidas aquí: Consideraciones de red para una instancia de App Service Environment.
La instancia de ASE está suspendida	La instancia de ASE especificada está suspendida. Esta suspensión puede deberse a que hay pocas cuentas o a que una configuración de red virtual no es válida. Resuelva la causa principal del problema y reanude la instancia de ASE para que siga atendiendo el tráfico.
Se ha iniciado una actualización de ASE	Se ha iniciado una actualización de la plataforma a la instancia de ASE especificada. Es posible que se produzcan retrasos en las operaciones de escalado.
Se ha completado una actualización de ASE	Ha finalizado una actualización de plataforma de la instancia de ASE especificada.
Se han iniciado operaciones de escalado	Se ha comenzado a escalar un plan de App Service ({0}). Estado deseado: {1} I{2} trabajos.
Se han completado las operaciones de escalado	Ha finalizado el escalado de un plan de App Service ({0}). Estado actual: {1} I{2} trabajos.
Se han producido errores en las operaciones de escalado	No se ha podido escalar un plan de App Service ({0}). Estado actual: {1} I{2} trabajos.

Puede habilitar el registro en la instancia de ASE:

1. En el portal, vaya a Configuración de diagnóstico.
2. Seleccione Agregar configuración de diagnóstico.
3. Especifique un nombre para la integración de registros.
4. Seleccione y configure los destinos de registro que desee.
5. Seleccione AppServiceEnvironmentPlatformLogs.

Si integra esta solución con Log Analytics, podrá ver los registros seleccionando Registros en el portal de ASE y creando una consulta en AppServiceEnvironmentPlatformLogs. Los registros solo se emiten cuando el ASE tiene un evento que lo desencadenará. Si el ASE no tiene ese tipo de evento, no habrá ningún registro. Para ver rápidamente un ejemplo de registros en el área de trabajo de Log Analytics, realice una operación de escalado con uno de los planes de App Service del ASE. Después, puede ejecutar una consulta en AppServiceEnvironmentPlatformLogs para ver esos registros.

Creación de una alerta

Para crear una alerta sobre los registros, siga las instrucciones de Creación, visualización y administración de alertas de registro mediante Azure Monitor. En resumen:

• Abra la página Alertas en el portal de ASE.
• Seleccione Nueva regla de alertas.
• Seleccione el recurso para que sea el área de trabajo de Log Analytics.
• Establezca la condición con una búsqueda de registros personalizada que use una consulta como "AppServiceEnvironmentPlatformLogs | donde ResultDescription contiene "ha empezado el escalado" o cualquier cosa que desee. Establezca el umbral según corresponda.
• Agregue o cree un grupo de acciones según sus preferencias. En el grupo de acciones se define la respuesta a la alerta como, por ejemplo, enviar un correo electrónico o un mensaje SMS.
• Asigne un nombre a la alerta y guárdela.

Preferencia de actualización

Si tiene varias instancias de ASE, es posible que prefiera que unas se actualicen antes que otras. Este comportamiento se puede habilitar a través del portal de ASE. En Configuración, tiene la opción de establecer la preferencia de actualización. Estos son los tres valores posibles:

• Ninguna: Azure actualizará la instancia de ASE en alguno de los lotes. Este es el valor predeterminado.
• Early: la instancia de ASE se actualizará durante la primera mitad de las actualizaciones de App Service.
• Late: la instancia de ASE se actualizará durante la segunda mitad de las actualizaciones de App Service.

Seleccione el valor deseado y seleccione Guardar. El valor predeterminado de cualquier ASE es Ninguno.

Tiene más sentido utilizar la característica upgradePreferences cuando hay varias instancias de ASE, porque las que estén configuradas con el valor "Early" (Pronto) se actualizarán antes de las que tienen el valor "Late" (Tarde). Si tiene varias instancias de ASE, los entornos de ASE de desarrollo y pruebas deben establecerse en "Early", mientras que los entornos de ASE de producción deben establecerse en "Late".

Precios

La SKU de precios denominada Aislado solo puede utilizarse con instancias de ASE. Todos los planes de App Service que se hospedan en la instancia de ASE están en el plan de tarifa Aislado. Las tarifas del plan Aislado para los planes de App Service pueden variar según la región.

Además del precio de los planes de App Service, hay una tarifa fija para el propio entorno ASE. Esta tarifa fija no cambia con el tamaño del entorno ASE. Se aplica a la infraestructura de ASE con una velocidad de escalado predeterminada de un front-end adicional por cada 15 instancias del plan de App Service.

Si la velocidad de escalado predeterminada de un front-end por cada 15 instancias del plan de App Service no es lo suficientemente rápida, puede ajustar la ratio con la que se agregan servidores front-end o el tamaño de estos. Al ajustar la proporción o el tamaño, paga por los núcleos de front-end que no se agregarían de manera predeterminada.

Por ejemplo, si ajusta el factor de escala en 10, se agrega un Front-End por cada 10 instancias en los planes de App Service. La tarifa fija cubre una escala de un Front-End por cada 15 instancias. Con un factor de escala de 10, paga una tarifa por el tercer servidor front-end que se agrega para las 10 instancias del plan de App Service. No es necesario que pague por él si llega a 15 instancias, ya que se agregó automáticamente.

Si ajusta el tamaño de los front-end a dos núcleos pero no se ajusta la ratio, pagará por los núcleos adicionales. Las instancias de ASE se crean con dos servidores front-end, por lo que incluso estando por debajo del umbral de escalado automático, pagaría por dos núcleos adicionales si aumentara el tamaño a servidores front-end con dos núcleos.

Para más información, consulte Precios de Azure App Service.

Eliminar un entorno ASE

Para eliminar un entorno ASE:

1. Seleccione Eliminar en la parte superior del panel App Service Environment.

2. Escriba el nombre de su ASE para confirmar que desea eliminarlo. Cuando se elimina un entorno ASE, también se elimina todo su contenido.

   

3. Seleccione Aceptar.

CLI de ASE

Hay funcionalidades de línea de comandos para administrar a un ASE. Los comandos de la CLI de Azure se indican a continuación.

C:\>az appservice ase --help

Group
    az appservice ase : Manage App Service Environments v2.
        This command group is in preview. It may be changed/removed in a future release.
Commands:
    create         : Create app service environment.
    delete         : Delete app service environment.
    list           : List app service environments.
    list-addresses : List VIPs associated with an app service environment.
    list-plans     : List app service plans associated with an app service environment.
    show           : Show details of an app service environment.
    update         : Update app service environment.

For more specific examples, use: az find "az appservice ase"