Mode de routage des requêtes

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

Cette page décrit comment les requêtes HTTP des utilisateurs atteignent la version appropriée d'un service. Les requêtes peuvent être acheminées de l'une des manières suivantes :

Routage avec des URL
Routage avec un fichier de distribution
Routage avec Cloud Load Balancing

Ces options ne s'appliquent qu'aux applications déployées. Lorsque vous testez localement, le comportement de routage dépend de l'environnement d'exécution et de développement que vous utilisez.

Notez que si vous utilisez les anciens services groupés pour tester votre application à l'aide du serveur de développement local, les fonctionnalités de routage et de distribution disponibles sont légèrement différentes. Pour créer de manière automatisée des URL fonctionnant à la fois avec des serveurs de production et des serveurs de développement, utilisez la fonction

Routage avec des URL

Une fois votre application exécutée dans App Engine, vous pouvez utiliser l'URL suivante pour lui envoyer des requêtes HTTP :

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

où PROJECT_ID est l'ID du projet Google Cloud contenant l'application.

Cette URL envoie des requêtes au service par défaut de votre application dans la version que vous avez configurée pour recevoir du trafic.

URL des services et des versions

Si vous créez plusieurs services dans votre application, chacun d'eux possède sa propre URL. Chaque version d'un service possède également sa propre URL. Vous pouvez donc déployer et tester une nouvelle version avant de la configurer pour recevoir du trafic.

Les URL de services et de versions spécifiques sont au format suivant :

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

Vous pouvez omettre VERSION-dot- si vous n'avez pas besoin de cibler une version spécifique.

Pour récupérer l'ID des services et des versions de votre application, vous pouvez utiliser l'un des outils suivants :

Console

Dans la console Google Cloud, vous pouvez afficher les pages sur les instances, les services et les versions correspondantes.

gcloud

Exécutez la commande gcloud app instances list pour répertorier les ID de ressources d'un projet Google Cloud spécifique.

API

Pour récupérer les ID de ressources de manière automatisée, consultez les méthodes list de l'API Admin.

Exemples d'URL

Voici quelques exemples d'URL pour App Engine, indiquant à la fois le domaine appspot.com attribué par App Engine à votre application et un domaine personnalisé, que vous pouvez configurer pour votre application.

Envoie la requête à une instance disponible du service default :
```
https://PROJECT_ID.REGION_ID.r.appspot.com
https://CUSTOM_DOMAIN
```
Les requêtes sont reçues par toute version configurée pour le trafic dans le service default.
Envoie une requête à une instance disponible d'un service spécifique :
```
https://SERVICE_ID-dot-PROJECT_ID.REGION_ID.r.appspot.com
https://SERVICE_ID.CUSTOM_DOMAIN
```
Les requêtes sont reçues par toute version configurée pour le trafic dans le service ciblé. Si ce service n'existe pas, la requête est redirigée par routage souple.
Envoie une requête à une instance disponible d'une version spécifique dans le service

Service default :
```
https://VERSION_ID-dot-default-dot-PROJECT_ID.REGION_ID.r.appspot.com
https://VERSION_ID.CUSTOM_DOMAIN
```
Lorsqu'un service n'est pas ciblé, les requêtes sont envoyées au service default.

Routage souple

Si une requête correspond à la partie PROJECT_ID.REGION_ID.r.appspot.com du nom d'hôte, mais inclut un nom de service, de version ou d'instance inexistant, la requête est acheminée vers le service default. Le routage souple ne s'applique pas aux domaines personnalisés. Les requêtes qui leur sont envoyées renvoient un code d'état HTTP 404 si le nom d'hôte n'est pas valide.

Routage ciblé

Les formats d'URL suivants sont assurés d'atteindre leur cible, si celle-ci existe. Ces requêtes ne sont jamais interceptées ni redirigées par les formats que vous avez définis dans votre fichier de distribution :

Envoie la requête à une instance disponible d'un service et d'une version spécifiques :


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

Si vous faites appel à des services avec scaling manuel, vous pouvez cibler une instance et lui envoyer une requête en incluant son ID. L'ID de l'instance est un entier compris entre 0 et le nombre total d'instances en cours d'exécution. Il peut être spécifié comme suit :

Envoie une requête à un service et une version spécifiques dans une instance spécifique :
```
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
```
Remarque : Le ciblage d'une instance n'est pas disponible dans les services configurés pour l'autoscaling ou le scaling de base. L'ID de l'instance doit être un entier compris entre 0 et le nombre total d'instances en cours d'exécution. Quels que soient le type de scaling ou la classe d'instance, vous ne pouvez pas envoyer une requête à une instance spécifique sans cibler un service ou une version au sein de cette instance.

Routage avec un fichier de distribution

Vous pouvez créer un fichier de distribution afin de remplacer les règles de routage d'App Engine basées sur l'URL et de définir vos propres règles de routage personnalisées. Avec un fichier de distribution, vous pouvez envoyer des requêtes entrantes à un service spécifique en fonction du chemin d'accès ou du nom d'hôte indiqué dans l'URL de la requête.

Créer un fichier de distribution

Pour créer un fichier de distribution, procédez comme suit :

Créez un fichier nommé dispatch.yamlà la racine du répertoire de votre projet ou dans le répertoire racine du service default.
Définissez des règles de routage dans le fichier, comme décrit dans la documentation de référence sur le fichier dispatch.yaml.

Notez les points suivants concernant les règles de routage :

Vous pouvez définir jusqu'à 20 règles de routage. Chaque règle doit contenir les éléments url et service.
Les règles doivent utiliser des formats d'URL HTTP incluant la notation "." pour séparer les sous-domaines. Les URL définies avec la notation HTTPS "-dot-" ne sont pas acceptées.
Les règles s'appliquent également aux URL que vous définissez dans votre fichier cron.yaml.

Par exemple, vous pouvez créer un fichier de distribution pour acheminer les requêtes mobiles, telles que https://simple-sample.uc.r.appspot.com/mobile/, vers une interface mobile, et les requêtes de nœud de calcul, telles que https://simple-sample.uc.r.appspot.com/work/, vers un backend statique :

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

Déployer le fichier de distribution

Pour déployer le fichier de distribution à l'aide de gcloud, exécutez la commande suivante :

gcloud app deploy dispatch.yaml

Routage avec Cloud Load Balancing

Cloud Load Balancing est un produit distinct qui permet des configurations réseau avancées pour toutes vos applications exécutées sur Google Cloud.

Lorsque l'équilibrage de charge HTTP(S) est activé pour les applications sans serveur, vous avez les possibilités suivantes :

Configurer votre application sans serveur pour qu'elle soit diffusée à partir d'une adresse IP IPv4 et/ou IPv6 dédiée non partagée avec d'autres services.
Réutiliser les mêmes certificats SSL et clés privées que pour Compute Engine, Google Kubernetes Engine et Cloud Storage. Cela évite d'avoir à gérer des certificats distincts pour les applications sans serveur.

L'équilibreur de charge n'interfère pas avec les règles de routage de votre fichier dispatch.yaml et n'interagit pas avec elles. Les règles dispatch.yaml ne sont évaluées que lorsqu'un NEG sans serveur dirige le trafic vers App Engine.

Veuillez noter les points suivants :

Nous vous recommandons d'utiliser des contrôles d'entrée afin que votre application ne reçoive que les requêtes envoyées par l'équilibreur de charge (et par le VPC le cas échéant). Sinon, les utilisateurs peuvent se servir de l'URL App Engine de votre application pour contourner l'équilibreur de charge, les règles de sécurité Google Cloud Armor, les certificats SSL et les clés privées qui sont transmises via l'équilibreur de charge.

Informations supplémentaires sur les URL App Engine

Comprendre l'ID de région dans les URL

Vous pouvez utiliser les outils suivants pour afficher l'ID de région de votre application :

Console

Dans la console Google Cloud, vous pouvez afficher les URL des instances, des services et des versions de votre application.

Toutes ces URL incluent l'ID de région.

gcloud

Lorsque vous déployez une application ou un service, la commande gcloud app deploy affiche l'URL une fois le déploiement réussi. Cette URL inclut l'ID de région.

Pour afficher l'URL d'un service déjà déployé, procédez comme suit :

Saisissez la commande gcloud app versions list pour répertorier les versions d'un service spécifique. Par exemple, pour répertorier les versions du service par défaut, saisissez gcloud app versions list --service=default.
Saisissez la commande gcloud app versions describe. Le résultat de cette commande inclut l'URL de version avec l'ID de région de l'application. Par exemple, pour décrire la version 20191023t101741 du service par défaut, saisissez gcloud app versions describe 20191023t101741 --service=default.

Le nom de domaine est inclus dans les données de la requête

Le nom de domaine utilisé pour la requête est inclus dans les données de la requête qui sont transmises à l'application. Par conséquent, vous pouvez utiliser ces données pour contrôler le mode de réponse de votre application en fonction du nom de domaine dans la requête. Par exemple, si vous souhaitez rediriger le trafic vers un domaine officiel, vous pouvez encoder votre application pour qu'elle vérifie l'en-tête Host de la requête et réponse sur la base du nom de domaine.