Mode de routage des requêtes

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 de distribution pour acheminer des modèles 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

App Engine détermine qu'une requête entrante est destinée à votre application à partir du nom de domaine de la requête. Une requête dont le nom de domaine est http://[YOUR_PROJECT_ID].appspot.com est acheminée vers l'application ayant l'ID [YOUR_PROJECT_ID]. Chaque application obtient gratuitement un nom de domaine appspot.com.

Les domaines appspot.com sont également compatibles avec les sous-domaines au format [SUBDOMAIN]-dot-[YOUR_PROJECT_ID].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 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.

Les requêtes pour ces URL sont toutes dirigées vers la version de l'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 à une version utilise l'ID de cette version spécifique en plus du nom de domaine appspot.com (par exemple, http://[VERSION_ID]-dot-[YOUR_PROJECT_ID].appspot.com). Vous pouvez également utiliser des sous-domaines avec l'URL spécifique à la version : http://[SUBDOMAIN]-dot-[VERSION_ID]-dot-[YOUR_PROJECT_ID].appspot.com. Vous trouverez d'autres informations et des exemples dans la section Routage via une URL.

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 les données de la requête 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.

Routage via une URL

Vous pouvez cibler une requête HTTP avec des degrés de précision différents. Dans les exemples suivants, 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 [MY_PROJECT_ID] représentent les ID de ressources de votre application.

Conseil : Les outils suivants vous permettent de récupérer les ID des ressources de votre application.

Console

Dans la console GCP, 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 GCP spécifique.

API

Pour récupérer les ID de ressources de manière automatisée, consultez les méthodes list dans 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://[MY_PROJECT_ID].appspot.com
    http://[MY_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-[MY_PROJECT_ID].appspot.com
    http://[SERVICE_ID].[MY_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-[MY_PROJECT_ID].appspot.com
    http://[VERSION_ID].[MY_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 [YOUR_PROJECT_ID].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-[MY_PROJECT_ID].appspot.com
    http://[VERSION_ID].[SERVICE_ID].[MY_PROJECT_ID].[MY_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 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 la console GCP.

Exemple

Pour illustrer les différents formats d'URL, supposons qu'il existe un projet GCP avec 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 deuxième service service2 comprend la version vBackend.

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.appspot.com
    https://vFrontend-dot-requestsProject.appspot.com
    
  2. Pour cibler la version vBackend à l'aide d'un domaine personnalisé sans HTTPS, vous pouvez utiliser :

    http://vBackend.service2.example.net
    http://vBackend.example.net
    

    requestsProject.appspot.com est mappé sur 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 http://simple-sample.appspot.com/mobile/, vers une interface mobile, et les requêtes de nœud de calcul, telles que http://simple-sample.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 configuration 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
Cette page vous a-t-elle été utile ? Évaluez-la :

Envoyer des commentaires concernant…

Environnement flexible App Engine pour les documents Ruby