Veröffentlichen interner APIs für externe Benutzer

API Management
Application Gateway
Azure DevOps
Monitor
Virtual Network

In diesem Szenario verfügt ein Unternehmen über mehrere APIs mit App Service-Umgebungen (ILB ASE) und möchte diese APIs intern mit 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 eines Application Gateways an den internen API Management-Dienst erreicht werden, der wiederum die in der ASE bereitgestellten APIs in Anspruch nimmt.

Aufbau

Architekturdiagramm

Das obige Szenario umfasst einen kompletten Lebenszyklus von internen APIs, die von den externen Benutzern in Anspruch genommen werden.

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 einem virtuellen Azure-Computer installiert ist.
  2. Der Agent überträgt den Build per Push an die API-Anwendung, die in der ILB ASE gehostet wird.
  3. Das API Management nutzt die oben aufgeführten APIs über HOST-Header, die in der API Management-Richtlinie angegeben sind.
  4. Das API Management verwendet den DNS-Namen der ASE (App Service-Umgebung) für alle APIs.
  5. Application Gateway macht den API Management-Entwickler und das API-Portal verfügbar.
  6. Mithilfe des privaten 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 Webdatenverkehr, mit dem Sie eingehenden Datenverkehr für Ihre Webanwendungen verwalten können.
  • 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.

Überlegungen

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

Verfügbarkeit

Der Azure API Management-Dienst könnte als Bereitstellung in mehreren Regionen für eine höhere Verfügbarkeit und auch zur Reduzierung von Wartezeiten bereitgestellt werden. Dieses Feature ist nur im Premium-Modus verfügbar. Der API Management-Dienst in diesem speziellen Szenario nutzt APIs aus App Service-Umgebungen. Es besteht auch die Möglichkeit, APIM für APIs zu 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.

Skalierbarkeit

API Management-Instanzen können abhängig von einer Reihe von Faktoren erweitert sein, z.B. die Anzahl und Übertragungsrate von gleichzeitigen Verbindungen, Art und Anzahl von konfigurierten Richtlinien, Umfang von Anforderungen und Antworten sowie Back-End-Latenzzeiten für die APIs. Die Optionen für das horizontale Hochskalieren von Instanzen sind in den Tarifen „Basic“, „Standard“ und „Premium“ verfügbar, werden aber für Tarife unter „Premium“ 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 eine Skalierung mit Einschränkungen auf der Grundlage des Tarifs ausgelegt, und die unter den App Service-Umgebungen gehosteten Anwendungen können je nach Anforderungen der Anwendung aufskaliert (Anzahl der Instanzen) oder hochskaliert (Größe der Instanz) werden.

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.

Sicherheit

Da das obige Beispielszenario vollständig in einem internen Netzwerk gehostet wird, sind API Management und ASE bereits in einer gesicherten Infrastruktur (Azure VNet) bereitgestellt. Application Gateway-Instanzen können in das Azure Security Center integriert werden, 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.

Resilienz

In diesem Beispielszenario geht es zwar eher um die Konfiguration, aber die in den App Service-Umgebungen gehosteten APIs sollten 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.

Bereitstellen des Szenarios

Voraussetzungen und Annahmen

  1. Es muss ein benutzerdefinierter Domänenname erworben werden.
  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, die konfiguriert werden können.

Bereitstellung und Zusammenstellung der Komponenten

In Azure bereitstellen

Die mit der oben genannten Resource Manager-Vorlage bereitgestellten Komponenten müssen wie folgt weiter konfiguriert werden.

  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 ILB-Option (interner 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. Konfigurieren Sie nach der Bereitstellung

    • Die Web-App, die das TLS-Zertifikat verwenden soll
    • Application Insights für die obigen Apps: api-insights.
    • Erstellen Sie einen 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. Erstellt den API Management-Dienst: apim-intern.

  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 die oben erstellte Test-VM, um den API Management-Dienst intern im virtuellen Netzwerk zu testen.

    Hinweis

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

  8. Konfigurieren Sie Application Gateway (WAF V1) für den Zugriff auf den API-Dienst: „apim-gateway“ über Port 80. Fügen Sie TLS-Zertifikate zur App 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 obigen Schritte die DNS-Einträge in den GoDaddy-CNAME-Einträgen von „api.contoso.org“ und „portal.contoso.org“ mit dem öffentlichen DNS-Namen von App Gateway: „ase-appgtwy.westus.cloudapp.azure.com“. Überprüfen Sie anschließend, ob das Entwicklerportal öffentlich zugänglich ist und Sie in der Lage sind, die APIM-Dienst-APIs über das Azure-Portal zu testen.

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

Preise

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

Der Developer-Tarif kann zur Evaluierung der API Management-Funktionen verwendet werden. Der Developer-Tarif sollte nicht für die Produktion verwendet werden.

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 die Preisinformationen der App Service-Umgebungen hier

Die Application Gateway-Preise können hier konfiguriert werden, abhängig von dem erforderlichen Tarif und den Ressourcen.

Testen Sie das zugehörige Szenario unter Migrieren von älteren Web-APIs zu API Management