Aplicación web básica

En este artículo se proporciona una arquitectura básica dirigida a aprender a usar aplicaciones web en Azure App Service en una única región.

Arquitectura

Figura 1: Arquitectura básica de Azure App Service

Descargue un archivo Visio de esta arquitectura.

Flujo de trabajo

1. Un usuario emite una solicitud HTTPS al dominio predeterminado de App Service en azurewebsites.net. Este dominio apunta automáticamente a la dirección IP pública integrada de App Service. La conexión TLS se establece desde el cliente directamente a App Service. Azure administra completamente el certificado.
2. Easy Auth, una característica de Azure App Service, garantiza que el usuario que accede al sitio se autentique con Microsoft Entra ID.
3. El código de aplicación implementado en App Service controla la solicitud. Por ejemplo, ese código podría conectarse a una instancia de Azure SQL Database mediante un cadena de conexión configurada en App Service como una configuración de aplicación.
4. La información sobre la solicitud original a App Service y la llamada a Azure SQL Database se registran en Application Insights.

Componentes

• Microsoft Entra ID es un servicio de administración de identidades y accesos basado en la nube. Proporciona un único plano de control de identidades para administrar los permisos y roles de los usuarios que acceden a su aplicación web. Se integra con App Service y simplifica la autenticación y autorización para aplicaciones web.
• App Service es una plataforma totalmente administrada para crear, implementar y escalar aplicaciones web.
• Azure Monitor es un servicio de supervisión que recopila, analiza y actúa sobre los datos de telemetría en toda la implementación.
• Azure SQL Database es un servicio de base de datos relacional administrado para datos relacionales.

Recomendaciones y consideraciones

Los componentes enumerados en este vínculo de arquitectura a las guías de servicio del marco de arquitectura de Azure. En las guías de servicio se detallan recomendaciones y consideraciones para servicios específicos. En esta sección se amplía esa guía resaltando las recomendaciones y consideraciones clave del marco de arquitectura de Azure que se aplican a esta arquitectura. Para más información, consulte Marco de buena arquitectura de Microsoft Azure.

Esta arquitectura básica no está pensada para implementaciones de producción. La arquitectura favorece la simplicidad y la eficacia de los costos a través de la funcionalidad para permitir evaluar y obtener información sobre Azure App Service. En las secciones siguientes se describen algunas deficiencias de esta arquitectura básica, junto con recomendaciones y consideraciones.

Confiabilidad

La confiabilidad garantiza que la aplicación pueda cumplir los compromisos contraídos con los clientes. Para obtener más información, consulte Lista de comprobación de revisión de diseño para confiabilidad.

Dado que esta arquitectura no está diseñada para implementaciones de producción, a continuación se describen algunas de las características de confiabilidad críticas que se omiten en esta arquitectura:

• El plan de App Service está configurado para el nivel Standard, que no tiene compatibilidad con la zona de disponibilidad de Azure. App Service deja de estar disponible en caso de cualquier problema con la instancia, el bastidor o el centro de datos que hospeda la instancia.
• Azure SQL Database está configurado para el nivel Basic, que no admite la redundancia de zona. Esto significa que los datos no se replican en zonas de disponibilidad de Azure, lo que supone una pérdida de datos confirmados en caso de interrupción.
• Las implementaciones en esta arquitectura pueden provocar tiempo de inactividad con implementaciones de aplicaciones, ya que la mayoría de las técnicas de implementación requieren que se reinicien todas las instancias en ejecución. Los usuarios pueden experimentar errores 503 durante este proceso. Esto se soluciona en la arquitectura de línea de base a través de ranuras de implementación. El diseño cuidadoso de la aplicación, la administración de esquemas y el control de la configuración de la aplicación son necesarios para admitir la implementación de ranuras simultáneas. Use este POC para diseñar y validar el enfoque de implementación de producción basado en ranuras.
• El escalado automático no está habilitado en esta arquitectura básica. Para evitar problemas de confiabilidad debido a la falta de recursos de proceso disponibles, debe sobreaprovisionar para ejecutar siempre con suficiente capacidad de proceso para controlar la capacidad simultánea máxima.

Consulte cómo superar estos problemas de confiabilidad en la sección de confiabilidad de la aplicación web con redundancia de zona de alta disponibilidad de línea de base.

Si esta carga de trabajo finalmente requiere una arquitectura activa-activa o activa-pasiva de varias regiones, consulte Aplicación web para varias regiones con alta disponibilidad para obtener instrucciones sobre cómo implementar la carga de trabajo hospedada en App Service en varias regiones.

Seguridad

La seguridad proporciona garantías contra ataques deliberados y el abuso de datos y sistemas valiosos. Para obtener más información, consulte Lista de comprobación de revisión de diseño para seguridad.

Dado que esta arquitectura no está diseñada para implementaciones de producción, a continuación se describen algunas de las características de seguridad críticas que se omitieron en esta arquitectura, junto con otras recomendaciones y consideraciones de confiabilidad:

• Esta arquitectura básica no implementa la privacidad de la red. Los planos de datos y administración de los recursos, como Azure App Service y Azure SQL Server, son accesibles a través de la red pública de Internet. La omisión de redes privadas aumenta significativamente la superficie expuesta a ataques de la arquitectura. Para ver cómo la implementación de redes privadas garantiza las siguientes características de seguridad, consulte la sección de redes de la aplicación web con redundancia de zona de alta disponibilidad de línea de base:

  • Un único punto de entrada seguro para el tráfico de clientes
  • El tráfico de red se filtra en el nivel de paquete y en el nivel de DDoS.
  • La filtración de datos se minimiza manteniendo el tráfico en Azure mediante Private Link
  • Los recursos de red se agrupan y aíslan de forma lógica entre sí mediante la segmentación de la red.

• Esta arquitectura básica no incluye una implementación de Azure Web Application Firewall. La aplicación web no está protegida contra vulnerabilidades de seguridad comunes. Consulte la implementación de línea de base para ver cómo se puede implementar Web Application Firewall con Azure Application Gateway en una arquitectura de Azure App Services.

• Esta arquitectura básica almacena secretos como la cadena de conexión de Azure SQL Server en la configuración de la aplicación. Aunque la configuración de la aplicación se cifra, al pasar a producción, considere la posibilidad de almacenar secretos en Azure Key Vault para aumentar la gobernanza. Una solución todavía mejor es usar la identidad administrada para la autenticación y no tener secretos almacenados en el cadena de conexión.

• La depuración remota y los puntos de conexión de Kudu se pueden dejar habilitados durante la fase de desarrollo o de prueba de concepto. Al pasar a producción, debe deshabilitar el plano de control, la implementación o el acceso remoto innecesarios.

• Los métodos de autenticación local para las implementaciones de sitio FTP y SCM se pueden dejar habilitados durante la fase de desarrollo o de prueba de concepto. Al pasar a producción, debe deshabilitar la autenticación local en esos puntos de conexión.

• No es necesario habilitar Microsoft Defender para App Service en la fase de prueba de concepto. Al pasar a producción, debe permitir que Defender para App Service genere recomendaciones de seguridad que debe implementar para aumentar la posición de seguridad y detectar varias amenazas en App Service.

• Azure App Service incluye un punto de conexión SSL en un subdominio de azurewebsites.net sin costo adicional. Las solicitudes HTTP se redirigen al punto de conexión HTTPS de forma predeterminada. En el caso de las implementaciones de producción, normalmente usará un dominio personalizado asociado a Application Gateway o API Management delante de la implementación de App Service.

• Utiliza el mecanismo de autenticación integrado para App Service ("EasyAuth"). EasyAuth simplifica el proceso de integración de proveedores de identidad en su aplicación web. Gestiona la autenticación fuera de su aplicación web, por lo que no tiene que realizar cambios significativos en el código.

• Utiliza identidad gestionada para las identidades de carga de trabajo. La identidad administrada elimina la necesidad de que los desarrolladores administren las credenciales de autenticación. La arquitectura básica se autentica en SQL Server mediante contraseña en un cadena de conexión. Considere la posibilidad de usar la identidad administrada para autenticarse en Azure SQL Server.

Si quiere conocer otras consideraciones de seguridad, consulte Protección de una aplicación en Azure App Service.

Excelencia operativa

La excelencia operativa abarca los procesos de las operaciones que implementan una aplicación y la mantienen en ejecución en producción. Para obtener más información, consulte la Lista de comprobación de revisión de diseño para la excelencia operativa.

En las secciones siguientes se proporcionan instrucciones sobre la configuración, la supervisión y la implementación de la aplicación de App Service.

Configuraciones de aplicaciones

Dado que la arquitectura básica no está pensada para producción, usa la configuración de App Service para almacenar los valores de configuración y los secretos. Se pueden almacenar secretos en la configuración de App Service durante la fase de PoC. No usa secretos reales y no requiere la gobernanza de secretos que requieren las cargas de trabajo de producción.

A continuación se muestran las recomendaciones y consideraciones de configuración:

• Empiece por usar la configuración de App Service para almacenar valores de configuración y cadenas de conexión en las implementaciones de prueba de concepto. La configuración de la aplicación y las cadenas de conexión se cifran y descifran justo antes de inyectarse en la aplicación cuando se inicia.
• Al pasar a la fase de producción, almacene los secretos en Azure Key Vault. El uso de Azure Key Vault mejora la gobernanza de secretos de dos maneras:
  • La externalización del almacenamiento de secretos en Azure Key Vault permite centralizar el almacenamiento de secretos. Dispone de un lugar para administrar secretos.
  • Con Azure Key Vault, puede registrar cada interacción con secretos, incluyendo cada vez que se accede a un secreto.
• Al pasar a producción, puede mantener el uso de la configuración de Azure Key Vault y App Service mediante referencias de Key Vault.

Diagnóstico y supervisión

Durante la fase de prueba de concepto, es importante comprender qué registros y métricas están disponibles para capturarse. A continuación se muestran recomendaciones y consideraciones para la supervisión en la fase de prueba de concepto:

• Habilite el registro de diagnóstico para los orígenes de registro de todos los elementos. La configuración del uso de todas las opciones de diagnóstico le ayuda a comprender qué registros y métricas se proporcionan de fábrica y las brechas que deberá cerrar con una plataforma de registro en el código de la aplicación. Al pasar a producción, debe eliminar los orígenes de registro que no agregan valor y que agregan ruido y costo al receptor de registro de la carga de trabajo.
• Configure el registro para que use Azure Log Analytics. Azure Log Analytics proporciona una plataforma escalable para centralizar el registro que es fácil de consultar.
• Use Application Insights u otra herramienta de Administración del rendimiento de las aplicaciones (APM) para emitir telemetría y registros con el fin de supervisar el rendimiento de las aplicaciones.

Implementación

A continuación se muestran instrucciones sobre la implementación de la aplicación de App Service.

• Siga las instrucciones de CI/CD para Azure Web Apps con Azure Pipelines para automatizar la implementación de la aplicación. Empiece a compilar la lógica de implementación en la fase de PoC. La implementación de CI/CD al principio del proceso de desarrollo le permite iterar rápidamente y de forma segura en la aplicación a medida que avanza hacia la producción.
• Use plantillas de ARM para implementar recursos de Azure y sus dependencias. Es importante iniciar este proceso en la fase de PoC. A medida que avanza hacia la producción, quiere la capacidad de implementar automáticamente la infraestructura.
• Use diferentes plantillas de ARM e intégrelas con los servicios de Azure DevOps. Esta configuración le permite crear entornos diferentes. Por ejemplo, puede replicar escenarios similares a producción o entornos de prueba de carga solo cuando sea necesario y ahorrar costos.

Para más información, consulte la sección DevOps en Marco de buena arquitectura de Microsoft Azure.

Contenedores

La arquitectura básica se puede usar para implementar código compatible directamente en instancias de Windows o Linux. Como alternativa, App Service también es una plataforma de hospedaje de contenedores para ejecutar la aplicación web en contenedores. App Service ofrece varios contenedores integrados. Si usa aplicaciones personalizadas o de varios contenedores para ajustar aún más el entorno de tiempo de ejecución o para admitir un lenguaje de código no compatible de forma nativa, deberá introducir un registro de contenedor.

Plano de control

Durante la fase de PoC, familiarícese con el plano de control de Azure App Service tal como se expone a través del servicio Kudu. Este servicio expone las API de implementación comunes, como las implementaciones de archivos ZIP, además de los registros sin procesar y las variables de entorno.

Si usa contenedores, asegúrese de comprender la capacidad de Kudu para abrir una sesión SSH en un contenedor que admita funcionalidades de depuración avanzadas.

Eficiencia del rendimiento

La eficiencia del rendimiento es la capacidad que tiene la carga de trabajo para escalar con el fin de satisfacer de manera eficiente las demandas que los usuarios hayan realizado sobre ella. Para obtener más información, consulte Lista de comprobación de revisión de diseño para la eficiencia del rendimiento.

Dado que esta arquitectura no está diseñada para implementaciones de producción, a continuación se describen algunas de las características de eficiencia del rendimiento críticas que se omitieron en esta arquitectura, junto con otras recomendaciones y consideraciones.

Un resultado de la prueba de concepto debe ser la selección de SKU que calcule que es adecuada para la carga de trabajo. La carga de trabajo debe diseñarse para satisfacer la demanda de forma eficaz mediante el escalado horizontal ajustando el número de instancias de proceso implementadas en el plan de App Service. No diseñe el sistema para que dependa de cambiar la SKU de proceso para que se ajuste a la demanda.

• En esta arquitectura básica, App Service no tiene implementado el escalado automático. El servicio no se escala horizontalmente de forma dinámica ni se ajusta de forma eficaz a la demanda.
  • El nivel Estándar admite la configuración de autoescala para permitirle configurar el escalado automático basado en reglas. Parte del proceso de POC debe ser llegar a una configuración de escalado automático eficaz en función de las necesidades de recursos del código de la aplicación y las características de uso esperadas.
  • En el caso de las implementaciones de producción, considere usar los niveles Premium que admiten el escalado automático donde la plataforma controla automáticamente las decisiones de escalado.
• Siga las instrucciones para escalar verticalmente bases de datos individuales sin tiempo de inactividad de la aplicación si necesita un nivel de servicio o de rendimiento superior para SQL Database.

Implementación de este escenario

La guía está respaldada por un ejemplo de implementación que muestra una implementación básica de App Service en Azure.

Pasos siguientes

Recursos relacionados

• Aplicación web con redundancia de zona de línea de base
• Aplicación web de varias regiones de alta disponibilidad

Documentación del producto:

• Información general de App Service
• Introducción a Azure Monitor
• Introducción a los planes de Azure App Service
• Introducción a Log Analytics en Azure Monitor
• ¿Qué es Microsoft Entra ID?
• ¿Qué es Azure SQL Database?

Módulos de Microsoft Learn:

• Configuración y administración de Azure Monitor
• Configuración de Microsoft Entra ID
• Configuración de Azure Monitor
• Implementación y configuración de servidores, instancias y bases de datos para Azure SQL
• Explorar Azure App Service
• Hospedaje de una aplicación web con Azure App Service
• Hospedaje de su dominio en Azure DNS
• Implementación de Azure Key Vault
• Administración de usuarios y grupos en Microsoft Entra ID