Environnement d'exécution Python 3

L'environnement d'exécution Python est la pile logicielle chargée d'installer le code de votre service Web et ses dépendances, et d'exécuter votre service App Engine.

L'environnement d'exécution Python pour App Engine dans l'environnement standard est déclaré dans le fichier app.yaml :

runtime: pythonVERSION

Où VERSION correspond aux numéros de version Python MAJOR et MINOR. Par exemple, pour utiliser la dernière version de Python, Python 3.12, spécifiez 312.

Pour les autres versions de Python compatibles, ainsi que pour la version d'Ubuntu correspondante pour votre version de Python, consultez le Calendrier de compatibilité des environnements d'exécution.

Versions Python 3

L'environnement d'exécution Python utilise la dernière version stable de la version spécifiée dans votre fichier app.yaml. App Engine se met automatiquement à jour en cas de nouvelle version corrective, mais pas en cas de nouvelle version mineure.

Par exemple, l'application peut être déployée sur Python 3.7.0 et faire ultérieurement l'objet d'une mise à jour automatique vers la version 3.7.1, mais elle ne sera pas automatiquement mise à jour vers la prochaine version mineure Python 3.8.0.

Faites l'essai

Si vous débutez sur Google Cloud, créez un compte pour évaluer les performances d'App Engine en conditions réelles. Les nouveaux clients bénéficient également de 300 $ de crédits gratuits pour exécuter, tester et déployer des charges de travail.

Profiter d'un essai gratuit d'App Engine

App Engine exécute des applications Python dans un conteneur sécurisé par gVisor sur une distribution Linux Ubuntu mise à jour.

Dépendances

Lors du déploiement, App Engine utilise le gestionnaire de packages Python pip pour installer les dépendances définies dans le fichier de métadonnées requirements.txt du répertoire racine de votre projet. Aucune dépendance n'a besoin d'être téléchargée puisqu'App Engine effectue une nouvelle installation.

La spécification de dépendances utilisant la norme Pipfile/Pipfile.lock n'est actuellement pas possible et votre projet ne doit pas contenir ces fichiers.

Démarrage de l'application

L'environnement d'exécution démarre votre application en exécutant la commande spécifiée dans le champ entrypoint du fichier app.yaml. Si vous avez configuré un point d'entrée de serveur Web Gunicorn dans le fichier app.yaml, vous devez également ajouter gunicorn à votre fichier requirements.txt.

Le point d'entrée doit démarrer un serveur Web qui écoute le port spécifié par la variable d'environnement PORT. Exemple :

entrypoint: gunicorn -b :$PORT main:app

Le framework Web utilisé par votre application prend en charge le routage des requêtes vers les gestionnaires appropriés de votre application.

Si vous ne spécifiez pas le champ entrypoint et que votre application répond aux exigences suivantes, App Engine la démarre avec le serveur Web gunicorn.

• La racine du répertoire de votre application contient un fichier main.py avec un objet compatible WSGI appelé app.

• Votre application ne contient pas de fichiers Pipfile ou Pipfile.lock.

Si vous ne spécifiez pas de point d'entrée pour l'environnement d'exécution Python 3, App Engine configure et démarre le serveur Web Gunicorn par défaut.

Remarque : La valeur default timeout of gunicorn est de 30 secondes lorsque le champ entrypoint est spécifié. Les nœuds de calcul silencieux pendant plus longtemps que ce délai sont supprimés et redémarrés. Si votre gestionnaire prend plus de 30 secondes, vous pouvez rencontrer une erreur [CRITICAL] WORKER TIMEOUT. Pour vous assurer que la requête aboutit, en fonction de votre cas d'utilisation, vous pouvez utiliser -- timeout flag dans le champ entrypoint pour augmenter le délai avant expiration.

Bonnes pratiques relatives à entrypoint

• Vérifiez que le module Python requis pour exécuter le point d'entrée spécifié dans app.yaml est présent dans le fichier requirements.txt. Ajoutez gunicorn au fichier requirements.txt uniquement si un point de terminaison gunicorn est explicitement spécifié dans le fichier app.yaml.

• Pour des performances optimales, l'entrypoint doit être léger, car il s’exécute à chaque création d'une instance de votre application.

• Vous pouvez exploiter le champ entrypoint pour ajuster les performances de votre application. Par exemple, si vous utilisez gunicorn comme serveur Web, vous pouvez employer l'option --workers dans le champ entrypoint pour configurer le nombre de nœuds de calcul diffusant votre application.

  Le nombre de nœuds de calcul que vous spécifiez doit correspondre à la classe d'instance de votre application App Engine :

  Classe d'instance	Nœuds de calcul
  F1	2
  F2	4
  F4	8
  F4_1G	8
  B1	2
  B2	4
  B4	8
  B4_1G	8
  B8	8

  Ces conseils servent de point de départ pour sélectionner le nombre de nœuds de calcul. Vous devrez peut-être utiliser un autre nombre de nœuds de calcul en fonction des caractéristiques de performance de votre application. L'exemple ci-dessous illustre un déploiement App Engine qui utilise deux nœuds de calculs gunicorn pour diffuser les applications :

  entrypoint: gunicorn -b :$PORT -w 2 main:app
  

• Nous vous recommandons de configurer votre serveur Web pour écouter les requêtes HTTP et y répondre sur le port spécifié par votre variable d'environnement $PORT. L'utilisation du port par défaut 8080 empêche App Engine d'utiliser sa couche NGINX pour compresser les réponses HTTP. Notez que si vous utilisez le port 8080, des avertissements concernant le port 8080 et NGINX s'affichent dans les fichiers journaux de votre application.

Autres frameworks Web

Outre Django et Flask, vous pouvez utiliser d'autres frameworks Web avec App Engine, tels que uwsgi et Tornado L'exemple suivant montre comment utiliser uwsgi avec App Engine :

runtime: python39
entrypoint: uwsgi --http-socket :$PORT --wsgi-file main.py --callable app --master --processes 1 --threads 2

uwsgi==2.0.22
Flask==3.0.0

Variables d'environnement

Les variables d'environnement suivantes sont définies par l'environnement d'exécution :

Variable d'environnement	Description
GAE_APPLICATION	ID de votre application App Engine. Cet ID est précédé du préfixe "region code~", tel que "e~" pour les applications déployées en Europe.
GAE_DEPLOYMENT_ID	ID du déploiement actuel.
GAE_ENV	Environnement App Engine. Variable définie sur standard.
GAE_INSTANCE	ID de l'instance sur laquelle votre service est en cours d'exécution.
GAE_MEMORY_MB	Quantité de mémoire disponible pour le processus d'application, en Mo.
GAE_RUNTIME	Environnement d'exécution spécifié dans le fichier app.yaml.
GAE_SERVICE	Nom de service spécifié dans le fichier app.yaml. Si aucun nom de service n'est spécifié, il est défini par défaut sur default.
GAE_VERSION	Libellé de la version actuelle du service.
GOOGLE_CLOUD_PROJECT	ID du projet Google Cloud associé à votre application.
PORT	Port qui reçoit les requêtes HTTP.
NODE_ENV (disponible uniquement dans l'environnement d'exécution Node.js)	Variable définie sur production lorsque votre service est déployé.

Vous pouvez définir des variables d'environnement supplémentaires dans le fichier app.yaml, mais les valeurs ci-dessus ne peuvent pas être remplacées, sauf NODE_ENV.

HTTPS et proxy de transfert

App Engine met fin aux connexions HTTPS au niveau de l'équilibreur de charge et transfère les requêtes à votre application. Certaines applications doivent déterminer l'adresse IP et le protocole de la requête d'origine. L'adresse IP de l'utilisateur est disponible dans l'en-tête standard X-Forwarded-For. Les applications nécessitant ces informations doivent configurer leur framework Web pour qu'il fasse confiance au proxy.

Système de fichiers

L'environnement d'exécution comprend un système de fichiers complet. Le système de fichiers est en lecture seule, à l'exception de l'emplacement /tmp, qui est un disque virtuel stockant les données dans la mémoire RAM de votre instance App Engine.

Serveur de métadonnées

Chaque instance de votre application peut demander des informations sur l'instance et votre projet à l'aide du serveur de métadonnées App Engine.

Remarque : Les métadonnées personnalisées ne sont pas acceptées dans l'environnement standard.

Vous pouvez accéder au serveur de métadonnées via les points de terminaison suivants :

• http://metadata
• http://metadata.google.internal

Les requêtes envoyées au serveur de métadonnées doivent inclure l'en-tête de requête Metadata-Flavor: Google. Cet en-tête indique que la requête a été envoyée dans le but de récupérer les valeurs de métadonnées.

La table suivante répertorie les points de terminaison sur lesquels vous pouvez effectuer des requêtes HTTP pour des métadonnées spécifiques :

Point de terminaison des métadonnées	Description
/computeMetadata/v1/project/numeric-project-id	Numéro de projet attribué à votre projet.
/computeMetadata/v1/project/project-id	ID de projet attribué à votre projet.
/computeMetadata/v1/instance/region	Région dans laquelle l'instance est en cours d'exécution.
/computeMetadata/v1/instance/service-accounts/default/aliases
/computeMetadata/v1/instance/service-accounts/default/email	Adresse e-mail du compte de service par défaut attribué à votre projet.
/computeMetadata/v1/instance/service-accounts/default/	Répertorie tous les comptes de service par défaut pour votre projet.
/computeMetadata/v1/instance/service-accounts/default/scopes	Répertorie tous les champs d'application disponibles pour les comptes de service par défaut.
/computeMetadata/v1/instance/service-accounts/default/token	Renvoie le jeton d'authentification pouvant servir à authentifier votre application auprès d'autres API Google Cloud.

Par exemple, pour récupérer votre ID de projet, envoyez une requête à http://metadata.google.internal/computeMetadata/v1/project/project-id.