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 dispatch pour acheminer des formats d'URL spécifiques suivant vos propres règles.

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 ModulesService.getVersionHostname.

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 ayant l'ID[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'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 coder 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 chacune les ID de ressource de l'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 des ressources d'un projet GCP spécifique.

API

Pour récupérer les ID des 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 dispatch :

  • 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 dispatch :

  • 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 dans une instance spécifique :

    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 limiter l'accès à un service, ajoutez l'élément <role-name>admin</role-name> à sa règle de sécurité.

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 dispatch 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 se trouver dans le même répertoire que les autres fichiers de configuration, comme le fichier app.yaml. Le fichier de distribution permet de définir jusqu'à 20 règles de routage, chaque règle é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

Le fichier de distribution dispatch.yaml peut se trouver n'importe où dans le répertoire du code source.

Pour déployer le fichier de configuration de la distribution sans apporter aucune autre modification à la version actuellement diffusée, exécutez l'une des commandes suivantes dans le répertoire contenant le fichier de distribution, en fonction de l'environnement que vous utilisez :

gcloud

gcloud app deploy dispatch.yaml

Maven

mvn appengine:deployDispatch dispatch.yaml

Gradle

gradle appengineDeployDispatch dispatch.yaml

IDE

Si vous utilisez IntelliJ ou Eclipse, vous devez sélectionner chaque fichier de configuration à déployer à l'aide du formulaire de déploiement.

Routage sur le serveur de développement

Découvrir les adresses d'instance

Le serveur de développement local crée toutes les instances au démarrage. Notez qu'actuellement, les instances avec scaling de base ne sont pas acceptées sur le serveur de développement local. Chaque instance créée se voit attribuer son propre port. Les attributions de ports s'affichent dans le flux de messages du journal du serveur. Les clients Web peuvent communiquer avec une instance particulière en ciblant son port. Une seule instance (et un seul port) est créée pour les services avec scaling automatique. Voici à quoi ressemblent ces messages dans le journal du serveur (notez que les services s'appelaient auparavant modules) :

INFO: Module instance service-auto is running at http://localhost:37251/

Un port unique est attribué à chaque instance d'un service avec scaling manuel :

INFO: Module instance service-manual instance 0 is running at http://localhost:43190/
INFO: Module instance service-manual instance 1 is running at http://localhost:52642/

De plus, chaque service avec scaling manuel se voit attribuer un port supplémentaire afin que les clients puissent accéder au service sans spécifier d'instance spécifique. Les requêtes adressées à ce port sont automatiquement acheminées vers l'une des instances configurées :

INFO: Module instance service-manual is running at http://localhost:12361/

Le tableau suivant montre comment appeler ces services sur le serveur de développement et dans l'environnement App Engine :

Service Instance Adresse du serveur de développement Adresse App Engine
service-auto (non utilisé) http://localhost:37251/ http://v1.service-auto.[PROJECT_ID].appspot.com/
service-manual 0 http://localhost:43190/ http://0.v1.service-manual.[PROJECT_ID].appspot.com/
service-manual 1 http://localhost:52642/ http://1.v1.service-manual.[PROJECT_ID].appspot.com/
service-manual (non utilisé) http://localhost:12361/ http://v1.service-manual.[PROJECT_ID].appspot.com/

Si vous utilisez les plug-ins Maven ou Gradle, vous pouvez attribuer le numéro de port utilisé par le serveur de développement local. Pour en savoir plus, consultez les sections concernant Apache Maven, Apache Maven (basé sur le SDK Cloud) ou Gradle.

Fichiers de distribution

Tous les fichiers de distribution sont ignorés lors de l'exécution du serveur de développement local. Le seul moyen de cibler les instances consiste à utiliser leurs ports.
Cette page vous a-t-elle été utile ? Évaluez-la :

Envoyer des commentaires concernant…

Environnement standard App Engine pour Java