Verwenden von Azure Front Door in einer mehrinstanzenfähigen Lösung

  • Artikel

Azure Front Door ist das moderne Cloud-CDN (Content Delivery Network), das schnellen und zuverlässigen Zugriff zwischen Benutzer*innen sowie den statischen und dynamischen Webinhalten von Anwendungen auf der ganzen Welt ermöglicht. In diesem Artikel werden einige der Features von Azure Front Door beschrieben, die nützlich sind, wenn Sie in mehrinstanzenfähigen Systemen arbeiten. Außerdem werden Links zu zusätzlichen Anleitungen und Beispielen bereitgestellt.

Wenn Sie Azure Front Door als Teil einer mehrinstanzenfähigen Lösung verwenden, müssen Sie einige Entscheidungen basierend auf dem Entwurf und den Anforderungen Ihrer Lösung treffen. Sie müssen die folgenden Faktoren berücksichtigen:

  • Wie viele Mandanten haben Sie und wie viele erwarten Sie in Zukunft?
  • Teilen Sie Ihre Anwendungsebene zwischen mehreren Mandanten, stellen Sie viele Anwendungsinstanzen für Einzelmandanten bereit, oder stellen Sie separate Bereitstellungsstempel bereit, die von mehreren Mandanten gemeinsam genutzt werden?
  • Möchten Ihre Mandanten ihre eigenen Domänennamen verwenden?
  • Werden Sie Platzhalterdomänen verwenden?
  • Müssen Sie Ihre eigenen TLS-Zertifikate verwenden, oder verwaltet Microsoft Ihre TLS-Zertifikate?
  • Haben Sie die Kontingente und Grenzwerte für Azure Front Door berücksichtigt? Wissen Sie, welche Grenzwerte Sie bei Wachstum erreichen werden? Wenn Sie vermuten, dass Sie sich diesen Grenzwerten nähern, sollten Sie mehrere Azure Front Door-Profile verwenden. Überlegen Sie alternativ, ob Sie Ihre Verwendungsweise von Azure Front Door ändern möchten, um die Grenzwerte zu vermeiden. Beachten Sie, dass die Premium-SKU höhere Grenzwerte als die Standard-SKU aufweist.
  • Haben Sie oder Ihre Mandanten Anforderungen für die IP-Adressfilterung, das Geoblocking oder das Anpassen von WAF-Regeln?
  • Haben alle Anwendungsserver Ihrer Mandanten Internetzugriff?

Features von Azure Front Door, die die Mehrinstanzenfähigkeit unterstützen

In diesem Abschnitt werden mehrere wichtige Features von Azure Front Door beschrieben, die für mehrinstanzenfähige Lösungen nützlich sind. Es wird beschrieben, wie Azure Front Door Ihnen beim Konfigurieren benutzerdefinierter Domänen helfen kann, einschließlich Informationen zu Platzhalterdomänen und TLS-Zertifikaten. Außerdem wird zusammengefasst, wie Sie Azure Front Door-Routingfunktionen verwenden können, um die Mehrinstanzenfähigkeit zu unterstützen.

Benutzerdefinierte Domänen

Azure Front Door stellt einen Standardhostnamen für jeden von Ihnen erstellten Endpunkt bereit, z. B. contoso.z01.azurefd.net. Bei den meisten Lösungen ordnen Sie stattdessen Ihren eigenen Domänennamen dem Azure Front Door-Endpunkt zu. Benutzerdefinierte Domänennamen ermöglichen es Ihnen, Ihr eigenes Branding zu verwenden und das Routing basierend auf dem Hostnamen zu konfigurieren, der in der Anforderung eines Clients angegeben wird.

In einer mehrinstanzenfähigen Lösung können Sie mandantenspezifische Domänennamen oder Unterdomänen verwenden und Azure Front Door so konfigurieren, dass der Datenverkehr des Mandanten an die richtige Ursprungsgruppe für die Workload dieses Mandanten weitergeleitet wird. Sie können beispielsweise einen benutzerdefinierten Domänennamen wie tenant1.app.contoso.com konfigurieren. Mit Azure Front Door können Sie mehrere benutzerdefinierte Domänen in einem einzelnen Azure Front Door-Profil konfigurieren.

Weitere Informationen finden Sie unter Hinzufügen einer benutzerdefinierten Domäne zu Front Door.

Platzhalterdomänen

Platzhalterdomänen vereinfachen die Konfiguration von DNS-Einträgen und der Konfiguration für das Azure Front Door-Datenverkehrsrouting, wenn Sie eine freigegebene Stammdomäne und mandantenspezifische Unterdomänen verwenden. Angenommen, Ihre Mandanten greifen mithilfe von Unterdomänen wie tenant1.app.contoso.com und tenant2.app.contoso.com auf ihre Anwendungen zu. Sie können eine Platzhalterdomäne (*.app.contoso.com) konfigurieren, anstatt jede mandantenspezifische Domäne einzeln zu konfigurieren.

Azure Front Door unterstützt das Erstellen benutzerdefinierter Domänen, die Platzhalter verwenden. Anschließend können Sie eine Route für Anforderungen konfigurieren, die in der Platzhalterdomäne eingehen. Beim Onboarding eines neuen Mandanten müssen Sie Ihre DNS-Server nicht neu konfigurieren, keine neuen TLS-Zertifikate ausstellen oder die Konfiguration Ihres Azure Front Door-Profils aktualisieren.

Platzhalterdomänen funktionieren gut, wenn Sie Ihren gesamten Datenverkehr an eine einzelne Ursprungsgruppe senden. Wenn Sie jedoch über separate Stempel Ihrer Lösung verfügen, ist eine Platzhalterdomäne auf einer Ebene nicht ausreichend. Sie müssen entweder Stammdomänen mit mehreren Ebenen verwenden oder eine zusätzliche Konfiguration bereitstellen, indem Sie z. B. die Routen überschreiben, die für die Unterdomäne jedes Mandanten verwendet werden sollen. Weitere Informationen finden Sie unter Überlegungen zur Verwendung von Domänennamen in einer mehrinstanzenfähigen Lösung.

Azure Front Door stellt keine verwalteten TLS-Zertifikate für Platzhalterdomänen aus. Daher müssen Sie Ihr eigenes Zertifikat erwerben und bereitstellen.

Weitere Informationen finden Sie unter Platzhalterdomänen.

Verwaltete TLS-Zertifikate

Das Abrufen und Installieren von TLS-Zertifikaten kann komplex und fehleranfällig sein. TLS-Zertifikate laufen zudem nach einem bestimmten Zeitraum ab, in der Regel nach einem Jahr, und müssen erneut ausgestellt und neu installiert werden, um Unterbrechungen des Anwendungsdatenverkehrs zu vermeiden. Wenn Sie verwaltete TLS-Zertifikate von Azure Front Door verwenden, ist Microsoft für das Ausstellen, Installieren und Erneuern von Zertifikaten für Ihre benutzerdefinierte Domäne verantwortlich.

Ihre Ursprungsanwendung wird möglicherweise in einem anderen Azure-Dienst gehostet, der auch verwaltete TLS-Zertifikate bereitstellt, z. B. Azure App Service. Azure Front Door arbeitet transparent mit dem anderen Dienst zusammen, um Ihre TLS-Zertifikate zu synchronisieren.

Wenn Sie Ihren Mandanten erlauben, ihre eigenen benutzerdefinierten Domänen bereitzustellen, und Sie möchten, dass Azure Front Door Zertifikate für diese Domänennamen ausstellen soll, sollten Ihre Mandanten keine CAA-Einträge auf ihren DNS-Servern konfigurieren, sodass Azure Front Door möglicherweise keine Zertifikate in ihrem Namen ausstellen kann. Weitere Informationen finden Sie unter TLS/SSL-Zertifikate.

Weitere Informationen zu TLS-Zertifikaten finden Sie unter End-to-End-TLS mit Azure Front Door.

Routing

Eine mehrinstanzenfähige Anwendung kann einen oder mehrere Anwendungsstempel aufweisen, die den Mandanten bedienen. Stempel werden häufig verwendet, um Bereitstellungen in mehreren Regionen zu ermöglichen und die Skalierung einer Lösung auf eine große Anzahl von Mandanten zu unterstützen.

Azure Front Door verfügt mehre leistungsstarke Routingfunktionen, die eine Reihe von mehrinstanzenfähigen Architekturen unterstützen können. Sie können das Routing verwenden, um Datenverkehr auf die Ursprünge innerhalb eines Stempels zu verteilen oder an den richtigen Stempel für einen bestimmten Mandanten zu senden. Sie können das Routing basierend auf einzelnen Domänennamen, Platzhalterdomänennamen und URL-Pfaden konfigurieren. Außerdem können Sie die Regel-Engine verwenden, um das Routingverhalten weiter anzupassen.

Weitere Informationen finden Sie unter Übersicht über die Routingarchitektur.

Regelmodul

Sie können die Azure Front Door-Regel-Engine verwenden, um die Verarbeitung von Anforderungen von Azure Front Door am Netzwerkedge anzupassen. Mit der Regel-Engine können Sie kleine Logikblöcke innerhalb der Anforderungsverarbeitungspipeline von Azure Front Door ausführen. Sie können das Regelmodul für eine Vielzahl von Aufgaben verwenden, einschließlich der folgenden:

  • Rufen Sie Informationen zur HTTP-Anforderung ab, einschließlich Segmenten der URL und des Pfads, und verteilen Sie die Informationen an einen anderen Teil der Anforderung.
  • Ändern Sie Elemente der HTTP-Anforderung, bevor sie an den Ursprung gesendet wird.
  • Ändern Sie einige Teile der HTTP-Antwort, bevor sie an den Client zurückgegeben wird.
  • Überschreiben Sie die Routingkonfiguration für eine Anforderung, z. B. durch Ändern der Ursprungsgruppe, an die eine Anforderung gesendet werden soll.

Im Folgenden finden Sie einige Beispielansätze für die Verwendung des Azure Front Door-Regelmoduls in einer multiinstanzenübergreifenden Lösung:

  • Angenommen, Sie stellen eine mehrinstanzenfähige Anwendungsebene bereit, in der Sie auch wie in den folgenden Beispielszenarios beschrieben mandantenspezifische Platzhalterunterdomänen verwenden. Sie können die Regel-Engine verwenden, um den Mandantenbezeichner aus der Anforderungsunterdomäne zu extrahieren und einem Anforderungsheader hinzuzufügen. Diese Regel könnte der Anwendungsebene dabei helfen, zu bestimmen, von welchem Mandanten die Anforderung stammt.
  • Angenommen, Sie stellen eine mehrinstanzenfähige Anwendungsebene bereit und verwenden pfadbasiertes Routing (z . B. https://application.contoso.com/tenant1/welcome und https://application.contoso.com/tenant2/welcome für Mandanten 1 bzw. 2). Sie können das Regelmodul verwenden, um das Mandantenbezeichnersegment aus dem URL-Pfadsegment zu extrahieren und die URL neu zu schreiben, um den Mandantenbezeichner in einen Abfragezeichenfolgenparameter oder Anforderungsheader einzuschließen, damit die Anwendung verwendet werden kann.

Weitere Informationen finden Sie unter Was ist die Azure Front Door-Regel-Engine?.

Beispielszenarien

Die folgenden Beispielszenarios veranschaulichen, wie Sie verschiedene mehrinstanzenfähige Architekturen in Azure Front Door konfigurieren können und wie sich die von Ihnen getroffenen Entscheidungen auf Ihre DNS- und TLS-Konfiguration auswirken können.

Viele mehrinstanzenfähige Lösungen implementieren das Bereitstellungsstempelmuster. Wenn Sie diesen Bereitstellungsansatz verwenden, stellen Sie in der Regel ein einzelnes freigegebenes Azure Front Door-Profil bereit und verwenden Azure Front Door, um eingehenden Datenverkehr an den entsprechenden Stempel weiterzuleiten. Dieses Bereitstellungsmodell ist das am häufigsten verwendete, und die Szenarios 1 bis 4 in diesem Artikel zeigen, wie Sie es verwenden können, um eine Reihe von Anforderungen zu erfüllen.

In einigen Situationen können Sie jedoch möglicherweise in jedem Stempel Ihrer Lösung ein Azure Front Door-Profil bereitstellen. Szenario 5 beschreibt dieses Bereitstellungsmodell.

Szenario 1: Vom Anbieter verwaltete Platzhalterdomäne, einzelner Stempel

Contoso erstellt eine kleine mehrinstanzenfähige Lösung. Das Unternehmen stellt einen einzelnen Stempel in einer einzelnen Region bereit, und dieser Stempel bedient alle Mandanten. Alle Anforderungen werden an denselben Anwendungsserver weitergeleitet. Contoso hat sich für die Verwendung von Platzhalterdomänen für alle Mandanten entschieden, zum Beispiel tenant1.contoso.com und tenant2.contoso.com.

Contoso stellt Azure Front Door mithilfe der folgenden Konfiguration bereit:

Diagramm: Azure Front Door-Konfiguration mit einer einzelnen benutzerdefinierten Domäne, Route und Ursprungsgruppe sowie einem TLS-Platzhalterzertifikat in Azure Key Vault

DNS-Konfiguration

Einmalige Konfiguration: Contoso konfiguriert zwei DNS-Einträge:

  • Einen TXT-Platzhaltereintrag für *.contoso.com. Dieser ist auf den Wert festgelegt, der von Azure Front Door während des Onboardingprozesses der benutzerdefinierten Domäne angegeben wurde.
  • Ein CNAME-Platzhaltereintrag, *.contoso.com, der ein Alias für den Azure Front Door-Endpunkt von Contoso ist: contoso.z01.azurefd.net.

Wenn ein neuer Mandant integriert wird: Es ist keine zusätzliche Konfiguration erforderlich.

TLS-Konfiguration

Einmalige Konfiguration: Contoso kauft ein TLS-Platzhalterzertifikat, fügt es einem Schlüsseltresor hinzu und gewährt Azure Front Door Zugriff auf den Tresor.

Wenn ein neuer Mandant integriert wird: Es ist keine zusätzliche Konfiguration erforderlich.

Azure Front Door-Konfiguration

Einmalige Konfiguration: Contoso erstellt ein Azure Front Door-Profil und einen einzelnen Endpunkt. Sie fügen eine benutzerdefinierte Domäne mit dem Namen *.contoso.com hinzu und ordnen der benutzerdefinierten Domänenressource ihr TLS-Platzhalterzertifikat zu. Anschließend konfigurieren sie eine einzelne Ursprungsgruppe, die einen einzelnen Ursprung für ihren Anwendungsserver enthält. Schließlich konfigurieren sie eine Route, um die benutzerdefinierte Domäne mit der Ursprungsgruppe zu verknüpfen.

Wenn ein neuer Mandant integriert wird: Es ist keine zusätzliche Konfiguration erforderlich.

Vorteile

  • Diese Konfiguration ist relativ einfach zu konfigurieren und bietet Kunden Marken-URLs von Contoso.
  • Der Ansatz unterstützt eine große Anzahl von Mandanten.
  • Wenn ein neuer Mandant integriert wird, muss Contoso keine Änderungen an Azure Front Door-, DNS- oder TLS-Zertifikaten vornehmen.

Nachteile

  • Dieser Ansatz lässt sich nicht einfach über einen einzelnen Anwendungsstempel oder eine einzelne Region hinaus skalieren.
  • Contoso muss ein TLS-Platzhalterzertifikat kaufen und es verlängern und installieren, wenn es abläuft.

Szenario 2: Vom Anbieter verwaltete Platzhalterdomäne, mehrere Stempel

Proseware erstellt eine mehrinstanzenfähige Lösung für mehrere Stempel, die sowohl in Australien als auch in Europa bereitgestellt werden. Alle Anforderungen innerhalb einer einzelnen Region werden vom Stempel in dieser Region bedient. So wie Contoso hat sich auch Proseware für die Verwendung von Platzhalterdomänen für alle Mandanten entschieden, zum Beispiel tenant1.proseware.com und tenant2.proseware.com.

Proseware stellt Azure Front Door mithilfe der folgenden Konfiguration bereit:

Diagramm: Azure Front Door-Konfiguration mit mehreren benutzerdefinierten Domänen, Routen und Ursprungsgruppen sowie einem TLS-Platzhalterzertifikat in Key Vault

DNS-Konfiguration

Einmalige Konfiguration: Proseware konfiguriert zwei DNS-Einträge:

  • Einen TXT-Platzhaltereintrag für *.proseware.com. Dieser ist auf den Wert festgelegt, der von Azure Front Door während des Onboardingprozesses der benutzerdefinierten Domäne angegeben wurde.
  • Ein CNAME-Platzhaltereintrag, *.proseware.com, der ein Alias für den Azure Front Door-Endpunkt von Proseware ist: proseware.z01.azurefd.net.

Wenn ein neuer Mandant integriert wird: Es ist keine zusätzliche Konfiguration erforderlich.

TLS-Konfiguration

Einmalige Konfiguration: Proseware kauft ein TLS-Platzhalterzertifikat, fügt es einem Schlüsseltresor hinzu und gewährt Azure Front Door Zugriff auf den Tresor.

Wenn ein neuer Mandant integriert wird: Es ist keine zusätzliche Konfiguration erforderlich.

Azure Front Door-Konfiguration

Einmalige Konfiguration: Proseware erstellt ein Azure Front Door-Profil und einen einzelnen Endpunkt. Das Unternehmen konfiguriert mehrere Ursprungsgruppen, eine pro Anwendungsstempel/Server in jeder Region.

Wenn ein neuer Mandant integriert wird: Proseware fügt Azure Front Door eine benutzerdefinierte Domänenressource hinzu. Sie verwenden den Namen *.proseware.com und ordnen ihr TLS-Platzhalterzertifikat ihrer benutzerdefinierten Domänenressource zu. Anschließend erstellen sie eine Route, um anzugeben, an welche Ursprungsgruppe (Stempel) die Anforderungen des Mandanten weitergeleitet werden sollen. Im vorherigen Diagramm wird tenant1.proseware.com an die Ursprungsgruppe in der Region Australien weitergeleitet und tenant2.proseware.com an die Ursprungsgruppe in der Region Europa.

Vorteile

  • Wenn neue Mandanten integriert werden, sind keine DNS- oder TLS-Konfigurationsänderungen erforderlich.
  • Proseware verwaltet eine einzelne Instanz von Azure Front Door, um Datenverkehr an mehrere Stempel in mehreren Regionen weiterzuleiten.

Nachteile

  • Proseware muss Azure Front Door jedes Mal neu konfigurieren, wenn ein neuer Mandant integriert wird.
  • Proseware muss auf Azure Front Door-Kontingente und -Grenzwerte achten, insbesondere auf die Anzahl von Routen und benutzerdefinierten Domänen sowie auf den Grenzwert für zusammengesetztes Routing.
  • Proseware muss ein TLS-Platzhalterzertifikat kaufen.
  • Proseware ist für die Verlängerung und Installation des Zertifikats verantwortlich, wenn es abläuft.

Szenario 3: Vom Anbieter verwaltete, stempelbasierte Platzhalterunterdomänen

Fabrikam erstellt eine mehrinstanzenfähige Lösung. Das Unternehmen stellt Stempel in Australien und im den USA bereit. Alle Anforderungen innerhalb einer einzelnen Region werden vom Stempel in dieser Region bedient. Fabrikam verwendet stempelbasierte Stammdomänen wie tenant1.australia.fabrikam.com, tenant2.australia.fabrikam.com und tenant3.us.fabrikam.com.

Das Unternehmen stellt Azure Front Door mithilfe der folgenden Konfiguration bereit:

Diagramm: Azure Front Door-Konfiguration mit mehreren benutzerdefinierten stempelbasierten Stammdomänen, Routen, Ursprungsgruppen sowie einem TLS-Platzhalterzertifikat in Key Vault

DNS-Konfiguration

Einmalige Konfiguration: Fabrikam konfiguriert die folgenden beiden DNS-Platzhaltereinträge für jeden Stempel.

  • Ein TXT-Platzhaltereintrag für jeden Stempel: *.australia.fabrikam.com und *.us.fabrikam.com. Sie werden auf die Werte festgelegt, die von Azure Front Door während des Onboardingprozesses für benutzerdefinierte Domänen angegeben wurden.
  • Ein CNAME-Platzhaltereintrag für die einzelnen Stempel *.australia.fabrikam.com und *.us.fabrikam.com, die beide Aliase für den Azure Front Door-Endpunkt sind: fabrikam.z01.azurefd.net.

Wenn ein neuer Mandant integriert wird: Es ist keine zusätzliche Konfiguration erforderlich.

TLS-Konfiguration

Einmalige Konfiguration: Fabrikam kauft ein TLS-Platzhalterzertifikat für jeden Stempel, fügt sie einem Schlüsseltresor hinzu und gewährt Azure Front Door Zugriff auf den Tresor.

Wenn ein neuer Mandant integriert wird: Es ist keine zusätzliche Konfiguration erforderlich.

Azure Front Door-Konfiguration

Einmalige Konfiguration: Fabrikam erstellt ein Azure Front Door-Profil und einen einzelnen Endpunkt. Sie konfigurieren eine Ursprungsgruppe für jeden Stempel. Sie erstellen benutzerdefinierte Domänen mithilfe eines Platzhalters für jede stempelbasierte Unterdomäne: *.australia.fabrikam.com und *.us.fabrikam.com. Sie erstellen eine Route für die benutzerdefinierte Domäne jedes Stempels, um Datenverkehr an die entsprechende Ursprungsgruppe zu senden.

Wenn ein neuer Mandant integriert wird: Es ist keine zusätzliche Konfiguration erforderlich.

Vorteile

  • Dieser Ansatz ermöglicht Fabrikam die stempelübergreifende Skalierung auf eine große Anzahl von Mandanten.
  • Wenn neue Mandanten integriert werden, sind keine DNS- oder TLS-Konfigurationsänderungen erforderlich.
  • Fabrikam verwaltet eine einzelne Instanz von Azure Front Door, um Datenverkehr an mehrere Stempel in mehreren Regionen weiterzuleiten.

Nachteile

  • Da URLs eine mehrteilige Stammdomänenstruktur verwenden, können URLs für Benutzer*innen in der Anwendung komplexer sein.
  • Fabrikam muss mehrere TLS-Platzhalterzertifikate kaufen.
  • Fabrikam ist für die Verlängerung und Installation der TLS-Zertifikate verantwortlich, wenn sie ablaufen.

Szenario 4: Vanity-Domänen

Adventure Works Cycles erstellt eine mehrinstanzenfähige Lösung. Das Unternehmen stellt Stempel in mehreren Regionen bereit, z. B. in Australien und in den USA. Alle Anforderungen innerhalb einer einzelnen Region werden vom Stempel in dieser Region bedient. Adventure Works ermöglicht es seinen Mandanten, ihre eigenen Domänennamen mitzubringen. Beispielsweise kann Mandant 1 einen benutzerdefinierten Domänennamen wie tenant1app.tenant1.com konfigurieren.

Das Unternehmen stellt Azure Front Door mithilfe der folgenden Konfiguration bereit:

Diagramm: Azure Front Door-Konfiguration mit mehreren benutzerdefinierten Vanity-Domänen, Routen und Ursprungsgruppen sowie einer Kombination von TLS-Zertifikaten in Key Vault- und TLS-Zertifikaten, die von Azure Front Door verwaltet werden

DNS-Konfiguration

Einmalige Konfiguration: Nichts.

Wenn ein neuer Mandant integriert wird: Der Mandant muss zwei Datensätze auf seinem eigenen DNS-Server erstellen:

  • Ein TXT-Eintrag für die Domänenüberprüfung. Beispielsweise muss Mandant 1 einen TXT-Eintrag mit dem Namen tenant1app.tenant1.com konfigurieren und auf den Wert festlegen, der während des Onboardingprozesses für benutzerdefinierte Domänen von Azure Front Door angegeben wurde.
  • Ein CNAME-Eintrag, der als Alias für den Azure Front Door-Endpunkt für Adventure Works verwendet wird. Beispielsweise muss Mandant 1 einen CNAME-Eintrag mit dem Namen tenant1app.tenant1.com konfigurieren und ihm adventureworks.z01.azurefd.net zuordnen.

TLS-Konfiguration

Adventure Works und seine Mandanten müssen entscheiden, wer TLS-Zertifikate ausstellt:

  • Die einfachste Möglichkeit besteht darin, Azure Front Door zum Ausstellen und Verwalten der Zertifikate zu verwenden. Mandanten sollten jedoch keine CCA-Einträge auf ihren DNS-Servern konfigurieren. In diesem Rahmen können die Einträge die Azure Front Door-Zertifizierungsstelle daran hindern, Zertifikate auszustellen.
  • Alternativ können Mandanten ihre eigenen Zertifikate bereitstellen. Sie müssen mit Adventure Works arbeiten, um das Zertifikat in einen Schlüsseltresor hochzuladen und Zugriff auf Azure Front Door zu ermöglichen.

Azure Front Door-Konfiguration

Einmalige Konfiguration: Adventure Works erstellt ein Azure Front Door-Profil und einen einzelnen Endpunkt. Sie konfigurieren eine Ursprungsgruppe für jeden Stempel. Sie erstellen keine benutzerdefinierten Domänenressourcen oder Routen.

Wenn ein neuer Mandant integriert wird: Adventure Works fügt Azure Front Door eine benutzerdefinierte Domänenressource hinzu. Sie verwenden den vom Mandanten bereitgestellten Domänennamen und ordnen das entsprechende TLS-Zertifikat der benutzerdefinierten Domänenressource zu. Anschließend erstellen sie eine Route, um anzugeben, an welche Ursprungsgruppe (Stempel) die Anforderungen des Mandanten weitergeleitet werden sollen. Im vorherigen Diagramm wird tenant1app.tenant1.com an die Ursprungsgruppe in der Region Australien weitergeleitet und tenant2app.tenant3.com an die Ursprungsgruppe in der Region USA.

Vorteile

  • Kunden können ihre eigenen Domänennamen angeben. Azure Front Door leitet Anforderungen transparent an die mehrinstanzenfähige Lösung weiter.
  • Adventure Works verwaltet eine einzelne Instanz von Azure Front Door, um Datenverkehr an mehrere Stempel in mehreren Regionen weiterzuleiten.

Nachteile

  • Adventure Works muss Azure Front Door jedes Mal neu konfigurieren, wenn ein neuer Mandant integriert wird.
  • Mandanten müssen am Onboardingprozess beteiligt werden. Sie müssen DNS-Änderungen vornehmen und möglicherweise TLS-Zertifikate ausstellen.
  • Mandanten steuern ihre DNS-Einträge. Änderungen an DNS-Einträgen können sich auf deren Zugriff auf die Adventure Works-Lösung auswirken.
  • Adventure Works muss auf Azure Front Door-Kontingente und -Grenzwerte achten, insbesondere auf die Anzahl von Routen und benutzerdefinierten Domänen sowie auf den Grenzwert für zusammengesetztes Routing.

Szenario 5: Azure Front Door-Profil pro Stempel

Sie können für jeden Stempel ein Azure Front Door-Profil bereitstellen. Wenn Sie über zehn Stempel verfügen, stellen Sie zehn Instanzen von Azure Front Door bereit. Dieser Ansatz kann nützlich sein, wenn Sie den Verwaltungszugriff auf die Azure Front Door-Konfiguration der einzelnen Stempel einschränken müssen. Er kann auch hilfreich sein, wenn Sie mehrere Azure Front Door-Profile verwenden müssen, um eine Überschreitung von Ressourcenkontingenten oder -grenzwerten zu vermeiden.

Tipp

Azure Front Door ist eine globale Ressource. Auch wenn Sie regionale Stempel bereitstellen, ist jedes Azure Front Door-Profil global verteilt. Sie sollten überlegen, ob Sie wirklich mehrere Azure Front Door-Profile bereitstellen müssen und welche Vorteile Sie dadurch gewinnen.

Wenn Sie über einen Stempel verfügen, der mehrere Mandanten bedient, müssen Sie überlegen, wie Sie Datenverkehr an jeden Mandanten weiterleiten. Sehen Sie sich die in den vorherigen Szenarios beschriebenen Ansätze an, und ziehen Sie in Betracht, Ansätze entsprechend Ihren Anforderungen zu kombinieren.

Vorteile

  • Wenn Sie Ihre Konfiguration auf mehrere Profile erweitern, ist es weniger wahrscheinlich, dass Sie die Azure Front Door-Ressourcengrenzwerte erreichen. Wenn Sie z. B. eine hohe Anzahl benutzerdefinierter Domänen unterstützen müssen, können Sie die Domänen auf mehrere Azure Front Door-Profile aufteilen und innerhalb der Grenzwerte jedes Profils bleiben.
  • Mit diesem Ansatz können Sie die Verwaltungsberechtigungen Ihrer Azure Front Door-Ressourcen festlegen. Sie können die rollenbasierte Zugriffssteuerung (Role-Based Access Control, RBAC) von Azure verwenden, um Administratoren Zugriff auf das Profil eines einzelnen Stempels zu gewähren.

Nachteile

  • Dieser Ansatz verursacht in der Regel hohe Kosten, da Sie mehr Profile bereitstellen. Weitere Informationen finden Sie unter Grundlegendes zur Front Door-Abrechnung.
  • Es gibt eine Beschränkung für die Anzahl von Azure Front Door-Profilen, die Sie in einem einzelnen Azure-Abonnement bereitstellen können. Weitere Informationen finden Sie unter Kontingente und Grenzwerte für Front Door.
  • Sie müssen das Azure Front Door-Profil jedes Stempels separat konfigurieren und die DNS-Konfiguration, TLS-Zertifikate und TLS-Konfiguration für jeden Stempel verwalten.

Beitragende

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

Hauptautoren:

Andere Mitwirkende:

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

Nächste Schritte