Übersicht über URL-Zuordnungen

Application Load Balancer von Google Cloudund Cloud Service Mesh verwenden eine Google Cloud-Konfigurationsressource, die als URL-Zuordnung bezeichnet wird, um HTTP(S)-Anfragen an Backend-Diensteoder Backend-Bucketsweiterzuleiten.

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. 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
Regionsübergreifender interner Application Load Balancer INTERNAL_MANAGED Global, intern Backend-Dienste
Regionaler interner Application Load Balancer INTERNAL_MANAGED Regional, intern Backend-Dienste
Cloud Service Mesh 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 Cloud Service Mesh verwendet werden, unterstützen ebenfalls mehrere erweiterte Features zur Trafficverwaltung. Weitere Informationen zu diesen Unterschieden finden Sie unter Load-Balancer-Features im Vergleich: Routing und Trafficverwaltung. Darüber hinaus können regionale URL-Zuordnungen eine Ressource sein, die in App Hub als Dienst festgelegt ist, das sich in der Vorschau befindet.

Funktionsweise von URL-Zuordnungen

Wenn eine Anfrage beim Load-Balancer eingeht, leitet er sie anhand der in der URL-Zuordnung definierten Regeln an einen Backend-Dienstoder einen Backend-Bucket weiter.

Ein Backend-Dienst stellt eine Sammlung von Backends dar, bei denen es sich um Instanzen einer Anwendung oder eines Mikrodienstes handelt. Ein Backend-Bucket ist ein Google Cloud Storage-Bucket, der häufig zum Hosten statischer Inhalte wie Bilder verwendet wird.

Für regionale externe Application Load Balancer, interne Application Load Balancer und 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)

Benennung

Jede URL-Zuordnung hat einen Namen. Wenn Sie einen HTTP(S)-basierten Load-Balancer mithilfe der Google Cloud Console erstellen, wird der URL-Zuordnung ein Name zugewiesen. Dieser Name entspricht dem Namen des Load-Balancers in der Google Cloud Console. Wenn Sie Google Cloud CLI oder die API verwenden, können Sie einen benutzerdefinierten Namen für die URL-Zuordnung definieren.

URL-Zuordnungskomponenten

Eine URL-Zuordnung ist eine Gruppe von Google Cloud-Konfigurationsressourcen, die Anfragen für URLs an Backend-Diensteoder Backend-Buckets weiterleiten. Dazu verwendet die URL-Zuordnung die Teile Hostname und Pfad für jede von ihr verarbeitete URL:

  • Ein Hostname ist der Domainnamen-Abschnitt einer URL. Der Hostname der URL http://example.net/video/hd ist 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-Diensteoder Backend-Buckets eingehende Anfragen erhalten:

  • Standard-Backend-Dienst oder Standard-Backend-Bucket. Wenn Sie eine URL-Zuordnung erstellen, müssen Sie entweder einen Standard-Backend-Dienst oder einen Standard-Backend-Bucket angeben, aber nicht beides. Diese Standardeinstellung stellt den Backend-Dienst oder Backend-Bucket dar, an den Google Cloud Anfragen für URLs mit beliebigem Hostnamen weiterleitet, sofern keine entsprechende Hostregel vorhanden ist.

  • Hostregel (hostRules). Eine Hostregel leitet Anfragen, die an einen oder mehrere verknüpfte Hostnamen gesendet werden, an einen einzelnen Pfad-Matcher (pathMatchers) weiter. Der Hostname einer URL wird genau mit der Gruppe der konfigurierten Hostnamen der Hostregel abgeglichen. Wenn Sie in einer URL-Zuordnungs-Host- und -Pfadregel den Host weglassen, entspricht die Regel jedem angeforderten Host. Um Anfragen fü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 beim Abgleich mit einer Hostregel berücksichtigt. 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-Bucketzuordnen. Der nächste Abschnitt enthält weitere Informationen zur Funktionsweise von Pfadregeln.

Reihenfolge von Vorgängen

Für einen bestimmten Hostnamen und -pfad in einer angeforderten URL verwendet Google Cloud das folgende Verfahren, um die Anfrage an den richtigen Backend-Dienstoder Backend-Bucketso weiterzuleiten, wie es in Ihrer URL-Zuordnung konfiguriert ist:

  • Wenn die URL-Zuordnung keine Hostregel für den Hostnamen der URL enthält, leitet Google Cloud Anfragen an den Standard-Backend-Dienstder URL-Zuordnung oder an den Standard-Backend-Bucketweiter, je nachdem, welchen Sie definiert haben.

  • Wenn die URL-Zuordnung eine Hostregel mit dem Hostnamen der URL enthält, wird der Pfad-Matcher, auf den sich diese Hostregel bezieht, verwendet:

    • Wenn der Pfad-Matcher eine Pfadregel enthält, die genau mit dem URL-Pfad übereinstimmt, leitet Google Cloud Anfragen an den Backend-Dienst oder den Backend-Bucket für diese Pfadregel weiter.

    • Wenn der Pfad-Matcher keine Pfadregel enthält, die genau dem URL-Pfad entspricht, aber eine Pfadregel enthält, die auf /* endet und deren Präfix dem längsten Abschnitt des URL-Pfads entspricht, leitet Google Cloud Anfragen an den Backend-Dienst oder Backend-Bucket für diese Pfadregel weiter. Für die URL-Zuordnung mit den beiden Pfad-Matcher-Regeln /video/hd/movie1 und /video/hd/* wird beispielsweise die URL mit der Pfadregel /video/hd/movie1 abgeglichen, wenn sie genau diesen Pfad enthält.

    • Wenn keine der vorherigen Bedingungen zutrifft, leitet Google Cloud Anfragen an den Standard-Backend-Dienst oder den Standard-Backend-Bucketdes Pfad-Matchers weiter, je nachdem, welchen Sie definiert haben.

Pfad-Matcher-Einschränkungen

Für Hostnamen, Pfad-Matcher und Pfadregeln gelten Einschränkungen.

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

  • Eine Pfadregel kann nur ein Platzhalterzeichen (*) hinter einem Schrägstrich (/) enthalten. Zum Beispiel gelten /videos/* und /videos/hd/* für Pfadregeln, /videos* und /videos/hd* hingegen nicht.

  • Pfadregeln verwenden keine regulären Ausdrücke oder Teilstringabgleiche. PathTemplateMatch kann vereinfachte Operatoren zum Pfadabgleich verwenden. Beispielsweise gelten Pfadregeln für /videos/hd oder /videos/hd/* nicht für eine URL mit dem Pfad /video/hd-abcd. Für diesen Pfad gilt jedoch eine Pfadregel für /video/*.

  • Pfad-Matcher und generell URL-Zuordnungen bieten keine Features, die wie LocationMatch-Anweisungen von Apache funktionieren. Wenn Ihre Anwendung dynamische URL-Pfade mit einem gemeinsamen Präfix wie /videos/hd-abcd und /videos/hd-pqrs generiert und Sie Anfragen an diese Pfade an verschiedene Backend-Dienste senden müssen, ist dies mit einer URL-Zuordnung vielleicht nicht möglich. In Fällen, in denen nur wenige dynamische URLs möglich sind, können Sie eventuell einen Pfad-Matcher mit einem begrenzten Satz von Pfadregeln erstellen. Bei komplexeren Fällen müssen Sie einen pfadbasierten Abgleich regulärer Ausdrücke auf Ihren Back-Ends durchführen.

Platzhalter und Musterabgleichsoperatoren in Pfadvorlagen für Routingregeln

Mit den Operatoren für den flexiblen Musterabgleich können Sie mithilfe einer Platzhaltersyntax mehrere Teile eines URL-Pfads abgleichen, einschließlich partieller URLs und Suffixe (Dateiendungen). Diese Operatoren können hilfreich sein, wenn Sie Traffic weiterleiten und Umschreibungen basierend auf komplexen URL-Pfaden ausführen müssen. Sie können auch eine oder mehrere Pfadkomponenten mit benannten Variablen verknüpfen und dann beim Umschreiben der URL auf diese Variablen verweisen. Mit benannten Variablen können Sie die URL-Komponenten neu anordnen und entfernen, bevor die Anfrage an den Ursprung gesendet wird.

Der Musterabgleich mit Platzhaltern wird nur für die folgenden Produkte unterstützt:

  • Globaler externer Application Load Balancer
  • Regionaler externer Application Load Balancer
  • Regionaler interner Application Load Balancer
  • Regionsübergreifender interner Application Load Balancer
  • 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.

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-Bucketweitergeleitet: Dies hat folgende Konsequenzen:

  • Google Cloud verwendet den Hostnamen einer URL, um eine einzelne Hostregel und den zugehörigen Pfad-Matcher auszuwählen.

  • Wenn Sie Pfadregeln in einem Pfad-Matcher verwenden, können Sie jeweils nur eine Pfadregel für denselben Pfad erstellen. Anfragen für /videos/hd können beispielsweise jeweils nur an einen Backend-Dienst oder Backend-Bucketgerichtet werden. Backend-Dienste können Backend-Instanzgruppen oder Backend-Netzwerk-Endpunktgruppen (NEGs) in verschiedenen Zonen und Regionenhaben. Sie können auch Backend-Buckets mit Multi-Regional Storage erstellen.

    Um Traffic für eine eindeutige URL an mehrere Dienste weiterzuleiten, können Sie Routingregeln anstelle von Pfadregeln verwenden. Wenn Sie den Pfad-Matcher mit Routingregeln für Header- oder Parameterübereinstimmungen konfigurieren, kann eine eindeutige URL basierend auf dem Inhalt der Header oder Abfrageparameter an mehrere Backend-Dienste oder Backend-Bucketsin der URL weitergeleitet werden.

    Ebenso können bei regionalen Application Load Balancern und Cloud Service Meshgewichtete Backend-Dienste für Routingaktionen dieselbe URL an mehrere Backend-Dienste oder Backend-Bucketsweiterleiten, abhängig von den Gewichtungen, die für den gewichteten Backend-Dienst festgelegt sind.

URL-Zuordnungen und -Protokolle

Sie können dieselbe URL-Zuordnung, Hostregeln und Pfadabgleiche verwenden, um sowohl HTTP- als auch HTTPS-Anfragen von Clients zu verarbeiten, solange sowohl ein Ziel-HTTP-Proxy als auch ein Ziel-HTTPS-Proxy auf die URL-Zuordnung verweisen.

Einfachste URL-Zuordnung

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

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

URL-Zuordnung ohne Regeln, außer der Standardeinstellung
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.

  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