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. L'ajout de REGION_ID.r dans les URL App Engine est facultatif pour les applications existantes. Il sera bientôt obligatoire pour toutes les applications nouvelles.

Pour assurer une transition en douceur, nous mettons lentement à jour App Engine afin d'utiliser les ID de région. Si nous n'avons pas encore mis à jour votre projet Google Cloud, vous ne verrez pas d'ID de région pour votre application. Étant donné que l'ID est facultatif pour les applications existantes, vous n'avez pas besoin de mettre à jour les URL ni d'effectuer d'autres modifications une fois l'ID de région disponible pour vos applications existantes.

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 :

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.

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

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 Cloud 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 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_ID-dot-SERVICE_ID-dot-PROJECT_ID.REGION_ID.r.appspot.com
    https://VERSION_ID.SERVICE_ID.PROJECT_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). Sans quoi les utilisateurs munis de l'URL App Engine de votre application peuvent contourner l'équilibreur de charge, les stratégies 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

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. L'ajout de REGION_ID.r dans les URL App Engine est facultatif pour les applications existantes. Il sera bientôt obligatoire pour toutes les applications nouvelles.

Pour assurer une transition en douceur, nous mettons lentement à jour App Engine afin d'utiliser les ID de région. Si nous n'avons pas encore mis à jour votre projet Google Cloud, vous ne verrez pas d'ID de région pour votre application. Étant donné que l'ID est facultatif pour les applications existantes, vous n'avez pas besoin de mettre à jour les URL ni d'effectuer d'autres modifications une fois l'ID de région disponible pour vos applications existantes.

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

Console

Dans Cloud 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.