Module 11: Migrer de Google App Engine vers Cloud Functions

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.

Il peut arriver que votre application ne soit pas complète. d'avoir besoin des ressources d'App Engine ou de Cloud Run. Si votre code se compose uniquement d'un microservice ou d'une fonction simple, Cloud Functions est probablement plus adapté. Cet atelier de programmation vous explique comment migrer des applications App Engine simples (ou décomposer les applications volumineuses en plusieurs microservices) et les déployer sur Cloud Functions, une autre plate-forme sans serveur créée spécialement pour des cas d'utilisation de ce type.

Vous apprendrez à

  • Utiliser Cloud Shell
  • Activer l'API Google Cloud Translation
  • Authentifier les requêtes API
  • Convertir une petite application App Engine à exécuter 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 ?

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

2. Contexte

Les systèmes PaaS tels que Google App Engine et Cloud Functions offrent de nombreuses possibilités aux utilisateurs. Ces plates-formes sans serveur permettent à votre équipe technique de se concentrer sur la création de solutions d'entreprise au lieu de passer du temps à étudier les plates-formes à utiliser et à déterminer la quantité de matériel nécessaire. Les applications peuvent effectuer un scaling automatique à la hausse si nécessaire, effectuer un scaling à la baisse jusqu'à zéro avec la facturation à l'utilisation pour maîtriser les coûts. De plus, elles sont compatibles avec un grand nombre de langages de développement courants.

Cependant, si App Engine est parfaitement adapté au développement d'applications Web full stack ou aux backends complexes pour les applications mobiles, il est fréquent que les développeurs s'efforcent principalement de mettre en ligne certaines fonctionnalités, comme la mise à jour d'un flux d'actualités ou l'affichage du dernier score d'un match éliminatoire de l'équipe à domicile. Bien que la logique de codage existe pour les deux scénarios, aucun des deux ne semble être une "application" complète nécessitant la puissance d'App Engine. C'est là que Cloud Functions entre en jeu.

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

  • ne fait pas partie d'une application à part entière ;
  • ne sont pas nécessaires dans l'ensemble d'une pile de développement.
  • 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 décomposer une application monolithique volumineuse en plusieurs microservices, chacun utilisant une base de données commune partagée, telle que Cloud Firestore ou Cloud SQL. Si vous souhaitez que votre fonction ou votre microservice soit conteneurisé et exécuté sans serveur sur Cloud Run, c'est également possible.

Notre exemple d'application App Engine, 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 des applications entières, la prise en main doit être plus simple (et plus rapide) et allégée. en général. La migration comprend les étapes suivantes :

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

3. Configuration/Préparation

Cet atelier de programmation commence avec la version Python 3 de l'exemple d'application Cloud NDB App Engine pour le module 2, car Cloud Functions n'est pas compatible avec Python 2. Commençons par configurer le projet, récupérer le code, puis déployer l'application de référence pour vérifier que nous commençons avec du code fonctionnel.

1. Configurer le projet

Si vous avez terminé l'atelier de programmation du module 2 (et que vous l'avez transféré 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 pour lequel 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'une application exemple du module 2 qui fonctionne. Si vous n'en avez pas, suivez l'un des tutoriels indiqués ci-dessus avant de poursuivre. Si vous connaissez déjà son contenu, vous pouvez commencer par saisir le code du module 2 ci-dessous.

Nous allons commencer par découvrir le code Python 3 du module 2, que vous utilisiez le vôtre ou le nôtre. L'atelier de programmation du module 11 présente chaque étape et se termine par un code semblable à celui du dossier du dépôt du module 11 (FINISH).

Le répertoire des fichiers de démarrage Python 3 Module 2 (les vôtres ou les nôtres) doit se présenter comme 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 exécutées, vous êtes prêt à la convertir en fonction Cloud.

4. Supprimer des fichiers de configuration

Le fichier app.yaml est un artefact App Engine non utilisé avec Cloud Functions. Supprimez-le dès maintenant. Si vous ne le faites pas ou si vous oubliez de le faire, cela ne pose aucun problème, puisque Cloud Functions ne l'utilise pas. Il s'agit de la seule modification de configuration, car requirements.txt reste identique à ce qu'il a été présenté dans le module 2.

Si vous transférez également une application App Engine Python 2 vers Python 3, supprimez appengine_config.py et, le cas échéant, le dossier lib. 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'existe qu'un seul fichier d'application, main.py. Toutes les modifications nécessaires pour passer à Cloud Functions sont donc appliquées à ce fichier.

Importations

Comme nous ne travaillons qu'avec des fonctions, il n'est pas nécessaire d'avoir un framework d'application Web. Toutefois, pour plus de commodité, lorsque des fonctions Cloud basées sur Python sont appelées, elles reçoivent automatiquement un objet de requête que votre code peut utiliser selon les besoins. (L'équipe Cloud Functions l'a sélectionné comme un objet de requête Flask transmis à votre fonction.)

Les frameworks Web ne faisant pas partie de l'environnement Cloud Functions, il n'y a aucune importation à partir de 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, ce qui signifie qu'il est toujours nécessaire d'appeler flask.render_template(), d'où son importation depuis Flask. Aucun framework Web signifie qu'il n'est pas nécessaire d'instancier une application Flask. Par conséquent, supprimez app = Flask(__name__). Le 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, trouver des solutions de contournement appropriées, supprimer complètement leur utilisation ou trouver des proxys. Ce n'est qu'alors que vous pourrez 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 du gestionnaire principal

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

  1. Flask n'est plus utilisé après la conversion de l'application en fonction Cloud. Vous devez donc supprimer les décorateurs de routage.
  2. Cloud Functions transmet automatiquement l'objet Flask Request en tant que paramètre. Vous devez donc créer 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é de manière appropriée, root() dans App Engine, pour décrire de quoi il s'agissait (le gestionnaire d'application racine). En tant que fonction Cloud, il est moins logique d'utiliser ce nom. À la place, nous allons déployer la fonction Cloud portant le nom visitme. Vous devez donc l'utiliser également comme nom de la fonction Python. De même, dans les modules 4 et 5, nous avons également nommé le service Cloud Run visitme.

Voici ce qui a changé avant et après:

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)

Voilà qui conclut toutes les mises à jour nécessaires. Notez que les modifications apportées n'ont eu d'incidence que sur "l'infrastructure" de l'application. du code source. Aucune modification n'est requise dans le code de base de l'application et ses fonctionnalités n'ont pas été altérées. Pour illustrer ce point, voici une illustration des modifications apportées:

668f30e3865b27a9.png

Développement et tests locaux

Alors qu'App Engine dispose du serveur de développement local dev_appserver.py, Cloud Functions dispose d'un framework des fonctions. Avec ce framework, vous pouvez développer et tester en local. Vous pouvez déployer votre code dans Cloud Functions, mais aussi sur d'autres plates-formes de calcul telles que Compute Engine, Cloud Run, ou même sur des systèmes cloud hybrides ou sur site compatibles avec Knative. Vous trouverez ci-dessous des liens supplémentaires vers le framework des fonctions.

6. Migration Build and Deploy

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

$ 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 indiquée dans le résultat du déploiement et accédez à votre application. L'URL respecte le format suivant: REGION-PROJECT_ID.cloudfunctions.net/visitme. Le résultat doit être identique à celui obtenu précédemment dans App Engine:

2732ae9218f011a2.png

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

7. Résumé/Nettoyage

Félicitations ! Vous avez converti cette petite application App Engine en fonction Cloud. Autre cas d'utilisation approprié: décomposer une grande application monolithique App Engine en une série de microservices, chacun en tant que fonction Cloud. Il s'agit d'une technique de développement plus moderne, qui offre une expérience (la " Pile JAM"). Il permet de combiner et de mettre en correspondance, et de réutiliser le code, deux objectifs. Cependant, un autre avantage est que ces microservices continueront d'être débogués au fil du temps, ce qui se traduira par un code stable et par une réduction globale des coûts de maintenance.

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 que des frais ne vous soient facturés. La plate-forme App Engine dispose d'un quota sans frais. Vous ne serez donc pas facturé tant que vous ne dépasserez pas son niveau d'utilisation. Il en va de même pour Datastore, Pour en savoir plus, consultez la page Tarifs de Cloud Datastore.

Le déploiement sur des plates-formes telles qu'App Engine et Cloud Functions entraîne des coûts minimes de compilation et de stockage. Dans certaines régions, Cloud Build et Cloud Storage disposent de leur propre quota sans frais. Les compilations utilisent une partie de ce quota. Soyez attentif à l'utilisation de votre espace de stockage afin de réduire les coûts potentiels, en particulier si votre région ne propose pas de version sans frais de ce type.

Malheureusement, Cloud Functions n'a pas de fonctionnalité . Sauvegardez votre code et supprimez simplement la fonction. Vous pourrez toujours le redéployer avec le même nom ultérieurement. Toutefois, si vous ne comptez pas continuer avec d'autres ateliers de programmation concernant 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 à étudier 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 Cloud Buildpacks
  • 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 sont axés sur les développeurs et leur explique comment passer des services groupés App Engine à des solutions de remplacement autonomes de Google Cloud:

  • 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

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 plutôt que vers Cloud Functions. Consultez le module 4 pour intégrer votre application dans un conteneur à l'aide de Docker, ou le module 5 pour le faire sans conteneurs, ni connaissances de Docker, ni paramètres Dockerfile. Qu'il s'agisse de Cloud Functions ou de Cloud Run, 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

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 de dépôt des modules 8 (START) et 9 (FINISH). Vous pouvez également y accéder à partir du dépôt de toutes les migrations de l'atelier de programmation App Engine que vous pouvez cloner ou télécharger sous forme de fichier ZIP.

Atelier de programmation

Python 3

Module 2

code

Module 11

code

Ressources en ligne

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

App Engine

Cloud Functions

Autres informations sur le cloud

Vidéos

Licence

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