Migrer vers l'environnement d'exécution Python 3

Python 2.7 n'est plus compatible à partir du 31 janvier 2024. Vos applications Python 2.7 existantes continueront à fonctionner et à recevoir du trafic. Toutefois, App Engine peut bloquer le redéploiement des applications qui utilisent des environnements d'exécution après leur date de fin de compatibilité. Nous vous recommandons de migrer vers la dernière version compatible de Python en suivant les instructions de cette page.

La migration vers l'environnement d'exécution Python 3 vous permet d'utiliser des fonctionnalités de langage à jour et de créer des applications plus portables, avec du code idiomatique. L'environnement d'exécution Python 3 utilise la dernière version de l'interpréteur Python Open Source fourni par Python Software Foundation. Les applications créées dans l'environnement d'exécution Python 3 peuvent utiliser le riche écosystème de packages et de frameworks Python, y compris ceux qui utilisent du code C, en déclarant des dépendances dans un fichier requirements.txt.

Présentation du processus de migration d'un environnement d'exécution

Nous recommandons l'approche incrémentielle suivante pour la migration d'un environnement d'exécution. Elle vous permet de maintenir une application fonctionnelle et testable tout au long du processus :

  1. Mettez à jour votre application pour qu'elle soit compatible avec Python 3.

    Plusieurs solutions sont disponibles pour vous aider à effectuer cette mise à jour. Par exemple, vous pouvez utiliser Six, Python-Future ou Python-Modernize.

    Pour plus d'informations sur cette étape du processus de migration d'un environnement d'exécution, consultez la section Portage du code Python 2 vers Python 3 sur le site de documentation Python Software Foundation.

  2. Choisissez l'une des stratégies de mise en œuvre suivantes pour tout service groupé App Engine utilisé par votre application :

    1. Migrez les anciens services groupés de votre application Python 2 vers des services Google Cloud non groupés, des services tiers ou d'autres solutions de remplacement recommandées.

    2. Continuez à utiliser les anciens services groupés dans vos applications Python 3. Cette approche vous donne la possibilité de passer à des services non regroupés plus tard dans le cycle de migration.

    Assurez-vous de tester votre application après la migration de chaque service.

  3. Préparez les fichiers de configuration App Engine pour l'environnement d'exécution Python 3. Plusieurs modifications importantes ont une incidence sur les paramètres de configuration dans app.yaml. Cela concerne entre autres les points suivants :

    • Les applications sont désormais considérées comme étant "threadsafe" (capacité à fonctionner en mode multithread). Si votre application n'est pas thread-safe, vous devez définir max_concurrent_requests sur 1 dans votre fichier app.yaml. Ce paramètre peut entraîner la création de plus d'instances que nécessaire pour une application thread-safe, générant ainsi des coûts inutiles.

    • Le fichier app.yaml n'achemine plus les requêtes vers vos scripts. Vous devez utiliser un framework Web avec routage intégré à l'application et mettre à jour ou supprimer tous les gestionnaires script dans app.yaml. Pour obtenir un exemple de procédure avec le framework Flask, consultez l'exemple de code du guide de migration App Engine dans GitHub.

      Pour en savoir plus sur la modification de ce fichier et d'autres fichiers de configuration, consultez la section Fichiers de configuration.

  4. Dans les environnements d'exécution de deuxième génération, les journaux d'application ne sont plus imbriqués dans les journaux de requêtes. Des étapes supplémentaires sont nécessaires pour afficher la vue imbriquée des journaux de requêtes et d'applications dans l'explorateur de journaux. Pour en savoir plus, consultez la page Migrer vers Cloud Logging.

  5. Testez et déployez votre application mise à jour dans un environnement Python 3.

    Une fois tous vos tests réussis, déployez l'application mise à niveau sur App Engine, mais empêchez le trafic d'être automatiquement acheminé vers la nouvelle version. Utilisez la répartition du trafic pour migrer progressivement le trafic de votre application dans l'environnement d'exécution Python 2 vers l'application dans l'environnement d'exécution Python 3. Si vous rencontrez des problèmes, vous pouvez acheminer tout le trafic vers une version stable jusqu'à ce que le problème soit résolu.

Pour obtenir des exemples de conversion d'applications Python 2 en Python 3, vous pouvez consulter ces ressources supplémentaires.

Principales différences entre les environnements d'exécution Python 2 et Python 3

La plupart des modifications à effectuer lors de la migration d'un environnement d'exécution sont dues aux différences suivantes entre les environnements d'exécution Python 2 et Python 3 :

Différences d'utilisation de la mémoire

Les environnements d'exécution de deuxième génération présentent une utilisation de référence de la mémoire plus élevée que les environnements d'exécution de première génération. Cela est dû à plusieurs facteurs, tels que les différentes versions d'image de base et les différences dans la manière dont les deux générations calculent l'utilisation de la mémoire.

Dans les environnements d'exécution de deuxième génération, l'utilisation de la mémoire des instances est calculée comme la somme de la mémoire utilisée par un processus d'application et du nombre de fichiers d'application mis en cache de manière dynamique en mémoire. Pour éviter que les applications qui utilisent beaucoup de mémoire ne provoquent des arrêts d'instance en raison du dépassement des limites de mémoire, effectuez une mise à niveau vers une classe d'instance plus grande avec plus de mémoire.

Différences d'utilisation du processeur

Les environnements d'exécution de deuxième génération peuvent constater une utilisation de référence plus élevée lors du démarrage à froid de l'instance. Selon la configuration du scaling d'une application, cela peut avoir des effets secondaires inattendus, tels qu'un nombre d'instances plus élevé que prévu si une application est configurée pour évoluer en fonction de l'utilisation du processeur. Pour éviter ce problème, examinez et testez les configurations de scaling des applications pour vous assurer que le nombre d'instances est acceptable.

Différences au niveau des en-têtes de requête

Les environnements d'exécution de première génération permettent de transmettre à l'application des en-têtes de requêtes comportant des traits de soulignement (par exemple, X-Test-Foo_bar). Les environnements d'exécution de deuxième génération introduisent Nginx dans l'architecture hôte. Suite à cette modification, les environnements d'exécution de deuxième génération sont configurés pour supprimer automatiquement les en-têtes comportant des traits de soulignement (_). Pour éviter les problèmes liés à l'application, évitez d'utiliser des traits de soulignement dans les en-têtes de requête de l'application.

Différences des nœud de calcul Gunicorn

Pour les environnements d'exécution Python 3 et versions ultérieures, le nombre de nœuds de calcul Gunicorn a un impact direct sur l'utilisation de la mémoire. L'augmentation de l'utilisation de la mémoire est directement proportionnelle à celle du nombre de nœuds de calcul. Pour réduire la consommation de mémoire, envisagez de réduire le nombre de nœuds de calcul Gunicorn. Consultez la section Bonnes pratiques relatives à Entrypoint pour obtenir des instructions sur la configuration du nombre de nœuds de calcul Gunicorn.

Problèmes de compatibilité entre Python 2 et Python 3

Lorsque Python 3 a été lancé en 2008, plusieurs modifications incompatibles avec les versions antérieures ont été introduites dans le langage. Certaines de ces modifications ne nécessitent que des mises à jour mineures de votre code, telles que changer l'instruction print en fonction print(). D'autres modifications peuvent nécessiter des mises à jour importantes de votre code, telles que la manière dont vous gérez les données binaires, le texte et les chaînes.

En outre, de nombreuses bibliothèques Open Source largement utilisées, y compris les bibliothèques standards Python, ont été modifiées lors du passage de Python 2 à Python 3.

Services groupés App Engine dans l'environnement d'exécution Python 3

Pour réduire la complexité et les efforts liés à la migration, l'environnement standard App Engine vous permet d'accéder à plusieurs anciens services groupés et API dans l'environnement d'exécution Python 3, tels que Memcache. Votre application Python 3 peut appeler les API des services groupés à l'aide des bibliothèques idiomatiques et accéder aux mêmes fonctionnalités que dans l'environnement d'exécution Python 2.

Vous avez également la possibilité d'utiliser des produits Google Cloud qui offrent des fonctionnalités similaires aux anciens services groupés. Nous vous recommandons de migrer vers les produits Google Cloud non regroupés afin de bénéficier d'améliorations continues et de nouvelles fonctionnalités.

Pour les services groupés qui ne sont pas disponibles séparément dans Google Cloud, tels que le traitement d'image, la recherche et les messages, nous vous suggérons des fournisseurs tiers ou d'autres solutions.

Fichiers de configuration

Avant de pouvoir exécuter votre application dans l'environnement d'exécution Python 3 de l'environnement standard App Engine, vous devrez peut-être modifier certains des fichiers de configuration utilisés par App Engine :

Framework Web nécessaire pour acheminer les requêtes au contenu dynamique

Dans l'environnement d'exécution Python 2, vous pouvez créer des gestionnaires d'URL dans le fichier app.yaml pour spécifier l'application à exécuter lorsqu'une URL ou un format d'URL spécifique est demandé.

Dans l'environnement d'exécution Python 3, votre application doit utiliser un framework Web tel que Flask ou Django pour acheminer les requêtes au contenu dynamique au lieu d'utiliser des gestionnaires d'URL dans app.yaml. Pour le contenu statique, vous pouvez continuer à créer des gestionnaires d'URL dans le fichier app.yaml de votre application.

Applications ne comportant que du contenu statique

Lorsque vous hébergez une application Web statique sur App Engine, vous spécifiez des gestionnaires dans votre fichier app.yaml pour mapper les URL à vos fichiers statiques.

Dans Python 2, si une requête ne correspond à aucun des gestionnaires spécifiés dans le fichier app.yaml, App Engine renvoie un code d'erreur 404.

Dans Python 3, si une requête ne correspond à aucun des gestionnaires, App Engine recherche un fichier main.py et renvoie une erreur 5xx si aucun fichier main.py n'est identifié. Comme les applications App Engine ne comportant que du contenu statique ne nécessitent pas de fichier main.py, cette erreur s'affiche pour la plupart des utilisateurs, en plus des erreurs de démarrage d'instance dans les journaux d'application.

Pour conserver le comportement d'émission d'une erreur 404 en cas de non-correspondance des gestionnaires statiques, et pour éviter des erreurs dans les journaux, vous pouvez employer l'une des méthodes suivantes :

  • Ajouter un gestionnaire statique fourre-tout pointant vers un répertoire vide dans le fichier app.yaml.
  • Ajouter une application dynamique simple dans le fichier main.py pour renvoyer une erreur 404.

Exemples d'utilisation de l'une ou l'autre de ces options :

app.yaml

Créez un répertoire vide dans le répertoire racine de l'application, tel que empty/. Dans la section du fichier app.yaml dédiée aux gestionnaires de fichiers, créez un gestionnaire tout à la fin afin d'intercepter tous les autres formats d'URL, puis spécifiez le répertoire empty dans les éléments static_files et upload :

  handlers:
  - url:
    .
    .
    .
  - url: /(.*)$
    static_files: empty/\1
    upload: empty/.*$

main.py

Créez un fichier main.py et ajoutez le code suivant pour renvoyer une erreur 404 :

  def app(env, start_response):
    start_response('404 Not Found', [('Content-Type','text/html')])
    return [b"Not Found"]

Tests

Nous vous recommandons d'appliquer une approche de test idiomatique pour Python plutôt que de dépendre de dev_appserver. Par exemple, vous pouvez utiliser venv pour créer un environnement local Python 3 isolé. N'importe quel framework de test Python standard peut être utilisé pour écrire vos tests unitaires, d'intégration et système. Vous pouvez également choisir de configurer des versions de développement de vos services ou d'utiliser les émulateurs locaux disponibles pour de nombreux produits Google Cloud.

Vous pouvez éventuellement utiliser la version bêta de dev_appserver, qui est compatible avec Python 3. Pour en savoir plus sur cette fonctionnalité de test, consultez la page Utiliser le serveur de développement local.

Déploiement…

Python 3 n'accepte pas les déploiements effectués à l'aide de la commande appcfg.py. Utilisez l'outil de ligne de commande gcloud pour déployer votre application.

Logging

La journalisation dans l'environnement d'exécution Python 3 suit la norme de journalisation dans Cloud Logging. Dans l'environnement d'exécution Python 3, les journaux d'application ne sont plus regroupés avec les journaux de requêtes, mais sont séparés dans des enregistrements différents. Pour en savoir plus sur la lecture et l'écriture des journaux dans l'environnement d'exécution Python 3, consultez le guide de journalisation.

Autres ressources de migration

Pour en savoir plus sur la migration de vos applications App Engine vers des services Cloud autonomes ou l'environnement d'exécution Python 3, vous pouvez consulter les ressources App Engine suivantes :