Übersicht über URL-Zuordnungen

HTTP(S)-Load-Balancer von Google Cloud und Traffic Director verwenden eine Google Cloud-Konfigurationsressource, die als URL-Zuordnung bezeichnet wird, um Anfragen an Back-End-Dienste oder Back-End-Buckets weiterzuleiten.

Mit einem externen HTTP(S)-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 Back-End-Dienst.
  • Anfragen für https://example.com/audio gehen an einen anderen Back-End-Dienst.
  • Anfragen für https://example.com/images werden an einen Cloud Storage-Back-End-Bucket gesendet.
  • Anfragen für andere Host- und Pfadkombinationen werden an einen Standard-Back-End-Dienst gesendet.

URL-Zuordnungen werden bei den folgenden Google Cloud-Produkten verwendet:

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
Regionaler externer HTTP(S)-Load-Balancer EXTERNAL_MANAGED Regional, extern Back-End-Dienste
Externer HTTP(S)-Load-Balancer EXTERNAL Global, extern Back-End-Dienste, Back-End-Buckets
Interner HTTP(S)-Load-Balancer INTERNAL_MANAGED Regional, intern Back-End-Dienste
Traffic Director INTERNAL_SELF_MANAGED Global, intern Back-End-Dienste

Nicht alle Features zur URL-Zuordnung sind für alle Produkte verfügbar. URL-Zuordnungen, die mit regionalen externen HTTP(S)-Load-Balancern, internen HTTP(S)-Load-Balancern und Traffic Director verwendet werden, unterstützen ebenfalls mehrere erweiterte Features zur Trafficverwaltung. Weitere Informationen zu diesen Unterschieden finden Sie unter Erweiterte Trafficverwaltung.

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 Back-End-Dienst stellt eine Sammlung von Back-Ends dar, bei denen es sich um Instanzen einer Anwendung oder eines Mikrodienstes handelt. Ein Back-End-Bucket ist ein Google Cloud Storage-Bucket, der häufig zum Hosten statischer Inhalte wie Bilder verwendet wird.

Für externe HTTP(S)-Load-Balancer, interne HTTP(S)-Load-Balancer und Traffic Director sind folgende Ziele möglich:

Darüber hinaus unterstützt ein externer HTTP(S)-Load-Balancer Folgendes:

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 Back-End-Dienste weitergeleitet.
  • Zwei Domains:
    • example.net hostet Schulungsvideos.
    • example.org hostet die Website Ihrer Organisation.
  • Vier Server:
    • Einer hostet die Website Ihrer Organisation (Back-End-Dienst: org-site).
    • In einem wird die gesamte Schulungsvideo-Website gehostet (Back-End-Dienst: video-site).
    • In einem werden HD-Schulungsvideos gehostet (Back-End-Dienst: video-hd).
    • Einer hostet Schulungsvideos mit Standard Definition (SD) (Back-End-Dienst: video-sd).

Anfragen sollen so gestellt werden:

  • Anfragen an example.org (oder eine andere Domain als example.net), um zum Back-End-Dienst org-site zu gelangen.
  • Anfragen an example.net, die nicht mit spezifischeren Pfaden übereinstimmen, um zum video-site-Back-End-Dienst zu gelangen.
  • Anfragen an example.net/video/hd/*, um zum Back-End-Dienst video-hd zu gelangen.
  • Anfragen an example.net/video/sd/*, um zum Back-End-Dienst video-sd zu gelangen.

Ein --path-rule für /video/* stimmt mit URIs wie /video/test1, /video/test2 und so weiter überein. Diese Pfadregel stimmt jedoch nicht mit dem Pfad /video überein.

Wenn der Load-Balancer eine Anfrage mit /../ in der URL empfängt, antwortet er mit einer 302-Weiterleitung. Wenn beispielsweise die Anfrage für http://example.net/video/../abc gesendet wird, konvertiert der Load-Balancer diese Anfrage in http://example.net/abc und verarbeitet sie entsprechend der URL-Zuordnungskonfiguration. 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 Back-End-Dienstes (zum Vergrößern anklicken)
Beispiel für die Einrichtung eines Back-End-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 stimmt mit dem Namen des Load-Balancers überein. Wenn Sie das gcloud-Befehlszeilentool 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 (zum Vergrößern klicken)
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 Back-End-Dienste oder Back-End-Buckets eingehende Anfragen erhalten:

  • Standard-Back-End-Dienst oder Standard-Back-End-Bucket. Wenn Sie eine URL-Zuordnung erstellen, müssen Sie entweder einen Standard-Back-End-Dienst oder einen Standard-Back-End-Bucket angeben, aber nicht beides. Diese Standardeinstellung stellt den Back-End-Dienst oder Back-End-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ü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 partiellen Hostnamen mit dem Platzhalterzeichen * abzugleichen. Beispiel: eine Hostregel *.example.net wird mit den beiden Hostnamen foo.example.net und bar.example.net abgeglichen.

    • Portnummer Sie können auch den Parameter Hostregel verwenden, um eine Portnummer anzugeben. Wenn Sie beispielsweise example.net-Anfragen an Port 8080 weiterleiten möchten, setzen Sie die Hostregel auf example.net:8080.
  • 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 Back-End-Dienst oder Back-End-Bucket, der die Anfrage liefern soll. Ein Pfad-Matcher besteht aus zwei Elementen:

    • Standard-Back-End-Dienst für Pfad-Matcher oder Standard-Back-End-Bucket für Pfad-Matcher. Für jeden Pfad-Matcher müssen Sie mindestens einen Standard-Back-End-Dienst oder einen Standard-Back-End-Bucket angeben, aber nicht beides. Diese Standardeinstellung stellt den Back-End-Dienst oder Back-End-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 Back-End-Dienst oder Back-End-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 Back-End-Dienst oder Back-End-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-Back-End-Dienst der URL-Zuordnung oder an den Standard-Back-End-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 Back-End-Dienst oder den Back-End-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 Back-End-Dienst oder Back-End-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-Back-End-Dienst oder den Standard-Back-End-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 keinen regulären Ausdruck oder Teilstringabgleich. 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 Back-End-Dienste senden müssen, ist dies mit einer URL-Zuordnung vielleicht nicht möglich. In einfachen Fällen, in denen nur wenige dynamische URLs möglich sind, können Sie 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.

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 (zum Vergrößern anklicken).
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 (zum Vergrößern klicken).
Die Beziehung zwischen Hostregeln und Pfad-Matchern (zum Vergrößern klicken)

Beziehung zwischen URL und Back-End

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

    Ebenso können bei regionalen HTTP(S)-Load-Balancern und Traffic Director gewichtete Back-End-Dienste für Routingaktionen dieselbe URL an mehrere Back-End-Dienste oder -Buckets weiterleiten, abhängig von den Gewichtungen, die für den gewichteten Back-End-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.

Sie können Weiterleitungen mithilfe von URL-Zuordnungen konfigurieren, wie in den folgenden Anleitungen dargestellt:

Einfachste URL-Zuordnung

Die einfachste URL-Zuordnung hat nur einen Standard-Back-End-Dienst oder einen Standard-Back-End-Bucket. Sie enthält keine Hostregeln und keine Pfad-Matcher. Alle angeforderten URLs werden entweder vom Standard-Back-End-Dienst oder vom Standard-Back-End-Bucket verarbeitet, je nachdem, welchen Sie definiert haben.

Wenn Sie einen Standard-Back-End-Dienst definieren, leitet Google Cloud Anfragen an die Back-End-Instanzgruppen oder Back-End-Netzwerk-Endpunktgruppen (NEGs) gemäß der Konfiguration des Back-End-Dienstes weiter.

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

Beispiel für einen URL-Zuordnungsworkflow mit einem externen HTTP(S)-Load-Balancer

Das folgende Beispiel zeigt die Reihenfolge der Vorgänge für eine URL-Zuordnung. In diesem Beispiel wird die URL-Zuordnung für einen externen HTTP(S)-Load-Balancer konfiguriert. Zur Vereinfachung des Konzepts werden nur Back-End-Dienste verwendet. Sie können sie jedoch stattdessen durch Back-End-Buckets ersetzen. Informationen zum Erstellen der anderen Komponenten des externen HTTP(S)-Load-Balancers finden Sie unter Externen HTTP(S)-Load-Balancer erstellen.

Ein Beispiel für das Erstellen einer URL-Zuordnung eines internen HTTP(S)-Load-Balancers und weiterer Komponenten finden Sie unter Vorbereitung für den Aufbau des internen HTTP(S)-Load-Balancers.

Jeder im folgenden Beispiel beschriebene Back-End-Dienst hat ein externes Schema und verwendet das HTTP-, HTTPS- oder HTTP/2-Protokoll.

  1. Erstellen Sie eine URL-Zuordnung für den Load-Balancer und geben Sie einen Standard-Back-End-Dienst an. In diesem Beispiel wird eine URL-Zuordnung mit dem Namen video-org-url-map erstellt, die auf einen vorhandenen Back-End-Dienst namens org-site verweist.

    gcloud compute url-maps create video-org-url-map \
        --default-service=org-site
    
  2. Erstellen Sie einen Pfadabgleich namens video-matcher mit den folgenden Merkmalen:

    • Der Standard-Back-End-Dienst ist video-site, ein bereits vorhandener Back-End-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 Back-End-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 Back-End-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
    
  3. 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 klicken)
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 Back-End-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-Back-End-Dienst der URL-Zuordnung weitergeleitet.
Hostname:
example.net
/video
/video/examples
video-site Die Anfrage wird an den Standard-Back-End-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 Back-End-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 Back-End-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 Configuration
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 Beispiel wird jede API-Ressource mit Annotationen versehen.

kind: compute#urlMap
name: web-map-http
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 ?
  },
  "defaultUrlRedirect": {
    "redirectResponseCode": enum,
  }

Vollständige End-to-End-Beispiele finden Sie auf den folgenden Seiten:

Erweiterte Trafficverwaltung

Nicht alle Features zur URL-Zuordnung sind für alle Produkte verfügbar. URL-Zuordnungen werden mit regionalen externen HTTP(S)-Load-Balancern, internen HTTP(S)-Load-Balancern und Traffic Director verwendet, um mehrere erweiterte Features zur Trafficverwaltung zu unterstützen, die nicht alle auf externen HTTP(S)-Load-Balancern unterstützt werden.

In der folgenden Tabelle sehen Sie, welche URL-Zuordnungs-Features für jedes Produkt verfügbar sind. Jedes Produkt hat spezielle Themen, die erklären, wie die Trafficverwaltung funktioniert. Außerdem enthält es Beispiel-URL-Zuordnungen für jeden Anwendungsfall.

Produkt Leitfaden für die Funktionen der URL-Zuordnung und der Trafficverwaltung
Externer HTTP(S)-Load-Balancer Load-Balancing-Features: Routing und Trafficverwaltung

Übersicht über die Trafficverwaltung für externe HTTP(S)-Load-Balancer

Regionaler externer HTTP(S)-Load-Balancer Load-Balancing-Features: Routing und Trafficverwaltung

Übersicht über die Trafficverwaltung für regionale externe HTTP(S)-Load-Balancer

Trafficverwaltung für regionale externe HTTP(S)-Load-Balancer einrichten

Interner HTTP(S)-Load-Balancer Load-Balancing-Features: Routing und Trafficverwaltung

Übersicht über die Trafficverwaltung für interne HTTP(S)-Load-Balancer

Trafficverwaltung für interne HTTP(S)-Load-Balancer einrichten

Traffic Director Traffic Director-Features: Routing und Trafficverwaltung

Erweiterte Trafficverwaltung

Erweiterte Trafficverwaltung konfigurieren

Referenz zu API und Cloud SDK

Neben der Cloud Console können Sie die API und das Cloud SDK verwenden, um URL-Zuordnungen zu erstellen.

API

Eine Beschreibung der Attribute und Methoden, die Sie für URL-Zuordnungen über die REST API nutzen können, finden Sie unter:

Produkt API-Dokumentation
Externes HTTP(S)-Load-Balancing urlMaps
Internes HTTP(S)-Load-Balancing regionUrlMaps
Traffic Director urlMaps

Cloud SDK

Informationen zum gcloud-Befehlszeilentool im Cloud SDK finden Sie unter:

Verwenden Sie für eine erweiterte Trafficverwaltung YAML-Dateien und importieren Sie sie mit dem Befehl gcloud compute url-maps import.

Nächste Schritte