Eine HTTP-Anwendung benötigt Layer-7-Routing? Erstelle ein Application Gateway

Der regionale CloudTrips Load Balancer verteilt TCP-Verbindungen, versteht aber nicht die HTTP-Anfrage innerhalb einer Verbindung. Er kann /images/* und /api/* nicht unterschiedlich weiterleiten, keine Entscheidungen anhand von HTTP-Headern treffen und keine Web Application Firewall anwenden.

Erstelle ein Azure Application Gateway vor den zwei privaten CloudTrips-Webservern. Application Gateway arbeitet auf Layer 7, der Anwendungsschicht. Es agiert als Reverse Proxy: Es nimmt die HTTP-Verbindung des Clients an, liest die Anfrage, wendet eine Routingregel an und öffnet eine neue Verbindung zu einem gesunden Backend.

Internetclient
      |
Öffentliche IP des Application Gateways
      |
HTTP-Listener und Routingregel
      |----------------------|
Privater WEB01          Privater WEB02

Diese erste Konfiguration sendet alle Anfragen an einen Backend Pool. Die nächsten Trips verwenden dasselbe Gateway für Routing nach URL-Pfad und das Umschreiben von Anfragen.

Dieser Trip baut auf Eine Webanwendung benötigt Traffic-Verteilung? Erstelle einen Load Balancer auf. Verwende vm-cloudtrips-web01-test-weu, vm-cloudtrips-web02-test-weu, ihren Webdienst auf Port 80 und vnet-cloudtrips-test-weu erneut. Der bestehende Load Balancer ist kein Backend des Application Gateways; beide Dienste verbinden sich unabhängig mit den VMs.

Application Gateway Standard_v2 verursacht eine feste stündliche Gebühr, solange es bereitgestellt ist – auch bei einem Autoscaling-Minimum von null. Führe die Application-Gateway-Trips zusammen aus und bereinige danach die Ressourcen.

Die vorhandenen Webserver vorbereiten

Falls die beiden VMs nach dem vorherigen Trip deallokiert wurden, starte sie:

az vm start --resource-group rg-cloudtrips-network-test-weu --name vm-cloudtrips-web01-test-weu
az vm start --resource-group rg-cloudtrips-network-test-weu --name vm-cloudtrips-web02-test-weu

Der zuvor erstellte systemd-Dienst cloudtrips-web startet automatisch. Falls eine VM gelöscht wurde, wiederhole zuerst die Abschnitte zur VM und Testseite aus dem Load-Balancer-Trip.

Ein eigenes Application-Gateway-Subnetz erstellen

Application Gateway benötigt ein eigenes Subnetz. Azure platziert dort verwaltete Gateway-Instanzen, wenn der Dienst skaliert oder gewartet wird. VMs und andere Ressourcentypen dürfen dieses Subnetz nicht mitbenutzen.

Öffne vnet-cloudtrips-test-weu, wähle Settings > Subnets und danach + Subnet. Konfiguriere:

Name: snet-appgw
Starting address: 10.20.4.0
Size: /24
Network security group: None
Route table: None

Wähle Save.

10.20.4.0/24 liegt innerhalb des VNet-Adressraums 10.20.0.0/16 und überschneidet sich nicht mit den Subnetzen für Anwendung, Daten oder die frühere Firewall. Ein /24 bietet Platz für Autoscaling und Wartungsvorgänge von Application Gateway v2.

Den Zugriff des Gateways auf die Backends erlauben

Die Application-Gateway-Instanzen senden Anfragen von privaten Adressen in snet-appgw. Erlaube diese Anfragen in der NSG von snet-app.

Öffne nsg-cloudtrips-app-test-weu, wähle Settings > Inbound security rules und füge hinzu:

Source: IP Addresses
Source IP addresses/CIDR ranges: 10.20.4.0/24
Source port ranges: *
Destination: IP Addresses
Destination IP addresses/CIDR ranges: 10.20.1.0/24
Service: HTTP
Action: Allow
Priority: 105
Name: Allow-HTTP-ApplicationGateway
Description: Allow Application Gateway to reach the CloudTrips web backends

Diese Regel erlaubt die Verbindung vom Gateway zum Backend auf Port 80. Sie ist vom öffentlichen Listener getrennt: Internetclients verbinden sich mit der öffentlichen IP des Gateways und nicht direkt über diese Regel.

Das Application Gateway erstellen

Suche nach Application gateways und wähle Create. Lege unter Basics fest:

Subscription: CloudTrips TEST
Resource group: rg-cloudtrips-network-test-weu
Application gateway name: agw-cloudtrips-web-test-weu
Region: West Europe
Tier: Standard V2
Enable autoscaling: Yes
Minimum instance count: 0
Maximum instance count: 2
Virtual network: vnet-cloudtrips-test-weu
Subnet: snet-appgw

Ein Minimum von null reserviert bei ausbleibendem Lab-Traffic keine Kapazitätseinheiten, entfernt aber nicht die feste stündliche Gebühr des Gateways.

Wähle unter Frontends die Option Public und erstelle eine öffentliche IP:

Public IP address: Add new
Name: pip-cloudtrips-appgw-test-weu
SKU: Standard
Assignment: Static

Den privaten Backend Pool hinzufügen

Wähle unter Backends die Option Add a backend pool und konfiguriere:

Name: be-cloudtrips-web-test-weu
Add backend pool without targets: No
Target type: Virtual machine
Targets: die NICs von vm-cloudtrips-web01-test-weu und vm-cloudtrips-web02-test-weu

Application Gateway speichert die privaten NIC-Adressen der VMs als Backendziele. Keine der VMs benötigt eine öffentliche IP.

Den Listener mit den Backends verbinden

Wähle unter Configuration die Option Add a routing rule. Konfiguriere den Listener:

Rule name: rule-cloudtrips-http
Priority: 100
Listener name: listener-cloudtrips-http
Frontend IP: Public IPv4
Protocol: HTTP
Port: 80
Listener type: Basic

Ein Listener wartet auf passende Clientanfragen an einer Frontend-IP und einem Port. Ein Basic Listener akzeptiert auf dieser öffentlichen IP und Port 80 jeden Hostnamen.

Wähle unter Backend targets:

Backend target: be-cloudtrips-web-test-weu
Backend settings: Add new
Backend settings name: settings-cloudtrips-http
Backend protocol: HTTP
Backend port: 80
Cookie-based affinity: Disable
Connection draining: Disable
Request time-out: 20 seconds
Override backend path: Leave empty
Use custom probe: No

Die Routingregel verbindet drei Komponenten:

• Der Listener empfängt die Clientanfrage.
• Der Backend Pool bestimmt die möglichen Server.
• Die Backend Settings legen fest, wie sich Application Gateway mit ihnen verbindet.

Ohne eigene Probe prüft Application Gateway automatisch / über HTTP auf Backend-Port 80. Antworten von 200 bis 399 gelten als gesund. Das genügt, weil beide CloudTrips-Testseiten unter / erfolgreich antworten.

Aktiviere noch kein Path-based Routing. Wähle Add, ergänze die Tags Application: CloudTrips, Environment: TEST und Purpose: Layer7Routing und wähle Review + create > Create.

Die Bereitstellung von Application Gateway kann mehrere Minuten dauern.

Den Backendzustand prüfen

Öffne agw-cloudtrips-web-test-weu, wähle Monitoring > Backend health und klappe be-cloudtrips-web-test-weu auf. Beide Backendadressen sollten Healthy melden.

Ein ungesunder Zustand bedeutet meistens, dass der Webdienst gestoppt ist, die NSG den Zugriff von 10.20.4.0/24 auf Port 80 nicht erlaubt oder die Backend Settings das falsche Protokoll beziehungsweise den falschen Port verwenden.

Layer-7-Routing testen

Kopiere die öffentliche IP aus der Übersicht des Application Gateways und führe aus:

for request in {1..6}; do
  curl --connect-timeout 10 http://<application-gateway-public-ip>
done

Die Antworten sollten von WEB01 und WEB02 kommen. Application Gateway liest jede HTTP-Anfrage, wertet rule-cloudtrips-http aus, wählt einen gesunden Server aus be-cloudtrips-web-test-weu und sendet eine neue HTTP-Anfrage an Backend-Port 80.

Das sichtbare Ergebnis ähnelt dem Test des regionalen Load Balancers, die Entscheidung fällt jetzt jedoch auf Layer 7. Die aktuelle Basic Rule sendet noch jede URL an denselben Pool; der nächste Trip wählt Backend Pools anhand des HTTP-Pfads aus.

Das Lab behalten oder entfernen

Behalte agw-cloudtrips-web-test-weu, pip-cloudtrips-appgw-test-weu, snet-appgw und beide Web-VMs, wenn du direkt mit den Trips zu Path-based Routing und Rewrite Rules fortfährst.

Falls du die Labs pausierst, lösche zuerst das Application Gateway und danach seine öffentliche IP, um deren Gebühren zu beenden. Das leere Subnetz snet-appgw kann kostenlos bestehen bleiben. Deallokiere die beiden Web-VMs, wenn sie nicht benötigt werden.