Module 11: Migrer de Google App Engine vers Cloud Functions

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.

Il peut arriver que vous n'ayez pas d'application entière nécessitant les ressources d'App Engine ou de Cloud Run. Si votre code ne se compose que d'un microservice ou d'une fonction simple, Cloud Functions est probablement plus adapté. Cet atelier de programmation vous apprend à migrer des applications App Engine simples (ou à diviser des applications plus volumineuses en plusieurs microservices) et à les déployer sur Cloud Functions, une autre plate-forme sans serveur spécialement conçue pour ce type de cas d'utilisation.

Vous apprendrez à

  • Utiliser Cloud Shell
  • Activer l'API Google Cloud Translation
  • Authentifier les requêtes API
  • Convertir une petite application App Engine pour qu'elle s'exécute sur Cloud Functions
  • Déployer votre code dans Cloud Functions

Prérequis

Enquête

Comment allez-vous utiliser ce tutoriel ?

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

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

Débutant Intermédiaire Expert

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

Débutant Intermédiaire Expert

2. Arrière-plan

Les systèmes PaaS tels que Google App Engine et Cloud Functions offrent de nombreux avantages aux utilisateurs. Ces plates-formes sans serveur permettent à votre équipe technique de se concentrer sur la création de solutions métier plutôt que de passer du temps à rechercher les plates-formes à utiliser et à déterminer la quantité de matériel nécessaire. Les applications peuvent évoluer automatiquement en fonction de vos besoins, voire même jusqu'à s'interrompre entièrement pour ne plus générer aucuns frais avec la facturation à l'utilisation. Elles sont également compatibles avec de nombreux langages de développement courants.

Toutefois, si le développement d'applications Web full stack ou de backends complexes pour les applications mobiles est idéal pour App Engine, il arrive souvent que les développeurs essaient principalement de mettre en ligne certaines fonctionnalités, comme la mise à jour d'un flux d'actualités ou la récupération du dernier score du match de qualification de l'équipe à domicile. Bien qu'une logique de codage existe pour les deux scénarios, aucun ne semble être une "application" à part entière nécessitant la puissance d'App Engine. C'est là qu'intervient Cloud Functions.

Cloud Functions permet de déployer le petit extrait de code qui :

  • Ne fait pas partie d'une application entière
  • N'est pas nécessaire dans une pile de développement complète
  • Se trouve dans une application ou un backend d'application mobile unique qui se concentre sur une seule chose

Vous pouvez également utiliser Cloud Functions pour diviser une grande application monolithique en plusieurs microservices, chacun utilisant une base de données commune partagée telle que Cloud Firestore ou Cloud SQL. Vous pouvez également conteneuriser votre fonction ou votre microservice et l'exécuter sans serveur sur Cloud Run.

Notre exemple d'application App Engine, qui a été présenté dans presque tous les tutoriels de migration, est une application courte avec des fonctionnalités de base qui fonctionne tout aussi bien dans Cloud Functions. Dans ce tutoriel, vous allez apprendre à modifier cette application pour qu'elle s'exécute sur Cloud Functions. Du point de vue d'App Engine, les fonctions étant plus simples que les applications entières, votre expérience de démarrage devrait être plus facile (et plus rapide), et avec moins de "frais généraux" en général. La migration comprend les étapes suivantes :

  • Configuration/Préparation
  • Supprimer les fichiers de configuration
  • Modifier les fichiers d'application

3. Configuration/Préparation

Cet atelier de programmation commence par la version Python 3 de l'exemple d'application Cloud NDB App Engine du module 2, car Cloud Functions n'est pas compatible avec Python 2. Commençons par configurer notre projet, obtenir le code, puis déployer l'application de base pour nous assurer de bien utiliser du code fonctionnel.

1. Configurer le projet

Si vous avez terminé l'atelier de programmation Module 2 (et que vous l'avez migré vers Python 3), nous vous recommandons de réutiliser le même projet (et le même code). Vous pouvez également créer un projet ou réutiliser un autre projet existant. Assurez-vous que le projet dispose d'un compte de facturation actif et que le service App Engine est activé.

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

L'une des conditions préalables à cet atelier de programmation est de disposer d'un exemple d'application fonctionnel du Module 2. Si vous n'en avez pas, suivez l'un de ces tutoriels (liens ci-dessus) avant de continuer. Si vous connaissez déjà le contenu de ce tutoriel, vous pouvez récupérer le code du module 2 ci-dessous.

Que vous utilisiez votre application ou la nôtre, le code de départ ("START") est celui du module 2 pour Python 3. Le présent atelier de programmation du module 11 vous guide pour chaque étape jusqu'à obtenir un code similaire à celui du dossier du dépôt du module 11 ("FINISH").

Pour Python 3, le répertoire de départ (votre code ou notre code) doit ressembler à ce qui suit :

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

3. (Re)Déployer l'application de référence

Étapes préliminaires restantes :

  1. Familiarisez-vous avec l'outil de ligne de commande gcloud
  2. Redéployez l'exemple d'application avec gcloud app deploy
  3. Vérifier que l'application s'exécute sans problème sur App Engine

Une fois ces étapes effectuées, vous êtes prêt à convertir l'application en fonction Cloud.

4. Supprimer les fichiers de configuration

Le fichier app.yaml est un artefact App Engine qui n'est pas utilisé avec Cloud Functions. Supprimez-le maintenant. Si vous ne le faites pas ou si vous oubliez de le faire, cela n'a aucune importance, car Cloud Functions ne l'utilise pas. Il s'agit de la seule modification de configuration, car requirements.txt reste identique à ce qu'il était dans le module 2.

Si vous portez également une application App Engine Python 2 vers Python 3, supprimez appengine_config.py et le dossier lib, le cas échéant. Il s'agit d'artefacts App Engine inutilisés dans l'environnement d'exécution Python 3.

5. Modifier les fichiers d'application

Il n'y a qu'un fichier d'application : main.py. Par conséquent, toutes les modifications nécessaires pour passer à Cloud Functions se produisent dans ce fichier.

Importations

Comme nous ne travaillons qu'avec des fonctions, nous n'avons pas besoin de framework d'application Web. Toutefois, pour plus de commodité, lorsqu'une fonction Cloud Functions basée sur Python est appelée, un objet de requête lui est automatiquement transmis pour que votre code puisse l'utiliser si nécessaire. (L'équipe Cloud Functions l'a sélectionné pour qu'il s'agisse d'un objet de requête Flask transmis à votre fonction.)

Étant donné que les frameworks Web ne font pas partie du paysage Cloud Functions, il n'y a pas d'importations depuis Flask sauf si votre application utilise d'autres fonctionnalités Flask. C'est effectivement notre cas, car le rendu du modèle a toujours lieu après la conversion en fonction. Cela signifie qu'un appel à flask.render_template() est toujours nécessaire, d'où son importation depuis Flask. Comme aucun framework Web n'est utilisé, il n'est pas nécessaire d'instancier une application Flask. Vous pouvez donc supprimer app = Flask(__name__). Votre code se présente comme suit, avant et après l'application des modifications :

AVANT :

from flask import Flask, render_template, request
from google.cloud import ndb

app = Flask(__name__)
ds_client = ndb.Client()

APRÈS :

from flask import render_template
from google.cloud import ndb

ds_client = ndb.Client()

Si vous dépendez de l'objet d'application (app) ou de toute autre infrastructure de framework Web, vous devez résoudre toutes ces dépendances en trouvant des solutions de contournement appropriées, en supprimant complètement leur utilisation ou en trouvant des proxys. Vous pourrez ensuite convertir votre code en fonction Cloud. Sinon, il est préférable de rester sur App Engine ou de conteneuriser votre application pour Cloud Run.

Mettre à jour la signature de la fonction de gestionnaire principal

Les modifications requises dans la signature de la fonction sont les suivantes :

  1. Flask n'étant plus utilisé après la conversion de l'application en fonction Cloud, supprimez les décorateurs de route.
  2. Cloud Functions transmet automatiquement l'objet Flask Request en tant que paramètre. Créez donc une variable pour celui-ci. Dans notre application exemple, nous l'appellerons request.
  3. Les fonctions Cloud déployées doivent être nommées. Notre gestionnaire principal a été nommé root() dans App Engine pour décrire ce qu'il était (le gestionnaire d'application racine). En tant que fonction Cloud, ce nom est moins pertinent. Nous allons plutôt déployer la fonction Cloud Functions avec le nom visitme. Utilisez donc ce nom pour la fonction Python. De même, dans les modules 4 et 5, nous avons également nommé le service Cloud Run visitme.

Voici les captures d'écran avant et après ces modifications :

AVANT :

@app.route('/')
def root():
    'main application (GET) handler'
    store_visit(request.remote_addr, request.user_agent)
    visits = fetch_visits(10)
    return render_template('index.html', visits=visits)

APRÈS :

def visitme(request):
    'main application (GET) handler'
    store_visit(request.remote_addr, request.user_agent)
    visits = fetch_visits(10)
    return render_template('index.html', visits=visits)

C'est tout pour les modifications nécessaires. Notez que les modifications apportées n'ont affecté que le code d'infrastructure de l'application. Aucune modification n'est nécessaire dans le code de l'application principale, et aucune fonctionnalité de l'application n'a été modifiée. Voici une représentation visuelle des modifications apportées pour illustrer ce point :

668f30e3865b27a9.png

Développement et tests locaux

Alors qu'App Engine dispose du serveur de développement local dev_appserver.py, Cloud Functions possède son propre framework Functions. Ce framework vous permet de développer et de tester des applications en local. Votre code peut être déployé sur Cloud Functions, mais aussi sur d'autres plates-formes de calcul telles que Compute Engine, Cloud Run, ou même sur des systèmes sur site ou de cloud hybride compatibles avec Knative. Vous trouverez ci-dessous d'autres liens vers le framework des fonctions.

6. Migration Build and Deploy

Le déploiement sur Cloud Functions diffère légèrement de celui sur App Engine. Comme aucun fichier de configuration n'est utilisé en dehors de requirements.txt, vous devez fournir plus d'informations sur le code dans la ligne de commande. Déployez votre nouvelle fonction Cloud déclenchée par HTTP s'exécutant sous Python 3.10 avec cette commande :

$ gcloud functions deploy visitme --runtime python310 --trigger-http --allow-unauthenticated

Un résultat semblable aux lignes suivantes doit s'afficher :

Deploying function (may take a while - up to 2 minutes)...⠛
For Cloud Build Logs, visit: https://console.cloud.google.com/cloud-build/builds;region=REGION/f5f6fc81-1bb3-4cdb-8bfe?project=PROJECT_ID
Deploying function (may take a while - up to 2 minutes)...done.
availableMemoryMb: 256
buildId: f5f6fc81-1bb3-4cdb-8bfe
buildName: projects/PROJECT_ID/locations/REGION/builds/f5f6fc81-1bb3-4cdb-8bfe
dockerRegistry: CONTAINER_REGISTRY
entryPoint: visitme
httpsTrigger:
  securityLevel: SECURE_OPTIONAL
  url: https://REGION-PROJECT_ID.cloudfunctions.net/visitme
ingressSettings: ALLOW_ALL
labels:
  deployment-tool: cli-gcloud
name: projects/PROJECT_ID/locations/REGION/functions/visitme
runtime: python310
serviceAccountEmail: PROJECT_ID@appspot.gserviceaccount.com
sourceUploadUrl: https://storage.googleapis.com/uploads-853031211983.REGION.cloudfunctions.appspot.com/8c923758-cee8-47ce-8e97-5720a5301c34.zip
status: ACTIVE
timeout: 60s
updateTime: '2022-05-16T18:28:06.153Z'
versionId: '8'

Une fois votre fonction déployée, utilisez l'URL de la sortie du déploiement pour accéder à votre application. L'URL est au format REGION-PROJECT_ID.cloudfunctions.net/visitme. Le résultat doit être identique à celui obtenu lorsque vous l'avez déployé sur App Engine :

2732ae9218f011a2.png

Comme pour la plupart des autres ateliers de programmation et vidéos de la série, la fonctionnalité de base de l'application ne change pas. L'objectif est d'appliquer une technique de modernisation et de faire en sorte que l'application fonctionne exactement comme avant, mais avec une infrastructure plus récente. Par exemple, migrer d'un ancien service App Engine vers son produit Cloud autonome de remplacement ou, comme dans le cas de ce tutoriel, déplacer une application vers une autre plate-forme Google Cloud sans serveur.

7. Résumé/Nettoyage

Félicitations pour avoir converti cette petite application App Engine en fonction Cloud Functions ! Autre cas d'utilisation approprié : décomposer une grande application App Engine monolithique en une série de microservices, chacun étant une fonction Cloud Functions. Il s'agit d'une technique de développement plus moderne qui permet d'obtenir un composant plus "plug-and-play" (à la manière de la pile JAM). Il permet de combiner et de réutiliser le code, ce qui constitue deux objectifs. Un autre avantage est que ces microservices continueront d'être débogués au fil du temps, ce qui signifie un code stable et des coûts de maintenance globaux plus faibles.

Effectuer un nettoyage

Une fois cet atelier de programmation terminé, vous pouvez désactiver l'application App Engine du module 2 (temporairement ou définitivement) pour éviter d'être facturé. La plate-forme App Engine dispose d'un quota sans frais. Vous ne serez donc pas facturé tant que vous resterez dans les limites de son niveau d'utilisation. Il en va de même pour Datastore. Pour en savoir plus, consultez la page des tarifs de Cloud Datastore.

Le déploiement sur des plates-formes telles qu'App Engine et Cloud Functions entraîne des coûts de compilation et de stockage mineurs. Dans certaines régions, Cloud Build et Cloud Storage disposent de leur propre quota sans frais. Les compilations consomment une partie de ce quota. Surveillez votre utilisation du stockage pour minimiser les coûts potentiels, en particulier si votre région ne propose pas de niveau sans frais.

Malheureusement, Cloud Functions ne dispose pas de fonctionnalité de désactivation. Sauvegardez votre code et supprimez simplement la fonction. Vous pourrez toujours le redéployer ultérieurement avec le même nom. En revanche, si vous ne souhaitez pas poursuivre d'autres ateliers de programmation sur la migration et que vous souhaitez tout supprimer complètement, arrêtez vos projets Cloud.

Étapes suivantes

Au-delà de ce tutoriel, d'autres modules de migration à consulter incluent la conteneurisation de votre application App Engine pour Cloud Run. Consultez les liens vers les ateliers de programmation des modules 4 et 5 :

  • Module 4 : Migrer vers Cloud Run avec Docker
  • Conteneurisez votre application pour l'exécuter sur Cloud Run avec Docker.
  • Cette migration vous permet de rester sur Python 2.
  • Module 5 : Migrer vers Cloud Run avec les buildpacks Cloud
  • Conteneurisez votre application pour qu'elle s'exécute sur Cloud Run avec les packs de création Cloud.
  • Il n'est pas nécessaire de déjà connaître Docker, les conteneurs ou les Dockerfile.
  • Nécessite que votre application ait déjà été migrée vers Python 3 (les packs de création ne sont pas compatibles avec Python 2)

De nombreux autres modules expliquent aux développeurs comment migrer des services groupés App Engine vers des services Cloud autonomes de remplacement :

  • 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

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 au lieu de Cloud Functions. 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. Que vous envisagiez de passer à Cloud Functions ou à Cloud Run, le changement de plate-forme sans serveur est facultatif. Nous vous recommandons d'étudier 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

Problèmes/commentaires concernant le module de migration App Engine en atelier de programmation

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

Ressources de migration

Le tableau ci-dessous contient des liens vers les dossiers du dépôt pour les modules 8 (START) et 9 (FINISH). Vous pouvez également y accéder depuis le dépôt pour toutes les migrations d'ateliers de programmation App Engine que vous pouvez cloner ou télécharger sous forme de fichier ZIP.

Atelier de programmation

Python 3

Module 2

code

Module 11

code

Ressources en ligne

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

App Engine

Cloud Functions

Informations sur les autres clouds

Vidéos

Licence

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