Editar

Aplicación web básica

Azure App Service
Azure Key Vault
Azure Monitor
Azure SQL Database

Esta arquitectura muestra los componentes fundamentales de una aplicación web básica. Puede usar la arquitectura para compilar una aplicación web y, a continuación, personalizar la aplicación según sus necesidades.

Architecture

Diagram showing the reference architecture for a basic web application in Azure.

Descargue un archivo Visio de esta arquitectura.

Componentes

  • Azure App Service es una plataforma completamente administrada para crear e implementar aplicaciones en la nube. Permite definir un conjunto de recursos de proceso para que una aplicación web se ejecute, implemente aplicaciones web y configure ranuras de implementación.
  • Una ranura de implementación permite almacenar provisionalmente una implementación y, posteriormente, intercambiarla con la implementación de producción. De este modo, evita realizar la implementación directamente en producción. Consulte la sección de ingeniería e implementación de versiones a continuación para obtener recomendaciones específicas.
  • Dirección IP: la aplicación de App Service tiene una dirección IP pública y un nombre de dominio. El nombre de dominio es un subdominio de azurewebsites.net, como contoso.azurewebsites.net.
  • Azure DNS es un servicio de hospedaje para dominios DNS que permite resolver nombres mediante la infraestructura de Microsoft Azure. Al hospedar dominios en Azure, puede administrar los registros DNS con las mismas credenciales, API, herramientas y facturación que con los demás servicios de Azure. Para usar un nombre de dominio personalizado, como contoso.com, cree registros DNS que asignen el nombre de dominio personalizado a la dirección IP. Para más información, consulte Configurar un nombre de dominio personalizado en Azure App Service.
  • Azure SQL Database es una base de datos como servicio relacional en la nube. SQL Database comparte su base de código con el motor de base de datos de Microsoft SQL Server. Según los requisitos de la aplicación, también puede usar Azure Database for MySQL o Azure Database for PostgreSQL. Se trata de servicios de bases de datos totalmente administrados, basados en los motores de bases de datos de código abierto MySQL Server y Postgres.
  • Microsoft Entra ID es un servicio de administración de identidades y acceso basado en la nube que permite a los empleados acceder a aplicaciones en la nube desarrolladas para su organización.
  • Azure Monitor es una solución para recopilar, analizar y actuar sobre registros y métricas en todos los entornos.
  • Azure Key Vault admite la administración de secretos, la administración de claves y la administración de certificados. Puede almacenar secretos de aplicación como cadenas de conexión de base de datos.

Recomendaciones

Los requisitos pueden diferir de la arquitectura descrita y dada en el código. El código se implementa con configuraciones de producción. Use las recomendaciones para personalizar la implementación para satisfacer sus necesidades.

Plan de App Service

El plan de App Service tiene diferentes planes de tarifa. Cada plan de tarifa admite varios tamaños de instancia, que se diferencian por el número de núcleos y la memoria. Puede cambiar el plan de tarifa después de la implementación seleccionando "Escalar verticalmente (Plan de App Service)" en el panel de navegación izquierdo. Estas son algunas recomendaciones de App Service:

  • Ejecute la carga de trabajo de producción en los planes de tarifa Básico, Estándar y Premium. En estos tres niveles, la aplicación se ejecuta en instancias de máquina virtual dedicadas y tiene recursos asignados que se pueden escalar horizontalmente.
  • Use los niveles Estándar y Premier si necesita escalabilidad automática y TLS/SSL.
  • Cree un plan de App Service diferente para pruebas y desarrollo. Use los niveles Gratis y Compartido (versión preliminar) para pruebas y desarrollo para mejorar la rentabilidad. Pero no use los niveles Gratis y Compartido para cargas de trabajo de producción. Los recursos compartidos no se pueden escalar horizontalmente.
  • Asegúrese de eliminar planes que no use, como las implementaciones de prueba. Los planes de App Service se facturan por segundo. Se le cobra por las instancias del plan de App Service, aunque la aplicación esté detenida. Para más información sobre planes y facturación de App Service, consulte:

La plantilla de ARM siguiente se implementa en el plan de tarifa Estándar.

SQL Database

  • Use Azure SQL Database para reducir la sobrecarga de administración. Azure SQL Database crea una construcción lógica que sirve como punto administrativo central para una colección de bases de datos. Esta construcción lógica reduce la sobrecarga de administración. Cada base de datos del grupo se implementa con un nivel de servicio específico. Dentro de cada grupo, las bases de datos no pueden compartir recursos. No existen costos de proceso para el servidor, pero debe especificar el nivel de cada base de datos. Por lo tanto, debido a los recursos dedicados, es posible que aumente el rendimiento, pero que el costo sea mayor.
  • Planee la capacidad, y elija un nivel de servicio y un nivel de rendimiento que se ajusten a sus necesidades. SQL Database admite los niveles de servicio Básico, Estándar y Premium, con varios niveles de rendimiento dentro de cada nivel medido en Unidades de transacción de base de datos (DTU).

Region

  • Cree el plan de App Service y la instancia de SQL Database en la misma región para minimizar la latencia de red. Por lo general, elija la región más cercana a los usuarios.
  • El grupo de recursos también tiene una región. Especifica dónde se almacenan los metadatos de implementación. Coloque el grupo de recursos y sus recursos en la misma región para mejorar la disponibilidad durante la implementación.
  • Use la calculadora de precios para calcular los costos.
  • Para más información, consulte la sección acerca de los costos del artículo sobre elmarco de buena arquitectura de Microsoft Azure.

Consideraciones

Estas consideraciones forman los pilares del Marco de buena arquitectura de Azure. Los pilares son un conjunto de principios guía para mejorar la calidad de una carga de trabajo. Para más información, consulte Marco de buena arquitectura de Microsoft Azure.

Eficiencia del rendimiento

Una de las ventajas principales de Azure App Service es la posibilidad de escalar la aplicación en función de la carga. Estas son algunas consideraciones que se deben tener en cuenta al planear el escalado de la aplicación.

Ajuste de escala de la aplicación de App Service

Hay dos formas de escalar una aplicación de App Service:

  • Escalar verticalmente significa cambiar el tamaño de la instancia. El tamaño de la instancia determina la memoria, el número de núcleos y el almacenamiento en cada instancia de máquina virtual. La escalabilidad vertical se puede ajustar manualmente cambiando el tamaño de la instancia o el nivel del plan.
  • Escalar horizontalmente significa agregar instancias para controlar el aumento de la carga. Cada nivel de precios tiene un número máximo de instancias. Puede escalar horizontalmente cambiando el recuento de instancias manualmente o configurando el escalado automático para que Azure agregue o quite instancias automáticamente según la programación y/o las métricas de rendimiento. Cada operación de escalado se realiza rápidamente y, normalmente, en unos segundos.

Para habilitar el escalado automático, cree un perfil de escalado automático que defina el número mínimo y máximo de instancias. Puede configurar perfiles basados en programación para desencadenar eventos de escalado. Por ejemplo, puede crear perfiles distintos para los días laborables y los fines de semana. Un perfil puede contener reglas sobre cuándo agregar o quitar instancias. Por ejemplo, agregar dos instancias si el uso de la CPU es superior al 70 % durante 5 minutos.

Recomendaciones para el ajuste de escala de una aplicación web:

  • Limite el escalado y la reducción vertical tanto como sea posible. Puede desencadenar un reinicio de la aplicación. En su lugar, escale horizontalmente. Seleccione un nivel y un tamaño que satisfagan sus requisitos de rendimiento con la carga típica y escale horizontalmente las instancias para controlar los cambios en el volumen de tráfico.
  • Habilite el escalado automático. Si la aplicación tiene una carga de trabajo normal predecible, cree perfiles para programar los recuentos de instancias con antelación. Si la carga de trabajo no es predecible, use el escalado automático basado en reglas para reaccionar a los cambios de carga cuando se produzcan. Puede combinar ambos enfoques.
  • Use el uso de CPU para las reglas de escalado automático. El uso de la CPU suele ser una buena métrica para las reglas de escalado automático. Sin embargo, debería realizar pruebas de carga de la aplicación, identificar posibles cuellos de botella y basar las reglas de escalado automático en esos datos.
  • Establezca un período de enfriamiento más corto para agregar instancias y uno más prolongado para quitarlas. Las reglas de escalado automático incluyen un período de enfriamiento. El período de enfriamiento es el intervalo que se debe esperar una vez completada una acción de escalado antes de iniciar la siguiente. El período de enfriamiento permite que el sistema se estabilice antes de realizar otro ajuste de escala. Por ejemplo, establezca 5 minutos para agregar una instancia y 60 minutos para quitarla. Es mejor agregar nuevas instancias rápidamente bajo una carga intensa para controlar el tráfico adicional y reducir el escalado gradualmente.

Escalado de bases de datos SQL

Escale verticalmente bases de datos individuales sin tiempo de inactividad de la aplicación si necesita un nivel de servicio o un nivel de rendimiento superior para SQL Database.

Para más información, consulte Escalar recursos de base de datos única en Azure SQL Database.

Confiabilidad

En el momento de escribir este artículo, el Acuerdo de Nivel de Servicio (SLA) para App Service es del 99,95 %. El SLA de App Service se aplica tanto a instancias únicas como múltiples. El Acuerdo de Nivel de Servicio para SQL Database es del 99,99 % para los niveles Básico, Estándar y Premium.

Copias de seguridad

SQL Database proporciona restauración a un momento dado y restauración geográfica para restaurar la pérdida de datos. Estas características están disponibles en todos los niveles y se habilitan automáticamente. No es necesario programar ni administrar las copias de seguridad.

  • Use la restauración a un momento dado. Puede usar la recuperación de un error humano mediante el restablecimiento de la base de datos a un momento anterior en el tiempo.
  • Use la restauración geográfica. Puede usar la recuperación de una interrupción del servicio mediante la restauración de una base de datos a partir de una copia de seguridad con redundancia geográfica.
  • Considere la posibilidad de usar la copia de seguridad y restauración de App Service. La copia de seguridad y restauración es una característica para los archivos de la aplicación. Sin embargo, los archivos de los que se realiza la copia de seguridad incluyen la configuración de la aplicación en texto sin formato, como cadenas de conexión.
  • Evite utilizar la característica de copia de seguridad de App Service para hacer copias de seguridad de las bases de datos SQL. Exporta la base de datos a un archivo BACPAC de SQL, que consume DTU. En su lugar, use la restauración a un momento dado de SQL Database descrita anteriormente. Para más información, consulte el tema sobre la continuidad del negocio en la nube y la recuperación ante desastres de la base datos con SQL Database.

Excelencia operativa

Cree grupos de recursos independientes para entornos de producción, desarrollo y pruebas. Los entornos independientes facilitan la administración de implementaciones, la eliminación de implementaciones de prueba y la asignación de derechos de acceso.

Al asignar recursos a grupos de recursos, tenga en cuenta las siguientes características:

  • Ciclo de vida. En general, coloque los recursos con el mismo ciclo de vida en el mismo grupo de recursos.
  • Acceso. Puede usar el control de acceso basado en rol (RBAC) de Azure para aplicar directivas de acceso a los recursos de un grupo.
  • Facturación. Puede ver los costes acumulados del grupo de recursos.

Para más información, consulte Información general de Azure Resource Manager.

Configuraciones de aplicaciones

  • Almacene los valores de configuración como valores de configuración de la aplicación. Defina la configuración de la aplicación en las plantillas de Resource Manager, o bien mediante PowerShell. En tiempo de ejecución, la configuración de la aplicación está disponible para la aplicación en forma de variables de entorno.
  • Nunca compruebe contraseñas, claves de acceso ni cadenas de conexión en el control de código fuente. En su lugar, pase los secretos como parámetros a un script de implementación que almacene estos valores como valores de configuración de la aplicación.
  • Cuando intercambia una ranura de implementación, los valores de configuración de la aplicación se intercambian de forma predeterminada. Si necesita una configuración diferente para producción y ensayo, puede crear configuraciones de la aplicación que se ciñan a un espacio y no se intercambien.

Diagnóstico y supervisión

DevOps

  • Use plantillas de ARM para implementar recursos de Azure y sus dependencias. La plantilla de ARM correspondiente implementa una sola aplicación web. Todos los recursos están aislados en la misma carga de trabajo básica. Este aislamiento de la carga de trabajo facilita la asociación de recursos específicos de la carga de trabajo a un equipo. A continuación, el equipo puede administrar de forma independiente todos los aspectos de esos recursos. Este aislamiento permite que el equipo de DevOps realice la integración continua y la entrega continua (CI/CD).
  • Use diferentes plantillas de ARM e intégrelas con los servicios de Azure DevOps. Esta configuración le permite crear entornos diferentes en cuestión de minutos. Por ejemplo, puede replicar escenarios similares a producción o entornos de prueba de carga solo cuando sea necesario y ahorrar costos.
  • Aprovisione varias instancias de la aplicación web. No quiere que la aplicación web dependa de una sola instancia y, posiblemente, cree un único punto de error. El uso de varias instancias mejora la resistencia y la escalabilidad.

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

Ingeniería e implementación de versiones

  • Use plantillas de Azure Resource Manager para aprovisionar los recursos de Azure. Las plantillas facilitan la automatización de las implementaciones a través de PowerShell o de la CLI de Azure.
  • Implemente la aplicación (código, archivos binarios y archivos de contenido). Tiene varias opciones, incluida la implementación desde un repositorio de Git local, mediante Visual Studio, o bien la implementación continua desde el control de código fuente basado en la nube. Consulte Documentación de implementación de Azure App Service.

Una aplicación de App Service siempre tiene una ranura de implementación denominada production. El espacio de producción representa el sitio de producción activo. Se recomienda crear un espacio de ensayo para la implementación de actualizaciones. Las ventajas de usar un espacio de ensayo incluyen:

  • Puede comprobar si la implementación finalizó correctamente antes de pasarla a producción.
  • La implementación en un espacio de ensayo garantiza que todas las instancias estén preparadas antes de pasarlas a producción. Muchas aplicaciones presentan tiempos de preparación y arranque en frío considerables.
  • Cree un tercer espacio para contener la última implementación correcta conocida. Después de intercambiar ensayo y producción, mueva la implementación de producción anterior (que ahora está en la fase de ensayo) en el último espacio correcto conocido. De este modo, si detecta un problema más tarde, puede revertir rápidamente a la última versión correcta conocida.

Swapping slots for production and staging deployments

  • Si realiza la reversión a una versión anterior, asegúrese de que los cambios del esquema de base de datos sean compatibles con versiones anteriores.
  • No use espacios en la implementación de producción para pruebas, ya que todas las aplicaciones del mismo plan de App Service comparten las mismas instancias de máquina virtual. Por ejemplo, las pruebas de carga pueden degradar el sitio de producción en vivo. En su lugar, use planes de App Service independientes para producción y prueba. Al colocar las implementaciones de prueba en un plan independiente, se aíslan de la versión de producción.

Seguridad

En esta sección se enumeran las consideraciones de seguridad que son específicas de los servicios de Azure descritos en este artículo. No es una lista completa de procedimientos de seguridad recomendados. Si quiere conocer otras consideraciones de seguridad, consulte Protección de una aplicación en Azure App Service.

Auditoría de SQL Database

La auditoría puede ayudarle a mantener el cumplimiento de normativas, y a conocer las discrepancias y anomalías que pueden indicar problemas en el negocio o infracciones de seguridad sospechosas. Consulte Introducción a la auditoría de SQL Database.

Ranuras de implementación

Cada ranura de implementación tiene una dirección IP pública. Proteja los espacios que no sean de producción mediante el inicio de sesión de Microsoft Entra para que solo los miembros de los equipos de desarrollo y DevOps puedan acceder a esos puntos de conexión.

Registro

Los registros nunca deben registrar las contraseñas de los usuarios ni otra información que pudiera utilizarse para cometer fraudes de identidad. Borre esos detalles de los datos antes de almacenarlos.

SSL

Una aplicación de App Service incluye un punto de conexión SSL en un subdominio de azurewebsites.net sin costo adicional alguno. El punto de conexión SSL incluye un certificado comodín para el dominio *.azurewebsites.net. Si usa un nombre de dominio personalizado, debe proporcionar un certificado que coincida con el dominio personalizado. El enfoque más sencillo consiste en adquirir un certificado directamente a través de Azure Portal. También puede importar certificados de otras entidades emisoras de certificados. Para más información, consulte Compra y configuración de un certificado SSL para Azure App Service.

HTTPS no está habilitado de forma predeterminada en la implementación de plantillas de ARM. Como procedimiento recomendado de seguridad, la aplicación debe exigir HTTPS mediante el redireccionamiento de las solicitudes HTTP. Puede implementar HTTPS dentro de la aplicación o usar una regla de reescritura de direcciones URL como se describe en Habilitación de HTTPS para una aplicación en Azure App Service.

Autenticación

Se recomienda realizar la autenticación a través de un proveedor de identidades (IDP), como Microsoft Entra ID, Facebook, Google o Twitter. Use OAuth 2 u OpenID Connect (OIDC) para el flujo de autenticación. Microsoft Entra ID proporciona funcionalidades para administrar usuarios y grupos, crear roles de aplicación, integrar las identidades locales y consumir servicios de back-end, como Microsoft 365 y Skype Empresarial.

Evite que la aplicación administre credenciales e inicios de sesión de usuario directamente. Crea una superficie de ataque potencial. Como mínimo, debería tener confirmación por correo electrónico, recuperación de contraseñas y autenticación multifactor, validación de la seguridad de la contraseña y almacenamiento de hashes de contraseña de forma segura. Los proveedores de identidades importantes controlan todas esas cosas en lugar del usuario, y supervisan y mejoran constantemente sus prácticas de seguridad.

Considere la posibilidad de usar la autenticación de App Service para implementar el flujo de autenticación de OAuth/OIDC. Las ventajas de la autenticación del App Service incluyen:

  • Es fácil de configurar.
  • No se requiere ningún código para los escenarios de autenticación simples.
  • Admite la autorización delegada mediante tokens de acceso de OAuth para consumir recursos en nombre del usuario.
  • Proporciona una memoria caché de tokens integrada.

Algunas limitaciones de la autenticación de App Service:

  • Opciones de personalización limitadas.
  • La autorización delegada está restringida a un recurso de back-end por cada sesión de inicio de sesión.
  • Si usa más de un IDP, no hay ningún mecanismo integrado para la detección del dominio kerberos de inicio.
  • Para los escenarios multiinquilino, la aplicación debe implementar la lógica para validar el emisor del token.

Implementación de este escenario

Esta arquitectura incluye un plan de Azure App Service y una aplicación vacía. Usa Azure SQL Database y Azure Key Vault para almacenar la cadena de conexión de base de datos y Azure Monitor para el registro, la supervisión y las alertas.

Use el siguiente comando para crear un grupo de recursos para la implementación. Para usar un shell insertado, seleccione el botón Pruébelo.

az group create --name basic-web-app --location eastus

Ejecute el siguiente comando para implementar la aplicación web y la infraestructura de apoyo. Cuando se le solicite, escriba un nombre de usuario y una contraseña. Estos valores se utilizan para acceder a la instancia de Azure SQL Database.

az deployment group create --resource-group basic-web-app  \
    --template-uri https://raw.githubusercontent.com/mspnp/samples/master/solutions/basic-web-app/azuredeploy.json

Para obtener información detallada y otras opciones de implementación, consulte las plantillas de ARM que se usaron para implementar esta solución.

Plantilla de Resource Manager de aplicación web básica

Pasos siguientes

Sugerencias para solucionar problemas de la aplicación:

Documentación del producto:

Módulos de Microsoft Learn: