Bearbeiten

Veröffentlichen interner APIs für externe Benutzer

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

In diesem Szenario konsolidiert eine Organisation mehrere APIs intern mithilfe des Azure API Management-Diensts, der in einem virtuellen Netzwerk bereitgestellt wird.

Aufbau

Architekturdiagramm, das den gesamten Lebenszyklus der internen APIs zeigt, die von den externen Benutzern genutzt werden.

Laden Sie eine Visio-Datei dieser Architektur herunter.

Das vorangegangene Szenario umfasst einen kompletten Lebenszyklus interner APIs, die von den externen Benutzern genutzt werden.

Datenfluss

Die Daten fließen wie folgt:

  1. Entwickler checken Code in ein GitHub-Repository ein, das mit dem CI/CD-Pipeline-Agent verbunden ist, der auf einer Azure-VM installiert ist.
  2. Der Agent überträgt den Build per Push an die API-Anwendung, die in der ILB ASE gehostet wird.
  3. Azure API Management nutzt die vorangegangenen APIs über HOST-Header, die in der API Management-Richtlinie angegeben sind.
  4. API Management verwendet den DNS-Namen der App Service-Umgebung für alle APIs.
  5. Application Gateway macht den API Management-Entwickler und das API-Portal verfügbar.
  6. Mithilfe von privatem Azure-DNS wird der Datenverkehr intern zwischen ASE, API Management und Application Gateway weitergeleitet.
  7. Externe Benutzer verwenden das verfügbar gemachte Entwicklerportal, um die APIs über die öffentliche IP-Adresse von Application Gateway zu nutzen.

Komponenten

  • Mit Azure Virtual Network können Azure-Ressourcen sicher untereinander sowie mit dem Internet und mit lokalen Netzwerken kommunizieren.
  • Mit privatem Azure-DNS können Domänennamen in einem virtuellen Netzwerk aufgelöst werden, ohne dass eine benutzerdefinierte DNS-Lösung hinzugefügt werden muss.
  • Azure API Management unterstützt Organisationen beim Veröffentlichen von APIs für externe, Partner- und interne Entwickler, um ihre Daten und Dienste nutzen zu können.
  • Application Gateway ist ein Lastenausgleich für Web-Datenverkehr, das Ihnen dabei hilft, eingehenden Datenverkehr für Ihre Web-Anwendungen zu verwalten.
  • Die App Service-Umgebung für den internen Lastenausgleich ist ein Feature von Azure App Service, das eine vollständig isolierte und dedizierte Umgebung zur sicheren Ausführung von App Service-Apps mit umfangreicher Skalierung bereitstellt.
  • Azure DevOps ist ein Dienst für die Verwaltung Ihres Entwicklungslebenszyklus und umfasst Features für Planung und Projektmanagement, Codeverwaltung, Build und Release.
  • Application Insights ist ein erweiterbarer, für Webentwickler konzipierter Dienst zur Verwaltung der Anwendungsleistung (Application Performance Management, APM) auf mehreren Plattformen.
  • Azure Cosmos DB ist ein global verteilter Datenbankdienst von Microsoft mit mehreren Modellen.

Alternativen

  • In einem Azure-Lift & Shift-Szenario, das direkt in einem Azure Virtual Network bereitgestellt wird, könnten Back-End-Server direkt über private IP-Adressen adressiert werden.
  • Bei der Verwendung lokaler Ressourcen könnte die API Management-Instanz eine private Verbindung über ein Azure-VPN-Gateway und eine Site-to-Site-IPSec-VPN-Verbindung oder ExpressRoute mit dem internen Dienst herstellen, wodurch ein Hybridszenario mit Azure und einer lokalen Umgebung entstehen würde.
  • Vorhandene oder Open-Source-DNS-Anbieter können anstelle des Azure-basierten DNS-Diensts verwendet werden.
  • Interne APIs, die außerhalb von Azure bereitgestellt werden, können dennoch davon profitieren, wenn die APIs über den API Management-Dienst bereitgestellt werden.

Szenariodetails

In diesem Szenario hostet ein Unternehmen mehrere APIs mithilfe der Azure Application Service-Umgebung (ILB ASE) und möchte diese APIs intern mithilfe von Azure API Management (APIM) konsolidieren, das in einem virtuellen Netzwerk bereitgestellt wird. Die interne API Management-Instanz könnte auch externen Benutzern zur Verfügung gestellt werden, um das volle Potenzial der APIs nutzen zu können. Diese externe Offenlegung könnte über die Weiterleitungsanforderungen von Azure Application Gateway an den internen API Management-Dienst erreicht werden, der wiederum die in der Azure App Service-Umgebung bereitgestellten APIs in Anspruch nimmt.

  • Die Web-APIs werden über ein gesichertes HTTPS-Protokoll gehostet und verwenden ein TLS-Zertifikat.
  • Das Application Gateway ist auch über Port 443 für sichere und zuverlässige ausgehende Aufrufe konfiguriert.
  • Der API Management-Dienst ist so konfiguriert, dass er benutzerdefinierte Domänen mit TLS-Zertifikaten verwendet.
  • Überprüfen der vorgeschlagenen Netzwerkkonfiguration für App Service-Umgebungen
  • Es muss ausdrücklich erwähnt werden, dass Port 3443 es API Management ermöglicht, die Verwaltung über das Azure-Portal oder PowerShell durchzuführen.
  • Nutzen Sie die Richtlinien innerhalb von APIM, um einen HOST-Header für die in der ASE gehostete API hinzuzufügen. Dadurch wird sichergestellt, dass der Lastenausgleich der ASE die Anforderung ordnungsgemäß weiterleitet.
  • Das API Management akzeptiert den DNS-Eintrag der ASE für alle Apps, die unter App Service-Umgebungen gehostet werden. Fügen Sie eine APIM-Richtlinie hinzu, um den HOST-Header explizit so festzulegen, dass der ASE-Lastenausgleich zwischen Apps unter der App Service-Umgebung unterscheiden kann.
  • Erwägen Sie die Integration in Azure Application Insights. Dadurch stehen Ihnen über Azure Monitor auch Metriken für die Überwachung zur Verfügung.
  • Wenn Sie CI/CD-Pipelines für die Bereitstellung interner APIs verwenden, erwägen Sie die Erstellung eines eigenen gehosteten Agents auf einem virtuellen Computer innerhalb des virtuellen Netzwerks.

Mögliche Anwendungsfälle

  • Synchronisieren Sie Kundenadresseninformationen intern, nachdem der Kunde eine Änderung vorgenommen hat.
  • Gewinnen von Entwicklern für Ihre Plattform, indem eindeutige Datenressourcen verfügbar gemacht werden

Überlegungen

Diese Überlegungen setzen die Säulen des Azure Well-Architected Framework um, das eine Reihe von Leitprinzipien enthält, die zur Verbesserung der Qualität eines Workloads verwendet werden können. Weitere Informationen finden Sie unter Microsoft Azure Well-Architected Framework.

Zuverlässigkeit

Zuverlässigkeit stellt sicher, dass Ihre Anwendung Ihre Verpflichtungen gegenüber den Kunden erfüllen kann. Weitere Informationen finden Sie in der Übersicht über die Säule „Zuverlässigkeit“.

Verfügbarkeit

Sie können den Azure API Management-Dienst als Bereitstellung in mehreren Regionen für eine höhere Verfügbarkeit und auch zur Reduzierung von Wartezeiten bereitstellen. Diese Funktion ist nur im Premium-Modus verfügbar. Der API Management-Dienst in diesem speziellen Szenario nutzt APIs aus App Service-Umgebungen. Sie können auch APIM für APIs verwenden, die in der internen lokalen Infrastruktur gehostet werden.

App Service-Umgebungen könnten Traffic Manager-Profile verwenden, um den in App Service-Umgebungen gehosteten Datenverkehr für eine höhere Skalierung und Verfügbarkeit zu verteilen.

Resilienz

Auch wenn es in diesem Beispielszenario zwar eher um die Konfiguration geht, sollten die in den App Service-Umgebungen gehosteten APIs ausreichend resilient sein, um Fehler in den Anforderungen zu behandeln, die schließlich vom API Management-Dienst und Application Gateway verwaltet werden. Berücksichtigen Sie Muster für Wiederholungen und Trennschalter im API-Design. Allgemeine Informationen zur Entwicklung robuster Lösungen finden Sie unter Entwerfen robuster Anwendungen für Azure.

Sicherheit

Sicherheit bietet Schutz vor vorsätzlichen Angriffen und dem Missbrauch Ihrer wertvollen Daten und Systeme. Weitere Informationen finden Sie unter Übersicht über die Säule „Sicherheit“.

Da das vorangegangene Beispielszenario vollständig in einem internen Netzwerk gehostet wird, sind API Management und ASE bereits in einer gesicherten Infrastruktur (Azure VNet) bereitgestellt. Sie können Application Gateway-Instanzen in Microsoft Defender for Cloud integrieren, um eine reibungslose Möglichkeit zur Vermeidung, Erkennung und Reaktion auf Bedrohungen für die Umgebung bereitzustellen. Allgemeine Informationen zum Entwerfen sicherer Lösungen finden Sie in der Dokumentation zur Azure-Sicherheit.

Kostenoptimierung

Bei der Kostenoptimierung geht es um die Suche nach Möglichkeiten, unnötige Ausgaben zu reduzieren und die Betriebseffizienz zu verbessern. Weitere Informationen finden Sie unter Übersicht über die Säule „Kostenoptimierung“.

API Management ist in vier Tarifen erhältlich: Developer, Basic, Standard und Premium. Ausführliche Informationen zu den Unterschieden zwischen den einzelnen Tarifen finden Sie in der API Management-Preisübersicht.

Kunden können API Management skalieren, indem sie Einheiten hinzufügen und entfernen. Die Kapazität jeder Einheit ist vom Tarif abhängig.

Hinweis

Sie können den Developer-Tarif zur Evaluierung der API Management-Features verwenden. Sie sollten den „Developer“-Tarif nicht für die Produktion verwenden.

Im Azure-Preisrechner können Sie die voraussichtlichen Kosten für Ihre speziellen Bereitstellungsanforderungen ermitteln, indem Sie die Anzahl von Skalierungseinheiten und App Service-Instanzen ändern.

Ebenso finden Sie hier die Preisübersicht der App Service-Umgebungen.

Sie können die Application Gateway-Preise in Abhängigkeit von dem erforderlichen Tarif und den Ressourcen konfigurieren.

Effiziente Leistung

Leistungseffizienz ist die Fähigkeit Ihrer Workload, auf effiziente Weise eine den Anforderungen der Benutzer entsprechende Skalierung auszuführen. Weitere Informationen finden Sie unter Übersicht über die Säule „Leistungseffizienz“.

Skalierbarkeit

Sie können API Management-Instanzen in Abhängigkeit von einer Reihe von Faktoren aufskalieren, z. B. die Anzahl und Übertragungsrate von gleichzeitigen Verbindungen, Art und Anzahl von konfigurierten Richtlinien, Umfang von Anforderungen und Antworten sowie Backend-Latenzzeiten für die APIs. Die Optionen für das Aufskalieren von Instanzen sind in den Tarifen „Basic“, „Standard“ und „Premium“ verfügbar, werden aber in den Tarifen „Basic“ und „Standard“ durch einen oberen Grenzwert für die Skalierung begrenzt. Die Instanzen werden als Einheiten bezeichnet und können auf bis zu maximal zwei Einheiten im Tarif „Basic“, vier Einheiten im Tarif „Standard“ und eine beliebige Anzahl von Einheiten im Tarif „Premium“ skaliert werden. Die Optionen für die automatische Skalierung sind ebenfalls verfügbar, um das Aufskalieren auf Basis von Regeln zu aktivieren.

App Service-Umgebungen sind für die Skalierung mit Grenzwerten basierend auf dem Tarif konzipiert. Sie können die unter den App Service-Umgebungen gehosteten Anwendungen in Abhängigkeit von den Anforderungen der Anwendung konfigurieren, um aufzuskalieren (Anzahl der Instanzen) oder hochzuskalieren (Größe der Instanz).

Die automatische Skalierung von Azure Application Gateway ist im Rahmen der zonenredundanten SKU in allen globalen Azure-Regionen verfügbar. Informationen zur automatischen Skalierung des App-Gateways finden Sie in der öffentlichen Previewfunktion.

Bereitstellen dieses Szenarios

Voraussetzungen und Annahmen

  1. Sie müssen einen benutzerdefinierten Domänennamen erwerben.
  2. Sie benötigen ein TLS-Zertifikat für alle benutzerdefinierten Domänen (im Beispiel wird ein Platzhalterzertifikat des Azure-Zertifikatdiensts verwendet). Sie können auch ein selbstsigniertes Zertifikat für Testszenarien der Entwickler erwerben.
  3. Für diese spezifische Bereitstellung werden der Domänenname „contoso.org“ und ein TLS-Platzhalterzertifikat für die Domäne verwendet.
  4. Die Bereitstellung verwendet die im Bereitstellungsabschnitt genannten Ressourcennamen und Adressräume. Sie können die Ressourcennamen und Adressräume konfigurieren.

Bereitstellung und Zusammenstellung der Komponenten

In Azure bereitstellen

Sie müssen die mithilfe der vorherigen Resource Manager-Vorlage bereitgestellten Komponenten wie folgt konfigurieren:

  1. VNet mit den folgenden Konfigurationen:

    • Name: ase-internal-vnet
    • Adressraum für VNet: 10.0.0.0/16
    • Vier Subnetze
      • backendSubnet für DNS-Dienst: 10.0.0.0/24
      • apimsubnet für internen API Management-Dienst: 10.0.1.0/28
      • asesubnet für ILB ASE: 10.0.2.0/24
      • VMSubnet für virtuelle Testcomputer und intern gehostete DevOps-Agent-VM: 10.0.3.0/24
  2. Dienst für privates DNS (Public Preview), da das Hinzufügen eines DNS-Diensts ein leeres VNet erfordert.

  3. App Service-Umgebung mit Option für internen Lastenausgleich: aseinternal (DNS: aseinternal.contoso.org). Nachdem die Bereitstellung abgeschlossen ist, laden Sie das Platzhalterzertifikat für den ILB hoch.

  4. App Service-Plan mit ASE als Speicherort

  5. Eine API-App (App Services zur Vereinfachung) – srasprest (URL: https://srasprest.contoso.org) – ASP.NET MVC-basierte Web-API. Nach der Bereitstellung konfigurieren Sie Folgendes:

    • Web-App, die das TLS-Zertifikat verwenden soll
    • Application Insights für die vorangegangenen Apps: api-insights
    • Erstellen Sie einen Azure Cosmos DB-Dienst für Web-APIs, die intern im VNet gehostet werden: noderestapidb
    • Erstellen Sie DNS-Einträge in der erstellten privaten DNS-Zone.
    • Sie können Azure Pipelines verwenden, um die Agents auf virtuellen Computern zu konfigurieren, sodass der Code für die Web-App im internen Netzwerk bereitgestellt wird
    • Erstellen Sie zum internen Testen der API-App eine Test-VM innerhalb des VNet-Subnetzes.
  6. Erstellen des API Management-Diensts: apim-internal

  7. Konfigurieren Sie den Dienst so, dass eine Verbindung mit dem internen VNet im Subnetz hergestellt wird: apimsubnet. Nachdem die Bereitstellung abgeschlossen ist, führen Sie die folgenden zusätzlichen Schritte aus:

    • Konfigurieren Sie benutzerdefinierte Domänen für APIM-Dienste mit TLS:
      • API-Portal (api.contoso.org)
      • Entwicklerportal (portal.contoso.org)
      • Konfigurieren Sie die ASE-Apps im API-Abschnitt mit der vom DNS-Namen der ASE hinzugefügten Richtlinie für den HOST-Header der Web-App.
      • Verwenden Sie den vorhergehenden virtuellen Test-Computer, um den API Management-Dienst intern im virtuellen Netzwerk zu testen

    Hinweis

    Das Testen der APIM-APIs über das Azure-Portal funktioniert nicht, da „api.contoso.org“ nicht öffentlich aufgelöst werden kann.*

  8. Konfigurieren Sie die Application Gateway-Instanz (WAF V1) für den Zugriff auf den API-Dienst: „apim-gateway“ über Port 80. Fügen Sie TLS-Zertifikate zur Application Gateway-Instanz und den entsprechenden Integritätstests und HTTP-Einstellungen hinzu. Konfigurieren Sie außerdem die Regeln und Listener für die Verwendung des TLS-Zertifikats.

Konfigurieren Sie nach erfolgreichem Abschluss der vorangegangenen Schritte die DNS-Einträge in den CNAME-Einträgen der Web-Registrierungsstelle von „api.contoso.org“ und „portal.contoso.org“ mit dem öffentlichen DNS-Namen des App Gateways: ase-appgtwy.westus.cloudapp.azure.com. Überprüfen Sie, ob das Entwicklerportal öffentlich zugänglich ist und Sie in der Lage sind, die APIM-Dienst-APIs über das Azure-Portal zu testen.

Hinweis

Es ist keine bewährte Methode, dieselbe URL für interne und externe Endpunkte für die APIM-Dienste zu verwenden (auch wenn beide URLs in dieser Demo identisch sind). Wenn Sie unterschiedliche URLs für interne und externe Endpunkte verwenden möchten, können Sie Application Gateway WAF v2 verwenden, das die HTTP-Umleitung und viele weitere Optionen unterstützt.

Beitragende

Dieser Artikel wird von Microsoft gepflegt. Er wurde ursprünglich von folgenden Mitwirkenden geschrieben.

Hauptautor:

Andere Mitwirkende:

Melden Sie sich bei LinkedIn an, um nicht öffentliche LinkedIn-Profile anzuzeigen.

Nächste Schritte

Migrieren einer Web-App per Azure API Management