Übersicht über URL-Zuordnungen

Application Load Balancer von Google Cloud und Traffic Director verwenden eine Google Cloud-Konfigurationsressource, die als URL-Zuordnung bezeichnet wird, um HTTP(S)-Anfragen an Backend-Dienste oder 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 Back-End-Dienst oder einen Back-End-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).

Anfragen sollen so gestellt werden:

Anfragen an example.org (oder eine andere Domain als example.net), um zum Backend-Dienst org-site zu gelangen.
Anfragen an example.net, die nicht mit spezifischeren Pfaden übereinstimmen, um zum video-site-Backend-Dienst zu gelangen.
Anfragen an example.net/video/hd/*, um zum Backend-Dienst video-hd zu gelangen.
Anfragen an example.net/video/sd/*, um zum Backend-Dienst video-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.

Beispiel für die Einrichtung eines Backend-Dienstes (zum Vergrößern anklicken)

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 Back-End-Dienste oder Back-End-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 beispielsweise example.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.

Konfiguration des Load-Balancers mit grundlegendem Ablauf der URL-Zuordnung. — Konfiguration des Load-Balancers mit grundlegendem Ablauf der URL-Zuordnung (zum Vergrößern klicken)

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-Dienste oder 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.

Hinweis: Backend-Buckets werden mit internen Application Load Balancern und Traffic Director nicht unterstützt.
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ür http://example.net/video/hd an einen Pfad-Matcher weiterzuleiten, benötigen Sie eine einzelne Hostregel, die mindestens den Hostnamen example.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 URLs http://example.org, http://example.net/video/hd und http://example.com/audio können alle drei Hostnamen example.org, example.net, und example.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 Hostnamen news.example.net und finance.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 auf example.net:8080. Beim klassischen Application Load Balancer wird nur der Hostname in der URL berücksichtigt, wenn eine Hostregel abgeglichen wird. Beispielsweise entsprechen example.net-Anfragen für Port 8080 und Port 80 der Hostregel example.net.
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-Bucket zuordnen. 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-Dienst oder Backend-Bucket so 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-Dienst der URL-Zuordnung oder an den Standard-Backend-Bucket weiter, 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-Pfades 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-Bucket des 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/abc@xyz.com/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 von cart-matcher. Die Variable {username=*} entspricht abc@xyz.com und die Variable {cartid=**} stimmt mit FL0001090004/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 von pathTemplateMatch in unserem pathTemplateRewrite verwendet haben.
Die umgeschriebene Anfrage wird mit dem umgeschriebenen URL-Pfad /abc@xyz.com-FL0001090004/entries/SJFI38u3401nms?fields=FULL&client_type=WEB an cart-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 von user-matcher. Der erste * entspricht abc%40xyz.com und der zweite * dem Wert abc-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 und x-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.

Die Beziehung zwischen Hostnamen und Hostregeln. — Die Beziehung zwischen Hostnamen und Hostregeln (zum Vergrößern anklicken).

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.

Die Beziehung zwischen Hostregeln und Pfad-Matchern. — Die Beziehung zwischen Hostregeln und Pfad-Matchern (zum Vergrößern klicken)

Beziehung zwischen URL und Backend

Jede eindeutige URL wird nur an einen einzelnen Backend-Dienst oder Backend-Bucket weitergeleitet: 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-Bucket gerichtet werden. Backend-Dienste können Backend-Instanzgruppen oder Backend-Netzwerk-Endpunktgruppen (NEGs) in verschiedenen Zonen und Regionen haben. Sie können auch Backend-Buckets mit multiregionalen Storage-Klassen 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 -Buckets in der URL weitergeleitet werden.

Ebenso können bei regionalen Application Load Balancern und Traffic Director gewichtete Backend-Dienste für Routingaktionen dieselbe URL an mehrere Backend-Dienste oder -Buckets weiterleiten, 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.

URL-Zuordnung ohne Regeln, außer der Standardeinstellung (zum Vergrößern anklicken)

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 namens org-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 Namen video-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 Namen video-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
```

Erstellen Sie eine Hostregel für den example.net-Hostnamen, der auf den video-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:

URL-Zuordnung mit einer Pfadregel, Pfad-Matchern und einer Hostregel (zum Vergrößern anklicken)

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 folgenden unterscheiden `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, ist prefixRedirect effektiv ein Präfix, da der übereinstimmende Pfad immer / ist.
Wenn Sie eine urlRedirect in der Routingregel oder einer Pfadregel eines Pfad-Matchers verwenden, ist prefixRedirect 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.