Remarque : Au cours des prochains mois, nous allons réorganiser le site de documentation App Engine afin de faciliter la recherche de contenu et de mieux s'aligner avec les autres produits Google Cloud. Le contenu disponible sera le même, mais la navigation correspondra désormais au reste des produits Cloud.

PHP 8.1 est désormais en phase de disponibilité générale.

Fichier de configuration app.yaml

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

Le fichier app.yaml permet de configurer les paramètres de votre application App Engine. Le fichier app.yaml contient également des informations sur le code de l'application, l'environnement d'exécution PHP et le point d'entrée.

Chaque service de l'application possède son propre fichier app.yaml, qui sert de descripteur pour son déploiement. Vous devez d'abord créer le fichier app.yaml pour le service default pour pouvoir créer et déployer des fichiers app.yaml pour des services supplémentaires dans l'application.

Pour PHP 7 et versions ultérieures, le fichier app.yaml doit contenir au moins une entrée runtime. Pour obtenir un bref aperçu, consultez la page Définir des paramètres d'exécution.

Structure des répertoires

Pour savoir comment structurer plusieurs services dans votre application, consultez la page Structurer des services Web dans App Engine.

Exemple

Voici un exemple de fichier app.yaml pour une application PHP 7 et versions ultérieures :

runtime: php81 # Replace with php74 to use PHP 7.4

handlers:
# Serve a directory as a static resource.
- url: /stylesheets
  static_dir: stylesheets

# Serve images as static resources.
- url: /(.+\.(gif|png|jpg))$
  static_files: \1
  upload: .+\.(gif|png|jpg)$

# Serve your app through a front controller at index.php or public/index.php.
- url: .*
  script: auto

Dans cet exemple, App Engine diffuse en tant que ressources statiques les fichiers possédant une extension gif, png ou jpg. Le code de l'application lit les fichiers configurés au moment de l'exécution.

Syntaxe

La syntaxe du fichier app.yaml utilise le format YAML.

Le format YAML accepte les commentaires. Les lignes commençant par le caractère dièse (#) sont ignorées :

# This is a comment.

Les formats d'URL et de chemin d'accès au fichier utilisent la syntaxe d'expressions régulières POSIX étendue, à l'exception des éléments classés et des classes utilisées pour les classements. Les références arrières aux correspondances groupées, telles que \1, sont compatibles, de même que les extensions Perl suivantes : \w \W \s \S \d \D.

Éléments de l'environnement d'exécution et d'application

Élément	Description
`app_engine_apis`	Facultatif. Si vous souhaitez utiliser les anciens services groupés App Engine pour des environnements d'exécution de deuxième génération, définissez ce champ sur `true`.
`build_env_variables`	Preview — build environment variables Cette fonctionnalité est soumise aux "Conditions des offres de pré-DG" dans la section "Conditions d'utilisation générales" des Conditions spécifiques au service. Les fonctionnalités pré-DG sont disponibles "en l'état" et peuvent avoir une assistance limitée. Pour en savoir plus, consultez les descriptions des étapes de lancement. Facultatif. Si vous utilisez un environnement d'exécution compatible avec les packs de création, vous pouvez définir des variables d'environnement de compilation dans votre fichier `app.yaml`. Pour en savoir plus, consultez la section Utiliser des variables d'environnement de compilation.
`default_expiration`	Facultatif. Définit une durée de mise en cache globale par défaut pour tous les gestionnaires de fichiers statiques d'une application. Vous pouvez également configurer une durée de mise en cache pour des gestionnaires de fichiers statiques spécifiques. La valeur est une chaîne de nombres et d'unités, séparés par des espaces. Les unités possibles sont "d" pour les jours, "h" pour les heures, "m" pour les minutes et "s" pour les secondes. Par exemple, `"4d 5h"` définit l'expiration du cache sur une durée de 4 jours et 5 heures après la première requête du fichier. Si cette valeur n'est pas définie, le serveur de production définit le délai d'expiration sur 10 minutes. Exemple : runtime: php81 # Replace with php74 to use PHP 7.4 default_expiration: "4d 5h" handlers: # ... Pour en savoir plus, consultez Expiration du cache.
`entrypoint`	Facultatif. Remplace le comportement de démarrage par défaut en exécutant la commande `entrypoint` au démarrage de l'application. Pour que votre application soit en mesure de recevoir des requêtes HTTP, l'élément `entrypoint` doit contenir une commande qui lance un serveur Web écoutant le port 8080. Si vous ne spécifiez pas de point d'entrée `entrypoint`, App Engine diffusera votre application via un contrôleur frontal dans un fichier `public/index.php` ou `index.php`.
`env_variables`	Facultatif. Vous pouvez définir des variables d'environnement dans le fichier `app.yaml` pour les rendre disponibles pour votre application. L'utilisation des variables d'environnement dont le préfixe est `GAE` est réservée au système. Ces variables ne sont pas autorisées dans le fichier `app.yaml`. Exemple : env_variables: MY_VAR: "my value" où `MY_VAR` et `my value` sont le nom et la valeur de la variable d'environnement que vous souhaitez définir et où chaque entrée de variable d'environnement est indentée de deux espaces sous l'élément `env_variables`. Les variables d'environnement dont la valeur n'est pas spécifiée sont définies par défaut sur `"None"`. Vous pouvez ensuite récupérer la valeur de ces variables en utilisant `getenv()` ou `$_SERVER`, mais pas `$_ENV`. Les commandes suivantes renvoient la valeur de la variable d'environnement `MY_VAR` : echo getenv('MY_VAR'); ou echo $_SERVER['MY_VAR']; Consultez également la liste des variables d'environnement d'exécution qui ne peuvent pas être écrasées.
`error_handlers`	Facultatif. Permet de configurer les pages d'erreur personnalisées qui s'affichent pour différents types d'erreurs. Cet élément peut contenir les éléments suivants : `error_code` Facultatif. L'élément `error_code` peut avoir l'une des valeurs suivantes : `over_quota` Indique que l'application a dépassé le quota d'une ressource. `timeout` Élément diffusé si un délai arrive à expiration avant que votre application ne réponde. L'attribut error_code est facultatif. S'il n'est pas spécifié, le fichier fourni constitue le message d'erreur par défaut affiché par votre application. `file` Chaque entrée indique un fichier statique qui doit être diffusé à la place du message d'erreur générique. Si vous spécifiez un élément `file` sans élément `error_code` correspondant, le fichier statique constitue la page d'erreur par défaut de l'application. Avertissement : Veillez à ce que le chemin du fichier de réponse en cas d'erreur ne chevauche pas les chemins vers le gestionnaire de fichiers statiques. Les données d'erreur personnalisées doivent être inférieures à 10 kilo-octets. Exemple : error_handlers: - file: default_error.html - error_code: over_quota file: over_quota.html
`handlers`	Facultatif. Liste de formats d'URL, avec la description de leurs modes de gestion. Pour gérer les URL, App Engine peut exécuter le code de l'application ou diffuser des fichiers statiques importés avec le code, tels que des images, des fichiers CSS ou des fichiers JavaScript. Si vous avez défini des éléments `handlers` statiques, vous devez également définir un gestionnaire pour tout le reste du trafic d'application qui doit être acheminé vers un point d'entrée `entrypoint`. Pour acheminer le trafic vers un point d'entrée `entrypoint`, spécifiez le chemin d'accès vers votre contrôleur frontal avec l'élément `entrypoint` ou utilisez l'élément `script` si votre application contient un fichier `public/index.php` ou `index.php`. Exemple : url: .* script: auto Voir la syntaxe de l'élément "handlers" et des sous-éléments
`inbound_services`	Facultatif. Les applications doivent activer ces services pour pouvoir recevoir des requêtes entrantes. Vous pouvez activer le service pour une application PHP 7 et versions ultérieures en incluant une section `inbound_services` dans le fichier `app.yaml`. `warmup` Active les requêtes de préchauffage. Consultez la page Configurer des requêtes de préchauffage. Exemple : inbound_services: - mail - warmup
`instance_class`	Facultatif. Classe d'instance de ce service. Les valeurs suivantes sont disponibles en fonction du scaling de votre service : Scaling automatique `F1`, `F2`, `F4`, `F4_1G` Par défaut : `F1` Vous pouvez éventuellement utiliser l'élément `automatic_scaling` pour modifier les paramètres par défaut du scaling automatique, tels que le nombre minimal et maximal d'instances, la latence et les connexions simultanées. Remarque : Si `instance_class` est défini sur au moins `F2`, vous pouvez optimiser vos instances en définissant `max_concurrent_requests` sur une valeur supérieure à la valeur par défaut de dix. Pour déterminer la valeur optimale, augmentez-la progressivement et surveillez les performances de votre application. Scaling de base et scaling manuel `B1`, `B2`, `B4`, `B4_1G`, `B8` Par défaut : `B2` Les classes d'instances de base et manuelle nécessitent de spécifier l'élément `basic_scaling` ou `manual_scaling`.
`runtime`	Obligatoire. Nom de l'environnement d'exécution utilisé par votre application. Par exemple, pour spécifier PHP 8.1, utilisez : runtime: php81
`service`	Obligatoire si vous créez un service. Facultatif pour le service `default`. Un nom doit avoir été attribué à chaque service et à chaque version. Il peut contenir des chiffres, des lettres et des traits d'union. La longueur combinée de `VERSION-dot-SERVICE-dot-PROJECT_ID` (où `VERSION` est le nom de votre version, `SERVICE` est le nom de votre service et `PROJECT_ID` est l'ID de votre projet) ne peut pas comporter plus de 63 caractères et ne peut pas commencer ni se terminer par un trait d'union. Choisissez un nom unique pour chaque service et chaque version. N'utilisez pas le même nom pour plusieurs services ou versions. Exemple : service: service-name
`service_account`	Facultatif. L'élément `service_account` vous permet de spécifier un compte de service géré par l'utilisateur en tant qu'identité de la version. Le compte de service spécifié sera utilisé pour accéder à d'autres services Google Cloud et pour exécuter des tâches. Exemple : service_account: [SERVICE_ACCOUNT_NAME]@[PROJECT_ID].iam.gserviceaccount.com
`vpc_access_connector`	Facultatif. Configure votre application pour utiliser un connecteur d'accès au VPC sans serveur afin d'envoyer des requêtes à des ressources internes du réseau VPC. Pour en savoir plus, consultez Se connecter à un réseau VPC. `name` Littéral de chaîne Spécifiez le nom complet de votre connecteur d'accès au VPC sans serveur entre guillemets : "projects/`PROJECT_ID`/locations/`REGION`/connectors/`CONNECTOR_NAME`" `egress_setting` Facultatif. La valeur par défaut est `private-ranges-only`. L'élément `egress_setting` peut avoir l'une des valeurs suivantes : `private-ranges-only` Valeur par défaut. Les requêtes adressées aux adresses IP internes sont envoyées via le connecteur d'accès au VPC sans serveur vers le réseau VPC connecté. Les requêtes adressées à des adresses IP externes sont envoyées à l'Internet public. `all-traffic` Toutes les requêtes sont envoyées via le connecteur d'accès au VPC sans serveur vers le réseau VPC connecté. Exemple vpc_access_connector: name: "projects/`PROJECT_ID`/locations/`REGION`/connectors/`CONNECTOR_NAME`" egress_setting: all-traffic

Élément "handlers"

L'élément handlers fournit une liste de formats d'URL et une description de la manière dont ils doivent être gérés. Pour gérer les URL, App Engine peut exécuter le code d'application ou diffuser les fichiers statiques transférés avec le code, tels que des fichiers image, CSS ou JavaScript.

Les formats sont évalués selon leur ordre d'apparition dans le fichier app.yaml, de haut en bas. Le premier mappage dont le format correspond à l'URL est employé pour gérer la requête.

Le tableau suivant répertorie les sous-éléments de l'élément handlers qui contrôlent le comportement des scripts, des fichiers statiques, des répertoires statiques et d'autres paramètres.

Élément	Description
`expiration`	Facultatif. Durée pendant laquelle un fichier statique diffusé par ce gestionnaire doit être mis en cache par les serveurs proxy et les navigateurs. La valeur correspond à une chaîne de nombres et d'unités, séparés par des espaces, où les unités possibles sont `d` pour les jours, `h` pour les heures, `m` pour les minutes et `s` pour les secondes. Par exemple, `"4d 5h"` définit l'expiration du cache sur une durée de 4 jours et 5 heures après la première requête du fichier. Si cet élément n'est pas spécifié, la valeur `default_expiration` définie dans l'application s'applique. Pour en savoir plus, consultez Expiration du cache.
`http_headers`	Facultatif. Vous pouvez définir des en-têtes HTTP pour les réponses de vos gestionnaires de fichiers statiques ou de répertoires. Si vous devez définir des en-têtes HTTP dans vos gestionnaires `script`, indiquez-les plutôt dans le code de votre application. Pour en savoir plus sur les en-têtes de réponse qui affectent la mise en cache, consultez Mettre en cache du contenu statique. Exemple handlers: - url: /images static_dir: static/images http_headers: X-Foo-Header: foo X-Bar-Header: bar value vary: Accept-Encoding # ... Compatibilité avec le CORS Une des principales applications de cette fonctionnalité consiste à accepter le partage de ressources multi-origines (CORS), tel que l'accès aux fichiers hébergés par une autre application App Engine. Par exemple, vous pouvez avoir une application de jeu `mygame.uc.r.appspot.com` qui accède aux éléments hébergés par `myassets.uc.r.appspot.com`. Cependant, si `mygame` tente d'envoyer une requête `XMLHttpRequest` JavaScript à `myassets`, elle n'aboutit pas à moins que le gestionnaire de `myassets` affiche un en-tête de réponse `Access-Control-Allow-Origin:` contenant la valeur `http://mygame.uc.r.appspot.com`. Voici comment faire en sorte que votre gestionnaire de fichiers statiques affiche la valeur d'en-tête de réponse requise : handlers: - url: /images static_dir: static/images http_headers: Access-Control-Allow-Origin: https://mygame.uc.r.appspot.com # ... Remarque : Si vous souhaitez autoriser tous les utilisateurs à accéder à vos éléments, vous pouvez utiliser le caractère générique `'*'` au lieu de `https://mygame.uc.r.appspot.com`.
`mime_type`	Facultatif. Si vous précisez le type MIME, ce gestionnaire l'utilise pour diffuser tous les fichiers. Dans le cas contraire, le type MIME d'un fichier est dérivé de l'extension du nom de fichier. Si le même fichier est importé avec plusieurs extensions, l'extension obtenue peut dépendre de l'ordre dans lequel les importations ont eu lieu. Pour en savoir plus sur les types de médias MIME disponibles, consultez le site Web de l'IANA sur les types de médias MIME.
`redirect_http_response_code`	Facultatif. L'élément `redirect_http_response_code` est utilisé avec le paramètre `secure` pour définir le code de réponse HTTP affiché lors de l'exécution d'une redirection requise par le mode de configuration du paramètre `secure`. L'élément `redirect_http_response_code` peut avoir les valeurs suivantes : `301` Code de réponse "Moved Permanently" (Déplacé définitivement) `302` Code de réponse "Found" (Trouvé) `303` Code de réponse "See Other" (Voir ailleurs) `307` Code de réponse "Temporary Redirect" (Redirection temporaire) Exemple handlers: - url: /youraccount/.* script: auto secure: always redirect_http_response_code: 301 Lorsque la requête d'un utilisateur est redirigée, le code d'état HTTP est défini sur la valeur du paramètre `redirect_http_response_code`. Le code d'état 302 s'affiche si le paramètre n'est pas spécifié.
`script`	Facultatif. Spécifie que les requêtes adressées au gestionnaire spécifique doivent cibler votre application. La seule valeur acceptée pour l'élément `script` est `auto`, car l'ensemble du trafic est diffusé à l'aide de la commande "entrypoint". Pour utiliser des gestionnaires de fichiers statiques, au moins l'un de vos gestionnaires doit contenir la ligne `script: auto` ou définir un élément `entrypoint` à déployer correctement. handlers: - url: /images static_dir: static/images - url: /.* script: myapp.php
`secure`	Facultatif. Tous les gestionnaires d'URL peuvent utiliser le paramètre `secure`, y compris les gestionnaires de scripts et les gestionnaires de fichiers statiques. L'élément `secure` peut avoir les valeurs suivantes : `optional` Les requêtes HTTP et HTTPS dont les URL correspondent au gestionnaire aboutissent sans redirection. L'application peut examiner la requête pour déterminer le protocole utilisé et répondre en conséquence. Il s'agit de la valeur par défaut lorsque `secure` n'est pas fourni pour un gestionnaire. `never` Les requêtes d'accès à une URL, qui correspondent à ce gestionnaire et qui utilisent le protocole HTTPS, sont automatiquement redirigées vers l'URL HTTP équivalente. Lorsque la requête HTTPS d'un utilisateur est redirigée pour être convertie en requête HTTP, les paramètres sont supprimés de la requête. Cela empêche un utilisateur d'envoyer accidentellement des données de requête destinées à une connexion sécurisée, via une connexion non sécurisée. `always` Les requêtes d'accès à une URL, qui correspondent à ce gestionnaire et qui n'utilisent pas le protocole HTTPS, sont automatiquement redirigées vers l'URL HTTPS contenant le même chemin d'accès. Les paramètres de requête sont conservés pour la redirection. Exemple : handlers: - url: /youraccount/.* script: auto secure: always Pour cibler une version spécifique de votre application à l'aide du domaine `REGION_ID.r.appspot.com`, vous devez remplacer les points qui séparent généralement les composants du sous-domaine de l'URL par la chaîne `-dot-`. Exemple : `https://VERSION_ID-dot-default-dot-PROJECT_ID.REGION_ID.r.appspot.com` Pour utiliser des domaines personnalisés avec HTTPS, vous devez d'abord activer et configurer les certificats SSL pour ce domaine. Pour les comptes Google, la connexion et la déconnexion s'effectuent toujours via une connexion sécurisée, quelle que soit la manière dont les URL sont configurées.
`static_dir`	Facultatif. Chemin d'accès au répertoire contenant les fichiers statiques, à partir du répertoire racine de l'application. Tous les éléments situés après la fin du format `url` correspondant sont ajoutés à `static_dir` pour former le chemin d'accès complet au fichier demandé. Chaque fichier du répertoire statique est diffusé en utilisant le type MIME correspondant à son extension de nom de fichier, sauf s'il a été remplacé par le paramètre `mime_type` du répertoire. Tous les fichiers du répertoire donné sont importés en tant que fichiers statiques et aucun d’entre eux ne peut être exécuté en tant que script. Exemple : handlers: # All URLs beginning with /stylesheets are treated as paths to # static files in the stylesheets/ directory. - url: /stylesheets static_dir: stylesheets # ...
`static_files`	Facultatif. Un gestionnaire de modèles de fichiers statiques associe un modèle d'URL à des chemins d'accès aux fichiers statiques importés avec l'application. L'expression régulière du format d'URL peut définir des regroupements d'expressions régulières à utiliser pour la construction du chemin d'accès au fichier. Vous pouvez employer cette méthode à la place de `static_dir` pour réaliser un mappage vers des fichiers spécifiques d'une structure de répertoires, sans mapper l'intégralité du répertoire. Exemple : handlers: # All URLs ending in .gif .png or .jpg are treated as paths to # static files in the static/ directory. The URL pattern is a # regular expression, with a grouping that is inserted into the # path to the file. - url: /(.\.(gif\|png\|jpg))$ static_files: static/\1 upload: static/.\.(gif\|png\|jpg)$ # ... Les fichiers statiques ne peuvent pas être identiques aux fichiers de code d'application.
`upload`	Facultatif. Expression régulière qui correspond aux chemins d'accès de tous les fichiers référencés par ce gestionnaire. Elle est nécessaire, car le gestionnaire ne peut pas déterminer quels fichiers de votre répertoire d'application correspondent aux formats `url` et `static_files` en question. Les fichiers statiques sont transférés et gérés indépendamment des fichiers d'application. Dans l'exemple ci-dessus, le format `upload` suivant peut être utilisé : `archives/(.)/items/(.)`
`url`	Élément requis sous `handlers`. Format d'URL sous la forme d'une expression régulière. L'expression peut contenir des regroupements qu'il est possible de désigner dans le chemin d'accès au script à l'aide de références arrières à des expressions régulières. Par exemple, `/profile/(.)/(.)` correspond à l'URL `/profile/edit/manager`, et utilise `edit` et `manager` comme premier et second regroupements. Le format d'URL présente des différences de comportement lorsqu'il est utilisé avec les éléments suivants : `static_dir` Utilise le préfixe d'une URL. Le modèle d'expression régulière ne doit pas contenir de regroupements lorsqu'il est utilisé avec l'élément `static_dir`. Toutes les URL commençant par ce préfixe sont gérées par ce gestionnaire, en utilisant la partie d'URL située après le préfixe comme une partie du chemin d'accès au fichier. `static_files` Un gestionnaire de modèles de fichiers statiques associe un format d'URL à des chemins d'accès aux fichiers statiques importés avec l'application. L'expression régulière du format d'URL peut définir des regroupements d'expressions régulières à utiliser pour la construction du chemin d'accès au fichier. Vous pouvez employer cette méthode à la place de `static_dir` pour réaliser un mappage vers des fichiers spécifiques d'une structure de répertoires, sans mapper l'intégralité du répertoire.

Éléments de scaling

Les éléments du tableau suivant configurent le scaling de votre application. Pour en savoir plus sur le scaling des applications App Engine, consultez la documentation sur les types de scaling.

Élément Description

Élément	Description
`automatic_scaling`	Facultatif. Applicable seulement aux applications qui utilisent une classe d'instance F1 ou supérieure. Spécifiez cet élément pour modifier les paramètres par défaut du scaling automatique, tels que la définition de niveaux minimal et maximal pour le nombre d'instances, la latence et les connexions simultanées d'un service. Cet élément peut contenir les éléments suivants : `max_instances` Facultatif. Indiquez une valeur comprise entre 0 et 2 147 483 647, où zéro désactive le paramètre. Ce paramètre spécifie le nombre maximal d'instances que App Engine peut créer pour cette version de module. Cela permet de limiter les coûts d'un module. `min_instances` Avertissement : Pour veiller au bon fonctionnement de cette fonctionnalité, vous devez vous assurer que les requêtes de préchauffage sont activées et que votre application les gère. Remarque : Ce paramètre ne s'applique que si la version de l'application définie par ce fichier `app.yaml` est configurée pour recevoir du trafic. Pour en savoir plus sur le routage du trafic vers les différentes versions d'une application, consultez la page Répartir le trafic. Facultatif. Nombre minimal d'instances que App Engine doit créer pour cette version de module. Ces instances diffusent le trafic lorsque des requêtes arrivent, et continuent à le diffuser même lorsque des instances supplémentaires sont lancées pour gérer le trafic. Spécifiez une valeur comprise entre 0 et 1 000. Vous pouvez définir le paramètre sur la valeur 0 pour permettre la mise à l'échelle de 0 instances afin de réduire les coûts lorsqu'aucune requête n'est diffusée. Notez que le nombre d'instances spécifié vous est facturé, qu'elles reçoivent ou non du trafic. `max_idle_instances` Facultatif. Nombre maximal d'instances inactives qu'App Engine doit gérer pour cette version. Définissez une valeur comprise entre 1 et 1 000. Si aucune valeur n'est spécifiée, la valeur par défaut est `automatic`, ce qui signifie qu'App Engine gère le nombre d'instances inactives. Tenez bien compte des éléments suivants : Une valeur maximale élevée réduit le nombre d'instances inactives de manière plus progressive lorsque les niveaux de charge reviennent à la normale après un pic. Votre application peut ainsi maintenir des performances constantes grâce aux fluctuations de la charge des requêtes. En revanche, cela augmente également le nombre d'instances inactives (et les coûts d'exploitation qui en découlent) pendant les périodes de charges importantes. Une valeur maximale faible réduit les coûts d'exploitation, mais peut dégrader les performances en présence de niveaux de charge instables. Remarque : Lorsque vous revenez à des niveaux normaux après un pic de charge, le nombre d'instances inactives peut temporairement dépasser la valeur maximale spécifiée. Cependant, le nombre d'instances qui vous sera facturé ne pourra pas dépasser le nombre maximal spécifié. `min_idle_instances` Avertissement : Pour veiller au bon fonctionnement de cette fonctionnalité, vous devez vous assurer que les requêtes de préchauffage sont activées et que votre application les gère. Remarque : Ce paramètre ne s'applique que si la version de l'application définie par ce fichier `app.yaml` est configurée pour recevoir du trafic. Pour en savoir plus sur le routage du trafic vers les différentes versions d'une application, consultez la page Répartir le trafic. Facultatif. Nombre d'instances supplémentaires qui doivent rester en cours d'exécution et prêtes à diffuser le trafic pour cette version. App Engine calcule le nombre d'instances nécessaires pour diffuser le trafic actuel de votre application en fonction de paramètres de scaling tels que `target_cpu_utilization` et `target_throughput_utilization`. En définissant `min_idle_instances`, vous spécifiez le nombre d'instances à exécuter en plus de ce nombre calculé. Par exemple, si App Engine calcule que cinq instances sont nécessaires pour diffuser le trafic et que `min_idle_instances` est défini sur deux, App Engine exécutera sept instances (cinq instances, soit le nombre calculé en fonction du trafic, plus deux instances supplémentaires selon `min_idle_instances`). Sachez que vous êtes facturé à hauteur du nombre d'instances spécifiées, que celles-ci reçoivent ou non du trafic. Tenez bien compte des éléments suivants : Une valeur minimale faible permet de limiter vos coûts d'exploitation pendant les périodes d'inactivité, mais signifie que le nombre d'instances immédiatement disponible en cas de pic de charge soudain risque d'être réduit. Une valeur minimale élevée vous permet de préparer l'application aux pics de charge rapides des requêtes. App Engine conserve le nombre minimal d'instances en cours d'exécution pour diffuser les requêtes entrantes. Vous êtes facturé à hauteur du nombre d'instances spécifiées, que celles-ci traitent ou non des requêtes. Si vous définissez un nombre minimal d'instances inactives, le temps de latence a moins d'impact sur les performances de votre application. `target_cpu_utilization` Facultatif. Définissez une valeur comprise entre 0,5 et 0,95. La valeur par défaut est `0.6`. Ce paramètre spécifie le seuil d'utilisation du processeur à partir duquel de nouvelles instances sont démarrées pour gérer le trafic. Vous pouvez ainsi trouver un bon équilibre entre les performances et les coûts. Les valeurs inférieures augmentent les performances et les coûts, et les valeurs supérieures diminuent les performances, mais également les coûts. Par exemple, une valeur de 0,7 signifie que de nouvelles instances sont démarrées lorsque l'utilisation du processeur atteint 70 %. `target_throughput_utilization` Facultatif. Définissez une valeur comprise entre 0,5 et 0,95. La valeur par défaut est `0.6`. Élément utilisé avec `max_concurrent_requests` pour spécifier le moment où une nouvelle instance est démarrée en raison de requêtes simultanées. Lorsque le nombre de requêtes simultanées atteint une valeur égale à `max_concurrent_requests` multiplié par `target_throughput_utilization`, le programmeur tente de démarrer une nouvelle instance. `max_concurrent_requests` Facultatif. Nombre de requêtes simultanées qu'une instance de scaling automatique peut accepter avant que le programmeur génère une nouvelle instance (par défaut : 10, maximum : 1 000). Élément utilisé avec `target_throughput_utilization` pour spécifier le moment où une nouvelle instance est démarrée en raison de requêtes simultanées. Lorsque le nombre de requêtes simultanées atteint une valeur égale à `max_concurrent_requests` multiplié par `target_throughput_utilization`, le programmeur tente de démarrer une nouvelle instance. Nous vous recommandons de ne pas définir `max_concurrent_requests` sur moins de 10, sauf si vous avez besoin d'un seul thread. Une valeur inférieure à 10 est susceptible de générer la création de plus d'instances que nécessaire pour une application threadsafe, ce qui peut entraîner des coûts inutiles. Si ce paramètre est trop élevé, la latence de l'API peut augmenter. Notez que le programmeur peut créer une instance avant que le nombre maximal de requêtes effectif soit atteint. `max_pending_latency` Durée maximale pendant laquelle App Engine doit autoriser une requête à rester dans la file d'attente avant de démarrer des instances supplémentaires pour gérer les requêtes, et ainsi réduire le temps de latence. Une fois le seuil atteint, le scaling débute et provoque une augmentation du nombre d'instances. Si aucune valeur n'est spécifiée, la valeur par défaut est `automatic`. Cela signifie que les requêtes peuvent rester dans la file d'attente pendant 10 secondes au maximum, ce qui correspond au délai maximal de mise en file d'attente des requêtes avant le déclenchement d'une nouvelle instance. Une valeur maximale faible signifie que App Engine démarre plus rapidement de nouvelles instances pour les requêtes en attente. Cela améliore les performances, mais augmente les coûts d'exploitation. Une valeur maximale élevée signifie que les utilisateurs peuvent attendre plus longtemps pour que l'application diffuse leur requête (s'il y a des requêtes en attente et qu'aucune instance inactive ne les diffuse), mais aussi que l'exécution de votre application est moins coûteuse. `min_pending_latency` Élément facultatif que vous pouvez définir pour spécifier la durée minimale pendant laquelle App Engine doit autoriser une requête à rester en file d'attente avant de démarrer une nouvelle instance pour la gérer. La spécification d'une valeur peut réduire les coûts d'exécution, mais augmenter le délai de diffusion des requêtes et donc le temps d'attente des utilisateurs. Pour les applications gratuites, la valeur par défaut est `500ms`. Pour les applications payantes, la valeur par défaut est `0`. Cet élément fonctionne avec l'élément `max_pending_latency` pour déterminer à quel moment App Engine crée des instances. Si des requêtes en attente se trouvent dans la file d'attente : Inférieure à la valeur pour `min_pending_latency` que vous spécifiez, App Engine ne crée pas d'instances. Supérieure à la valeur pour `max_pending_latency`, App Engine tente de créer une instance. entre le moment spécifié par `min_pending_latency` et `max_pending_latency`, App Engine tente de réutiliser une instance existante. Si aucune instance n'est en mesure de traiter la requête avant `max_pending_latency`, App Engine crée une instance. Exemple automatic_scaling: target_cpu_utilization: 0.65 min_instances: 5 max_instances: 100 min_pending_latency: 30ms max_pending_latency: automatic max_concurrent_requests: 50
`basic_scaling`	Les applications qui utilisent une classe d'instance B1 ou ultérieure doivent spécifier cet élément ou `manual_scaling`. Cet élément permet le scaling de base des classes d'instances B1 et supérieures. Il peut contenir les éléments suivants : `max_instances` Obligatoire. Nombre maximal d'instances qu'App Engine peut créer pour cette version du service. Cette solution permet de limiter les coûts d'un service. `idle_timeout` Facultatif. L'instance est arrêtée pendant cette période après réception de sa dernière requête. La valeur par défaut est de cinq minutes (`5m`). Exemple basic_scaling: max_instances: 11 idle_timeout: 10m
`manual_scaling`	Les applications qui utilisent une classe d'instance B1 ou ultérieure doivent spécifier cet élément ou `basic_scaling`. Cet élément active le scaling manuel des classes d'instances B1 et supérieures, et peut contenir l'élément suivant : `instances` Nombre d'instances à attribuer au service au démarrage. Exemple : manual_scaling: instances: 5

automatic_scaling

Facultatif. Applicable seulement aux applications qui utilisent une classe d'instance F1 ou supérieure.

Spécifiez cet élément pour modifier les paramètres par défaut du scaling automatique, tels que la définition de niveaux minimal et maximal pour le nombre d'instances, la latence et les connexions simultanées d'un service.

Cet élément peut contenir les éléments suivants :

max_instances

Facultatif. Indiquez une valeur comprise entre 0 et 2 147 483 647, où zéro désactive le paramètre.

Ce paramètre spécifie le nombre maximal d'instances que App Engine peut créer pour cette version de module. Cela permet de limiter les coûts d'un module.

min_instances

Remarque : Ce paramètre ne s'applique que si la version de l'application définie par ce fichier app.yaml est configurée pour recevoir du trafic. Pour en savoir plus sur le routage du trafic vers les différentes versions d'une application, consultez la page Répartir le trafic.

Facultatif. Nombre minimal d'instances que App Engine doit créer pour cette version de module. Ces instances diffusent le trafic lorsque des requêtes arrivent, et continuent à le diffuser même lorsque des instances supplémentaires sont lancées pour gérer le trafic.

Spécifiez une valeur comprise entre 0 et 1 000. Vous pouvez définir le paramètre sur la valeur 0 pour permettre la mise à l'échelle de 0 instances afin de réduire les coûts lorsqu'aucune requête n'est diffusée. Notez que le nombre d'instances spécifié vous est facturé, qu'elles reçoivent ou non du trafic.

max_idle_instances

Facultatif. Nombre maximal d'instances inactives qu'App Engine doit gérer pour cette version. Définissez une valeur comprise entre 1 et 1 000. Si aucune valeur n'est spécifiée, la valeur par défaut est automatic, ce qui signifie qu'App Engine gère le nombre d'instances inactives. Tenez bien compte des éléments suivants :

Une valeur maximale élevée réduit le nombre d'instances inactives de manière plus progressive lorsque les niveaux de charge reviennent à la normale après un pic. Votre application peut ainsi maintenir des performances constantes grâce aux fluctuations de la charge des requêtes. En revanche, cela augmente également le nombre d'instances inactives (et les coûts d'exploitation qui en découlent) pendant les périodes de charges importantes.
Une valeur maximale faible réduit les coûts d'exploitation, mais peut dégrader les performances en présence de niveaux de charge instables.

Remarque : Lorsque vous revenez à des niveaux normaux après un pic de charge, le nombre d'instances inactives peut temporairement dépasser la valeur maximale spécifiée. Cependant, le nombre d'instances qui vous sera facturé ne pourra pas dépasser le nombre maximal spécifié.

min_idle_instances

Facultatif. Nombre d'instances supplémentaires qui doivent rester en cours d'exécution et prêtes à diffuser le trafic pour cette version.

App Engine calcule le nombre d'instances nécessaires pour diffuser le trafic actuel de votre application en fonction de paramètres de scaling tels que target_cpu_utilization et target_throughput_utilization. En définissant min_idle_instances, vous spécifiez le nombre d'instances à exécuter en plus de ce nombre calculé. Par exemple, si App Engine calcule que cinq instances sont nécessaires pour diffuser le trafic et que min_idle_instances est défini sur deux, App Engine exécutera sept instances (cinq instances, soit le nombre calculé en fonction du trafic, plus deux instances supplémentaires selon min_idle_instances).

Sachez que vous êtes facturé à hauteur du nombre d'instances spécifiées, que celles-ci reçoivent ou non du trafic. Tenez bien compte des éléments suivants :

Une valeur minimale faible permet de limiter vos coûts d'exploitation pendant les périodes d'inactivité, mais signifie que le nombre d'instances immédiatement disponible en cas de pic de charge soudain risque d'être réduit.
Une valeur minimale élevée vous permet de préparer l'application aux pics de charge rapides des requêtes. App Engine conserve le nombre minimal d'instances en cours d'exécution pour diffuser les requêtes entrantes. Vous êtes facturé à hauteur du nombre d'instances spécifiées, que celles-ci traitent ou non des requêtes.

Si vous définissez un nombre minimal d'instances inactives, le temps de latence a moins d'impact sur les performances de votre application.

target_cpu_utilization

Facultatif. Définissez une valeur comprise entre 0,5 et 0,95. La valeur par défaut est 0.6.

Ce paramètre spécifie le seuil d'utilisation du processeur à partir duquel de nouvelles instances sont démarrées pour gérer le trafic. Vous pouvez ainsi trouver un bon équilibre entre les performances et les coûts. Les valeurs inférieures augmentent les performances et les coûts, et les valeurs supérieures diminuent les performances, mais également les coûts. Par exemple, une valeur de 0,7 signifie que de nouvelles instances sont démarrées lorsque l'utilisation du processeur atteint 70 %.

target_throughput_utilization

Facultatif. Définissez une valeur comprise entre 0,5 et 0,95. La valeur par défaut est 0.6.

Élément utilisé avec max_concurrent_requests pour spécifier le moment où une nouvelle instance est démarrée en raison de requêtes simultanées. Lorsque le nombre de requêtes simultanées atteint une valeur égale à max_concurrent_requests multiplié par target_throughput_utilization, le programmeur tente de démarrer une nouvelle instance.

max_concurrent_requests

Facultatif. Nombre de requêtes simultanées qu'une instance de scaling automatique peut accepter avant que le programmeur génère une nouvelle instance (par défaut : 10, maximum : 1 000).

Élément utilisé avec target_throughput_utilization pour spécifier le moment où une nouvelle instance est démarrée en raison de requêtes simultanées. Lorsque le nombre de requêtes simultanées atteint une valeur égale à max_concurrent_requests multiplié par target_throughput_utilization, le programmeur tente de démarrer une nouvelle instance.

Nous vous recommandons de ne pas définir max_concurrent_requests sur moins de 10, sauf si vous avez besoin d'un seul thread. Une valeur inférieure à 10 est susceptible de générer la création de plus d'instances que nécessaire pour une application threadsafe, ce qui peut entraîner des coûts inutiles.

Si ce paramètre est trop élevé, la latence de l'API peut augmenter. Notez que le programmeur peut créer une instance avant que le nombre maximal de requêtes effectif soit atteint.

max_pending_latency

Durée maximale pendant laquelle App Engine doit autoriser une requête à rester dans la file d'attente avant de démarrer des instances supplémentaires pour gérer les requêtes, et ainsi réduire le temps de latence. Une fois le seuil atteint, le scaling débute et provoque une augmentation du nombre d'instances. Si aucune valeur n'est spécifiée, la valeur par défaut est automatic. Cela signifie que les requêtes peuvent rester dans la file d'attente pendant 10 secondes au maximum, ce qui correspond au délai maximal de mise en file d'attente des requêtes avant le déclenchement d'une nouvelle instance.

Une valeur maximale faible signifie que App Engine démarre plus rapidement de nouvelles instances pour les requêtes en attente. Cela améliore les performances, mais augmente les coûts d'exploitation.

Une valeur maximale élevée signifie que les utilisateurs peuvent attendre plus longtemps pour que l'application diffuse leur requête (s'il y a des requêtes en attente et qu'aucune instance inactive ne les diffuse), mais aussi que l'exécution de votre application est moins coûteuse.

min_pending_latency

Élément facultatif que vous pouvez définir pour spécifier la durée minimale pendant laquelle App Engine doit autoriser une requête à rester en file d'attente avant de démarrer une nouvelle instance pour la gérer. La spécification d'une valeur peut réduire les coûts d'exécution, mais augmenter le délai de diffusion des requêtes et donc le temps d'attente des utilisateurs.

Pour les applications gratuites, la valeur par défaut est 500ms. Pour les applications payantes, la valeur par défaut est 0.

Cet élément fonctionne avec l'élément max_pending_latency pour déterminer à quel moment App Engine crée des instances. Si des requêtes en attente se trouvent dans la file d'attente :

Inférieure à la valeur pour min_pending_latency que vous spécifiez, App Engine ne crée pas d'instances.
Supérieure à la valeur pour max_pending_latency, App Engine tente de créer une instance.
entre le moment spécifié par min_pending_latency et max_pending_latency, App Engine tente de réutiliser une instance existante. Si aucune instance n'est en mesure de traiter la requête avant max_pending_latency, App Engine crée une instance.

Exemple

automatic_scaling:
  target_cpu_utilization: 0.65
  min_instances: 5
  max_instances: 100
  min_pending_latency: 30ms
  max_pending_latency: automatic
  max_concurrent_requests: 50

basic_scaling

Les applications qui utilisent une classe d'instance B1 ou ultérieure doivent spécifier cet élément ou manual_scaling.

Cet élément permet le scaling de base des classes d'instances B1 et supérieures. Il peut contenir les éléments suivants :

max_instances: Obligatoire. Nombre maximal d'instances qu'App Engine peut créer pour cette version du service. Cette solution permet de limiter les coûts d'un service.
idle_timeout: Facultatif. L'instance est arrêtée pendant cette période après réception de sa dernière requête. La valeur par défaut est de cinq minutes (5m).

Exemple

basic_scaling:
  max_instances: 11
  idle_timeout: 10m

manual_scaling

Les applications qui utilisent une classe d'instance B1 ou ultérieure doivent spécifier cet élément ou basic_scaling.

Cet élément active le scaling manuel des classes d'instances B1 et supérieures, et peut contenir l'élément suivant :

instances: Nombre d'instances à attribuer au service au démarrage.

Exemple :

manual_scaling:
  instances: 5