Étendre la compatibilité avec les services groupés App Engine: partie 1 (module 17)

1. Présentation

La série d'ateliers de programmation Serverless Migration Station (tutoriels pratiques à suivre à votre rythme) et les vidéos associées sont destinées à aider les développeurs Google Cloud sans serveur à moderniser leurs applications en les guidant tout au long d'une ou plusieurs migrations, principalement en les aidant à abandonner les anciens services. Cela rend vos applications plus portables et vous offre plus d'options et de flexibilité, ce qui vous permet de vous intégrer à une plus large gamme de produits Cloud et d'y accéder, et de passer plus facilement aux versions linguistiques plus récentes. Bien qu'elle se concentre initialement sur les premiers utilisateurs de Cloud, principalement les développeurs App Engine (environnement standard), cette série est suffisamment large pour inclure d'autres plates-formes sans serveur comme Cloud Functions et Cloud Run, ou ailleurs si nécessaire.

Auparavant, les développeurs devaient migrer depuis les "services groupés" hérités d'App Engine, comme Datastore et Memcache, avant de pouvoir mettre à niveau les versions linguistiques. Il s'agissait de deux tâches potentiellement difficiles à effectuer l'une après l'autre. En rendant de nombreux services groupés clés disponibles dans le service App Engine de deuxième génération, les développeurs peuvent désormais migrer 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 à Python 3 tout en continuant à utiliser le service groupé Datastore (via la bibliothèque App Engine NDB). L'utilisation de la plupart des services groupés ne nécessite qu'une mise à jour mineure du code, comme nous le verrons dans ce tutoriel. Toutefois, d'autres services nécessitent des modifications plus importantes. Nous les aborderons dans la partie 2, un module et un atelier de programmation de suivi.

Vous apprendrez à

  • Transférer un exemple d'application App Engine de Python 2 vers Python 3
  • Mettre à jour la configuration de l'application pour inclure le SDK App Engine
  • Ajoutez du code SDK à l'application compatible avec les services groupés dans les environnements d'exécution de deuxième génération, comme Python 3.

Prérequis

Enquête

Comment allez-vous utiliser ce tutoriel ?

Je vais le lire uniquement Je vais le lire et effectuer les exercices

Quel est votre niveau d'expérience avec Python ?

Débutant Intermédiaire Expert

Quel est votre niveau d'expérience avec les services Google Cloud ?

Débutant Intermédiaire Expert

2. Arrière-plan

Le service App Engine d'origine a été lancé en 2008 et était fourni avec un ensemble d'anciennes API (désormais appelées services groupés) pour 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 les liant à App Engine et souhaitaient que leurs applications soient plus portables. De plus, de nombreux services groupés sont devenus des produits Cloud autonomes. L'équipe App Engine a donc lancé la plate-forme de nouvelle génération en 2018 sans eux.

Aujourd'hui, les développeurs Python 2 sont impatients de passer à Python 3. Une application 2.x utilisant des services groupés devait migrer hors de ces services avant de pouvoir être portée vers la version 3.x, ce qui représentait deux migrations forcées consécutives, potentiellement difficiles. Pour faciliter cette transition, l'équipe App Engine a introduit à l'automne 2021 un "trou de ver" vers le passé, permettant aux applications exécutées sur des environnements d'exécution de nouvelle génération d'accéder à de nombreux services groupés. Bien que cette version n'inclue pas tous les services disponibles dans les environnements d'exécution d'origine, les principaux, tels que Datastore, Task Queue et Memcache, sont disponibles.

Cet atelier de programmation vous montre les modifications nécessaires pour mettre à niveau votre application vers Python 3 tout en conservant l'utilisation des services groupés. L'objectif est de faire fonctionner vos applications sur les derniers environnements d'exécution, ce qui vous permettra ensuite de migrer des services groupés vers des équivalents Cloud autonomes ou des alternatives tierces selon votre propre calendrier, plutôt que de bloquer la mise à niveau vers la version 3.x. Bien qu'il ne soit plus nécessaire de migrer depuis les services groupés, cela vous offre plus de portabilité et de flexibilité en termes d'hébergement de vos applications. Vous pouvez ainsi passer à des plates-formes plus adaptées à vos charges de travail ou simplement rester sur App Engine tout en passant à une version plus récente du langage, comme décrit ci-dessus.

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 (opération effectuée dans l'atelier de programmation du module 1), mais son utilisation de Datastore est restée intacte.

Ce tutoriel comprend les étapes suivantes :

  1. Configuration/Préparation
  2. Mettre à jour la configuration
  3. Modifier le code de l'application

3. Configuration/Préparation

Cette section explique comment effectuer les opérations suivantes :

  1. Configurer votre projet Cloud
  2. Obtenir un exemple d'application de référence
  3. (Re)Déployer et valider l'application de référence

Ces étapes vous permettent de commencer avec un 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 fonctionnelle du module 1. Pour cela, suivez l'atelier de programmation du module 1 (recommandé) ou copiez l'application du module 1 depuis le dépôt. Que vous utilisiez votre application ou la nôtre, le code de départ ("START") est celui du module 1. Cet atelier de programmation vous guide pour chaque étape jusqu'à obtenir un code similaire à celui du dossier "FINISH" du dépôt du module 7.

Quelle que soit l'application du module 1 que vous utilisez, le dossier doit ressembler à ce qui suit, avec éventuellement 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

Pour (re)déployer l'application du module 1, procédez comme suit :

  1. Supprimez le dossier lib s'il existe, puis exécutez pip install -t lib -r requirements.txt pour le remplir à nouveau.lib Si vous avez installé Python 2 et Python 3, vous devrez peut-être utiliser la commande pip2.
  2. Assurez-vous d'avoir installé et initialisé l'outil de ligne de commande gcloud, et d'avoir consulté son utilisation.
  3. Définissez votre projet Cloud avec gcloud config set project PROJECT_ID si vous ne souhaitez pas saisir votre PROJECT_ID à chaque commande gcloud émise.
  4. Déployez l'exemple d'application avec gcloud app deploy
  5. Vérifiez que l'application du module 1 s'exécute comme prévu, sans problème, et qu'elle affiche les visites les plus récentes (comme illustré ci-dessous).

a7a9d2b80d706a2b.png

4. Mettre à jour la configuration

Une fois ces étapes effectuées et que vous avez vérifié que votre application Web fonctionne, vous êtes prêt à la migrer vers Python 3, en commençant par la configuration.

Ajouter le SDK à requirements.txt

L'environnement d'exécution App Engine Python 3 réduit considérablement la surcharge liée à l'utilisation de bibliothèques tierces. Il vous suffit de les lister dans requirements.txt. Pour utiliser les services groupés dans Python 3, ajoutez-y le package SDK App Engine, appengine-python-standard. Le package SDK rejoint Flask à partir 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 :

  1. Remplacez la directive runtime par la version Python 3 compatible. Par exemple, spécifiez python310 pour Python 3.10.
  2. Supprimez les directives threadsafe et api_version, car aucune d'elles n'est utilisée dans Python 3.
  3. Supprimez entièrement la section handlers, car cette application ne comporte que des gestionnaires de script. Si votre application comporte des gestionnaires de fichiers statiques, laissez-les intacts dans handlers.
  4. Contrairement à l'environnement d'exécution Python 2, l'environnement d'exécution Python 3 n'est pas compatible avec les bibliothèques tierces intégrées. Si votre application comporte une section libraries dans app.yaml, supprimez-la entièrement. (Il suffit de répertorier les packages requis dans requirements.txt comme les bibliothèques non intégrées.) Notre exemple d'application ne comporte pas de section libraries. Passez donc à l'étape suivante.
  5. Créez une directive app_engine_apis définie sur true pour l'utiliser. Cela correspond à l'ajout du 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 n'ont besoin d'être listés que dans requirements.txt, sauf si vous avez quelque chose de spécial dans appengine_config.py, il n'est pas nécessaire, alors supprimez-le. 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 fournir. Cela signifie qu'il n'y a plus de commande pip install ni de dossier lib. Vous pouvez donc le supprimer. Résumer :

  • Supprimer le fichier appengine_config.py
  • Supprimer le dossier lib

Vous avez terminé d'apporter les modifications de configuration nécessaires.

5. Modifier le code de l'application

Pour accéder à la majorité des services groupés disponibles dans l'environnement d'exécution Python 3, vous devez ajouter un court extrait de code qui encapsule l'objet d'application Web Server Gateway Interface (WSGI) dans main.py. La fonction wrapper est google.appengine.api.wrap_wsgi_app(). Pour l'utiliser, importez-la et encapsulez votre objet WSGI avec. 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 à votre application d'accéder à la plupart des services groupés dans Python 3, d'autres, comme Blobstore et Mail, nécessitent du code supplémentaire. Nous aborderons ces exemples dans un autre module sur la migration.

Vous avez terminé d'apporter toutes les modifications nécessaires pour ajouter l'utilisation des services groupés App Engine à l'exemple d'application du module 1. L'application est déjà compatible avec Python 2 et 3. Il n'y a donc pas d'autres modifications à apporter pour la porter vers Python 3, à part celles que vous avez déjà effectuées dans la configuration. La dernière étape consiste à déployer cette application modifiée dans l'environnement d'exécution Python 3 App Engine de nouvelle génération et à vérifier que les modifications ont bien été appliquées.

6. Résumé/Nettoyage

Cette section conclut cet atelier de programmation en déployant l'application et en vérifiant qu'elle fonctionne comme prévu et dans toutes les sorties reflétées. Après la validation de l'application, effectuez tout nettoyage nécessaire 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 fonctionnalité n'a été modifiée. La sortie doit donc être identique à celle de l'application du module 1 :

a7a9d2b80d706a2b.png

Remarques finales

Félicitations pour avoir fait le premier pas vers le portage de vos applications Python 2 App Engine vers Python 3 tout en conservant leur utilisation des services groupés pour le moment.

Effectuer un nettoyage

Général

Si vous avez terminé pour le moment, nous vous recommandons de désactiver votre application App Engine pour éviter d'être facturé. Toutefois, si vous souhaitez effectuer d'autres tests ou expériences, la plate-forme App Engine dispose d'un quota sans frais. Tant que vous ne dépassez pas ce niveau d'utilisation, aucun frais ne devrait vous être facturé. Cela concerne le calcul, mais des frais peuvent également s'appliquer aux services App Engine concernés. Pour en savoir plus, consultez la page de tarification. 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 "Spécifique à cet atelier de programmation" ci-dessous.

Pour être tout à fait transparent, le déploiement sur une plate-forme de calcul sans serveur Google Cloud comme App Engine entraîne de légers coûts de compilation et de stockage. Cloud Build et Cloud Storage disposent chacun de leur propre quota sans frais. Le stockage de cette image utilise une partie de ce quota. Toutefois, il est possible que vous résidiez dans une région où ce niveau sans frais n'est pas disponible. Veillez donc à surveiller votre utilisation de l'espace de stockage pour minimiser les coûts potentiels. Voici quelques "dossiers" Cloud Storage spécifiques que 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 souhaitez pas poursuivre avec cette application ni avec d'autres ateliers de programmation de migration associés 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 :

Étapes suivantes

Vous pouvez ensuite procéder de plusieurs façons :

  1. Mettre à jour le code à l'aide de services groupés nécessitant davantage de modifications de code
  2. Migrer des services groupés vers des produits Cloud autonomes
  3. Migrer depuis App Engine vers une autre plate-forme Cloud sans serveur

L'accès à d'autres services groupés tels que Blobstore, Mail et Deferred nécessite davantage de modifications du code. Voici quelques modules de migration à prendre en compte pour abandonner les anciens services groupés App Engine :

  • Module 2 : Migrer d'App Engine NDB vers Cloud NDB
  • Modules 7 à 9 : migration d'App Engine TaskQueue (tâches push) vers Cloud Tasks
  • Modules 12 et 13 : migration de Memcache d'App Engine vers Cloud Memorystore
  • Modules 15 et 16 : Migrer le Blobstore App Engine vers Cloud Storage
  • Modules 18 et 19 : files d'attente de tâches App Engine (tâches d'extraction) vers Cloud Pub/Sub

App Engine n'est plus la seule plate-forme sans serveur de Google Cloud. Si vous avez une petite application App Engine ou une application dont les fonctionnalités sont limitées et que vous souhaitez la transformer en microservice autonome, ou si vous souhaitez diviser une application monolithique en plusieurs composants réutilisables, ce sont de bonnes raisons d'envisager de passer à Cloud Functions. Si la conteneurisation fait désormais partie de votre workflow de développement d'applications, en particulier s'il s'agit d'un pipeline CI/CD (intégration continue/livraison ou déploiement continus), envisagez de migrer vers Cloud Run. Ces scénarios sont couverts par les modules suivants :

  • Migrer 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 le faire sans conteneurs, sans connaissances sur Docker ni Dockerfile.

Le passage à une autre plate-forme serverless est facultatif. Nous vous recommandons d'examiner les meilleures options pour vos applications et vos cas d'utilisation avant d'apporter des modifications.

Quel que soit le module de migration que vous envisagez ensuite, vous pouvez accéder à l'ensemble du contenu Serverless Migration Station (ateliers de programmation, vidéos, code source [le cas échéant]) dans son dépôt Open Source. Le README du dépôt fournit également des conseils sur les migrations à envisager et sur l'"ordre" pertinent des modules de migration.

7. Ressources supplémentaires

Vous trouverez ci-dessous des ressources supplémentaires pour les développeurs qui souhaitent en savoir plus sur ce module de migration ou sur des modules et produits associés. Vous y trouverez des liens vers le code, des informations sur la façon de nous faire part de vos commentaires sur ce contenu et divers éléments de documentation qui pourraient vous être utiles.

Problèmes/commentaires concernant l'atelier 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

Vous trouverez des liens vers les dossiers des dépôts du module 1 (code de départ "START") et du module 1b (code final "FINISH") dans le tableau ci-dessous. Vous pouvez également y accéder depuis le dépôt pour toutes les migrations d'ateliers de programmation App Engine.

Atelier de programmation

Python 2

Python 3

Module 1

code

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 être utiles pour ce tutoriel :

Services groupés App Engine

Documentation générale d'App Engine

Informations sur les autres clouds

Vidéos

Licence

Ce document est publié sous une licence Creative Commons Attribution 2.0 Generic.