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

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

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 Cloud Console 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

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

Cet atelier de programmation explique comment migrer un exemple d'application de Memcache d'App Engine (et de NDK) vers Cloud Memorystore (et Cloud NDB). Ce processus implique le remplacement des dépendances aux services groupés App Engine afin d'améliorer la portabilité de vos applications. Vous pouvez choisir de rester sur App Engine ou de passer à l'une des alternatives décrites précédemment.

Cette migration demande plus d'efforts que les autres projets de cette série. Il est recommandé de remplacer App Engine Memcache par Cloud Memorystore, un service de mise en cache entièrement géré dans le cloud. Memorystore est compatible avec une paire de moteurs de mise en cache Open Source courants, Redis et Memcached. Ce module de migration utilise Cloud Memorystore pour Redis. Pour en savoir plus, consultez la présentation de Memorystore et Redis.

Comme 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. Une fois cet exercice terminé, vous aurez mis à jour l'application de sorte que Cloud Memorystore remplace le service Memcache d'App Engine en tant que service de mise en cache, même si elle se comporte comme auparavant.

Ce tutoriel commence par l'application exemple du module 12 en Python 2, suivie d'une mise à niveau mineure supplémentaire facultative vers Python 3. Si vous savez déjà comment accéder aux services groupés App Engine à partir de 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. Cela implique de supprimer le SDK, car Memorystore n'est pas un service groupé App Engine. L'utilisation du SDK App Engine pour Python 3 n'est pas abordée dans ce tutoriel.

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 recommandons de réutiliser le projet que vous avez 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 une instruction "START" (le code de référence à partir duquel commencer) et un "FINISH" (l'application migrée). Le code FINISH vous est fourni pour vous permettre de comparer vos solutions avec les nôtres en cas de problème. En cas de problème, vous pouvez toujours revenir au mode "DÉMARRER". Ces points de contrôle sont conçus pour vous aider à bien apprendre à effectuer les migrations.

Quel que soit votre projet Cloud, assurez-vous qu'il dispose d'un compte de facturation actif. Vérifiez également qu'App Engine est activé. Examinez les conséquences générales sur les coûts de ces tutoriels et assurez-vous de bien les comprendre. Toutefois, contrairement aux autres ateliers de cette série, cet atelier de programmation utilise des ressources Cloud qui n'ont pas de version sans frais. Des coûts seront donc facturés pour réaliser l'exercice. Des informations plus spécifiques sur les coûts seront fournies, ainsi que des recommandations pour réduire l'utilisation. Nous fournirons également, à la fin, des instructions sur la libération des ressources afin de réduire les frais facturés.

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

Cet atelier de programmation, qui s'appuie sur le code de référence du module 12, vous guide pas à pas tout au long de la migration. Une fois l'opération terminée, vous accéderez à une application fonctionnelle du module 13, ressemblant fortement au code de l'un des dossiers FINISH. Voici ces ressources:

Le dossier "START" doit contenir les fichiers suivants:

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

Si vous utilisez la version Python 2, vous trouverez é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

Vos étapes préparatoires restantes:

  1. Familiarisez-vous à nouveau avec l'outil de ligne de commande gcloud (si nécessaire).
  2. (Re)déployer 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, tout le monde (utilisateurs de Python 2 et 3) doit importer le code dans App Engine à l'aide de la commande suivante:

gcloud app deploy

Une fois déployée, vérifiez que l'application se présente et fonctionne exactement comme l'application du module 12 (une application Web qui suit les visites, en les mettant en cache pour le même utilisateur pendant une heure) :

dfe56a02ae59ddd8.png

Étant donné que les visites les plus récentes sont mises en cache, les actualisations de page devraient se charger assez rapidement.

4. Configurer les services de mise en cache

Cloud Memorystore n'est pas un outil sans serveur. Veuillez indiquer une instance. dans ce cas, un service Redis. Contrairement à Memcache, Memorystore est un produit cloud autonome et ne propose pas de version sans frais. Veillez donc à consulter les informations tarifaires 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 App Engine (instances). Vous devez donc créer un connecteur d'accès au VPC sans serveur pour qu'App Engine puisse accéder à vos ressources Memorystore. Pour réduire les coûts liés au VPC, choisissez le type d'instance (f1-micro) et le plus petit nombre d'instances à demander (nous suggérons au minimum 2, au maximum 3). Consultez également la page d'informations tarifaires des VPC.

Nous réitérons ces recommandations pour réduire les coûts au fur et à mesure que nous vous guiderons dans la création de chaque ressource requise. De plus, lorsque vous créez des ressources Memorystore et VPC dans la console Cloud, le simulateur de coût de chaque produit s'affiche en haut à droite. Il vous donne une estimation du coût mensuel (voir l'illustration ci-dessous). Ces valeurs sont automatiquement ajustées si vous modifiez vos options. Voici à peu près le résultat:

7eb35ebf7248c010.png

Ces deux ressources sont requises, peu importe celle que vous créez en premier. Si vous créez d'abord l'instance Memorystore, votre application App Engine ne pourra pas y accéder sans le connecteur VPC. De même, si vous créez d'abord le connecteur VPC, votre application App Engine n'aura aucune communication sur ce réseau VPC. Dans ce tutoriel, vous allez commencer par 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 vous reporter aux guides Python 2 ou Python 3 dans la documentation officielle. Il convient également de consulter le guide de mise en cache des données disponible sur la page de migration Cloud NDB ( Python 2 ou Python 3).

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 terminer l'atelier de programmation. Vous pouvez limiter les coûts en utilisant les paramètres suivants:

  • Sélectionnez le niveau de service le plus bas: Basic (la valeur par défaut de la console : "Standard" et gcloud la valeur par défaut : "Basic").
  • Sélectionnez le minimum d'espace de stockage: 1 Go (par défaut de la console: 16 Go, gcloud par défaut: 1 Go).
  • Généralement, les versions les plus récentes de n'importe quel logiciel nécessitent le plus de ressources, mais il est probablement déconseillé de choisir la version la plus ancienne. La deuxième dernière version est actuellement la version Redis 5.0 (valeur 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 depuis la console Cloud. Si vous préférez le faire à partir de la ligne de commande, passez à l'étape suivante.

Depuis Cloud Console

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

68318997e3105db6.png

Une fois activé (et éventuellement la facturation), le tableau de bord Memorystore s'affiche. C'est ici que vous pouvez voir toutes les instances créées dans votre projet. Le projet ci-dessous n'en possède pas. 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:

63547aa575838a36.png

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

b77d927287fdf4c7.png

Pour limiter les coûts de ce tutoriel et de son application exemple, suivez les recommandations décrites 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 instructif de créer des instances Memorystore à partir de la console Cloud, certains préfèrent utiliser la ligne de commande. Assurez-vous que gcloud est installé et initialisé 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 se termine, 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 de la commande n'a pas d'effets secondaires (négatifs). Une fois le service activé, créons une instance Memorystore. Cette 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, suivi de l'ID de projet "my-project". La région de cette application exemple 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 votre application App Engine. Vous pouvez sélectionner la version de Redis que vous préférez, mais nous utilisons la version 5 comme recommandé précédemment. Compte tenu de ces paramètres, voici la commande à exécuter (avec la sortie associée):

$ 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 utilise par défaut les ressources minimales. Par conséquent, ni le niveau de service, ni la quantité de stockage n'étaient requis pour 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, cette commande vous permet de vérifier qu'elle est disponible et prête à être utilisée: 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é à saisir les informations d'instance ou à configurer votre application, veillez à utiliser HOST et PORT (et non RESERVED_IP). Le tableau de bord Cloud Memorystore dans Cloud Console devrait maintenant afficher cette instance:

c5a6948ec1c056ed.png

Depuis la 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 avoir des coûts associés indépendamment des ressources que vous utilisez déjà.

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

Comme avec Cloud Memorystore, vous pouvez créer le connecteur VPC Cloud sans serveur dans la console Cloud ou via la ligne de commande. De même, Cloud VPC ne propose pas de version sans frais. Nous vous recommandons donc d'allouer le moins de ressources possible à la réalisation de l'atelier de programmation afin de réduire au maximum les coûts. Pour cela, utilisez les paramètres suivants:

  • Sélectionnez le nombre maximal d'instances le plus bas: 3 (console et gcloud par défaut: 10).
  • Choisissez le type de machine le moins coûteux: f1-micro (valeur par défaut de la console: e2-micro, pas de gcloud par défaut).

La section suivante vous explique comment créer le connecteur depuis Cloud Console à l'aide des paramètres Cloud VPC 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 mise en réseau cloud de la console Cloud (vous devrez peut-être saisir des informations de facturation). Si vous n'avez pas encore activé l'API, vous serez invité à le faire:

e3b9c0651de25e97.png

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

b74b49b9d73b7dcf.png

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

6b26b2aafa719f73.png

Choisissez les paramètres appropriés pour vos propres applications. Pour ce tutoriel et son application exemple avec des besoins minimaux, il est logique de réduire les coûts. Suivez donc les recommandations décrites précédemment. Une fois que vous avez effectué vos sélections, cliquez sur Créer. L'installation 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. Vous devriez obtenir un résultat semblable à la commande suivante:

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

Lorsque l'API est activée, un connecteur VPC est créé à l'aide d'une commande qui se présente comme suit:

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)

Attendez-vous à un résultat semblable à celui présenté ci-dessous si vous exécutez la commande suivante en gardant à l'esprit les hypothèses ci-dessus:

$ 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 de 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 vérifier qu'elle a été créée et prête à être utilisée:

$ 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 doit maintenant afficher le connecteur que vous venez de créer:

e03db2c8140ed014.png

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 par ligne de commande ou dans la console, il est temps de mettre à jour la configuration de l'application pour qu'elle soit compatible avec leur utilisation.

5. Mettre à jour les fichiers de configuration

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

requirements.txt

Dans cette section, nous allons ajouter des packages pour les rendre compatibles avec Cloud Memorystore et Cloud NDB. Pour Cloud Memorystore pour Redis, il suffit d'utiliser le client Redis standard pour Python (redis), car il n'y a pas de bibliothèque cliente Cloud Memorystore en soi. 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 à verrouiller dans les versions fonctionnelles.

app.yaml

Nouvelles sections à ajouter

L'environnement d'exécution Python 2 App Engine nécessite des packages tiers spécifiques lors de l'utilisation d'API Cloud comme Cloud NDB, à savoir grpcio et setuptools. Les utilisateurs de Python 2 doivent répertorier des bibliothèques intégrées comme celles-ci, ainsi qu'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 de l'instance Cloud Memorystore et du connecteur VPC. Vous devez donc ajouter les deux nouvelles sections suivantes à app.yaml, quel que soit l'environnement d'exécution 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 app.yaml mis à jour devrait maintenant se présenter comme suit:

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 une Pour illustrer les mises à jour à appliquer à app.yaml:

ec2bb027a67debb6.png

*Différences avec Python 3

Cette section est facultative et uniquement si vous effectuez le portage vers Python 3. Pour ce faire, vous devez apporter un certain nombre de modifications à votre configuration Python 2. Ignorez cette section si vous n'effectuez pas la mise à niveau pour le moment.

Ni threadsafe, ni api_version ne sont utilisés dans l'environnement d'exécution Python 3. Supprimez donc ces deux paramètres. L'environnement d'exécution le plus récent d'App Engine n'accepte pas les bibliothèques tierces intégrées ni 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.

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 passer de webp2 à Flask dans le module 1. Par conséquent, tous les gestionnaires de script doivent être remplacés par auto. Comme cette application ne diffuse aucun fichier statique, elle est "inutile". d'avoir des gestionnaires listés (puisqu'ils sont tous des auto), ce qui permet de supprimer l'intégralité de la section handlers. Par conséquent, votre nouvelle version abrégée de app.yaml modifiée pour Python 3 devrait être raccourcie pour se présenter comme suit:

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

Récapitulons les différences de app.yaml lors du portage vers Python 3:

  • Supprimer les paramètres threadsafe et api_version
  • Supprimer la section libraries
  • Supprimer la section handlers (ou uniquement 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 lors de la création de ces ressources. En ce qui concerne votre instance Memorystore, veillez à utiliser HOST (et non RESERVED_IP) et PORT. Voici une méthode de ligne de commande rapide pour obtenir HOST et PORT en supposant que le nom d'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 notre exemple d'adresse IP d'instance Redis était 10.10.10.10 sur le port 6379 de notre projet my-project situé dans la région us-central1 avec le nom du connecteur VPC demo-vpc, les sections suivantes de app.yaml se présenteront comme suit:

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 le fichier appengine_config.py

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

Comme nous l'avons fait avec app.yaml précédemment, 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 vous en avez également besoin 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:

4140b3800694f77e.png

*Différences avec Python 3

Cette section est facultative et uniquement si vous effectuez le portage vers Python 3. L'une des modifications les plus intéressantes d'App Engine de deuxième génération est que la copie (parfois appelée "vendoring") de packages tiers (non intégrés) et le référencement de packages tiers intégrés dans app.yaml ne sont plus nécessaires. Vous pouvez donc supprimer l'intégralité du fichier appengine_config.py.

6. 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 une illustration des modifications que nous allons apporter pour migrer cette application vers Cloud Memorystore. Elles ne sont fournies qu'à titre d'illustration et ne vous permettent pas de les analyser en détail. Tout le travail repose sur les modifications que nous apportons au code.

5d043768ba7be742.png

Abordons ces sections une par une, en commençant par le haut.

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

Passer à Memorystore nécessite de lire les variables d'environnement. Cela signifie que nous avons besoin du module Python os ainsi que de redis, le client Python pour Redis. Étant donné que Redis ne peut pas mettre en cache les objets Python, mettez en cache la liste des visites les plus récentes à l'aide de pickle. Importez-la donc également. L'un des avantages de Memcache est que la sérialisation des objets s'effectue automatiquement, tandis que Memorystore est un peu plus "DIY". Enfin, mettez à niveau la version ndb d'App Engine 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

Initialisation de la mise à jour

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. Avec ces informations, instanciez un client Redis. Une fois ces mises à jour effectuées, votre code se présente comme suit:

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 Python 3

Cette section est facultative si vous démarrez avec la version Python 3 de l'application du module 12. Si tel est le cas, vous devez apporter plusieurs modifications liées aux importations et à l'initialisation.

Tout d'abord, étant donné que Memcache est un service App Engine groupé, son utilisation dans une application Python 3 nécessite le SDK App Engine, encapsulant spécifiquement 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 effectuons la migration vers Cloud Memorystore (et non vers un service groupé App Engine tel que Memcache), l'utilisation du SDK doit être supprimée. Cette opération est simple, car vous allez simplement supprimer la ligne entière qui importe à la fois memcache et wrap_wsgi_app. Supprimez également la ligne appelant wrap_wsgi_app(). Ces mises à jour laissent cette partie de l'application (l'application entière en fait) 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 les ndb d'App Engine, ce qui signifie que la définition des objets Visit reste la même. Imitant 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 les appels qui précèdent 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, puis placez les appels Datastore à l'intérieur (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 maintenant les changements de 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 utilise l'opération "get" et "set" tout comme Memcache. Tout ce que nous faisons, c’est échanger les bibliothèques clientes respectives, n’est-ce pas ? Vous y êtes 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, car Memcache se charge automatiquement). Ainsi, dans l'appel set(), "pickle" les visites dans une chaîne avec pickle.dumps(). De même, lorsque vous récupérez les visites à partir du cache, vous devez la débrancher avec pickle.loads() juste après get(). Voici le gestionnaire principal après avoir implémenté 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)

Vous venez de terminer les modifications requises dans main.py pour convertir l'utilisation de Memcache de l'exemple d'application vers Cloud Memorystore. Qu'en est-il du modèle HTML et du portage vers Python 3 ?

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

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

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

7. Résumé/Nettoyage

Cette section conclut cet atelier de programmation en déployant l'application, en vérifiant qu'elle fonctionne comme prévu et dans tout résultat réfléchi. Après la validation de l'application, effectuez un nettoyage et réfléchissez aux prochaines étapes.

Déployer et vérifier l'application

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

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

Les développeurs Python 2 et 3 doivent maintenant déployer leurs applications avec:

gcloud app deploy

Étant donné que vous avez simplement recâblé des éléments en arrière-plan pour un service de mise en cache complètement différent, l'application elle-même doit fonctionner de la même manière que l'application du module 12:

Application Visitme du module 7

Cette étape est la fin de l'atelier de programmation. Nous vous invitons à comparer votre exemple d'application mise à 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é, 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:

  • 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 sa page de tarification.
  • Les connecteurs d'accès au VPC sans serveur Cloud nécessitent des instances et n'offrent pas de version sans frais. Pour en savoir plus sur les coûts d'utilisation, consultez la section correspondante sur la page des tarifs de Cloud VPC.
  • Cloud Datastore (Cloud Firestore en mode Datastore) propose une version sans frais. consultez sa page des tarifs pour en savoir plus.

Ce tutoriel implique 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 pour éviter/réduire les frais facturés.

Arrêter l'instance Memorystore et le connecteur VPC

Il s'agit des produits sansde version sans frais. Vous êtes donc facturé en ce moment. Si vous n'arrêtez pas votre projet Cloud (voir la section suivante), vous devez supprimer à la fois votre instance Memorystore et le connecteur VPC pour arrêter la facturation. Comme lorsque vous avez créé ces ressources, vous pouvez les libérer à partir de la console Cloud ou de 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:

2b09baf1aa2e0a25.png

Une fois sur la page d'informations de cette instance, cliquez sur "Supprimer". et confirmez:

f9d9eb1c1d4c6107.png

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

ca5fbd9f4c7c9b60.png

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 sur gcloud config set project, vous devrez peut-être indiquer --project PROJECT_ID. Si votre instance Memorystore s'appelle demo-ms et que le connecteur VPC s'appelle demo-vpc, et qu'ils se trouvent tous les deux dans la région us-central1, exécutez la paire de commandes suivante, puis 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'ensemble de votre projet Cloud comme décrit précédemment. Toutefois, des frais vous sont facturés jusqu'à la fin du processus d'arrêt.

Étapes suivantes

Au-delà de ce tutoriel, d'autres modules de migration à envisager concernant l'abandon des anciens services groupés sont les suivants:

  • Module 2: Migrer de l'environnement ndb App Engine vers Cloud NDB
  • Modules 7 à 9: migration des tâches d'envoi de la file d'attente des tâches App Engine vers Cloud Tasks
  • 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: Migrer de la 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 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.

8. Ressources supplémentaires

Vous trouverez ci-dessous des ressources supplémentaires destinées aux développeurs qui étudient plus en détail ce module de migration ou le module de migration associé, ainsi que les produits associés. Vous y trouverez, par exemple, des emplacements où vous pouvez envoyer des commentaires sur ce contenu, des liens vers le code et diverses documents susceptibles de vous être utiles.

Commentaires et problèmes concernant les ateliers de programmation

Si vous rencontrez des problèmes avec cet atelier de programmation, commencez par faire une recherche avant de les signaler. Liens vers la recherche et la création d'un signalement :

Ressources de migration

Le tableau ci-dessous contient des liens vers les dossiers de dépôt des modules 12 (START) et 13 (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 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 vous être utiles pour ce tutoriel:

App Engine

App Engine NDB et Cloud NDB

Memcache d'App Engine et Cloud Memorystore

Cloud VPC

Autres informations sur le cloud

Licence

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