Migrer d'App Engine Memcache vers Cloud Memorystore (module 13)

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 montrer aux développeurs Python 2 App Engine comment migrer d'App Engine Memcache vers Cloud Memorystore (pour Redis). Il existe également une migration implicite d'App Engine ndb vers Cloud NDB, mais elle est principalement abordée dans l'atelier de programmation du module 2. Consultez-le pour obtenir plus d'informations détaillées.

Vous n'utilisez pas Memcache ?

Si votre application n'utilise pas App Engine Memcache, vous pouvez ignorer cet atelier de programmation ou le suivre comme exercice pour vous familiariser avec la migration vers Cloud Memorystore.

Vous apprendrez à

• Configurer une instance Cloud Memorystore (à partir de la console Cloud ou de l'outil gcloud)
• Configurer un connecteur d'accès au VPC sans serveur Cloud (à partir de la console Cloud ou de l'outil gcloud)
• Migrer d'App Engine Memcache vers Cloud Memorystore
• Implémenter la mise en cache avec Cloud Memorystore dans un exemple d'application
• Migrer depuis App Engine ndb vers Cloud NDB

Prérequis

• Un projet Google Cloud avec un compte de facturation actif (il ne s'agit pas d'un atelier de programmation sans frais)
• Des connaissances de base en Python
• Une connaissance correcte des commandes Linux courantes
• Des connaissances de base du développement et du déploiement d'applications App Engine
• Une application App Engine du module 12 fonctionnelle (suivez l'atelier de programmation du module 12 [recommandé] ou copiez l'application du module 12 depuis le dépôt).

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

Cet atelier de programmation montre comment migrer un exemple d'application depuis App Engine Memcache (et NDB) vers Cloud Memorystore (et Cloud NDB). Ce processus implique de remplacer les dépendances sur les services groupés App Engine, ce qui rend vos applications plus portables. Vous pouvez choisir de rester sur App Engine ou d'envisager de passer à l'une des alternatives décrites précédemment.

Cette migration nécessite plus d'efforts que les autres de cette série. Le remplacement recommandé pour App Engine Memcache est Cloud Memorystore, un service de mise en cache cloud entièrement géré. Memorystore est compatible avec deux moteurs de mise en cache Open Source populaires, Redis et Memcached. Ce module de migration utilise Cloud Memorystore pour Redis. Pour en savoir plus, consultez la présentation de Memorystore et Redis.

Étant donné que Memorystore nécessite un serveur en cours d'exécution, Cloud VPC est également nécessaire. Plus précisément, un connecteur d'accès au VPC sans serveur doit être créé pour que l'application App Engine puisse se connecter à l'instance Memorystore via son adresse IP privée. À la fin de cet exercice, vous aurez mis à jour l'application pour qu'elle se comporte comme avant, mais avec Cloud Memorystore comme service de mise en cache, en remplacement du service Memcache d'App Engine.

Ce tutoriel commence par l'exemple d'application du module 12 en Python 2, suivi d'une mise à niveau mineure facultative vers Python 3. Si vous savez déjà comment accéder aux services groupés App Engine depuis Python 3 via le SDK App Engine pour Python 3, vous pouvez commencer par la version Python 3 de l'exemple d'application du module 12. Pour ce faire, vous devrez cesser d'utiliser le SDK, car Memorystore n'est pas un service groupé App Engine. Ce tutoriel ne couvre pas l'utilisation du SDK App Engine Python 3.

Ce tutoriel comprend les étapes clés suivantes :

1. Configuration/Préparation
2. Configurer les services de mise en cache
3. Mettre à jour les fichiers de configuration
4. Mettre à jour l'application principale

3. Configuration/Préparation

Préparer le projet Cloud

Nous vous conseillons de réutiliser le même projet que celui utilisé pour l'atelier de programmation du module 12. Vous pouvez également créer un projet ou réutiliser un autre projet existant. Chaque atelier de programmation de cette série comporte un code "START" (code de base à partir duquel commencer) et un code "FINISH" (application migrée). Le code FINISH est fourni pour que vous puissiez comparer vos solutions aux nôtres en cas de problème. Vous pouvez toujours revenir à l'état de départ si quelque chose ne fonctionne pas. Ces points de contrôle sont conçus pour vous aider à effectuer les migrations.

Quel que soit le projet Cloud que vous utilisez, assurez-vous qu'il dispose d'un compte de facturation actif. Assurez-vous également que App Engine est activé. Examinez les implications générales en termes de coûts de ces tutoriels et assurez-vous de les comprendre. Contrairement à d'autres ateliers de programmation de cette série, celui-ci utilise des ressources Cloud qui ne disposent pas d'une version sans frais. Vous devrez donc payer certains coûts pour terminer l'exercice. Des informations plus spécifiques sur les coûts seront fournies avec les recommandations de réduction de l'utilisation, y compris des instructions à la fin sur la libération des ressources pour minimiser les frais de facturation.

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

À partir du code de référence du module 12, cet atelier de programmation vous guide pas à pas dans la migration. Une fois terminé, vous obtiendrez une application du module 13 fonctionnelle, qui ressemblera beaucoup au code de l'un des dossiers FINISH. Voici ces ressources :

• START : application Module 12 Python 2 (mod12) ou Python 3 (mod12b)
• FINISH : application Python 2 (mod13a) ou Python 3 (mod13b) du module 13
• Dépôt de migration complet (cloner ou télécharger un fichier ZIP)

Le dossier "START" doit contenir les fichiers suivants :

$ ls
README.md               app.yaml                main.py                 requirements.txt        templates                

Si vous commencez par la version Python 2, vous verrez également un fichier appengine_config.py et éventuellement un dossier lib si vous avez terminé l'atelier de programmation du module 12.

(Re)Déployer l'application du module 12

Étapes préliminaires restantes :

1. Familiarisez-vous avec l'outil de ligne de commande gcloud (si nécessaire).
2. (Re)déployez le code du module 12 sur App Engine (si nécessaire).

Les utilisateurs de Python 2 doivent supprimer et réinstaller le dossier lib à l'aide des commandes suivantes :

rm -rf ./lib; pip install -t lib -r requirements.txt                

À présent, tous les utilisateurs (Python 2 et 3) doivent importer le code dans App Engine à l'aide de la commande suivante :

gcloud app deploy                

Une fois le déploiement réussi, vérifiez que l'application ressemble et fonctionne comme celle du module 12, à savoir une application Web qui suit les visites et les met en cache pour le même utilisateur pendant une heure :

Comme les visites les plus récentes sont mises en cache, l'actualisation des pages devrait être assez rapide.

4. Configurer les services de mise en cache

Cloud Memorystore n'est pas sans serveur. Une instance est requise (dans ce cas, une instance Redis en cours d'exécution). Contrairement à Memcache, Memorystore est un produit Cloud autonome et ne dispose pas de version sans frais. Veillez donc à consulter les informations sur les tarifs de Memorystore pour Redis avant de continuer. Pour minimiser les coûts de cet exercice, nous vous recommandons d'utiliser le moins de ressources possible : un niveau de service Basic et une capacité de 1 Go.

L'instance Memorystore se trouve sur un réseau différent de celui de votre application (instances) App Engine. C'est pourquoi vous devez créer un connecteur d'accès au VPC sans serveur pour qu'App Engine puisse accéder à vos ressources Memorystore. Pour minimiser les coûts VPC, optez pour le type d'instance (f1-micro) et le nombre minimal d'instances à demander (nous vous suggérons au moins deux et au plus trois). Consultez également la page d'informations tarifaires sur le VPC.

Coût : ce tutoriel N'EST PAS sans frais

Alors que la plupart des ateliers de programmation sur la migration de cette série peuvent être suivis sans frais, celui-ci fait exception. Ni Cloud Memorystore ni Cloud VPC ne proposent de version sans frais. Vous ne pouvez donc pas continuer sans générer de frais. Nous vous recommandons vivement de consulter les informations tarifaires pour les deux produits avant de continuer. Si vous êtes sensible aux coûts, mais que vous souhaitez continuer à utiliser cette fonctionnalité, nous vous recommandons d'utiliser les options les moins chères. Pour réduire les coûts au minimum, libérez immédiatement ces ressources une fois l'atelier de programmation terminé.

Nous répétons ces recommandations pour réduire les coûts à mesure que nous vous guidons dans la création de chaque ressource requise. De plus, lorsque vous créez des ressources Memorystore et VPC dans la console Cloud, le calculateur de prix de chaque produit s'affiche en haut à droite, ce qui vous permet d'obtenir une estimation des coûts mensuels (voir l'illustration ci-dessous). Ces valeurs s'ajustent automatiquement si vous modifiez vos options. Voici à quoi vous devriez vous attendre :

Les deux ressources sont obligatoires, et l'ordre dans lequel vous les créez n'a pas d'importance. Si vous créez l'instance Memorystore en premier, votre application App Engine ne pourra pas y accéder sans le connecteur VPC. De même, si vous créez le connecteur VPC en premier, il n'y aura rien sur ce réseau VPC avec lequel votre application App Engine pourra communiquer. Dans ce tutoriel, vous allez d'abord créer l'instance Memorystore, puis le connecteur VPC.

Une fois les deux ressources en ligne, vous allez ajouter les informations pertinentes à app.yaml afin que votre application puisse accéder au cache. Vous pouvez également consulter les guides Python 2 ou Python 3 dans la documentation officielle. Il est également utile de consulter le guide de mise en cache des données sur la page de migration Cloud NDB ( Python 2 ou Python 3).

Créer toutes les ressources dans la région App Engine

Vous allez créer ci-dessous toutes les ressources Cloud supplémentaires nécessaires pour utiliser Cloud Memorystore comme service de mise en cache de votre application App Engine. Avant de le faire, sachez que vous devez créer l'instance Memorystore et le connecteur d'accès au VPC sans serveur dans la même région que l'application App Engine.

Créer une instance Cloud Memorystore

Comme Cloud Memorystore ne propose pas de version sans frais, nous vous recommandons d'allouer le moins de ressources possible pour effectuer l'atelier de programmation. Vous pouvez réduire les coûts au minimum en utilisant les paramètres suivants :

• Sélectionnez le niveau de service le plus bas : Basique (par défaut dans la console : "Standard", par défaut dans gcloud : "Basique").
• Choisissez la plus petite quantité de stockage : 1 Go (valeur par défaut de la console : 16 Go, valeur par défaut de gcloud : 1 Go).
• En règle générale, les versions les plus récentes de n'importe quel logiciel nécessitent le plus de ressources, mais il n'est probablement pas recommandé de sélectionner la version la plus ancienne non plus. La deuxième version la plus récente est actuellement Redis version 5.0 (version par défaut de la console : 6.x).

En gardant ces paramètres à l'esprit, la section suivante vous guidera dans la création de l'instance à partir de la console Cloud. Si vous préférez le faire à partir de la ligne de commande, passez à la section suivante.

Depuis Cloud Console

Accédez à la page Cloud Memorystore dans la console Cloud (vous serez peut-être invité à fournir des informations de facturation). Si vous n'avez pas encore activé Memorystore, vous serez invité à le faire :

Une fois que vous l'avez activé (éventuellement avec la facturation), vous accédez au tableau de bord Memorystore. Toutes les instances créées dans votre projet s'affichent ici. Le projet ci-dessous n'en comporte aucune. C'est pourquoi le message "Aucune ligne à afficher" s'affiche. Pour créer une instance Memorystore, cliquez sur Créer une instance en haut de la page :

Nouveautés de la console Cloud

Notez que l'interface utilisateur de la console Cloud change de temps en temps. Il est donc possible qu'elle ne ressemble pas exactement aux captures d'écran présentées ici.

Cette page comporte un formulaire à remplir avec les paramètres de votre choix pour créer l'instance Memorystore :

Pour limiter les coûts de ce tutoriel et de son exemple d'application, suivez les recommandations abordées précédemment. Une fois les sélections effectuées, cliquez sur Créer. Le processus de création prend plusieurs minutes. Une fois l'opération terminée, copiez l'adresse IP et le numéro de port de l'instance pour les ajouter à app.yaml.

Depuis la ligne de commande

Bien qu'il soit visuellement informatif de créer des instances Memorystore à partir de la console Cloud, certains préfèrent la ligne de commande. Assurez-vous d'avoir installé et initialisé gcloud avant de continuer.

Comme pour la console Cloud, Cloud Memorystore pour Redis doit être activé. Exécutez la commande gcloud services enable redis.googleapis.com et attendez qu'elle soit terminée, comme dans cet exemple :

$ gcloud services enable redis.googleapis.com
Operation "operations/acat.p2-aaa-bbb-ccc-ddd-eee-ffffff" finished successfully.

Si le service a déjà été activé, l'exécution (à nouveau) de la commande n'a aucun effet secondaire (négatif). Maintenant que le service est activé, créons une instance Memorystore. La commande se présente comme suit :

gcloud redis instances create NAME --redis-version VERSION \
    --region REGION --project PROJECT_ID

Choisissez un nom pour votre instance Memorystore. Cet atelier utilise "demo-ms" comme nom et "my-project" comme ID de projet. La région de cet exemple d'application est us-central1 (identique à us-central), mais vous pouvez en utiliser une plus proche de vous si la latence est un problème. Vous devez sélectionner la même région que celle de votre application App Engine. Vous pouvez sélectionner la version de Redis de votre choix, mais nous utilisons la version 5, comme recommandé précédemment. Compte tenu de ces paramètres, voici la commande à exécuter (ainsi que le résultat associé) :

$ gcloud redis instances create demo-ms --region us-central1 \
    --redis-version redis_5_0 --project my-project

Create request issued for: [demo-ms]
Waiting for operation [projects/my-project/locations/us-central1/operations/operation-xxxx] to complete...done.
Created instance [demo-ms].

Contrairement aux paramètres par défaut de la console Cloud, gcloud est défini par défaut sur des ressources minimales. Par conséquent, ni le niveau de service ni la quantité de stockage n'étaient requis dans cette commande. La création d'une instance Memorystore prend plusieurs minutes. Une fois l'opération terminée, notez l'adresse IP et le numéro de port de l'instance, car ils seront bientôt ajoutés à app.yaml.

Confirmer la création de l'instance

Depuis la console Cloud ou la ligne de commande

Que vous ayez créé votre instance à partir de la console Cloud ou de la ligne de commande, vous pouvez vérifier qu'elle est disponible et prête à l'emploi à l'aide de la commande suivante : gcloud redis instances list --region REGION.

Voici la commande permettant de vérifier les instances dans la région us-central1, ainsi que le résultat attendu montrant l'instance que nous venons de créer :

$ gcloud redis instances list --region us-central1
INSTANCE_NAME  VERSION    REGION       TIER   SIZE_GB  HOST         PORT  NETWORK  RESERVED_IP     STATUS  CREATE_TIME
demo-ms        REDIS_5_0  us-central1  BASIC  1        10.aa.bb.cc  6379  default  10.aa.bb.dd/29  READY   2022-01-28T09:24:45

Lorsque vous êtes invité à fournir les informations sur l'instance ou à configurer votre application, veillez à utiliser HOST et PORT (et non RESERVED_IP). Le tableau de bord Cloud Memorystore de la console Cloud Console devrait maintenant afficher cette instance :

Depuis une machine virtuelle Compute Engine

Si vous disposez d'une machine virtuelle (VM) Compute Engine, vous pouvez également envoyer des commandes directes à votre instance Memorystore depuis une VM pour vérifier qu'elle fonctionne. Sachez que l'utilisation d'une VM peut entraîner des coûts indépendants des ressources que vous utilisez déjà.

Créer un connecteur d'accès au VPC sans serveur

Comme pour Cloud Memorystore, vous pouvez créer le connecteur VPC Cloud sans serveur dans la console Cloud ou sur la ligne de commande. De même, Cloud VPC ne dispose pas d'un niveau sans frais. Nous vous recommandons donc d'allouer le moins de ressources possible pour terminer l'atelier de programmation afin de minimiser les coûts. Vous pouvez y parvenir avec les paramètres suivants :

• Sélectionnez le nombre maximal d'instances le plus faible : 3 (par défaut : 10 dans la console et gcloud)
• Choisissez le type de machine le moins cher : f1-micro (par défaut dans la console : e2-micro, pas de valeur par défaut pour gcloud)

La section suivante vous guidera dans la création du connecteur à partir de la console Cloud à l'aide des paramètres de VPC Cloud ci-dessus. Si vous préférez le faire à partir de la ligne de commande, passez à la section suivante.

Depuis la console Cloud

Accédez à la page Accès au VPC sans serveur de la section "Réseau cloud" dans la console Cloud (vous serez peut-être invité à fournir des informations de facturation). Si vous n'avez pas encore activé l'API, vous serez invité à le faire :

Une fois l'API activée (et éventuellement la facturation), vous accédez au tableau de bord affichant tous les connecteurs VPC créés. Le projet utilisé dans la capture d'écran ci-dessous n'en comporte aucun. C'est pourquoi le message "Aucune ligne à afficher" s'affiche. Dans la console, cliquez sur Create Connector (Créer un connecteur) en haut de l'écran :

Remplissez le formulaire avec les paramètres souhaités :

Choisissez les paramètres appropriés pour vos propres applications. Pour ce tutoriel et son application exemple aux besoins minimes, il est judicieux de minimiser les coûts. Suivez donc les recommandations abordées précédemment. Une fois les sélections effectuées, cliquez sur Créer. La demande d'un connecteur VPC prend quelques minutes.

Depuis la ligne de commande

Avant de créer un connecteur VPC, activez d'abord l'API Serverless VPC Access. Un résultat semblable à celui-ci devrait s'afficher après l'exécution de la commande suivante :

$ gcloud services enable vpcaccess.googleapis.com
Operation "operations/acf.p2-aaa-bbb-ccc-ddd-eee-ffffff" finished successfully.

Une fois l'API activée, un connecteur VPC est créé à l'aide d'une commande semblable à celle-ci :

gcloud compute networks vpc-access connectors create CONNECTOR_NAME \
    --range 10.8.0.0/28 --region REGION --project PROJECT_ID

Choisissez un nom pour votre connecteur, ainsi qu'une adresse IP de début de bloc CIDR /28 inutilisée. Ce tutoriel repose sur les hypothèses suivantes :

• ID du projet : my-project
• Nom du connecteur VPC : demo-vpc
• Nombre minimal d'instances : 2 (par défaut) et nombre maximal d'instances : 3
• Type d'instance : f1-micro
• Région : us-central1
• Bloc CIDR IPv4 : 10.8.0.0/28 (comme recommandé dans la console cloud)

Si vous exécutez la commande suivante en gardant à l'esprit les hypothèses ci-dessus, vous devriez obtenir un résultat semblable à celui-ci :

$ gcloud compute networks vpc-access connectors create demo-vpc \
    --max-instances 3 --range 10.8.0.0/28 --machine-type f1-micro \
    --region us-central1  --project my-project

Create request issued for: [demo-vpc]
Waiting for operation [projects/my-project/locations/us-central1/operations/xxx] to complete...done.
Created connector [demo-vpc].

La commande ci-dessus omet de spécifier les valeurs par défaut, telles que le nombre minimal d'instances (2) et un réseau nommé default. La création d'un connecteur VPC prend plusieurs minutes.

Confirmer la création du connecteur

Une fois le processus terminé, exécutez la commande gcloud suivante, en supposant qu'il s'agit de la région us-central1, pour confirmer qu'il a été créé et qu'il est prêt à être utilisé :

$ gcloud compute networks vpc-access connectors list --region us-central1
CONNECTOR_ID  REGION       NETWORK  IP_CIDR_RANGE  SUBNET  SUBNET_PROJECT  MIN_THROUGHPUT  MAX_THROUGHPUT  STATE
demo-vpc      us-central1  default  10.8.0.0/28                            200             300             READY

De même, le tableau de bord devrait maintenant afficher le connecteur que vous venez de créer :

Notez l'ID du projet Cloud, le nom du connecteur VPC et la région.

Maintenant que vous avez créé les ressources Cloud supplémentaires nécessaires, que ce soit en ligne de commande ou dans la console, il est temps de mettre à jour la configuration de l'application pour prendre en charge leur utilisation.

5. Mettre à jour les fichiers de configuration

La première étape consiste à apporter toutes les modifications nécessaires aux fichiers de configuration. L'objectif principal de cet atelier de programmation est d'aider les utilisateurs de Python 2 à migrer. Toutefois, chaque section ci-dessous contient généralement des informations sur le portage vers Python 3.

requirements.txt

Dans cette section, nous ajoutons des packages pour prendre en charge Cloud Memorystore et Cloud NDB. Pour Cloud Memorystore pour Redis, il suffit d'utiliser le client Redis standard pour Python (redis), car il n'existe pas de bibliothèque cliente Cloud Memorystore à proprement parler. Ajoutez redis et google-cloud-ndb à requirements.txt, en joignant flask du module 12 :

flask
redis
google-cloud-ndb

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é, spécifiez les numéros de version pour verrouiller les versions fonctionnelles.

app.yaml

Nouvelles sections à ajouter

L'environnement d'exécution App Engine Python 2 nécessite des packages tiers spécifiques lorsque vous utilisez des API Cloud telles que Cloud NDB, à savoir grpcio et setuptools. Les utilisateurs de Python 2 doivent lister les bibliothèques intégrées comme celles-ci avec une version disponible dans app.yaml. Si vous n'avez pas encore de section libraries, créez-en une et ajoutez les deux bibliothèques comme suit :

libraries:
- name: grpcio
  version: latest
- name: setuptools
  version: latest

Lors de la migration de votre application, il est possible qu'elle comporte déjà une section libraries. Si c'est le cas et que grpcio et setuptools sont manquants, ajoutez-les simplement à votre section libraries existante.

Ensuite, notre exemple d'application a besoin des informations sur l'instance Cloud Memorystore et le connecteur VPC. Ajoutez donc les deux nouvelles sections suivantes à app.yaml, quel que soit le runtime Python que vous utilisez :

env_variables:
    REDIS_HOST: 'YOUR_REDIS_HOST'
    REDIS_PORT: 'YOUR_REDIS_PORT'

vpc_access_connector:
    name: projects/PROJECT_ID/locations/REGION/connectors/CONNECTOR

C'est tout pour les mises à jour requises. Votre fichier app.yaml mis à jour devrait maintenant ressembler à ceci :

runtime: python27
threadsafe: yes
api_version: 1

handlers:
- url: /.*
  script: main.app

libraries:
- name: grpcio
  version: 1.0.0
- name: setuptools
  version: 36.6.0

env_variables:
    REDIS_HOST: 'YOUR_REDIS_HOST'
    REDIS_PORT: 'YOUR_REDIS_PORT'

vpc_access_connector:
    name: projects/PROJECT_ID/locations/REGION/connectors/CONNECTOR

Vous trouverez ci-dessous un exemple avant/après illustrant les modifications à apporter à app.yaml :

*Différences avec Python 3

Cette section est facultative et ne s'applique que si vous effectuez un portage vers Python 3. Pour ce faire, vous devez apporter plusieurs modifications à votre configuration Python 2. Ignorez cette section si vous ne souhaitez pas passer à un forfait supérieur pour le moment.

Ni threadsafe, ni api_version ne sont utilisés pour l'environnement d'exécution Python 3. Supprimez donc ces deux paramètres. Le dernier environnement d'exécution App Engine n'est pas compatible avec les bibliothèques tierces intégrées 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.

Ensuite, l'environnement d'exécution Python 3 nécessite l'utilisation de frameworks Web qui effectuent leur propre routage. C'est pourquoi nous avons montré aux développeurs comment migrer de webp2 vers Flask dans le module 1. Par conséquent, tous les gestionnaires de scripts doivent être définis sur auto. Étant donné que cette application ne diffuse aucun fichier statique, il est "inutile" d'avoir des gestionnaires listés (puisqu'ils sont tous auto). Vous pouvez donc également supprimer toute la section handlers. Par conséquent, votre nouveau app.yaml abrégé et adapté à Python 3 devrait ressembler à ceci :

runtime: python39

env_variables:
    REDIS_HOST: 'YOUR_REDIS_HOST'
    REDIS_PORT: 'YOUR_REDIS_PORT'

vpc_access_connector:
    name: projects/PROJECT_ID/locations/REGION/connectors/CONNECTOR

Voici un résumé des différences dans app.yaml lors du portage vers Python 3 :

• Supprimer les paramètres threadsafe et api_version
• Supprimer la section libraries
• Supprimez la section handlers (ou simplement les gestionnaires script si votre application diffuse des fichiers statiques).

Remplacer les valeurs

Les valeurs des nouvelles sections pour Memorystore et le connecteur VPC ne sont que des espaces réservés. Remplacez ces valeurs en majuscules (YOUR_REDIS_HOST, YOUR_REDIS_PORT, PROJECT_ID, REGION, CONNECTOR_NAME) par les valeurs enregistrées lorsque vous avez créé ces ressources précédemment. En ce qui concerne votre instance Memorystore, veillez à utiliser HOST (et non RESERVED_IP) et PORT. Voici une méthode rapide en ligne de commande pour obtenir HOST et PORT en supposant que le nom de l'instance est demo-ms et que REGION est us-central1 :

$ gcloud redis instances describe demo-ms --region us-central1 \
    --format "value(host,port)"
10.251.161.51   6379

Si l'adresse IP de notre exemple d'instance Redis était 10.10.10.10 utilisant le port 6379 dans notre projet my-project situé dans la région us-central1 avec un nom de connecteur VPC de demo-vpc, ces sections dans app.yaml ressembleraient à ceci :

env_variables:
    REDIS_HOST: '10.10.10.10'
    REDIS_PORT: '6379'

vpc_access_connector:
    name: projects/my-project/locations/us-central1/connectors/demo-vpc

Créer ou mettre à jour appengine_config.py

Ajouter la prise en charge des bibliothèques tierces intégrées

Comme nous l'avons fait avec app.yaml plus tôt, ajoutez l'utilisation des bibliothèques grpcio et setuptools. Modifiez appengine_config.py pour prendre en charge les bibliothèques tierces intégrées. Si cela vous semble familier, c'est parce que cela était également nécessaire dans le module 2 lors de la migration d'App Engine ndb vers Cloud NDB. La modification exacte requise consiste à ajouter le dossier lib à l'ensemble de travail setuptools.pkg_resources :

*Différences avec Python 3

Cette section est facultative et ne s'applique que si vous effectuez un portage vers Python 3. L'un des changements bienvenus de la deuxième génération d'App Engine est qu'il n'est plus nécessaire de copier (parfois appelé "vendoring") les packages tiers (non intégrés) ni de référencer les packages tiers intégrés dans app.yaml. Cela signifie que vous pouvez supprimer l'intégralité du fichier appengine_config.py.

6. 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. Nous avons fourni une représentation visuelle des modifications que nous allons apporter pour migrer cette application vers Cloud Memorystore. Il est fourni à titre d'illustration uniquement et n'est pas destiné à être analysé en détail. Tout le travail se trouve dans les modifications que nous apportons au code.

Commençons par le haut et traitons chaque section une par une.

Mettre à jour les importations

La section d'importation de main.py pour le module 12 utilise Cloud NDB et Cloud Tasks. Voici leurs importations :

AVANT :

from flask import Flask, render_template, request
from google.appengine.api import memcache
from google.appengine.ext import ndb

Pour passer à Memorystore, il faut lire les variables d'environnement. Nous avons donc besoin du module Python os et de redis, le client Python Redis. Étant donné que Redis ne peut pas mettre en cache les objets Python, marshal la liste des visites les plus récentes à l'aide de pickle. Importez-la également. L'un des avantages de Memcache est que la sérialisation des objets se fait automatiquement, alors que Memorystore est un peu plus "DIY". Enfin, migrez d'App Engine ndb vers Cloud NDB en remplaçant google.appengine.ext.ndb par google.cloud.ndb. Après ces modifications, vos importations devraient se présenter comme suit :

APRÈS :

import os
import pickle
from flask import Flask, render_template, request
from google.cloud import ndb
import redis

Mettre à jour l'initialisation

L'initialisation du module 12 consiste à instancier l'objet d'application Flask app et à définir une constante pour une heure de mise en cache :

AVANT :

app = Flask(__name__)
HOUR = 3600

L'utilisation des API Cloud nécessite un client. Instanciez donc un client Cloud NDB juste après Flask. Ensuite, récupérez l'adresse IP et le numéro de port de l'instance Memorystore à partir des variables d'environnement que vous avez définies dans app.yaml. À l'aide de ces informations, instanciez un client Redis. Voici à quoi ressemble votre code après ces modifications :

APRÈS :

app = Flask(__name__)
ds_client = ndb.Client()
HOUR = 3600
REDIS_HOST = os.environ.get('REDIS_HOST', 'localhost')
REDIS_PORT = os.environ.get('REDIS_PORT', '6379')
REDIS = redis.Redis(host=REDIS_HOST, port=REDIS_PORT)

*Migration vers Python 3

Cette section est facultative si vous commencez avec la version Python 3 de l'application du module 12. Dans ce cas, plusieurs modifications sont requises concernant les importations et l'initialisation.

Tout d'abord, comme Memcache est un service groupé App Engine, son utilisation dans une application Python 3 nécessite le SDK App Engine, en particulier l'encapsulation de l'application WSGI (ainsi que d'autres configurations nécessaires) :

AVANT :

from flask import Flask, render_template, request
from google.appengine.api import memcache, wrap_wsgi_app
from google.appengine.ext import ndb

app = Flask(__name__)
app.wsgi_app = wrap_wsgi_app(app.wsgi_app)
HOUR = 3600

Étant donné que nous migrons vers Cloud Memorystore (qui n'est pas un service groupé App Engine comme Memcache), l'utilisation du SDK doit être supprimée. C'est simple : il vous suffit de supprimer toute la ligne qui importe memcache et wrap_wsgi_app. Supprimez également la ligne appelant wrap_wsgi_app(). Ces mises à jour laissent cette partie de l'application (en fait, l'application entière) identique à la version Python 2.

APRÈS :

import os
import pickle
from flask import Flask, render_template, request
from google.cloud import ndb
import redis

app = Flask(__name__)
ds_client = ndb.Client()
HOUR = 3600
REDIS_HOST = os.environ.get('REDIS_HOST', 'localhost')
REDIS_PORT = os.environ.get('REDIS_PORT', '6379')
REDIS = redis.Redis(host=REDIS_HOST, port=REDIS_PORT)

Enfin, supprimez l'utilisation du SDK de app.yaml (supprimez la ligne : app_engine_apis: true) et de requirements.txt (supprimez la ligne : appengine-python-standard).

Migrer vers Cloud Memorystore (et Cloud NDB)

Le modèle de données de Cloud NDB est conçu pour être compatible avec celui d'App Engine ndb, ce qui signifie que la définition des objets Visit reste la même. Comme pour la migration du module 2 vers Cloud NDB, tous les appels Datastore dans store_visit() et fetch_visits() sont augmentés et intégrés dans un nouveau bloc with (car l'utilisation du gestionnaire de contexte Cloud NDB est requise). Voici ces appels avant ce changement :

AVANT :

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

def fetch_visits(limit):
    'get most recent visits'
    return Visit.query().order(-Visit.timestamp).fetch(limit)

Ajoutez un bloc with ds_client.context() aux deux fonctions et placez les appels Datastore à l'intérieur (en les mettant en retrait). Dans ce cas, aucune modification n'est nécessaire pour les appels eux-mêmes :

APRÈS :

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

def fetch_visits(limit):
    'get most recent visits'
    with ds_client.context():
        return Visit.query().order(-Visit.timestamp).fetch(limit)

Examinons ensuite les modifications apportées à la mise en cache. Voici la fonction main() du module 12 :

AVANT :

@app.route('/')
def root():
    'main application (GET) handler'
    # check for (hour-)cached visits
    ip_addr, usr_agt = request.remote_addr, request.user_agent
    visitor = '{}: {}'.format(ip_addr, usr_agt)
    visits = memcache.get('visits')

    # register visit & run DB query if cache empty or new visitor
    if not visits or visits[0].visitor != visitor:
        store_visit(ip_addr, usr_agt)
        visits = list(fetch_visits(10))
        memcache.set('visits', visits, HOUR)  # set() not add()

    return render_template('index.html', visits=visits)

Redis dispose d'appels "get" et "set", tout comme Memcache. Il suffit d'échanger les bibliothèques clientes respectives, n'est-ce pas ? Presque. Comme indiqué précédemment, nous ne pouvons pas mettre en cache une liste Python avec Redis (car elle doit d'abord être sérialisée, ce dont Memcache s'occupe automatiquement). Par conséquent, dans l'appel set(), "sérialisez" les visites dans une chaîne avec pickle.dumps(). De même, lorsque vous récupérez des visites à partir du cache, vous devez les désérialiser avec pickle.loads() juste après get(). Voici le gestionnaire principal après l'implémentation de ces modifications :

APRÈS :

@app.route('/')
def root():
    'main application (GET) handler'
    # check for (hour-)cached visits
    ip_addr, usr_agt = request.remote_addr, request.user_agent
    visitor = '{}: {}'.format(ip_addr, usr_agt)
    rsp = REDIS.get('visits')
    visits = pickle.loads(rsp) if rsp else None

    # register visit & run DB query if cache empty or new visitor
    if not visits or visits[0].visitor != visitor:
        store_visit(ip_addr, usr_agt)
        visits = list(fetch_visits(10))
        REDIS.set('visits', pickle.dumps(visits), ex=HOUR)

    return render_template('index.html', visits=visits)

Les modifications requises dans main.py pour convertir l'utilisation de Memcache par l'application exemple en Cloud Memorystore sont maintenant terminées. Qu'en est-il du modèle HTML et du portage vers Python 3 ?

Mettre à jour le fichier de modèle HTML et le porter vers Python 3

Surprise ! Vous n'avez rien à faire ici, car l'application a été conçue pour s'exécuter sur Python 2 et Python 3 sans aucune modification de code ni bibliothèque de compatibilité. Vous trouverez main.py. identiques dans les dossiers "FINISH" mod13a (2.x) et mod13b (3.x). Il en va de même pour requirements.txt , à l'exception des différences de numéros de version (le cas échéant). Comme l'interface utilisateur reste inchangée, templates/index.html n'est pas non plus modifié.

Tout ce qui est nécessaire pour exécuter cette application sur Python 3 App Engine a été effectué précédemment dans la configuration : les directives inutiles ont été supprimées de app.yaml, et appengine_config.py ainsi que le dossier lib ont été supprimés, car ils ne sont pas utilisés dans Python 3.

App Engine NDB et Cloud NDB fournissent une mise en cache automatisée

Bien que nous migrions explicitement d'App Engine Memcache vers Cloud Memorystore, notez qu'App Engine ndb et Cloud NDB fournissent respectivement une mise en cache automatisée vers Memcache ou Memorystore, pour Python 2 ou 3. Pour en savoir plus sur la mise en cache ndb, consultez Mise en cache NDB et Mise en cache Cloud NDB dans Activer la mise en cache des données. Les instructions de ce dernier document sont très similaires à celles de cet atelier de programmation. Pour en savoir plus, consultez Options de contexte et de transaction.

Nous n'avons pas utilisé cette mise en cache automatique, car notre exemple d'application n'interroge pas les entités Datastore individuelles (qui pourraient être facilement accessibles via le cache). Au lieu de cela, cette application met en cache un tableau d'entités (visites les plus récentes), ce qui constitue un cas d'utilisation trop spécifique et non pris en charge par la couche de mise en cache automatique. Toutefois, votre application peut effectuer de telles requêtes et tirer parti de cette fonctionnalité, ce qui simplifie son utilisation globale.

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

La dernière vérification consiste toujours à déployer l'application exemple. Développeurs Python 2 : supprimez et réinstallez lib à l'aide des commandes ci-dessous. (Si vous avez installé Python 2 et 3 sur votre système, vous devrez peut-être exécuter explicitement pip2.)

rm -rf ./lib
pip install -t lib -r requirements.txt

Les développeurs Python 2 et Python 3 doivent désormais déployer leurs applications avec la commande suivante :

gcloud app deploy

Comme vous avez simplement modifié les éléments sous le capot pour un service de mise en cache complètement différent, l'application elle-même devrait fonctionner de la même manière que votre application du module 12 :

Cette étape termine l'atelier de programmation. Nous vous invitons à comparer votre exemple d'application mis à jour avec l'un des dossiers du module 13, mod13a (Python 2) ou mod13b (Python 3).

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 :

• Cloud Memorystore nécessite des instances et ne propose pas de version sans frais. Pour en savoir plus sur les coûts d'utilisation, consultez la page des tarifs.
• Les connecteurs d'accès au VPC sans serveur Cloud nécessitent des instances et ne disposent pas de niveau sans frais. Pour en savoir plus sur les coûts d'utilisation, consultez la section correspondante sur la page Tarifs de Cloud VPC.
• Cloud Datastore (Cloud Firestore en mode Datastore) propose un niveau sans frais. Pour en savoir plus, consultez sa page de tarification.

Ce tutoriel impliquait l'utilisation de quatre produits Cloud :

• App Engine
• Cloud Datastore
• Cloud Memorystore
• Cloud VPC

Vous trouverez ci-dessous des instructions pour libérer ces ressources et éviter ou minimiser les frais de facturation.

Arrêter l'instance Memorystore et le connecteur VPC

Il s'agit de produits sans niveau sans frais. Par conséquent, la facturation est immédiate. Si vous ne fermez pas votre projet Cloud (voir la section suivante), vous devez supprimer votre instance Memorystore et le connecteur VPC pour arrêter la facturation. Comme lors de la création de ces ressources, vous pouvez également les libérer depuis la console Cloud ou la ligne de commande.

Depuis la console Cloud

Pour supprimer l'instance Memorystore, revenez au tableau de bord Memorystore et cliquez sur l'ID de l'instance :

Sur la page d'informations de cette instance, cliquez sur "Supprimer", puis confirmez :

Pour supprimer le connecteur VPC, accédez à son tableau de bord, cochez la case à côté du connecteur que vous souhaitez supprimer, puis cliquez sur "Supprimer" et confirmez :

Depuis la ligne de commande

La paire de commandes gcloud suivante supprime respectivement l'instance Memorystore et le connecteur VPC :

• gcloud redis instances delete INSTANCE --region REGION
• gcloud compute networks vpc-access connectors delete CONNECTOR --region REGION

Si vous n'avez pas défini votre ID de projet avec gcloud config set project, vous devrez peut-être fournir --project PROJECT_ID. Si votre instance Memorystore s'appelle demo-ms et que votre connecteur VPC s'appelle demo-vpc, et que les deux se trouvent dans la région us-central1, exécutez la paire de commandes suivante et confirmez :

$ gcloud redis instances delete demo-ms --region us-central1
You are about to delete instance [demo-ms] in [us-central1].
Any associated data will be lost.

Do you want to continue (Y/n)?

Delete request issued for: [demo-ms]
Waiting for operation [projects/PROJECT/locations/REGION/operations/operation-aaaaa-bbbbb-ccccc-ddddd] to complete...done.
Deleted instance [demo-ms].
$
$ gcloud compute networks vpc-access connectors delete demo-vpc --region us-central1
You are about to delete connector [demo-vpc] in [us-central1].
Any associated data will be lost.

Do you want to continue (Y/n)?

Delete request issued for: [demo-vpc]
Waiting for operation [projects/PROJECT/locations/REGION/operations/aaaaa-bbbb-cccc-dddd-eeeee] to complete...done.
Deleted connector [demo-vpc].

L'exécution de chaque requête prend quelques minutes. Ces étapes sont facultatives si vous choisissez d'arrêter l'intégralité de votre projet Cloud comme décrit précédemment. Toutefois, la facturation continue jusqu'à la fin du processus d'arrêt.

Étapes suivantes

Au-delà de ce tutoriel, voici d'autres modules de migration qui se concentrent sur l'abandon des anciens services groupés :

• Module 2 : migrer depuis App Engine ndb vers Cloud NDB
• Modules 7 à 9 : migrer les tâches push de la file d'attente de tâches App Engine vers Cloud Tasks
• 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 : migrer depuis la file d'attente de tâches App Engine (tâches de retrait) 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.

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

• Rechercher les problèmes
• Signaler un nouveau problème ou envoyer des commentaires

Ressources de migration

Le tableau ci-dessous contient des liens vers les dossiers du dépôt pour les modules 12 (START) et 13 (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 12	code	code
Module 13 (cet atelier de programmation)	code	code

Références en ligne

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

App Engine

• Documentation App Engine
• Environnement d'exécution Python 2 App Engine (environnement standard)
• Utiliser les bibliothèques intégrées d'App Engine sur Python 2 App Engine
• Environnement d'exécution Python 3 App Engine (environnement standard)
• Différences entre les environnements d'exécution Python 2 et Python 3 App Engine (environnement standard)
• Guide de migration d'App Engine (environnement standard) de Python 2 vers Python 3
• Informations sur les tarifs et les quotas d'App Engine

App Engine NDB et Cloud NDB

• Présentation d'App Engine NDB
• Utilisation d'App Engine NDB Datastore
• Documentation Google Cloud NDB
• Dépôt Google Cloud NDB
• Informations sur les tarifs de Cloud Datastore

App Engine Memcache et Cloud Memorystore

• Présentation de Memcache d'App Engine
• Documentation de référence sur Python 2 App Engine memcache
• Documentation de référence sur memcache App Engine pour Python 3
• Guide de migration d'App Engine memcache vers Cloud Memorystore
• Documentation Cloud Memorystore
• Documentation Cloud Memorystore pour Redis
• Informations sur la tarification de Cloud Memorystore pour Redis
• Versions de Redis compatibles avec Cloud Memorystore
• Page d'accueil de Cloud Memorystore
• Créer une instance Memorystore dans la console Cloud
• Page d'accueil du client Python Redis
• Documentation de la bibliothèque cliente Python Redis

Cloud VPC

• Documentation Google Cloud sur le VPC
• Page d'accueil du VPC Google Cloud
• Informations sur les tarifs de Cloud VPC
• Créer un connecteur d'accès au VPC sans serveur dans la console Cloud

Informations sur les autres clouds

• Python sur Google Cloud Platform
• Bibliothèques clientes Google Cloud Python
• Niveau "Toujours sans frais" de Google Cloud
• SDK Google Cloud (outil de ligne de commande gcloud)
• Toute la documentation Google Cloud

Licence

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