Müssen Header und URLs geändert werden? Konfiguriere Application-Gateway-Rewrite-Regeln

CloudTrips-Clients sollen eine stabile URL wie /api/health aufrufen, auch wenn das Backend die Antwort unter /internal/status.json speichert. Die Antwort soll außerdem zeigen, dass sie das Application Gateway passiert hat, ohne dafür den Anwendungscode zu ändern.

Konfiguriere ein Rewrite Set mit zwei Regeln: Eine ändert den an das Backend gesendeten Pfad, die andere fügt API-Antworten einen Response Header hinzu:

Client ruft auf:       /api/health
Gateway sendet:        /internal/status.json an den API Backend Pool
Client erhält Header:  X-CloudTrips-Gateway: ApplicationGateway

Im Browser oder Client bleibt /api/health sichtbar. Dies ist ein Rewrite und kein Redirect: Application Gateway ändert seine Backend-Anfrage, statt den Client zu einer zweiten Anfrage an eine andere URL aufzufordern.

Dieser Trip hängt von URLs benötigen unterschiedliche Backend Pools? Konfiguriere Path-based Routing ab. Behalte das vorhandene Application Gateway, rule-cloudtrips-paths, die Pfadregel /api/*, be-cloudtrips-api-test-weu und beide Web-VMs.

URL- und Header-Rewrites benötigen eine Application-Gateway-v2-SKU. Das vorhandene agw-cloudtrips-web-test-weu verwendet Standard_v2 und erfüllt diese Voraussetzung bereits. In diesem Trip wird keine neue kostenpflichtige Azure-Ressource erstellt.

Den internen Backend-Pfad erstellen

Öffne vm-cloudtrips-web02-test-weu, wähle Operations > Run command > RunShellScript und führe aus:

sudo mkdir -p /opt/cloudtrips-web/internal
printf '%s\n' '{"service":"CloudTrips API","status":"healthy","backend":"WEB02"}' \
  | sudo tee /opt/cloudtrips-web/internal/status.json >/dev/null
curl --silent http://127.0.0.1/internal/status.json

Der letzte Befehl sollte zurückgeben:

{"service":"CloudTrips API","status":"healthy","backend":"WEB02"}

Die Datei existiert nur unter dem Backend-Pfad. Application Gateway gibt ihr den sauberen öffentlichen Pfad /api/health.

Das Rewrite Set erstellen

Öffne agw-cloudtrips-web-test-weu, wähle Settings > Rewrites und danach Rewrite set. Trage ein:

Name: rewrite-cloudtrips-api-health
Routing rule: rule-cloudtrips-paths
Path rule: route-api (/api/*)

Das Portal zeigt die Pfadzuordnung möglicherweise erst nach Auswahl der Routingregel an. Ordne das Set route-api zu, nicht dem Standard-Backend der Path Map. Nur Anfragen, die zuerst /api/* entsprechen, sollen dieses Rewrite Set verwenden.

Nur die öffentliche Health-URL auswählen

Füge dem Set eine Rewrite-Regel hinzu:

Rewrite rule name: rewrite-api-health
Rule sequence: 100

Wähle unter Conditions die Option Add und konfiguriere:

Type of variable to check: Server variable
Server variable: uri_path
Case-sensitive: No
Operator: equal (=)
Pattern: ^/api/health$

uri_path enthält nur den Anfragepfad. Die Anker ^ und $ bedeuten, dass der vollständige Pfad /api/health lauten muss. Eine URL wie /api/health/details stimmt nicht überein.

Die URL umschreiben

Füge unter Actions eine URL-Aktion hinzu:

Rewrite type: URL
Action type: Set
URL path: /internal/status.json
Re-evaluate path map: No

Lasse den Query String unverändert. Re-evaluate path map bleibt bewusst deaktiviert: Application Gateway behält den anhand des ursprünglichen /api/*-Pfads ausgewählten API Pool bei und sendet den umgeschriebenen Pfad an WEB02. Bei einer erneuten Auswertung würde /internal/status.json nicht mehr mit /api/* übereinstimmen und könnte an den Standard-Web-Pool gesendet werden.

Den Header als separate Regel hinzufügen

Beschränke rewrite-api-health auf die oben beschriebene Bedingung und URL-Aktion. Wähle im selben Rewrite Set Add rewrite rule und konfiguriere:

Rewrite rule name: add-api-gateway-header
Rule sequence: 200
Conditions: None

Füge unter Actions hinzu:

Rewrite type: Response header
Action type: Set
Header name type: Custom header
Header name: X-CloudTrips-Gateway
Header value: ApplicationGateway

Der Header wird der Antwort hinzugefügt, die Application Gateway an den Client zurücksendet. Eine zusätzliche Bedingung ist nicht erforderlich, weil das Rewrite Set bereits ausschließlich route-api (/api/*) zugeordnet ist. Der Header erscheint deshalb bei API-Antworten, aber nicht beim Image-Pfad oder beim Standard-Web-Pfad.

Behalte die URL- und Response-Header-Aktionen in getrennten Regeln. In dieser getesteten Konfiguration wurde bei beiden Aktionen innerhalb der bedingten URL-Regel zwar der Backend-Pfad umgeschrieben, der Response Header jedoch nicht zurückgegeben. Mit der zweiten Regel wird die Response-Aktion unabhängig für den zugeordneten API-Pfad ausgeführt.

Wähle Create oder Save und warte, bis das Application-Gateway-Update erfolgreich abgeschlossen ist.

Den Rewrite testen

Führe die folgende Anfrage gegen die vorhandene öffentliche IP des Application Gateways aus:

curl --http1.1 --verbose \
  http://<application-gateway-public-ip>/api/health

Response Header beginnen in der ausführlichen Ausgabe mit <. Die Antwort sollte sowohl den benutzerdefinierten Header als auch die von WEB02 bereitgestellte JSON-Datei enthalten:

< HTTP/1.1 200 OK
< X-CloudTrips-Gateway: ApplicationGateway

{"service":"CloudTrips API","status":"healthy","backend":"WEB02"}

Prüfe nun den Gültigkeitsbereich des Headers:

curl --silent --show-error --dump-header - --output /dev/null \
  http://<application-gateway-public-ip>/api/status.json
curl --silent --show-error --dump-header - --output /dev/null \
  http://<application-gateway-public-ip>/images/test.txt
curl --silent --show-error --dump-header - --output /dev/null \
  http://<application-gateway-public-ip>/

X-CloudTrips-Gateway sollte bei /api/status.json erscheinen, weil auch dieser Pfad route-api verwendet. Bei /images/test.txt und / darf er nicht erscheinen, da diese den Image-Pfad beziehungsweise das Standard-Backend verwenden.

Der Client hat /api/health aufgerufen. Er hat weder /internal/status.json angefordert noch einen Redirect auf diesen Pfad gesehen. Die ursprüngliche /api/*-Route wählte das API Backend aus, der erste Rewrite änderte den Pfad der Backend-Verbindung und die zweite Regel fügte auf dem Rückweg den Header hinzu.

Ein Rewrite ist keine Autorisierungsgrenze. Verwende Authentifizierung, NSGs, Private Endpoints und Anwendungsautorisierung, wenn ein Pfad tatsächlich geschützt werden muss.

Behalte das Application Gateway, seinen Listener und die pfadbasierte Regel, die Backend Pools und beide VMs für die folgenden Application-Gateway-Trips.