1. Présentation
La série d'ateliers de programmation sur la station de migration sans serveur (tutoriels pratiques et d'auto-formation) et les vidéos associées visent à aider les développeurs sans serveur Google Cloud à moderniser leurs applications en les guidant dans une ou plusieurs migrations, principalement en abandonnant les anciens services. Vous améliorez ainsi la portabilité de vos applications, et vous bénéficiez de plus d'options et de flexibilité. Vous pouvez ainsi intégrer un plus large éventail de produits Cloud et y accéder, et passer plus facilement à de nouvelles langues. Bien qu'elle s'adresse initialement aux utilisateurs les plus anciens du cloud, principalement les développeurs d'environnements App Engine (standard), cette série est suffisamment large pour inclure d'autres plates-formes sans serveur telles que Cloud Functions et Cloud Run, ou ailleurs, le cas échéant.
Auparavant, les développeurs devaient effectuer la migration à partir des anciens "services groupés" d'App Engine. comme Datastore et Memcache avant de pouvoir mettre à niveau des versions linguistiques, deux opérations potentiellement difficiles à la suite. En rendant de nombreux services groupés clés disponibles dans le service App Engine de 2e génération, les développeurs peuvent désormais porter leurs applications vers les derniers environnements d'exécution tout en continuant à utiliser (la plupart) des services groupés. Cet atelier de programmation vous explique comment mettre à niveau un exemple d'application de Python 2 à 3 tout en conservant l'utilisation du service groupé Datastore (via la bibliothèque App Engine NDB). Comme nous le verrons dans ce tutoriel, l'utilisation de la plupart des services groupés ne nécessite qu'une mise à jour mineure du code, mais d'autres nécessitent des modifications plus importantes. ceux-ci seront abordés dans la « Partie 2 », un module complémentaire et un atelier de programmation.
Vous apprendrez à
- Exemple de port d'application App Engine Python 2 vers 3
- Mettre à jour la configuration de l'application pour inclure le SDK App Engine
- Ajouter le code SDK à l'application compatible avec les services groupés dans des environnements d'exécution de 2e génération tels que Python 3
Prérequis
- Un projet Google Cloud avec un compte de facturation GCP actif
- Des connaissances de base en Python
- Une connaissance correcte des commandes Linux courantes
- Connaissances de base sur le développement et le déploiement d'applications App Engine
- Une application App Engine opérationnelle du module 1 (suivez son atelier de programmation [recommandé] ou copiez l'application à partir du dépôt)
Enquête
Comment allez-vous utiliser ce tutoriel ?
Quel est votre niveau d'expérience avec Python ?
Quel est votre niveau d'expérience avec les services Google Cloud ?
<ph type="x-smartling-placeholder">2. Contexte
Lancé en 2008, le service App Engine d'origine est fourni avec un ensemble d'anciennes API (désormais appelées services groupés) afin de permettre aux développeurs de créer et de déployer facilement des applications à l'échelle mondiale. Ces services incluent Datastore, Memcache et Task Queue. Bien que pratiques, les utilisateurs se sont inquiétés de la portabilité de leurs applications lorsqu'ils utilisaient des API propriétaires qui les liaient à App Engine. Ils souhaitaient que leurs applications soient plus portables. Cette nouveauté, associée au fait que bon nombre de ces services groupés, qui arrivent bientôt à devenir leurs propres produits cloud autonomes, ont conduit l'équipe App Engine à lancer la plate-forme nouvelle génération en 2018 sans ces services.
Aujourd'hui, nous avons des développeurs Python 2 souhaitant passer à Python 3. Une application 2.x utilisant des services groupés nécessitait une migration de ces services avant que ses applications ne puissent être transférées vers 3.x, ce qui représente une paire de migrations forcées dos à dos, qui peuvent aussi poser problème. Pour faciliter cette transition, l'équipe App Engine a lancé à l'automne 2021 un "trou de ver". permettant aux applications exécutées sur des environnements d'exécution de nouvelle génération d'accéder à bon nombre de ces services groupés. Bien que cette version n'inclue pas tous les services disponibles dans les environnements d'exécution d'origine, des acteurs majeurs tels que Datastore, Task Queue et Memcache sont disponibles.
Cet atelier de programmation présente les modifications nécessaires pour mettre à niveau votre application vers Python 3 tout en conservant l'utilisation des services groupés. L'objectif est d'exécuter vos applications sur les derniers environnements d'exécution, afin de vous permettre de migrer des services groupés vers des solutions cloud autonomes équivalentes ou des alternatives tierces selon votre propre calendrier, au lieu de bloquer la mise à niveau vers la version 3.x. L'abandon des services groupés n'est plus obligatoire, mais cela vous offre plus de portabilité et de flexibilité concernant l'emplacement d'hébergement de vos applications, par exemple en passant à des plates-formes qui peuvent mieux servir vos charges de travail, ou simplement en restant sur App Engine tout en passant à une version plus récente d'un langage plus récent, comme nous venons de le voir.
L'exemple d'application Python 2 du module 1 utilise le service groupé Datastore via App Engine NDB. L'application a déjà migré les frameworks de webapp2 vers Flask, comme terminé dans l'atelier de programmation du module 1, mais l'utilisation de Datastore n'a pas changé.
Ce tutoriel comprend les étapes suivantes:
- Configuration/Préparation
- Mettre à jour la configuration
- Modifier le code d'application
3. Configuration/Préparation
Cette section explique comment effectuer les opérations suivantes :
- Configurer votre projet Cloud
- Obtenir un exemple d'application de référence
- (Re)Déployer et valider l'application de référence
Ces étapes permettent de s'assurer que vous commencez avec du code fonctionnel.
1. Configurer le projet
Si vous avez terminé l'atelier de programmation du module 1, nous vous recommandons de réutiliser le même projet (et le même code). Vous pouvez également créer un projet Cloud ou réutiliser un autre projet existant. Assurez-vous que le projet dispose d'un compte de facturation actif sur lequel le service App Engine a été activé.
2. Obtenir un exemple d'application de référence
L'une des conditions préalables à cet atelier de programmation est de disposer d'une application App Engine opérationnelle du module 1: suivez l'atelier de programmation du module 1 (recommandé) ou copiez l'application du module 1 à partir du dépôt. Que vous utilisiez le vôtre ou le nôtre, c'est dans le code du module 1 que nous allons "COMMENCER". Cet atelier de programmation présente chaque étape, se terminant par un code semblable à celui du dossier du dépôt du module 7 "FINISH".
- DÉBUT: dossier du module 1 (Python 2)
- FINISH: dossier du module 1b (Python 3)
- Dépôt complet (pour cloner ou télécharger le fichier ZIP)
Quelle que soit l'application du module 1 que vous utilisez, le dossier doit se présenter comme suit, éventuellement avec un dossier lib
:
$ ls README.md appengine_config.py requirements.txt app.yaml main.py templates
3. (Re)Déployer l'application de référence
Exécutez les étapes suivantes pour (re)déployer l'application du module 1:
- Supprimez le dossier
lib
s'il y en a un, puis exécutezpip install -t lib -r requirements.txt
pour remplir à nouveaulib
. Si Python 2 et 3 sont installés, vous devrez peut-être utiliser la commandepip2
à la place. - Assurez-vous d'avoir installé et initialisé l'outil de ligne de commande
gcloud
, et vérifié son utilisation. - Définissez votre projet Cloud avec
gcloud config set project
PROJECT_ID
si vous ne souhaitez pas saisir votrePROJECT_ID
avec chaque commandegcloud
émise. - Déployer l'exemple d'application avec
gcloud app deploy
- Vérifier que l'application du module 1 fonctionne comme prévu sans que les visites les plus récentes ne s'affichent (voir ci-dessous)
4. Mettre à jour la configuration
Une fois que vous avez exécuté ces étapes et constaté que votre application Web fonctionne, vous êtes prêt à transférer cette application vers Python 3, en commençant par la configuration.
Ajouter le SDK au fichier requirements.txt
L'environnement d'exécution Python 3 d'App Engine réduit considérablement les frais généraux liés à l'utilisation de bibliothèques tierces. Il vous suffit de les répertorier dans requirements.txt
. Pour utiliser les services groupés dans Python 3, ajoutez le package du SDK App Engine, appengine-python-standard
. Le package SDK rejoint Flask du module 1:
flask
appengine-python-standard
Mettre à jour le fichier app.yaml
Suivez les étapes ci-dessous pour appliquer les modifications de configuration à votre fichier app.yaml
:
- Remplacez la directive
runtime
par la version Python 3 compatible. Par exemple, spécifiezpython310
pour Python 3.10. - Supprimez les instructions
threadsafe
etapi_version
, car elles ne sont pas utilisées dans Python 3. - Supprimez complètement la section
handlers
, car cette application ne comporte que des gestionnaires de script. Si votre application dispose de gestionnaires de fichiers statiques, ne les modifiez pas danshandlers
. - Contrairement à Python 2, l'environnement d'exécution Python 3 n'accepte pas les bibliothèques tierces intégrées. Si votre application comporte une section
libraries
dansapp.yaml
, supprimez l'intégralité de la section. (Les packages requis ne doivent être listés que dansrequirements.txt
, comme les bibliothèques non intégrées.) Notre application exemple ne comporte pas de sectionlibraries
. Passez donc à l'étape suivante. - Créez une directive
app_engine_apis
définie surtrue
pour l'utiliser. Cela revient à ajouter le package SDK App Engine àrequirements.txt
ci-dessus.
Résumé des modifications à apporter à app.yaml
:
AVANT:
runtime: python27
threadsafe: yes
api_version: 1
handlers:
- url: /.*
script: main.app
APRÈS:
runtime: python310
app_engine_apis: true
Autres fichiers de configuration
Étant donné que tous les packages tiers ne doivent être listés que dans requirements.txt
, il n'est pas nécessaire de les supprimer, sauf si vous avez quelque chose de spécial dans appengine_config.py
. De même, étant donné que toutes les bibliothèques tierces sont automatiquement installées lors du processus de compilation, il n'est pas nécessaire de les copier ni de les fournisseurs. Vous n'avez donc plus besoin de commande pip install
ni de dossier lib
. Vous devez donc les supprimer. Résumé:
- Supprimer le fichier
appengine_config.py
- Supprimer
lib
dossier
Toutes les modifications de configuration nécessaires sont ainsi terminées.
5. Modifier le code d'application
Pour accéder à la majorité des services groupés disponibles dans l'environnement d'exécution Python 3, il faut un court extrait de code encapsulant l'objet d'application Web Server Gateway Interface (vTPM) dans main.py
. La fonction wrapper est google.appengine.api.wrap_wsgi_app()
. Pour l'utiliser, importez-la et encapsulez votre objet WSGI avec elle. Apportez les modifications ci-dessous pour refléter la mise à jour requise pour Flask dans main.py
:
AVANT:
from flask import Flask, render_template, request
from google.appengine.ext import ndb
app = Flask(__name__)
APRÈS:
from flask import Flask, render_template, request
from google.appengine.api import wrap_wsgi_app
from google.appengine.ext import ndb
app = Flask(__name__)
app.wsgi_app = wrap_wsgi_app(app.wsgi_app)
Consultez la documentation pour obtenir des exemples d'encapsulation WSGI pour d'autres frameworks Python.
Bien que cet exemple permette d'autoriser votre application à accéder à la plupart des services groupés dans Python 3, d'autres, tels que Blobstore et Mail, nécessitent du code supplémentaire. Nous aborderons ces exemples dans un autre module de migration.
Toutes les modifications nécessaires pour ajouter l'utilisation des services groupés App Engine à l'application exemple du module 1 sont désormais terminées. L'application est déjà compatible avec Python 2 et 3. Il n'y a donc aucune modification supplémentaire à apporter pour le portage vers Python 3, en dehors de ce que vous avez déjà fait dans la configuration. La dernière étape consiste à déployer cette application modifiée dans l'environnement d'exécution App Engine Python 3 de nouvelle génération et à vérifier que les mises à jour ont bien été effectuées.
6. Résumé/Nettoyage
Cette section conclut cet atelier de programmation en déployant l'application, en vérifiant qu'elle fonctionne comme prévu et dans tout résultat réfléchi. Après la validation de l'application, effectuez un nettoyage et réfléchissez aux prochaines étapes.
Déployer et vérifier l'application
Déployez l'application Python 3 avec gcloud app deploy
et vérifiez qu'elle fonctionne comme dans Python 2. Aucune des fonctionnalités ne change. La sortie doit donc être identique à celle de l'application du module 1:
Remarques finales
- Comparez ce que vous avez avec le contenu du dossier du module 1b (FINISH). Si vous avez fait une erreur en cours de route et apportez les modifications nécessaires,
- Comparez le
main.py
du module 0 et lemain.py
du module 1b sur cette page si votre application utilise toujourswebapp2
, puis suivez l'atelier de programmation du module 1 pour découvrir comment passer dewebapp2
à Flask.
Nous vous félicitons d'avoir effectué la première étape du portage de vos applications App Engine Python 2 vers Python 3 tout en continuant à utiliser les services groupés.
Effectuer un nettoyage
Général
Si vous avez terminé, nous vous recommandons de désactiver votre application App Engine afin d'éviter que des frais ne vous soient facturés. Toutefois, si vous souhaitez effectuer d'autres tests, la plate-forme App Engine dispose d'un quota sans frais. Tant que vous ne dépassez pas ce niveau d'utilisation, aucuns frais ne vous seront facturés. Cela concerne le calcul, mais des frais peuvent également s'appliquer pour les services App Engine concernés. Pour en savoir plus, consultez sa page des tarifs. Si cette migration implique d'autres services cloud, ceux-ci sont facturés séparément. Dans les deux cas, le cas échéant, consultez la section "Informations spécifiques à cet atelier de programmation" ci-dessous.
Afin d'informer l'ensemble des utilisateurs, le déploiement sur une plate-forme de calcul sans serveur Google Cloud comme App Engine entraîne des coûts minimes de compilation et de stockage. Cloud Build et Cloud Storage disposent de leur propre quota sans frais. Le stockage de cette image utilise une partie de ce quota. Cependant, vous pouvez résider dans une région qui n'offre pas ce type de version sans frais. Vous devez donc surveiller l'utilisation de votre espace de stockage afin de réduire les coûts potentiels. "Dossiers" Cloud Storage spécifiques vous devez examiner:
console.cloud.google.com/storage/browser/LOC.artifacts.PROJECT_ID.appspot.com/containers/images
console.cloud.google.com/storage/browser/staging.PROJECT_ID.appspot.com
- Les liens de stockage ci-dessus dépendent de votre
PROJECT_ID
et de votre *LOC
*ation (par exemple, "us
") si votre application est hébergée aux États-Unis.
En revanche, si vous ne comptez pas utiliser cette application ou d'autres ateliers de programmation liés à la migration, et que vous souhaitez tout supprimer complètement, arrêtez votre projet.
Spécifique à cet atelier de programmation
Les services listés ci-dessous sont propres à cet atelier de programmation. Pour en savoir plus, consultez la documentation de chaque produit:
- Le service App Engine Datastore est fourni par Cloud Datastore (Cloud Firestore en mode Datastore), également disponible avec une version sans frais. consultez la page des tarifs pour en savoir plus.
Étapes suivantes
Il y a plusieurs façons d'y accéder:
- Mettre à jour le code à l'aide de services groupés nécessitant davantage de modifications du code
- Effectuer une migration à partir de services groupés vers des produits Cloud autonomes
- Migrer d'App Engine vers une autre plate-forme sans serveur cloud
L'accès à d'autres services groupés tels que Blobstore, Mail et Deferred nécessite d'autres modifications de code. Voici quelques modules de migration axés sur l'abandon des anciens services groupés App Engine:
- Module 2: App Engine NDB vers Cloud NDB
- Modules 7 à 9: TaskQueue (tâches d'envoi) App Engine dans Cloud Tasks
- Modules 12 à 13: Memcache d'App Engine vers Cloud Memorystore
- Modules 15 à 16: Pipeline App Engine vers Cloud Storage
- Modules 18 à 19: TaskQueue (tâches d'extraction) App Engine vers Cloud Pub/Sub
App Engine n'est plus la seule plate-forme sans serveur de Google Cloud. Si vous disposez d'une petite application App Engine ou d'une application aux fonctionnalités limitées et que vous souhaitez la transformer en microservice autonome, ou si vous voulez diviser une application monolithique en plusieurs composants réutilisables, nous vous recommandons de passer à Cloud Functions. Si la conteneurisation fait désormais partie de votre workflow de développement d'applications, en particulier si elle consiste en un pipeline CI/CD (intégration continue/livraison continue ou déploiement), envisagez de migrer vers Cloud Run. Ces scénarios sont abordés dans les modules suivants:
- Effectuer une migration d'App Engine vers Cloud Functions: consultez le Module 11
- Migrer d'App Engine vers Cloud Run: consultez le module 4 pour conteneuriser votre application avec Docker, ou le module 5 pour effectuer cette opération sans conteneur, ni connaissance de Docker ou
Dockerfile
.
Le passage à une autre plate-forme sans serveur est facultatif. Nous vous recommandons de réfléchir aux meilleures options pour vos applications et cas d'utilisation avant d'apporter des modifications.
Quel que soit le module de migration que vous envisagez ensuite, tout le contenu de la station de migration sans serveur (ateliers de programmation, vidéos, code source [si disponible]) est accessible dans son dépôt Open Source. Le fichier README
du dépôt fournit également des indications sur les migrations à prendre en compte et sur l'ordre d'exécution approprié. des modules de migration.
7. Ressources supplémentaires
Vous trouverez ci-dessous des ressources supplémentaires destinées aux développeurs qui étudient plus en détail ce module de migration ou le module de migration associé, ainsi que les produits associés. Vous y trouverez, par exemple, des emplacements où vous pouvez envoyer des commentaires sur ce contenu, des liens vers le code et diverses documents susceptibles de vous être utiles.
Commentaires et problèmes concernant les ateliers de programmation
Si vous rencontrez des problèmes avec cet atelier de programmation, commencez par faire une recherche avant de les signaler. Liens vers la recherche et la création d'un signalement :
Ressources de migration
Le tableau ci-dessous contient des liens vers les dossiers de dépôt des modules 1 (START) et 1b (FINISH). Ils sont également accessibles à partir du dépôt pour toutes les migrations d'ateliers de programmation App Engine.
Atelier de programmation | Python 2 | Python 3 |
N/A | ||
Module 17 (cet atelier de programmation) | N/A | code (mod1b-flask) |
Ressources en ligne
Vous trouverez ci-dessous des ressources en ligne qui peuvent vous être utiles pour ce tutoriel:
Services groupés App Engine
- Accéder aux services groupés dans l'environnement d'exécution nouvelle génération Python 3
- Comparaison entre l'application du module 0 (Python 2) et l'application du module 1b (Python 3)
- Exemples de wrappers d'objets WSGI du framework Web du SDK App Engine
- Lancement de la compatibilité avec les services groupés App Engine dans les environnements d'exécution nouvelle génération (2021)
Documentation générale sur App Engine
- Documentation App Engine
- Environnement d'exécution App Engine (environnement standard) Python 2
- Utiliser les bibliothèques intégrées d'App Engine dans la version Python 2 d'App Engine
- Environnement d'exécution App Engine (environnement standard) Python 3
- Différences entre Python 2 et Trois environnements d'exécution App Engine (environnement standard)
- Guide de migration App Engine (environnement standard) pour Python 2 vers 3
- Informations sur les tarifs et les quotas d'App Engine
- Lancement de la plate-forme App Engine de deuxième génération (2018)
- Compatibilité à long terme avec les anciens environnements d'exécution
- Dépôt d'exemples de migration de la documentation
- Dépôt d'exemples de migration provenant de la communauté
Autres informations sur le cloud
- Python sur Google Cloud Platform
- Bibliothèques clientes Google Cloud Python
- "Toujours sans frais" de Google Cloud niveau
- SDK Google Cloud (outil de ligne de commande
gcloud
) - Toute la documentation Google Cloud
Vidéos
- Station de migration sans serveur
- Expéditions sans serveur
- S'abonner à Google Cloud Tech
- S'abonner à Google Developers
Licence
Ce document est publié sous une licence Creative Commons Attribution 2.0 Generic.