Application-Gateway-Änderung

Runbook für Operatoren und Reviewer für die Standardänderungen Workload zum Application Gateway hinzufügen und Änderungen an der workload-Konfiguration im Application Gateway. Die Felder der Anfrage, das vollständige JSON und die Auswirkungen stehen unter Application Gateway. Diese Seite nennt die Reihenfolge der Bearbeitung, die Prüfungen und die typischen Probleme. Das Deployment steht unter Application-Gateway-Deployment.

1. Die Anfrage prüfen

Fang nicht an, bevor diese Felder vollständig sind:

Feld	Hinweis
Workload-Name	Wird in den Namen von pool, setting, listener, rule und probe verwendet.
Backend-Adresse (IP oder FQDN)	Das Backend muss vom Gateway-Subnet aus erreichbar sein.
Listener-URL und Port (HTTP oder HTTPS)	Der öffentliche Host-Name.
SSL-Zertifikat	Pflicht für einen HTTPS-listener. Das Zertifikat muss schon im Key Vault des Gateways liegen (siehe Schritt 4).
Redirect	Ja oder nein (zum Beispiel HTTP auf HTTPS).
Health probe	Standard oder benutzerdefiniert mit Pfad, Protokoll und Intervall.
Benutzerdefinierte Fehlerseiten	Optional (zum Beispiel für 502 und 403).

2. Die Änderung vorbereiten

1. Erstelle im Konfigurations-Repository einen Branch von main, mit der Ticketnummer im Namen.
2. Öffne die Gateway-Datei der Region: application_gateway_hub.json im Ordner application_gateways/ der Region. Nutze genau diesen Namen für das hub-Gateway: Die Config tests prüfen nur diese Datei.
3. Mache dieselbe Änderung für jede Plattform-Umgebung, die sie braucht, zuerst canary.

3. In dieser Reihenfolge bearbeiten

Jeder Schritt fügt eine map in der Datei hinzu oder ändert sie. Die Namen, die du in einem früheren Schritt vergibst, sind die Referenzen in einem späteren. Nutze deshalb pro workload ein Namensmuster (zum Beispiel <workload>-pool, <workload>-https-settings).

Schritt	Map	Was zu tun ist	Prüfung
1	backend_address_pools	Den pool mit ip_addresses und/oder fqdns hinzufügen.	Bei Adressen nur IPv4.
2	probes	Nur für eine benutzerdefinierte probe: Protokoll, Host, Pfad, Intervall, Timeout, unhealthy threshold.	Bei einer Standard-probe bleibt probe_name im HTTP-setting null.
3	backend_http_settings	Port, Protokoll, Host-Name, Request-Timeout, probe-Name. Entweder ein fester host_name oder pick_host_name_from_backend_address auf true mit host_name null.	Ein Backend, das über HTTPS angesprochen wird, braucht ein vertrauenswürdiges Zertifikat.
4	ssl_certificates	Das Zertifikat über seine Key-Vault-secret-URI referenzieren.	Siehe unten.
5	http_listeners	Host-Name, Protokoll, Port, Zertifikat.	protocol und frontend_port_name passen zusammen: Https mit dem HTTPS-Port, Http mit dem HTTP-Port. Ein HTTPS-listener hat ssl_certificate_name.
6	redirect_configurations	Nur, wenn ein Redirect angefragt ist.
7	request_routing_rules	listener, pool und setting (oder den Redirect) verknüpfen.	Eine eindeutige priority. Jeder listener wird nur von einer rule genutzt.

Das Zertifikat

Das Zertifikat muss vor dem Deployment im Key Vault des Gateways importiert sein, als Certificate im PFX-Format. Am sichersten ist es, wenn der Antragsteller es importiert: Die PFX-Datei mit privatem Schlüssel und Passwort wird dann nie an das Plattform-Team geschickt. Verweise den Antragsteller auf Microsofts Tutorial zum Importieren eines Zertifikats.

• In der Datei ist das Zertifikat eine secret-URI: https://<key vault>.vault.azure.net/secrets/<name>. Wie sich eine URI mit und ohne Version verhält, steht unter Ein Zertifikat ersetzen.
• certificate_password_secret_id ist null, wenn die PFX-Datei kein Passwort hat. Wenn sie eines hat, speichere das Passwort als secret im selben Key Vault und referenziere es auf dieselbe Weise.
• Prüfe das Ablaufdatum des Zertifikats und trage es in das Monitoring oder den Kalender des Owners ein.

4. Validieren, committen und den pull request öffnen

1. Validiere das JSON gegen das Schema und führe die Config tests aus (JSON-Dateien mit Schema-Unterstützung bearbeiten).
2. Prüfe die Routing-Logik noch einmal: die Referenzen, die Prioritäten und die listeners.
3. Committe mit einer klaren Nachricht, pushe und öffne den pull request. Verlinke das Ticket.
4. Stimm dich mit den Netzwerk- und Security-Ownern deiner Organisation ab, wenn die Änderung etwas Neues im Internet veröffentlicht.

Checkliste für Reviewer

Mach zuerst die allgemeinen Prüfungen. Dann:

Prüfung	Warum
Jede Referenz zeigt auf einen existierenden Key: pool, setting, probe, listener, Port, Zertifikat, Redirect	Das Deployment schlägt fehl, oder das Gateway wird auf unerwartete Weise geändert.
Jeder HTTPS-listener hat ein Zertifikat, und das secret existiert im Key Vault des Gateways	Der listener kann ohne es nicht starten.
protocol und Port des listeners passen zusammen	Eine Abweichung bricht den listener.
Die Prioritäten der Routing-rules sind eindeutig, und jeder listener wird einmal genutzt	Config test.
Die Backend-Adresse ist gültig, und der Weg zum Backend ist offen: eine Firewallregel vom Gateway-Subnet und die NSG	Sonst ist das Backend unhealthy, und Anwender sehen einen 502.
Die probe passt zum Backend: Pfad, Host, Protokoll	Eine falsche probe markiert ein gesundes Backend als unhealthy.
Nichts anderes hat sich geändert: andere workloads auf demselben Gateway behalten ihre Einträge	Eine Datei beschreibt das ganze Gateway.
Die Änderung ist, wenn zutreffend, in canary und prod	Zuerst auf canary testen.
Kein bestehender Key wurde versehentlich umbenannt	Das Umbenennen eines Keys benennt die Unterressource um.

Dos und Don'ts

Do	Don't
Stimm dich vor der Änderung mit den Netzwerk- und Security-Teams ab.	Vergiss nicht, einen HTTPS-listener mit einem Zertifikat zu verknüpfen.
Prüfe die Ablaufdaten von Zertifikaten regelmäßig.	Ignoriere keine Konflikte zwischen Routing-rules und pool-Zuweisungen.
Prüfe, dass die probe-Konfiguration stimmt.	Übersieh nicht die Auswirkung auf die bestehenden workloads auf demselben Gateway.
Halte die Änderung nachvollziehbar fest.	Wende keine Änderung an, ohne sie zuerst in der Nicht-Produktionsumgebung zu testen.

Fehlerbehebung

Symptom	Ursache und Maßnahme
Das Backend ist nicht erreichbar	Der pool hat eine falsche Adresse, oder die Firewall oder NSG blockiert das Gateway. Meistens braucht es eine Firewallregel vom Gateway-Subnet zum Backend (Firewallregeln).
Der listener funktioniert nicht	Er ist mit der falschen Frontend-IP-Konfiguration oder dem falschen Port verknüpft.
Ein Zertifikatsfehler	Das Zertifikat ist nicht korrekt installiert oder mit dem falschen listener verknüpft.

Weitere Ursachen stehen unter Häufige Probleme.