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 à suivre à votre rythme) est destinée à aider les développeurs Google App Engine (standard) à moderniser leurs applications en les guidant tout au long 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 explique comment conteneuriser des applications App Engine afin de les déployer sur le service entièrement géré Cloud Run en utilisant Cloud Buildpacks, une alternative à Docker. Les buildpacks Cloud conteneurisent vos applications sans que vous ayez à gérer les fichiers Dockerfile ni même à connaître Docker.

Cet atelier de programmation s'adresse aux développeurs Python 2 App Engine qui ont migré leurs applications depuis les services intégrés d'origine vers Python 3 et qui souhaitent désormais les exécuter dans un conteneur. L'atelier de programmation COMMENCE avec une application Python 3 du module 2 ou du module 3 terminée.

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 ?

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

2. Arrière-plan

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 et à gérer un serveur Web, y compris à 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'un exemple d'application fonctionnel du Module 2 ou 3. 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 ces tutoriels, vous pouvez récupérer le code de l'un d'eux ci-dessous.

Que vous utilisiez votre application ou la nôtre, c'est là que ce tutoriel commence. Cet atelier de programmation vous guide tout au long de la migration. À la fin, votre code devrait correspondre à celui du dossier FINISH du dépôt du module 5.

Le répertoire des fichiers START (qu'il s'agisse de votre code ou du nôtre) 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 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.

Si vous ne souhaitez pas en savoir plus sur Docker et que vous voulez conteneuriser votre application App Engine pour l'exécuter sur Cloud Run ou toute autre plate-forme d'hébergement de conteneurs, vous êtes au bon endroit. Si vous souhaitez apprendre à utiliser Docker pour la conteneurisation d'applications, vous pouvez suivre l'atelier de programmation du module 4 après celui-ci. Il est identique à celui-ci, mais 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 à la colonne des packs de création Google Cloud (et éventuellement à la colonne 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 similaire à celui de la directive app.yaml entrypoint. Pour notre application exemple, notre Procfile exécutera 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 de Cloud Run.

Il vous suffit de déplacer votre directive app.yaml entrypoint dans un Procfile. Si vous n'en avez pas, utilisez le serveur de développement Flask pour le moment, car il s'agit simplement d'un exemple d'application de test pour 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 consulter le service.yaml généré automatiquement en accédant à 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

Le fichier requirements.txt n'a pas besoin d'être modifié. Flask doit y ê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

Les buildpacks ne sont pas compatibles avec Python 2. Nous n'aborderons donc pas ce point ici. Les applications Python 3 s'exécutant dans des conteneurs sur Cloud Run sont semblables aux applications Python 3 App Engine, car 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. Pour résumer l'emplacement d'une instruction "entrypoint" entre les deux plates-formes : cela se traduit directement par ce qui suit, en indiquant également l'équivalent Docker pour 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éparation, il est facile d'exécuter le serveur de développement Flask à partir de Python comme nous l'avons fait ci-dessus, mais les développeurs peuvent opter pour quelque chose de plus puissant pour la production, comme l'exemple 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 des fichiers sources effectuées, vous êtes prêt à exécuter votre conteneur 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 l'utilisez, assurez-vous d'utiliser le même nom de service SVC_NAME et le nom REGION souhaité plutôt que la sélection de menu indexée comme nous l'avons fait précédemment de manière interactive.

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 doit maintenant correspondre à celui du dossier du dépôt du module 5. Bravo ! Vous avez terminé l'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 sans frais, votre utilisation de Datastore vous sera facturée. Supprimez donc 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é. Vous pouvez maintenant découvrir comment faire la même chose avec Docker dans l'atelier de programmation du module 4 (lien ci-dessous), ou comment 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

Vous trouverez dans le tableau ci-dessous des liens vers les dossiers de dépôt correspondant aux modules 2 et 3 ("START") ainsi qu'au module 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 :