Cette page explique comment migrer des environnements d'exécution PHP de la première à la deuxième génération. Pour mettre à jour votre application de deuxième génération afin qu'elle utilise la dernière version compatible de PHP, consultez la page Mettre à niveau une application existante.
PHP 5 n'est plus compatible depuis le 30 janvier 2024. Vos applications PHP 5 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 l'environnement d'exécution PHP en suivant les instructions de cette page.
La migration vers un environnement d'exécution PHP de deuxième génération compatible vous permet d'utiliser des fonctionnalités de langage à jour et de créer des applications plus portables, avec du code idiomatique.
Problèmes de compatibilité entre PHP 5.5 et les environnements d'exécution PHP de deuxième génération
La documentation officielle de PHP fournit des informations sur les migrations à partir de différentes versions de PHP :
- Migration de PHP 5.5.x vers PHP 5.6.x
- Migration de PHP 5.6.x vers PHP 7.0.x
- Migration de PHP 7.0.x vers PHP 7.1.x
- Migration de PHP 7.1.x vers PHP 7.2.x
- Migration de PHP 7.2.x vers PHP 7.3.x
- Migration de PHP 7.3.x vers PHP 7.4.x
- Migration de PHP 7.4.x vers PHP 8.0.x
- Migration de PHP 8.0.x vers PHP 8.1.x
Principales différences entre PHP 5.5 et les environnements d'exécution PHP de deuxième génération
Voici un récapitulatif des différences entre les environnements d'exécution PHP 5.5 et PHP de deuxième génération dans l'environnement standard App Engine :
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.
Migrer votre fichier app.yaml
Vous devez placer un contrôleur frontal pour gérer tout le routage de votre application. Pour en savoir plus, consultez la section Démarrage de l'application.
Les environnements d'exécution PHP de deuxième génération ne permettent pas de personnaliser l'élément de gestionnaire script. La seule valeur valide est auto, car l'intégralité du trafic est diffusée à l'aide de la commande "entrypoint". Tous les gestionnaires d'URL non statiques doivent inclure script: auto pour se déployer correctement.
Le comportement de certains éléments du fichier de configuration app.yaml a été modifié :
| Élément | Type de modification | Description |
|---|---|---|
entrypoint | Ajouts | Facultatif. Utilisez ce champ pour spécifier la commande à exécuter au démarrage de votre application. |
threadsafe | Obsolète | Toutes les applications sont supposées être "threadsafe", ce qui signifie qu'une instance peut gérer plusieurs requêtes en même temps. |
api_version | Obsolète | Auparavant obligatoire, mais non requis dans les environnements d'exécution PHP de deuxième génération. |
application_readable | Obsolète | |
builtins | Obsolète | |
libraries | Obsolète | Les dépendances tierces arbitraires peuvent être installées à l'aide d'un fichier de métadonnées composer.json. |
handlers | Modifié |
|
Si vous utilisez l'un des champs obsolètes, une erreur se produira lors du déploiement de l'application.
Pour en savoir plus, consultez la documentation de référence sur app.yaml.
Restrictions d'environnement d'exécution réduites
Les environnements d'exécution PHP de deuxième génération présentent moins de restrictions que l'environnement d'exécution PHP 5.5.
- Vous pouvez installer des dépendances tierces.
- L'environnement d'exécution comprend un système de fichiers complet.
- Vous pouvez créer des processus ou des threads en arrière-plan qui existent au-delà du champ d'application de la requête pendant l'exécution de l'instance.
- Utilisez la bibliothèque cliente Google Cloud pour PHP afin d'intégrer des applications à d'autres services Google Cloud. Pour en savoir plus, consultez la page Installer la bibliothèque cliente Google Cloud.
Pour en savoir plus, consultez la page Environnement d'exécution PHP.
Effectuer une migration à partir du SDK PHP App Engine
Pour réduire la complexité et les efforts liés à la migration, l'environnement standard App Engine vous permet d'accéder à de nombreux anciens services et API groupés dans les environnements d'exécution PHP de deuxième génération, tels que Memcache. Votre application PHP de deuxième génération peut appeler les API de services groupés via le SDK App Engine et accéder à la plupart des fonctionnalités de l'environnement d'exécution PHP 5. Les anciens services groupés disponibles pour PHP 5 ne disposent pas tous d'un service correspondant dans les environnements d'exécution PHP de deuxième génération. Pour obtenir la liste complète des API des anciens services groupés disponibles pour les environnements d'exécution PHP de deuxième génération, consultez la documentation de référence des API des anciens services groupés.
Vous avez également la possibilité d'utiliser des produits Google Cloud qui offrent des fonctionnalités similaires aux anciens services groupés. Ces produits Google Cloud fournissent une bibliothèque cliente Google Cloud CLI idiomatique. Pour les anciens services groupés qui ne sont pas disponibles en tant que produits distincts dans Google Cloud, tels que la recherche, vous pouvez faire appel à des fournisseurs tiers ou à d'autres solutions. Pour en savoir plus sur la migration vers des services non groupés, consultez la page Effectuer la migration à partir de services groupés.
Exécuter votre application en local
Pour tester votre application et l'exécuter localement, procédez comme suit :
Installez localement une version de PHP correspondant à un environnement d'exécution PHP de deuxième génération disponible dans l'environnement standard App Engine.
Installez un serveur Web et utilisez-le pour diffuser votre application en local.
Par exemple, démarrez le serveur HTTP en exécutant la commande suivante :
php -S localhost:8080
Affichez ensuite votre application dans le navigateur Web à l'adresse http://localhost:8080.