Serverlose NEGs einrichten

Eine Netzwerk-Endpunktgruppe (NEG) ist eine Gruppe von Back-End-Endpunkten für einen Load-Balancer. Eine serverlose NEG ist ein Back-End, das auf einen Cloud Run-, App Engine- oder Cloud Functions-Dienst verweist.

Eine serverlose NEG kann Folgendes darstellen:

• Einen Cloud Run-Dienst oder eine Gruppe von Diensten mit demselben URL-Muster
• Eine Cloud Functions-Funktion oder eine Gruppe von Funktionen mit demselben URL-Muster
• Eine App Engine-Anwendung (Standard oder Flex), einen bestimmten Dienst innerhalb einer Anwendung oder sogar eine bestimmte Version einer Anwendung

Auf dieser Seite wird erläutert, wie Sie einen externen HTTP(S)-Load-Balancer erstellen, um Anfragen zum serverlosen Back-Ends zu leiten. Der Begriff "serverlos" bezieht sich hier auf die folgenden serverlosen Computing-Produkte: App Engine, Cloud Functions und Cloud Run (vollständig verwaltet).

Serverlose NEGs bieten Ihnen die Möglichkeit, serverlose Google Cloud-Anwendungen mit externem HTTP(S)-Load-Balancing zu verwenden. Nachdem Sie einen Load-Balancer mit dem serverlosen NEG-Back-End konfiguriert haben, werden Anfragen an den Load-Balancer zum serverlosen Back-End der Anwendung geleitet.

Vorbereitung

Erledigen Sie zuerst Folgendes:

1. Lesen Sie die Übersicht über serverlose NEGs.
2. Stellen Sie einen App Engine-, Cloud Functions- oder Cloud Run-Dienst (vollständig verwaltet) bereit.
3. Installieren Sie das Google Cloud SDK.
4. Konfigurieren Sie Berechtigungen.
5. Fügen Sie eine SSL-Zertifikatsressource hinzu.

App Engine-, Cloud Functions- oder Cloud Run-Dienst (vollständig verwaltet) bereitstellen

Bei den Anleitungen auf dieser Seite wird davon ausgegangen, dass Sie bereits einen (vollständig verwalteten) Cloud Run-, Cloud Functions- oder App Engine-Dienst ausführen.

Für das Beispiel auf dieser Seite wurde die Python-Kurzanleitung für Cloud Run (vollständig verwaltet) verwendet, um den helloworld-Dienst in der Region us-central1 bereitzustellen. Auf dem Rest dieser Seite wird gezeigt, wie Sie einen externen HTTP(S)-Load-Balancer einrichten, der ein serverloses NEG-Back-End verwendet, um Anfragen zum helloworld-Dienst zu leiten.

Wenn Sie noch keine serverlose Anwendung bereitgestellt haben oder eine serverlose NEG mit einer Beispielanwendung ausprobieren möchten, nutzen Sie eine der folgenden Kurzanleitungen. Sie können eine serverlose Anwendung in jeder Region erstellen, aber Sie müssen später zum Erstellen der serverlosen NEG und des Load-Balancers dieselbe Region verwenden.

Cloud Run (vollständig verwaltet)

Informationen zum Erstellen einer einfachen Hello World-Anwendung finden Sie unter Kurzanleitung: Erstellen und Bereitstellen. Dazu wird die Anwendung in einem Container-Image verpackt und anschließend das Container-Image in Cloud Run (vollständig verwaltet) bereitgestellt.

Wenn Sie bereits einen Beispielcontainer nach Container Registry hochgeladen haben, finden Sie weitere Informationen unter Kurzanleitung: Vorgefertigten Beispielcontainer bereitstellen.

Cloud Functions

Siehe Cloud Functions: Python-Kurzanleitung.

App Engine

Informationen finden Sie in den folgenden App Engine-Kurzanleitungen für Python 3:

• Standardumgebung
• Flexible Umgebung

Google Cloud SDK installieren

Installieren Sie das gcloud-Befehlszeilentool. In der gcloud-Übersicht finden Sie Informationen zum Konzept und zur Installation des Tools.

Wenn Sie das gcloud-Befehlszeilentool bisher noch nicht verwendet haben, führen Sie zuerst gcloud init aus, um Ihr gcloud-Verzeichnis zu initialisieren.

Berechtigungen konfigurieren

Um dieser Anleitung zu folgen, müssen Sie in einem Projekt eine serverlose NEG und einen externen HTTP(S)-Load-Balancer erstellen. Sie sollten entweder Inhaber oder Bearbeiter des Projekts sein oder die folgenden IAM-Rollen für Compute Engine haben:

Aufgabe	Erforderliche Rolle
Load-Balancer und Netzwerkkomponenten erstellen	Netzwerkadministrator
NEGs erstellen und ändern	Compute-Instanzadministrator
SSL-Zertifikate erstellen und ändern	Sicherheitsadministrator

Externe IP-Adresse reservieren

Nachdem die Dienste nun ausgeführt werden, müssen Sie eine globale statische externe IP-Adresse einrichten, über die Ihre Kunden den Load-Balancer erreichen können.

Hinweis: Dieser Schritt ist für dieses Beispiel erforderlich und wird allgemein empfohlen, da eine statische externe IP-Adresse nur eine einzelne Adresse enthält, auf die Ihre Domain verweist. Das Reservieren einer IP-Adresse ist auch dann wichtig, wenn Sie eine benutzerdefinierte Domain verwenden (auch für von Google verwaltete Zertifikate erforderlich). Später in diesem Prozess müssen Sie Ihre DNS-Einträge aktualisieren, damit sie auf diese IP-Adresse verweisen.

Console

1. Rufen Sie in der Google Cloud Console die Seite "Externe IP-Adressen" auf.
   Zur Seite "Externe IP-Adressen"
2. Klicken Sie auf Statische Adresse reservieren, um eine IPv4-Adresse zu reservieren.
3. Weisen Sie als Name example-ip zu.
4. Legen Sie für die Netzwerkstufe Premium fest.
5. Setzen Sie die IP-Version auf IPv4.
6. Legen Sie für Typ Global fest.
7. Klicken Sie auf Reservieren.

gcloud

gcloud compute addresses create example-ip \
    --ip-version=IPV4 \
    --global

Notieren Sie sich die reservierte IPv4-Adresse:

gcloud compute addresses describe example-ip \
    --format="get(address)" \
    --global

SSL-Zertifikatsressource erstellen

Wenn Sie einen HTTPS-Load-Balancer erstellen möchten, müssen Sie dem Front-End des Load-Balancers eine SSL-Zertifikatsressource hinzufügen. Erstellen Sie eine SSL-Zertifikatsressource mit einem von Google verwalteten SSL-Zertifikat oder einem selbst verwalteten SSL-Zertifikat.

• Von Google verwaltete Zertifikate. Es empfiehlt sich, von Google verwaltete Zertifikate zu verwenden, da Google Cloud diese Zertifikate automatisch abruft, verwaltet und verlängert. Zum Erstellen eines von Google verwalteten Zertifikats benötigen Sie eine Domain und die DNS-Einträge für diese Domain, damit das Zertifikat bereitgestellt werden kann. Wenn Sie noch keine Domain haben, können Sie eine Domain von Google Domains erhalten. Außerdem müssen Sie den DNS-A-Eintrag der Domain so aktualisieren, dass er auf die IP-Adresse des Load-Balancers verweist, die im vorherigen Schritt erstellt wurde (example-ip). Eine ausführliche Anleitung finden Sie unter Von Google verwaltete Zertifikate verwenden.

• Selbst signierte Zertifikate. Wenn Sie derzeit keine Domain einrichten möchten, können Sie ein selbst signiertes SSL-Zertifikat zu Testzwecken verwenden.

Warnung: Verwenden Sie für Produktionszwecke kein selbst signiertes Zertifikat.

In diesem Beispiel wird davon ausgegangen, dass Sie bereits eine SSL-Zertifikatsressource erstellt haben.

Wenn Sie diesen Prozess testen möchten, ohne eine SSL-Zertifikatsressource bzw. eine Domain (für von Google verwaltete Zertifikate erforderlich) zu erstellen, folgen Sie der Anleitung auf dieser Seite, um stattdessen einen HTTP-Load-Balancer einzurichten.

Externen HTTP(S)-Load-Balancer erstellen

Im folgenden Diagramm verwendet der Load-Balancer ein serverloses NEG-Back-End, um Anfragen zu einem serverlosen (vollständig verwalteten) Cloud Run-Dienst zu leiten. Für dieses Beispiel wurde die Python-Kurzanleitung für Cloud Run (vollständig verwaltet) verwendet, um den helloworld-python-Dienst bereitzustellen.

HTTPS-Load-Balancing für eine Cloud Run-Anwendung

Da Systemdiagnosen für Back-End-Dienste mit serverlosen NEG-Back-Ends nicht unterstützt werden, müssen Sie keine Firewallregel erstellen, die Systemdiagnosen zulässt, wenn der Load-Balancer nur serverlose NEG-Back-Ends hat.

Console

Load-Balancer benennen

1. Öffnen Sie in der Google Cloud Console die Seite "Load-Balancing".
   Zur Seite "Load-Balancing"
2. Klicken Sie unter HTTP(S)-Load-Balancing auf Konfiguration starten.
3. Wählen Sie unter Internet oder nur intern die Option Vom Internet zu meinen VMs aus.
4. Klicken Sie auf Weiter.
5. Geben Sie helloworld-lb als Name für den Load-Balancer ein.
6. Lassen Sie das Fenster geöffnet, um fortzufahren.

Back-End-Dienste konfigurieren

1. Klicken Sie auf Back-End-Konfiguration.
2. Halten Sie im Drop-down-Menü Back-End-Dienst erstellen oder auswählen den Mauszeiger auf Back-End-Dienste und wählen Sie Back-End-Dienst erstellen aus.
3. Legen Sie als Name für den Back-End-Dienst helloworld-backend-service fest.
4. Wählen Sie unter Back-End-Typ die Option Serverlose Netzwerk-Endpunktgruppe aus.
5. Wählen Sie im Drop-down-Menü Protokoll die Option HTTPS aus.
6. Wählen Sie unter Back-Ends im Fenster Neues Back-End die Option Serverlose Netzwerk-Endpunktgruppe erstellen aus.
   1. Geben Sie im Feld Name helloworld-serverless-neg ein.
   2. Wählen Sie unter Region die Option us-central1 aus.
   3. Wählen Sie einen Gruppentyp für den serverlosen Netzwerkendpunkt aus. In diesem Beispiel wird ein (vollständig verwalteter) Cloud Run-Dienst verwendet. Wählen Sie daher Cloud Run aus.
      1. Wählen Sie Dienstname auswählen aus.
      2. Wählen Sie in der Drop-down-Liste Dienst den Dienst helloworld aus.
   4. Klicken Sie auf Erstellen.
7. Klicken Sie im Fenster Neues Back-End auf Fertig.
8. (Optional) Wählen Sie Cloud CDN aktivieren aus.
9. Klicken Sie auf Erstellen.

Hostregeln und Pfad-Matcher konfigurieren

Hostregeln und Pfad-Matcher sind Konfigurationskomponenten der URL-Zuordnung eines externen HTTP(S)-Load-Balancers.

1. Klicken Sie auf Host- und Pfadregeln.
2. Behalten Sie die Standardhosts und -pfade bei. Das bedeutet, dass alle Anfragen an helloworld-backend-service gesendet werden.

Front-End konfigurieren

1. Klicken Sie auf Front-End-Konfiguration.
2. Geben Sie einen Namen ein.

3. Sie benötigen ein SSL-Zertifikat (gcloud compute ssl-certificates list), um einen HTTPS-Load-Balancer zu erstellen. Wir empfehlen die Verwendung eines von Google verwalteten Zertifikats, wie weiter oben beschrieben. Füllen Sie die folgenden Felder aus, um einen externen HTTP(S)-Load-Balancer zu konfigurieren.

   Prüfen Sie, ob die folgenden Optionen mit diesen Werten konfiguriert sind:

   Attribut	Wert (Wert eingeben bzw. Option auswählen)
   Protokoll	HTTPS
   Netzwerkdienststufe	Premium
   IP-Version	IPv4
   IP-Adresse	Beispiel-IP
   Port	443
   Zertifikat	Wählen Sie ein vorhandenes SSL-Zertifikat aus oder erstellen Sie ein neues. Zum Erstellen eines HTTPS-Load-Balancers benötigen Sie eine SSL-Zertifikatsressource, die im HTTPS-Proxy verwendet werden kann. Sie können eine SSL-Zertifikatsressource entweder mithilfe eines selbstverwalteten SSL-Zertifikats oder eines von Google verwalteten SSL-Zertifikats erstellen. Zum Erstellen eines von Google verwalteten Zertifikats benötigen Sie eine Domain. Der A-Eintrag der Domain muss in die IP-Adresse des Load-Balancers aufgelöst werden (in diesem Beispiel example-ip). Es wird empfohlen, von Google verwaltete Zertifikate zu verwenden, da Google Cloud diese Zertifikate automatisch abruft, verwaltet und verlängert. Wenn Sie keine Domain haben, können Sie ein selbst signiertes SSL-Zertifikat zu Testzwecken verwenden.

   Wenn Sie diesen Prozess testen möchten, ohne eine SSL-Zertifikatsressource (oder eine Domain, wie sie für von Google verwalteten Zertifikaten erforderlich sind) einzurichten, können Sie einen HTTP-Load-Balancer einrichten.
   
   Wenn Sie einen HTTP-Load-Balancer erstellen möchten, müssen die folgenden Optionen mit diesen Werten konfiguriert sein:

   Attribut	Wert (Wert eingeben bzw. Option auswählen)
   Protokoll	HTTP
   Netzwerkdienststufe	Premium
   IP-Version	IPv4
   IP-Adresse	Beispiel-IP
   Port	80

4. Klicken Sie auf Fertig.

Konfiguration prüfen

1. Klicken Sie auf Prüfen und abschließen.
2. Prüfen Sie Back-End, Host- und Pfadregeln und das Front-End.
3. Klicken Sie auf Erstellen.
4. Warten Sie, bis der Load-Balancer erstellt ist.
5. Klicken Sie auf den Namen des Load-Balancers (helloworld-lb).
6. Notieren Sie die IP-Adresse des Load-Balancers für die nächste Aufgabe. Sie wird als IP_ADDRESS bezeichnet.

Hinweis: Wenn Sie die Google Cloud Console zum Erstellen eines HTTP(S)-Load-Balancers mit einem serverlosen NEG-Back-End verwenden, ist das Logging standardmäßig aktiviert. Mit dem Befehl gcloud compute backend-services update können Sie das Logging bei Bedarf deaktivieren.

gcloud

1. Erstellen Sie eine serverlose NEG für Ihren (vollständig verwalteten) Cloud Run-Dienst. In diesem Beispiel wird davon ausgegangen, dass Sie einen (vollständig verwalteten) Cloud Run-Dienst namens helloworld bereitgestellt haben.

   gcloud compute network-endpoint-groups create helloworld-serverless-neg \
       --region=us-central1 \
       --network-endpoint-type=serverless  \
       --cloud-run-service=helloworld
   

   Informationen zum Erstellen einer NEG für einen App Engine-Dienst oder eine Cloud Functions-Funktion finden Sie in der gcloud-Übersicht für gcloud compute network-endpoint-groups create.
2. Erstellen Sie einen Back-End-Dienst und fügen Sie ihm die serverlose NEG als Back-End hinzu:

   gcloud compute backend-services create helloworld-backend-service \
       --global
   

   gcloud compute backend-services add-backend helloworld-backend-service \
       --global \
       --network-endpoint-group=helloworld-serverless-neg \
       --network-endpoint-group-region=us-central1
   

3. Erstellen Sie eine URL-Zuordnung, um eingehende Anfragen zum Back-End-Dienst helloworld-backend-service zu leiten:

   gcloud compute url-maps create helloworld-url-map \
       --default-service helloworld-backend-service
   

   Diese beispielhafte URL-Zuordnung ist nur auf einen Back-End-Dienst ausgerichtet, der einen einzelnen (vollständig verwalteten) Cloud Run-Dienst darstellt. Daher müssen keine Hostregeln oder Tools zum Abgleich von Pfaden eingerichtet werden. Wenn Sie mehr als einen Back-End-Dienst haben, können Sie Hostregeln verwenden, um Anfragen basierend auf dem Hostnamen zu verschiedenen Diensten zu leiten. Sie können auch Tools zum Abgleich von Pfaden einrichten, um Anfragen basierend auf dem Anfragepfad zu verschiedenen Diensten zu leiten.
4. Führen Sie diesen Schritt nur aus, wenn Sie einen HTTPS-Load-Balancer erstellen möchten. Dies ist für HTTP-Load-Balancer nicht erforderlich.
   Um einen HTTPS-Load-Balancer zu erstellen, benötigen Sie eine SSL-Zertifikatsressource, die im HTTPS-Proxy verwendet werden soll. Sie können eine SSL-Zertifikatsressource mit einem von Google verwalteten SSL-Zertifikat oder einem selbstverwalteten SSL-Zertifikat erstellen. Es empfiehlt sich, von Google verwaltete Zertifikate zu verwenden, da Google Cloud diese Zertifikate automatisch abruft, verwaltet und verlängert.
   Zum Erstellen eines von Google verwalteten Zertifikats benötigen Sie eine Domain. Wenn Sie keine Domain haben, können Sie ein selbst signiertes SSL-Zertifikat zu Testzwecken verwenden.
   
   So erstellen Sie eine von Google verwaltete SSL-Zertifikatsressource namens www-ssl-cert:

   gcloud compute ssl-certificates create www-ssl-cert \
       --domains [DOMAIN]
   

   So erstellen Sie eine selbstverwaltete SSL-Zertifikatsressource namens www-ssl-cert:

   gcloud compute ssl-certificates create www-ssl-cert \
       --certificate [CRT_FILE_PATH] \
       --private-key [KEY_FILE_PATH]
   

5. Erstellen Sie einen HTTP(S)-Zielproxy, um Anfragen an Ihre URL-Zuordnung weiterzuleiten:
   
   Erstellen Sie für einen HTTP-Load-Balancer einen HTTP-Zielproxy:

     gcloud compute target-http-proxies create helloworld-http-proxy \
       --url-map=helloworld-url-map
     

   Erstellen Sie für einen HTTPS-Load-Balancer einen HTTPS-Zielproxy. Der Proxy ist der Teil des Load-Balancers, der das SSL-Zertifikat für den HTTPS-Load-Balancer besitzt. Daher laden Sie in diesem Schritt auch Ihr Zertifikat.

   gcloud compute target-https-proxies create helloworld-https-proxy \
       --ssl-certificates=www-ssl-cert \
       --url-map=helloworld-url-map
   

6. Erstellen Sie eine globale Weiterleitungsregel, um eingehende Anfragen an den Proxy weiterzuleiten.
   
   Für einen HTTP-Load-Balancer:

   gcloud compute forwarding-rules create http-forwarding-rule \
       --address=example-ip \
       --target-http-proxy=helloworld-http-proxy \
       --global \
       --ports=80
   

   Für einen HTTPS-Load-Balancer:

   gcloud compute forwarding-rules create https-forwarding-rule \
       --address=example-ip \
       --target-https-proxy=helloworld-https-proxy \
       --global \
       --ports=443
   

DNS-Einträge Ihrer Domain aktualisieren, um die IP-Adresse des Load-Balancers zu verwenden

Hinweis: Dieser Schritt ist erforderlich, wenn Sie einen HTTPS-Load-Balancer mit einem von Google verwalteten Zertifikat erstellt haben. Dies ist auch erforderlich, wenn Ihre serverlosen Computing-Anwendungen benutzerdefinierten Domains zugeordnet werden.

Wenn Sie dies noch nicht getan haben, aktualisieren Sie den DNS-A-Eintrag Ihrer Domain so, dass er auf die IP-Adresse des Load-Balancers verweist. Dann wird Traffic, der an die vorhandenen benutzerdefinierten Domain-URLs von Cloud Run (vollständig verwaltet) oder App Engine stattdessen über den Load-Balancer weitergeleitet.

Wenn Sie z. B. eine benutzerdefinierte Domain mit dem Namen example.com haben und alle (vollständig verwalteten) Cloud Run-Dienste dieser Domain zugeordnet sind, sollten Sie den DNS-A-Eintrag entsprechend aktualisieren, damit example.com auf die IP-Adresse des Load-Balancers verweist.

Bevor Sie die DNS-Einträge aktualisieren, können Sie Ihre Konfiguration lokal testen. Erzwingen Sie dazu die lokale DNS-Auflösung der benutzerdefinierten Domain in die IP-Adresse des Load-Balancers. Passen Sie für lokale Tests entweder die Datei /etc/hosts/ auf Ihrem lokalen Computer an, damit example.com auf die IP-Adresse des Load-Balancers verweist, oder verwenden Sie das Flag curl --resolve, damit curl für die Anfrage die IP-Adresse des Load-Balancers verwendet.

Wird der DNS-Eintrag für example.com in die IP-Adresse des HTTP(S)-Load-Balancers aufgelöst, dann werden an example.com gesendete Anfragen über den Load-Balancer geleitet. Der Load-Balancer leitet sie je nach URL-Zuordnung an den entsprechenden Back-End-Dienst weiter. Wenn der Back-End-Dienst mit einer URL-Maske konfiguriert ist, verwendet die serverlose NEG außerdem die Maske, um die Anfrage zum entsprechenden (vollständig verwalteten) Cloud Run-, Cloud Functions- oder App Engine-Dienst zu leiten.

Wenn Sie von Google verwaltete Zertifikate verwenden, kann die Migration eines vorhandenen Dienstes zu einem externen HTTP(S)-Load-Balancer zu einer Ausfallzeit führen. In der Regel beträgt diese weniger als eine Stunde. Dies liegt daran, dass das SSL-Zertifikat für Ihren externen HTTP(S)-Load-Balancer erst bereitgestellt wird, wenn Sie Ihre DNS-Einträge so aktualisieren, dass sie auf die IP-Adresse des Load-Balancers verweisen.

Hinweis: Wenn Sie die Migration eines (vollständig verwalteten) Cloud Run-Dienstes mit einer benutzerdefinierten Domain zu einem HTTPS-Load-Balancer in Betracht ziehen, empfehlen wir, die Load-Balancer-Konfiguration vorher umfassend zu testen. Erwägen Sie beispielsweise die Bereitstellung eines separaten HTTP-Load-Balancers, um die serverlose NEG-Einrichtung zu testen, bevor Sie DNS-Einträge an der Produktionsbereitstellung ändern. Weitere Informationen zum Verwalten benutzerdefinierter Domains für Cloud Run (vollständig verwaltet) finden Sie unter Benutzerdefinierte Domains zuordnen.

Externen HTTP(S)-Load-Balancer testen

Nachdem Sie den Load-Balancer konfiguriert haben, können Sie Traffic an die IP-Adresse des Load-Balancers senden. Wenn Sie eine Domain konfiguriert haben, können Sie auch Traffic an den Domainnamen senden. Die DNS-Weitergabe kann jedoch einige Zeit in Anspruch nehmen. Sie können also erst einmal die IP-Adresse zu Testzwecken verwenden.

1. Öffnen Sie in der Google Cloud Console die Seite "Load-Balancing".
   Zur Seite "Load-Balancing"
2. Klicken Sie auf den Load-Balancer, den Sie gerade erstellt haben.
3. Notieren Sie sich die IP-Adresse des Load-Balancers.

4. Wenn Sie einen HTTP-Load-Balancer erstellt haben, können Sie ihn mit einem Webbrowser testen. Rufen Sie dafür http://IP_ADDRESS auf. Ersetzen Sie IP_ADDRESS durch die IP-Adresse des Load-Balancers. Sie sollten zur Startseite des helloworld-Dienstes geleitet werden.
   

   Wenn Sie einen HTTPS-Load-Balancer erstellt haben, können Sie den Load-Balancer mit einem Webbrowser testen. Rufen Sie dafür https://IP_ADDRESS auf. Ersetzen Sie IP_ADDRESS durch die IP-Adresse des Load-Balancers. Sie sollten zur Startseite des helloworld-Dienstes geleitet werden.
   

   Wenn dies nicht funktioniert und Sie ein von Google verwaltetes Zertifikat verwenden, prüfen Sie, ob der Status der Zertifikatsressource AKTIV ist. Weitere Informationen finden Sie unter Status der von Google verwalteten SSL-Zertifikatsressourcen.
   

   Wenn Sie ein selbst signiertes Zertifikat zu Testzwecken genutzt haben, zeigt Ihr Browser eine Warnung an. Sie müssen Ihrem Browser ausdrücklich anweisen, ein selbst signiertes Zertifikat zu akzeptieren. Bestätigen Sie die Warnung, um die eigentliche Seite zu sehen.

   Alternativ können Sie curl über die Befehlszeile Ihres lokalen Computers verwenden. Ersetzen Sie IP_ADDRESS durch die IPv4-Adresse des Load-Balancers: Sie sollten zur Startseite des helloworld-Dienstes geleitet werden.

   Wenn Sie ein von Google verwaltetes Zertifikat verwenden, testen Sie die Domain, die auf die IP-Adresse des Load-Balancers verweist. Beispiel:

   curl -k -s 'https://test.example.com:443' --connect-to test.example.com:443:IP_ADDRESS:443
   

   Wenn Sie ein selbst signiertes Zertifikat verwenden, müssen Sie auch das Flag -k angeben. Mit der curl-Option -k funktioniert curl, wenn Sie ein selbst signiertes Zertifikat haben. Sie sollten den Parameter -k nur verwenden, um Ihre eigene Website zu testen. Unter normalen Umständen ist die Prüfung auf ein gültiges Zertifikat eine wichtige Sicherheitsmaßnahme und Zertifikatwarnungen sollten nicht ignoriert werden.

5. (Optional) Wenn Sie eine benutzerdefinierte Domain verwenden, müssen Sie möglicherweise warten, bis die aktualisierten DNS-Einstellungen wirksam werden. Testen Sie dann Ihre Domain (z. B. https://test.example.com) im Webbrowser. Sie sollten zur Startseite des helloworld-Dienstes weitergeleitet werden.

Zusätzliche Konfigurationsoptionen

In diesem Abschnitt wird die Konfiguration des Beispiels um alternative und zusätzliche Optionen erweitert. Alle Aufgaben sind optional. Sie können sie in beliebiger Reihenfolge ausführen.

Multiregionales Load-Balancing einrichten

Hinweis: Das multiregionale Load-Balancing wird nur für serverlose NEGs mit Cloud Run- (vollständig verwaltet) und Cloud Functions-Back-Ends unterstützt.

Im oben beschriebenen Beispiel wird als Back-End nur ein einzelner (vollständig verwalteter) Cloud Run-Dienst verwendet. Da die serverlose NEG nur jeweils auf einen Endpunkt verweisen kann, erfolgt kein Load-Balancing. Der externe HTTP(S)-Load-Balancer dient nur als Front-End und leitet den Traffic an den angegebenen Endpunkt der helloworld-Anwendung weiter. Unter Umständen ist es jedoch vorteilhafter, wenn Sie Ihre (vollständig verwaltete) Cloud Run-Anwendung in mehreren Regionen bereitstellen, um die Verfügbarkeit Ihres Dienstes sowie die Latenz für die Nutzer zu verbessern.

Wenn ein Back-End-Dienst mehrere NEGs enthält, sorgt der Load-Balancer für ausgewogenen Traffic, indem Anfragen zur serverlosen NEG in der nächsten verfügbaren Region weitergeleitet werden. Back-End-Dienste können jedoch pro Region nur eine serverlose NEG enthalten. Damit Ihr (vollständig verwalteter) Cloud Run-Dienst in mehreren Regionen verfügbar ist, müssen Sie regionenübergreifendes Routing einrichten. Sie sollten ein einziges URL-Schema verwenden können, das überall auf der Welt funktioniert, aber Nutzeranfragen über die Region verarbeitet, die dem Nutzer am nächsten ist. Wenn die nächstgelegene Region nicht verfügbar ist oder nicht genügend Kapazitäten hat, wird die Anfrage zu einer anderen Region geleitet.

Zum Einrichten der multiregionalen Bereitstellung müssen Sie die Premium-Netzwerkstufe verwenden. So können Sie sicherstellen, dass alle regionalen (vollständig verwalteten) Cloud Run-Bereitstellungen kompatibel sind und Traffic aus jeder Region bereitstellen können.

So richten Sie einen Load-Balancer für mehrere Regionen ein:

1. Richten Sie zwei (vollständig verwaltete) Cloud Run-Dienste in verschiedenen Regionen ein. Angenommen, Sie haben zwei (vollständig verwaltete) Cloud Run-Dienste bereitgestellt: einen in einer Region in Europa und einen anderen in einer Region in den USA.
2. Erstellen Sie einen externen HTTP(S)-Load-Balancer mit der folgenden Konfiguration:
   1. Richten Sie einen globalen Back-End-Dienst mit zwei serverlosen NEGs ein.
      1. Erstellen Sie die erste NEG in derselben Region, in der sich der in Europa bereitgestellte Cloud Run-Dienst befindet.
      2. Erstellen Sie die zweite NEG in derselben Region, in der sich der in den USA bereitgestellte Cloud Run-Dienst befindet.
   2. Richten Sie Ihre Front-End-Konfiguration mit der Premium-Netzwerkstufe ein.

Der Rest der Konfiguration kann wie zuvor beschrieben sein. Die resultierende Konfiguration sollte etwa so aussehen:

Multiregionales Routing für serverlose Anwendungen (mit Failover)

Regionales Routing einrichten

Ein häufiger Grund für die Bereitstellung von Anwendungen in mehreren Regionen besteht darin, die Anforderungen an die Datenlokalität zu erfüllen. So können Sie beispielsweise sicherstellen, dass Anfragen von europäischen Nutzern immer in einer Region in Europa bearbeitet werden. Zum Einrichten benötigen Sie ein URL-Schema mit separaten URLs für Nutzer aus der EU und aus Nicht-EU-Ländern und müssen EU-Nutzer zu den URLs in der EU leiten.

In einem solchen Szenario würden Sie die URL-Zuordnung verwenden, um Anfragen von bestimmten URLs zu den entsprechenden Regionen zu leiten. Bei einer solchen Konfiguration werden Anfragen für eine Region niemals an eine andere Region gesendet. Dies sorgt für eine Isolierung der Regionen. Wenn dagegen eine Region ausfällt, werden Anfragen nicht zu einer anderen Region geleitet. Diese Konfiguration erhöht also nicht die Verfügbarkeit Ihres Dienstes.

Zum Einrichten des regionalen Routings müssen Sie die Premium-Netzwerkstufe verwenden, damit Sie verschiedene Regionen in einer Weiterleitungsregel kombinieren können.

So richten Sie einen Load-Balancer mit regionalem Routing ein:

1. Richten Sie zwei (vollständig verwaltete) Cloud Run-Dienste in verschiedenen Regionen ein. Angenommen, Sie haben zwei (vollständig verwaltete) Cloud Run-Dienste bereitgestellt: "hello-world-eu" in einer Region in Europa und "hello-world-us" in einer Region in den USA.
2. Erstellen Sie einen externen HTTP(S)-Load-Balancer mit der folgenden Konfiguration:
   1. Richten Sie einen Back-End-Dienst mit einer serverlosen NEG in Europa ein. Die serverlose NEG muss in derselben Region in Europa erstellt werden, in der sich der (vollständig verwaltete) Cloud Run-Dienst befindet.
   2. Richten Sie einen zweiten Back-End-Dienst mit einer anderen serverlosen NEG in den USA ein. Diese serverlose NEG muss in derselben Region in den USA erstellt werden, in der sich der (vollständig verwaltete) Cloud Run-Dienst befindet.
   3. Richten Sie Ihre URL-Zuordnung mit den entsprechenden Host- und Pfadregeln ein, sodass eine Gruppe von URLs zum europäischen Back-End-Dienst leitet. Alle Anfragen werden dagegen zum Back-End-Dienst in den USA geleitet.
   4. Richten Sie Ihre Front-End-Konfiguration mit der Premium-Netzwerkstufe ein.

Der Rest der Konfiguration kann wie zuvor beschrieben sein. Die resultierende Konfiguration sollte etwa so aussehen:

Regionales Routing für serverlose Anwendungen (kein Failover)

URL-Maske verwenden

Beim Erstellen einer serverlosen NEG können Sie, statt einen bestimmten (vollständig verwalteten) Cloud Run-Dienst auszuwählen, eine URL-Maske verwenden, um auf mehrere Dienste zu verweisen, die in derselben Domain bereitgestellt werden. Eine URL-Maske ist eine Vorlage für Ihr URL-Schema. Die serverlose NEG verwendet diese Vorlage, um den Dienstnamen aus der URL der eingehenden Anfrage zu extrahieren und die Anfrage dem entsprechenden Dienst zuzuordnen.

URL-Masken sind besonders nützlich, wenn Ihr Dienst einer benutzerdefinierten Domain zugeordnet ist und nicht der Standardadresse, die Google Cloud für den bereitgestellten Dienst angibt. Eine URL-Maske bietet die Möglichkeit, mehrere Dienste und Versionen mit einer einzigen Regel anzusprechen, selbst wenn Ihre Anwendung ein benutzerdefiniertes URL-Muster verwendet.

Falls Sie es noch nicht getan haben, lesen Sie den Abschnitt zu URL-Masken in der Übersicht zu serverlosen NEGs.

URL-Maske erstellen

Wenn Sie eine URL-Maske für Ihren Load-Balancer erstellen möchten, beginnen Sie mit der URL Ihres Dienstes. In diesem Beispiel wird eine serverlose Beispielanwendung verwendet, die unter https://example.com/login ausgeführt wird. Dies ist die URL, unter der der login-Dienst der Anwendung bereitgestellt wird.

1. Entfernen Sie http oder https aus der URL. Es verbleibt example.com/login.
2. Ersetzen Sie den Dienstnamen durch einen Platzhalter für die URL-Maske.
   1. Cloud Run (vollständig verwaltet): Ersetzen Sie den Namen des (vollständig verwalteten) Cloud Run-Dienstes durch den Platzhalter <service>. Wenn dem (vollständig verwalteten) Cloud Run-Dienst ein Tag zugeordnet ist, ersetzen Sie den Namen des Tags durch den Platzhalter <tag>. In diesem Beispiel lautet die URL-Maske example.com/<service>.
   2. Cloud Functions: Ersetzen Sie den Namen der Funktion durch den Platzhalter <function>. In diesem Beispiel lautet die URL-Maske <function>.example.com.
   3. App Engine: Ersetzen Sie den Namen des Dienstes durch den Platzhalter <service>. Wenn dem Dienst eine Version zugeordnet ist, ersetzen Sie die Version durch den Platzhalter <version>. In diesem Beispiel lautet die URL-Maske example.com/<service>.

3. Optional: Wenn sich der Dienstname (oder die Funktion, die Version oder das Tag) aus dem Pfadabschnitt der URL extrahieren lässt, kann die Domain weggelassen werden. Der Pfadteil der URL-Maske wird durch den ersten Schrägstrich (/) abgetrennt. Wenn in der URL-Maske kein / vorhanden ist, wird die Maske nur für den Host verwendet. Daher kann die URL-Maske in diesem Beispiel auf /<service> oder /<function> reduziert werden.

   Wenn sich der Dienstname aus dem Hostteil der URL extrahieren lässt, können Sie den Pfad in der URL-Maske vollständig weglassen.

   Sie können auch alle Host- oder Subdomain-Komponenten weglassen, die vor dem ersten Platzhalter stehen, sowie alle Pfadkomponenten, die nach dem letzten Platzhalter stehen. In solchen Fällen erfasst der Platzhalter die erforderlichen Informationen für die Komponente.

Hier einige weitere Beispiele zur Veranschaulichung dieser Regeln:

Cloud Run

In dieser Tabelle wird davon ausgegangen, dass Sie eine benutzerdefinierte Domain namens example.com haben und alle (vollständig verwalteten) Cloud Run-Dienste dieser Domain zugeordnet sind.

Dienst, Tag-Name	URL der benutzerdefinierten Domain in Cloud Run (vollständig verwaltet)	URL-Maske
Dienst: login	https://login-home.example.com/web	<Dienst>-home.example.com
Dienst: login	https://example.com/login/web	example.com/<Dienst> oder /<Dienst>
Dienst: login; Tag: test	https://test.login.example.com/web	<Tag>.<Dienst>.example.com
Dienst: login; Tag: test	https://example.com/home/login/test	example.com/home/<Dienst>/<Tag> oder /home/<Dienst>/<Tag>
Dienst: login; Tag: test	https://test.example.com/home/login/web	<Tag>.example.com/home/<Dienst>

Cloud Functions

In dieser Tabelle wird davon ausgegangen, dass Sie eine benutzerdefinierte Domain namens example.com haben und alle Ihre Cloud Functions-Dienste dieser Domain zugeordnet sind.

Funktionsname	Benutzerdefinierte Domain-URL in Cloud Functions	URL-Maske
login	https://example.com/login	/<Funktion>
login	https://example.com/home/login	/home/<Funktion>
login	https://login.example.com	<Funktion>.example.com
login	https://login.home.example.com	<Funktion>.home.example.com

App Engine

In dieser Tabelle wird davon ausgegangen, dass Sie eine benutzerdefinierte Domain namens example.com haben und alle Ihre App Engine-Dienste dieser Domain zugeordnet sind.

Dienstname, Version	Benutzerdefinierte Domain-URL in App Engine	URL-Maske
Dienst: login	https://login.example.com/web	<Dienst>.example.com
Dienst: login	https://example.com/home/login/web	example.com/home/<Dienst> oder /home/<Dienst>
Dienst: login; Version: test	https://test.example.com/login/web	<Version>.example.com/<Dienst>
Dienst: login; Version: test	https://example.com/login/test	example.com/<Dienst>/<Version>

Serverlose NEG mit URL-Maske erstellen

Console

Für einen neuen Load-Balancer können Sie den gleichen End-to-End-Prozess verwenden, wie weiter oben in diesem Thema beschrieben. Geben Sie bei der Konfiguration des Back-End-Dienstes eine URL-Maske ein, statt einen bestimmten Dienst auszuwählen.

Wenn Sie bereits einen Load-Balancer haben, können Sie die Back-End-Konfiguration bearbeiten und die serverlose NEG auf eine URL-Maske statt auf einen bestimmten Dienst verweisen lassen.

So fügen Sie einem vorhandenen Back-End-Dienst eine serverlose NEG hinzu, die auf eine URL-Maske verweist:

1. Öffnen Sie in der Google Cloud Console die Seite "Load-Balancing".
   Zur Seite "Load-Balancing"
2. Klicken Sie auf den Namen des Load-Balancers, dessen Back-End-Dienst Sie bearbeiten möchten.
3. Klicken Sie auf der Seite Details zum Load-Balancer auf Bearbeiten .
4. Klicken Sie auf der Seite HTTP(S)-Load-Balancer bearbeiten auf Back-End-Konfiguration.
5. Klicken Sie auf der Seite Back-End-Konfiguration für den Back-End-Dienst, den Sie ändern möchten, auf Bearbeiten .
6. Klicken Sie auf Back-End hinzufügen.
7. Wählen Sie Serverlose Netzwerk-Endpunktgruppe erstellen aus.
   1. Geben Sie im Feld Name helloworld-serverless-neg ein.
   2. Wählen Sie unter Region die Option us-central1 aus.
   3. Wählen Sie unter Typ des serverlosen Netzwerkendpunktgruppe die Plattform aus, auf der Ihre serverlosen Anwendungen (oder Dienste oder Funktionen) erstellt wurden.
      1. Wählen Sie URL-Maske verwenden aus.
      2. Geben Sie eine URL-Maske ein. Eine Anleitung zum Erstellen einer URL-Maske finden Sie unter URL-Maske erstellen.
      3. Klicken Sie auf Erstellen.
8. Klicken Sie im Fenster Neues Back-End auf Fertig.
9. Klicken Sie auf Aktualisieren.

gcloud: Cloud Run

So erstellen Sie eine serverlose NEG mit der URL-Beispielmaske example.com/<service>:

gcloud compute network-endpoint-groups create helloworld-neg-mask \
    --region=us-central1 \
    --network-endpoint-type=serverless \
    --cloud-run-url-mask="example.com/<service>"

gcloud: Cloud Functions

So erstellen Sie eine serverlose NEG mit der URL-Beispielmaske example.com/<function>:

gcloud compute network-endpoint-groups create helloworld-neg-mask \
    --region=us-central1 \
    --network-endpoint-type=serverless \
    --cloud-function-url-mask="example.com/<function>"

gcloud: App Engine

So erstellen Sie eine serverlose NEG mit der URL-Beispielmaske example.com/<service>:

gcloud compute network-endpoint-groups create helloworld-neg-mask \
    --region=us-central1 \
    --network-endpoint-type=serverless \
    --app-engine-url-mask="example.com/<service>"

Informationen dazu, wie der Load-Balancer mit Problemen bei nicht übereinstimmenden URL-Masken umgeht, finden Sie unter Probleme mit serverlosen NEGs beheben.

Cloud CDN aktivieren

Wenn Sie Cloud CDN für Ihren (vollständig verwalteten) Cloud Run-Dienst aktivieren, können Sie die Inhaltsübermittlung optimieren, indem Sie Inhalte im Cache in der Nähe Ihrer Nutzer speichern.

Sie können Cloud CDN mit dem Befehl gcloud compute backend-services update im Back-End-Dienst des externen HTTP(S)-Load-Balancers aktivieren.

  gcloud compute backend-services update helloworld-backend-service \
    --enable-cdn \
    --global

Cloud CDN wird für Back-End-Dienste mit (vollständig verwalteten) Cloud Run-, Cloud Functions- und App Engine-Back-Ends unterstützt.

Google Cloud Armor aktivieren

Google Cloud Armor ist ein Sicherheitsprodukt, das Schutz vor DDoS-Angriffen (Distributed Denial of Service) für alle GCLB-Proxy-Load-Balancer bietet. Google Cloud Armor stellt außerdem konfigurierbare Sicherheitsrichtlinien für Dienste bereit, auf die über einen externen HTTP(S)-Load-Balancer zugegriffen wird. Informationen zu Google Cloud Armor-Sicherheitsrichtlinien für HTTP(S)-Load-Balancing finden Sie unter Übersicht über die Google Cloud Armor-Sicherheitsrichtlinie.

Obwohl Google Cloud Armor für Back-End-Dienste mit (vollständig verwalteten) Cloud Run-, Cloud Functions- und App Engine-Back-Ends konfiguriert werden kann, gibt es bestimmte Einschränkungen, die mit dieser Funktion verbunden sind, insbesondere bei (vollständig verwalteten) Cloud Run und App Engine. Nutzer mit Zugriff auf die Standard-URLs, die diesen Diensten von Google Cloud zugewiesen werden, können den Load-Balancer umgehen und direkt die Dienst-URLs aufrufen. Dabei werden alle konfigurierten Google Cloud Armor-Sicherheitsrichtlinien umgangen.

Wenn Sie Cloud Functions verwenden, können Sie dies mithilfe der internal-and-gclb-Einstellung für eingehenden Traffic umgehen. So wird gewährleistet, dass Anfragen blockiert werden, die an standardmäßige cloudfunctions.net-URLs oder andere benutzerdefinierte Domains gesendet werden, die über Cloud Functions eingerichtet werden.

Serverlose NEG löschen

Eine Netzwerk-Endpunktgruppe kann nicht gelöscht werden, wenn sie mit einem Back-End-Dienst verknüpft ist. Bevor Sie eine NEG löschen, muss sie vom Back-End-Dienst getrennt sein.

Um eine serverlose NEG aus einem Back-End-Dienst zu entfernen, müssen Sie die Region angeben, in der die NEG erstellt wurde. Sie müssen auch das Flag --global angeben, da helloworld-backend-service eine globale Ressource ist.

gcloud compute backend-services remove-backend helloworld-backend-service \
    --network-endpoint-group=helloworld-serverless-neg \
    --network-endpoint-group-region=us-central1 \
    --global

So löschen Sie die serverlose NEG:

gcloud compute network-endpoint-groups delete helloworld-serverless-neg \
    --region=us-central1

Wenn Sie einen Load-Balancer mit einem serverlosen NEG-Back-End löschen, wird nur der dem Load-Balancer zugeordnete Back-End-Dienst gelöscht. Die serverlose NEG wird nicht automatisch gelöscht. Sie müssen die serverlose NEG manuell löschen, wie in diesem Abschnitt beschrieben.

Nächste Schritte

• Logging und Monitoring verwenden
• Probleme mit serverlosen NEGs beheben