Azure App Service es una eficaz plataforma de hospedaje de aplicaciones web. Azure Functions, basado en la infraestructura de App Service, le permite crear fácilmente cargas de trabajo de proceso controladas por eventos y sin servidor. Ambos servicios se usan con frecuencia en soluciones multiinquilino.
Características de Azure App Service y Azure Functions compatibles con multiinquilino
Azure App Service y Azure Functions incluyen muchas características compatibles con multiinquilino.
Nombres de dominio personalizados
Azure App Service le permite usar DNS con caracteres comodín y agregar sus propios certificados TLS con caracteres comodín. Cuando se usan subdominios específicos del inquilino, los certificados DNS y TLS con caracteres comodín le permiten escalar fácilmente la solución a un gran número de inquilinos, sin necesidad de una reconfiguración manual para cada nuevo inquilino.
Al usar nombres de dominio personalizados específicos del inquilino, es posible que tenga un gran número de nombres de dominio personalizados que deben agregarse a la aplicación. Puede resultar complicado administrar una gran cantidad de nombres de dominio personalizados, especialmente cuando requieren certificados TLS individuales. App Service proporciona certificados TLS administrados, lo que reduce el trabajo necesario cuando se trabaja con dominios personalizados. Sin embargo, hay límites que se deben tener en cuenta, como el número de dominios personalizados que se pueden aplicar a una sola aplicación.
Integración con Azure Front Door
App Service y Azure Functions se pueden integrar con Azure Front Door para actuar como el componente accesible a Internet de la solución. Azure Front Door permite agregar un firewall de aplicaciones web (WAF) y almacenamiento en caché perimetral, y proporciona otras optimizaciones de rendimiento. Puede volver a configurar fácilmente los flujos de tráfico para dirigir el tráfico a distintos back-end, en función de los cambiantes requisitos empresariales o técnicos.
Cuando se usa Azure Front Door con una aplicación multiinquilino, se puede usar para administrar los nombres de dominio personalizados y finalizar las conexiones TLS. La App Service se configura con un solo nombre de host y todo el tráfico fluye a través de esa aplicación, lo que ayuda a evitar la administración de nombres de dominio personalizados en varios lugares.
Como en el ejemplo anterior, Azure Front Door se puede configurar para modificar el Hostencabezado de la solicitud. El encabezado Host original enviado por el cliente se propaga a través del encabezado X-Forwarded-Host y el código de la aplicación puede usar este encabezado para asignar la solicitud al inquilino correcto.
Advertencia
Si la aplicación envía cookies o respuestas de redireccionamiento, debe tener cuidado especial. Los cambios en los encabezados Host de la solicitud podrían invalidar estas respuestas. Para más información, consulte el procedimiento recomendado para la conservación del nombre de host.
Puede usar puntos de conexión privados o restricciones de acceso de App Service para asegurarse de que el tráfico ha fluido a través de Front Door antes de llegar a la aplicación.
Para obtener más información sobre cómo usar Azure Front Door en una solución multiinquilino, consulte Uso de Azure Front Door en una solución multiinquilino.
Autenticación y autorización
Azure App Service puede validar tokens de autenticación en nombre de la aplicación. Cuando App Service recibe una solicitud, este comprueba si se cumplen cada una de las condiciones siguientes:
- La solicitud contiene un token.
- El token es válido.
- La solicitud está autorizada.
Si no se cumple alguna de las condiciones, App Service puede bloquear la solicitud o puede redirigir al usuario a su proveedor de identidades para que pueda iniciar sesión.
Si los inquilinos usan Microsoft Entra ID como su sistema de identidad, puede configurar Azure App Service para usar el punto de conexión /common para validar los tokens de usuario. Esto garantiza que, independientemente del inquilino de Microsoft Entra del usuario, sus tokens se validan y aceptan.
También puede integrar Azure App Service con Azure AD B2C para la autenticación de los consumidores.
Más información:
- Autorización de App Service
- Configuración de la autenticación en una aplicación web de ejemplo mediante Azure AD B2C
- Trabajar con identidades multiinquilino de Microsoft Entra
Restricciones de acceso
Puede restringir el tráfico a la aplicación mediante restricciones de acceso. Se pueden usar para especificar los intervalos de direcciones IP o las redes virtuales que pueden conectarse a la aplicación.
Cuando trabaje con una solución multiinquilino, tenga en cuenta el número máximo de reglas de restricción de acceso. Por ejemplo, si necesita crear una regla de restricción de acceso para cada inquilino, podría superar el número máximo de reglas permitidas. Si necesita un mayor número de reglas, considere la posibilidad de implementar un proxy inverso como Azure Front Door.
Modelos de aislamiento
Al trabajar con un sistema multiinquilino en el que se usa Azure App Service o Azure Functions, debe tomar una decisión sobre el nivel de aislamiento que quiere usar. Consulte los modelos de inquilino que se deben tener en cuenta para una solución multiinquilino y las instrucciones proporcionadas en los enfoques arquitectónicos para el proceso en soluciones multiinquilino, para ayudarle a seleccionar el mejor modelo de aislamiento para su escenario.
Al trabajar con Azure App Service y Azure Functions, debe tener en cuenta los siguientes conceptos clave:
- En Azure App Service, un plan representa su infraestructura de hospedaje. Una aplicación representa una sola aplicación que se ejecuta en esa infraestructura. Puede implementar varias aplicaciones en un solo plan.
- En Azure Functions, su hospedaje y aplicación también están separados, pero tiene opciones de hospedaje adicionales disponibles para el hospedaje elástico, donde Azure Functions administra el escalado por usted. Para simplificar, en este artículo nos referimos a la infraestructura de hospedaje como un plan, ya que los principios descritos aquí se aplican tanto a App Service como a Azure Functions, independientemente del modelo de hospedaje que use.
En la tabla siguiente se resumen las diferencias entre los principales modelos de aislamiento de inquilinos para Azure App Service y Azure Functions:
| Consideración | Aplicaciones compartidas | Aplicaciones por inquilino con planes compartidos | Planes por inquilino |
|---|---|---|---|
| Aislamiento de configuración | Bajo | Mediana. La configuración de nivel de aplicación se dedica al inquilino, la configuración de nivel de plan se comparte | Alta. Cada inquilino puede tener su propia configuración |
| Aislamiento de rendimiento | Bajo | Bajo-medio. Potencialmente sujeto a problemas de vecinos ruidosos | Alto |
| Complejidad de la implementación | Bajo | Medio | Alto |
| Complejidad operativa | Bajo | Alto | Alto |
| Costo de recursos | Bajo | Baja-alta en función de la aplicación | Alto |
| Escenario de ejemplo | Solución multiinquilino grande con un nivel de aplicación compartido | Migración de aplicaciones que no son compatibles con el inquilino a Azure al mismo tiempo que se obtiene cierta rentabilidad | Nivel de aplicación de inquilino único |
Aplicaciones compartidas
Puede implementar una aplicación compartida en un solo plan y usar la aplicación compartida para todos los inquilinos.
Esta suele ser la opción más rentable y requiere la menor sobrecarga operativa porque hay menos recursos que administrar. Puede escalar el plan general en función de la carga o la demanda, y todos los inquilinos que compartan el plan se beneficiarán de la mayor capacidad.
Es importante tener en cuenta las cuotas y los límites de App Service, como el número máximo de dominios personalizados que se pueden agregar a una sola aplicación y el número máximo de instancias de un plan que se pueden aprovisionar.
Para poder usar este modelo, el código de la aplicación debe ser compatible con multiinquilino.
Aplicaciones por inquilino con planes compartidos
También puede optar por compartir su plan entre varios inquilinos, pero implementar aplicaciones separadas para cada inquilino. Esto le proporciona aislamiento lógico entre cada inquilino y este enfoque le ofrece las siguientes ventajas:
- Rentabilidad: Al compartir la infraestructura de hospedaje, generalmente puede reducir los costes generales por inquilino.
- Separación de la configuración: La aplicación de cada inquilino puede tener su propio nombre de dominio, certificado TLS, restricciones de acceso y directivas de autorización de tokens aplicadas.
- Separación de actualizaciones: Los archivos binarios de aplicación de cada inquilino se pueden actualizar independientemente de otras aplicaciones del mismo plan.
Sin embargo, dado que los recursos de proceso del plan se comparten, las aplicaciones podrían estar sujetas al problema de vecino ruidoso. Además, hay límites en el número de aplicaciones que se pueden implementar en un solo plan.
Nota
No use ranuras de implementación para distintos inquilinos. Las ranuras no proporcionan aislamiento de recursos. Están diseñadas para escenarios de implementación cuando necesite tener varias versiones de su aplicación ejecutándose durante un breve período de tiempo, como implementaciones azul-verde y una estrategia de lanzamiento controlado.
Planes por inquilino
El nivel más sólido de aislamiento es implementar un plan dedicado para un inquilino. Este plan dedicado garantiza que el inquilino tenga el uso completo de todos los recursos de servidor asignados a ese plan.
Este enfoque le permite escalar la solución para proporcionar aislamiento de rendimiento para cada inquilino y evitar el problema de vecino ruidoso. Sin embargo, también tiene un coste mayor porque los recursos no se comparten con varios inquilinos. Además, debe tener en cuenta el número máximo de planes que se pueden implementar en un único grupo de recursos de Azure.
API de host
Puede hospedar las API tanto en Azure App Service como en Azure Functions. La elección de la plataforma dependerá del conjunto de características específico y de las opciones de escalado que necesite.
Independientemente de la plataforma que use para hospedar su API, considere la posibilidad de usar Azure API Management frente a su aplicación de API. API Management proporciona muchas características que pueden ser útiles para las soluciones multiinquilino, incluidas las siguientes:
- Un punto centralizado para toda autenticación. Esto puede incluir determinar el identificador de inquilino a partir de una notificación de token u otros metadatos de la solicitud.
- Enrutamiento de solicitudes a diferentes back-ends de API, que pueden basarse en el identificador de inquilino de la solicitud. Esto puede resultar útil cuando hospeda varios sellos de implementación, con sus propias aplicaciones de API independientes, pero debe tener una única dirección URL de API para todas las solicitudes.
Redes y multiinquilino
Direcciones IP
Muchas aplicaciones multiinquilino necesitan conectarse a las redes locales de los inquilinos para enviar datos.
Si necesita enviar tráfico saliente desde una dirección IP estática conocida o desde un conjunto de direcciones IP estáticas conocidas, considere la posibilidad de usar una puerta de enlace NAT Gateway. Para obtener más información sobre cómo usar NAT Gateway en soluciones multiinquilino, consulte Consideraciones de Azure NAT Gateway para la administración multiinquilino. App Service proporciona instrucciones sobre cómo integrarse con una NAT Gateway.
Si no necesita una dirección IP de salida estática, pero en su lugar necesita comprobar ocasionalmente la dirección IP que la aplicación usa para el tráfico saliente, puede consultar las direcciones IP actuales de la implementación de App Service.
Cuotas
Dado que App Service es en sí mismo un servicio multiinquilino, debe tener cuidado sobre cómo se usan los recursos compartidos. Las redes son una área a la que debe prestar especial atención, ya que hay límites que afectan al modo en que su aplicación puede funcionar con conexiones de red entrantes y salientes, incluida la traducción de direcciones de red de origen (SNAT) y los límites de puerto TCP.
Si la aplicación se conecta a un gran número de bases de datos o servicios externos, la aplicación podría estar en riesgo de agotamiento del puerto SNAT. En general, el agotamiento de puertos SNAT indica que el código no está reutilizando correctamente las conexiones TCP e, incluso en una solución multiinquilino, debe asegurarse de seguir los procedimientos recomendados para reutilizar las conexiones.
Sin embargo, en algunas soluciones multiinquilino, el número de conexiones salientes a distintas direcciones IP puede provocar el agotamiento de puertos SNAT, incluso si se siguen los procedimientos de codificación recomendados. En estos escenarios, considere una de las siguientes opciones:
- Implemente NAT Gateway para aumentar el número de puertos de SNAT que están disponibles para que la aplicación los use. Para obtener más información sobre cómo usar NAT Gateway en soluciones multiinquilino, consulte Consideraciones de Azure NAT Gateway para la administración multiinquilino.
- Use puntos de conexión de servicio al conectarse a servicios de Azure para omitir los límites del equilibrador de carga.
Incluso con estos controles en su lugar, puede aproximarse a los límites con un gran número de inquilinos, por lo que debe planear el escalado a planes de App Service adicionales o sellos de implementación.
Colaboradores
Microsoft mantiene este artículo. Originalmente lo escribieron los siguientes colaboradores.
Autor principal:
- John Downs | Ingeniero principal de software
Otros colaboradores:
- Thiago Almeida | Administrador de programas principal, Azure Functions
- Arsen Vladimirskiy | Principal Customer Engineer, FastTrack for Azure
Para ver los perfiles no públicos de LinkedIn, inicie sesión en LinkedIn.
Pasos siguientes
Revise Recursos para arquitectos y desarrolladores de soluciones multiinquilino.