Anfragerouting

Regions-ID

REGION_ID ist ein abgekürzter Code, den Google anhand der Region zuweist, die Sie beim Erstellen Ihrer Anwendung ausgewählt haben. Der Code bezieht sich nicht auf ein Land oder eine Provinz, auch wenn einige Regions-IDs häufig verwendeten Länder- und Provinzcodes ähneln können. Bei Anwendungen, die nach Februar 2020 erstellt wurden, ist REGION_ID.r in den App Engine-URLs enthalten. Bei Anwendungen, die vor diesem Datum erstellt wurden, ist die Regions-ID in der URL optional.

Hier finden Sie weitere Informationen zu Regions-IDs.

OK

Auf dieser Seite wird beschrieben, wie HTTP-Anfragen von Nutzern die richtige Version eines Dienstes erreichen. Anfragen können so weitergeleitet werden:

• Routing mit URLs

• Routing mit einer Weiterleitungsdatei

• Routing mit Cloud Load Balancing

Wenn Sie Ihre Anwendung über den lokalen Entwicklungsserver testen, weichen die verfügbaren Routing- und Weiterleitungsfunktionen geringfügig ab. Zum programmatischen Erstellen von URLs, die sowohl mit Produktions- als auch mit Entwicklungsservern kompatibel sind, können Sie die Methode ModulesService.getVersionHostname verwenden.

Weitere Informationen finden Sie unter Routing auf dem Entwicklungsserver.

Routing mit URLs

Wenn Ihre Anwendung in App Engine ausgeführt wird, können Sie mit der folgenden URL HTTP-Anfragen an die Anwendung senden:
https://PROJECT_ID.REGION_ID.r.appspot.com

Dabei ist PROJECT_ID die ID des Google Cloud-Projekts, das die Anwendung enthält.

Diese URL sendet Anfragen an den Standarddienst der Anwendung in der Version, die Sie für den Empfang von Traffic konfiguriert haben.

Hinweis: Wir empfehlen, das HTTPS-Protokoll zu verwenden, um Anfragen an Ihre Anwendung zu senden. HTTPS-Anfragen, die an REGION_ID.r.appspot.com gesendet werden, müssen zur Trennung von Subdomains die Zeichenfolge -dot- anstelle von . verwenden. Sie können die einfache URL-Notation . mit Ihren eigenen benutzerdefinierten Domains und mit HTTP-Anfragen verwenden.

URLs für Dienste und Versionen

Wenn Sie in Ihrer Anwendung mehrere Dienste erstellen, hat jeder Dienst eine eigene URL. Jede Version eines Dienstes hat auch eine eigene URL, sodass Sie eine neue Version bereitstellen und testen können, bevor Sie diese Version für den Empfang von Traffic konfigurieren.

Die URLs für bestimmte Dienste und Versionen haben das folgende Format:

VERSION-dot-SERVICE-dot-PROJECT_ID.REGION_ID.r.appspot.com

Sie können VERSION-dot- weglassen, wenn Sie keine bestimmte Version verwenden müssen.

Mit den folgenden Tools können Sie die IDs der Dienste und Versionen Ihrer Anwendung abrufen:

Console

In der Google Cloud Console rufen Sie die entsprechenden Seiten Instanzen, Dienste und Versionen auf.

gcloud

Führen Sie den Befehl gcloud app instances list aus, um die Ressourcen-IDs in einem bestimmten Google Cloud-Projekt aufzulisten.

API

Informationen zum programmgesteuerten Abrufen von Ressourcen-IDs finden Sie unter den list-Methoden der Admin API.

Beispiel-URLs

Hier sind einige Beispiel-URLs für App Engine, die sowohl die appspot.com-Domain enthalten, die App Engine Ihrer Anwendung zuweist, als auch eine benutzerdefinierte Domain, die Sie für Ihre Anwendung einrichten können.

• Sendet die Anfrage an eine verfügbare Instanz des Dienstes default:

  
  https://PROJECT_ID.REGION_ID.r.appspot.com
  https://CUSTOM_DOMAIN

  Anfragen werden von jeder Version empfangen, die für Traffic im Dienst default konfiguriert ist.

• Sendet eine Anfrage an eine verfügbare Instanz eines bestimmten Dienstes:

  
  https://SERVICE_ID-dot-PROJECT_ID.REGION_ID.r.appspot.com
  https://SERVICE_ID.CUSTOM_DOMAIN

  Anfragen werden von jeder Version empfangen, die im Zieldienst für Traffic konfiguriert ist. Wenn der Zieldienst nicht vorhanden ist, wird die Anfrage über Soft-Routing verarbeitet.

• Sendet eine Anfrage an eine verfügbare Instanz einer bestimmten Version im

  Dienst default:

  
  https://VERSION_ID-dot-default-dot-PROJECT_ID.REGION_ID.r.appspot.com
  https://VERSION_ID.CUSTOM_DOMAIN

  Wenn kein Dienst als Ziel vorgesehen ist, werden Anfragen an den Dienst default gesendet.

Soft-Routing

Wenn eine Anfrage mit dem Abschnitt PROJECT_ID.REGION_ID.r.appspot.com des Hostnamens übereinstimmt, aber einen Dienst-, Versions- oder Instanznamen enthält, der nicht vorhanden ist, wird die Anfrage an den Dienst default weitergeleitet. Dieses Soft-Routing wird nicht auf benutzerdefinierte Domains angewendet. Anfragen an solche Domains geben bei ungültigem Hostnamen den HTTP-Statuscode 404 zurück.

Gezieltes Routing

Die folgenden URL-Muster erreichen garantiert ihr Ziel, wenn es vorhanden ist. Diese Anfragen werden durch die Muster, die in Ihrer Weiterleitungsdatei definiert sind, nicht abgefangen und nicht umgeleitet:

• Sendet die Anfrage an eine verfügbare Instanz eines bestimmten Dienstes und einer bestimmten Version:

  
  https://VERSION-dot-SERVICE-dot-PROJECT_ID.REGION_ID.r.appspot.com
  https://VERSION_ID.SERVICE_ID.PROJECT_ID.CUSTOM_DOMAIN

• Wenn Sie manuell skalierte Dienste verwenden, können Sie durch Angabe der Instanz-ID eine Anfrage gezielt an eine bestimmte Instanz senden. Die Instanz-ID ist eine Ganzzahl zwischen 0 und der Gesamtzahl der ausgeführten Instanzen. Sie kann in folgender Weise festgelegt werden:

  Sendet eine Anfrage an einen bestimmten Dienst und eine bestimmte Version innerhalb einer spezifischen Instanz:

  https://INSTANCE_ID-dot-VERSION_ID-dot-SERVICE_ID-dot-PROJECT_ID.REGION_ID.r.appspot.com
  https://INSTANCE_ID.VERSION_ID.SERVICE_ID.CUSTOM_DOMAIN

  Hinweis: Gezielte Anfragen an eine Instanz werden in Diensten, die für die automatische oder einfache Skalierung konfiguriert sind, nicht unterstützt. Die Instanz-ID muss eine Ganzzahl zwischen 0 und der Gesamtzahl der ausgeführten Instanzen sein. Unabhängig davon, welchen Skalierungstyp oder welche Instanzklasse Sie verwenden, muss beim Senden einer Anfrage an eine bestimmte Instanz immer auf einen Dienst oder eine Version innerhalb dieser Instanz als Ziel verwiesen werden.

Routing mit einer Weiterleitungsdatei

Sie können eine Weiterleitungsdatei erstellen, um die URL-basierten Routingregeln von App Engine zu überschreiben und eigene benutzerdefinierte Routingregeln festzulegen. Mit einer Weiterleitungsdatei können Sie eingehende Anfragen auf Basis des Pfades oder Hostnamens in der Anfrage-URL an einen bestimmten Dienst senden.

Weiterleitungsdatei erstellen

So erstellen Sie eine Weiterleitungsdatei:

1. Erstellen Sie eine Datei mit dem Namen dispatch.yaml im selben Verzeichnis wie die anderen Konfigurationsdateien, z. B. app.yaml.

2. Definieren Sie Routingregeln in der Datei, wie in der Referenz zu dispatch.yaml beschrieben.

Beachten Sie die folgenden Hinweise zu den Routingregeln:

• Sie können bis zu 20 Routingregeln definieren. Jede Regel muss die Elemente url und service enthalten.
• Die Regeln müssen HTTP-URL-Muster verwenden, die die Notation „.“ zum Trennen von Subdomains enthalten. URLs, die mit der HTTPS-Notation „-dot-“ definiert sind, werden nicht unterstützt.
• Die Regeln gelten auch für die URLs, die Sie in der Cron-Datei definieren.

Sie können z. B. eine Weiterleitungsdatei erstellen, um Mobilgeräteanfragen wie https://simple-sample.uc.r.appspot.com/mobile/ an ein mobiles Frontend und Worker-Anfragen wie https://simple-sample.uc.r.appspot.com/work/ an ein statisches Backend weiterzuleiten:

dispatch:
  # Send all mobile traffic to the mobile frontend.
  - url: "*/mobile/*"
    service: mobile-frontend

  # Send all work to the one static backend.
  - url: "*/work/*"
    service: static-backend

Weiterleitungsdatei bereitstellen

Verwenden Sie je nach Umgebung einen der folgenden Befehle in dem Verzeichnis mit der Weiterleitungsdatei, um die Konfigurationsdatei für die Weiterleitung bereitzustellen, ohne die aktuell verwendete Version zu ändern:

gcloud

gcloud app deploy dispatch.yaml

Maven

mvn appengine:deployDispatch dispatch.yaml

Gradle

gradle appengineDeployDispatch dispatch.yaml

IDE

Wenn Sie IntelliJ oder Eclipse verwenden, wählen Sie im Bereitstellungsformular die einzelnen Konfigurationsdateien aus, die bereitgestellt werden sollen.

Routing mit Cloud Load Balancing

Cloud Load Balancing ist ein separates Produkt, das erweiterte Netzwerkkonfigurationen für alle in Google Cloud ausgeführten Anwendungen ermöglicht.

Wenn das HTTP(S)-Load-Balancing für serverlose Anwendungen aktiviert ist, haben Sie folgende Möglichkeiten:

• Sie können Ihre serverlose Anwendung so konfigurieren, dass sie über eine dedizierte IPv4- und/oder IPv6-IP-Adresse bereitgestellt wird, die nicht für andere Dienste freigegeben ist.

• Sie können dieselben SSL-Zertifikate und privaten Schlüssel wiederverwenden, die Sie für Compute Engine, Google Kubernetes Engine und Cloud Storage verwenden. Dadurch müssen keine separaten Zertifikate für serverlose Anwendungen verwaltet werden.

Der Load-Balancer beeinträchtigt nicht die Routingregeln in der Datei dispatch.yaml und interagiert auch nicht mit ihnen. Die dispatch.yaml-Regeln werden erst ausgewertet, wenn eine serverlose NEG den Traffic an App Engine weiterleitet.

Wichtige Hinweise:

• Wir empfehlen die Verwendung von Steuerelementen für eingehenden Traffic, damit Ihre Anwendung nur Anfragen empfängt, die vom Load-Balancer (und ggf. von der VPC) gesendet werden. Andernfalls können Nutzer die App Engine-URL Ihrer Anwendung verwenden, um den Load-Balancer, die Google Cloud Armor-Sicherheitsrichtlinien, SSL-Zertifikate und private Schlüssel zu umgehen, die über den Load-Balancer weitergegeben werden.

Routing auf dem Entwicklungsserver

Instanzadressen ermitteln

Der lokale Entwicklungsserver erstellt beim Start alle Instanzen. Beachten Sie, dass Instanzen mit einfacher Skalierung aktuell auf dem lokalen Entwicklungsserver nicht unterstützt werden. Jeder erstellten Instanz wird ein eigener Port zugewiesen. Die Portzuweisungen werden im Protokollnachrichtenstream des Servers angezeigt. Webclients können mit einer bestimmten Instanz kommunizieren, indem sie auf den Port der Instanz verweisen. Für automatisch skalierte Dienste werden nur eine Instanz und ein Port erstellt. Im Serverprotokoll sieht das so aus (beachten Sie, dass Dienste in der Vergangenheit Module genannt wurden):

INFO: Module instance service-auto is running at http://localhost:37251/

Jeder Instanz eines manuell skalierten Dienstes wird ein eindeutiger Port zugewiesen:

INFO: Module instance service-manual instance 0 is running at http://localhost:43190/
INFO: Module instance service-manual instance 1 is running at http://localhost:52642/

Darüber hinaus wird jedem manuell skalierten Dienst ein zusätzlicher Port zugewiesen, sodass Clients auf den Dienst zugreifen können, ohne eine bestimmte Instanz anzugeben. Anfragen an diesen Port werden automatisch an eine der konfigurierten Instanzen weitergeleitet:

INFO: Module instance service-manual is running at http://localhost:12361/

Die folgende Tabelle zeigt, wie diese Dienste auf dem Entwicklungsserver und in der App Engine-Umgebung aufgerufen werden können:

Dienst	Instanz	Adresse des Entwicklungsservers	App Engine-Adresse
service-auto	(nicht verwendet)	http://localhost:37251/	https://v1-dot-service-auto-dot-PROJECT_ID.REGION_ID.r.appspot.com/
service-manual	0	http://localhost:43190/	https://0-dot-v1-dot-service-manual-dot-PROJECT_ID.REGION_ID.r.appspot.com/

wird vom lokalen Entwicklungsserver verwendet. Weitere Informationen finden Sie unter Apache Maven oder Gradle.

Weiterleitungsdateien

Beim Ausführen des lokalen Entwicklungsservers werden alle Weiterleitungsdateien ignoriert. Gezielte Anfragen an Instanzen können nur über die zugehörigen Ports gesendet werden.

Zugriff auf einen Dienst beschränken

Alle Dienste sind standardmäßig öffentlich. Wenn Sie den Zugriff auf einen Dienst beschränken möchten, fügen Sie das Element <role-name>admin</role-name> zur Sicherheitsbeschränkung des Dienstes hinzu.

Zusätzliche Details zu App Engine-URLs

Regions-ID in URLs

REGION_ID ist ein abgekürzter Code, den Google anhand der Region zuweist, die Sie beim Erstellen Ihrer Anwendung ausgewählt haben. Der Code bezieht sich nicht auf ein Land oder eine Provinz, auch wenn einige Regions-IDs häufig verwendeten Länder- und Provinzcodes ähneln können. Bei Anwendungen, die nach Februar 2020 erstellt wurden, ist REGION_ID.r in den App Engine-URLs enthalten. Bei Anwendungen, die vor diesem Datum erstellt wurden, ist die Regions-ID in der URL optional.

Mit den folgenden Tools können Sie sich die Regions-ID Ihrer Anwendung ansehen:

Console

In der Google Cloud Console können Sie die URLs der Instanzen, Dienste und Versionen Ihrer Anwendung anzeigen.

Alle diese URLs enthalten die Regions-ID.

gcloud

Wenn Sie eine Anwendung oder einen Dienst bereitstellen, zeigt der Befehl gcloud app deploy die URL nach erfolgreicher Bereitstellung an. Diese URL enthält die Regions-ID.

So zeigen Sie die URL für einen Dienst an, der bereits bereitgestellt ist:

1. Geben Sie den Befehl gcloud app versions list ein, um die Versionen eines bestimmten Dienstes aufzulisten. Zum Auflisten der Versionen des Standarddienstes geben Sie beispielsweise gcloud app versions list --service=default ein.

2. Geben Sie den Befehl gcloud app versions describe ein. Die Ausgabe dieses Befehls enthält die Versions-URL mit der Regions-ID der Anwendung. Geben Sie gcloud app versions describe 20191023t101741 --service=default ein, um beispielsweise die Version 20191023t101741 für den Standarddienst zu beschreiben.

Der Domainname ist in den Anfragedaten enthalten

Der für die Anfrage verwendete Domainname ist in den Anfragedaten enthalten, die an die Anwendung übergeben werden. Daher lässt sich mithilfe der Anfragedaten steuern, wie die Anwendung auf Basis des Domainnamens in der Anfrage antwortet. Wenn Sie beispielsweise zu einer offiziellen Domain weiterleiten möchten, können Sie die Anwendung so programmieren, dass der Anfrageheader Host überprüft und dann auf Basis des Domainnamens entsprechend geantwortet wird.