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 :

Si vous testez votre application à l'aide du serveur de développement local, les fonctionnalités de routage et de répartition disponibles sont légèrement différentes. Pour créer de façon automatisée des URL fonctionnant à la fois avec des serveurs de production et des serveurs de développement, utilisez la méthode get_hostname.

Consultez la section routage sur le serveur de développement pour en savoir plus.

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, vous pouvez afficher les pages Instances, Services et Versions correspondantes.

gcloud

Exécutez la commande gcloud app instances list pour répertorier les ID de ressources d'un projet 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

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 :

  1. Créez un fichier nommé dispatch.yaml à la racine du répertoire de votre projet ou dans le répertoire racine du service default.

  2. 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.

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, 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.

Routage sur le serveur de développement

Découvrir les adresses d'instance

Le serveur de développement local crée toutes les instances de scaling manuel au démarrage. Les instances des services de scaling automatique et de base sont gérées de manière dynamique. Le serveur attribue un port à chaque service, et les clients peuvent compter sur le serveur pour équilibrer la charge et sélectionner une instance automatiquement. Les attributions de port pour l'adressage de chaque service s'affichent dans le flux de messages du journal du serveur. Voici les ports attribués à une application qui définit trois services (le type de scaling de chaque service n'a pas d'incidence) :

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

Lorsque vous utilisez l'adresse d'un service (par exemple, http://localhost:8082/), le serveur crée ou sélectionne une instance du service et lui envoie la requête.

Le serveur attribue des ports uniques à chaque instance d'un service. Pour découvrir ces ports, vous devez utiliser le serveur d'administration. Ce dernier dispose d'un port unique qui s'affiche dans le journal des messages :

INFO Starting admin server at: http://localhost:8000

Cette adresse vous permet d'accéder à la console du serveur d'administration. Vous pouvez ensuite cliquer sur Instances pour afficher l'état dynamique des instances de votre application :

Capture d'écran de la console d'administration dev_appserver

Une entrée distincte s'affiche pour chaque instance manuelle et de base. Les numéros d'instance sont des liens renvoyant à des adresses de port uniques pour chaque instance. Passez la souris sur un lien pour afficher le port attribué à cette instance ou cliquez sur le lien pour envoyer directement une requête à cette instance.

Fichiers de distribution

Si votre application inclut un fichier dispatch.yaml, le flux de messages du journal inclut un port de distribution :

INFO Starting dispatcher running at: http://localhost:8080

Les requêtes adressées à ce port sont acheminées conformément aux règles du fichier de distribution. Le serveur n'accepte pas les règles du fichier dispatch.yaml qui incluent des noms d'hôte (par exemple, url: "customer1.myapp.com/*"). Les règles comportant des formats de chemins relatifs (url: "*/fun") sont acceptées. Vous pouvez donc utiliser des URL telles que http://localhost/fun/mobile pour atteindre des instances. Le serveur signale une erreur dans le flux du journal si vous tentez de démarrer une application avec un fichier dispatch.yaml contenant des règles basées sur l'hôte.

Restreindre l'accès à un service

Tous les services sont publics par défaut. Si vous souhaitez limiter l'accès à un service, ajoutez l'élément login: admin à son élément handlers.

Informations supplémentaires sur les URL App Engine

Comprendre l'ID de région dans les URL

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.

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

Console

Dans la console, 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 :

  1. 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.

  2. 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éponde sur la base du nom de domaine.