Mode de routage des requêtes

ID de la région

Le code REGION_ID est attribué par Google en fonction de la région que vous sélectionnez lors de la création de votre application. L'ajout de REGION_ID.r dans les URL App Engine est facultatif pour les applications existantes. Il sera bientôt nécessaire pour toutes les nouvelles applications.

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 deux manières :

  • Les règles de routage par défaut d'App Engine s'appliquent aux requêtes dont l'URL se termine au niveau du domaine.

  • Vous pouvez également utiliser un fichier dispatch pour acheminer des formats d'URL spécifiques suivant vos propres règles.

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.

Requêtes et domaines

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 à la version de votre application que vous avez configurée pour recevoir du trafic.

Chaque version de l'application possède également sa propre URL. Vous pouvez donc déployer et tester une nouvelle version avant de la configurer pour recevoir du trafic. L'URL spécifique à la version utilise l'ID d'une version spécifique en plus de l'ID de projet, de l'ID de région et du nom de domaine appspot.com. Exemple : https://VERSION_ID-dot-default-dot-PROJECT_ID.REGION_ID.r.appspot.com.

Sous-domaines

Les domaines appspot.com sont également compatibles avec les sous-domaines au format SUBDOMAIN-dot-PROJECT_ID.REGION_ID.r.appspot.com, où SUBDOMAIN peut être toute chaîne autorisée dans une partie d'un nom de domaine, à l'exception du caractère .. Les requêtes envoyées de cette manière aux sous-domaines sont acheminées vers votre application.

Vous pouvez également utiliser des sous-domaines avec une URL spécifique à la version :
https://SUBDOMAIN-dot-VERSION_ID-dot-PROJECT_ID.REGION_ID.r.appspot.com.

Vous trouverez d'autres informations et des exemples dans la section Routage via une URL.

Domaines personnalisés

Vous pouvez configurer un domaine de premier niveau personnalisé à l'aide de G Suite, puis attribuer des sous-domaines à différentes applications, telles que Google Mail ou Sites. Vous pouvez également associer une application App Engine à un sous-domaine. Pour en savoir plus sur le mappage d'un domaine personnalisé avec l'application, consultez la page Sécuriser les domaines personnalisés avec SSL.

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.

ID de la région

Le code REGION_ID est attribué par Google en fonction de la région que vous sélectionnez lors de la création de votre application. L'ajout de REGION_ID.r dans les URL App Engine est facultatif pour les applications existantes. Il sera bientôt nécessaire pour toutes les nouvelles applications.

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.

Routage via une URL

Vous pouvez cibler une requête HTTP à des degrés de précision différents. Dans les exemples suivants, REGION_ID.r.appspot.com peut être remplacé par le domaine personnalisé de l'application, le cas échéant. Les sous-chaînes d'URL VERSION_ID, SERVICE_ID et PROJECT_ID représentent chacune les ID des ressources de votre application.

Vous pouvez utiliser les outils suivants pour récupérer les ID des ressources de votre application :

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.

Routage par défaut

Les formats d'URL suivants ont un comportement de routage par défaut. Notez que le routage par défaut est remplacé si un format correspondant est défini dans votre fichier de distribution :

  • 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_ID-dot-SERVICE_ID-dot-PROJECT_ID.REGION_ID.r.appspot.com
    https://VERSION_ID.SERVICE_ID.PROJECT_ID.CUSTOM_DOMAIN

Service par défaut

Le service default est créé lorsque vous déployez la version initiale de votre application sur App Engine. Les requêtes ne spécifiant aucun service ou spécifiant un service non valide sont acheminées vers le service default. Ces requêtes sont ensuite traitées par les versions que vous avez configurées pour recevoir du trafic dans le service default. Vous pouvez voir quelles versions sont configurées pour le trafic sur la page Versions de Cloud Console.

Exemple

Pour illustrer les différents formats d'URL, supposons qu'il existe un projet Cloud ayant l'ID requestsProject, qui inclut une application exécutant deux services et versions. Dans cet exemple, le service default de l'application comprend la version vFrontend, et le second service service2 comprend la version vBackend. L'identifiant de région uc a été attribué par Google pour les deux applications.

Pour cibler des services et des versions spécifiques, vous pouvez utiliser les formats d'URL suivants :

  1. Pour cibler la version dans le service default à l'aide de HTTPS, vous pouvez utiliser :

        https://vFrontend-dot-default-dot-requestsProject.uc.r.appspot.com
        https://vFrontend-dot-requestsProject.uc.r.appspot.com
    

  2. Pour cibler la version vBackend à l'aide d'un domaine personnalisé, vous pouvez utiliser :

    https://vBackend.service2.example.net
    https://vBackend.example.net
    

    requestsProject.uc.r.appspot.com est mappé avec le domaine example.net.

Routage avec un fichier de distribution

Pour les URL qui utilisent les formats décrits précédemment, vous pouvez créer un fichier de distribution afin de remplacer les règles de routage d'App Engine 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.

Pour en savoir plus sur la création d'un fichier de distribution, consultez la documentation de référence sur le fichier dispatch.yaml.

Créer un fichier de distribution

Le fichier de distribution doit être placé à la racine du répertoire de votre projet ou dans le répertoire racine du service default. Il permet de définir jusqu'à 20 règles de routage, chacune étant composée des éléments service et url.

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

Pour en savoir plus sur la définition du fichier dispatch.yaml, consultez la documentation de référence sur le fichier dispatch.yaml.

Déployer le fichier de distribution

Pour déployer le fichier de configuration dispatch.yaml, exécutez la commande suivante :

gcloud

gcloud app deploy dispatch.yaml