Migrer une bibliothèque Python 2 App Engine Cloud NDB Application Cloud Tasks pour Python 3 et Cloud Datastore (module 9)

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.

L'objectif de cet atelier de programmation est de porter l'exemple d'application du module 8 vers Python 3, de passer de l'utilisation de Cloud NDB à la bibliothèque cliente native Cloud Datastore pour accéder à Datastore (Cloud Firestore en mode Datastore), et de passer à la dernière version de la bibliothèque cliente Cloud Tasks.

Nous avons ajouté l'utilisation de Task Queue pour les tâches push dans le module 7, puis nous avons migré cette utilisation vers Cloud Tasks dans le module 8. Dans le module 9, nous continuons avec Python 3 et Cloud Datastore. Les utilisateurs de Task Queues pour les tâches de retrait migreront vers Cloud Pub/Sub et devront se reporter aux modules 18 et 19.

Vous apprendrez à

  • Portez l'exemple d'application du module 8 vers Python 3.
  • Passez de Cloud NDB aux bibliothèques clientes Cloud Datastore pour accéder à Datastore.
  • Passer à la dernière version de la bibliothèque cliente Cloud Tasks

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 module 7 montre comment utiliser les tâches d'envoi de la file d'attente des tâches App Engine dans les applications Python 2 Flask App Engine. Dans le Module 8, vous migrerez cette application de Task Queue vers Cloud Tasks. Dans le module 9, vous poursuivrez ce parcours et porterez cette application vers Python 3. Vous passerez également de l'accès à Datastore à l'aide de Cloud NDB à la bibliothèque cliente Cloud Datastore native.

Cloud NDB fonctionnant à la fois pour Python 2 et Python 3, il suffit aux utilisateurs d'App Engine qui transfèrent leurs applications de Python 2 vers Python 3. La migration supplémentaire des bibliothèques clientes vers Cloud Datastore est entièrement facultative. Il n'y a qu'une seule raison de l'envisager : vous avez des applications non-App Engine (et/ou des applications Python 3 App Engine) qui utilisent déjà la bibliothèque cliente Cloud Datastore et vous souhaitez consolider votre code pour accéder à Datastore avec une seule bibliothèque cliente. Cloud NDB a été créé spécifiquement pour les développeurs Python 2 App Engine en tant qu'outil de migration Python 3. Par conséquent, si vous n'avez pas encore de code utilisant la bibliothèque cliente Cloud Datastore, vous n'avez pas besoin d'envisager cette migration.

Enfin, le développement de la bibliothèque cliente Cloud Tasks ne se poursuit que dans Python 3. Nous migrons donc de l'une des dernières versions de Python 2 vers sa version Python 3 contemporaine. Heureusement, aucune modification incompatible n'a été apportée à Python 2. Vous n'avez donc rien d'autre à faire.

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 et de vous assurer qu'il est prêt à être migré vers les services cloud.

1. Configurer le projet

Si vous avez terminé l'atelier de programmation du module 8, réutilisez le même projet (et le même code). Vous pouvez également créer un projet ou réutiliser un autre projet existant. Assurez-vous que le projet dispose d'un compte de facturation actif et d'une application App Engine activée. Trouvez l'ID de votre projet, car vous en aurez besoin pendant cet atelier de programmation. Utilisez-le chaque fois que vous rencontrez la variable PROJECT_ID.

2. Obtenir un exemple d'application de référence

L'une des conditions préalables est de disposer d'une application App Engine fonctionnelle du module 8. Pour cela, suivez l'atelier de programmation du module 8 (recommandé) ou copiez l'application du module 8 depuis le dépôt. Que vous utilisiez votre code ou le nôtre, le code de départ ("START") est celui du module 8. Cet atelier de programmation vous guide tout au long de la migration jusqu'à obtenir un code similaire à celui du dossier du dépôt du module 9 ("FINISH").

Quelle que soit l'application du module 7 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 et valider l'application de référence

Pour déployer l'application du module 8, procédez comme suit :

  1. Supprimez le dossier lib, le cas échéant, puis exécutez pip install -t lib -r requirements.txt pour le remplir à nouveau.lib Si Python 2 et Python 3 sont tous les deux installés sur votre machine de développement, vous devrez peut-être utiliser pip2 à la place.
  2. Assurez-vous d'avoir installé et initialisé l'outil de ligne de commande gcloud, et d'avoir consulté son utilisation.
  3. (Facultatif) Définissez votre projet Cloud avec gcloud config set project PROJECT_ID si vous ne souhaitez pas saisir PROJECT_ID à chaque commande gcloud que vous exécutez.
  4. Déployez l'exemple d'application avec gcloud app deploy
  5. Vérifiez que l'application s'exécute comme prévu et sans problème. Si vous avez terminé l'atelier de programmation du module 8, l'application affiche les visiteurs les plus fréquents ainsi que les visites les plus récentes (comme illustré ci-dessous). En bas de l'écran, les tâches les plus anciennes qui seront supprimées sont indiquées.

4aa8a2cb5f527079.png

4. Mettre à jour la configuration

requirements.txt

Le nouveau requirements.txt est presque identique à celui du module 8, à une exception près : remplacez google-cloud-ndb par google-cloud-datastore. Modifiez votre fichier requirements.txt pour qu'il se présente comme suit :

flask
google-cloud-datastore
google-cloud-tasks

Ce fichier requirements.txt ne comporte aucun numéro de version, ce qui signifie que les dernières versions sont sélectionnées. En cas d'incompatibilité, il est courant d'utiliser des numéros de version pour verrouiller les versions fonctionnelles d'une application.

app.yaml

L'environnement d'exécution App Engine de deuxième génération n'est pas compatible avec les bibliothèques tierces intégrées comme dans la version 2.x, ni avec la copie des bibliothèques non intégrées. La seule exigence concernant les packages tiers est de les répertorier dans requirements.txt. Par conséquent, l'intégralité de la section libraries de app.yaml peut être supprimée.

Autre nouveauté : l'environnement d'exécution Python 3 nécessite l'utilisation de frameworks Web qui effectuent leur propre routage. Par conséquent, tous les gestionnaires de scripts doivent être définis sur auto. Toutefois, comme toutes les routes doivent être remplacées par auto et qu'aucun fichier statique n'est diffusé à partir de cet exemple d'application, il n'est pas pertinent d'avoir des gestionnaires. Supprimez donc également l'intégralité de la section handlers.

La seule chose à faire dans app.yaml est de définir l'environnement d'exécution sur une version compatible de Python 3, par exemple 3.10. Apportez cette modification pour que le nouveau app.yaml abrégé ne contienne qu'une seule ligne :

runtime: python310

Supprimer les fichiers appengine_config.py et lib

Les environnements d'exécution App Engine de nouvelle génération remanient l'utilisation des packages tiers :

  • Les bibliothèques intégrées sont celles qui ont été vérifiées par Google et mises à disposition sur les serveurs App Engine, probablement parce qu'elles contiennent du code C/C++ que les développeurs ne sont pas autorisés à déployer dans le cloud. Elles ne sont plus disponibles dans les runtimes de deuxième génération.
  • Il n'est plus nécessaire de copier les bibliothèques non intégrées (parfois appelées "vendoring" ou "self-bundling") dans les environnements d'exécution de deuxième génération. Ils doivent plutôt être listés dans requirements.txt, où le système de compilation les installe automatiquement pour vous au moment du déploiement.

En raison de ces modifications apportées à la gestion des packages tiers, ni le fichier appengine_config.py ni le dossier lib ne sont nécessaires. Vous pouvez donc les supprimer. Dans les environnements d'exécution de deuxième génération, App Engine installe automatiquement les packages tiers listés dans requirements.txt. Résumer :

  1. Pas de bibliothèques tierces copiées ni groupées automatiquement ; répertoriez-les dans requirements.txt.
  2. Pas de pip install dans un dossier lib et pas de dossier lib.
  3. Pas de liste de bibliothèques tierces intégrées (donc pas de section libraries) dans app.yaml. Listez-les dans requirements.txt.
  4. Pas de bibliothèques tierces à référencer depuis votre application, donc pas de fichier appengine_config.py.

Il vous suffit de répertorier toutes les bibliothèques tierces souhaitées dans requirements.txt.

5. Mettre à jour les fichiers de l'application

Il n'y a qu'un fichier d'application, main.py. Par conséquent, toutes les modifications de la présente section s'appliquent uniquement à ce fichier. Vous trouverez ci-dessous une illustration des différences concernant les modifications globales à apporter pour refactoriser le code existant dans la nouvelle application. Les lecteurs ne sont pas censés lire le code ligne par ligne, car son objectif est simplement de donner un aperçu visuel de ce qui est requis dans cette refactorisation (mais n'hésitez pas à l'ouvrir dans un nouvel onglet ou à le télécharger et à faire un zoom avant si vous le souhaitez).

5d043768ba7be742.png

Mettre à jour les importations et l'initialisation

La section d'importation de main.py pour le module 8 utilise Cloud NDB et Cloud Tasks. Elle doit se présenter comme suit :

AVANT :

from datetime import datetime
import json
import logging
import time
from flask import Flask, render_template, request
import google.auth
from google.cloud import ndb, tasks

app = Flask(__name__)
ds_client = ndb.Client()
ts_client = tasks.CloudTasksClient()

La journalisation est simplifiée et améliorée dans les environnements d'exécution de deuxième génération, comme Python 3 :

  • Pour une expérience de journalisation complète, utilisez Cloud Logging.
  • Pour une journalisation simple, envoyez simplement à stdout (ou stderr) via print().
  • Il n'est pas nécessaire d'utiliser le module Python logging (supprimez-le).

Par conséquent, supprimez l'importation de logging et remplacez google.cloud.ndb par google.cloud.datastore. De même, remplacez ds_client pour qu'il pointe vers un client Datastore au lieu d'un client NDB. Une fois ces modifications apportées, le haut de votre nouvelle application se présente comme suit :

APRÈS :

from datetime import datetime
import json
import time
from flask import Flask, render_template, request
import google.auth
from google.cloud import datastore, tasks

app = Flask(__name__)
ds_client = datastore.Client()
ts_client = tasks.CloudTasksClient()

Migrer vers Cloud Datastore

Il est maintenant temps de remplacer l'utilisation de la bibliothèque cliente NDB par Datastore. App Engine NDB et Cloud NDB nécessitent un modèle de données (classe). Pour cette application, il s'agit de Visit. La fonction store_visit() fonctionne de la même manière dans tous les autres modules de migration : elle enregistre une visite en créant un enregistrement Visit, en enregistrant l'adresse IP et l'agent utilisateur (type de navigateur) d'un client visiteur.

AVANT :

class Visit(ndb.Model):
    'Visit entity registers visitor IP address & timestamp'
    visitor   = ndb.StringProperty()
    timestamp = ndb.DateTimeProperty(auto_now_add=True)

def store_visit(remote_addr, user_agent):
    'create new Visit entity in Datastore'
    with ds_client.context():
        Visit(visitor='{}: {}'.format(remote_addr, user_agent)).put()

Toutefois, Cloud Datastore n'utilise pas de classe de modèle de données. Supprimez donc la classe. De plus, Cloud Datastore ne crée pas automatiquement d'horodatage lorsque des enregistrements sont créés. Vous devez donc le faire manuellement à l'aide de l'appel datetime.now().

Sans la classe de données, votre store_visit() modifié devrait se présenter comme suit :

APRÈS :

def store_visit(remote_addr, user_agent):
    'create new Visit entity in Datastore'
    entity = datastore.Entity(key=ds_client.key('Visit'))
    entity.update({
        'timestamp': datetime.now(),
        'visitor': '{}: {}'.format(remote_addr, user_agent),
    })
    ds_client.put(entity)

La fonction clé est fetch_visits(). Non seulement elle exécute la requête d'origine pour les derniers Visit, mais elle récupère également le code temporel du dernier Visit affiché et crée la tâche push qui appelle /trim (donc trim()) pour supprimer en masse les anciens Visit. Voici comment procéder avec Cloud NDB :

AVANT :

def fetch_visits(limit):
    'get most recent visits & add task to delete older visits'
    with ds_client.context():
        data = Visit.query().order(-Visit.timestamp).fetch(limit)
    oldest = time.mktime(data[-1].timestamp.timetuple())
    oldest_str = time.ctime(oldest)
    logging.info('Delete entities older than %s' % oldest_str)
    task = {
        'app_engine_http_request': {
            'relative_uri': '/trim',
            'body': json.dumps({'oldest': oldest}).encode(),
            'headers': {
                'Content-Type': 'application/json',
            },
        }
    }
    ts_client.create_task(parent=QUEUE_PATH, task=task)
    return (v.to_dict() for v in data), oldest_str

Voici les principales modifications apportées :

  1. Remplacez la requête Cloud NDB par l'équivalent Cloud Datastore. Les styles de requête sont légèrement différents.
  2. Contrairement à Cloud NDB, Datastore ne nécessite pas l'utilisation d'un gestionnaire de contexte ni l'extraction de ses données (avec to_dict()).
  3. Remplacer les appels de journalisation par print()

Après ces modifications, fetch_visits() se présente comme suit :

APRÈS :

def fetch_visits(limit):
    'get most recent visits & add task to delete older visits'
    query = ds_client.query(kind='Visit')
    query.order = ['-timestamp']
    visits = list(query.fetch(limit=limit))
    oldest = time.mktime(visits[-1]['timestamp'].timetuple())
    oldest_str = time.ctime(oldest)
    print('Delete entities older than %s' % oldest_str)
    task = {
        'app_engine_http_request': {
            'relative_uri': '/trim',
            'body': json.dumps({'oldest': oldest}).encode(),
            'headers': {
                'Content-Type': 'application/json',
            },
        }
    }
    ts_client.create_task(parent=QUEUE_PATH, task=task)
    return visits, oldest_str

En général, cela suffit. Malheureusement, un problème majeur se pose.

(Éventuellement) Créer une file d'attente (d'envoi)

Dans le module 7, nous avons ajouté l'utilisation d'taskqueue App Engine à l'application existante du module 1. L'un des principaux avantages des tâches push en tant qu'ancienne fonctionnalité App Engine est qu'une file d'attente "par défaut" est créée automatiquement. Lorsque cette application a été migrée vers Cloud Tasks dans le module 8, cette file d'attente par défaut était déjà présente. Nous n'avions donc toujours pas besoin de nous en soucier à ce moment-là. Mais cela va changer dans le module 9.

Un aspect essentiel à prendre en compte est que la nouvelle application App Engine n'utilise plus les services App Engine. Par conséquent, vous ne pouvez plus supposer qu'App Engine crée automatiquement une file d'attente des tâches dans un autre produit (Cloud Tasks). Telle qu'elle est écrite, la création d'une tâche dans fetch_visits() (pour une file d'attente inexistante) échouera. Une nouvelle fonction est nécessaire pour vérifier si la file d'attente ("par défaut") existe et, dans le cas contraire, en créer une.

Appelez cette fonction _create_queue_if() et ajoutez-la à votre application juste au-dessus de fetch_visits(), car c'est là qu'elle est appelée. Corps de la fonction à ajouter :

def _create_queue_if():
    'app-internal function creating default queue if it does not exist'
    try:
        ts_client.get_queue(name=QUEUE_PATH)
    except Exception as e:
        if 'does not exist' in str(e):
            ts_client.create_queue(parent=PATH_PREFIX,
                    queue={'name': QUEUE_PATH})
    return True

La fonction Cloud Tasks create_queue() nécessite le chemin d'accès complet à la file d'attente, à l'exception du nom de la file d'attente. Pour plus de simplicité, créez une autre variable PATH_PREFIX représentant QUEUE_PATH moins le nom de la file d'attente (QUEUE_PATH.rsplit('/', 2)[0]). Ajoutez sa définition en haut de sorte que le bloc de code avec toutes les affectations de constantes ressemble à ceci :

_, PROJECT_ID = google.auth.default()
REGION_ID = 'REGION_ID'    # replace w/your own
QUEUE_NAME = 'default'     # replace w/your own
QUEUE_PATH = ts_client.queue_path(PROJECT_ID, REGION_ID, QUEUE_NAME)
PATH_PREFIX = QUEUE_PATH.rsplit('/', 2)[0]

Modifiez maintenant la dernière ligne de fetch_visits() pour utiliser _create_queue_if(), en créant d'abord la file d'attente si nécessaire, puis en créant la tâche :

    if _create_queue_if():
        ts_client.create_task(parent=QUEUE_PATH, task=task)
    return visits, oldest_str

_create_queue_if() et fetch_visits() devraient désormais se présenter comme suit :

def _create_queue_if():
    'app-internal function creating default queue if it does not exist'
    try:
        ts_client.get_queue(name=QUEUE_PATH)
    except Exception as e:
        if 'does not exist' in str(e):
            ts_client.create_queue(parent=PATH_PREFIX,
                    queue={'name': QUEUE_PATH})
    return True

def fetch_visits(limit):
    'get most recent visits & add task to delete older visits'
    query = ds_client.query(kind='Visit')
    query.order = ['-timestamp']
    visits = list(query.fetch(limit=limit))
    oldest = time.mktime(visits[-1]['timestamp'].timetuple())
    oldest_str = time.ctime(oldest)
    print('Delete entities older than %s' % oldest_str)
    task = {
        'app_engine_http_request': {
            'relative_uri': '/trim',
            'body': json.dumps({'oldest': oldest}).encode(),
            'headers': {
                'Content-Type': 'application/json',
            },
        }
    }
    if _create_queue_if():
        ts_client.create_task(parent=QUEUE_PATH, task=task)
    return visits, oldest_str

À part l'ajout de ce code supplémentaire, le reste du code Cloud Tasks est en grande partie intact par rapport au module 8. Le dernier élément de code à examiner est le gestionnaire de tâches.

Gestionnaire de tâches de mise à jour (push)

Dans le gestionnaire de tâches trim(), le code Cloud NDB interroge les visites plus anciennes que la plus ancienne affichée. Il utilise une requête ne renvoyant que des clés pour accélérer le processus. Pourquoi extraire toutes les données si vous n'avez besoin que des ID de visite ? Une fois que vous avez tous les ID de visite, supprimez-les tous par lot avec la fonction delete_multi() de Cloud NDB.

AVANT :

@app.route('/trim', methods=['POST'])
def trim():
    '(push) task queue handler to delete oldest visits'
    oldest = float(request.get_json().get('oldest'))
    with ds_client.context():
        keys = Visit.query(
                Visit.timestamp < datetime.fromtimestamp(oldest)
        ).fetch(keys_only=True)
        nkeys = len(keys)
        if nkeys:
            logging.info('Deleting %d entities: %s' % (
                    nkeys, ', '.join(str(k.id()) for k in keys)))
            ndb.delete_multi(keys)
        else:
            logging.info(
                    'No entities older than: %s' % time.ctime(oldest))
    return ''   # need to return SOME string w/200

Comme pour fetch_visits(), la plupart des modifications consistent à remplacer le code Cloud NDB par Cloud Datastore, à ajuster les styles de requête, à supprimer l'utilisation de son gestionnaire de contexte et à remplacer les appels de journalisation par print().

APRÈS :

@app.route('/trim', methods=['POST'])
def trim():
    '(push) task queue handler to delete oldest visits'
    oldest = float(request.get_json().get('oldest'))
    query = ds_client.query(kind='Visit')
    query.add_filter('timestamp', '<', datetime.fromtimestamp(oldest))
    query.keys_only()
    keys = list(visit.key for visit in query.fetch())
    nkeys = len(keys)
    if nkeys:
        print('Deleting %d entities: %s' % (
                nkeys, ', '.join(str(k.id) for k in keys)))
        ds_client.delete_multi(keys)
    else:
        print('No entities older than: %s' % time.ctime(oldest))
    return ''   # need to return SOME string w/200

Aucune modification n'a été apportée au gestionnaire d'application principal root().

Portage vers Python 3

Cette application exemple a été conçue pour s'exécuter sur Python 2 et Python 3. Les modifications spécifiques à Python 3 ont été abordées précédemment dans les sections concernées de ce tutoriel. Aucune étape supplémentaire ni bibliothèque de compatibilité ne sont requises.

Mise à jour de Cloud Tasks

La dernière version de la bibliothèque cliente Cloud Tasks compatible avec Python 2 est la version 1.5.0. Au moment de la rédaction de cet article, la dernière version de la bibliothèque cliente pour Python 3 est entièrement compatible avec cette version. Aucune autre mise à jour n'est donc requise.

Mise à jour du modèle HTML

Aucune modification n'est nécessaire dans le fichier de modèle HTML, templates/index.html. Nous avons donc terminé toutes les modifications nécessaires pour arriver à l'application du module 9.

6. Résumé/Nettoyage

Déployer et vérifier l'application

Une fois que vous avez terminé les mises à jour du code, principalement le portage vers Python 3, déployez votre application avec gcloud app deploy. Le résultat doit être identique à celui des applications des modules 7 et 8, sauf que vous avez déplacé l'accès à la base de données vers la bibliothèque cliente Cloud Datastore et que vous êtes passé à Python 3 :

Application Visitme du module 7

Cette étape termine l'atelier de programmation. Nous vous invitons à comparer votre code à celui du dossier du module 9. Félicitations !

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

La migration des tâches d'envoi de la file d'attente de tâches App Engine vers Cloud Tasks est terminée. La migration facultative de Cloud NDB vers Cloud Datastore est également abordée seule (sans Task Queue ni Cloud Tasks) dans le module 3. En plus du module 3, d'autres modules de migration se concentrent sur l'abandon des anciens services groupés App Engine. Voici quelques exemples :

  • Module 2 : migrer d'App Engine NDB vers Cloud NDB
  • Module 3 : migrer de Cloud NDB vers Cloud Datastore
  • Modules 12 et 13 : migrer d'App Engine Memcache vers Cloud Memorystore
  • Modules 15 et 16 : migrer d'App Engine Blobstore vers Cloud Storage
  • Modules 18 et 19 : file 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

Problèmes/commentaires 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 du dépôt pour les modules 8 (START) et 9 (FINISH). Vous pouvez également y accéder depuis le dépôt pour toutes les migrations d'ateliers de programmation App Engine que vous pouvez cloner ou télécharger sous forme de fichier ZIP.

Atelier de programmation

Python 2

Python 3

Module 8

code

(n/a)

Module 9

(n/a)

code

Ressources en ligne

Vous trouverez ci-dessous des ressources en ligne qui peuvent être utiles pour ce tutoriel :

App Engine

Cloud NDB

Cloud Datastore

Cloud Tasks

Informations sur les autres clouds

Licence

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