Structurer des services Web dans App Engine

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. Pour les applications créées après février 2020, REGION_ID.r est inclus dans les URL App Engine. Pour les applications existantes créées avant cette date, l'ID de région est facultatif dans l'URL.

En savoir plus sur les ID de région

OK

Ce guide explique comment structurer les services et les ressources associées de votre application App Engine.

Structure des répertoires

Chaque version de votre service App Engine est définie dans un fichier de configuration app.yaml. Pour les applications simples, l'exigence minimale requise pour le déploiement consiste à définir le fichier app.yaml. Le fichier app.yaml sert de descripteur de déploiement. Il définit le type de scaling, ainsi que les ressources (processeur, disque et mémoire) à utiliser pour une version spécifique d'un service. Si vous déployez plusieurs versions d'un service, vous pouvez créer différents fichiers YAML dans le même répertoire pour représenter la configuration de chaque version.

Dans l'environnement d'exécution Java, les fichiers de configuration sont au format YAML.

Remarque : Dans l'environnement d'exécution Java, l'organisation des fichiers dépend du moteur d'exécution Java que vous utilisez. Vous avez peut-être besoin d'un fichier WAR ou JAR, correspondant à chaque service de votre application. Pour plus d'informations, consultez le guide du développeur d'exécution Java approprié.

Pour chacun des services, vous avez la possibilité de créer des répertoires distincts à la racine de votre application lorsque vous la développez en local. Si vous hébergez votre application à partir d'un système de contrôle de version (VCS) tel que GitHub, vous pouvez également la structurer de sorte qu'elle utilise des répertoires distincts dans un même dépôt ou des dépôts séparés pour chaque service. Chaque répertoire ou dépôt doit représenter un seul service et contenir le fichier app.yaml de ce service ainsi que le code source associé.

Vous avez la possibilité de spécifier un nom unique pour chaque fichier app.yaml de votre service. Par exemple, vous pouvez nommer un fichier de configuration d'après votre service ou utiliser des noms uniques pour représenter chaque version de ce service (service1.yaml ou app.flexible.yaml, par exemple).

Les autres fichiers de configuration facultatifs doivent résider dans le répertoire racine ou dans le dépôt du service default de votre application. Ces fichiers de configuration facultatifs appliquent des paramètres à l'échelle de l'application qui ne sont pas propres à un service particulier, y compris les fichiers dispatch.yaml, index.yaml et cron.yaml.

Examples

Une application simple ne nécessite que l'ajout de app.yaml au même emplacement que les fichiers source de l'application. Une application à un seul service n'inclut que le service default. Tous les fichiers peuvent résider dans le même répertoire, à la racine de cette application.

L'exemple ci-dessous montre comment structurer une application comprenant trois services si vous la développez en local. Le fichier dispatch.yaml facultatif a été ajouté à cette application dans le répertoire racine. Ce dernier contient trois répertoires, un pour chacun des services de l'application. Le sous-répertoire correspondant à service1 inclut les fichiers source et de configuration de ce service. De même, service2 et service3 se trouvent dans des répertoires distincts contenant les fichiers de chaque service. Toutefois, service3 inclut deux versions du fichier de configuration YAML :

Dans l'exemple suivant, un seul service possède le fichier dispatch.yaml facultatif et deux fichiers de configuration représentant différentes versions de ce service, service1.yaml et service2.yaml :

Conseils pour optimiser le temps d'activité d'une instance

Les pannes matérielles ou logicielles qui entraînent un arrêt anticipé ou des redémarrages fréquents des instances peuvent se produire sans avertissement. Par ailleurs, leur résolution peut prendre beaucoup de temps. Votre application doit pouvoir gérer ces défaillances.

Voici quelques stratégies efficaces à mettre en place pour éviter les temps d'arrêt dus aux redémarrages des instances :

• Réduisez le temps nécessaire au redémarrage des instances existantes ou au démarrage des nouvelles instances.
• Pour les calculs de longue durée, créez régulièrement des points de contrôle afin de pouvoir reprendre l'activité à partir de ces derniers.
• Votre application doit être "sans état" pour que rien ne soit stocké sur l'instance.
• Servez-vous de files d'attente pour exécuter des tâches asynchrones.
• Si vous configurez vos instances pour le scaling manuel , procédez comme suit :
  • Utilisez l'équilibrage de charge sur plusieurs instances.
  • Configurez plus d'instances que nécessaire pour gérer le trafic normal.
  • Mettez en place une logique de secours qui utilise les résultats mis en cache lorsqu'une instance avec scaling manuel n'est pas disponible.

Pour en savoir plus sur les instances, consultez la page Mode de gestion des instances.

Le service default

Toutes les applications App Engine comprennent un service default. Pour pouvoir créer et déployer des services supplémentaires sur votre application, vous devez déployer une version initiale de votre application sur le service default.

Ce service par défaut peut éventuellement être spécifié dans le fichier app.yaml avec le paramètre service: default.

Les requêtes adressées à votre application en utilisant votre projet Google Cloud sont envoyées au service default, par exemple, https://PROJECT_ID.REGION_ID.r.appspot.com. Pour savoir comment cibler vos autres services, consultez la page Assurer la communication entre les services.

Fichiers de configuration facultatifs

Les fichiers de configuration suivants contrôlent les fonctionnalités facultatives qui s'appliquent à tous les services d'une application donnée. Consultez les rubriques suivantes pour en savoir plus sur chacune des fonctionnalités facultatives :

• cron.yaml configure les tâches planifiées régulièrement qui fonctionnent à des heures définies ou à intervalles réguliers.
• dispatch.yaml remplace les règles de routage par défaut en envoyant 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.
• index.yaml spécifie les index dont l'application a besoin si vous utilisez des requêtes Datastore.
  • Notez que ce fichier est disponible pour tous les environnements d'exécution, à l'exception de l'environnement d'exécution .NET.

Considérations relatives au stockage de données et de fichiers

À partir d'App Engine, vous pouvez facilement accéder à d'autres services Google Cloud tels que Datastore, Cloud SQL et Cloud Storage.

Vous avez également la possibilité d'utiliser une base de données externe ou tierce compatible avec votre langage et accessible à partir de votre instance App Engine.

Pour en savoir plus sur le stockage de fichiers dans Google Cloud ou en externe, consultez la page Comprendre le stockage des données et des fichiers.

Vous avez aussi la possibilité de choisir le mode de diffusion du contenu statique. Vous pouvez diffuser le contenu statique de votre application directement depuis cette application dans App Engine, héberger votre contenu statique sur une solution Google Cloud telle que Cloud Storage, ou utiliser un réseau de diffusion de contenu (CDN) tiers. Pour plus d'informations sur la diffusion de contenu statique, consultez la page Diffuser des fichiers statiques.

Étape suivante

Si vous travaillez avec plusieurs services et que vous souhaitez les déployer ensemble, consultez les étapes pour déployer plusieurs services.