Environnement d'exécution Python 2

Avec App Engine, vous pouvez créer des applications Web à l'aide du langage de programmation Python et tirer parti des nombreux outils et des nombreux frameworks et bibliothèques pour Python utilisés par les développeurs professionnels afin de créer des applications Web de classe mondiale. Votre application Python s'exécute sur l'infrastructure évolutive de Google et utilise ses capacités de stockage permanent et ses services à grande échelle.

Présentation

App Engine exécute votre code d'application Python à l'aide d'un interpréteur Python pré-chargé dans un environnement sécurisé en mode "bac à sable". Votre application reçoit des requêtes Web, exécute des tâches et envoie des réponses en communiquant avec cet environnement.

Une application Web Python interagit avec le serveur Web App Engine à l'aide du protocole WSGI. Les applications peuvent donc utiliser n'importe quel framework d'application Web compatible WSGI. App Engine inclut un framework d'applications Web tout simple, appelé webapp2, pour faciliter la mise en route. Pour les applications plus importantes, des frameworks tiers plus sophistiqués, tels que Django, fonctionnent bien avec App Engine.

L'interpréteur Python peut exécuter n'importe quel code Python, y compris les modules Python que vous incluez avec votre application, ainsi que la bibliothèque standard Python. L'interpréteur ne peut pas charger les modules Python avec du code C ; c'est un environnement "pur" Python.

L'environnement de "bac à sable" sécurisé isole votre application à des fins de service et de sécurité. Ainsi, les opérations effectuées par une application donnée n'ont aucune incidence sur les performances et l'évolutivité des autres applications. Par exemple, une application ne peut pas écrire de données dans le système de fichiers local ni établir de connexions réseau arbitraires. En revanche, les applications utilisent les services évolutifs fournis par App Engine pour stocker des données et communiquer via Internet. L'interpréteur Python déclenche une exception lorsqu'une application tente d'importer un module Python à partir de la bibliothèque standard connue pour ne pas fonctionner dans les restrictions du bac à sable.

La plate-forme App Engine offre de nombreux services que votre code peut appeler. Votre application peut également configurer des tâches planifiées qui s'exécutent à des intervalles donnés.

Sélectionner l'environnement d'exécution Python 2

Vous spécifiez l'environnement d'exécution Python dans le fichier de configuration app.yaml, qui est utilisé pour déployer votre application dans App Engine. Par exemple, vous ajoutez ce qui suit au fichier app.yaml pour utiliser Python version 2.7 :

runtime: python27
api_version: 1
threadsafe: true
...

Le premier élément, runtime, sélectionne l'environnement d'exécution Python.

Le second élément, api_version, sélectionne la version de l'environnement d'exécution Python à utiliser. Au moment où cette section a été rédigée, App Engine comportait une seule version de l'environnement Python, 1. Si l'équipe App Engine devait apporter à l'environnement des modifications non compatibles avec le code existant, elle utiliserait un nouvel identifiant de version. Votre application continuera à utiliser la version sélectionnée jusqu'à ce que vous modifiiez le paramètre api_version et transfériez votre application.

Pour plus d'informations sur le fichier app.yaml et comment déployer votre application sur App Engine, consultez la documentation de référence sur app.yaml ainsi que les sujets Migration vers Python 2.7 et Déployer une application Python.

Bac à sable

Pour qu'App Engine puisse distribuer des requêtes aux applications de plusieurs serveurs Web, et pour éviter qu'une application interfère avec une autre, l'application s'exécute dans un environnement de "bac à sable" restreint. Dans cet environnement, l'application peut exécuter du code, stocker et interroger les données dans Datastore, utiliser les services de messagerie, de récupération d'URL et d'utilisateurs App Engine, examiner la requête Web de l'utilisateur et préparer la réponse.

Une application App Engine ne peut pas :

  • Écrire sur le système de fichiers. Les applications doivent utiliser Datastore pour stocker des données persistantes. La lecture à partir du système de fichiers est autorisée, et tous les fichiers transférés avec l'application sont disponibles.

  • répondre lentement. Une requête Web vers une application doit être traitée en quelques secondes. Les processus qui mettent trop de temps à répondre sont interrompus afin d'éviter de surcharger le serveur Web ;

  • effectuer d'autres types d'appels système.

Bac à sable dans Python

Vous pouvez importer et utiliser des fichiers .pyc lorsque vous utilisez l'environnement d'exécution Python 2.7, mais vous ne pouvez pas importer une version .py et .pyc d'un même fichier. Vous pouvez importer des fichiers .zip contenant des fichiers .py ou .pyc (ou les deux). Un certain nombre de mises en garde importantes s’appliquent si vous importez des fichiers .pyc :

  • Pour un script CGI, le gestionnaire de script doit toujours utiliser l'extension de fichier .py, même si vous importez un fichier .pyc.
  • Par défaut, les fichiers .pyc sont ignorés lors du déploiement. Vous devez remplacer l'élément skip_files dans votre fichier app.yaml afin que les fichiers .pyc ne soient pas ignorés à cause de la nouvelle valeur.
  • Vous devez utiliser Python 2.7 pour créer le fichier .pyc. Si vous possédez une autre version de Python (telle que Python 2.6) sur votre ordinateur de développement, vous devez obtenir la version 2.7 pour créer un fichier .pyc compatible.

Python 2 pur

L'intégralité du code pour l'environnement d'exécution Python doit être du Python pur et ne doit inclure aucune extension en langage C ni aucun autre code nécessitant une compilation.

L'environnement comprend la bibliothèque standard Python. Certains modules ont été désactivés, car leurs principales fonctions, telles que la mise en réseau ou l'écriture dans le système de fichiers, ne sont pas prises en charge par App Engine. Par ailleurs, le module os est disponible, mais les fonctions incompatibles sont désactivées. Toute tentative d'importation d'un module incompatible ou d'utilisation d'une fonction incompatible génère une exception.

Quelques modules de la bibliothèque standard ont été remplacés ou personnalisés pour fonctionner avec App Engine. Ces modules varient entre les deux environnements d'exécution Python, comme décrit ci-dessous.

Bibliothèques personnalisées dans Python version 2.7

Dans l'environnement d'exécution de la version 2.7 de Python, les modules suivants ont été remplacés ou personnalisés :

  • tempfile est désactivé, sauf pour TemporaryFile qui est associé à StringIO.

  • logging est disponible et son utilisation est fortement encouragée ! Consultez la page sur le module logging pour en savoir plus.

Outre la bibliothèque standard Python et les bibliothèques App Engine, l'environnement d'exécution Python version 2.7 inclut plusieurs bibliothèques tierces.

Ajout de bibliothèques tierces Python

Vous pouvez inclure des bibliothèques Python tierces avec votre application en plaçant le code dans votre répertoire d'application. Si vous créez un lien symbolique vers le répertoire d'une bibliothèque dans votre répertoire d'application, ce lien est suivi et la bibliothèque est incluse dans l'application que vous déployez dans App Engine.

Le chemin d'inclusion du module Python inclut le répertoire racine de votre application, qui est le répertoire contenant le fichier app.yaml. Les modules Python que vous créez dans le répertoire racine de votre application sont disponibles via un chemin depuis la racine. N'oubliez pas de créer les fichiers __init__.py requis dans vos sous-répertoires afin que Python les reconnaisse comme des packages. Assurez-vous également que vos bibliothèques n’ont pas besoin d’extensions C.

Threads

Les threads peuvent être créés dans Python version 2.7 à l'aide des modules thread ou threading. Notez que l'environnement d'exécution rejoindra les threads à la fin de la requête afin que ceux-ci ne puissent pas s'exécuter après la fin de la requête.

Threads en arrière-plan

Le code exécuté sur une instance de scaling manuel ou de base peut démarrer un thread en arrière-plan pouvant survivre à la requête qui le génère. Cela permet à une instance d'effectuer des tâches périodiques ou planifiées arbitraires ou de continuer à travailler en arrière-plan après le retour d'une requête à l'utilisateur.

Les entrées os.environ et de journalisation d'un thread d'arrière-plan sont indépendantes de celles du thread générateur.

Vous devez importer le module google.appengine.api.background_thread à partir du SDK pour App Engine.

from google.appengine.api import background_thread

La classe BackgroundThread ressemble à la classe Python standard threading.Threadclass, mais peut "survivre" à la requête qui l'engendre. Il existe également la fonction start_new_background_thread() qui crée un thread d'arrière-plan et le lance :

# sample function to run in a background thread
def change_val(arg):
    global val
    val = arg

if auto:
    # Start the new thread in one command
    background_thread.start_new_background_thread(change_val, ['Cat'])
else:
    # create a new thread and start it
    t = background_thread.BackgroundThread(
        target=change_val, args=['Cat'])
    t.start()
Le nombre maximal de fils de discussion en arrière-plan simultanés créés par l'API App Engine est de 10 par instance. (Cette limite ne s'applique pas aux threads Java normaux non liés à l'API App Engine.)

Outils

Le SDK pour App Engine comprend des outils permettant de tester votre application, d'importer des fichiers d'application, de gérer des index Datastore, de télécharger des données de journal et d'importer de grandes quantités de données dans Datastore.

Le serveur de développement exécute votre application sur votre ordinateur local pour le tester. Le serveur simule les restrictions liées aux services Datastore et au bac à sable. Le serveur de développement peut également générer une configuration pour les index Datastore sur la base des requêtes exécutées par l'application durant les tests.

L'outil gcloud gère toutes les interactions de ligne de commande avec l'application s'exécutant sur App Engine. Vous utilisez gcloud app deploy pour importer votre application dans App Engine ou pour mettre à jour des fichiers de configuration spécifiques, comme la configuration de l'index Datastore, qui vous permet de créer de nouveaux index avant de déployer votre code. Vous pouvez également afficher les données de journal de votre application afin d'analyser les performances de votre application à l'aide de vos propres outils.

Concurrence et latence

La latence de votre application a le plus grand impact sur le nombre d'instances nécessaires pour desservir votre trafic. Si vous traitez les requêtes rapidement, une seule instance peut gérer un grand nombre de requêtes.

Les instances à un seul thread peuvent gérer une requête simultanée. Par conséquent, il existe une relation directe entre le temps de latence et le nombre de requêtes pouvant être traitées sur l'instance par seconde. Par exemple, une latence de 10 ms équivaut à 100 requêtes/seconde/instance.

Les instances à plusieurs threads peuvent gérer de nombreuses requêtes simultanées. Par conséquent, il existe une relation directe entre le nombre de processeurs consommés et le nombre de requêtes/seconde.

Les applications Python version 2.7 prennent en charge les requêtes simultanées, de sorte qu'une seule instance peut gérer les nouvelles requêtes tout en en attendant d'autres. La simultanéité réduit considérablement le nombre d'instances requises par votre application, mais vous devez concevoir votre application pour qu'elle soit compatible avec le multithreading.

Par exemple, si une instance B4 (environ 2,4 GHz) consomme 10 Mcycles/requête, vous pouvez traiter 240 requêtes/seconde/instance. Si elle consomme 100 Mcycles/requête, vous pouvez traiter 24 requêtes/seconde/instance. Ces chiffres sont le cas idéal mais sont assez réalistes par rapport à ce que vous pouvez accomplir sur une instance.

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_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.

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.