Module 5: Migrer de Google App Engine vers Cloud Run à l'aide de Cloud Buildpacks

1. Présentation

Cette série d'ateliers de programmation (tutoriels pratiques et d'auto-formation) vise à aider les développeurs Google App Engine (standard) à moderniser leurs applications en les guidant lors d'une série de migrations. Une fois l'opération effectuée, les utilisateurs peuvent rendre leurs applications plus portables en les conteneurisant pour Cloud Run, le service d'hébergement de conteneurs de Google Cloud étroitement lié à App Engine, ainsi que pour d'autres services d'hébergement de conteneurs.

Ce tutoriel vous explique comment conteneuriser des applications App Engine pour les déployer sur le service entièrement géré Cloud Run à l'aide de Cloud Buildpacks, une alternative à Docker. Les buildpacks Cloud permettent de conteneuriser vos applications sans gérer les fichiers Dockerfile ni même savoir quoi que ce soit sur Docker.

Cet atelier de programmation est destiné aux développeurs Python 2 App Engine qui ont déplacé leurs applications depuis les services intégrés d'origine vers Python 3, et qui souhaitent maintenant les exécuter dans un conteneur. L'atelier de programmation commence par une application Python 3 terminée dans le module 2 ou dans le module 3.

Vous apprendrez à effectuer les tâches suivantes :

  • Conteneuriser votre application à l'aide de Cloud Buildpacks
  • Déployer des images de conteneur dans Cloud Run.

Prérequis

Enquête

Comment allez-vous utiliser cet atelier de programmation ?

<ph type="x-smartling-placeholder"></ph> Je vous invite à le lire uniquement Je vais le lire et effectuer les exercices .

2. Contexte

Les systèmes PaaS tels qu'App Engine et Cloud Functions offrent de nombreux avantages pour vos équipes et vos applications. Par exemple, ces plates-formes sans serveur permettent aux équipes SysAdmin/Devops de se concentrer sur la création de solutions. Votre application peut être rédigée dans de nombreux langages de développement courants et é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.

La flexibilité des conteneurs est un autre atout majeur avec la capacité d'utiliser n'importe quel langage, n'importe quelle bibliothèque et n'importe quels binaires. Découvrez Google Cloud Run pour offrir aux utilisateurs le meilleur des deux mondes, les avantages de la technologie sans serveur et la flexibilité des conteneurs.

Apprendre à utiliser Cloud Run dépasse le cadre du présent atelier de programmation. Pour cela, consultez la documentation de Cloud Run. L'objectif ici est de vous indiquer comment conteneuriser votre application App Engine pour Cloud Run (ou d'autres services). Avant de continuer, vous devez comprendre que votre expérience utilisateur sera légèrement différente. Effectivement, le travail se fait à un niveau plus bas et il n'est plus nécessaire de manipuler et de déployer le code d'application.

Au lieu de cela, vous devez apprendre à mieux connaître les conteneurs, notamment la compilation et le déploiement. Vous devez également décider des éléments à inclure dans l'image de conteneur, y compris un serveur Web car vous n'utiliserez plus le serveur Web d'App Engine. Si vous ne souhaitez pas fonctionner de cette manière, conserver vos applications sur App Engine n'est pas un mauvais choix.

Dans ce tutoriel, vous allez apprendre à conteneuriser votre application, à supprimer les fichiers de configuration App Engine, à gérer un serveur Web et, entre autres, à démarrer votre application.

La migration comprend les étapes suivantes :

  1. Configuration/Préparation
  2. Conteneuriser l'application
    • Remplacer les fichiers de configuration
    • Modifier les fichiers d'application

3. Configuration/Préparation

Avant de passer à la partie principale de ce tutoriel, nous allons configurer notre projet, obtenir le code et déployer l'application de base pour nous assurer de bien utiliser du code fonctionnel.

1. Configurer le projet

Si vous avez suivi les ateliers de programmation Module 2 ou Module 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 App Engine (app) 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 ou 3 qui fonctionne. Si vous n'en avez pas, nous vous recommandons de suivre l'un ou l'autre des didacticiels (liens ci-dessus) avant de poursuivre. Si vous connaissez déjà leur contenu, vous pouvez simplement commencer par récupérer l'un de leurs dossiers de code ci-dessous.

Que vous utilisiez le vôtre ou le nôtre, c'est là que ce didacticiel commence. Cet atelier de programmation vous explique comment effectuer la migration. Une fois la migration terminée, elle devrait correspondre essentiellement au contenu du dossier du dépôt FINISH du module 5.

Le répertoire des fichiers START (les vôtres ou les nôtres) devrait ressembler à ceci:

$ 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 à conteneuriser l'application.

4. Conteneuriser l'application

Docker est aujourd'hui la plate-forme de conteneurisation standard dans le secteur. Comme indiqué précédemment, l'un des défis de l'utilisation de Docker est qu'il faut faire beaucoup d'efforts pour créer et entretenir un bon Dockerfile (le fichier de configuration qui détermine la façon dont vos images de conteneurs sont créées). En revanche, les packs de création nécessitent peu d'efforts car ils utilisent l'introspection pour déterminer les dépendances de votre application et optimiser le conteneur au mieux pour votre application.

Vous êtes au bon endroit si vous ne voulez pas vous familiariser avec Docker et souhaitez conteneuriser votre application App Engine afin de l'exécuter sur Cloud Run ou toute autre plate-forme d'hébergement de conteneurs. Si vous souhaitez apprendre à utiliser Docker pour la conteneurisation d'applications, vous pouvez suivre l'atelier de programmation du module 4 une fois celui-ci terminé. Il est identique à celui-ci, mais il utilise Docker pour vous permettre de mieux comprendre comment gérer les images de conteneurs.

La procédure de migration comprend le remplacement des fichiers de configuration App Engine et la spécification de démarrage de votre application. Le tableau ci-dessous récapitule les fichiers de configuration requis pour chaque type de plate-forme. Comparez la colonne App Engine avec la colonne Buildpacks (et éventuellement Docker):

Description

App Engine

Docker

Buildpacks

Configuration générale

app.yaml

Dockerfile

(service.yaml)

Bibliothèques tierces

requirements.txt

requirements.txt

requirements.txt

Configuration tierce

app.yaml (plus appengine_config.py et lib [2.x uniquement])

(n/a)

(n/a)

Démarrage

(n/a) ou app.yaml (si entrypoint est utilisé)

Dockerfile

Procfile

Ignorer les fichiers

.gcloudignore et .gitignore

.gcloudignore, .gitignore et .dockerignore

.gcloudignore et .gitignore

Une fois votre application en conteneur, elle peut être déployée dans Cloud Run. Parmi les autres options de plate-forme de conteneur Google Cloud figurent Compute Engine, GKE et Anthos.

Configuration générale

App Engine démarre automatiquement votre application mais ce n'est pas le cas de Cloud Run. Procfile joue un rôle semblable à celui de la directive app.yaml entrypoint. Pour notre exemple d'application, notre Procfile exécute python main.py pour démarrer le serveur de développement Flask. Si vous le souhaitez, vous pouvez également utiliser un serveur Web de production comme gunicorn. Dans ce cas, veillez à l'ajouter à requirements.txt. Pour en savoir plus sur le déploiement à partir du code source à l'aide de Buildpacks, consultez cette page de documentation Cloud Run.

Il vous suffit de déplacer la directive app.yaml entrypoint dans une Procfile. Si vous n'en avez pas, utilisez le serveur de développement Flask pour l'instant. Il s'agit d'un exemple d'application de test permettant de familiariser les utilisateurs avec cette migration. Votre application sera une commande de démarrage spécifique que vous connaissez le mieux. En coulisses, le service Cloud Run crée un service.yaml qui ressemble davantage à un app.yaml. Vous pouvez voir le service.yaml généré automatiquement en cliquant sur un lien comme celui-ci, mais pour votre service SVC_NAME et REGION: https://console.cloud.google.com/run/detail/REGION/SVC_NAME/yaml/view.

Bibliothèques tierces

Il n'est pas nécessaire de modifier le fichier requirements.txt. Flask doit être présent avec votre bibliothèque cliente Datastore (Cloud Datastore ou Cloud NDB). Si vous souhaitez utiliser un autre serveur HTTP compatible WSGI tel que Gunicorn (la version à jour au moment de la rédaction de cet article est la 20.0.4), ajoutez gunicorn==20.0.4 au fichier requirements.txt.

Configuration tierce

Buildpacks n'étant pas compatible avec Python 2, nous n'en parlerons pas ici. Les applications Python 3 exécutées dans des conteneurs sur Cloud Run sont semblables aux applications App Engine Python 3, dans la mesure où les bibliothèques tierces doivent être spécifiées dans requirements.txt.

Démarrage

Les utilisateurs de Python 3 ont la possibilité de convertir leurs fichiers app.yaml de manière à utiliser un entrypoint plutôt que des directives script: auto dans leur section handlers. Si vous utilisez un entrypoint dans votre fichier app.yaml Python 3, il doit ressembler à ce qui suit :

runtime: python38
entrypoint: python main.py

L'instruction entrypoint indique à App Engine comment démarrer le serveur. Vous pouvez le déplacer presque directement dans votre Procfile. Résumer l'emplacement d'une directive de point d'entrée entre les deux plates-formes: cela se traduit directement par ce qui suit. montrant également l'équivalent Docker à titre d'information:

  • Packs de création Google Cloud : ligne dans Procfile : web: python main.py
  • Docker : ligne dans Dockerfile : ENTRYPOINT ["python", "main.py"]

Pour les tests et la préproduction, il est facile d'exécuter le serveur de développement de Flask à partir de Python comme indiqué ci-dessus. Toutefois, les développeurs peuvent opter pour une solution plus puissante pour la production, comme l'exemple de guide de démarrage rapide Cloud Run qui utilise gunicorn.

Dossiers d'application

Toutes les applications du module 2 et du module 3 sont entièrement compatibles avec Python 2 et 3, ce qui signifie qu'il n'y a pas de modification des composants de base du fichier main.py. Nous n'ajouterons que quelques lignes de code de démarrage. Ajoutez deux lignes en bas de main.py pour démarrer le serveur de développement car Cloud Run nécessite d'ouvrir le port 8080 pour pouvoir appeler votre application :

if __name__ == '__main__':
    import os
    app.run(debug=True, threaded=True, host='0.0.0.0',
            port=int(os.environ.get('PORT', 8080)))

5. Migration Build and Deploy

Une fois votre configuration App Engine remplacée par des Buildpacks et les mises à jour de fichiers sources terminées, vous pouvez l'exécuter sur Cloud Run. Mais avant cela, parlons brièvement des services.

Services ou applications

Bien qu'App Engine ait été créé principalement pour héberger des applications, il s'agit également d'une plate-forme permettant d'héberger des services Web ou des applications composées d'un ensemble de microservices. Dans Cloud Run, tout est un service, qu'il s'agisse d'un service réel ou d'une application dotée d'une interface Web. Nous vous recommandons donc de penser en termes de services plutôt qu'en termes d'applications.

À moins que votre application App Engine ne soit constituée de plusieurs services, vous n'avez pas à effectuer de dénomination particulière lors du déploiement de vos applications. Cela change dans Cloud Run, car vous devez trouver un nom de service. Le domaine appspot.com d'App Engine inclut l'ID de projet, par exemple https://PROJECT_ID.appspot.com, et parfois une abréviation de l'ID de région, par exemple http://PROJECT_ID.REGION_ID.r.appspot.com.

Le domaine d'un service Cloud Run inclut le nom du service, l'abréviation de région et une valeur de hachage, mais pas l'ID de projet, par exemple https://SVC_NAME-HASH-REG_ABBR.a.run.app. En résumé, commencez dès à présent à réfléchir à un nom de service !

Déployer le service

Exécutez la commande ci-dessous pour compiler votre image de conteneur et la déployer dans Cloud Run. Lorsque vous y êtes invité, sélectionnez votre région et autorisez les connexions non authentifiées pour faciliter les tests puis choisissez une région appropriée, où SVC_NAME est le nom du service que vous déployez.

$ gcloud run deploy SVC_NAME --source .
Please choose a target platform:
 [1] Cloud Run (fully managed)
 [2] Cloud Run for Anthos deployed on Google Cloud
 [3] Cloud Run for Anthos deployed on VMware
 [4] cancel
Please enter your numeric choice:  1

To specify the platform yourself, pass `--platform managed`. Or, to make this the default target platform, run `gcloud config set run/platform managed`.

Please specify a region:
 [1] asia-east1
 [2] asia-east2
 [3] asia-northeast1
 [4] asia-northeast2
 [5] asia-northeast3
 [6] asia-south1
 [7] asia-southeast1
 [8] asia-southeast2
 [9] australia-southeast1
 [10] europe-north1
 [11] europe-west1
 [12] europe-west2
 [13] europe-west3
 [14] europe-west4
 [15] europe-west6
 [16] northamerica-northeast1
 [17] southamerica-east1
 [18] us-central1
 [19] us-east1
 [20] us-east4
 [21] us-west1
 [22] us-west2
 [23] us-west3
 [24] us-west4
 [25] cancel
Please enter your numeric choice: <select your numeric region choice>

To make this the default region, run `gcloud config set run/region REGION`.

Allow unauthenticated invocations to [SVC_NAME] (y/N)?  y

Building using Buildpacks and deploying container to Cloud Run service [SVC_NAME] in project [PROJECT_ID] region [REGION]
✓ Building and deploying... Done.
  ✓ Uploading sources...
  ✓ Building Container... Logs are available at [https://console.cloud.google.com/cloud-build/builds/BUILD-HASH?project=PROJECT_NUM].
  ✓ Creating Revision...
  ✓ Routing traffic...
Done.
Service [SVC_NAME] revision [SVC_NAME-00014-soc] has been deployed and is serving 100 percent of traffic.
Service URL: https://SVC_NAME-HASH-REG_ABBR.a.run.app

Accédez à l'URL spécifiée avec votre navigateur pour vérifier que le déploiement a bien réussi.

Comme l'indique la commande gcloud, les utilisateurs peuvent définir divers paramètres par défaut pour réduire la sortie et l'interactivité, comme illustré ci-dessus. Par exemple, pour éviter toutes les interactions, vous pouvez utiliser la commande de déploiement en une ligne suivante :

$ gcloud beta run deploy SVC_NAME --source . --platform managed --region REGION --allow-unauthenticated

Si vous utilisez celui-ci, veillez à sélectionner le même nom de service SVC_NAME et le nom REGION souhaité, et non la sélection du menu indexé comme nous l'avons fait de manière interactive ci-dessus.

6. Résumé/Nettoyage

Vérifiez que l'application fonctionne aussi bien sur Cloud Run que dans App Engine. Si vous avez consulté cette série sans suivre les ateliers de programmation précédents, l'application elle-même ne change pas. Elle enregistre toutes les visites sur la page Web principale (/) et ressemble à ceci une fois que vous avez consulté le site suffisamment de fois :

Application Visitme

Votre code devrait maintenant correspondre à ce qui se trouve dans le dossier du dépôt du module 5. Félicitations, vous avez terminé cet atelier de programmation du module 5.

Facultatif : Effectuer un nettoyage

Que diriez-vous d'un bon nettoyage pour éviter que des frais vous soient facturés tant que vous n'êtes pas prêt à passer à l'atelier de programmation suivant sur la migration ? Comme vous utilisez maintenant un autre produit, consultez la grille tarifaire de Cloud Run.

Facultatif : désactiver le service

Si vous n'êtes pas encore prêt à passer au tutoriel suivant, désactivez votre service pour éviter des frais supplémentaires. Lorsque vous serez prêt à passer au prochain atelier de programmation, vous pourrez le réactiver. Tant que votre application est désactivée, elle ne génère aucun trafic, donc aucuns frais. Toutefois, si vous dépassez le quota gratuit, votre utilisation de Datastore vous sera facturée alors supprimez suffisamment d'éléments pour rester dans la limite.

En revanche, si vous ne souhaitez pas poursuivre vos migrations et que vous souhaitez tout supprimer complètement, vous pouvez supprimer votre service ou arrêter le projet complètement.

Étapes suivantes

Félicitations ! Vous venez de conteneuriser votre application et ce tutoriel est désormais terminé. L'étape suivante consiste à apprendre à réaliser la même opération avec Docker dans l'atelier de programmation du module 4 (lien ci-dessous) ou à effectuer une autre migration App Engine:

  • Module 4 : Migrer vers Cloud Run avec Docker
    • Conteneurisez votre application pour l'exécuter sur Cloud Run avec Docker.
    • Cela vous permet de continuer d'utiliser Python 2.
  • Module 7 : files d'attente d'envoi de tâches App Engine (obligatoire si vous utilisez des files d'attente de tâches d'envoi de tâches [push])
    • Ajoutez des tâches push taskqueue App Engine à l'application du module 1.
    • Préparez les utilisateurs à migrer vers Cloud Tasks dans le module 8.
  • Module 3 :
    • Modernisez l'accès au Datastore en passant de Cloud NDB à Cloud Datastore.
    • Il s'agit de la bibliothèque utilisée pour les applications Python 3 App Engine ou autres.
  • Module 6 : Migrer vers Cloud Firestore
    • Migrer vers Cloud Firestore pour utiliser les fonctionnalités de Firebase.
    • Bien que Cloud Firestore soit compatible avec Python 2, cet atelier de programmation n'est disponible que pour Python 3.

7. 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 2 et 3 (START) et 5 (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 2

code

(code)

Module 3

(code)

code

Module 5

(n/a)

code

Ressources App Engine et Cloud Run

Vous trouverez ci-dessous d'autres ressources concernant cette migration spécifique :