Application Load Balancer von Google Cloudund Traffic Director verwenden eine Google Cloud-Konfigurationsressource, die als URL-Zuordnung bezeichnet wird, um HTTP(S)-Anfragen an Backend-Diensteoder Backend-Buckets weiterzuleiten.
Mit einem externen Application Load Balancer können Sie beispielsweise eine einzelne URL-Zuordnung verwenden, um Anfragen anhand der in der URL-Zuordnung konfigurierten Regeln an verschiedene Ziele weiterzuleiten:
- Anfragen für
https://example.com/video
gehen an einen Backend-Dienst. - Anfragen für
https://example.com/audio
gehen an einen anderen Backend-Dienst.
- Anfragen für
https://example.com/images
werden an einen Cloud Storage-Backend-Bucket gesendet.
- Anfragen für andere Host- und Pfadkombinationen werden an einen Standard-Backend-Dienst gesendet.
URL-Zuordnungen werden bei den folgenden Google Cloud-Produkten verwendet:
- Externer Application Load Balancer (global, regional, klassisch)
- Interner Application Load Balancer (regionenübergreifend und regional)
- Traffic Director, wenn Traffic Director mit den Load-Balancing-APIs bereitgestellt wird
Es gibt zwei Arten von URL-Zuordnungsressourcen: globale und regionale. Die Art der verwendeten Ressource hängt vom Load-Balancing-Schema des Produkts ab.
Produkt | Load-Balancing-Schema | Typ der URL-Zuordnungsressource | Unterstützte Ziele |
---|---|---|---|
Globaler externer Application Load Balancer | EXTERNAL_MANAGED |
Global, extern | Backend-Dienste, Backend-Buckets |
Klassischer Application Load Balancer | EXTERNAL |
Global, extern | Backend-Dienste, Backend-Buckets |
Regionaler externer Application Load Balancer | EXTERNAL_MANAGED |
Regional, extern | Backend-Dienste |
Regionenübergreifender interner Application Load Balancer | INTERNAL_MANAGED |
Global, intern | Backend-Dienste |
Regionaler interner Application Load Balancer | INTERNAL_MANAGED |
Regional, intern | Backend-Dienste |
Traffic Director | INTERNAL_SELF_MANAGED |
Global, intern | Backend-Dienste |
Nicht alle URL-Zuordnungs-Features sind für alle Produkte verfügbar. URL-Zuordnungen, die mit globalen externen Application Load Balancern, regionalen externen Application Load Balancern, internen Application Load Balancern und Traffic Director verwendet werden, unterstützen ebenfalls mehrere erweiterte Features zur Traffic-Verwaltung. Weitere Informationen zu diesen Unterschieden finden Sie unter Load-Balancer-Features im Vergleich: Routing und Trafficverwaltung. Darüber hinaus können regionale URL-Zuordnungen eine Ressource sein, die in App Hub als Dienst festgelegt ist, das sich in der Vorschau befindet.
Funktionsweise von URL-Zuordnungen
Wenn eine Anfrage beim Load-Balancer eingeht, leitet er sie anhand der in der URL-Zuordnung definierten Regeln an einen Backend-Dienstoder einen Backend-Bucket weiter.
Ein Backend-Dienst stellt eine Sammlung von Backends dar, bei denen es sich um Instanzen einer Anwendung oder eines Mikrodienstes handelt. Ein Backend-Bucket ist ein Google Cloud Storage-Bucket, der häufig zum Hosten statischer Inhalte wie Bilder verwendet wird.
Für regionale externe Application Load Balancer, interne Application Load Balancer und Traffic Director sind folgende Ziele möglich:
- Standard-Backend-Dienst
- Nicht standardmäßiger Backend-Dienst
Darüber hinaus unterstützen globale externe Application Load Balancer Folgendes:
- Standard-Backend-Bucket
- Nicht standardmäßiger Backend-Bucket
Angenommen, Sie haben zum Beispiel folgende Konfiguration:
- Eine IP-Adresse:
- Alle Anfragen an Ihre Organisation gehen an dieselbe IP-Adresse und denselben Load-Balancer.
- Der Traffic wird anhand der Anfrage-URL an verschiedene Backend-Dienste weitergeleitet.
- Zwei Domains:
example.net
hostet Schulungsvideos.example.org
hostet die Website Ihrer Organisation.
- Vier Server:
- Einer hostet die Website Ihrer Organisation (Backend-Dienst:
org-site
). - In einem wird die gesamte Schulungsvideo-Website gehostet (Backend-Dienst:
video-site
). - In einem werden HD-Schulungsvideos gehostet (Backend-Dienst:
video-hd
). - Einer hostet Schulungsvideos in Standard Definition (SD) (Backend-Dienst:
video-sd
).
- Einer hostet die Website Ihrer Organisation (Backend-Dienst:
Anfragen sollen so gestellt werden:
- Anfragen an
example.org
(oder eine andere Domain alsexample.net
), um zum Backend-Dienstorg-site
zu gelangen. - Anfragen an
example.net
, die nicht mit spezifischeren Pfaden übereinstimmen, um zumvideo-site
-Backend-Dienst zu gelangen. - Anfragen an
example.net/video/hd/*
, um zum Backend-Dienstvideo-hd
zu gelangen. - Anfragen an
example.net/video/sd/*
, um zum Backend-Dienstvideo-sd
zu gelangen.
Eine --path-rule
für /video/*
stimmt mit URIs wie /video/test1
und /video/test2
überein. Diese Pfadregel stimmt jedoch nicht mit dem Pfad /video
überein.
Wenn der Load-Balancer eine Anfrage mit /../
in der URL empfängt, transformiert der Load-Balancer die URL, indem er das Pfadsegment vor ..
entfernt und mit der transformierten URL antwortet. Wenn beispielsweise eine Anfrage für http://example.net/video/../abc
gesendet wird, antwortet der Load-Balancer mit einer 302-Weiterleitung an http://example.net/abc
. Die meisten Clients reagieren dann, indem sie eine Anfrage an die vom Load-Balancer zurückgegebene URL senden (in diesem Fall http://example.net/abc
). Diese 302-Weiterleitung wird in Cloud Logging nicht protokolliert.
Mit der URL-Zuordnung können Sie diese Art von host- und pfadbasiertem Routing einrichten.
Benennung
Jede URL-Zuordnung hat einen Namen. Wenn Sie einen HTTP(S)-basierten Load-Balancer mithilfe der Google Cloud Console erstellen, wird der URL-Zuordnung ein Name zugewiesen. Dieser Name entspricht dem Namen des Load-Balancers in der Google Cloud Console. Wenn Sie Google Cloud CLI oder die API verwenden, können Sie einen benutzerdefinierten Namen für die URL-Zuordnung definieren.
URL-Zuordnungskomponenten
Eine URL-Zuordnung ist eine Gruppe von Google Cloud-Konfigurationsressourcen, die Anfragen für URLs an Backend-Diensteoder Backend-Buckets weiterleiten. Dazu verwendet die URL-Zuordnung die Teile Hostname und Pfad für jede von ihr verarbeitete URL:
- Ein Hostname ist der Domainnamen-Abschnitt einer URL. Der Hostname der URL
http://example.net/video/hd
ist beispielsweiseexample.net
. - Ein Pfad ist der Teil einer URL, der auf den Hostnamen und die optionale Portnummer folgt. Der Pfadteil der URL
http://example.net/video/hd
ist beispielsweise/video/hd
.
Dieses Diagramm zeigt die Struktur der Load-Balancing-Konfigurationsobjekte, sodass Sie erkennen können, wie sie zueinander in Beziehung stehen.
Mit den folgenden Konfigurationsparametern der URL-Zuordnung steuern Sie, welche Backend-Diensteoder Backend-Buckets eingehende Anfragen erhalten:
- Standard-Backend-Dienst oder Standard-Backend-Bucket. Wenn Sie eine URL-Zuordnung erstellen, müssen Sie entweder einen Standard-Backend-Dienst oder einen Standard-Backend-Bucket angeben, aber nicht beides. Diese Standardeinstellung stellt den Backend-Dienst oder Backend-Bucket dar, an den Google Cloud Anfragen für URLs mit beliebigem Hostnamen weiterleitet, sofern keine entsprechende Hostregel vorhanden ist.
Hostregel (
hostRules
). Eine Hostregel leitet Anfragen, die an einen oder mehrere verknüpfte Hostnamen gesendet werden, an einen einzelnen Pfad-Matcher (pathMatchers
) weiter. Der Hostname einer URL wird genau mit der Gruppe der konfigurierten Hostnamen der Hostregel abgeglichen. Wenn Sie in einer URL-Zuordnungs-Host- und -Pfadregel den Host weglassen, entspricht die Regel jedem angeforderten Host. Um Anfragen fürhttp://example.net/video/hd
an einen Pfad-Matcher weiterzuleiten, benötigen Sie eine einzelne Hostregel, die mindestens den Hostnamenexample.net
enthält. Diese Hostregel könnte auch Anfragen für andere Hostnamen verarbeiten, sie würde sie jedoch zum selben Pfad-Matcher weiterleiten.Wenn Sie Anfragen an verschiedene Pfad-Matcher weiterleiten müssen, müssen Sie andere Hostregeln verwenden. Zwei Hostregeln in einer URL-Zuordnung dürfen nicht denselben Hostnamen enthalten.
Es ist möglich, alle Hostnamen durch Angabe des Platzhalterzeichens
*
in der Hostregel abzugleichen. Für die URLshttp://example.org
,http://example.net/video/hd
undhttp://example.com/audio
können alle drei Hostnamenexample.org
,example.net
, undexample.com
durch Angabe von*
in der Hostregel angeglichen werden. Es ist auch möglich, einen Teil des Hostnamens mit dem Platzhalterzeichen*
abzugleichen. Beispiel: Eine Hostregel*.example.net
wird mit den beiden Hostnamennews.example.net
undfinance.example.net
abgeglichen.- Portnummer Verschiedene Application Load Balancer verarbeiten Portnummern unterschiedlich. Beim internen Application Load Balancer können Sie mit dem Parameter Hostregel eine Portnummer angeben. Wenn Sie beispielsweise
example.net
-Anfragen an Port 8080 weiterleiten möchten, setzen Sie die Hostregel aufexample.net:8080
. Beim klassischen Application Load Balancer wird nur der Hostname in der URL beim Abgleich mit einer Hostregel berücksichtigt. Beispielsweise entsprechenexample.net
-Anfragen für Port 8080 und Port 80 der Hostregelexample.net
.
- Portnummer Verschiedene Application Load Balancer verarbeiten Portnummern unterschiedlich. Beim internen Application Load Balancer können Sie mit dem Parameter Hostregel eine Portnummer angeben. Wenn Sie beispielsweise
Pfad-Matcher (
pathMatchers
). Ein Pfad-Matcher ist der Konfigurationsparameter, auf den eine Hostregel verweist. Er definiert die Beziehung zwischen dem Pfadteil einer URL und dem Backend-Dienst oder Backend-Bucket , der die Anfrage liefern soll. Ein Pfad-Matcher besteht aus zwei Elementen:Standard-Backend-Dienst für Pfad-Matcher oder Standard-Backend-Bucket für Pfad-Matcher. Für jeden Pfad-Matcher müssen Sie mindestens einen Standard-Backend-Dienst oder einen Standard-Backend-Bucket angeben, aber nicht beides. Diese Standardeinstellung stellt den Backend-Dienst oder Backend-Bucket dar, an den Google Cloud Anfragen für URLs weiterleitet, deren Hostnamen mit einer Hostregel für den Pfad-Matcher übereinstimmen und deren URL-Pfade keiner Pfadregel im Pfad-Matcher entsprechen.
Pfadregeln. Für jeden Pfad-Matcher können Sie eine oder mehrere Pfadregeln angeben, bei denen es sich um Schlüssel/Wert-Paare handelt, die einen URL-Pfad einem einzelnen Backend-Dienst oder Backend-Bucketzuordnen. Der nächste Abschnitt enthält weitere Informationen zur Funktionsweise von Pfadregeln.
Reihenfolge von Vorgängen
Für einen bestimmten Hostnamen und -pfad in einer angeforderten URL verwendet Google Cloud das folgende Verfahren, um die Anfrage an den richtigen Backend-Dienstoder Backend-Bucketso weiterzuleiten, wie es in Ihrer URL-Zuordnung konfiguriert ist:
Wenn die URL-Zuordnung keine Hostregel für den Hostnamen der URL enthält, leitet Google Cloud Anfragen an den Standard-Backend-Dienstder URL-Zuordnung oder an den Standard-Backend-Bucketweiter, je nachdem, welchen Sie definiert haben.
Wenn die URL-Zuordnung eine Hostregel mit dem Hostnamen der URL enthält, wird der Pfad-Matcher, auf den sich diese Hostregel bezieht, verwendet:
Wenn der Pfad-Matcher eine Pfadregel enthält, die genau mit dem URL-Pfad übereinstimmt, leitet Google Cloud Anfragen an den Backend-Dienst oder den Backend-Bucket für diese Pfadregel weiter.
Wenn der Pfad-Matcher keine Pfadregel enthält, die genau dem URL-Pfad entspricht, aber eine Pfadregel enthält, die auf
/*
endet und deren Präfix dem längsten Abschnitt des URL-Pfads entspricht, leitet Google Cloud Anfragen an den Backend-Dienst oder Backend-Bucket für diese Pfadregel weiter. Für die URL-Zuordnung mit den beiden Pfad-Matcher-Regeln/video/hd/movie1
und/video/hd/*
wird beispielsweise die URL mit der Pfadregel/video/hd/movie1
abgeglichen, wenn sie genau diesen Pfad enthält.Wenn keine der vorherigen Bedingungen zutrifft, leitet Google Cloud Anfragen an den Standard-Backend-Dienst oder den Standard-Backend-Bucketdes Pfad-Matchers weiter, je nachdem, welchen Sie definiert haben.
Pfad-Matcher-Einschränkungen
Für Hostnamen, Pfad-Matcher und Pfadregeln gelten Einschränkungen.
Platzhalter, reguläre Ausdrücke und dynamische URLs in Pfadregeln
Eine Pfadregel kann nur ein Platzhalterzeichen (
*
) hinter einem Schrägstrich (/
) enthalten. Zum Beispiel gelten/videos/*
und/videos/hd/*
für Pfadregeln,/videos*
und/videos/hd*
hingegen nicht.Pfadregeln verwenden keine regulären Ausdrücke oder Teilstringabgleiche. PathTemplateMatch kann vereinfachte Operatoren zum Pfadabgleich verwenden. Beispielsweise gelten Pfadregeln für
/videos/hd
oder/videos/hd/*
nicht für eine URL mit dem Pfad/video/hd-abcd
. Für diesen Pfad gilt jedoch eine Pfadregel für/video/*
.Pfad-Matcher und generell URL-Zuordnungen bieten keine Features, die wie
LocationMatch
-Anweisungen von Apache funktionieren. Wenn Ihre Anwendung dynamische URL-Pfade mit einem gemeinsamen Präfix wie/videos/hd-abcd
und/videos/hd-pqrs
generiert und Sie Anfragen an diese Pfade an verschiedene Backend-Dienste senden müssen, ist dies mit einer URL-Zuordnung vielleicht nicht möglich. In Fällen, in denen nur wenige dynamische URLs möglich sind, können Sie eventuell einen Pfad-Matcher mit einem begrenzten Satz von Pfadregeln erstellen. Bei komplexeren Fällen müssen Sie einen pfadbasierten Abgleich regulärer Ausdrücke auf Ihren Back-Ends durchführen.
Platzhalter und Musterabgleichsoperatoren in Pfadvorlagen für Routingregeln
Mit den Operatoren für den flexiblen Musterabgleich können Sie mithilfe einer Platzhaltersyntax mehrere Teile eines URL-Pfads abgleichen, einschließlich partieller URLs und Suffixe (Dateiendungen). Diese Operatoren können hilfreich sein, wenn Sie Traffic weiterleiten und Umschreibungen basierend auf komplexen URL-Pfaden ausführen müssen. Sie können auch eine oder mehrere Pfadkomponenten mit benannten Variablen verknüpfen und dann beim Umschreiben der URL auf diese Variablen verweisen. Mit benannten Variablen können Sie die URL-Komponenten neu anordnen und entfernen, bevor die Anfrage an den Ursprung gesendet wird.
Der Musterabgleich mit Platzhaltern wird nur für die folgenden Produkte unterstützt:
- Globaler externer Application Load Balancer
- Regionaler externer Application Load Balancer
- Regionaler interner Application Load Balancer
- Regionsübergreifender interner Application Load Balancer
- Traffic Director
Im folgenden Beispiel wird der Traffic für eine E-Commerce-Anwendung mit separaten Diensten für Einkaufswageninformationen und Nutzerinformationen weitergeleitet.
Sie können routeRules
mit flexiblen Musterabgleichsoperatoren und benannten Variablen konfigurieren, um die eindeutige ID des Nutzers an die Seite mit den Details zum Nutzerkonto und die Einkaufswageninformationen des Nutzers nach dem Umschreiben der URL an einen Einkaufswagenverarbeitungsdienst zu senden.
pathMatchers:
- name: cart-matcher
routeRules:
- description: CartService
matchRules:
- pathTemplateMatch: '/xyzwebservices/v2/xyz/users/{username=*}/carts/{cartid=**}'
service: cart-backend
priority: 1
routeAction:
urlRewrite:
pathTemplateRewrite: '/{username}-{cartid}/'
- name: user-matcher
routeRules:
- description: UserService
matchRules:
- pathTemplateMatch: '/xyzwebservices/v2/xyz/users/*/accountinfo/*'
service: user-backend
priority: 1
Wenn ein Client /xyzwebservices/v2/xyz/users/[email protected]/carts/FL0001090004/entries/SJFI38u3401nms?fields=FULL&client_type=WEB
anfordert, das sowohl Nutzerinformationen als auch Einkaufswageninformationen enthält, geschieht Folgendes:
- Der Anfragepfad entspricht dem
pathTemplateMatch
im Pfadabgleich voncart-matcher
. Die Variable{username=*}
entspricht[email protected]
und die Variable{cartid=**}
stimmt mitFL0001090004/entries/SJFI38u3401nms
überein. - Die Abfrageparameter werden vom Pfad getrennt, der Pfad wird basierend auf
pathTemplateRewrite
umgeschrieben und die Abfrageparameter werden an den umgeschriebenen Pfad angehängt. Sie dürfen nur dieselben Variablen verwenden, die wir zum Definieren vonpathTemplateMatch
in unserempathTemplateRewrite
verwendet haben. - Die umgeschriebene Anfrage wird mit dem umgeschriebenen URL-Pfad
/[email protected]/entries/SJFI38u3401nms?fields=FULL&client_type=WEB
ancart-backend
gesendet.
Folgendes geschieht, wenn ein Client stattdessen /xyzwebservices/v2/xyz/users/abc%40xyz.com/accountinfo/abc-1234
anfordert, das nur Nutzer- und Kontoinformationen enthält:
- Der Anfragepfad entspricht dem
pathTemplateMatch
im Pfadabgleich vonuser-matcher
. Der erste*
entsprichtabc%40xyz.com
und der zweite*
dem Wertabc-1234
. - Die Anfrage wird an
user-backend
gesendet.
In folgender Tabelle wird die Syntax für Pfadvorlagenmuster beschrieben.
Operator | Stimmt überein mit |
---|---|
* |
Einzelnem Pfadsegment ohne die Trennzeichen des Pfads / . |
** |
Null oder mehreren Zeichen, einschließlich aller Pfadtrennzeichen / zwischen mehreren Pfadsegmenten. Wenn andere Operatoren enthalten sind, muss der Operator ** der letzte Operator sein. |
{name} oder {name=*} |
Benannter Variable, die einem Pfadsegment entspricht. Entspricht einem einzelnen Pfadsegment, ohne das Trennzeichen / für den umgebenden Pfad. |
{name=news/*} |
Benannter Variable, die explizit zwei Pfadsegmenten entspricht: news und ein Platzhaltersegment * . |
{name=*/news/*} |
Benannter Variable, die drei Pfadsegmenten entspricht. |
{name=**} |
Benannter Variable, die null oder mehr Zeichen entspricht. Falls vorhanden, muss es sich um den letzten Operator handeln. |
Wenn Sie diese Operatoren für den flexiblen Musterabgleich verwenden, sollten Sie Folgendes beachten:
- In einem Muster können mehrere Operatoren kombiniert werden.
- Abfrageparameter werden vom Pfad getrennt, der Pfad wird basierend auf
pathTemplateRewrite
umgeschrieben und die Abfrageparameter werden an den umgeschriebenen Pfad angehängt. - Anfragen werden nicht mit Prozentcodierung normalisiert. Eine URL mit einem prozentcodierten Schrägstrich (%2F) wird beispielsweise nicht in die nicht codierte Form decodiert.
- Jeder Variablenname wie
{segment}
oder{region}
kann im selben Muster nur einmal vorkommen. Mehrere Variablen mit demselben Namen sind ungültig und werden abgelehnt. - Bei Variablennamen wird zwischen Groß- und Kleinschreibung unterschieden und sie müssen gültige Kennzeichnungen sein. Prüfen Sie, ob der Variablenname gültig ist. Er muss mit dem regulären Ausdruck
^[a-zA-Z][a-zA-Z0-9_]*$
übereinstimmen.{API}
,{api}
und{api_v1}
sind gültige Kennungen. Sie identifizieren drei verschiedene Variablen.{1}
,{_api}
und{10alpha}
sind keine gültigen Kennzeichnungen.
- Pro Vorlagenmuster sind maximal fünf Operatoren zulässig.
Wenn Sie eine optionale URL-Umschreibung ausführen möchten, bevor die Anfrage an den Ursprung gesendet wird, können Sie dieselben Variablen verwenden, die Sie zum Erfassen eines Pfades definiert haben.
Sie können beispielsweise im Feld pathTemplateRewrite
auf Variablen verweisen, sie neu anordnen oder weglassen, wenn Sie urlRewrite
definieren.
Wenn Sie Variablen und Operatoren für den flexiblen Musterabgleich für URL-Umschreibungen verwenden, beachten Sie Folgendes:
- Beim Umschreiben einer URL können Sie Variablen weglassen, wenn sie für die umgeschriebene URL nicht erforderlich sind.
- Vor Umschreibungen können Sie die URL identifizieren, die vom Client an Ihrem Ursprung gesendet wurde. Untersuchen Sie dazu die Antwortheader. Die ursprüngliche Client-URL wird mit den Headern
x-client-request-url
undx-envoy-original-path
gefüllt.
Beziehung zwischen Hostname und Hostregel
Ein Hostname kann nur auf eine einzelne Hostregel verweisen.
Eine einzelne Hostregel kann mehrere Hostnamen verarbeiten.
Beziehung zwischen Hostregel und Pfad-Matcher
Mehrere Hostregeln können auf einen einzelnen Pfad-Matcher verweisen.
Eine Hostregel kann nur auf einen einzelnen Pfad-Matcher verweisen.
Das folgende Diagramm veranschaulicht diese Punkte.
Beziehung zwischen URL und Backend
Jede eindeutige URL wird nur an einen einzelnen Backend-Dienst oder Backend-Bucketweitergeleitet: Dies hat folgende Konsequenzen:
Google Cloud verwendet den Hostnamen einer URL, um eine einzelne Hostregel und den zugehörigen Pfad-Matcher auszuwählen.
Wenn Sie Pfadregeln in einem Pfad-Matcher verwenden, können Sie jeweils nur eine Pfadregel für denselben Pfad erstellen. Anfragen für
/videos/hd
können beispielsweise jeweils nur an einen Backend-Dienst oder Backend-Bucketgerichtet werden. Backend-Dienste können Backend-Instanzgruppen oder Backend-Netzwerk-Endpunktgruppen (NEGs) in verschiedenen Zonen und Regionenhaben. Sie können auch Backend-Buckets mit Multi-Regional Storage erstellen.Um Traffic für eine eindeutige URL an mehrere Dienste weiterzuleiten, können Sie Routingregeln anstelle von Pfadregeln verwenden. Wenn Sie den Pfad-Matcher mit Routingregeln für Header- oder Parameterübereinstimmungen konfigurieren, kann eine eindeutige URL basierend auf dem Inhalt der Header oder Abfrageparameter an mehrere Backend-Dienste oder Backend-Bucketsin der URL weitergeleitet werden.
Ebenso können bei regionalen Application Load Balancern und Traffic Directorgewichtete Backend-Dienste für Routingaktionen dieselbe URL an mehrere Backend-Dienste oder Backend-Bucketsweiterleiten, abhängig von den Gewichtungen, die für den gewichteten Backend-Dienst festgelegt sind.
URL-Zuordnungen und -Protokolle
Sie können dieselbe URL-Zuordnung, Hostregeln und Pfadabgleiche verwenden, um sowohl HTTP- als auch HTTPS-Anfragen von Clients zu verarbeiten, solange sowohl ein Ziel-HTTP-Proxy als auch ein Ziel-HTTPS-Proxy auf die URL-Zuordnung verweisen.
Einfachste URL-Zuordnung
Die einfachste URL-Zuordnung hat nur einen Standard-Backend-Dienst oder einen Standard-Backend-Bucket. Sie enthält keine Hostregeln und keine Pfad-Matcher. Alle angeforderten URLs werden entweder vom Standard-Backend-Dienst oder vom Standard-Backend-Bucket verarbeitet, je nachdem, welchen Sie definiert haben.
Wenn Sie einen Standard-Backend-Dienst definieren, leitet Google Cloud Anfragen an die Backend-Instanzgruppen oder Backend-Netzwerk-Endpunktgruppen (NEGs) gemäß der Konfiguration des Backend-Dienstes weiter.
Beispiel für einen URL-Zuordnungsworkflow mit einem externen Application Load Balancer
Das folgende Beispiel zeigt die Reihenfolge der Vorgänge für eine URL-Zuordnung. In diesem Beispiel wird nur die URL-Zuordnung für einen vorhandenen klassischen Application Load Balancer konfiguriert. Zur Vereinfachung des Konzepts werden nur Backend-Dienste verwendet. Sie können sie jedoch stattdessen durch Backend-Buckets ersetzen. Informationen zum Erstellen der anderen Komponenten des Load Balancers finden Sie unter Klassischen Application Load Balancer erstellen.
Weitere Informationen zum Erstellen und Konfigurieren von URL-Zuordnungen mit Pfad-Matchern und Hostregeln finden Sie in der Dokumentation zu gcloud compute url-maps create
.
Erstellen Sie eine URL-Zuordnung für den Load Balancer und geben Sie einen Standard-Backend-Dienst an. In diesem Beispiel wird eine URL-Zuordnung mit dem Namen
video-org-url-map
erstellt, die auf einen vorhandenen Backend-Dienst namensorg-site
verweist.gcloud compute url-maps create video-org-url-map \ --default-service=org-site
Erstellen Sie einen Pfadabgleich namens
video-matcher
mit den folgenden Merkmalen:- Der Standard-Backend-Dienst ist
video-site
, ein bereits vorhandener Backend-Dienst. - Fügen Sie Pfadregeln hinzu, die Anfragen für den exakten URL-Pfad
/video/hd
oder das URL-Pfadpräfix/video/hd/*
an einen vorhandenen Backend-Dienst mit dem Namenvideo-hd
weiterleiten. - Fügen Sie Pfadregeln hinzu, die Anfragen für den exakten URL-Pfad
/video/sd
oder das URL-Pfadpräfix/video/sd/*
an einen vorhandenen Backend-Dienst mit dem Namenvideo-sd
weiterleiten.
gcloud compute url-maps add-path-matcher video-org-url-map \ --path-matcher-name=video-matcher \ --default-service=video-site \ --path-rules=/video/hd=video-hd,/video/hd/*=video-hd,/video/sd=video-sd,/video/sd/*=video-sd
- Der Standard-Backend-Dienst ist
Erstellen Sie eine Hostregel für den
example.net
-Hostnamen, der auf denvideo-matcher
-Pfad-Matcher verweist.gcloud compute url-maps add-host-rule video-org-url-map \ --hosts=example.net \ --path-matcher-name=video-matcher
Die video-org-url-map
-URL-Zuordnung sollte so aussehen:
gcloud compute url-maps describe video-org-url-map
creationTimestamp: '2021-03-05T13:34:15.833-08:00' defaultService: https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/backendServices/org-site fingerprint: mfyJIT7Zurs= hostRules: - hosts: - '*' pathMatcher: video-matcher - hosts: - example.net pathMatcher: video-matcher id: '8886405179645041976' kind: compute#urlMap name: video-org-url-map pathMatchers: - defaultService: https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/backendServices/video-site name: video-matcher pathRules: - paths: - /video/hd - /video/hd/* service: https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/backendServices/video-hd - paths: - /video/sd - /video/sd/* service: https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/backendServices/video-sd selfLink: https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/urlMaps/video-org-url-map
Die video-org-url-map
-URL-Zuordnung leitet angeforderte URLs folgendermaßen an Back-Ends weiter:
In der folgenden Tabelle wird die Anfrageverarbeitung im vorherigen Diagramm erläutert.
Hostname | URL-Pfade | Ausgewählter Backend-Dienst | Grund für die Auswahl |
---|---|---|---|
Hostname: example.org und alle anderen Hostnamen, die sich vom folgendenunterscheiden example.net : |
Alle Pfade | org-site |
Der Hostname befindet sich in keiner Hostregel der URL-Zuordnung. Daher wird die Anfrage an den Standard-Backend-Dienst der URL-Zuordnung weitergeleitet. |
Hostname:example.net |
/video /video/examples |
video-site |
Die Anfrage wird an den Standard-Backend-Dienst gesendet, da keine Pfadregel für /video/ oder /video/* vorliegt. Die Hostregel für example.net verweist auf einen Pfad-Matcher, der aber über keine Pfadregeln verfügt, die für diese Pfade gelten würden.
|
Hostname:example.net |
/video/hd /video/hd/movie1 /video/hd/movies/movie2 Andere URLs, die mit /video/hd/* beginnen |
video-hd |
Eine Hostregel für example.net verweist auf einen Pfad-Matcher, dessen Pfadregeln Anfragen für URL-Pfade, die genau mit /video/hd übereinstimmen oder mit /video/hd/* beginnen, an den Backend-Dienst video-hd weiterleiten. |
Hostname:example.net |
/video/sd /video/sd/show1 /video/sd/shows/show2 Andere URLs, die mit /video/sd/* beginnen |
video-sd |
Eine Hostregel für example.net verweist auf einen Pfad-Matcher, dessen Pfadregeln Anfragen für URL-Pfade, die genau mit /video/sd übereinstimmen oder mit /video/sd/* beginnen, an den Backend-Dienst video-sd weiterleiten. |
URL-Weiterleitungen
Eine URL-Weiterleitung leitet die Besucher Ihrer Domain von einer URL zu einer anderen weiter.
Eine Standard-URL-Weiterleitung wird bei der Übereinstimmung mit einem bestimmten Muster in der eingehenden Anfrage nicht konditioniert. Sie können beispielsweise eine Standard-URL-Weiterleitung verwenden, um beliebige Hostnamen an einen Hostnamen Ihrer Wahl weiterzuleiten.
Es gibt mehrere Möglichkeiten, eine URL-Weiterleitung zu erstellen, wie in der folgenden Tabelle dargestellt.
Methode | Konfiguration |
---|---|
Standard-URL-Weiterleitung der URL-Zuordnung | Toplevel defaultUrlRedirect |
Standard-URL-Weiterleitung eines Pfad-Matchers | pathMatchers[].defaultUrlRedirect[] |
URL-Weiterleitung einer Pfad-Matcher-Pfadregel | pathMatchers[].pathRules[].urlRedirect |
URL-Weiterleitung einer Pfad-Matcher-Routingregel | pathMatchers[].routeRules[].urlRedirect |
Innerhalb eines defaultUrlRedirect
oder urlRedirect
funktioniert pathRedirect
immer so:
- Der gesamte Anfragepfad wird durch den von Ihnen angegebenen Pfad ersetzt.
Die Funktionsweise von prefixRedirect
hängt davon ab, wie sie in defaultUrlRedirect
oder urlRedirect
verwenden:
- Wenn Sie eine
defaultUrlRedirect
verwenden, istprefixRedirect
effektiv ein Präfix, da der übereinstimmende Pfad immer/
ist. - Wenn Sie eine
urlRedirect
in der Routingregel oder einer Pfadregel eines Pfad-Matchers verwenden, istprefixRedirect
eine Präfix-Ersetzung, die darauf basiert, wie der angeforderte Pfad gemäß der Definition in der Pfadregel oder Routingregel abgeglichen wurde.
Beispiele für Weiterleitungen
Die folgende Tabelle enthält einige Beispiele für Weiterleitungskonfigurationen. In der rechten Spalte sehen Sie die API-Konfiguration für eine Standard-URL-Weiterleitung.
Sie wollen | Über eine Standard-URL-Weiterleitung |
---|---|
HTTP-zu-HTTPS-Weiterleitung Weiterleitung http://host.name/path zu https://host.name/path |
kind: compute#urlMap name: web-map-http defaultUrlRedirect: httpsRedirect: True |
HTTP-zu-HTTPS- und Host-Weiterleitung Weiterleitung http://any-host-name/path zu https://www.example.com/path |
kind: compute#urlMap name: web-map-http defaultUrlRedirect: httpsRedirect: True hostRedirect: "www.example.com" |
HTTP-zu-HTTPS- und Host-Weiterleitung + vollständige Pfadweiterleitung Weiterleitung http://any-host-name/path zu https://www.example.com/newPath |
kind: compute#urlMap name: web-map-http defaultUrlRedirect: httpsRedirect: True hostRedirect: "www.example.com" pathRedirect: "/newPath" |
HTTP-zu-HTTPS- und Host-Weiterleitung + Präfix-Weiterleitung Weiterleitung http://any-host-name/originalPath zu https://www.example.com/newPrefix/originalPath |
kind: compute#urlMap name: web-map-http defaultUrlRedirect: httpsRedirect: True hostRedirect: "www.example.com" prefixRedirect: "/newPrefix" |
Im folgenden Teil-Snippet wird jede API-Ressource mit Annotationen versehen.
defaultUrlRedirect: redirectResponseCode: MOVED_PERMANENTLY_DEFAULT httpsRedirect: True # True if you want https://, false if you want http:// hostRedirect: "new-host-name.com" # Omit to keep the requested host pathRedirect: "/new-path" # Omit to keep the requested path; mutually exclusive to prefixRedirect prefixRedirect: "/newPrefix" # Omit to keep the requested path; mutually exclusive to pathRedirect stripQuery: False # True to omit everything in the URL after ? ...
Nächste Schritte
Informationen zum Hinzufügen, Validieren, Testen, Auflisten oder Löschen einer URL-Zuordnung finden Sie unter URL-Zuordnungen verwenden.
Informationen zu Routingregelzuordnungen mit Traffic Director finden Sie unter Übersicht über die Traffic Director-Routingregelzuordnungen.