Édition

Publier des API internes pour des utilisateurs externes

Gestion des API
Application Gateway
Azure DevOps
Monitor
Réseau virtuel

Dans ce scénario, une organisation héberge plusieurs API à l’aide d’Azure App Service Environment (ASE) et souhaite consolider ces API en interne à l’aide de la Gestion des API Azure (APIM) déployée dans un réseau virtuel. L’instance de Gestion des API interne peut également être exposée à des utilisateurs externes pour permettre l’utilisation du potentiel complet des API. Cette exposition externe peut être obtenue en utilisant Azure Application Gateway pour transférer des demandes au service Gestion des API interne, qui utilise à son tour les API déployées dans l’ASE.

Cas d’usage potentiels

  • Synchroniser les informations d’adresse client en interne après une modification apportée par le client.
  • Attirer les développeurs sur votre plateforme en exposant des ressources de données uniques.

Architecture

Diagramme de l'architecture

Téléchargez un fichier Visio de cette architecture.

Le scénario ci-dessus couvre un cycle de vie complet d’API internes qui sont consommées par les utilisateurs externes.

Dataflow

Les données circulent comme suit :

  1. Les développeurs enregistrent le code dans un dépôt GitHub connecté à l’agent de pipeline CI/CD installé sur une machine virtuelle Azure.
  2. L’agent envoie la build à l’application API hébergée sur l’ASE ILB.
  3. La Gestion des API Azure consomme les API ci-dessus via les en-têtes HOST spécifiés dans la stratégie de la Gestion des API.
  4. La Gestion des API utilise le nom DNS de l’environnement de service d’application (App Service Environment, ASE) pour toutes les API.
  5. Application Gateway expose le portail des développeurs et des API de la Gestion des API.
  6. Un DNS privé Azure est utilisé pour acheminer le trafic en interne entre ASE, Gestion des API et Application Gateway.
  7. Des utilisateurs externes utilisent le portail des développeurs exposé pour consommer les API via l’adresse IP publique d’Application Gateway.

Composants

  • Le réseau virtuel Azure permet aux ressources Azure de communiquer en toute sécurité entre elles, avec Internet et avec des réseaux locaux.
  • Le DNS privé Azure permet de résoudre les noms de domaine dans un réseau virtuel sans avoir à ajouter une solution DNS personnalisée.
  • La Gestion des API Azure aide les organisations à publier des API pour des développeurs externes, partenaires, et internes, qui leur permettent d’utiliser leurs données et services.
  • Application Gateway est un équilibreur de charge de trafic web qui vous permet de gérer le trafic vers vos applications web.
  • L’environnement de service d’application (App Service Environment) de l’équilibreur de charge interne (ILB) est une fonctionnalité d’Azure App Service qui fournit un environnement totalement isolé et dédié pour l’exécution sécurisée d’applications App Service à grande échelle.
  • Azure DevOps est un service qui permet de gérer le cycle de vie de votre développement. Il inclut des fonctionnalités de planification et de gestion de projets, de gestion de code, de génération de build et de mise en production.
  • Application Insights est un service extensible de gestion des performances des applications (APM) destiné aux développeurs web sur de multiples plateformes.
  • Azure Cosmos DB est un service de base de données multimodèle de Microsoft distribué à l’échelle mondiale.

Autres solutions

Considérations

  • Les API web sont hébergées sur un protocole HTTPs sécurisé, et utilisent un Certificat TLS.
  • Application Gateway est également configurée sur le port 443 pour des appels sortants sécurisés et fiables.
  • Le service Gestion des API est configuré pour utiliser des domaines personnalisés à l’aide de certificats TLS.
  • Examinez la Configuration réseau suggérée pour les environnements App Service.
  • Il doit y avoir une mention explicite concernant le port 3443, autorisant le service Gestion des API à opérer via le Portail Azure ou PowerShell.
  • Tirez parti des stratégies de APIM pour ajouter un en-tête de l’hôte pour l’API hébergée sur l’ASE. Cela permet de s’assurer que l’équilibreur de charge d’ASE transfère correctement la demande.
  • La Gestion des API accepte l’entrée DNS d’ASE pour toutes les applications hébergées dans des environnements ASE. Ajoutez une stratégie APIM pour définir explicitement l’en-tête HOST afin de permettre à l’équilibreur de charge d’ASE de faire la différence entre les applications dans l’App Service Environment.
  • Envisagez d’intégrer Azure Application Insights qui expose également des métriques via Azure Monitor pour la supervision.
  • Si vous utilisez des pipelines CI/CD pour déployer des API internes, envisagez de créer votre propre agent hébergé sur une machine virtuelle au sein du réseau virtuel.

Disponibilité

Le service Gestion des API Azure peut être déployé en tant que déploiement multirégion pour améliorer la disponibilité et réduire les latences. Cette fonctionnalité n’est disponible qu’en mode Premium. Dans ce scénario spécifique, le service Gestion des API consomme les API des environnements ASE. Il est également possible d’utiliser APIM pour des API hébergées sur une infrastructure locale interne.

Des environnements ASE pourraient utiliser des profils Traffic Manager pour distribuer le trafic qu’ils hébergent pour une mise à l’échelle et une disponibilité supérieures.

Extensibilité

Les instances de Gestion des API peuvent faire l’objet d’une montée en puissance parallèle en fonction d’un certain nombre de facteurs tels que le nombre et la fréquence de connexions simultanées, le type et le nombre de stratégies configurées, les tailles de demande et de réponse, ainsi que les latences principales sur les API. Des options de montée en puissance parallèle d’instance sont disponibles aux niveaux De base, Standard et Premium, mais sont contraintes par une limite d’échelle supérieure aux niveaux inférieurs à Premium. Les instances, appelées unités, peuvent être mises à l’échelle jusqu’à un maximum de deux unités au niveau De base, quatre unités au niveau Standard et un nombre quelconque d’unités au niveau Premium. Des options de mise à l’échelle automatique sont également disponibles pour permettre la montée en puissance parallèle en fonction de règles.

Les environnements ASE sont conçus pour une mise à l’échelle avec des limites basées sur le niveau tarifaire, et les applications hébergées dans les environnements ASE peuvent être configurées pour la montée en puissance parallèle (nombre d’instances) ou la montée en puissance (taille d’instance) en fonction des exigences de l’application.

Une mise à l’échelle automatique d’Azure Application Gateway est disponible avec la référence (SKU) de zone redondante dans toutes les régions Azure globales. Consultez la fonctionnalité d’évaluation publique concernant la mise à l’échelle automatique d’Application Gateway.

Sécurité

Étant donné que l’exemple de scénario ci-dessus est entièrement hébergé sur un réseau interne, la Gestion des API et l’ASE sont déjà déployées sur une infrastructure sécurisée (réseau virtuel Azure). Application Gateway peut être intégré à Microsoft Defender pour le cloud pour fournir un moyen transparent d’empêcher, de détecter et de traiter les menaces pesant sur l’environnement. Pour obtenir des conseils d’ordre général sur la conception de solutions sécurisées, consultez la documentation sur la sécurité Azure.

Résilience

Dans cet exemple de scénario qui aborde plus en détail la configuration, les API hébergées sur les environnements ASE doivent être suffisamment résilientes pour gérer les erreurs dans les demandes, qui sont finalement gérées par le service Gestion des API et Application Gateway. Envisagez des modèles de nouvelle tentative et de disjoncteur dans la conception dAPI. Pour obtenir des conseils d’ordre général sur la conception de solutions résilientes, consultez l’article Conception d’applications résilientes pour Azure.

Optimisation des coûts

Le service Gestion des API est disponible en quatre niveaux : Développeur, De base, Standard et Premium. Vous trouverez des conseils détaillés sur la différence entre ces niveaux dans Tarification Gestion des API.

Les clients peuvent mettre à l’échelle Gestion des API en ajoutant et en supprimant des unités. La capacité de chaque unité dépend de son niveau.

Notes

Le niveau Développeur peut être utilisé pour l’évaluation des fonctionnalités du service Gestion des API. Le niveau Développeur ne doit pas servir pour la production.

Pour afficher les coûts prévus et effectuer une personnalisation en fonction des besoins de votre déploiement, vous pouvez modifier le nombre d’unités d’échelle et d’instances App Service dans la calculatrice de prix AzureApp Service.

De même, les conseils pour la tarification des environnements ASE sont fournis ici.

La tarification d’Application Gateway peut être configurée ici en fonction du niveau et des ressources requis.

Déployer ce scénario

Conditions préalables requises et hypothèses

  1. Vous devez acheter un nom de domaine personnalisé.
  2. Un certificat TLS (nous avons utilisé un certificat générique du service de certificats Azure) à utiliser pour tous nos domaines personnalisés. Vous pouvez également vous procurer un certificat auto-signé pour des scénarios de DevTest.
  3. Ce déploiement spécifique utilise le nom de domaine contoso.org et un certificat TLS générique pour le domaine.
  4. Le déploiement utilise les noms de ressources et les espaces d’adressage mentionnés dans la section déploiement, qui peuvent être configurés.

Déploiement et regroupement des éléments

Déployer sur Azure

Les composants déployés à l’aide du modèle Resource Manager ci-dessus doivent être configurés comme indiqué ci-dessous.

  1. Réseau virtuel avec les configurations suivantes :

    • Nom : ase-internal-vnet
    • Espace d’adressage pour réseau virtuel : 10.0.0.0/16
    • Quatre sous-réseaux
      • backendSubnet pour le service DNS : 10.0.0.0/24
      • apimsubnet pour le service de gestion des API internes : 10.0.1.0/28
      • asesubnet pour ILB ASE : 10.0.2.0/24
      • VMSubnet pour les machines virtuelles de test et la machine virtuelle de l’agent hébergé DevOps interne : 10.0.3.0/24

  2. Service de DNS privé (préversion publique), car l’ajout d’un service DNS nécessite que le réseau virtuel soit vide.

  3. App Service Environment avec l’option Internal Load Balancer (ILB) : aseinternal (DNS : aseinternal.contoso.org). Une fois le déploiement terminé, chargez le certificat générique pour l’ILB.

  4. Plan App Service avec ASE en tant qu’emplacement.

  5. Application API (App Services par souci de simplicité) - srasprest (URL : https://srasprest.contoso.org) – API web basée sur ASP.NET MVC. Après le déploiement, configurez :

    • application web pour utiliser le certificat TLS.
    • Application Insights pour les applications ci-dessus : API-Insights.
    • Créez un service Azure Cosmos DB pour les API web hébergées en interne sur le réseau virtuel : noderestapidb
    • Créez des entrées DNS sur la zone de DNS privé créée.
    • Vous pouvez utiliser Azure Pipelines pour configurer les agents sur des machines virtuelles afin de déployer le code de l’application web sur le réseau interne.
    • Pour tester l’application API en interne, créez une machine virtuelle de test dans le sous-réseau de réseau virtuel.

  6. Crée le service Gestion des API : apim-internal

  7. Configurez le service pour qu’il se connecte au réseau virtuel interne sur le sous-réseau : apimsubnet. Une fois le déploiement terminé, effectuez les étapes supplémentaires ci-dessous.

    • Configurez des domaines personnalisés pour les services APIM utilisant TLS :
      • Portail des API (api.contoso.org).
      • Portail de développement (portal.contoso.org).
      • Dans la section API, configurez les applications ASE à l’aide de la stratégie ajoutée Nom DNS d’ASE pour l’en-tête de l’hôte pour l’application web.
      • Utilisez la machine virtuelle de test créée ci-dessus pour tester le service Gestion des API interne sur le réseau virtuel.

    Notes

    Le test des API APIM à partir du Portail Azure ne fonctionnera toujours pas, car api.contoso.org ne peut pas être résolu publiquement.*

  8. Configurez Application Gateway (WAF v1) pour accéder au service API : apim-gateway sur le port 80. Ajoutez des certificats TLS à la Application Gateway, ainsi que les sondes d’intégrité et les paramètres Http correspondants. Configurez également les règles et les écouteurs pour utiliser le certificat TLS.

Une fois les étapes ci-dessus accomplies, configurez les entrées DNS dans les entrées CNAME GoDaddy de api.contoso.org et portal.contoso.org avec le Nom DNS public d’Application Gateway, ase-appgtwy.westus.cloudapp.azure.com, puis vérifiez si vous êtes en mesure d’atteindre le portail de développement à partir du portail public, et de tester les API des services APIM à l’aide du portail Azure.

Il n’est pas recommandé d’utiliser la même URL pour les points de terminaison interne et externe des services APIM (dans la démonstration ci-dessus, les deux URL sont identiques). Si vous souhaitez choisir des URL différentes pour les points de terminaison interne et externe, vous pourriez utiliser App Gateway WAF v2, qui prend en charge la redirection HTTP et bien plus encore.

Étapes suivantes

Consultez le scénario connexe sur la Migration d’API web héritées vers Gestion des API.