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. Das Einbinden von REGION_ID.r
in App Engine-URLs ist für vorhandene Anwendungen optional und wird bald für alle neuen Anwendungen erforderlich sein.
Für einen reibungslosen Übergang wird App Engine nach und nach für die Verwendung von Regions-IDs aktualisiert. Wenn Ihr Google Cloud-Projekt noch nicht aktualisiert wurde, wird für Ihre Anwendung keine Regions-ID angezeigt. Da die ID für vorhandene Anwendungen optional ist, müssen Sie keine URLs aktualisieren oder andere Änderungen vornehmen, wenn die Regions-ID für Ihre vorhandenen Anwendungen verfügbar wird.
Auf dieser Seite wird beschrieben, wie HTTP-Anfragen von Nutzern die richtige Version eines Dienstes erreichen. Anfragen können auf folgende Weise weitergeleitet werden:
Wenn Sie Ihre Anwendung über den lokalen Entwicklungsserver testen, weichen die verfügbaren Routing- und Weiterleitungsfunktionen geringfügig ab. Mit der Methode get_hostname können Sie programmatisch URLs erstellen, die sowohl mit Produktions- als auch mit Entwicklungsservern funktionieren.
Weitere Informationen finden Sie unter Routing auf dem Entwicklungsserver.
Routing mit URLs
Sobald 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.
URLs für Dienste und Versionen
Wenn Sie mehrere Dienste in Ihrer Anwendung 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 kein Targeting auf eine bestimmte Version vornehmen müssen.
Sie können mit einem der folgenden Tools die IDs der Dienste und Versionen Ihrer Anwendung abrufen:
Console
In der Cloud Console rufen Sie die entsprechenden Seiten für Instanzen, Dienste und Versionen auf.
gcloud
Führen Sie den Befehl gcloud app instances list
aus, um die Ressourcen-IDs in einem bestimmten 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 Beispiele zu URLs für App Engine, die sowohl die appspot.com
-Domain zeigen, 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 die Anfrage an eine verfügbare Instanz des Dienstes
- 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 kann nicht auf benutzerdefinierte Domains angewendet werden. 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_ID-dot-SERVICE_ID-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
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 Requests basierend auf dem Pfad oder Hostnamen in der Request-URL an einen bestimmten Dienst senden.
Weiterleitungsdatei erstellen
So erstellen Sie eine Weiterleitungsdatei:
Erstellen Sie eine Datei mit dem Namen
dispatch.yaml
entweder im Stammverzeichnis Ihres Projektverzeichnisses oder im Stammverzeichnis Ihresdefault
-Dienstes.Definieren Sie Routingregeln in der Datei, wie in der Referenz zu
dispatch.yaml
erläutert.
Beachten Sie die folgenden Hinweise zu den Routingregeln:
- Sie können bis zu 20 Routingregeln definieren. Jede Regel muss die Elemente
url
undservice
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 Front-End und Worker-Anfragen wie https://simple-sample.uc.r.appspot.com/work/
an ein statisches Back-End 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
Führen Sie den folgenden Befehl aus, um die Weiterleitungsdatei bereitzustellen:
gcloud app deploy dispatch.yaml
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 HTTP(S)-Load-Balancing für serverlose Anwendungen aktiviert ist, können Sie:
Ihre serverlose Anwendung so konfigurieren, dass sie von einer dedizierten IPv4- und/oder IPv6-IP-Adresse bereitgestellt wird, die nicht für andere Dienste freigegeben ist.
Dieselben SSL-Zertifikate und privaten Schlüssel wieder verwenden, 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 oder interagiert nicht mit Routingregeln in der Datei dispatch.yaml
. 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, 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 manuellen Skalierungsinstanzen. Instanzen für automatische und einfache Skalierungsdienste werden dynamisch verwaltet. Der Server weist jedem Dienst einen Port zu. Für die Ausführung bestimmter Clients ist es erforderlich, dass der Server für den Lastenausgleich sorgt und automatisch eine Instanz auswählt. Die Portzuweisungen für die Adressierung jedes Dienstes werden im Log-Nachrichtenstream des Servers angezeigt. Dies sind die Ports für eine Anwendung, die drei Dienste definiert, wobei der Skalierungstyp der Dienste irrelevant ist:
INFO Starting module "default" running at: http://localhost:8084
INFO Starting module "service1" running at: http://localhost:8082
INFO Starting module "service2" running at: http://localhost:8083
Wenn Sie die Adresse eines Dienstes verwenden (z. B. http://localhost:8082/
), wählt der Server eine Instanz des Dienstes aus oder erstellt eine Instanz und sendet die Anfrage an diese Instanz.
Der Server weist jeder Instanz eines Dienstes eindeutige Ports zu. Damit die Ports erkannt werden, müssen Sie den Admin-Server verwenden. Es gibt einen eindeutigen Port für den Admin-Server, der im Nachrichten-Log angegeben wird:
INFO Starting admin server at: http://localhost:8000
Mit dieser Adresse werden Sie zur Admin-Serverkonsole weitergeleitet. Dort können Sie durch Klicken auf Instanzen den dynamischen Status der Instanzen Ihrer Anwendung abrufen:
Für jede manuelle und einfache Instanz wird ein separater Eintrag angezeigt. Die Instanznummern sind Links mit eindeutigen Portadressen für jede Instanz. Sie können den Mauszeiger über einen Link bewegen, um den dieser Instanz zugewiesenen Port anzuzeigen. Oder klicken Sie auf den Link, um eine Anfrage direkt an diese Instanz zu senden.
Weiterleitungsdateien
Enthält Ihre Anwendung einedispatch.yaml
-Datei, enthält der Lognachrichtenstream einen Weiterleistungsport:
INFO Starting dispatcher running at: http://localhost:8080
Anfragen an diesen Port werden gemäß den Regeln in der Weiterleitungsdatei weitergeleitet. Der Server unterstützt keine Regeln für dispatch.yaml
-Dateien mit Hostnamen, z. B. url: "customer1.myapp.com/*"
. Regeln mit relativen Pfadmustern (url: "*/fun"
) funktionieren. Sie können also Instanzen mit URLs wie http://localhost/fun/mobile
erreichen. Der Server meldet einen Fehler im Logstream, wenn Sie versuchen, eine Anwendung mit einer Datei dispatch.yaml
zu starten, die hostbasierte Regeln enthält.
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 seinen Handlern das Element login: admin
hinzu.
Zusätzliche Details zu App Engine-URLs
Regions-ID in URLs verstehen
REGION_ID
ist ein Abkürzungscode, den Google basierend auf 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 Regionen-IDs häufig verwendeten Länder- und Provinzcodes ähneln. Das Einbinden von REGION_ID.r
in App Engine-URLs ist für vorhandene Anwendungen optional und wird bald für alle neuen Anwendungen erforderlich sein.
Für einen reibungslosen Übergang wird App Engine nach und nach für die Verwendung von Regions-IDs aktualisiert. Wenn wir Ihr Google Cloud-Projekt noch nicht aktualisiert haben, wird für Ihre Anwendung keine Regions-ID angezeigt. Da die ID für vorhandene Anwendungen optional ist, müssen Sie keine URLs aktualisieren oder andere Änderungen vornehmen, sobald die Regions-ID für Ihre vorhandenen Anwendungen verfügbar ist.
Mit den folgenden Tools können Sie sich die Regions-ID Ihrer Anwendung ansehen:
Console
In der 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:
Geben Sie den Befehl
gcloud app versions list
ein, um die Versionen eines bestimmten Dienstes aufzulisten. Um beispielsweise die Versionen des Standarddienstes aufzulisten, geben Siegcloud app versions list --service=default
ein.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 Siegcloud 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.