Compartir a través de

Creación y uso de un entorno de una instancia de Azure App Service Environment de Load Balancer

  • Artículo

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, revise 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, vea la Actualización de retirada de App Service Environment v1 y v2.

Azure App Service Environment es una implementación de Azure App Service en una subred de Azure Virtual Network (VNet). Hay dos maneras de implementar una instancia de App Service Environment (ASE):

  • Con una dirección VIP en una dirección IP externa, a la que se suele hacer referencia como instancia externa de ASE.
  • Con una dirección VIP en una dirección IP interna, llamada a menudo un ASE con un ILB porque el punto de conexión interno es un equilibrador de carga interno (ILB).

Este artículo muestra cómo crear un ASE con un ILB. Para obtener información general sobre el ASE, consulte Introducción a App Service Environment. Para obtener información sobre cómo crear un ASE externo, consulte [Crear un ASE externo][MakeExternalASE].

Información general

Puede implementar un ASE con un punto de conexión accesible por Internet o con una dirección IP en la red virtual. Para establecer la dirección IP en una dirección de red virtual, el ASE debe implementarse con un ILB. Al implementar el ASE con un ILB, debe proporcionar el nombre del ASE. El nombre de la instancia de ASE se usa en el sufijo de dominio para las aplicaciones de ASE. El sufijo de dominio de ASE de ILB es <nombre de ASE>.appserviceenvironment.net. Las aplicaciones que se crean en una instancia de ASE de ILB no se colocan en el DNS público.

Con las versiones anteriores de la instancia de ASE de ILB era necesario proporcionar un sufijo de dominio y un certificado predeterminado para las conexiones HTTPS. El sufijo de dominio ya no se recopila durante la creación de la instancia de ASE de ILB ni tampoco se recopila ya un certificado predeterminado. Ahora, cuando se crea una instancia de ASE de ILB, Microsoft proporciona el certificado predeterminado y el explorador confía en él. Todavía puede establecer nombres de dominio personalizados en aplicaciones de la instancia de ASE y establecer certificados en esos nombres de dominio personalizados.

Con una instancia de ASE de ILB, puede hacer cosas como las siguientes:

  • Hospedar aplicaciones de intranet de forma segura en la nube a las que se accede a través de una conexión de sitio a sitio o ExpressRoute
  • Proteger aplicaciones con un dispositivo WAF
  • Hospedar aplicaciones en la nube que no se muestran en los servidores DNS públicos.
  • Crear aplicaciones de back-end aisladas de Internet con las que pueden integrarse de forma segura sus aplicaciones de front-end.

Funcionalidad deshabilitada

Sin embargo, cuando utilice un ASE con un ILB, no podrá realizar algunas operaciones:

  • Use el enlace TLS/SSL basado en IP.
  • Asigne direcciones IP a aplicaciones específicas.
  • Compre y use un certificado con una aplicación a través de Azure Portal. Puede obtener certificados directamente en una entidad de certificación y usarlos con sus aplicaciones. No puede obtenerlas a través de Azure Portal.

Creación de un ASE con un ILB

Para crear un ASE de ILB, consulte Creación de un ASE mediante una plantilla de Azure Resource Manager.

Nota:

El nombre de App Service Environment no debe tener más de 36 caracteres.

Creación de una aplicación en un ASE con un ILB

Crea una aplicación en un ASE con un ILB del mismo modo que crea una aplicación en un ASE normalmente.

  1. En Azure Portal, seleccione Create un recurso>Web>Web App.

  2. Escriba el nombre de la aplicación.

  3. Seleccione la suscripción.

  4. Seleccione o cree un grupo de recursos.

  5. Seleccione la publicación, la pila del entorno en tiempo de ejecución y el sistema operativo.

  6. Seleccione una ubicación que sea una instancia de ASE de ILB existente.

  7. Seleccione o cree un plan de App Service.

  8. Seleccione Revisar y crear y, cuando esté listo, seleccione Crear.

Trabajos web, Functions y ASE de ILB

Functions y los trabajos web se admiten en un ASE de ILB, pero para que el portal funcione con ellos, debe tener acceso a la red para el sitio de SCM. Esto significa que el explorador debe estar en un host que se encuentre en la red virtual o conectado a ella. Si la instancia de ASE de ILB tiene un nombre de dominio que no finaliza en appserviceenvironment.net, deberá conseguir que el explorador confíe en el certificado HTTPS que se usa en el sitio SCM.

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.

Publicación con un ASE con un ILB

Para cada aplicación que se cree, hay dos puntos de conexión. En una instancia de ASE de ILB, tiene <nombre de la aplicación>.<dominio de ASE de ILB> y <nombre de la aplicación>.scm.<dominio de ASE de ILB> .

El nombre del sitio SCM le lleva a la consola de Kudu, denominada Advanced Portal dentro de Azure Portal. La consola de Kudu le permite visualizar las variables de entorno, explorar el disco, utilizar una consola y mucho más. Para más información, consulte Consola de Kudu para Azure App Service.

Los sistemas de CI basados en Internet, como GitHub y Azure DevOps, seguirán funcionando con un ASE de ILB si se puede acceder al agente de compilación a través de Internet y este está en la misma red que ASE de ILB. Por tanto, en el caso de Azure DevOps, si el agente de compilación se crea en la misma red virtual que el ASE de ILB (también puede usar una red virtual diferente), podrá extraer el código del repositorio Git de Azure DevOps e implementarlo en el ASE de ILB. Si no desea crear su propio agente de compilación, deberá usar 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. Este dominio aparece en el perfil de publicación de la aplicación y en la hoja del portal de la aplicación (en Información general>Información esencial y también en Propiedades). Si tiene una instancia de ASE de ILB con el sufijo de dominio <nombre de ASE>.appserviceenvironment.net y una aplicación llamada mytest, use mytest.<nombre de ASE>.appserviceenvironment.net para FTP y mytest.scm.contoso.net para la implementación de MSDeploy.

Configuración de una instancia de ASE de ILB con un dispositivo WAF

Puede combinar un dispositivo de firewall de aplicaciones web (WAF) con la instancia de ASE de ILB para exponer solo las aplicaciones que quiera a Internet y el resto mantenerlas accesibles desde la red virtual. Esta estrategia le permite crear aplicaciones seguras de varios niveles entre otras cosas.

Para obtener más información sobre cómo configurar la instancia de ASE de ILB con un dispositivo WAF, consulte Configuración de un firewall de aplicaciones web para App Service Environment. En este artículo se muestra cómo usar una aplicación virtual Barracuda con su ASE. Otra opción es utilizar Azure Application Gateway. Application Gateway utiliza las reglas de núcleo de OWASP para proteger cualquier aplicación que se encuentre detrás de él. Para más información sobre Application Gateway, consulte Introducción al firewall de aplicaciones web de Azure.

Instancias de ASE de LIB creadas antes de mayo de 2019

Con las instancias de ASE de ILB que se crearon antes de mayo de 2019, había que establecer el sufijo de dominio durante la creación de ASE. También era necesario cargar un certificado predeterminado que se basaba en dicho sufijo de dominio. Además, con una instancia antigua de ASE de ILB, no puede realizar el inicio de sesión único en la consola de Kudu con las aplicaciones de dicha instancia. Al configurar DNS para una instancia de este tipo, deberá establecer el registro D comodín en una zona que coincida con el sufijo de dominio. Para crear o cambiar ASE de ILB con sufijo de dominio personalizado, debes usar plantillas de Azure Resource Manager y una versión de API anterior a 2019. La última versión de API de soporte técnico es 2018-11-01.

Introducción