Aplicación web básica

Azure App Service
Azure Monitor
Azure SQL Database

En este artículo se proporciona una arquitectura básica que le ayudará a obtener información sobre la ejecución de aplicaciones web en Azure App Service en una sola región.

Importante

Esta arquitectura no está pensada para aplicaciones de producción. Sirve como una configuración introductoria para fines de aprendizaje y prueba de concepto (POC). Para diseñar una aplicación de App Service de producción, consulte Aplicación web con alta disponibilidad y redundancia de zona como línea base.

Arquitectura

Diagrama que muestra una arquitectura básica de App Service.

Descargue un archivo Visio de esta arquitectura.

Flujo de trabajo

El siguiente flujo de trabajo corresponde al diagrama anterior.

  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 la aplicación de App Service. La conexión de seguridad de la capa de transporte (TLS) se establece desde el cliente directamente al App Service. Azure administra completamente el certificado.

  2. La autenticación sencilla, que es una característica de App Service, garantiza que el usuario que accede al sitio se autentique mediante 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 configurado 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 SQL Database se registra en Application Insights.

Componentes

  • Microsoft Entra ID es un servicio de administración de identidades y acceso basado en la nube que proporciona funcionalidades de autenticación y autorización. En esta arquitectura, se integra con App Service a través de Easy Auth para garantizar la autenticación para los usuarios que acceden a la aplicación web. También simplifica el proceso de autenticación sin necesidad de cambios significativos en el código.

  • App Service es una plataforma administrada para compilar, implementar y escalar aplicaciones web. En esta arquitectura, hospeda el código de la aplicación web, controla las solicitudes HTTPS en el dominio predeterminado azurewebsites.net y se conecta a SQL Database a través de cadenas de conexión configuradas.

  • Azure Monitor es un servicio de supervisión que recopila, analiza y actúa sobre datos de telemetría de entornos locales y en la nube. En esta arquitectura, captura y almacena información sobre las solicitudes a App Service y las llamadas a SQL Database mediante la integración de Application Insights.

  • SQL Database es un servicio de base de datos relacional administrado que proporciona funcionalidades de SQL Server en la nube. En esta arquitectura, actúa como la capa de almacenamiento de datos, que permite a la aplicación de App Service conectarse a través de cadenas de conexión definidas en la configuración de la aplicación.

Consideraciones

Estas consideraciones implementan los pilares del Azure Well-Architected Framework, que es un conjunto de principios rectores que puede utilizar para mejorar la calidad de una carga de trabajo. Para obtener más información, consulte Well-Architected Framework.

Los componentes enumerados en esta arquitectura están vinculados a las guías de servicio de Well-Architected. En las guías de servicio se detallan recomendaciones y consideraciones para servicios específicos. Esta sección amplía esa guía resaltando las recomendaciones y consideraciones clave deWell-Architected Framework que se aplican a esta arquitectura.

Esta arquitectura básica está diseñada solo para fines de evaluación y aprendizaje. Da prioridad a la simplicidad y la eficiencia de costo sobre la funcionalidad de grado de producción. En las secciones siguientes se resaltan las limitaciones clave de esta arquitectura y se proporcionan recomendaciones y consideraciones que le ayudarán a planear implementaciones más sólidas.

Confiabilidad

La confiabilidad ayuda a garantizar que la aplicación pueda cumplir los compromisos que realice para sus clientes. Para obtener más información, consulte Lista de comprobación de revisión de diseño para confiabilidad.

Esta arquitectura no está diseñada para implementaciones de producción. En esta arquitectura se omiten las siguientes características de confiabilidad críticas:

  • El plan de Servicio de Aplicaciones está configurado para el nivel Estándar, que no incluye compatibilidad con zonas de disponibilidad de Azure. App Service deja de estar disponible si se produce un problema con la instancia, el bastidor o el centro de datos que hospeda la instancia.

  • SQL Database está configurado para el nivel Básico, que no admite redundancia de zona. Como resultado, los datos no se replican en las Zonas de Disponibilidad de Azure, lo que conlleva el riesgo de pérdida de datos confirmados si se produce una interrupción.

  • Las implementaciones en esta arquitectura pueden provocar tiempo de inactividad para las 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. Este tiempo de inactividad de implementación se aborda en la arquitectura base a través de slots 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 esta prueba de concepto para diseñar y validar el enfoque de implementación en entorno productivo basado en slots.

  • El escalado automático no está habilitado en esta arquitectura básica. Para evitar problemas de confiabilidad causados por recursos informáticos insuficientes, debe sobreaprovisionar para garantizar una capacidad suficiente para manejar la demanda simultánea máxima.

Para obtener más información sobre cómo superar estos problemas de fiabilidad, consulte Aplicación web de alta disponibilidad y redundancia de zona - Fiabilidad.

Si la carga de trabajo requiere una arquitectura activa-activa o activa-pasiva de varias regiones, consulte Enfoques para aplicaciones de App Service de varias regiones ante la recuperación de desastres.

Seguridad

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

Esta arquitectura no está diseñada para implementaciones de producción. Las siguientes características de seguridad críticas 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 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 obtener más información sobre cómo implementar redes privadas garantiza las siguientes características de seguridad, consulte Aplicación web de alta disponibilidad y redundancia zonal de referencia – Redes. La implementación de redes privadas ayuda a mitigar estos riesgos al proporcionar las siguientes características de seguridad:

    • Un único punto de entrada seguro para el tráfico de cliente.

    • El tráfico de red se filtra tanto en el nivel de paquete como en el nivel de denegación de servicio distribuido (DDoS).

    • La filtración de datos se minimiza al mantener el tráfico en Azure mediante Azure 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. Para ver cómo se puede implementar Azure Web Application Firewall con Azure Application Gateway en una arquitectura de App Services, consulte la implementación baseline.

  • Esta arquitectura básica almacena secretos como la cadena de conexión de SQL Server en la Configuración de la aplicación. La configuración de la aplicación se cifra de forma predeterminada. Sin embargo, al pasar a producción, considere la posibilidad de almacenar secretos en Azure Key Vault para aumentar la gobernanza. Para mejorar la seguridad y reducir la sobrecarga de administración de secretos, considere la posibilidad de usar la identidad administrada para la autenticación en lugar de insertar secretos en cadenas de conexión.

  • Es posible que la depuración remota y los puntos de conexión de Kudu permanezcan habilitados durante el desarrollo o la fase de POC. 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 sitios de protocolo de transferencia de archivos (FTP) y gestión del control de origen (SCM) pueden permanecer habilitados durante la fase de desarrollo o POC. 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 POC. Al pasar a producción, debe habilitar Defender para que App Service genere recomendaciones de seguridad. Debe implementar estas recomendaciones para aumentar la posición de seguridad y detectar varias amenazas en la implementación de App Service.

  • 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 se usa un dominio personalizado con Application Gateway o API Management delante de la implementación de App Service.

  • Use el mecanismo de autenticación integrado para App Service. Easy Auth simplifica el proceso de integración de proveedores de identidades en la 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 una contraseña en un cadena de conexión. Considere la posibilidad de usar identidad administrada para autenticarse en SQL Server.

Para más información, consulte Protección de una aplicación en App Service.

Optimización de costos

La optimización de costos se centra en formas de reducir los gastos innecesarios y mejorar las eficiencias operativas. Para obtener más información, consulte Lista de comprobación de revisión de diseño para la optimización de costos.

Esta arquitectura optimiza el costo mediante muchos intercambios en relación con los otros pilares del Well-Architected Framework. Estas ventajas y desventajas se realizan específicamente para alinearse con los objetivos de aprendizaje y poC de esta arquitectura. El ahorro de costos en comparación con una arquitectura más preparada para producción, como la aplicación web de alta disponibilidad y redundancia entre zonas de referencia, se debe principalmente a las siguientes opciones:

  • Una única instancia de App Service, sin escalado automático habilitado

  • Plan de tarifa estándar para App Service

  • Sin certificado TLS personalizado ni dirección IP estática

  • Sin firewall de aplicaciones web (WAF)

  • Ninguna cuenta de almacenamiento dedicada para la implementación de aplicaciones

  • Plan de tarifa básico para SQL Database, sin directivas de retención de copia de seguridad

  • No hay componentes de Microsoft Defender para la nube

  • Ningún control de salida del tráfico de red a través de un firewall

  • Sin puntos de conexión privados

  • Registros mínimos y período de retención de registros en registros de Azure Monitor

Para ver el costo estimado de esta arquitectura, consulte la estimación preconfigurada en la calculadora de precios de Azure que usa los componentes de esta arquitectura. Normalmente, el costo de esta arquitectura se puede reducir aún más mediante una suscripción Azure Dev/Test, que sería un tipo de suscripción ideal para POC como este.

Excelencia operativa

La excelencia operativa abarca los procesos de operaciones que implementan una aplicación y lo 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. Puede almacenar secretos en la configuración de App Service durante la fase de POC. Usted no utiliza secretos reales ni requiere la gobernanza de secretos que exigen las cargas de trabajo de producción.

Tenga en cuenta las siguientes 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 implementaciones de POC. La configuración de la aplicación y las cadenas de conexión se cifran y descifran inmediatamente antes de insertarse en la aplicación cuando se inicia.

  • Al pasar a producción, almacene los secretos en Key Vault. Key Vault mejora la gobernanza de los secretos de dos maneras:

    • La externalización de los secretos a Key Vault proporciona una única ubicación centralizada para la administración segura de secretos.

    • Mediante el uso de Key Vault, puede registrar cada interacción con secretos, incluido cada vez que se accede a un secreto.

  • Al pasar a producción, puede mantener el uso de Key Vault y la configuración de App Service mediante referencias de Key Vault.

Contenedores

Puede usar la arquitectura básica para implementar código compatible directamente en Windows o instancias de Linux. Como alternativa, App Service también es una plataforma de hospedaje de contenedores que puede usar para ejecutar la aplicación web en contenedor. App Service proporciona varios contenedores integrados. Las aplicaciones personalizadas o de varios contenedores ayudan a ajustar el entorno en tiempo de ejecución o admiten lenguajes de código que no se admiten de forma nativa. Este enfoque requiere la introducción de un registro de contenedor.

Plano de control

Durante la fase de POC, familiarícese con el plano de control del servicio App, al que se puede acceder a través del servicio Kudu. Este servicio proporciona API de implementación comunes, como implementaciones ZIP, y expone registros sin procesar y variables de entorno.

Si usa contenedores, asegúrese de que comprende la capacidad de Kudu de abrir una sesión de Secure Shell (SSH) en un contenedor para admitir funcionalidades de depuración avanzadas.

Diagnóstico y supervisión

Durante la fase de POC, es importante entender qué registros y métricas están disponibles para la captura. Tenga en cuenta las siguientes recomendaciones e ideas para la supervisión en la fase de POC:

  • Habilite los registros de diagnóstico para todos los orígenes de registro de elementos. La configuración del uso de todas las opciones de diagnóstico le ayuda a comprender qué registros y métricas se proporcionan automáticamente y le ayuda a identificar los huecos que necesita cerrar mediante un marco de registro en el código de la aplicación. Al pasar a producción, elimine los orígenes de registro que no agregan valor, pero sí ruido y costo al sumidero de registros de su carga de trabajo.

  • Configura la configuración de los registros 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 de rendimiento de aplicaciones (APM) para emitir telemetría y registros para supervisar el rendimiento de la aplicación.

  • Use un modelo de salud que combina múltiples señales correlacionadas en estados de salud. Envíe alertas basadas en transiciones de estado en la arquitectura, no en umbrales de métricas aislados. Los modelos de estado de Azure Monitor ayudan a definir, medir y visualizar el estado de la carga de trabajo mediante la correlación de métricas, registros y trazas para obtener estados de estado procesables en los recursos y componentes de Azure.

    En esta arquitectura, el modelo de mantenimiento agrega señales de los recursos de App Service y SQL Database y de los componentes de la aplicación implementados en App Service. Evalúa la disponibilidad y la latencia, la conectividad de la base de datos y el rendimiento de las consultas, las tasas de éxito de autenticación y las señales de nivel de aplicación pertinentes. Cada entidad del modelo emite un estado de salud que se propaga y consolida a través de las cadenas de dependencias en un único indicador de nivel superior de la salud general de la carga de trabajo.

Implementación

Los puntos siguientes proporcionan instrucciones para implementar 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 construir la lógica de implementación en la fase de POC. La implementación de la integración continua y la entrega continua (CI/CD) al principio del proceso de desarrollo le permite iterar de forma rápida y segura en la aplicación a medida que avanza hacia la producción.

  • Utilice plantillas de Azure Resource Manager (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 poder implementar automáticamente la infraestructura.

  • Use diferentes plantillas de ARM e intégrelas con Azure DevOps Services. 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 obtener más información, consulte los principios de diseño de excelencia operativa.

Eficiencia del rendimiento

La eficiencia del rendimiento hace referencia a la capacidad de escalado de la carga de trabajo para satisfacer las demandas de los usuarios de forma eficaz. 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, en esta sección se describen algunas de las características críticas de eficiencia del rendimiento que se omitieron en esta arquitectura, junto con otras recomendaciones y consideraciones.

Un resultado de la POC debe ser una selección de SKU que calcule que es adecuada para la carga de trabajo. Diseñe la carga de trabajo 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 alinearse con la demanda.

  • La implementación de App Service en esta arquitectura básica no tiene implementado el escalado automático. El servicio no se escala horizontalmente ni verticalmente de forma dinámica para alinearse eficazmente con la demanda.

    • El nivel Estándar admite la configuración de escalado automático para permitirle configurar el escalado automático basado en reglas. Como parte del proceso de POC, determine la configuración de escalado automático eficaz adaptada a los requisitos de recursos del código de la aplicación y los patrones de uso esperados.

    • En el caso de las implementaciones de producción, considere 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.

Pasos siguientes

Tutoriales de implementación:

Documentación del producto:

Módulos de Microsoft Learn: