Implementación empresarial mediante Azure App Service Environment

Esta arquitectura de referencia muestra una carga de trabajo empresarial común que utiliza App Service Environment versión 3. También se describen los procedimientos recomendados para reforzar la seguridad de la carga de trabajo.

Hay disponible una implementación de referencia de esta arquitectura en GitHub.

Architecture

Descargue un archivo Visio de esta arquitectura.

Flujo de trabajo

App Service Environment versión 3 proporciona características diferentes a las anteriores y ventajas de esas versiones. Para más información, consulte Diferencias funcionales. Puede implementar App Service Environment de dos maneras:

• Como App Service Environment externa con una dirección IP pública
• Como App Service Environment interna con una dirección IP interna que pertenece al equilibrador de carga interno (ILB)

Esta arquitectura de referencia implementa una aplicación web empresarial en una App Service Environment interna, también denominada App Service Environment de ILB. Use un App Service Environment de ILB cuando el escenario requiera lo siguiente:

• Hospede aplicaciones de intranet con seguridad mejorada en la nube y acceda a ellas a través de una VPN de sitio a sitio o Azure ExpressRoute.
• Proporcionar una capa de protección para las aplicaciones mediante un firewall de aplicaciones web (WAF).
• Hospedar aplicaciones en la nube que no se muestran en los servidores DNS públicos.
• Cree aplicaciones back-end aisladas de Internet, con las que sus aplicaciones front-end puedan integrarse de forma altamente segura.

App Service Environment debe implementarse siempre en su propia subred de la red virtual empresarial para permitir un control estricto del tráfico entrante y saliente. Dentro de esta subred, las aplicaciones de App Service se implementan en uno o varios planes de App Service, que son una colección de recursos físicos necesarios para ejecutar la aplicación. En función de la complejidad y los requisitos de recursos, se puede compartir un plan de App Service entre varias aplicaciones. Esta implementación de referencia despliega una aplicación web llamada Voting App , que interactúa con una API web privada y una función. También implementa una aplicación web ficticia denominada Aplicación de prueba para demostrar implementaciones de varias aplicaciones. Cada aplicación de App Service se hospeda en su propio plan de App Service, lo que permite escalar cada una de ellas de forma independiente si es necesario. Todos los recursos necesarios para estas aplicaciones hospedadas, como el almacenamiento y el proceso, así como las necesidades de escalado, están totalmente administrados por la infraestructura de App Service Environment.

La aplicación de votación sencilla de esta implementación permite a los usuarios ver las entradas existentes o crear otras, así como votar sobre las entradas existentes. La API web se usa para crear y recuperar entradas y votos. Los propios datos se almacenan en una base de datos de SQL Server. Para mostrar las actualizaciones de datos asincrónicas, la aplicación web pone en cola los votos recién agregados en una instancia de Service Bus. La función selecciona los votos en cola y actualiza la base de datos SQL. Azure Cosmos DB se usa para almacenar un boceto de anuncio que la aplicación web recupera para que se muestre en el explorador. La aplicación usa Azure Cache for Redis para la administración de la memoria caché. Se utiliza Azure Cache for Redis de nivel Premium, que permite la configuración en la misma red virtual que el App Service Environment, en su propia subred. Esto proporciona una seguridad y un aislamiento mejorados a la memoria caché.

Las aplicaciones web son los únicos componentes accesibles a Internet a través de Application Gateway. No se puede obtener acceso a la API ni a la función desde un cliente de Internet. El tráfico entrante está protegido por un WAF configurado en Application Gateway.

Componentes

Los siguientes servicios son clave para bloquear el App Service Environment en esta arquitectura:

• Azure Virtual Network es una red privada en la nube Azure propiedad de una empresa. Proporciona mayor seguridad y aislamiento basados en la red. App Service Environment es una implementación App Service en una subred de la red virtual propiedad de la empresa. Permite a la empresa controlar estrictamente ese espacio de red y los recursos a los que accede mediante el uso de grupos de seguridad de red y puntos finales privados.

• Application Gateway es un equilibrador de carga de tráfico web a nivel de aplicación con descarga TLS/SSL y WAF. Escucha en una dirección IP pública y dirige el tráfico al punto final de la aplicación en el entorno de servicio de aplicaciones ILB. Dado que se trata de enrutamiento a nivel de aplicación, puede enrutar el tráfico a varias aplicaciones dentro del mismo entorno de servicio de aplicaciones ILB. Para más información, consulte Hospedaje de varios sitios de Application Gateway.

• Azure Firewall se utiliza para restringir el tráfico saliente de la aplicación web. El tráfico saliente que no pasa por los canales de punto de conexión privados y una tabla de rutas requerida por App Service Environment se dirige a la subred del cortafuegos. Para simplificar, esta arquitectura configura todos los puntos de conexión privados en la subred de servicios.

• Microsoft Entra ID o Microsoft Entra ID proporciona derechos de acceso y administración de permisos a los recursos y servicios de Azure. Las Identidades administradas asignan identidades a servicios y aplicaciones, administrados automáticamente por Microsoft Entra ID. Estas identidades se pueden usar para autenticarse en cualquier servicio que admita la autenticación de Microsoft Entra. Esto elimina la necesidad de configurar explícitamente las credenciales para estas aplicaciones. Esta arquitectura asigna una identidad administrada a la aplicación web.

• Azure Key Vault almacena todos los secretos y credenciales requeridos por las aplicaciones. Use esta opción para almacenar secretos directamente en la aplicación.

• GitHub Actions proporciona capacidades de integración continua y despliegue continuo en esta arquitectura. Dado que el Entorno App Service se encuentra en la red virtual, se utiliza una máquina virtual como jumpbox dentro de la red virtual para desplegar aplicaciones en los planes App Service. La acción compila las aplicaciones fuera de la red virtual. Para una mayor seguridad y una conectividad RDP/SSH sin fisuras, considere el uso de Azure Bastion para el jumpbox.

Configuración multisitio

Descargue un archivo Visio de esta arquitectura.

El Entorno de Servicio de Aplicaciones Interno puede alojar varias aplicaciones web y API con puntos finales HTTP. Estas aplicaciones se bloquean desde la red pública de Internet, ya que solo se puede acceder a la dirección IP de ILB desde dentro de la red virtual. Application Gateway se utiliza para exponer selectivamente estas aplicaciones a Internet. App Service Environment asigna una URL por defecto a cada aplicación App Service como <default-appName>.<app-service-environment-domain>.appserviceenvironment.net. Se crea una zona DNS privada que asigna el nombre de dominio App Service Environment a la dirección IP App Service Environment ILB. Esto evita tener que utilizar un DNS personalizado para acceder a las aplicaciones dentro de la red virtual.

Application Gateway está configurado para que un oyente escuche en el puerto HTTPS las solicitudes dirigidas a la dirección IP de la puerta de enlace. Por motivos de simplicidad, esta implementación no usa un registro de nombres DNS público. Requiere que modifique el archivo localhost de su ordenador para que apunte una URL elegida arbitrariamente a la IP de la Azure Application Gateway. Para simplificar, el agente de escucha usa un certificado autofirmado para procesar estas solicitudes. Application Gateway tiene grupos de backend para cada URL predeterminada de la aplicación App Service. Una regla de enrutamiento está configurada para conectar el agente de escucha al grupo de back-end. Se crea la configuración HTTP que determina si la conexión entre la puertas de enlace y el Entorno de Azure App Service estará cifrada. Esta configuración también se usa para invalidar el encabezado de host HTTP de entrada con un nombre de host seleccionado del grupo de back-end. Esta implementación utiliza certificados predeterminados creados para las URL de aplicación predeterminadas del Entorno de Azure App Service, en las que confía la puerta de enlace. La solicitud se redirige a la dirección URL predeterminada de la aplicación correspondiente. El DNS privado vinculado a la red virtual reenvía esta solicitud a la IP del ILB. App Service Environment reenvía esto al servicio de aplicaciones solicitado. Cualquier comunicación HTTP dentro de las aplicaciones de ASE pasa por el DNS privado. Tenga en cuenta que el receptor, el grupo de backend, la regla de enrutamiento y la configuración HTTP deben configurarse en la puerta de enlace de la aplicación para cada aplicación del Entorno de servicio de aplicaciones.

Revisa appgw.bicep y dns.bicep para aprender cómo se hacen estas configuraciones para permitir múltiples sitios. La aplicación web denominada testapp es una aplicación vacía creada para mostrar esta configuración. Se accede a estos archivos JSON desde el script de implementación deploy_std.sh. También se accede a ellos mediante commands_ha.azcli, que se utiliza para un despliegue de App Service Environment multisitio de alta disponibilidad.

Detalles del escenario

Azure App Service es un servicio de PaaS que se usa para hospedar una variedad de aplicaciones en Azure: Web Apps, API Apps, Functions y Mobile Apps. App Service Environment o ASE permite a las empresas implementar las aplicaciones de App Service en una subred en su propia Azure Virtual Network, lo que proporciona un entorno aislado, de alta escalabilidad y dedicado para sus cargas de trabajo en la nube.

Consideraciones

Estas consideraciones implementan los pilares del marco de buena arquitectura de Azure, que es un conjunto de principios guía que se pueden usar para mejorar la calidad de una carga de trabajo. Para más información, consulte Marco de buena arquitectura de Microsoft Azure.

Seguridad

La seguridad proporciona garantías contra ataques deliberados y el abuso de datos y sistemas valiosos. Para más información, consulte Introducción al pilar de seguridad.

Entorno de App Service

Un App Service Environment interno se despliega en la red virtual de la empresa, oculto de la Internet pública. Permite a la empresa bloquear sus servicios de back-end, como las API web y las funciones, en el nivel de red. Se puede acceder a cualquier aplicación de App Service Environment con un punto final HTTP a través del ILB, desde dentro de la red virtual. Application Gateway está configurado para reenviar solicitudes a la aplicación web a través del ILB. La propia aplicación web pasa por el ILB para acceder a la API. Los componentes críticos de back-end, es decir, la API y la función, son realmente inaccesibles desde la red pública de Internet.

Se crean certificados predeterminados para cada servicio de aplicaciones para el nombre de dominio predeterminado asignado por App Service Environment. Este certificado puede reforzar la seguridad del tráfico entre la puerta de enlace y la aplicación, y puede ser necesario en determinados casos. Estos certificados no son visibles a través del navegador del cliente. Sólo puede responder a los certificados configurados en Application Gateway.

Application Gateway

La implementación de referencia configura Application Gateway mediante programación en appgw.bicep. El archivo commands_std.azcli utiliza esta configuración al desplegar la puerta de enlace:

az deployment group create --resource-group $RGNAME --template-file templates/appgw.bicep --parameters vnetName=$VNET_NAME appgwSubnetAddressPrefix=$APPGW_PREFIX appgwApplications=@appgwApps.parameters.json
APPGW_PUBLIC_IP=$(az deployment group show -g $RGNAME -n appgw --query properties.outputs.appGwPublicIpAddress.value -o tsv)

Cifrado

Como se describe en Descripción general de la terminación TLS y TLS de extremo a extremo con Application Gateway, Application Gateway puede utilizar Transport Layer Security (TLS)/Capa de sockets seguros (SSL) para cifrar y proteger todo el tráfico de los navegadores web. El cifrado se puede configurar de las siguientes maneras:

• Cifrado finalizado en la puerta de enlace. Los grupos de back-end en este caso están configurados para HTTP. El cifrado se detiene en la puerta de enlace, y el tráfico entre la puerta de enlace y App Service no está cifrado. Dado que el cifrado conlleva un uso intensivo de la CPU, el tráfico sin cifrar en el back-end mejora el rendimiento y permite una administración de certificados más sencilla. Esto proporciona un nivel de seguridad razonable, ya que el back-end está protegido según la configuración de red.

• Cifrado de un extremo a otro. En algunos escenarios, como requisitos de seguridad o de cumplimiento específicos, es posible que sea necesario cifrar el tráfico entre la puerta de enlace y la aplicación. Esto se logra mediante el uso de la conexión HTTPS y la configuración de certificados en el grupo de back-end.

Esta implementación de referencia utiliza certificados autofirmados para Application Gateway. Para el código de producción, se debe usar un certificado emitido por una entidad de certificación. Para obtener una lista de los tipos de certificados admitidos, consulte Certificados admitidos para la terminación TLS. Lea Configuración de una puerta de enlace de aplicaciones con terminación TLS mediante Azure Portal para obtener información sobre cómo crear el cifrado con la terminación de puerta de enlace. Las siguientes líneas de código en appgw.bicep configuran esto mediante programación:

          httpListeners: [for item in appgwApplications: {
          name: '${appgwListenerName}${item.name}'
          properties: {
            frontendIPConfiguration: {
              id: '${appgwId}/frontendIPConfigurations/${appgwFrontendName}'
            }
            frontendPort: {
              id: '${appgwId}/frontendPorts/port_443'
            }
            protocol: 'Https'
            sslCertificate: {
              id: '${appgwId}/sslCertificates/${appgwSslCertificateName}${item.name}'
            }
            hostName: item.hostName
            requireServerNameIndication: true
          }
        }]

La implementación de referencia muestra el cifrado de un extremo a otro para el tráfico entre Application Gateway y las aplicaciones web en el App Service Environment. Se usan los certificados SSL predeterminados. Los grupos de back-end de esta implementación se configuran para redirigir el tráfico HTTPS con el nombre de host invalidado por los nombres de dominio predeterminados asociados a las aplicaciones web. Application Gateway confía en los certificados SSL predeterminados porque los emite Microsoft. Consulte Configuración de App Service con Application Gateway para saber cómo se realizan estas configuraciones. El código siguiente de appgw.bicep muestra cómo se configura en la implementación de referencia:

        backendHttpSettingsCollection: [for item in appgwApplications: {
        name: '${appgwHttpSettingsName}${item.name}'
        properties: {
          port: 443
          protocol: 'Https'
          cookieBasedAffinity: 'Disabled'
          pickHostNameFromBackendAddress: true
          requestTimeout: 20
          probe: {
            id: '${appgwId}/probes/${appgwHealthProbeName}${item.name}'
          }
        }
      }]

Firewall de aplicaciones web

El firewall de aplicaciones web (WAF) de Application Gateway protege las aplicaciones web de ataques maliciosos, como la inyección SQL. También se integra con Azure Monitor, para supervisar los ataques mediante un registro en tiempo real. Es necesario que WAF se habilite en la puerta de enlace, como se describe en Creación de una puerta de enlace de aplicaciones con un firewall de aplicaciones web mediante Azure Portal. La implementación de referencia habilita WAF mediante programación en el archivo appgw.bicep con el siguiente fragmento:

        webApplicationFirewallConfiguration: {
        enabled: true
        firewallMode: 'Detection'
        ruleSetType: 'OWASP'
        ruleSetVersion: '3.0'
      }

Virtual Network

Los grupos de seguridad de red pueden asociarse a una o varias subredes de la red virtual. Se trata de reglas de seguridad que permiten o deniegan el tráfico entre distintos recursos de Azure. Esta arquitectura asocia un grupo de seguridad de red independiente para cada subred. Esto permite el ajuste fino de estas reglas por subred, según los servicios contenidos en esa subred. Por ejemplo, consulte la configuración para "type": "Microsoft.Network/networkSecurityGroups" en el archivo ase.bicep para el grupo de seguridad de red para la subred App Service Environment, y en el archivo appgw.bicep para el grupo de seguridad de red para la subred Application Gateway.

Los puntos de conexión privados permiten la conectividad privada de seguridad mejorada entre los clientes y los servicios de Azure a través de una red privada. Proporcionan una dirección IP accesible de forma privada para el servicio de Azure, lo que permite el tráfico de seguridad mejorada a un recurso de Azure Private Link. La plataforma valida las conexiones de red, permitiendo sólo aquellas que se conectan al recurso Private Link especificado. Los puntos de conexión privados admiten directivas de red como grupos de seguridad de red, rutas definidas por el usuario y grupos de seguridad de aplicaciones. Para mejorar la seguridad, debe habilitar puntos de conexión privados para cualquier servicio de Azure que los admita. A continuación, puede mejorar la seguridad del servicio en la red virtual deshabilitando el acceso público, bloqueando eficazmente cualquier acceso desde la red pública de Internet. Esta arquitectura configura puntos de conexión privados para los servicios que la soportan: Azure Service Bus, SQL Server, Key Vault y Azure Cosmos DB. Puede ver la configuración en privatendpoints.bicep.

Para habilitar puntos de conexión privados, también debe configurar zonas DNS privadas. Para obtener más información, vea Configuración de DNS para puntos de conexión privados de Azure.

Firewall

Azure Firewall y los puntos de conexión privados de servicio se complementan entre sí. Los puntos de conexión privados ayudan a proteger los recursos al permitir solo el tráfico que se origina en la red virtual. Azure Firewall permite restringir el tráfico saliente de las aplicaciones. Se recomienda permitir que todo el tráfico saliente pase a través de la subred del firewall, incluido el tráfico del punto de conexión privado. Esto permite una mejor supervisión del tráfico saliente. En aras de la simplicidad, esta arquitectura de referencia configura todos los puntos de conexión privados en la subred de servicios en lugar de en la subred del firewall.

Para saber cómo se integra Azure Firewall con App Service Environment, consulte Configuración de Azure Firewall con su App Service Environment. El firewall supervisa y bloquea todo el tráfico que no atraviesa los puntos de conexión privados y la tabla de rutas de la red virtual.

Microsoft Entra ID

Microsoft Entra ID proporciona características de seguridad para autenticar aplicaciones y autorizar el acceso a los recursos. Esta arquitectura de referencia usa dos características clave de Microsoft Entra ID: identidades administradas y control de acceso basado en roles de Azure.

En las aplicaciones en la nube, las credenciales necesarias para autenticarse en los servicios en la nube deben estar protegidas. Lo ideal sería que las credenciales nunca aparecieran en las estaciones de trabajo de los desarrolladores o que se protegieran en el control de código fuente. Azure Key Vault proporciona una manera de almacenar de forma segura credenciales y secretos, pero la aplicación todavía tiene que autenticarse en Key Vault para recuperarlos. Las identidades administradas para los recursos de Azure proporcionan a los servicios de Azure una identidad administrada automáticamente en Microsoft Entra ID. Esta identidad puede usarse para autenticarse en cualquier servicio que admita la autenticación de Microsoft Entra, incluido Key Vault, sin necesidad de credenciales en la aplicación.

El control de acceso basado en roles de Azure (RBAC de Azure) administra el acceso a los recursos de Azure. Esto incluye:

• Qué entidad tiene el acceso: usuario, identidad gestionada, entidad de seguridad principal.
• Qué tipo de acceso tiene: propietario, colaborador, lector, administrador.
• Alcance del acceso: recurso, grupo de recursos, suscripción o grupo de gestión.

Puede bloquear el acceso a las aplicaciones del Entorno App Service controlando estrictamente el rol requerido y el tipo de acceso para cada aplicación. De este modo, se pueden implantar varias aplicaciones en el mismo App Service Environment desde distintos equipos de desarrollo. Por ejemplo, un equipo podría controlar el front-end y otro equipo, el back-end. RBAC de Azure se puede usar para limitar el acceso de cada equipo a las aplicaciones en las que se está trabajando. Explore Roles personalizados de Azure para crear roles adecuados para su organización.

Key Vault

Algunos servicios admiten identidades gestionadas pero utilizan Azure RBAC para configurar los permisos de la aplicación. Por ejemplo, consulte los roles incorporados de Service Bus y Azure RBAC en Azure Cosmos DB. Se requiere el acceso de Propietario a la suscripción para conceder estos permisos, aunque el personal con acceso de Colaborador puede implementar estos servicios. Para permitir que un equipo más amplio de desarrolladores pueda ejecutar los scripts de implementación, la siguiente mejor opción es usar las directivas de control de acceso nativo del servicio:

• En Service Bus, se trata de firmas de acceso compartido.
• Para Azure Cosmos DB, son las claves.

Las cadenas de conexión para estas directivas de control de acceso se almacenan en Key Vault. Se accede al almacén a través de identidades gestionadas, que requieren Azure RBAC. Establezca la directiva de acceso para estas cadenas de conexión de forma adecuada. Por ejemplo, solo lectura para el back-end, solo escritura para el front-end, etc., en lugar de usar la directiva de acceso raíz predeterminada.

El siguiente código en services.bicep muestra la configuración de Key Vault para estos servicios:

      resource keyVaultName_CosmosKey 'Microsoft.KeyVault/vaults/secrets@2022-07-01' = {
      parent: keyVaultName
      name: 'CosmosKey'
      properties: {
        value: cosmosName.listKeys().primaryMasterKey 
      }
    }

      resource keyVaultName_ServiceBusListenerConnectionString 'Microsoft.KeyVault/vaults/secrets@2022-07-01' = {
      parent: keyVaultName
      name: 'ServiceBusListenerConnectionString'
      properties: {
        value: listKeys(serviceBusName_ListenerSharedAccessKey.id, '2021-11-01').primaryConnectionString
      }
    }

      resource keyVaultName_ServiceBusSenderConnectionString 'Microsoft.KeyVault/vaults/secrets@2022-07-01' = {
      parent: keyVaultName
      name: 'ServiceBusSenderConnectionString'
      properties: {
        value: listKeys(serviceBusName_SenderSharedAccessKey.id, '2021-11-01').primaryConnectionString
      }
    }

Las aplicaciones acceden a estos valores de la cadena de conexión; para ello, hacen referencia al par clave-valor de Key Vault. Esto se hace en el archivo sites.bicep , como se muestra en el código siguiente de Voting App:

  properties: {
    enabled: true
    hostingEnvironmentProfile: {
      id:aseId
    }
    serverFarmId: votingWebPlanName.id
    siteConfig: {
      appSettings: [
        {
          name: 'ConnectionStrings:sbConnectionString'
          value: '@Microsoft.KeyVault(SecretUri=${reference(resourceId('Microsoft.KeyVault/vaults/secrets', keyVaultName, serviceBusSenderConnectionStringSecretName), '2022-07-01').secretUriWithVersion})'
        }
        {
          name: 'ConnectionStrings:RedisConnectionString'
          value: '@Microsoft.KeyVault(SecretUri=${reference(keyVaultName_redisSecretName.id, '2022-07-01').secretUriWithVersion})'
        }
        {
          name: 'ConnectionStrings:CosmosKey'
          value: '@Microsoft.KeyVault(SecretUri=${reference(resourceId('Microsoft.KeyVault/vaults/secrets', keyVaultName, cosmosKeySecretName), '2022-07-01').secretUriWithVersion})'
        }
      ]
    }
  }

La función también tiene acceso a la cadena de conexión del agente de escucha de Service Bus de una manera similar.

Escalabilidad

Diseño de aplicaciones escalables

La aplicación de esta arquitectura de referencia está estructurada para que se puedan escalar componentes individuales en función del uso. Cada aplicación web, API y función se implementa en su propio plan de App Service. Puede supervisar cada aplicación en busca de cuellos de botella de rendimiento y, a continuación, escalarla verticalmente si es necesario.

Escalado automático Application Gateway

El escalado automático se puede habilitar en la versión 2 de Azure Application Gateway. Esto permite a App Gateway escalar o reducir verticalmente en función de los patrones de carga de tráfico. Esta arquitectura de referencia configura autoscaleConfiguration en el archivo appgw.bicep para escalar entre cero y diez instancias adicionales. Vea Escalado de Application Gateway y WAF v2 para más información.

Implementación

Los scripts de implementación de esta arquitectura de referencia se utilizan para implementar App Service Environment, otros servicios y las aplicaciones dentro de App Service Environment. Una vez implementadas estas aplicaciones, es posible que las empresas deseen tener un plan de integración e implementación continuas para las actualizaciones y el mantenimiento de las aplicaciones. Esta sección muestra algunas de las formas más comunes que los desarrolladores utilizan para CI/CD de aplicaciones App Service Environment.

Las aplicaciones sólo pueden desplegarse en un Entorno de Servicio de Aplicaciones interno desde dentro de la red virtual. Los tres métodos siguientes son ampliamente utilizados para desplegar aplicaciones del Entorno App Service:Environment:

• Manualmente dentro de la Azure Virtual Network: Cree una máquina virtual dentro de la red virtual App Service Environment con las herramientas necesarias para el despliegue. Abra la conexión RDP a la máquina virtual con una configuración de NSG. Copie sus artefactos de código en la máquina virtual, compílelos y despliéguelos en la subred App Service Environment. Se trata de una manera sencilla de configurar un entorno de desarrollo de prueba y compilación inicial. No obstante, no se recomienda para el entorno de producción, ya que no puede escalar el rendimiento de implementación requerido.

• Conexión punto a punto desde la estación de trabajo local: Esto le permite extender su red virtual App Service Environment a su máquina de desarrollo, y desplegar desde allí. Esta es otra manera de configurar un entorno de desarrollo inicial, que no se recomienda para producción.

• Mediante Azure Pipelines: implementa una canalización de CI/CD completa, finalizando en un agente ubicado dentro de la red virtual. Esto es ideal para entornos de producción que requieren un alto rendimiento de implementación. La canalización de compilación permanece completamente fuera de la red virtual. La canalización de despliegue copia los objetos creados en el agente de creación dentro de la red virtual y, a continuación, los despliega en la subred del entorno de servicios de aplicaciones. Para obtener más información, lea este debate sobre el agente de compilación autoalojado entre Pipelines y la red virtual App Service Environment.

Se recomienda usar Azure Pipelines para entornos de producción. La creación de scripts de CI/CD con la ayuda del esquema de YAML de Azure Pipelines permite automatizar los procesos de compilación e implementación. azure-pipelines.yml implementa una canalización de CI/CD para la aplicación web en esta implementación de referencia. Hay scripts de CI/CD similares para la API web y para la función. Lea Uso de Azure Pipelines para obtener información sobre cómo se usan para automatizar CI/CD para cada aplicación.

Algunas empresas pueden no querer mantener un agente de construcción permanente dentro de la red virtual. En ese caso, puede elegir crear un agente de compilación dentro de la canalización de DevOps y anularlo una vez completada la implementación. Esto agrega otro paso en DevOps, pero reduce la complejidad del mantenimiento de la máquina virtual. Incluso puede considerar el uso de contenedores como agentes de compilación, en lugar de máquinas virtuales. Los agentes de compilación también pueden evitarse por completo desplegándolos desde un archivo comprimido situado fuera de la red virtual, normalmente en una cuenta de almacenamiento. La cuenta de almacenamiento deberá ser accesible desde el App Service Environment. La canalización debe ser capaz de acceder al almacenamiento. Al final de la canalización de versión, se puede colocar un archivo ZIP en el almacenamiento de blobs. El App Service Environment puede entonces recogerlo y desplegarlo. Tenga en cuenta las siguientes limitaciones de este enfoque:

• Existe una desconexión entre DevOps y el proceso de implementación real, lo que provoca dificultades en la supervisión y el seguimiento de cualquier problema de implementación.
• En un entorno bloqueado con tráfico protegido, puede que tenga que cambiar las reglas para acceder al archivo ZIP en el almacenamiento.
• Tendrá que instalar extensiones y herramientas específicas en el App Service Environment para poder desplegar desde el zip.

Para conocer otras formas de implementar las aplicaciones en los planes de App Service, lea los artículos de App Service que se centran en las estrategias de implementación.

Optimización de costos

Puede usar la calculadora de precios de Azure para calcular los costos. Otras consideraciones se describen en la sección Costo de Marco de buena arquitectura de Microsoft Azure. Las reservas de Azure le ayudan a ahorrar dinero, ya que se compromete a planes de uno o tres años para muchos productos de Azure. Lea más en el artículo Adquisición de una reserva.

Estos son algunos puntos que se deben tener en cuenta para algunos de los servicios clave que se usan en esta arquitectura.

App Service Environment v3

Hay varias opciones de precios disponibles para App Service. Se despliega un Entorno App Service utilizando el Plan de Servicio Aislado v2. Dentro de este plan, hay múltiples opciones de tamaños de CPU, desde I1v2 hasta I6v2. Esta implementación de referencia utiliza tres I1v2 por instancia.

Application Gateway

Los precios de Application Gateway ofrecen varias opciones de precios para App Gateway. Esta implementación utiliza la SKU Application Gateway Standard v2 y WAF v2, que admite el autoescalado y la redundancia de zonas. Consulte Escalado de Application Gateway v2 y WAF v2 para obtener más información sobre el modelo de precios utilizado para esta SKU.

Azure Cache for Redis

Los precios de Azure Cache for Redis proporcionan las diversas opciones de precios para este servicio. Esta arquitectura usa la SKU Prémium para la compatibilidad con la red virtual.

A continuación se muestran las páginas de precios de otros servicios que se usan para bloquear la App Service Environment:

• Precios de Azure Firewall

• Precios de Key Vault

• Precios de Microsoft Entra

Implementación de este escenario

Para realizar la implementación de referencia de esta arquitectura, consulte el archivo Léame de GitHub y siga el script para implementaciones estándar.

Colaboradores

Microsoft mantiene este artículo. Originalmente lo escribieron los siguientes colaboradores.

Autor principal:

• Dhanashri Kshirsagar | Gestor de contenido sénior

Otros colaboradores:

• Deep Bhattacharya | Arquitecto de soluciones en la nube
• Suhas Rao | Arquitecto de soluciones en la nube

Para ver los perfiles no públicos de LinkedIn, inicie sesión en LinkedIn.

Pasos siguientes

• Ejecución de una aplicación en Azure App Service directamente desde un paquete ZIP
• Esquema de YAML de Azure Pipelines
• Obtención de direcciones de administración de la API
• Azure Key Vault
• Azure Pipelines

Recursos relacionados

Para obtener información sobre cómo ampliar esta arquitectura para admitir la alta disponibilidad, lea Implementación de aplicaciones de alta disponibilidad en Azure App Service Environment.