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
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 l'environnement d'exécution, les gestionnaires et d'autres paramètres de ressources à 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.
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.standard.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.
Si vous utilisez Java et les anciens services groupés, vous pouvez spécifier le service par défaut dans le fichier appengine-web.xml avec le paramètre <service>default</service>.
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.yamlconfigure les tâches planifiées régulièrement qui fonctionnent à des heures définies ou à intervalles réguliers.dispatch.yamlremplace 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.yamlspécifie les index dont l'application a besoin si vous utilisez des requêtes Datastore.
Noms des fichiers
App Engine exécute des applications dans un conteneur sur une distribution Linux Ubuntu mise à jour. Les noms de fichiers que vous utilisez dans l'environnement standard App Engine doivent être compatibles avec UTF-8. Il peut s'agir d'un fichier UTF-8 ou d'un fichier pouvant être converti automatiquement en toute sécurité en UTF-8. Si vos noms de fichiers utilisent des encodages différents, déployez votre application à partir d'une machine ayant des paramètres de langage de nom de fichier compatibles avec UTF-8.
Le déploiement du conteneur échoue si les noms de fichiers ne sont pas compatibles avec UTF-8. Notez que le codage des caractères que vous utilisez dans un fichier n'est soumis à aucune limite.
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.