Übersicht über URL-Zuordnungen

Google Cloud Application Load Balancer und Cloud Service Mesh verwenden Google Cloudeine Konfigurationsressource namens URL-Zuordnung, 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:

Es gibt zwei Arten von URL-Zuordnungsressourcen: globale und regionale.

  • Globale urlMaps werden von globalen externen Application Load Balancern, klassischen Application Load Balancern, regionenübergreifenden internen Application Load Balancern und Cloud Service Mesh verwendet.

  • regionUrlMaps werden von regionalen externen Application Load Balancern, regionalen internen Application Load Balancern und Cloud Service Mesh verwendet.

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 Backend-Dienste, Backend-Buckets
Klassischer Application Load Balancer EXTERNAL Global Backend-Dienste, Backend-Buckets
Regionaler externer Application Load Balancer EXTERNAL_MANAGED Regional Backend-Dienste
Regionsübergreifender interner Application Load Balancer INTERNAL_MANAGED Global Backend-Dienste
Regionaler interner Application Load Balancer INTERNAL_MANAGED Regional Backend-Dienste
Cloud Service Mesh INTERNAL_SELF_MANAGED Global Backend-Dienste
Cloud Service Mesh INTERNAL_SELF_MANAGED Regional 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 Cloud Service Mesh 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. Außerdem können regionale URL-Zuordnungen eine Ressource sein, die in App Hub-Anwendungen als Dienst festgelegt ist.

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 Cloud Service Mesh sind folgende Ziele möglich:

Darüber hinaus unterstützen globale externe Application 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 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
Beispiel für die Einrichtung eines Backend-Dienstes (zum Vergrößern anklicken)

Load-Balancer benennen

Bei Application Load Balancern ist der Name des Load Balancers immer derselbe wie der Name der URL-Zuordnung. Das Verhalten für jede Google Cloud Schnittstelle ist wie folgt:

  • Google Cloud console. Wenn Sie einen Application Load Balancer über dieGoogle Cloud Console erstellen, wird der URL-Zuordnung automatisch derselbe Name zugewiesen, den Sie für den Namen des Load Balancers eingegeben haben.
  • Google Cloud CLI oder API Wenn Sie einen Application Load Balancer mit der gcloud CLI oder der API erstellen, geben Sie beim Erstellen der URL-Zuordnung einen Namen Ihrer Wahl ein. Dieser Name der URL-Zuordnung wird dann in derGoogle Cloud Console als Name des Load-Balancers angezeigt.

Informationen zur Namensgebung für Proxy-Network-Load-Balancer und Passthrough-Network-Load-Balancer finden Sie unter Übersicht über Backend-Dienste: Load-Balancer-Namensgebung.

URL-Zuordnungskomponenten

Eine URL-Zuordnung ist eine Gruppe von Google Cloud Konfigurationsressourcen, die Anfragen für URLs an Backend-Dienste oder 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 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 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 entweder genau oder mithilfe von regulären Ausdrücken 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 Back-End-Dienst oder Back-End-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 denGoogle 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.

      Mit den Operatoren für den flexiblen Musterabgleich können Sie mithilfe einer Platzhaltersyntax mehrere Teile eines URL-Pfads erfassen, 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. Weitere Informationen finden Sie unter Platzhalter, reguläre Ausdrücke und dynamische URLs in Pfadregeln.

      Wenn Sie erweiterte Routingfunktionen benötigen, z. B. wenn Sie Traffic für eine eindeutige URL an mehrere Dienste weiterleiten möchten, können Sie Routingregeln anstelle von Pfadregeln verwenden.

    • Routingregeln: Routenregeln können als Alternative zu Pfadregeln verwendet werden, wenn Sie erweiterte Funktionen für das Traffic-Routing benötigen, z. B. das Weiterleiten von Traffic basierend auf dem URL-Pfad, HTTP-Headern und Abfrageparametern.

      Sie können Routenregeln mit flexiblen Mustervergleichsoperatoren und benannten Variablen konfigurieren. Diese Operatoren können hilfreich sein, wenn Sie Traffic weiterleiten und Umschreibungen basierend auf komplexen URL-Pfaden ausführen müssen. Weitere Informationen finden Sie unter Platzhalter und Musterabgleichsoperatoren in Pfadvorlagen für Routingregeln.

      Sie können Routenregeln auch so konfigurieren, dass sie mit regulären Ausdrücken abgeglichen werden, die dem Pfad, den Abfrageparametern oder den Headern in der eingehenden Anfrage entsprechen. Weitere Informationen finden Sie unter Reguläre Ausdrücke in Routenregeln.

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.

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. 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 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 -Buckets in der URL weitergeleitet werden.

    Ebenso können bei regionalen Application Load Balancern und Cloud Service Mesh 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-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
URL-Zuordnung ohne Regeln, außer der Standardeinstellung (zum Vergrößern anklicken)

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,Google Cloud werden Anfragen an den Standard-Backend-Dienst der URL-Zuordnung oder an den Standard-Backend-Bucket weitergeleitet, 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, Google Cloud leitet 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-Pfads entspricht, leitet Google CloudAnfragen 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, Google Cloud werden Anfragen an den Standard-Backend-Dienst oder den Standard-Backend-Bucket des Pfad-Matchers weitergeleitet, je nachdem, welchen Sie definiert haben.

Einschränkungen für die Konfiguration von URL-Zuordnungen

In den folgenden Abschnitten werden bestimmte Konfigurationseinschränkungen für Komponenten von URL-Zuordnungen beschrieben.

Matcher für reguläre Ausdrücke in Host- und Routingregeln

Mit Hostregeln können Sie den Hostnamen einer URL mit der Gruppe der konfigurierten Hostnamen der Hostregel abgleichen. Sie können entweder einen bestimmten Hostnamen oder einen Platzhalter * im Feld hostRules[].hosts[] verwenden, der mit dem Hostnamen in der eingehenden Anfrage abgeglichen wird.

Mit Routingregeln können Sie Abgleichsregeln definieren, die einen regulären Ausdruck entweder im Pfad, im Abfragestring oder in einem Header in der eingehenden Anfrage abgleichen können. In Routingregeln können reguläre Ausdrücke für die folgenden URL-Zuordnungsfelder verwendet werden:

  • pathMatchers[].routeRules[].matchRules[].regexMatch: Ein regulärer Ausdruck, der verwendet wird, um den Pfad der eingehenden Anfrage abzugleichen.
  • pathMatchers[].routeRules[].matchRules[].headerMatches[].regexMatch: Ein regulärer Ausdruck, der ein Prädikat enthält, das mit einem Header der eingehenden Anfrage übereinstimmt.
  • pathMatchers[].routeRules[].matchRules[].queryParameterMatches[].regexMatch: Ein regulärer Ausdruck, der ein Prädikat enthält, das mit einem Abfrageparameter der eingehenden Anfrage übereinstimmt.

Eine Anfrage gilt als Übereinstimmung mit einer RouteRule, wenn eine der MatchRules erfüllt ist. Prädikate innerhalb einer bestimmten „matchRule“ haben jedoch eine AND-Semantik. Das heißt, alle Vorhersagen in einer „matchRule“ müssen übereinstimmen, damit die Anfrage der Regel entspricht.

Zusätzliche Nutzungshinweise:

  • Reguläre Ausdrücke werden nur für die folgenden Produkte unterstützt:

    • Regionale interne Application Load Balancer
    • Regionsübergreifende interne Application Load Balancer
    • Regionale externe Application Load Balancer

    Globale und klassische Application Load Balancer unterstützen keine regulären Ausdrücke.

  • Sie müssen die RE2-Syntax verwenden, um Ihre regulären Ausdrücke zu erstellen. Eine vollständige Liste der Einschränkungen und Operatoren, die in URL-Zuordnungen zulässig sind, finden Sie unter RE2-Spezifikationen für URL-Zuordnungen.

  • Der Abgleich regulärer Ausdrücke ist in Bezug auf den Speicherverbrauch und die Latenz bei der Verarbeitung von Anfragen aufwendig. Wenn Sie reguläre Ausdrücke verwenden, müssen Sie bei der Planung der Bereitstellung die Leistungseinbußen berücksichtigen. Wenn Sie beispielsweise eine URL-Zuordnung mit einem einzelnen regulären Ausdruck haben, erhöht sich die Latenz des Load Balancers um 100 Mikrosekunden pro Anfrage. Wenn Ihre URL-Zuordnung fünf reguläre Ausdrücke enthält, die abgeglichen werden müssen, können Sie mit einer Latenz von 200 Mikrosekunden pro Anfrage rechnen.

Beispiel 1: Regulären Ausdruck für den Pfad verwenden

Der Pfad gilt als Übereinstimmung, wenn er mit dem regulären Ausdruck übereinstimmt, der durch regexMatch angegeben wird, nachdem alle Abfrageparameter und Anker aus der ursprünglichen URL entfernt wurden. In den folgenden Beispiel-URL-Zuordnungen würde der reguläre Ausdruck für die Routenregel /videos/hd.* auf eine URL mit dem Pfad /videos/hd-abcd?key=245 angewendet.

defaultService: projects/example-project/global/backendServices/org-site
name: rule-match-url-map
hostRules:
- hosts:
  - '*' # Match any host
  pathMatcher: video-matcher
- hosts:
  - example.net
  pathMatcher: video-matcher
pathMatchers:
- name: video-matcher
  # Optional: default service for this path matcher if no routeRules match
  defaultService: projects/example-project/global/backendServices/video-site
  routeRules:
  - priority: 100000
    matchRules:
    - regexMatch: /videos/hd.*
    routeAction:
      weightedBackendServices:
      - backendService: projects/example-project/global/backendServices/video-hd
        weight: 100

Hier finden Sie eine Erläuterung der einzelnen Felder der Beispiel-URL-Zuordnung:

  • defaultService: Gibt den Standard-Backend-Dienst an, der verwendet werden soll, wenn keine anderen Regeln in der URL-Zuordnung mit der eingehenden Anfrage übereinstimmen.
  • name: Weist dieser URL-Zuordnungskonfiguration den Namen rule-match-url-map zu.
  • hostRules: Definiert eine Liste von Regeln für den Abgleich des Host-Headers eingehender Anfragen. Die erste Regel stimmt mit jedem Host (*) überein und leitet den Traffic an den pathMatcher mit dem Namen video-matcher weiter. Die zweite Regel entspricht speziell dem Host example.net und leitet Traffic auch an den Pfad-Matcher video-matcher weiter.
  • pathMatchers: Definiert eine Liste benannter Pfad-Matcher.
  • name: Definiert einen Pfad-Matcher mit dem Namen video-matcher.
  • defaultService: Legt den Standarddienst für diesen Pfad-Matcher fest. Dieser Dienst wird verwendet, wenn eine Anfrage mit den Hostregeln übereinstimmt, die auf video-matcher verweisen, aber nicht mit den routeRules darin.
  • routeRules: Enthält eine Liste von Regeln, die mit dem URL-Pfad abgeglichen werden.
  • priority: Legt die Priorität dieser Regel auf 100.000 fest. Regeln werden in der Reihenfolge von der niedrigsten zur höchsten Prioritätsnummer ausgewertet.
  • matchRules: Enthält die Bedingungen, die erfüllt sein müssen, damit diese Routenregel angewendet wird.
  • regexMatch: Mit dieser Bedingung wird geprüft, ob der URL-Pfad mit dem regulären Ausdruck /videos/hd.* übereinstimmt (z. B. „/videos/hd“ und „/videos/hd-caching“).
  • routeAction: Gibt die Aktion an, die ausgeführt werden soll, wenn alle Bedingungen in matchRules erfüllt sind.
  • weightedBackendServices: Verteilt den Traffic anhand von Gewichten auf eine Liste von Backend-Diensten.
  • backendService: Gibt den Backend-Dienst an, an den der Traffic weitergeleitet werden soll.
  • weight: Weist diesem Backend-Dienst ein Gewicht von 100 zu. Da es der einzige Dienst in der Liste ist, erhält er 100% des Traffics, der dieser „routeRule“ entspricht.

Die folgende URL-Zuordnung zeigt ein ähnliches Beispiel ohne Verwendung von routeAction.

defaultService: projects/example-project/global/backendServices/video-site
name: path-matcher-videos
routeRules:
  matchRules:
  - regexMatch: /videos/hd.*
  priority: 100000
  service: projects/example-project/global/backendServices/video-hd

Beispiel 2: Header mit einem regulären Ausdruck abgleichen

Der Header gilt als Übereinstimmung, wenn der Wert des Headers mit dem regulären Ausdruck übereinstimmt, der durch regexMatch angegeben wird. In der folgenden Beispiel-URL-Zuordnung würde der reguläre Ausdruck für den Headernamen, .*Android.*-hd, beispielsweise auf eine Anfrage mit dem Header User-Agent:123Androidabc-hd angewendet.

defaultService: projects/example-project/regions/us-central1/backendServices/default-backend-service
name: header-match-url-map
hostRules:
- hosts:
  - '*'  # Match any host
  pathMatcher: header-matcher
pathMatchers:
- name: header-matcher
  # Optional: default service for this path matcher if no routeRules match
  defaultService: projects/example-project/regions/us-central1/backendServices/default-backend-service
  routeRules:
  - priority: 1
    matchRules:
    - headerMatches:
      - headerName: User-Agent
        regexMatch: .*Android.*-hd
    # This prefix match applies to the path part of the URL
    - prefixMatch: /video/
    # service: can be used instead of routeAction if no other actions are needed
    service: projects/example-project/regions/us-central1/backendServices/video-backend-service
    # Alternatively, use routeAction to specify the service:
    # routeAction:
    #   weightedBackendServices:
    #   - backendService: projects/example-project/regions/us-central1/backendServices/video-backend-service
    #     weight: 100

Hier finden Sie eine Erläuterung der einzelnen Felder der Beispiel-URL-Zuordnung:

  • defaultService: Gibt den Standard-Backend-Dienst an, der verwendet werden soll, wenn keine anderen Regeln in der URL-Zuordnung mit der eingehenden Anfrage übereinstimmen.
  • name: Weist dieser URL-Zuordnungskonfiguration den Namen header-match-url-map zu.
  • hostRules: Definiert eine Liste von Regeln für den Abgleich des Host-Headers eingehender Anfragen. Die Regel stimmt mit jedem Host überein („*“) und leitet den Traffic an den Header-Matcher mit dem Namen pathMatcher weiter.
  • pathMatchers: Definiert eine Liste benannter Pfad-Matcher.
  • name: Definiert einen Pfad-Matcher mit dem Namen header-matcher.
  • defaultService: Legt den Standarddienst für diesen Pfad-Matcher fest. Dieser Dienst wird verwendet, wenn eine Anfrage mit der Hostregel übereinstimmt, aber nicht mit einem der routeRules in diesem Pfad-Matcher.
  • routeRules: Enthält eine Liste von Regeln, die eingehende Anfragen anhand von Headern und Pfaden abgleichen.
  • priority: Legt die Priorität dieser Regel auf 1 fest. Regeln werden in der Reihenfolge von der niedrigsten zur höchsten Prioritätsnummer ausgewertet.
  • matchRules: Enthält eine Liste von Bedingungen, die alle zutreffen müssen, damit die Regel übereinstimmt.
  • headerMatches: Gibt Bedingungen basierend auf Anfrageheadern an.
  • headerName: Sucht nach dem User-Agent-Header.
  • regexMatch: Prüft, ob der Wert des User-Agent-Headers mit dem regulären Ausdruck .*Android.*-hd übereinstimmt. Dies würde User-Agents entsprechen, die auf ein Android-Gerät hinweisen und einen String mit „-hd“ enthalten.
  • prefixMatch: Wenn diese Bedingung auf /video/ festgelegt ist, wird geprüft, ob der URL-Pfad mit „/video/“ beginnt.
  • service: Wenn alle matchRules-Bedingungen erfüllt sind, wird der Traffic an diesen Backend-Dienst weitergeleitet.
  • Im auskommentierten Abschnitt routeAction wird eine alternative Möglichkeit zum Angeben des Backend-Dienstes gezeigt. Diese wäre erforderlich, wenn Sie andere Routenaktionen wie URL-Rewrites, Header-Transformationen oder gewichtete Backend-Dienste konfigurieren müssten.

Beispiel 3: Regulären Ausdruck verwenden, um Abfrageparameter abzugleichen

Der Abfrageparameter gilt als Übereinstimmung, wenn der Wert des Pfads mit den Abfrageparametern mit dem regulären Ausdruck übereinstimmt, der durch regexMatch angegeben wird. Im folgenden Beispiel für eine URL-Zuordnung würde der Suchparameter für reguläre Ausdrücke, /im.*/.*.html, auf eine URL mit Suchparametern wie /images/random_page.html?param1=param_value_123abc-hd angewendet.

defaultService: projects/example-project/regions/us-central1/backendServices/sample-bs
name: query-match-url-map
hostRules:
- hosts:
  - '*'  # Match any host
  pathMatcher: query-matcher
pathMatchers:
- name: query-matcher
  # Optional: default service for this path matcher if no routeRules match
  defaultService: projects/example-project/regions/us-central1/backendServices/sample-bs
  routeRules:
  - priority: 1
    matchRules:
    - queryParameterMatches:
      - name: param1   #parameter name in query
        regexMatch: param_value_.*-hd
    # This regexMatch applies to the path part of the URL
    - regexMatch: /im.*/.*.html
    # Directs traffic to this service if all conditions in matchRules are met
    service: projects/example-project/regions/us-central1/backendServices/sample-images-bs

Hier finden Sie eine Erläuterung der einzelnen Felder der Beispiel-URL-Zuordnung:

  • hostRules: Fügt eine Regel hinzu, die mit allen Hosts (*) übereinstimmt, und leitet den Traffic an den pathMatcher mit dem Namen query-matcher weiter.
  • pathMatchers: Definiert einen Pfad-Matcher mit dem Namen query-matcher.
  • routeRules: Platziert den bereitgestellten routeRules-Block in query-matcher.
  • priority: Legt die Priorität dieser Regel auf 1 fest. Regeln werden in der Reihenfolge ihrer Prioritätsnummer ausgewertet, von der niedrigsten zur höchsten.
  • matchRules: Enthält die Bedingungen für die routeRules.
  • queryParameterMatches: Prüft, ob der Abfrageparameter mit dem Namen „param1“ dem regulären Ausdruck param_value_.*-hd entspricht.
  • regexMatch: Der reguläre Ausdruck /im.*/.*.html wird auf den Pfad der URL (z. B. /images/random_page.html) vor dem Suchstring angewendet.
  • service: Gibt den Backend-Dienst an, der verwendet werden soll, wenn alle Bedingungen in matchRules zutreffen.

Platzhalter, reguläre Ausdrücke und dynamische URLs in Pfadregeln und Präfixabgleich

  • Eine Pfadregel (pathMatchers[].pathRules[]) 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/*.

  • Bei einem Präfixabgleich (pathMatchers[].routeRules[].matchRules[].prefixMatch) wird * nicht als Platzhalterzeichen, sondern als Literalzeichen behandelt.

  • Pfad-Matcher und generell URL-Zuordnungen bieten keine Features, die wie die <LocationMatch>-Anweisung 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
  • Cloud Service Mesh

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:

  1. 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.
  2. 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.
  3. 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:

  1. Der Anfragepfad entspricht dem pathTemplateMatch im Pfadabgleich von user-matcher. Der erste * entspricht abc%40xyz.com und der zweite * dem Wert abc-1234.
  2. 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.

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 Classic Application Load Balancer erstellen.

Weitere Informationen zum Erstellen und Konfigurieren von URL-Zuordnungen mit Pfad-Matchern und Hostregeln finden Sie in der gcloud compute url-maps create-Dokumentation.

  1. 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

  2. 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

  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.
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 möchten Ü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