Publier des API internes pour des utilisateurs externes

Dans ce scénario, une organisation consolide plusieurs API en interne à l’aide du service Gestion des API Azure déployé dans un réseau virtuel.

Architecture

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

Le diagramme 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 aide à 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

• Dans un scénario de migration lift-and-shift Azure déployé dans un réseau virtuel Azure, des serveurs principaux peuvent être adressés directement via des adresses IP privées.
• En cas d’utilisation de ressources locales, l’instance Gestion des API peut communiquer avec le service interne de façon privée via une passerelle VPN Azure et une connexion VPN IPSec site à site ou via ExpressRoute, ce qui crée un scénario hybride local et Azure.
• Il est possible d’utiliser des fournisseurs DNS existants ou open source à la place du service DNS basé sur Azure.
• Les API internes déployées en dehors d’Azure peuvent toujours bénéficier de l’exposition des API par le biais du service Gestion des API.

Détails du scénario

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.

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

Cas d’usage potentiels

• Synchronisez en interne les informations relatives à l'adresse du client lorsque celui-ci apporte une modification.
• Attirer les développeurs sur votre plateforme en exposant des ressources de données uniques.

Considérations

Ces considérations implémentent les piliers d’Azure Well-Architected Framework qui est un ensemble de principes directeurs qui permettent d’améliorer la qualité d’une charge de travail. Pour plus d'informations, consultez Microsoft Azure Well-Architected Framework.

Fiabilité

La fiabilité permet de s’assurer que votre application tient vos engagements auprès de vos clients. Pour plus d’informations, consultez la page Vue d’ensemble du pilier de fiabilité.

Disponibilité

Vous pouvez déployer le service Gestion des API Azure 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. Vous pouvez également 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.

Résilience

Même si cet exemple de scénario 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.

Sécurité

La sécurité fournit des garanties contre les attaques délibérées, et contre l’utilisation abusive de vos données et systèmes importants. Pour plus d’informations, consultez Vue d’ensemble du pilier 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). Vous pouvez intégrer Application Gateway à Microsoft Defender pour le cloud afin de 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.

Optimisation des coûts

L’optimisation des coûts consiste à examiner les moyens de réduire les dépenses inutiles et d’améliorer l’efficacité opérationnelle. Pour plus d’informations, consultez Vue d’ensemble du pilier d’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.

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, vous disposez de conseils pour la tarification des environnements ASE.

Vous pouvez configurer la tarification d’Application Gateway en fonction du niveau et des ressources requis.

Efficacité des performances

L’efficacité des performances est la capacité de votre charge de travail à s’adapter à la demande des utilisateurs de façon efficace. Pour plus d’informations, consultez Vue d’ensemble du pilier d’efficacité des performances.

Extensibilité

Vous pouvez effectuer un scale-out des instances Gestion des API 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 scale-out d’instance sont disponibles aux niveaux De base, Standard et Premium, mais sont contraintes par une limite d’échelle supérieure aux niveaux De base et Standard. 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. Vous pouvez configurer les applications hébergées dans les environnements App Service pour qu'elles bénéficient d’un scale-out (nombre d'instances) ou d’un scale-up (taille de l'instance) en fonction des besoins 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.

Déployer ce scénario

Conditions préalables requises et hypothèses

1. Vous devez acheter un nom de domaine personnalisé.
2. Vous avez besoin d’un certificat TLS (nous avons utilisé un certificat générique du service de certificats Azure) 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'adresses mentionnés dans la section Déploiement. Vous pouvez configurer les noms de ressources et les espaces d’adressage.

Déploiement et regroupement des éléments

Vous devez configurer davantage les composants déployés à l’aide du modèle Resource Manager précédent comme suit :

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.

   • Pour plus d’informations, reportez-vous aux instructions de déploiement.

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 les éléments suivants :

   • 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éez un 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 suivantes :

   • 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.
     • Utiliser 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 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 à 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 précédentes effectuées avec succès, configurez les entrées DNS dans les entrées CNAME du bureau d’enregistrement Web de api.contoso.org et de portal.contoso.org avec le nom DNS public de la passerelle applicative : ase-appgtwy.westus.cloudapp.azure.com. Vérifiez que vous pouvez accéder au portail de développement à partir d’une adresse publique et que vous pouvez tester les API des services APIM à l'aide du portail Azure.

Contributeurs

Cet article est géré par Microsoft. Il a été écrit à l’origine par les contributeurs suivants.

Auteur principal :

• Srikant Sarwa | Ingénieur client senior

Autres contributeurs :

• Shawn Kupfer | Rédacteur technique

Pour afficher les profils LinkedIn non publics, connectez-vous à LinkedIn.

Étapes suivantes

• Tutoriel : Importer et publier votre première API
• Tutoriel : Créer et publier un produit
• Tutoriel : Publier plusieurs versions de votre API

Ressources associées

Effectuer la migration d’une application web avec Gestion des API Azure