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 zulassen, dass ein App Engine-Standarddienst mit einem anderen App Engine-Dienst im selben Projekt kommuniziert, ohne den Zieldienst für das öffentliche Internet verfügbar zu machen.
So lassen Sie die Kommunikation zwischen Diensten im selben Projekt zu:
Sie konfigurieren die Steuerelemente für eingehenden Traffic, indem Sie die Einstellungen für eingehenden Traffic des Zieldienstes anpassen, um nur „internen“ Traffic zuzulassen.
Die Einstellung „intern“ lässt nur Anfragen von den VPC-Netzwerken des Projekts zu. Dazu gehören App Engine-Ressourcen von einer Clientanwendung im selben Netzwerk, wenn ausgehender Traffic über einen Connector weitergeleitet wird. Der gesamte andere Traffic aus dem Internet oder anderen Google Cloud-Projekten, einschließlich anderer App Engine-Dienste, wird blockiert.
Leiten Sie den Traffic über einen Connector für serverlosen VPC-Zugriff weiter:
Hängen Sie für jede App Engine-Version, die privaten Traffic an andere Anwendungsendpunkte sendet, die Version an einen Connector für serverlosen VPC-Zugriff an, der zu einem der eigenen Netzwerke des Google Cloud-Projekts gehört, nicht zu einem freigegebenen VPC-Netzwerk.
Achten Sie darauf, dass der private Google-Zugriff für das Subnetz aktiviert ist, das vom Connector für serverlosen VPC-Zugriff verwendet wird.
Konfigurieren Sie eine der folgenden Optionen:
Clientanfragen zur Verwendung des IP-Bereichs
private.googleapis.com
durch Hinzufügen eines DNS-Eintrags für den Zielhostnamen. Folgen Sie der DNS-Konfiguration, um den DNS-Hostnamen hinzuzufügen. Achten Sie jedoch darauf, die private Zone fürappspot.com
statt fürgoogleapis.com
zu konfigurieren. Achten Sie außerdem darauf, dass der Traffic an dieappspot.com
-Adresse der Zielanwendung weitergeleitet wird und nicht an eine benutzerdefinierte Domain. Ihre Anwendung kann nur mit dieserappspot.com
-Domain im IP-Bereichprivate.googleapis.com
erreicht werden.Die Client-App soll über den Connector für serverlosen VPC-Zugriff
all-traffic
senden, 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 Anwendungen, die in Projekten ausgeführt werden, zu einem freigegebenen VPC-Netzwerk gehören, das für das Aufrufen einer Anwendung konfiguriert ist, die im Hostprojekt des freigegebenen VPC-Netzwerks ausgeführt wird.
Führen Sie die vorherigen Schritte für die Kommunikation zwischen Diensten im selben Projekt aus, um dieses Muster zu verwenden. Hängen Sie in der Standardumgebung jede Clientversion an einen Connector für serverlosen VPC-Zugriff im freigegebenen VPC-Netzwerk an.
Andere Kommunikationsmethoden zwischen Projekten, die internen Zugriff haben, sind in 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