Le document traite des prérequis et des meilleures pratiques pour le déploiement et la gestion d'applications PHP, incluant des considérations sur le runtime, la configuration des serveurs et base de données, ainsi que l'importance du reporting et de l'optimisation des performances. Il souligne également les conséquences des évolutions majeures et mineures de PHP sur les applications, ainsi que la nécessité de séparer les données et d'utiliser des outils pour améliorer la sécurité et la gestion des performances. Enfin, il évoque des paramètres divers liés aux composants tiers et aux environnements de déploiement.

1. Lucas Bonnet
Pierre Couzy

3. ◦ Dans le temps
◦ Dans l’environnement d’exécution
◦ Dans les évolutions

4.  Les prérequis ?
◦ Le runtime PHP
◦ Les extensions
◦ Logging
 L’appli ?
◦ Paramétrage
◦ La base de données
◦ Les autres données
 La prod ?
◦ Le serveur
◦ Les caches
◦ Retour sur la base de données
 Le déploiement

5. Un premier impact sur les versions majeures
 Fonctions obsolètes
 Vieux workarounds qui cessent de fonctionner
 Nouveaux bugs
Mais aussi sur les versions mineures
 Corrections apportées suite à l’analyse par CoVerity
 Gestion d’erreur parfois subtilement différente
 Exemples : Eval, PDO
Et enfin selon l’OS
 Profil de perf TRES différent entre 5.2 et 5.3 sous Windows
Le choix du runtime va avoir de très grosses conséquences
 Soit on fige une version de PHP en prod
 Soit on sait recetter l’appli sur une nouvelle version de …

6.  Installez php sans extensions
 Activez le reporting
 Ajoutez le strict minimum
 Mettez php.ini au carré
 Ne jetez pas les extensions
qui ne vous servent pas ?
◦ On est pas d’accord sur le sujet.

7.  Calendar : installé ou pas ?
 Mb_string : en mod_php sur 5.2 en mutu, si
des sites activent mb_string les autres en
“profitent”
 Au fait, quand on ajoute une
extension à une install existante,
on prend quelle version ?
 Un cauchemar particulier sous Windows
◦ Prenez les versions VC9 NTS pour IIS, et VC6 TS
pour Apache

9.  À faire sur la bécane de dev et après chaque
mise en prod et à garder dans les docs

10.  Les composants tiers (FW, plugins, etc.)
 Les paramètres de déploiement
 Les paramètres de fonctionnement
 L’adhérence à la base de données
 Le filesystem
 Etc.

13.  Des paramètres regroupés
 Différenciés par
environnement de
déploiement
 Différenciés par nature
◦ appli/infra/opti/…
 Préférez des formats texte…
◦ Et documentés

14.  Le minimum syndical
◦ Une couche technique d’abstraction
◦ Un référentiel pour les requêtes custom
 PDO
◦ Pas complet, mais on a pas mieux.
 Une parenthèse sur les ORM

15.  A votre avis ?
◦ Images uploadées
◦ Sessions
◦ Fichiers auto-générés
◦ Logs
◦ Code uploadé par un admin (depuis l’IHM Web)

16.  Quelques questions simples
◦ Conventions ?
◦ Permissions ?
◦ Abstraction ? (wrappers etc)
◦ Limites à comprendre
 Nb de fichiers/folders par …
 Limites sur un nom de fichier ?
 Permissions sur répertoires : pas toujours dispo

17.  Fichiers auto-générés
 Vignettes
 Sessions
 Paramétrage des logs
◦ Log errors = on
◦ display_errors = off
 E_STRICT
 E_ALL
 E_DEPRECATED
 E_NOTICE

18.  Les 5 principales causes couvrent 86% des
attaques recensées
 Comment se couvrir ?
 Coverity
 Php lint

19.  Séparez les données
◦ UGC
◦ Données de structure / modules / etc
 Exemple : Drupal, un nouveau module
◦ Le filesystem
◦ La base de données
◦ Même sans contenus utilisateur
◦ l’upgrade est faite par code

20.  C’est quoi l’adresse de ton SMTP ?
◦ Si c’est pour quelques mails l’hébergeur peut
éventuellement le fournir
◦ Si c’est pour spammer on passe par un service
dédié et externe (critsend, etc.)
 Tu peux m’ouvrir un accès FTP ?
◦ Pour de la mise en prod ?
◦ Pour de la mise à dispo d’exports divers et variés
◦ Pour du reparamétrage

21.  Profils de charge inattendus
◦ Un appel synchrone à FB oublié dans un coin sur la
home
 La base s’éloigne
◦ Lag qui passe de 1 à 10 ms
 Saturations disque / RAM / réseau
 Oui, j’ai laissé l’historique dans la
base, pourquoi tu demandes ça ?

22. Un process par Chargement de Gestion d’un pool
FastCGI
ISAPI & mod-php
CGI
requête PHP in-process de process
(surrogate IIS ou
process Apache)
Avantage Avantage Avantages
• Très stable • Très performant • Plus rapide que CGI
• Plus stable
Inconvénient Inconvénients qu’ISAPI/mod_php
• Permet de
• *Très* lent sous • Stabilité fonctionner sans
Windows (coût • Réentrance réentrance
énorme de création
d’un process)

23. http://forge.bearstech.com/trac/wiki/DebianLampLenny

24.  Optimiser, c’est mal
◦ En dev
 Avant la mise en prod
 Par copier/coller de trucs sur internet

25.  Sur la bécane
◦ Cache d’opcode
◦ Cache de résolution dns/filesystem
◦ User code ?
◦ Caches de rendu divers et variés
◦ Cache de bdd
 Entre bécanes
◦ Sessions dans memcache/redis/..
 Au cul des bécanes
◦ Varnish (cookie de session anyone ?)

26.  Tables à croissance infinie
 Requêtes non cachées
 Requêtes impliquant un table scan
 Select * from MyHugeNewsTable
… Order by rand()
 Fonctionnellement, une jointure est équivalente à
une boucle.
 Les BDD savent optimiser les requêtes identiques
(par exemple les requêtes paramétrées)
◦ Il y toujours PDO::ATTR_EMULATE_PREPARES si vous en
avez besoin

27.  Mon premier déploiement
◦ Coupez le réseau de la machine du développeur et
filez-lui une clé USB.
 Pour les suivants, automatisez
◦ Aujourd’hui ce n’est pas la norme
… Et on est polis
 Un contrôleur de source ça peut garder plein
de trucs
◦ Y compris une appli qui n’est pas sous contrôle de
source avant l’arrivée en prod