Publicación de las API internas para usuarios externos

En este escenario, una organización ha hospedado varias API mediante instancias de Application Service Environment (ASE de ILB) y le gustaría consolidar estas API internamente mediante Azure API Management (APIM) implementado dentro de una instancia de Virtual Network. También se puede exponer la instancia de API Management interna a usuarios externos para permitir el uso de todo el potencial de las API. Esta exposición externa puede lograrse mediante el desvío por parte de Application Gateway de las solicitudes al servicio de API Management interno, que a su vez consume las API implementadas en ASE.

Posibles casos de uso

• Sincronizar la información de la dirección del cliente internamente después de un cambio realizado por el cliente
• Atraer a los desarrolladores a su plataforma mediante la exposición de recursos de datos únicos

Architecture

El escenario anterior abarca un ciclo de vida completo de las API internas que los usuarios externos consumen.

Flujo de datos

El flujo de datos es el siguiente:

1. Los desarrolladores registran código en un repositorio de GitHub conectado al agente de canalización de CI/CD instalado en una máquina virtual de Azure.
2. El agente inserta la compilación en la aplicación de API hospedada en ASE de ILB.
3. API Management consume las API anteriores a través de los encabezados HOST especificados en la directiva de API Management.
4. API Management usa el nombre DNS de las instancias de App Service Environment para todas las API.
5. Application Gateway expone el portal para desarrolladores y API de API Management.
6. Azure DNS privado se usa para enrutar el tráfico internamente entre ASE, API Management y Application Gateway.
7. Los usuarios externos usan el portal para desarrolladores expuesto para consumir las API a través de la dirección IP pública de Application Gateway.

Componentes

• Azure Virtual Network permite que recursos de Azure se puedan comunicar de forma segura entre ellos, con Internet y con redes en el entorno local.
• Azure DNS privado permite resolver nombres de dominio en una red virtual sin necesidad de agregar una solución DNS personalizada.
• Azure API Management ayuda a las organizaciones a publicar API para desarrolladores externos, asociados e internos para usar sus datos y servicios.
• Application Gateway es un equilibrador de carga de tráfico web que permite administrar el tráfico a las aplicaciones web.
• App Service Environment de equilibrador de carga interno es una característica de Azure App Service que proporciona un entorno completamente aislado y dedicado para ejecutar de forma segura las aplicaciones de App Service a gran escala.
• Azure DevOps es un servicio para administrar el ciclo de vida de desarrollo e incluye características para el planeamiento y administración del proyecto, la administración del código, la compilación y el lanzamiento.
• Application Insights es un servicio de Application Performance Management (APM) extensible para desarrolladores web en varias plataformas.
• Azure Cosmos DB es un servicio de base de datos con varios modelos distribuido de forma global de Microsoft.

Alternativas

• En un escenario lift-and-shift de Azure implementado en Azure Virtual Network, los servidores de back-end se podrían direccionar directamente a través de direcciones IP privadas.
• Si se usan recursos locales, la instancia de API Management podría llegar al servicio interno de forma privada mediante Azure VPN Gateway y una conexión VPN de IPSec de sitio a sitio o ExpressRoute, creando un escenario híbrido de Azure y entorno local.
• Se pueden usar proveedores DNS existentes o de código abierto en lugar del servicio DNS basado en Azure.
• Las API internas implementadas fuera de Azure todavía pueden beneficiarse de la exposición de las API a través del servicio API Management.

Consideraciones

• Las API web se hospedan a través del protocolo HTTPS seguro y usarán un certificado TLS.
• Application Gateway también se configura en el puerto 443 para llamadas salientes seguras y de confianza.
• El servicio API Management está configurado para usar dominios personalizados mediante certificados TLS.
• Revise la configuración de red sugerida para instancias de App Service Environment.
• Debe haber una mención explícita sobre el puerto 3443 que permita a API Management la administración a través de Azure Portal o PowerShell.
• Aproveche las directivas de APIM para agregar un encabezado HOST para la API hospedada en ASE. Esto garantiza que el equilibrador de carga de ASE desvíe correctamente la solicitud.
• API Management acepta la entrada DNS de ASE para todas las aplicaciones hospedadas en instancias de App Service Environment. Agregue una directiva de APIM para establecer explícitamente el encabezado HOST a fin de permitir que el equilibrador de carga de ASE distinga entre aplicaciones de App Service Environment.
• Considere la posibilidad de la integración con Azure Application Insights, que también expone las métricas mediante Azure Monitor para la supervisión.
• Si usa canalizaciones de CI/CD para implementar API internas, considere la posibilidad de crear su propio agente hospedado en una máquina virtual dentro de Virtual Network.

Disponibilidad

El servicio Azure API Management se puede implementar como una implementación de varias regiones para mayor disponibilidad y también para reducir latencias. Esta característica solo está disponible en modo premium. El servicio API Management de este escenario específico consume las API de instancias de App Service Environment. También puede usar APIM para las API hospedadas en la infraestructura local interna.

Las instancias de App Service Environment pueden usar perfiles de Traffic Manager para distribuir el tráfico hospedado en instancias de App Service Environment para una mayor escala y disponibilidad.

Escalabilidad

Las instancias de API Management se pueden escalar horizontalmente en función de una serie de factores, como el número y la velocidad de las conexiones simultáneas, el tipo y el número de directivas configuradas, los tamaños de solicitud y respuesta y las latencias de back-end en las API. Las opciones de escalado horizontal de la instancia están disponibles en los niveles básico, estándar y premium, pero tienen un límite de escala superior en los niveles por debajo de premium. Las instancias se conocen como unidades y se pueden escalar verticalmente hasta un máximo de dos unidades en el nivel básico, cuatro unidades en el nivel estándar y cualquier número de unidades en el nivel premium. También están disponibles opciones de escalado automático para habilitar el escalado horizontal basado en reglas.

Las instancias de App Service Environment están diseñadas para la escala con límites en función del plan de tarifa y las aplicaciones hospedadas en las instancias de App Service Environment pueden configurarse para escalar horizontalmente (número de instancias) o escalar verticalmente (tamaño de instancia) en función de los requisitos de la aplicación.

El escalado automático de Azure Application Gateway está disponible como parte de la SKU con redundancia de zona en todas las regiones globales de Azure. Vea la característica en vista previa pública sobre el escalado automático de App Gateway.

Seguridad

Dado que el escenario de ejemplo anterior se hospeda completamente en una red interna, API Management y ASE ya están implementados en la infraestructura protegida (red virtual de Azure). Las instancias de Application Gateway se pueden integrar con Microsoft Defender for Cloud para proporcionar una manera perfecta de evitar, detectar y responder a las amenazas del entorno. Para instrucciones generales de diseño de soluciones seguras, consulte Documentación de Azure Security Center.

Resistencia

Aunque este escenario de ejemplo trata más sobre la configuración, las API hospedadas en las instancias de App Service Environment deben ser lo suficientemente resistentes para controlar los errores de las solicitudes, que finalmente se administran mediante el servicio API Management y Application Gateway. Tenga en cuenta los patrones de reintento e interruptor en el diseño de la API. Para obtener instrucciones generales sobre el diseño de soluciones resistentes, consulte Diseño de aplicaciones resistentes de Azure.

Implementación de este escenario

Requisitos previos y suposiciones

1. Deberá adquirir un nombre de dominio personalizado.
2. Un certificado TLS (utilizamos un certificado comodín del servicio de certificados de Azure) para usar uno para todos los dominios personalizados. También puede adquirir un certificado autofirmado para escenarios de prueba de desarrollo.
3. Esta implementación específica usa el nombre de dominio contoso.org y un certificado TLS comodín para el dominio.
4. La implementación usa los nombres de recursos y los espacios de direcciones que se mencionan en la sección de implementación, y se pueden configurar.

Implementación y agrupación de las partes

Los componentes implementados con la plantilla de Resource Manager anterior deben configurarse más, tal como se indica a continuación.

1. Red virtual con las configuraciones siguientes:

   • Nombre: ase-internal-vnet
   • Espacio de direcciones para la red virtual: 10.0.0.0/16
   • Cuatro subredes
     • backendSubnet para el servicio DNS: 10.0.0.0/24
     • apimsubnet para el servicio API Management interno: 10.0.1.0/28
     • asesubnet para ILB ASE: 10.0.2.0/24
     • VMSubnet para máquinas virtuales de prueba y la máquina virtual de agente hospedado de DevOps interno: 10.0.3.0/24

2. Servicio DNS privado (versión preliminar pública), ya que la adición de un servicio DNS requiere que la red virtual esté vacía.

   • Consulte las instrucciones de implementación para más información.

3. App Service Environment con la opción del equilibrador de carga interno: aseinternal (DNS: aseinternal.contoso.org). Una vez completada la implementación, cargue el certificado comodín para ILB.

4. Plan de App Service con ASE como ubicación.

5. Una aplicación de API (App Services para simplificar): srasprest (URL: https://srasprest.contoso.org): API Web basada en MVC de ASP.NET. Después de que la implementación, configure

   • La aplicación web para usar el certificado TLS.
   • Application Insights para las aplicaciones anteriores: api-insights.
   • Cree un servicio de Cosmos DB para las API web hospedadas internamente en la red virtual: noderestapidb
   • Cree entradas DNS en la zona creada de DNS privado.
   • Puede usar Azure Pipelines para configurar los agentes en Virtual Machines a fin de implementar el código para la aplicación web en la red interna.
   • Para probar la aplicación de API internamente, cree una máquina virtual de prueba dentro de la subred de red virtual.

6. Crea un servicio API Management: apim-internal

7. Configure el servicio para que se conecte a la red virtual interna en la subred: apimsubnet. Una vez completada la implementación, lleve a cabo los siguientes pasos adicionales.

   • Configure dominios personalizados para los servicios APIM mediante TLS
     • Portal de API (api.contoso.org)
     • Portal para desarrolladores (api.contoso.org)
     • En la sección API, configure las aplicaciones de ASE con la directiva agregada de nombre DNS de ASE para el encabezado HOST de la aplicación web.
     • Use la máquina virtual de prueba creada anteriormente para probar el servicio de API Management interno en Virtual Network.

   Nota

   La prueba de las API de APIM desde Azure Portal no funcionará todavía, ya que api.contoso.org no puede resolverse públicamente.*

8. Configure Application Gateway (WAF V1) para tener acceso al servicio de API: apim-gateway en el puerto 80. Agregue certificados TLS a App Gateway y a los sondeos de estado y la configuración Http correspondientes. Configure también las reglas y los escuchas para usar el certificado TLS.

Una vez que se hayan completado correctamente los pasos anteriores, configure las entradas DNS en las entradas CNAME de GoDaddy de api.contoso.org y portal.contoso.org con el nombre DNS público de App Gateway: ase-appgtwy.westus.cloudapp.azure.com, y compruebe si puede tener acceso al portal para desarrolladores desde público para probar las API de servicios APIM con Azure Portal.

No es recomendable usar la misma dirección URL para los puntos de conexión interno y externo de los servicios APIM (actualmente en la demostración anterior, ambas direcciones URL son iguales). Si queremos tener direcciones de URL diferentes para los puntos de conexión interno y externo, podríamos usar WAF v2 de App Gateway, que admite la redirección http, entre otras muchas funciones.

Precios

API Management se ofrece en cuatro niveles: desarrollador, básico, estándar y premium. Puede encontrar instrucciones detalladas sobre las diferencias entre estos niveles en la guía de precios de Azure API Management.

Los clientes pueden escalar API Management agregando o quitando unidades. Cada unidad tiene una capacidad que depende de su nivel.

Para ver los costos proyectados y realizar la personalización pertinente en función de las necesidades de la implementación, puede modificar el número de unidades de escalado y las instancias de App Service en la Calculadora de precios de Azure.

De forma similar, aquí se proporciona la guía de precios de instancias de App Service Environment.

Los precios de Application Gateway se pueden configurar aquí en función del nivel y los recursos necesarios.

Pasos siguientes

• Tutorial: Importación y publicación de la primera API
• Tutorial: Crear y publicar un producto
• Tutorial: Publicación de varias versiones de la API

Recursos relacionados

Consulte el escenario relacionado en Migración de las API web heredadas a API Management