Environnement d'exécution PHP 5

Avec App Engine, vous pouvez créer des applications Web à l'aide du langage de programmation PHP. Votre application PHP s'exécute sur l'infrastructure évolutive de Google, et utilise ses services et son espace de stockage persistant à grande échelle.

Sélectionner l'environnement d'exécution PHP

App Engine exécute votre application Web PHP à l'aide d'un interpréteur PHP version 5.5.34. Remarque : Sous Linux, vous devez également installer PHP localement pour exécuter vos applications PHP.

Pour que votre application utilise l'environnement d'exécution PHP, ajoutez les éléments suivants à votre fichier app.yaml :

runtime: php55
api_version: 1
...

Le premier élément, runtime, sélectionne l'environnement d'exécution PHP.

Le second élément, api_version, sélectionne la version de l'environnement d'exécution PHP à utiliser. Au moment de la rédaction de cette section, App Engine dispose d'une seule version de l'environnement PHP, 1. Si des modifications ultérieures risquent de ne pas être rétrocompatibles, l'équipe App Engine utilisera un nouvel identifiant de version. Votre application continuera à utiliser la version sélectionnée jusqu'à ce que vous modifiiez le paramètre api_version et transfériez votre application.

Pour plus d'informations sur le fichier app.yaml et le déploiement de votre application sur App Engine, consultez la documentation de référence sur app.yaml et la documentation sur le déploiement d'une application PHP.

Bac à sable

Pour qu'App Engine puisse distribuer des requêtes aux applications sur plusieurs serveurs Web, et pour éviter qu'une application n'interfère avec une autre, l'application s'exécute dans un environnement de "bac à sable" restreint. Dans cet environnement, l'application peut exécuter du code, utiliser la messagerie App Engine ainsi que les services de récupération d'URL et d'utilisateurs, examiner la requête Web de l'utilisateur et préparer la réponse.

Une application App Engine ne peut pas effectuer les actions suivantes :

  • Écrire sur le système de fichiers. Les applications PHP peuvent utiliser Google Cloud Storage pour stocker des fichiers persistants. La lecture à partir du système de fichiers est autorisée, et tous les fichiers transférés avec l'application sont disponibles.

  • répondre lentement. Une requête Web vers une application doit être traitée en quelques secondes. Les processus qui mettent trop de temps à répondre sont interrompus afin d'éviter de surcharger le serveur Web ;

  • Effectuer d'autres types d'appels système.

Chargement automatique des classes

Les classes SPL (Standard PHP Library) et toutes les classes faisant partie du SDK pour App Engine sont automatiquement chargées en cas de besoin. Cela signifie que vous n'avez pas besoin d'utiliser les instructions include ou require en haut de vos scripts PHP.

Par défaut, le chargement automatique des classes ne se produit que pour les classes définies dans les fichiers situés dans le répertoire racine du SDK pour App Engine (et s'il a été spécifié par --php_executable_path, votre installation PHP locale).

Pour appliquer le chargement automatique des classes à d'autres chemins d'accès, utilisez le paramètre set_include_path dans votre script PHP.

set_include_path('my_additional_path' . PATH_SEPARATOR . get_include_path());

Extensions activées

Les extensions suivantes ont été activées dans l'environnement d'exécution PHP pour App Engine :

  • apc
  • bcmath
  • calendrier
  • Core
  • ctype
  • date
  • dom
  • ereg
  • exif
  • filtre
  • ftp
  • gd
  • hash
  • iconv
  • json
  • libxml
  • mailparse
  • mbstring
  • mcrypt
  • memcache
  • memcached
  • mysql
  • mysqli
  • mysqlnd
  • OAuth
  • openssl
  • pcre
  • PDO
  • pdo_mysql
  • Reflet
  • session
  • shmop
  • SimpleXML
  • soap
  • sockets (pour les applications avec facturation activée)
  • SPL
  • standard
  • tokenizer
  • xml
  • xmlreader
  • xmlwriter
  • xsl
  • zip
  • zlib

Extensions à chargement dynamique

Les extensions suivantes peuvent être chargées dynamiquement via la configuration du fichier php.ini.

  • cURL : cette extension utilise le service de socket pour effectuer des requêtes et est soumise au quota et aux restrictions de ce service. Pour en savoir plus, consultez la page Requêtes sortantes.
  • MongoDB : cette extension permet à un développeur de se connecter à une instance MongoDB existante. Elle utilise le service de socket pour effectuer des requêtes, et est soumise au quota et aux restrictions de ce service.
  • ImageMagick
  • intl
  • fileinfo

Pour activer ces extensions, ajoutez-leur des directives dans votre fichier php.ini sous extension, comme suit :

extension = "curl.so"
extension = "mongo.so"
extension = "imagick.so"
extension = "intl.so"
extension = "fileinfo.so"

Sessions

La plupart des applications Web ont besoin d'un moyen de préserver les informations relatives à l'état de l'utilisateur entre les requêtes. PHP fournit un niveau de gestion de session pratique. Les sessions au sein d'App Engine fonctionnent comme des sessions dans toute autre application PHP.

Définition d'une variable dans une session utilisateur :

session_start();
$_SESSION['Foo'] = 'Bar';

Lors d'une requête ultérieure par le même utilisateur :

session_start();
print $_SESSION['Foo']; // prints Bar

Par défaut, l'environnement d'exécution App Engine utilise Memcache pour stocker les informations de session à l'aide de la classe MemcacheSessionHandler. Vous pouvez ajuster ce comportement en spécifiant votre propre gestionnaire de session à l'aide de la méthode PHP session_set_save_handler(). Memcache permet aux données de session d'être enregistrées et récupérées rapidement, ce qui signifie que la surcharge sur votre requête est minime. Toutefois, les données contenues dans le memcache d'App Engine peuvent être vidées périodiquement, ce qui signifie que les informations de session sont perdues. Pour les sessions plus longues, il peut être préférable d'utiliser un autre service de stockage, tel que Cloud SQL.

Clés $_SERVER spéciales

PHP rend le tableau $_SERVER[] spécial disponible dans le champ d'application de la requête. En plus des paramètres CGI standards, App Engine propose quelques clés supplémentaires utiles.

  • APPLICATION_ID : paramètre app_id défini à la création de l'application, par exemple "my-wordpress".
  • AUTH_DOMAIN : domaine utilisé pour l'authentification des utilisateurs à l'aide de l'API Users. Si l'application est hébergée sur appspot.com, AUTH_DOMAIN a pour valeur gmail.com, et tous les comptes Google sont acceptés. Si l'application est hébergée sur un domaine personnalisé avec Google Workspace, AUTH_DOMAIN a pour valeur le nom du domaine.
  • CURRENT_VERSION_ID : versions principale et secondaire de l'application en cours d'exécution (par exemple, "X.Y"). Le numéro de la version principale ("X") est spécifié dans le fichier app.yaml de l'application. Le numéro de la version secondaire ("Y") est défini automatiquement lorsque chaque version de l'application est transférée vers App Engine. Sur le serveur Web de développement, la version secondaire correspond toujours à "1".
  • DEFAULT_VERSION_HOSTNAME : nom d'hôte de la version par défaut de cette application, par exemple my-php-app.uc.r.appspot.com.
  • HTTP_X_APPENGINE_CITY : nom de la ville d'origine de la requête. Par exemple, la valeur d'en-tête d'une requête provenant de Mountain View serait "mountain view".
  • HTTP_X_APPENGINE_CITYLATLONG : latitude et longitude de la ville d'origine de la requête. Cette chaîne peut par exemple prendre la forme "37.386051, -122.083851" pour une requête provenant de Mountain View.
  • HTTP_X_APPENGINE_COUNTRY : pays d'origine de la requête, sous forme de code de pays ISO 3166-1 alpha-2. App Engine définit ce code à partir de l'adresse IP du client.
  • HTTP_X_APPENGINE_REGION : nom de la région d'origine de la requête. Cette valeur n'a de sens que dans le contexte du pays dans X-Appengine-Country. Par exemple, si le pays est "États-Unis" et la région est "ca", ce "ca" signifie "Californie", et non Canada.
  • USER_EMAIL : renvoie l'adresse e-mail de l'utilisateur, s'il a été authentifié à l'aide de l'API Users. Les applications doivent utiliser un pseudo pour les noms affichables.
  • USER_ID : si l'adresse e-mail est associée à un compte Google, user_id renvoie l'identifiant permanent unique de l'utilisateur, sous forme de chaîne (str.), si celui-ci a été authentifié à l'aide de l'API Users. L'identifiant de l'utilisateur ne change pas, même si son adresse e-mail change.
  • USER_IS_ADMIN : 1 si l'utilisateur connecté est également un administrateur de l'application, si celui-ci a été authentifié à l'aide de l'API Users. 0 dans les autres cas.
  • USER_NICKNAME : pour les utilisateurs de comptes Google, le pseudo de l'utilisateur correspond à la partie "nom" de son adresse e-mail lorsque celle-ci est associée au même domaine que l'application, et à l'adresse e-mail complète de l'utilisateur dans les autres cas.
  • USER_ORGANIZATION : une application utilisant le paramètre de comptes Google peut déterminer si l'utilisateur actuellement connecté possède un compte Google personnel ou un compte géré par un domaine Google Workspace.

Comportement de PHP_SELF et de SCRIPT_NAME mis à jour dans la version 1.9.0

L'implémentation de $_SERVER['SCRIPT_NAME'] et de $_SERVER['PHP_SELF'] antérieure à la version 1.9.0 est très différente de la version 1.9.0 et ultérieure. Les modifications ont été apportées à des fins de cohérence avec la mise en œuvre Apache généralement attendue par les applications PHP.

Les exemples suivants illustrent la différence.

Avant la version 1.9.0Après la version 1.9.0

app.yaml :

- url: /.*
  script: index.php
REQUEST_URI: /
SCRIPT_FILENAME: /path/to/index.php
SCRIPT_NAME: /
      PHP_SELF: /
REQUEST_URI: /
SCRIPT_FILENAME: /path/to/index.php
SCRIPT_NAME: /index.php
PHP_SELF: /index.php
REQUEST_URI: /bar
SCRIPT_FILENAME: /path/to/index.php
SCRIPT_NAME: /bar
PHP_SELF: /bar
REQUEST_URI: /bar
SCRIPT_FILENAME: /path/to/index.php
SCRIPT_NAME: /index.php
PHP_SELF: /index.php
REQUEST_URI: /index.php/foo/bar
SCRIPT_FILENAME: /path/to/index.php
SCRIPT_NAME: /index.php/foo/bar
PHP_SELF: /index.php/foo/bar
REQUEST_URI: /index.php/foo/bar
SCRIPT_FILENAME: /path/to/index.php
SCRIPT_NAME: /index.php
PHP_SELF: /index.php/foo/bar
REQUEST_URI: /test.php/foo/bar
SCRIPT_FILENAME: /path/to/index.php
SCRIPT_NAME: /test.php/foo/bar
PHP_SELF: /test.php/foo/bar
REQUEST_URI: /test.php/foo/bar
SCRIPT_FILENAME: /path/to/index.php
SCRIPT_NAME: /index.php
PHP_SELF: /index.php

app.yaml :

- url: /.*
  script: foo/index.php
REQUEST_URI: /bar
SCRIPT_FILENAME: /path/to/foo/index.php
SCRIPT_NAME: /bar
PHP_SELF: /bar
REQUEST_URI: /bar
SCRIPT_FILENAME: /path/to/foo/index.php
SCRIPT_NAME: /foo/index.php
PHP_SELF: /foo/index.php

Directives avec de nouveaux paramètres d'initialisation par défaut

Ce tableau spécifie les directives dont les valeurs par défaut d'initialisation diffèrent des valeurs par défaut fournies avec l'interpréteur PHP standard disponible sur php.net. Vous pouvez remplacer ces directives par défaut en les incluant dans un fichier php.ini pour votre application.

Directive Valeur par défaut dans App Engine
detect_unicode false
session.gc_maxlifetime 600
session.cookie_secure 600
session.cookie_httponly 1
session.use_only_cookies 1
display_errors 0
display_startup_errors 0
html_errors 0
log_errors 1
file_uploads 0
upload_max_filesize 262144
max_file_uploads 0
date.timezone UTC
sendmail_path null
allow_url_fopen 1
allow_url_include 0
enable_dl 0
expose_php Off
register_globals Off
magic_quotes_gpc 0
mysqlnd.collect_statistics 0
mysql.allow_local_infile 0
mysqli.allow_local_infile 0

Fonctions désactivées

Pour des raisons de sécurité ou de compatibilité avec l'environnement d'exécution App Engine, certaines fonctions PHP ont été désactivées. Une partie de ces fonctions peut être explicitement réactivée dans le fichier php.ini pour votre application.

Fonctions désactivées de façon permanente

Les fonctions suivantes ont été désactivées de manière permanente dans App Engine :

  • disk_free_space()
  • disk_total_space()
  • diskfreespace()
  • escapeshellarg() and escapeshellcmd()
  • exec()
  • highlight_file()
  • lchgrp(), lchown(), link(), and symlink()
  • passthru()
  • pclose() and popen()
  • proc_close(), prog_get_status(), proc_nice(), proc_open(), and proc_terminate()
  • set_time_limit()
  • shell_exec()
  • show_source()
  • system()

App Engine n'inclut pas l'extension pcntl. Par conséquent, les fonctions fournies par pcntl ne sont pas disponibles pour les applications PHP exécutées dans App Engine.

Disponibilité de tempnam() et sys_get_temp_dir()

Les applications App Engine s'exécutent dans un bac à sable de sécurité qui n'autorise pas l'écriture sur le système de fichiers local. Pour cette raison, la version de tempnam() d'App Engine renvoie un fichier temporaire en mémoire pouvant être écrit ultérieurement sur une solution de stockage permanent, telle que les buckets Google Cloud Storage.

Voici un exemple d'écriture dans le fichier temporaire en mémoire à l'aide de file_put_contents() et fwrite().

<?php
$dir = sys_get_temp_dir();
$tmp = tempnam($dir, “foo”);
file_put_contents($tmp, “hello”)
$f = fopen($tmp, “a”);
fwrite($f, “ world”);
fclose($f)
echo file_get_contents($tmp);

Le résultat attendu de l'exemple serait le suivant :

hello world

Fonctions partiellement restreintes

App Engine pour l'environnement d'exécution PHP n'accepte pas le modificateur de modèle /e des fonctions preg_replace() et mb_ereg_replace(). Consultez la documentation PREG_REPLACE_EVAL contenant l'avis d'obsolescence et un exemple de mise à jour du code pour utiliser preg_replace_callback() à la place.

Fonctions pouvant être activées manuellement

Cette liste spécifie la fonction PHP qui doit être activée manuellement à l'aide de la directive google_app_engine.enable_functions dans le fichier php.ini de votre application.

  • gc_collect_cycles(), gc_enable(), gc_disable() et gc_enabled()
  • getmypid()
  • getmyuid() et getmygid()
  • getrusage()
  • getmyinode()
  • get_current_user()
  • libxml_disable_entity_loader()*
  • parse_str()
  • phpinfo()
  • phpversion()
  • php_uname()
  • php_sapi_name()

Vous pouvez également désactiver ces fonctions manuellement en utilisant la directive disable_functions dans le fichier php.ini de votre application.

Fonctions nécessitant l'activation de la facturation

Les fonctions suivantes utilisent des sockets et ne sont donc disponibles que pour les applications avec la facturation activée.

Utilisation de flux

Wrappers de flux d'E/S PHP disponibles

Les wrappers de flux d'E/S PHP suivants sont disponibles :

  • php://input
  • php://output
  • php://memory
  • php://temp

Wrappers de flux

De nombreuses fonctions dans PHP, telles que fopen() ou file_get_contents(), profitent de l'interface de flux de PHP pour accepter différents protocoles.

Voici la liste des wrappers de flux intégrés qui sont enregistrés automatiquement et disponibles dans l'environnement d'exécution App Engine.

Voici la liste des gestionnaires de flux intégrés non compatibles avec App Engine dont l'enregistrement a été annulé.

  • data://
  • expect://
  • ogg://
  • phar://
  • rar://
  • ssh2://

Transports de flux désactivés

Les transports de flux suivants ont été désactivés.

  • ssl
  • sslv2
  • sslv3
  • tcp
  • tls
  • udg
  • udp
  • unix

PHP pur

L'ensemble du code destiné à l'environnement d'exécution PHP doit être écrit en PHP pur. App Engine ne permet pas de transférer ses propres extensions C.

L'environnement inclut la bibliothèque standard PHP. Certaines extensions ont été désactivées, car leurs fonctions principales ne sont pas compatibles avec App Engine, telles que la mise en réseau et l'écriture sur le système de fichiers.

Vous pouvez inclure d'autres bibliothèques PHP pures dans votre application en plaçant le code dans le répertoire de votre application, qui contient également votre fichier app.yaml.

Par exemple, vous pouvez créer un lien symbolique dans le répertoire de votre application qui pointe vers le répertoire d'une bibliothèque. Ce lien est ensuite suivi et la bibliothèque est incluse dans votre application lorsque vous effectuez un déploiement dans App Engine.

Vous pouvez également inclure des bibliothèques PHP en spécifiant des directives php.ini et en incluant des instructions PHP include dans votre code. Cependant, l'option à privilégier consiste à utiliser un outil de gestion des dépendances PHP tel que Composer.

Exemples :

  • Si vous incluez le répertoire racine de votre application dans la directive include_path de votre fichier php.ini :

    include_path=".:/[ROOT_DIR]/myapp"
    

    Vous pouvez ensuite utiliser les instructions include ou include_once pour inclure des fichiers PHP relatifs à votre include_path :

    include_once 'myfile.php';
    
  • Si vous choisissez d'utiliser Composer pour inclure les bibliothèques PHP pures, vous pouvez simplement inclure un seul fichier une fois les dépendances installées :

    require_once 'vendor/autoload.php';
    

    Lorsque vous utilisez Composer pour installer les dépendances de votre application, tous les packages sont ajoutés dans le répertoire de votre application sous vendor, qui est également l'emplacement de génération du fichier autoload.php.

Outils

Le SDK pour App Engine inclut des outils permettant de tester votre application et d'importer les fichiers associés.

Le serveur de développement exécute votre application sur votre ordinateur local pour le tester.

L'outil gcloud gère toutes les interactions de ligne de commande avec l'application s'exécutant sur App Engine. Vous utilisez gcloud app deploy pour importer votre application dans App Engine ou pour mettre à jour des fichiers de configuration individuels. Vous avez également la possibilité d'afficher les données de journalisation de votre application afin d'analyser les performances de cette dernière à l'aide de vos propres outils.

Code source de l'interpréteur PHP

Vous pouvez télécharger le code source de l'interpréteur PHP d'App Engine dans le dépôt appengine-php sur GitHub.

Simultanéité et latence

La latence de votre application a le plus grand impact sur le nombre d'instances nécessaires pour desservir votre trafic. Si vous traitez les requêtes rapidement, une seule instance peut gérer un grand nombre de requêtes.

Variables d'environnement

Les variables d'environnement suivantes sont définies par l'environnement d'exécution :

Variable d'environnement Description
GAE_APPLICATION ID de votre application App Engine. Cet ID est précédé du préfixe "region code~", tel que "e~" pour les applications déployées en Europe.
GAE_DEPLOYMENT_ID ID du déploiement actuel.
GAE_ENV Environnement App Engine. Variable définie sur standard.
GAE_INSTANCE ID de l'instance sur laquelle votre service est en cours d'exécution.
GAE_RUNTIME Environnement d'exécution spécifié dans le fichier app.yaml.
GAE_SERVICE Nom de service spécifié dans le fichier app.yaml. Si aucun nom de service n'est spécifié, il est défini par défaut sur default.
GAE_VERSION Libellé de la version actuelle du service.
GOOGLE_CLOUD_PROJECT ID du projet Google Cloud associé à votre application.
PORT Port qui reçoit les requêtes HTTP.

Vous pouvez définir des variables d'environnement supplémentaires dans le fichier app.yaml, mais les valeurs ci-dessus ne peuvent pas être remplacées.