URLs benötigen unterschiedliche Backend Pools? Konfiguriere Path-based Routing

Veröffentlicht am:
#networking

Das CloudTrips Application Gateway sendet derzeit jede URL an denselben Backend Pool. Dadurch können Web-, Bild- und API-Komponenten nicht unabhängig skaliert oder gewartet werden.

Konfiguriere Path-based Routing, damit Application Gateway den Backend Pool anhand des Pfads in jeder HTTP-Anfrage auswählt:

/images/*  ──► WEB01 Image Pool
/api/*     ──► WEB02 API Pool
alles andere ──► ursprünglicher Web Pool

Die öffentliche IP bleibt gleich. Verwende Port 8080 nur beim Erstellen des zweiten Listeners und der pfadbasierten Regel. Sobald diese Regel vorhanden ist, entfernst du die alte Basic Rule und stellst den neuen Listener auf den normalen HTTP-Port 80 um.

Dieser Trip hängt von Eine HTTP-Anwendung benötigt Layer-7-Routing? Erstelle ein Application Gateway ab. Behalte agw-cloudtrips-web-test-weu, beide privaten Web-VMs, den HTTP-Listener, die Backend Settings und die NSG-Regel Allow-HTTP-ApplicationGateway.

Application Gateway und die zwei laufenden VMs verursachen Gebühren. Führe diesen und die folgenden Application-Gateway-Trips zusammen aus.

Jedem Backend eine eigene URL geben

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

sudo mkdir -p /opt/cloudtrips-web/images
printf '%s\n' 'CloudTrips image service from WEB01' \
  | sudo tee /opt/cloudtrips-web/images/test.txt >/dev/null
curl --silent http://127.0.0.1/images/test.txt

Der letzte Befehl sollte zurückgeben:

CloudTrips image service from WEB01

Führe auf vm-cloudtrips-web02-test-weu aus:

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

Die Ausgabe sollte lauten:

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

Die vorhandenen Python-Dienste stellen bereits Dateien unter /opt/cloudtrips-web bereit. Es ist daher weder ein neuer Prozess noch ein zusätzlicher eingehender Port notwendig.

Den Image Backend Pool erstellen

Öffne agw-cloudtrips-web-test-weu, wähle Settings > Backend pools und danach Add. Konfiguriere:

Name: be-cloudtrips-images-test-weu
Add backend pool without targets: No
Target type: Virtual machine
Target: vm-cloudtrips-web01-test-weu
NIC: die NIC von vm-cloudtrips-web01-test-weu

Wähle Save und warte, bis der Bereitstellungsstatus des Application Gateways Succeeded lautet.

Den API Backend Pool erstellen

Füge einen weiteren Pool hinzu:

Name: be-cloudtrips-api-test-weu
Add backend pool without targets: No
Target type: Virtual machine
Target: vm-cloudtrips-web02-test-weu
NIC: die NIC von vm-cloudtrips-web02-test-weu

Wähle Save und warte erneut auf Succeeded.

Dieselbe NIC kann dem ursprünglichen Web Pool und einem spezialisierten Application-Gateway-Pool angehören. Durch das getrennte Hinzufügen der Pools werden gleichzeitige NIC-Updates wie beim Konflikt im vorherigen Trip vermieden.

Application Gateway Backend pools-Seite mit dem Standard-Web-, Image- und API-Pool

Einen zweiten Listener erstellen

Die vorhandene Basic Rule kann im Portal nicht auf pfadbasiert umgestellt werden. Außerdem muss Application Gateway immer mindestens eine Regel haben. Behalte rule-cloudtrips-http.

Wähle Settings > Listeners > Add listener und konfiguriere:

Listener name: listener-cloudtrips-paths
Frontend IP: Public IPv4
Protocol: HTTP
Frontend port: Add new
Frontend port name: port-cloudtrips-paths-8080
Port: 8080
Listener type: Basic
Associated routing rule: Not associated

Port 80 wird bereits von listener-cloudtrips-http verwendet. Deshalb muss dieser zweite Listener vorübergehend Port 8080 verwenden. Nach dem Hinzufügen der neuen pfadbasierten Regel entfernst du die alte Regel und ihren Listener und stellst diesen Listener wieder auf Port 80 um. Über settings-cloudtrips-http verbindet sich Application Gateway während des gesamten Vorgangs mit Backend-Port 80 auf beiden VMs.

Wähle Add und warte, bis das Application-Gateway-Update erfolgreich abgeschlossen wurde. Zu diesem Zeitpunkt wartet der Listener nur an der öffentlichen IP und Port 8080. Er leitet noch keine Anfragen weiter, weil ihm keine Routingregel zugeordnet ist. Im nächsten Schritt wird rule-cloudtrips-paths erstellt und mit diesem Listener verbunden.

Die pfadbasierte Regel erstellen

Wähle Settings > Rules > Add routing rule und konfiguriere:

Rule name: rule-cloudtrips-paths
Priority: 200
Listener: listener-cloudtrips-paths

Wähle unter Backend targets das Standardziel:

Backend target: be-cloudtrips-web-test-weu
Backend settings: settings-cloudtrips-http

Dieser Standard-Pool verarbeitet Anfragen wie /, die mit keinem konfigurierten Pfad übereinstimmen. Wähle Add multiple targets to create a path-based rule und füge hinzu:

Path: /images/*
Target name: route-images
Backend settings: settings-cloudtrips-http
Backend target: be-cloudtrips-images-test-weu

Füge das API-Ziel hinzu:

Path: /api/*
Target name: route-api
Backend settings: settings-cloudtrips-http
Backend target: be-cloudtrips-api-test-weu

Füge nicht /* hinzu. Dieses Muster würde jede verbleibende URL abfangen, bevor der Standard-Pool verwendet wird. Wenn sich Muster überschneiden, wertet Application Gateway sie in der angezeigten Reihenfolge aus. Platziere daher spezifischere Pfade vor allgemeineren. Beim Pfadvergleich wird außerdem die Groß- und Kleinschreibung berücksichtigt: /api/* stimmt nicht mit /API/* überein.

Wähle Add und warte, bis das Application-Gateway-Update erfolgreich abgeschlossen wurde. Unter Settings > Rules sollten sowohl die ursprüngliche Port-80-Regel als auch die neue pfadbasierte Port-8080-Regel vorhanden sein.

Den pfadbasierten Listener auf Port 80 umstellen

Port 8080 war nur ein Workaround für die Einrichtung: Zwei Basic Listener können nicht gleichzeitig dieselbe öffentliche Frontend-IP und denselben Port verwenden. Da Application Gateway jetzt eine zweite Regel besitzt, schließe die Umstellung ab:

  1. Lösche unter Settings > Rules die Regel rule-cloudtrips-http und warte auf den erfolgreichen Abschluss.
  2. Lösche unter Settings > Listeners den jetzt nicht mehr zugeordneten listener-cloudtrips-http und warte erneut.
  3. Öffne listener-cloudtrips-paths, ändere seinen Frontend-Port von 8080 auf 80 und speichere.

Der endgültige öffentliche Traffic-Pfad wird jetzt von rule-cloudtrips-paths auf Port 80 verarbeitet. Die Backendverbindung verwendet weiterhin HTTP-Port 80.

Application-Gateway-Regel mit Image- und API-Pfadmustern für unterschiedliche Backend Pools

Alle Backend Pools prüfen

Öffne Monitoring > Backend health. Die Seite sollte jetzt anzeigen:

be-cloudtrips-web-test-weu: WEB01 und WEB02
be-cloudtrips-images-test-weu: WEB01
be-cloudtrips-api-test-weu: WEB02

Es gibt weiterhin nur zwei VMs. Backend Health zeigt eine Zeile für jede Kombination aus Server und Poolmitgliedschaft. Deshalb erscheint dieselbe private IP mehrmals:

WEB01: Standard-Web-Pool + Image Pool
WEB02: Standard-Web-Pool + API Pool

Eine VM darf mehreren Application-Gateway-Backend-Pools angehören, wenn sie verschiedene Anfragetypen verarbeitet. Dieses Lab verwendet zwei VMs erneut, um zusätzliche Kosten zu vermeiden. In einer größeren Produktionsumgebung hätten Web-, Image- und API-Pool normalerweise jeweils eigene Gruppen aus mehreren Servern, damit jede Komponente unabhängig skaliert und gewartet werden kann.

Alle Einträge sollten Healthy werden. Die Pools verwenden settings-cloudtrips-http erneut, sodass die Standardprobe bei jedem Ziel / auf Port 80 prüft.

Die Routingentscheidung beweisen

Sende diese Anfragen an die vorhandene öffentliche IP des Application Gateways:

curl http://<application-gateway-public-ip>/
curl http://<application-gateway-public-ip>/images/test.txt
curl http://<application-gateway-public-ip>/api/status.json

Die Root-Anfrage kann einen der beiden Server im Standard-Pool erreichen. Die anderen beiden Ergebnisse müssen eindeutig sein:

CloudTrips image service from WEB01
{"service":"CloudTrips API","backend":"WEB02"}

Lokales Terminal mit Standard-URL sowie Image- und API-Pfaden, die ihre vorgesehenen CloudTrips Backend Pools erreichen

Application Gateway leitet den vollständigen ursprünglichen Pfad an das ausgewählte Backend weiter. /images/test.txt erreicht WEB01 deshalb als /images/test.txt und nicht als /test.txt. Der nächste Trip verwendet eine Rewrite Rule, wenn das Backend einen anderen Pfad benötigt oder ein Request- beziehungsweise Response-Header geändert werden muss.

Behalte das Application Gateway, den pfadbasierten Listener und die Regel, alle drei Backend Pools und beide VMs für den Rewrite-Rule-Trip.