Front Door benötigt Routinglogik? Konfiguriere Rules Engine

Veröffentlicht am:
#networking

CloudTrips verwendet jetzt Origin-Prioritäten für automatisches Failover. Dieses Design reagiert auf den Zustand der Origins. Manchmal soll das Routing jedoch von der Anfrage selbst abhängen. Ein Release Engineer möchte beispielsweise eine Maintenance-Seite prüfen, ohne die primäre Anwendung für alle Benutzer zu deaktivieren.

Erstelle ein Rule Set in Azure Front Door, das nach diesem Request Header sucht:

X-CloudTrips-Mode: maintenance

Passende Anfragen gehen an eine eigene Origin Group, die nur den Storage Origin enthält. Anfragen ohne den Header verwenden weiterhin die Application-Gateway-Origin-Group der Standardroute.

                         kein passender Header
Client -> Front Door --------------------------> og-cloudtrips-weu
             |
             | X-CloudTrips-Mode: maintenance
             `---------------------------------> og-cloudtrips-maintenance-neu

Der Header versetzt nicht die gesamte Site in den Maintenance-Modus. Er ändert nur die Anfrage, die ihn enthält. Dadurch lässt sich die Regel demonstrieren, ohne andere Benutzer zu unterbrechen.

Dieser Trip hängt von Front Door benötigt mehrere Origins? Konfiguriere eine Origin Group ab. Behalte afd-cloudtrips-test, route-cloudtrips-all, og-cloudtrips-weu, origin-appgw-weu, den Maintenance Storage Account und seine statische Website. Setze origin-appgw-weu vor dem Fortfahren wieder auf Enabled.

Die Front-Door-Objekte verstehen

An einer Anfrage sind mehrere Front-Door-Objekte beteiligt. In der aktuellen CloudTrips-Konfiguration hängen sie folgendermaßen zusammen:

Front-Door-Profil: afd-cloudtrips-test
|
|-- Endpunkt: cloudtrips-edge-2930ec0f
|   `-- Standarddomain: cloudtrips-edge-...z03.azurefd.net
|
|-- Route: route-cloudtrips-all
|   |-- Domain: die standardmäßige azurefd.net-Domain
|   |-- URL-Muster: /*
|   |-- Standard-Origin-Group: og-cloudtrips-weu
|   `-- Rule Set: rsCloudTripsRouting
|
|-- Rule Set: rsCloudTripsRouting
|   `-- Passender Maintenance Header
|       `-- Override: og-cloudtrips-maintenance-neu
|
`-- Origin Groups
    |-- og-cloudtrips-weu
    |   |-- Application Gateway, Priorität 1
    |   `-- Storage, Priorität 2
    |
    `-- og-cloudtrips-maintenance-neu
        `-- Storage, Priorität 1

Das Profil ist die zentrale Azure-Front-Door-Ressource, die die anderen Konfigurationsobjekte enthält. Der Endpunkt ist der öffentliche Edge-Einstieg. Azure weist ihm eine standardmäßige azurefd.net-Domain zu; später können benutzerdefinierte Domains hinzugefügt werden.

Die Domain ist der Hostname in der URL des Clients. Front Door findet damit den Endpunkt und eine geeignete Route. Die Route gleicht anschließend ein URL-Muster wie /* ab und definiert die Standard-Origin-Group, akzeptierte Protokolle, das Forwarding Protocol, Caching und verknüpfte Rule Sets.

Ein Rule Set ergänzt eine Route um bedingte Logik. Es ersetzt die Route nicht. Wenn keine Regel zutrifft, behält die Route ihre Standard-Origin-Group. Wenn die Maintenance-Regel zutrifft, überschreibt sie diese Gruppe nur für die aktuelle Anfrage:

Ohne Header:
Domain -> Endpunkt -> Route -> og-cloudtrips-weu

Mit X-CloudTrips-Mode: maintenance:
Domain -> Endpunkt -> Route -> passende Regel -> og-cloudtrips-maintenance-neu

Kurz gesagt: Die Domain identifiziert die Anfrage, der Endpunkt empfängt sie, die Route gleicht sie ab und das Rule Set kann das Ziel bedingt ändern.

Den Ausgangszustand bestätigen

Öffne afd-cloudtrips-test, wähle Front Door manager und öffne route-cloudtrips-all. Bestätige:

Origin group: og-cloudtrips-weu
Forwarding protocol: HTTP only
Caching: Disabled
Rules: None

Öffne Settings > Origin groups > og-cloudtrips-weu und bestätige:

origin-appgw-weu: Enabled, priority 1
origin-maintenance-neu: Enabled, priority 2
Health probe protocol: HTTP

Für den Storage Account muss Require secure transfer weiterhin deaktiviert sein. Dadurch bleiben beide Origins mit der HTTP-Verbindung der Route kompatibel. Client-Anfragen an den Front-Door-Endpunkt verwenden weiterhin HTTPS.

Rufe die Hostnamen des Endpunkts und der Storage-Website ab:

AFD_HOST=$(az afd endpoint list \
  --resource-group rg-cloudtrips-network-test-weu \
  --profile-name afd-cloudtrips-test \
  --query '[0].hostName' \
  --output tsv)

FALLBACK_STORAGE="stctfd$(az account show \
  --query id \
  --output tsv | tr -d '-' | cut -c1-8)"

STORAGE_HOST=$(az storage account show \
  --resource-group rg-cloudtrips-network-test-weu \
  --name "$FALLBACK_STORAGE" \
  --query 'primaryEndpoints.web' \
  --output tsv | sed -E 's#^https?://##; s#/$##')

printf 'Front Door: %s\nStorage website: %s\n' \
  "$AFD_HOST" "$STORAGE_HOST"

Eine eigene Maintenance Origin Group erstellen

Eine Regel überschreibt eine Origin Group, nicht einen einzelnen Origin in der vorhandenen Gruppe der Route. Bei erneuter Verwendung von og-cloudtrips-weu würde die Maintenance-Seite nicht erzwungen, weil das fehlerfreie Application Gateway mit Priorität 1 weiterhin gewinnt.

Behalte origin-maintenance-neu in der vorhandenen Gruppe og-cloudtrips-weu. Dieser Origin wird weiterhin für das automatische prioritätsbasierte Failover benötigt. Die neue Gruppe erhält ein zweites Front-Door-Origin-Objekt, das auf dieselbe statische Storage-Website verweist. Dafür sind weder ein weiterer Storage Account noch eine zweite Kopie der Maintenance-Seite erforderlich.

Die fertige Konfiguration enthält:

og-cloudtrips-weu
|-- origin-appgw-weu                 Priorität 1: normale Anwendung
`-- origin-maintenance-neu           Priorität 2: automatisches Failover

og-cloudtrips-maintenance-neu
`-- origin-rules-maintenance-neu     Priorität 1: Rules-Engine-Override

Beide Maintenance Origins -> derselbe Endpunkt der statischen Storage-Website

Wähle in afd-cloudtrips-test Settings > Origin groups > + Add und konfiguriere:

Name: og-cloudtrips-maintenance-neu
Session affinity: Disabled
Health probe status: Enabled
Path: /
Protocol: HTTP
Request type: GET
Interval: 30 seconds

Wähle + Add an origin und konfiguriere:

Name: origin-rules-maintenance-neu
Origin type: Storage (Static website)
Host name: Select the existing maintenance Storage account
Origin host header: Keep the generated static-website hostname
HTTP port: 80
HTTPS port: 443
Priority: 1
Weight: 1000
Status: Enabled
Private Link: Disabled

Wähle Add und speichere anschließend die Origin Group. Warte, bis ihr Deployment Status Succeeded lautet und der Origin fehlerfrei ist. Derselbe Storage-Endpunkt kann durch Origins in zwei verschiedenen Origin Groups repräsentiert werden. Jeder Origin ist ein separates Front-Door- Konfigurationsobjekt.

Verschiebe oder lösche origin-maintenance-neu nach dem Erstellen der neuen Gruppe nicht aus og-cloudtrips-weu. Andernfalls funktioniert das im vorherigen Trip konfigurierte automatische Failover nicht mehr.

Auf der Seite Origin groups kann für og-cloudtrips-maintenance-neu an dieser Stelle Unassociated angezeigt werden. Das ist zu erwarten. Diese Anzeige zählt direkte Verknüpfungen mit Endpunkten und Routen. Die vorhandene Route muss weiterhin direkt mit og-cloudtrips-weu als Standardgruppe verknüpft bleiben.

Wähle für die reine Maintenance-Gruppe nicht die Option Associate endpoint and route. Die nachfolgend erstellte Rules-Engine-Aktion referenziert sie als bedingten Override:

Direkte Routenverknüpfung: route-cloudtrips-all -> og-cloudtrips-weu
Bedingte Regelreferenz: passender Header -> og-cloudtrips-maintenance-neu

Das Portal kann für die Maintenance-Gruppe auch nach der Bereitstellung der Regel weiterhin Unassociated anzeigen, weil eine Regelreferenz keine direkte Routenverknüpfung ist.

Azure-Front-Door-Origin-Groups mit og-cloudtrips-weu an der Standardroute und og-cloudtrips-maintenance-neu als unassociated

Das Rule Set erstellen

Wähle im Front-Door-Profil Settings > Rule sets > + Add. Verwende diesen Namen:

rsCloudTripsRouting

Öffne das neue Rule Set und wähle + Add rule. Konfiguriere den Regelnamen und das Auswertungsverhalten:

Rule name: routeMaintenanceHeader
Order: 1
Stop evaluating remaining rules: Enabled

Das Beenden der Auswertung ist nicht erforderlich, solange dies die einzige Regel ist. Es legt jedoch die beabsichtigte Priorität eindeutig fest, wenn später weitere Routingregeln hinzukommen.

Wähle unter Conditions die Option + Add condition und konfiguriere:

Condition: Request header
Header name: X-CloudTrips-Mode
Operator: Equal
Value: maintenance
Case transform: Lowercase

Durch die Lowercase-Transformation stimmen auch Werte wie Maintenance und MAINTENANCE mit dem kleingeschriebenen Vergleichswert überein. Header-Namen selbst unterscheiden gemäß HTTP nicht zwischen Groß- und Kleinschreibung.

Die Route für passende Anfragen überschreiben

Wähle unter Actions die Option + Add action und konfiguriere die Routingaktion:

Action: Route configuration override
Origin group override: og-cloudtrips-maintenance-neu
Forwarding protocol: HTTP only
Caching: Disabled

Füge eine zweite Aktion hinzu, damit das Ergebnis in den Response Headern sichtbar ist:

Action: Modify response header
Operator: Overwrite
Header name: X-CloudTrips-Rule
Header value: maintenance

Wähle Save. Das Überschreiben der Routenkonfiguration ändert die Origin Group für passende Anfragen. Die Standard-Origin-Group der Route wird dadurch nicht verändert.

Azure-Front-Door-Regel mit der Maintenance-Bedingung für X-CloudTrips-Mode, dem Origin-Group Override und der Diagnose-Response-Header-Aktion

Das Rule Set mit der Route verknüpfen

Ein Rule Set hat keine Wirkung, solange keine Route darauf verweist. Kehre zum Front Door manager zurück, öffne route-cloudtrips-all und wähle unter Rules:

rsCloudTripsRouting

Speichere die Route und warte, bis die Front-Door-Bereitstellung Succeeded anzeigt. Die Verteilung der Konfiguration auf die Edge-Standorte kann mehrere Minuten dauern.

Azure-Front-Door-Rule-Set mit einer Regel, die dem CloudTrips-Endpunkt und der Route zugeordnet ist

Die Standardroute testen

Sende eine normale Anfrage ohne den Header aus der Bedingung:

curl --silent --show-error \
  --dump-header - \
  "https://${AFD_HOST}/" \
  --output -

Der Body sollte von WEB01 oder WEB02 stammen. Die Header dürfen X-CloudTrips-Rule nicht enthalten:

CloudTrips response from WEB01

Damit ist belegt, dass eine nicht passende Anfrage weiterhin die Standard-Origin-Group og-cloudtrips-weu verwendet.

Lokales Terminal mit einer normalen Front-Door-Anfrage, die die CloudTrips-Anwendung ohne Diagnose-Rule-Header zurückgibt

Den Maintenance Override testen

Sende dieselbe Anfrage mit dem passenden Header:

curl --silent --show-error \
  --dump-header - \
  --header 'X-CloudTrips-Mode: maintenance' \
  "https://${AFD_HOST}/" \
  --output -

Die Response Header sollten enthalten:

x-cloudtrips-rule: maintenance

Der Body sollte enthalten:

CloudTrips is temporarily unavailable
Front Door reached the secondary maintenance origin.

Der Diagnose-Response-Header belegt, dass die Regel ausgelöst wurde. Der Maintenance-Body belegt, dass ihr Origin-Group Override die Standardgruppe der Route für diese Anfrage ersetzt hat.

Lokales Terminal mit dem Maintenance Request Header, der die Front-Door-Regel und die Storage-Maintenance-Antwort auslöst

Teste einen anderen Wert:

curl --silent --show-error \
  --header 'X-CloudTrips-Mode: normal' \
  "https://${AFD_HOST}/"

Die Anfrage sollte WEB01 oder WEB02 zurückgeben, weil die Bedingung nicht zutrifft.

Die Verarbeitungsreihenfolge verstehen

Front Door gleicht zuerst die Domain des Endpunkts und die Route ab. Danach wertet der Dienst die mit dieser Route verknüpften Rule Sets der Reihe nach aus. Wenn keine Regel zutrifft, bleibt die Standard-Origin-Group der Route wirksam. Wenn diese Regel zutrifft, überschreibt Front Door die Gruppe, bevor ein Origin ausgewählt wird.

WAF -> Routenabgleich -> Rule-Set-Auswertung -> Origin-Group-Auswahl -> Origin

Der benutzerdefinierte Header ist ein Routingsignal und keine Authentifizierung oder Autorisierung. Jeder Client kann ihn senden, aber dies betrifft nur die jeweilige Anfrage des Clients. Verwende eine Request-Header-Regel niemals allein zum Schutz vertraulicher Inhalte.

Die Regel behalten oder entfernen

Behalte das Rule Set verknüpft, wenn spätere Front-Door-Trips darauf aufbauen. Normale Anfragen bleiben unverändert, solange sie den optionalen Header nicht enthalten.

Wenn du die Lab-Konfiguration entfernen möchtest, bearbeite zuerst route-cloudtrips-all und entferne rsCloudTripsRouting unter Rules. Lösche nach der erfolgreichen Bereitstellung der Route das Rule Set und danach og-cloudtrips-maintenance-neu. Behalte die ursprüngliche Gruppe og-cloudtrips-weu und ihre beiden Origins für automatisches prioritätsbasiertes Failover.