Cette page explique comment installer et utiliser les anciens services groupés fournis avec l'environnement d'exécution Python 3 pour l'environnement standard. Votre application doit accéder aux services groupés via le SDK des services App Engine pour Python 3.
Avant de commencer
- Consultez la liste des API des anciens services groupés que vous pouvez appeler dans l'environnement d'exécution Python.
- Avant de démarrer un projet de migration vers Python 3, consultez les pages Présentation de la migration de l'environnement d'exécution et Considérations sur la migration lors de l'utilisation des anciens services groupés.
Installer le SDK des services App Engine
Pour installer le SDK des services App Engine, procédez comme suit :
Ajoutez le SDK à votre application en incluant la ligne suivante dans le fichier
requirements.txt
:appengine-python-standard>=1.0.0
Vous trouverez le SDK sur GitHub sous le dépôt
appengine-python-standard
et sur PyPI.Ajoutez le code suivant dans votre script Python principal. Ce code crée un middleware WSGI qui définit les variables requises pour activer les appels d'API.
Flask
from flask import Flask from google.appengine.api import wrap_wsgi_app app = Flask(__name__) app.wsgi_app = wrap_wsgi_app(app.wsgi_app)
Django
from DJANGO_PROJECT_NAME.wsgi import application from google.appengine.api import wrap_wsgi_app app = wrap_wsgi_app(application)
Pyramid
from pyramid.config import Configurator from google.appengine.api import wrap_wsgi_app config = Configurator() # make configuration settings app = config.make_wsgi_app() app = wrap_wsgi_app(app)
WSGI
import google.appengine.api def app(environ, start_response): start_response('200 OK', [('Content-Type', 'text/plain')]) yield b'Hello world!\n' app = google.appengine.api.wrap_wsgi_app(app)
Ajoutez la ligne suivante au fichier
app.yaml
avant de déployer l'application :app_engine_apis: true
Pour déployer votre application, utilisez la commande
gcloud app deploy
.
Considérations sur la migration
Tenez compte des considérations suivantes si vous effectuez une migration vers l'environnement d'exécution Python 3 et que votre application utilise des anciens services groupés.
Tests
Pour tester localement la fonctionnalité concernant les anciens services groupés dans votre application Python 3, utilisez le serveur de développement local.
Lorsque vous exécutez la commande dev_appserver.py
, vous devez définir l'argument --runtime_python_path
en spécifiant un chemin d'accès à l'interpréteur Python 3.
Exemple :
python3 CLOUD_SDK_ROOT/bin/dev_appserver.py --runtime_python_path=/usr/bin/python3
Vous pouvez également définir l'argument sur une liste de paires [RUNTIME_ID]=[PYTHON_INTERPRETER_PATH]
séparées par une virgule. Exemple :
python3 CLOUD_SDK_ROOT/bin/dev_appserver.py --runtime_python_path="python27=/user/bin/python2.7,python3=/usr/bin/python3"
Compatibilité avec le fichier pickle
Les services partagés, y compris Memcache, Cloud NDB et la configuration différée, utilisent le module pickle pour sérialiser et partager des objets Python. Si votre environnement App Engine utilise à la fois Python 2 et Python 3, ce qui est courant lors d'une migration, vous devez vous assurer que les objets sérialisés partagés écrits par une version de Python peuvent être reconstitués par l'autre. Vous trouverez des conseils sur la mise en œuvre de la compatibilité entre versions du module pickle dans ce guide.
Par défaut, Python 3 utilise des protocoles de pickling qui ne sont pas compatibles avec Python 2.
Cela peut entraîner des échecs lorsque votre application tente de reconstituer un objet Python dans un environnement Python 2 qui a été écrit dans un environnement Python 3.
Pour éviter ce problème, définissez les variables d'environnement suivantes dans le fichier app.yaml
de votre application Python 3 si nécessaire :
- Pour les applications qui utilisent Memcache, y compris celles qui utilisent NDB, définissez :
MEMCACHE_USE_CROSS_COMPATIBLE_PROTOCOL: 'True'
- Pour les applications qui utilisent NDB pour se connecter à Datastore, définissez :
NDB_USE_CROSS_COMPATIBLE_PICKLE_PROTOCOL: 'True'
- Pour les applications qui utilisent la configuration différée, définissez :
DEFERRED_USE_CROSS_COMPATIBLE_PICKLE_PROTOCOL: 'True'
Dans Python 2, les objets string
contiennent une séquence de valeurs de 8 octets. Dans Python 3, les objets string
contiennent une séquence de caractères Unicode. Par défaut, le module pickle Python 3 traduit un fichier string
Python 2 au format Unicode en interprétant l'objet string
Python 3 en caractères ASCII. Cela peut entraîner des erreurs pour des valeurs non comprises dans la plage de caractères ASCII de 0 à 127. Memcache permet de remplacer ce mappage par défaut.
from google.appengine.api import memcache
import six.moves.cPickle as pickle
def _unpickle_factory(file):
return pickle.Unpickler(file, encoding='latin1')
memcache.setup_client(memcache.Client(unpickler=_unpickle_factory))
L'encodage latin1
définit un mappage pour chacune des 256 valeurs possibles de chaque octet dans un objet string
Python 2. Cela évite les erreurs de décodage. Cependant, si votre objet string
Python 2 contient des données Unicode réelles en dehors de la plage latin1
, telles que des données lues à partir d'un fichier, cPickle ne mappera pas correctement les données. Par conséquent, il est important de mettre à jour votre code Python 2 pour conserver les données Unicode avec des objets unicode
et non des objets string
, pour les objets que vous "picklez". Le guide de compatibilité inclut des informations sur les mises à jour nécessaires.
La méthode décrite précédemment pour mettre à jour votre code Python 2 afin de produire des sérialisations compatibles avec Python 3 concerne les sérialisations de courte durée, telles que celles stockées dans Memcache. Vous devrez peut-être mettre à jour ou réécrire les sérialisations Python 2 de longue durée, telles que celles stockées dans Datastore lors de votre migration. Par exemple, la sérialisation écrite à l'aide de google.appengine.ext.ndb.model.PickleProperty
peut nécessiter une mise à niveau.
Consultez le guide de compatibilité pour en savoir plus sur les limites et les problèmes moins courants.
Frameworks Web
webapp2
n'est pas groupé ou accepté dans Python 3. Les applications doivent donc être réécrites afin d'inclure l'utilisation d'un framework compatible avec WSGI (tel que Flask).
Une stratégie de migration recommandée consiste à remplacer webapp2
dans votre application Python 2.7 par Flask (ou un framework Web alternatif tel que Django, Pyramid, Bottle ou web.py), tout en restant sur Python 2.7.
Ensuite, lorsque votre application mise à jour est stable, migrez le code vers Python 3, puis déployez et testez votre application à l'aide d'App Engine pour Python 3.
Pour obtenir des exemples de conversion d'applications Python 2.7 qui définissent webapp2
pour utiliser le framework Flask, vous pouvez consulter ces ressources supplémentaires.
Utiliser des gestionnaires
Une application Python 3 ne peut être associée qu'à un seul script. Par conséquent, si votre fichier app.yaml
contient plusieurs gestionnaires script
qui mappent des URL à différents scripts, vous devez combiner ces scripts en un seul script qui gère le routage d'URL.
L'exemple suivant montre les différences des gestionnaires dans le fichier app.yaml
pour les différents environnements d'exécution.
Python 2
runtime: python27 api_version: 1 threadsafe: true handlers: - url: / script: home.app - url: /index\.html script: home.app - url: /stylesheets static_dir: stylesheets - url: /(.*\.(gif|png|jpg))$ static_files: static/\1 upload: static/.*\.(gif|png|jpg)$ - url: /admin/.* script: admin.app login: admin - url: /.* script: not_found.app
Python 3
runtime: python312
app_engine_apis: true
handlers:
- url: /stylesheets
static_dir: stylesheets
- url: /(.*\.(gif|png|jpg))$
static_files: static/\1
upload: static/.*\.(gif|png|jpg)$
- url: /admin/.*
script: auto
login: admin
Votre application Python 3 doit gérer le routage d'URL (par exemple, avec les décorateurs Flask).
Si vous souhaitez utiliser plusieurs gestionnaires script
avec différents formats d'URL ou d'autres attributs dans vos gestionnaires, chaque gestionnaire doit spécifier script: auto
.
Vous pouvez également remplacer le comportement de démarrage par défaut en spécifiant un champ entrypoint
dans votre fichier app.yaml
.
Pour en savoir plus sur l'utilisation de gestionnaires spécifiques, consultez les présentations de Blobstore, du déploiement différé et de la messagerie.
Thread safety
Les applications sont considérées comme sécurisées. Les appels d'API doivent être effectués sur le thread de requête. Le fait d'utiliser une ancienne API de services groupés au démarrage de l'application peut entraîner des erreurs de sécurité.
Pour en savoir plus, consultez la page Erreurs de sécurité lors de l'utilisation des anciens services groupés pour Python.
Utiliser le service URL Fetch
Pour utiliser URL Fetch pour Python, vous devez appeler explicitement la bibliothèque URL Fetch.
Si votre application Python 3 utilise l'API URL Fetch, l'en-tête de requête X-Appengine-Inbound-Appid
est ajouté lorsque votre application envoie une requête à une autre application App Engine. Cela permet à l'application de réception de vérifier l'identité de l'application appelante. Pour en savoir plus, consultez la section Migrer des requêtes sortantes.
Exemple (ndb
App Engine)
Vous trouverez ci-dessous une application Python 2 de base qui enregistre les visites de pages avec App Engine ndb
pour accéder à Datastore. Elle est associée à une application Python 3 équivalente à l'utilisation de webapp2
, qui a été remplacée par Flask et les modifications requises décrites ci-dessus pour accéder aux services groupés dans Python 3 ont été mises en œuvre.
Python 2 (webapp2
)
Python 3 (Flask)
Ces deux applications sont disponibles dans le dépôt Open Source du contenu de migration App Engine Python (exemples de code, vidéos, ateliers de programmation), en particulier dans les dossiers mod0
et mod1b
, respectivement.