Publier des API internes pour des utilisateurs externes

Dans ce scénario, une organisation consolide plusieurs API en interne à l’aide d’Azure Gestion des API déployées à l’intérieur d’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 (push) la build à l’application API hébergée sur l’environnement App Service 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. Gestion des API utilise le nom DNS de l’environnement App Service pour toutes les API.
5. Application Gateway expose le portail Gestion des API développeur et API.
6. Azure DNS privé est utilisé pour router le trafic en interne entre App Service Environment, Gestion des API et Application Gateway.
7. Les utilisateurs externes utilisent le portail des développeurs exposés pour consommer les API via l’adresse IP publique 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 App Service d’équilibreur de charge interne est une fonctionnalité Azure App Service qui fournit un environnement entièrement isolé et dédié pour exécuter en toute sécurité des 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 lift-and-shift Azure déployé dans un réseau virtuel Azure, les serveurs principaux peuvent être directement traités par le biais d’adresses IP privées.
• Si vous utilisez des ressources locales, l’instance de Gestion des API peut revenir au service interne en privé via une connexion VPN Azure passerelle VPN et de site à site (IPSec) VPN ou ExpressRoute pour créer un scénario Azure hybride et local.
• 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 Application Service Environment (ILB App Service Environment) et souhaite consolider ces API en interne à l’aide d’Azure Gestion des API (APIM) déployées à l’intérieur d’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 à l’aide des demandes de transfert Azure Application Gateway vers le service de Gestion des API interne, qui consomme à son tour les API déployées dans l’environnement App Service.

• Les API web sont hébergées sur un protocole HTTPs sécurisé, et utilisent un Certificat TLS.
• La passerelle d’application est également configurée sur le port 443 pour les 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.
• Utilisez des stratégies dans APIM pour ajouter un en-tête HOST pour l’API hébergée sur App Service Environment. Cela garantit que l’équilibreur de charge App Service Environment transfère correctement la requête.
• Le Gestion des API accepte l’entrée DNS De l’environnement App Service pour toutes les applications hébergées dans les environnements App Service. Ajoutez une stratégie APIM pour définir explicitement l’en-tête HOST pour permettre à l’équilibreur de charge App Service Environment de différencier les applications sous l’environnement App Service.
• 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 à l’intérieur 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 précédent est hébergé complètement sur un réseau interne, Gestion des API et App Service Environment sont déjà déployés sur une infrastructure sécurisée (Azure Réseau virtuel). 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 le 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 App Service Environment : 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. DNS privé service (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 d’équilibreur de charge interne (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 App Service Environment en tant qu’emplacement

5. Application API (App Service pour plus de simplicité) - srasprest (URL : https://srasprest.contoso.org) – ASP.NET API web basée sur modèle-view-controller (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 un réseau virtuel : noderestapidb
   • Créer des entrées DNS sur la zone Azure 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 vous connecter à un 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 API (api.contoso.org)
     • Portail des développeurs (portal.contoso.org)
     • Dans la section API, configurez les applications App Service Environment à l’aide du nom DNS App Service Environment ajouté pour l’en-tête HOST 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

   Remarque

   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 la passerelle d’application pour accéder au service d’API : apim-gateway sur le port 80. Ajoutez des certificats TLS à la passerelle d’application et aux sondes d’intégrité correspondantes et aux paramètres HTTP. Configurez également les règles et les écouteurs pour utiliser le certificat TLS.

Une fois les étapes précédentes terminées, configurez les entrées DNS dans les entrées CNAME du bureau d’enregistrement web et api.contoso.org portal.contoso.org avec le nom DNS public d’Application Gateway : 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