Publicación de las API internas para usuarios externos

En este escenario, una organización consolida varias API internamente mediante Azure API Management implementado en una instancia de Virtual Network.

Architecture

Descargue un archivo Visio de esta arquitectura.

El diagrama anterior cubre un ciclo de vida completo de las API internas que son consumidas por los usuarios externos.

Flujo de datos

El flujo de datos es el siguiente:

1. Los desarrolladores registran el código en un repositorio de GitHub que está conectado a un agente de canalización CI/CD que está instalado en una máquina virtual de Azure.
2. El agente envía la compilación a la aplicación API alojada en ILB ASE.
3. Azure API Management consume las API anteriores a través de los encabezados HOST que se especifican en la política 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 IP pública del 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 ayuda a 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.

Detalles del escenario

En este escenario, una organización aloja múltiples API mediante Azure Application Service Environment (ILB ASE) y quiere consolidar estas API internamente mediante el uso de Azure API Management (APIM) implementado dentro de una red virtual. 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 Azure Application Gateway de las solicitudes al servicio de API Management interno, que a su vez consume las API implementadas en ASE.

• 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.

Posibles casos de uso

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

Consideraciones

Estas consideraciones implementan los pilares del marco de buena arquitectura de Azure, que es un conjunto de principios guía que se pueden usar para mejorar la calidad de una carga de trabajo. Para más información, consulte Marco de buena arquitectura de Microsoft Azure.

Confiabilidad

La confiabilidad garantiza que la aplicación pueda cumplir los compromisos contraídos con los clientes. Para más información, consulte Resumen del pilar de confiabilidad.

Disponibilidad

Puede implementar el servicio Azure API Management 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.

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.

Seguridad

La seguridad proporciona garantías contra ataques deliberados y el abuso de datos y sistemas valiosos. Para más información, consulte Introducción al pilar de 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). Puede integrar las instancias de Application Gateway con Microsoft Defender for Cloud para proporcionar una manera perfecta de evitar las amenazas del entorno, así como detectarlas y responder a ellas. Para instrucciones generales de diseño de soluciones seguras, consulte Documentación de Azure Security Center.

Optimización de costos

La optimización de costos trata de buscar formas de reducir los gastos innecesarios y mejorar las eficiencias operativas. Para más información, vea Información general del pilar de optimización de costos.

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, puede encontrar la guía de precios de instancias de App Service Environment.

Puede configurar los precios de Application Gateway en función del nivel y los recursos necesarios.

Eficiencia del rendimiento

La eficiencia del rendimiento es la capacidad de la carga de trabajo para escalar con el fin de satisfacer de manera eficiente las demandas que los usuarios hayan ejercido sobre ella. Para obtener más información, vea Resumen del pilar de eficiencia del rendimiento.

Escalabilidad

Puede escalar horizontalmente las instancias de API Management 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 Básico y Estándar. 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. Puede configurar las aplicaciones hospedadas en las instancias de App Service Environment 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.

Implementación de este escenario

Requisitos previos y suposiciones

1. Debe comprar un nombre de dominio personalizado.
2. Necesita 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 desarrollo/pruebas.
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 mencionados en la sección Implementación. Puede configurar los nombres de recursos y los espacios de direcciones.

Implementación y agrupación de las partes

Debe configurar aún más los componentes implementados mediante la plantilla de Resource Manager anterior de la siguiente manera:

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 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 Azure 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. Cree un servicio de 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 APIM API 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 Application 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 completados correctamente los pasos anteriores, configure las entradas DNS en las entradas CNAME del registrador web de api.contoso.org y portal.contoso.org con el nombre DNS público de la instancia de Application Gateway: ase-appgtwy.westus.cloudapp.azure.com. Compruebe que puede acceder al portal de desarrollo desde público y que puede probar las API de servicios APIM mediante Azure Portal.

Colaboradores

Microsoft mantiene este artículo. Originalmente lo escribió el siguiente colaborador.

Autor principal:

• Srikant Sarwa | Ingeniero de clientes sénior

Otros colaboradores:

• Shawn Kupfer | Redactor técnico

Para ver los perfiles no públicos de LinkedIn, inicie sesión en LinkedIn.

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

Migración de una aplicación web mediante Azure API Management