InMy.Live

Publié par Wesley Chun (@wescpy), avocat développeur, Google Cloud

Comprendre la migration globale

Dans l’ensemble, le module 21 apporte des modifications majeures à l’exemple d’application du module 20, mettant en œuvre une transition des services groupés App Engine (NDB et utilisateurs) vers des services cloud autonomes (Cloud Datastore et Identity Platform). Identity Platform ne sait rien des administrateurs d’App Engine. Il doit donc être créé, ce qui nécessite l’utilisation du API du gestionnaire de ressources cloud. Les applications dépendant de Python 2 ont des mises à jour supplémentaires requises. Discutons un peu plus en détail.

Migration “parties”

Les modifications suivantes doivent être apportées à l’exemple d’application :

• Migrer des utilisateurs d’App Engine (côté serveur) vers Cloud Identity Platform (côté client)

• Migrer d’App Engine NDB, l’autre service groupé utilisé dans le module 20, vers Cloud NDB (nécessite l’utilisation de l’API Cloud Datastore)
• Utilisez Cloud Resource Manager* (via son API) pour récupérer la stratégie d’autorisation IAM du projet Cloud afin de rassembler l’ensemble d’utilisateurs administrateurs App Engine pour l’application.
• Utiliser le SDK Firebase Admin pour vérifier si l’utilisateur est un administrateur App Engine
• Migrer de Python 2 à 3 (et éventuellement revenir à Python 2 [more on this below])

*Au moment d’écrire ces lignes, la documentation Resource Manager ne contient que des instructions de configuration pour accéder à l’API à partir de la bibliothèque cliente des API Google de niveau inférieur plutôt qu’à partir de la bibliothèque cliente Resource Manager. Pour savoir comment paramétrer cette dernière, rendez-vous directement dans la documentation de la bibliothèque cliente Resource Manager. La bibliothèque cliente de niveau inférieur ne doit être utilisée que dans des circonstances où une bibliothèque cliente Cloud n’existe pas ou ne dispose pas des fonctionnalités dont votre application a besoin. L’un de ces cas d’utilisation est Python 2, et nous le couvrirons sous peu.

Passer des services groupés App Engine aux services cloud autonomes

La migration NDB vers Cloud NDB est identique au contenu de la migration du module 2, elle n’est donc pas traitée en profondeur ici dans le module 21. L’objectif principal est de passer à Identity Platform pour continuer à prendre en charge les connexions des utilisateurs ainsi que la mise en œuvre de l’utilisation du gestionnaire de ressources. et Firebase Admin SDK pour créer un proxy permettant de reconnaître les utilisateurs administrateurs d’App Engine tels qu’ils sont fournis par le service Users. Vous trouverez ci-dessous un pseudocode implémentant les modifications clés apportées à l’application principale où des lignes de code nouvelles ou mises à jour sont en gras:

Les principales différences à noter :

1. Le code de service Utilisateurs côté serveur disparaît de l’application principale, se déplaçant dans le modèle Web (côté client) (non illustré ici).
2. Pratiquement tout le nouveau code de l’application Module 21 ci-dessus sert à reconnaître les utilisateurs administrateurs d’App Engine. Il n’y a aucune modification des opérations d’application ou des modèles de données autres que Cloud NDB nécessitant l’utilisation de gestionnaires de contexte Python pour encapsuler tout le code Datastore (à l’aide de Python avec blocs).

Les versions complètes de l’application avant et après les mises à jour se trouvent respectivement dans les dossiers de dépôt Module 20 (Python 2) et Module 21 (Python 3). En plus de la vidéo, assurez-vous de consulter la documentation d’Identity Platform ainsi que l’atelier de programmation du module 21 qui vous guide pas à pas à travers les migrations abordées.

Outre les changements de codage nécessaires ainsi que le passage du côté serveur au côté client, notez que l’utilisation du service Users est couverte par le modèle de tarification d’App Engine, tandis qu’Identity Platform est un service cloud indépendant facturé par les MAU (utilisateurs actifs mensuels). les coûts doivent être pris en compte en cas de migration. Pour plus d’informations, consultez la documentation sur les tarifs d’Identity Platform.

Considérations Python 2

Avec l’arrêt de Python 2, Java 8, PHP 5 et Go 1.11, par leurs communautés respectives, Google Cloud a rassuré les utilisateurs en exprimant une prise en charge continue à long terme de ces anciens environnements d’exécution App Engine, y compris la maintenance de l’environnement d’exécution Python 2. Ainsi, bien qu’il n’y ait actuellement aucune obligation pour les utilisateurs de migrer, les développeurs eux-mêmes expriment leur intérêt pour la mise à jour de leurs applications vers les dernières versions linguistiques.
La migration principale du module 21 inclut automatiquement un port de Python 2 à 3, car c’est là que la plupart des développeurs se dirigent. Pour ceux qui ont des dépendances nécessitant de rester sur Python 2, un effort supplémentaire est requis :

Le codelab couvre ce backport en profondeur, alors consultez la section spécifique pour les utilisateurs de Python 2 si vous êtes dans cette situation. Si vous ne voulez pas y penser, dirigez-vous simplement vers le référentiel pour une version Python 2 fonctionnelle de l’application Module 21.