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

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

Nous avons ajouté l'utilisation de la file d'attente de tâches pour les tâches push dans le module 7, puis nous avons migré cette utilisation vers Cloud Tasks dans le module 8. Dans ce module 9, nous passons à Python 3 et à Cloud Datastore. Ceux qui utilisent des files d'attente pour les tâches d'extraction migreront vers Cloud Pub/Sub et doivent plutôt se référer aux modules 18 à 19.

Vous apprendrez à

  • Porter l'exemple d'application du module 8 vers Python 3
  • Passer 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 ?

<ph type="x-smartling-placeholder"></ph> Je vous invite à 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 ?

<ph type="x-smartling-placeholder"></ph> Débutant Intermédiaire Expert .

2. Contexte

Le module 7 montre comment utiliser les tâches d'envoi de la file d'attente des tâches App Engine dans les applications App Engine Flask Python 2. Dans le module 8, vous migrez cette application de la file d'attente de tâches vers Cloud Tasks. Dans le module 9, vous poursuivez le parcours et le portage de cette application vers Python 3, et vous faites passer l'accès à Datastore de Cloud NDB à la bibliothèque cliente Cloud Datastore native.

Étant donné que Cloud NDB fonctionne à la fois avec Python 2 et 3, cela suffit aux utilisateurs d'App Engine qui transfèrent leurs applications de Python 2 vers Python 3. Une migration supplémentaire de bibliothèques clientes vers Cloud Datastore est totalement facultative. Cela n'est valable que pour une seule raison: vous disposez d'applications non-App Engine (et/ou d'applications App Engine Python 3) qui utilisent déjà la bibliothèque cliente Cloud Datastore et souhaitez consolider votre codebase pour accéder à Datastore avec une seule bibliothèque cliente. Cloud NDB a été créé spécifiquement pour les développeurs App Engine Python 2 en tant qu'outil de migration Python 3. Par conséquent, si vous ne disposez 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" de l'une des versions finales de Python 2 à sa version Python 3 contemporaine. Heureusement, aucune modification destructive n'est apportée par Python 2. Vous n'avez donc rien d'autre à faire ici.

Ce tutoriel comprend les étapes suivantes:

  1. Configuration/Préparation
  2. Mettre à jour la configuration
  3. Modifier le code d'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

Cette procédure permet de s'assurer que vous commencez avec du code fonctionnel et qu'il est prêt pour la migration vers les services Cloud.

1. Configurer le projet

Si vous avez terminé l'atelier de programmation du module 8, réutilisez ce projet (et ce 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. Recherchez l'ID de votre projet, car vous en aurez besoin au cours de 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 une application App Engine opérationnelle du module 8: suivez l'atelier de programmation du module 8 (recommandé) ou copiez l'application du module 8 à partir du dépôt. Que vous utilisiez le vôtre ou le nôtre, nous commencerons par le code du Module 8 ("DÉMARRER"). Cet atelier de programmation vous guide tout au long de la migration et se termine par un code ressemblant à 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 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 et valider l'application de référence

Exécutez les étapes suivantes pour déployer l'application du module 8:

  1. Supprimez le dossier lib s'il y en a un, puis exécutez pip install -t lib -r requirements.txt pour remplir à nouveau lib. Si Python 2 et 3 sont installés sur votre ordinateur 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 vérifié son utilisation.
  3. (Facultatif) Définissez votre projet Cloud avec gcloud config set project PROJECT_ID si vous ne souhaitez pas saisir PROJECT_ID avec chaque commande gcloud que vous émettez.
  4. Déployer l'exemple d'application avec gcloud app deploy
  5. Vérifiez que l'application fonctionne comme prévu sans problème. Si vous avez terminé l'atelier de programmation du module 8, l'application affiche les principaux visiteurs ainsi que les visites les plus récentes (voir ci-dessous). Les anciennes tâches qui seront supprimées sont indiquées en bas de l'écran.

4aa8a2cb5f527079.png

4. Mettre à jour la configuration

requirements.txt

Le nouveau requirements.txt est presque identique à celui du module 8, à une seule différence importante: remplacez google-cloud-ndb par google-cloud-datastore. Apportez cette modification pour que votre fichier requirements.txt 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 s'assurer que les versions fonctionnelles d'une application sont intégrées.

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 de bibliothèques non intégrées. La seule condition requise pour 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 script doivent être remplacés par auto. Toutefois, étant donné que toutes les routes doivent être remplacées par auto et qu'aucun fichier statique n'est diffusé à partir de cet exemple d'application, il est inutile d'avoir aucun gestionnaire. Vous devez donc également supprimer l'intégralité de la section handlers.

Dans app.yaml, il vous suffit de définir l'environnement d'exécution sur une version compatible de Python 3, par exemple 3.10. Apportez cette modification pour que la nouvelle version abrégée de app.yaml ne contienne que cette ligne unique:

runtime: python310

Supprimer les fichiers appengine_config.py et lib

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

  • Les bibliothèques intégrées sont approuvé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 environnements d'exécution de 2e génération.
  • La copie de bibliothèques non intégrées (parfois appelée "vendoring" ou "auto-regroupement") n'est plus nécessaire dans les environnements d'exécution de 2e génération. Ils devraient être répertorié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 devez donc les supprimer. Dans les environnements d'exécution de deuxième génération, App Engine installe automatiquement les packages tiers répertoriés dans requirements.txt. Résumé:

  1. Pas de bibliothèques tierces auto-groupées ou copiées les afficher 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 (et donc pas de section libraries) dans app.yaml. les afficher dans requirements.txt
  4. Pas de bibliothèques tierces à référencer depuis votre application : pas de fichier appengine_config.py

La seule condition requise pour les développeurs consiste à répertorier toutes les bibliothèques tierces souhaitées dans requirements.txt.

5. Mettre à jour les fichiers de l'application

Il n'existe qu'un seul fichier d'application, main.py. Toutes les modifications apportées dans cette section ne concernent donc que ce fichier. Vous trouverez ci-dessous les différences Illustration montrant 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 but est simplement d'obtenir un aperçu illustré des éléments requis dans cette refactorisation (mais n'hésitez pas à ouvrir un nouvel onglet ou à télécharger et à zoomer 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. il 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, modifiez ds_client pour qu'il pointe vers un client Datastore au lieu d'un client NDB. Une fois ces modifications effectuées, la partie supérieure 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, qui enregistre l'adresse IP et l'user-agent du client visiteur (type de navigateur).

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()

Cependant, Cloud Datastore n'utilise pas de classe de modèle de données. Vous devez donc supprimer la classe. De plus, Cloud Datastore ne crée pas automatiquement de code temporel lors de la création des enregistrements, ce qui vous oblige à le faire manuellement. Cette opération s'effectue via 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 principale est fetch_visits(). Non seulement il exécute la requête d'origine pour les dernières Visit, mais il récupère également le code temporel du dernier Visit affiché et crée la tâche d'envoi qui appelle /trim (donc trim()) pour supprimer en masse les anciens Visit. Ici, elle utilise 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

Principales modifications:

  1. Remplacer la requête Cloud NDB par une requête Cloud Datastore équivalente. les styles de requête diffèrent légèrement.
  2. Contrairement à Cloud NDB, Datastore ne nécessite pas l'utilisation d'un gestionnaire de contexte et ne vous oblige pas à extraire 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

Ce serait normalement tout ce qui est nécessaire. Malheureusement, il y a un problème majeur.

(Peut-être) Créer une file d'attente d'envoi

Dans le module 7, nous avons ajouté l'utilisation d'App Engine taskqueue à l'application existante du module 1. L'un des principaux avantages des tâches d'envoi en tant qu'ancienne fonctionnalité d'App Engine est qu'une règle "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'avons donc encore pas besoin de nous en soucier. Ce point sera modifié dans le module 9.

Il est essentiel de prendre en compte le fait 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 de tâches dans un autre produit (Cloud Tasks). Tel qu'écrit, 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 ("default") existe et, si ce n'est pas le cas, 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 sera 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 create_queue() de Cloud Tasks nécessite le nom de chemin complet de la file d'attente, à l'exception de son nom. 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 dans la partie supérieure de la page, de sorte que le bloc de code contenant toutes les attributions constantes se présente comme suit:

_, 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]

À présent, modifiez 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 ensuite 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 maintenant 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

À l'exception de l'ajout de ce code supplémentaire, le reste du code Cloud Tasks est resté presque intact lors du module 8. Le dernier morceau 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 antérieures à la plus ancienne affichée. Il utilise une requête ne contenant que des clés pour accélérer le processus. Pourquoi récupérer toutes les données si vous n'avez besoin que des ID de visite ? Une fois que vous disposez de tous les ID de visite, supprimez-les tous en lot à l'aide de 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(), l'essentiel des modifications consiste à 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().

Port vers Python 3

Cet exemple d'application a été conçu pour s'exécuter à la fois avec Python 2 et 3. Toutes les modifications spécifiques à Python 3 ont été abordées précédemment dans les sections correspondantes de ce tutoriel. Aucune étape supplémentaire ni aucune bibliothèque de compatibilité n'est requise.

Mise à jour de Cloud Tasks

La version finale de la bibliothèque cliente Cloud Tasks compatible avec Python 2 est la version 1.5.0. Au moment de la rédaction de ce document, 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 non plus dans le fichier de modèle HTML, templates/index.html. Ainsi, vous avez 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 port 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 est la fin de l'atelier de programmation. Nous vous invitons à comparer votre code avec le contenu du dossier du module 9. Félicitations !

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:

Étapes suivantes

Notre migration des tâches d'envoi de la file d'attente de tâches App Engine vers Cloud Tasks est maintenant terminée. La migration facultative de Cloud NDB vers Cloud Datastore est également traitée seule (sans file d'attente de tâches ni Cloud Tasks) dans le module 3. En plus du module 3, d'autres modules concernant la migration sont axés sur l'abandon des anciens services groupés App Engine:

  • Module 2: Migrer d'App Engine NDB vers Cloud NDB
  • Module 3: Migrer de Cloud NDB vers Cloud Datastore
  • Modules 12 à 13: Migrer de Memcache d'App Engine vers Cloud Memorystore
  • Modules 15 à 16: effectuer la migration d'un paquet d'application App Engine vers Cloud Storage
  • Modules 18 à 19: File d'attente des 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 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
  • Effectuer une migration 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

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 8 (START) et 9 (FINISH). Vous pouvez également y accéder à partir du dépôt de toutes les migrations de l'atelier 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 vous être utiles pour ce tutoriel:

App Engine

Cloud NDB

Cloud Datastore

Cloud Tasks

Autres informations sur le cloud

Licence

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