ID de la région
Le REGION_ID
est un code abrégé que Google attribue en fonction de la région que vous sélectionnez lors de la création de votre application. Le code ne correspond pas à un pays ou une province, même si certains ID de région peuvent ressembler aux codes de pays et de province couramment utilisés. Pour les applications créées après février 2020, REGION_ID.r
est inclus dans les URL App Engine. Pour les applications existantes créées avant cette date, l'ID de région est facultatif dans l'URL.
En savoir plus sur les ID de région
Plusieurs méthodes sont disponibles pour assurer la communication entre vos services App Engine ou avec d'autres services, tels que les services Google Cloud et des applications externes.
L'approche la plus simple pour communiquer avec votre service App Engine consiste à envoyer des requêtes HTTP ciblées, dans lesquelles l'URL comprend le nom ou l'ID d'une ressource. Par exemple, vous pouvez inclure l'ID d'un service ou d'une version que vous souhaitez cibler, en plus de l'ID du projet Google Cloud correspondant :
https://VERSION-dot-SERVICE-dot-PROJECT_ID.REGION_ID.r.appspot.com
La longueur combinée de VERSION-dot-SERVICE-dot-PROJECT_ID
(où VERSION
est le nom de votre version, SERVICE
est le nom de votre service et PROJECT_ID
est l'ID de votre projet) ne peut pas comporter plus de 63 caractères et ne peut pas commencer ni se terminer par un trait d'union. Si la longueur combinée comporte plus de 63 caractères, le message d'erreur DNS address could not be
found.
peut s'afficher.
Apprenez-en davantage sur les requêtes dans App Engine :
- Mode de traitement des requêtes : découvrez comment votre application reçoit des requêtes et envoie des réponses.
- Mode de routage des requêtes : découvrez comment cibler vos services, y compris comment définir des URL HTTPS.
- Découvrez comment autoriser les requêtes entre vos services et d'autres services Google Cloud :
Vos services App Engine peuvent également communiquer à l'aide de Pub/Sub, un service de messagerie asynchrone fiable entre plusieurs processus, dont App Engine. Ces processus peuvent être des instances spécifiques de votre application, des services ou même des applications externes.
Pour partager des données entre plusieurs bases de données et votre application App Engine ou une autre application externe, consultez la page Comprendre le stockage des données et des fichiers.
Si vous utilisez les anciens services groupés, vous pouvez également transmettre des requêtes entre services et depuis des services vers des points de terminaison externes à l'aide de l'API URL Fetch.
En outre, les services de l'environnement standard qui résident dans le même projet Google Cloud peuvent également utiliser l'une des API App Engine pour les tâches suivantes :
- Partager une instance memcache unique
- Collaborer en répartissant les tâches entre les services via des files d'attente de tâches
Communication privée
Communication entre les services dans un même projet
Vous pouvez autoriser un service standard App Engine à communiquer avec un autre service App Engine dans le même projet sans avoir à exposer le service de destination à l'Internet public.
Pour autoriser la communication entre les services dans le même projet, procédez comme suit:
Configurez les contrôles d'entrée en ajustant les paramètres d'entrée du service de destination pour autoriser uniquement le trafic "interne".
Le paramètre "interne" n'autorise que les requêtes provenant des réseaux VPC du projet. Cela inclut les ressources App Engine d'une application cliente sur le même réseau lorsque le trafic de sortie est acheminé via un connecteur. Tout autre trafic provenant d'Internet ou d'autres projets Google Cloud, y compris d'autres services App Engine, est bloqué.
Acheminez le trafic via un connecteur d'accès au VPC sans serveur:
Pour chaque version d'App Engine qui envoie du trafic privé vers d'autres points de terminaison d'application, associez la version à un connecteur d'accès au VPC sans serveur appartenant à l'un des réseaux du projet Google Cloud, et non à un réseau VPC partagé.
Assurez-vous que l'accès privé à Google est activé pour le sous-réseau utilisé par le connecteur d'accès au VPC sans serveur.
Configurez l'une des options suivantes:
Les clients souhaitent utiliser la plage d'adresses IP
private.googleapis.com
en ajoutant une entrée DNS pour le nom d'hôte de destination. Suivez la configuration DNS pour ajouter le nom d'hôte DNS, mais veillez à configurer la zone privée pourappspot.com
plutôt quegoogleapis.com
. Assurez-vous également que le trafic est dirigé vers l'adresseappspot.com
de l'application de destination, et non vers un domaine personnalisé. Votre application n'est accessible que sur la plage d'adresses IPprivate.googleapis.com
avec ce domaineappspot.com
.L'application cliente pour envoyer
all-traffic
via le connecteur d'accès au VPC sans serveur, au lieu de configurer des requêtes pour utiliser la plage d'adresses IPprivate.googleapis.com
.
Communication entre les services dans différents projets
Vous pouvez disposer d'un accès privé entre les projets Google Cloud lorsque les applications exécutées dans les projets appartiennent à un réseau VPC partagé configuré pour appeler une application s'exécutant dans le projet hôte du réseau VPC partagé.
Pour utiliser ce modèle, suivez les étapes précédentes afin de permettre la communication entre les services dans un même projet. Dans l'environnement standard, associez chaque version de client à un connecteur d'accès au VPC sans serveur sur le réseau VPC partagé.
Les autres méthodes de communication entre des projets qui utilisent l'accès interne ne sont pas possibles dans App Engine.
Chemins d'URL réservés
Vous ne pouvez pas utiliser les chemins d'URL suivants :
- Chemins d'accès se terminant par
/eventlog
- Chemins commençant par
/_ah/
- Certains chemins se terminant par
z