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.
Für die Kommunikation zwischen Ihren App Engine-Diensten oder mit anderen Diensten einschließlich Google Cloud-Diensten und externen Anwendungen stehen verschiedene Methoden zur Verfügung.
Am einfachsten ist die Kommunikation in Form gezielter HTTP-Anfragen an den App Engine-Dienst. Dabei enthält die URL den Namen oder die ID einer Ressource. Sie können beispielsweise zusätzlich zur entsprechenden Google Cloud-Projekt-ID die ID des Dienstes oder der Version angeben, die aufgerufen werden soll:
https://VERSION-dot-SERVICE-dot-PROJECT_ID.REGION_ID.r.appspot.com
Beachten Sie, dass bei der kombinierten Länge von VERSION-dot-SERVICE-dot-PROJECT_ID
, wobei VERSION
der Name Ihrer Version, SERVICE
der Name des Dienstes und PROJECT_ID
Ihre Projekt-ID ist, die maximal 63 Zeichen lang sein und nicht mit einem Bindestrich beginnen oder enden darf. Wenn die kombinierte Länge mehr als 63 Zeichen beträgt, wird möglicherweise Fehler DNS address could not be
found.
angezeigt.
Weitere Informationen zu Anfragen in App Engine:
- Anfrageverarbeitung: Erfahren Sie, wie Ihre Anwendung Anfragen empfängt und Antworten sendet.
- Anfragerouting: Erfahren Sie, wie Sie Ihre Dienste gezielt auswählen und HTTPS-URLs definieren.
- Erfahren Sie, wie die Anfragen zwischen Ihren Diensten und anderen Google Cloud-Diensten autorisiert werden:
Ihre App Engine-Dienste können auch über Pub/Sub kommunizieren. Damit wird ein zuverlässiges asynchrones Messaging mit m:n-Beziehung zwischen Prozessen einschließlich App Engine bereitgestellt. Bei diesen Prozessen kann es sich um einzelne Instanzen Ihrer Anwendung, um Dienste oder auch um externe Anwendungen handeln.
Weitere Informationen zur gemeinsamen Nutzung von Daten in Datenbanken und der App Engine-Anwendung bzw. einer anderen externen Anwendung finden Sie unter Informationen zu Daten- und Dateispeichern.
Wenn Sie die gebündelten Legacy-Dienste verwenden, können Sie über die URL Fetch API auch Anfragen zwischen verschiedenen Diensten und von Diensten an externe Endpunkte übergeben.
Darüber hinaus besteht für Dienste in der Standardumgebung im selben Google Cloud-Projekt die Möglichkeit, eine App Engine API für die folgenden Aufgaben zu verwenden:
- einzelne memcache-Instanz freigeben
- Durch dienstübergreifende Zuweisung von Aufgaben über Aufgabenwarteschlangen zusammenarbeiten
Private Kommunikation
Kommunikation zwischen Diensten im selben Projekt
Sie können einem App Engine-Standarddienst erlauben, mit einem anderen App Engine-Dienst im selben Projekt zu kommunizieren, ohne den Zieldienst dem öffentlichen Internet aussetzen zu müssen.
So erlauben Sie die Kommunikation zwischen Diensten im selben Projekt:
Sie konfigurieren die Steuerelemente für eingehenden Traffic, indem Sie die Einstellungen für eingehenden Traffic des Zieldienstes anpassen, um nur „internen“ Traffic zuzulassen.
Bei der Einstellung „intern“ sind nur Anfragen von den VPC-Netzwerken des Projekts zulässig. Dazu gehören auch App Engine-Ressourcen aus einer Clientanwendung im selben Netzwerk, wenn ausgehender Traffic über einen Connector weitergeleitet wird. Alle anderen Zugriffe aus dem Internet oder anderen Google Cloud-Projekten, einschließlich anderer App Engine-Dienste, werden blockiert.
Leiten Sie den Traffic über einen Connector für serverlosen VPC-Zugriff weiter:
Ordnen Sie für jede App Engine-Version, die privaten Traffic an andere App-Endpunkte sendet, einen Connector für den serverlosen VPC-Zugriff zu, der zu einem der eigenen Netzwerke des Google Cloud-Projekts gehört, nicht zu einem freigegebenen VPC-Netzwerk.
Der private Google-Zugriff muss für das Subnetz aktiviert sein, das vom Connector für serverlosen VPC-Zugriff verwendet wird.
Konfigurieren Sie eine der folgenden Optionen:
Der Client fordert die Verwendung des IP-Bereichs
private.googleapis.com
an, indem er einen DNS-Eintrag für den Ziel-Hostnamen hinzufügt. Folgen Sie der DNS-Konfiguration, um den DNS-Hostnamen hinzuzufügen. Achten Sie aber darauf, die private Zone fürappspot.com
und nicht fürgoogleapis.com
zu konfigurieren. Außerdem muss der Traffic an dieappspot.com
-Adresse der Ziel-App und nicht an eine benutzerdefinierte Domain weitergeleitet werden. Ihre App kann nur über den IP-Bereichprivate.googleapis.com
und mit dieserappspot.com
-Domain erreicht werden.Die Client-Anwendung, die
all-traffic
über den Connector für serverlosen VPC-Zugriff sendet, anstatt Anfragen für die Verwendung des IP-Bereichsprivate.googleapis.com
zu konfigurieren.
Kommunikation zwischen Diensten in verschiedenen Projekten
Sie können privaten Zugriff zwischen Google Cloud-Projekten haben, wenn in Projekten ausgeführte Apps zu einem freigegebenen VPC-Netzwerk gehören, das so konfiguriert ist, dass eine App aufgerufen wird, die im Hostprojekt des freigegebenen VPC-Netzwerks ausgeführt wird.
Wenn Sie dieses Muster verwenden möchten, folgen Sie der Anleitung zum Kommunizieren zwischen Diensten im selben Projekt. Ordnen Sie in der Standardumgebung jede Clientversion einem Connector für den serverlosen VPC-Zugriff im freigegebenen VPC-Netzwerk zu.
Andere Methoden der Kommunikation zwischen Projekten mit internem Zugriff sind in der App Engine nicht möglich.
Reservierte URL-Pfade
Die folgenden URL-Pfade können nicht verwendet werden:
- Pfade, die auf
/eventlog
enden - Pfade, die mit
/_ah/
beginnen - Einige Pfade, die auf
z
enden