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 les formats d'URL spécifiques en fonction de vos propres règles.

Si vous testez 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 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.

Pour en savoir plus, consultez la section Routage sur le serveur de développement.

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 dont l'ID est [YOUR_PROJECT_ID]. Chaque application obtient gratuitement un nom de domaine appspot.com.

Les domaines appspot.com acceptent également les sous-domaines au format [SUBDOMAIN]-dot-[YOUR_PROJECT_ID].appspot.com, où [SUBDOMAIN] peut être n'importe quelle chaîne autorisée dans une partie d'un nom de domaine, à l'exclusion 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é à votre application, consultez Sécuriser des domaines personnalisés avec SSL.

Toutes les requêtes pour ces URL sont dirigées vers 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 donnée 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. Consultez la section Routage via une URL pour obtenir plus d'informations et d'exemples.

Le nom de domaine utilisé pour la requête est inclus dans les données de requête transmises à votre 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 à des degrés de précision différents. Dans les exemples suivants, appspot.com peut être remplacé par le domaine personnalisé de votre application, le cas échéant. Les sous-chaînes d'URL [VERSION_ID], [SERVICE_ID] et [MY_PROJECT_ID] représentent les ID des 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 façon automatisée, consultez la section 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 toutes les versions configurées pour recevoir du 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 toutes les versions configurées pour recevoir du trafic dans le service ciblé. Si ce service n'existe pas, la requête est redirigée temporairement.

  • 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]
  • 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, et peut être spécifié comme suit :

    Envoie une requête à un service et à une version spécifiques au sein d'une instance donnée :

    https://[INSTANCE_ID]-dot-[VERSION_ID]-dot-[SERVICE_ID]-dot-[MY_PROJECT_ID].appspot.com
    http://[INSTANCE_ID].[VERSION_ID].[SERVICE_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. Pour identifier les versions qui ont été configurées pour le trafic, accédez à la page Versions de la console GCP.

Restreindre l'accès à un service

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

Exemple

Pour mieux comprendre les différents formats d'URL, supposons qu'il existe un projet GCP avec l'ID requestsProject, comprenant une application qui exécute 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, utilisez ce qui suit :

    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, utilisez ce qui suit :

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

    requestsProject.appspot.com est mappé au 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 pour ignorer les règles de routage d'App Engine et définir vos propres règles de routage personnalisées. Un fichier de distribution permet d'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

appcfg

Si vous installez le SDK App Engine d'origine, exécutez la commande suivante :

appcfg.py update_dispatch [YOUR_APP_DIR]

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 sélectionne (ou crée) une instance dans le 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 :

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 comprend 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 chemin 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.

Cette page vous a-t-elle été utile ? Évaluez-la :

Envoyer des commentaires concernant…

Environnement standard App Engine pour Python