Editar

Compartir a través de


Publicación de las API internas para usuarios externos

Azure API Management
Azure Application Gateway
Azure DevOps
Azure Monitor
Azure Virtual Network

En este escenario, una organización consolida varias API internamente mediante Azure API Management implementado dentro de una red virtual.

Architecture

Diagrama de arquitectura que muestra el ciclo de vida completo de las API internas que son consumidas por los usuarios externos.

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 inserta la compilación en la aplicación de API hospedada en App Service Environment de ILB.
  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 App Service Environment para todas las API.
  5. Application Gateway expone el portal de API Management para desarrolladores y API.
  6. Azure DNS privado se usa para enrutar el tráfico internamente entre App Service Environment, 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 ayuda a administrar el tráfico a las aplicaciones web.
  • App Service Environment del equilibrador de carga interno es una característica de App de Azure Service que proporciona un entorno totalmente aislado y dedicado para ejecutar aplicaciones de App Service de forma segura 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 de migración mediante lift-and-shift de Azure implementado en una red virtual de Azure, los servidores back-end podrían abordarse directamente a través de direcciones IP privadas.
  • Si usa recursos locales, la instancia de API Management podría volver a ponerse en contacto con el servicio interno de forma privada a través de una instancia de Azure VPN Gateway y una conexión VPN de seguridad de protocolo de Internet (IPSec) de sitio a sitio o ExpressRoute que realiza un escenario híbrido de Azure y 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 hospeda varias API mediante App de Azure lication Service Environment (ILB App Service Environment) y quiere consolidar estas API internamente mediante Azure API Management (APIM) implementada 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 podría lograrse mediante App de Azure lication Gateway reenvío de solicitudes al servicio de API Management interno, que a su vez consume las API implementadas en App Service Environment.

  • Las API web se hospedan a través del protocolo HTTPS seguro y usarán un certificado TLS.
  • La puerta de enlace de aplicaciones también está configurada a través del puerto 443 para llamadas salientes seguras y confiables.
  • 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.
  • Use directivas dentro de APIM para agregar un encabezado HOST para la API hospedada en App Service Environment. Esto garantiza que el equilibrador de carga de App Service Environment reenvíe correctamente la solicitud.
  • API Management acepta la entrada DNS de App Service Environment para todas las aplicaciones hospedadas en Entornos de App Service. Agregue una directiva de APIM para establecer explícitamente el encabezado HOST para permitir que el equilibrador de carga de App Service Environment difera entre aplicaciones en 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 la red virtual.

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 App Service Environment ya están implementados en la infraestructura segura (Azure Virtual Network). 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.

Nota

Puede usar el nivel Desarrollador para la evaluación de las características de API Management. No debe usar el nivel Desarrollador para producción.

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

Implementación en Azure

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 siguientes configuraciones:

    • 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 App Service Environment de ILB: 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. DNS privado servicio (versión preliminar pública), ya que agregar un servicio DNS requiere que la red virtual esté vacía.

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

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

  5. Una aplicación de API (App Service para simplificar): srasprest (DIRECCIÓN URL: https://srasprest.contoso.org) – ASP.NET API web basada en Model-View-Controller (MVC). 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
    • Creación de entradas DNS en la zona de Azure DNS privado creada
    • 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 la red virtual.
  6. Cree un servicio de API Management: apim-internal.

  7. Configure el servicio para conectarse a la red virtual interna en 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 de desarrollo (portal.contoso.org)
      • En la sección API, configure las aplicaciones de App Service Environment mediante el nombre DNS agregado de App Service Environment para el encabezado HOST para 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 la puerta de enlace de aplicaciones para acceder al servicio de API: apim-gateway en el puerto 80. Agregue certificados TLS a la puerta de enlace de aplicaciones y los sondeos de estado correspondientes y la configuración HTTP. 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 y portal.contoso.org con el nombre DNS público de api.contoso.org 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.

Nota:

No se recomienda usar la misma dirección URL para los puntos de conexión internos y externos de los servicios APIM.

Colaboradores

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

Autor principal:

Otros colaboradores:

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

Pasos siguientes

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