P1010426.JPG

Déploiement des applications PHP

La discussion a débuté autour d'une question ouverte sur les besoins en terme de déploiement : un bon outil doit permettre à minima l'installation et la mise à jour du code d'une application. 2 approches sont possibles : push ou pull de l'appli sur la machine cible (le push se faisant via un outil installé sur sa propre machine, et le pull en se connectant à la machine cible en SSH). Thomas Cataldo a souligné le fait que l'outil choisi dépendait de la plate-forme cible, en donnant pour exemple les plate-formes Windows pour lesquelles la création d'un MSI était une bonne solution. Il a également été rappelé que le déploiement était rarement sous la responsabilité du développeur, mais plutôt d'un profil intégrateur/exploitant.

Outils disponibles

Peu d'outils PHP existent pour faire ça ! Ont été cités :

  • Capistrano : outil écrit en Ruby pour faciliter le déploiement d'une appli sur de multiples serveurs (note : il permet d'exécuter des commandes en parallèle sur des machines distantes via SSH, et propose un Domain Specific Language qui rend les scripts de déploiement faciles à écrire et simples à comprendre). Il est utilisable pour déployer des applis PHP.
  • Puppet : autre outil Ruby permettant de déployer des fichiers de configuration sur des machines type Unix, nécessite un serveur installé sur les machines cibles.
  • scripts shells
  • makefiles
  • Ant (Java)
  • Phing : un port d'Ant en PHP
  • PEAR, qui est à l'origine un framework de déploiement
  • PHAR (introduit en PHP 5.3), qui permet de packager une appli PHP sous la forme d'une archive, à l'image des JARs et WARs en Java

Thomas Cataldo, Sylvain Garcia (packageur OBM), et Christophe Sauthier (MOTU Ubuntu) ont parlé des possibilités offertes par les systèmes de packaging proposées par les distributions Linux (.deb sous Debian/Ubuntu, .rpm sous Fedora/RedHat). Il est possible de créer ce type de paquets assez rapidement, mais cela n'a d'intérêt que si les paquets sont mis à jour régulièrement et publiés via un serveur de paquets. De façon générale, les développeurs préfèrent utiliser les mécanismes de packaging offerts par le langage (PEAR pour PHP, Gems pour Ruby) plutôt que par les distribs pour différentes raisons : volonté d'installer les librairies ailleurs que dans l'emplacement par défaut de la distrib (contraintes de production souvent) ou d'utiliser des versions de librairies plus récentes que celles proposées par la distrib.

Enfin, il a été évoqué que les frameworks offraient certaines fonctionnalités utiles pour le déploiement, comme la migration des schémas de base de données (fonctionnalité introduite par Rails, et reprise dans plusieurs frameworks PHP).

Synthèse personnelle

PHP dispose d'outils efficaces pour gérer l'installation/mise à jour du code source d'une application (PEAR, PHAR qui a beaucoup de potentiel) sur un serveur, mais rien pour gérer le déploiement sur X serveurs, gérer la config d'Apache, etc...

P1010429.JPG

Les frameworks

Cette session a été bien sûr riche en trolls (ma présence y étant sans nul doute pour quelque chose ;) ! Nous avons commencé par essayer de définir ce qu'est un framework (par rapport à une librairie en particulier) : c'est un cadre de développement, fournissant des conventions et une structure pour le développement d'un logiciel en équipe, et qui **impose** une manière de développer. Nous avons ensuite procédé à un tour de table autour des frameworks utilisés par chacun. L'impact de Rails et notamment de son aspect "convention over configuration" sur les frameworks PHP a été rappelé. Un framework ne règle pas tous les problèmes, il est tout à fait possible de mal l'utiliser et de se retrouver avec des anti-patterns du type "Fat controllers". Mais globalement, un framework est un outil qui permet d'écrire moins de code et de développer plus rapidement, si et seulement si on a une bonne maîtrise du framework. Un framework permet aussi d'avoir une structure commune entre les projets, ce qui est intéressant en terme de maintenance (il est plus facile pour un développeur qui n'a pas participé au projet de prendre en main sa maintenance, ce qui diminue les risques du turn-over dans une société).

  • ZF : très modulaire et plutôt bas niveau. Intéressant dans le cas de la migration d'une appli existante qui peut être faite de manière progressive. De plus en plus de fonctionnalités.
  • Symfony : présente l'avantage d'être supporté par une boîte française, et d'être très richement documenté. Très structurant/contraignant, mais sa version 2.0 doit apporter un découplage fort de ses composants.
  • CakePHP : à l'origine un clone de Rails mais s'en éloigne avec le temps, compatible PHP4 jusqu'à présent, mais sera bientôt PHP5 only. Une source de composants devrait être ajouté pour ne pas avoir à aller les chercher sur le web, ainsi que la possibilité de personnaliser la génération de code.

NoSQL

Problématique

La montée en charge des bases de données relationnelles se traduit souvent par l'achat d'un serveur plus gros, mais outre le coût, cette solution a ses limites. Le clustering est difficile. Les BD actuelles n'ont pas de mode multi-master valable (toujours un "single point of failure", réplication instantanée non garantie). Elles sont en fait des compromis intégrité/performances/fiabilité/etc... et ne brillent pas par leur extensibilité.

Les BD "NoSQL" sont conçues pour une extensibilité extrême (plusieurs milliers de serveurs low-cost) et permettent une architecture flexible dans laquelle il est facile de rajouter de nouvelles instances. Certaines sont une alternative intéressante dans le cas de modèles de données complexes sous une forme relationnelle (réseaux sociaux par exemple).

Solutions

Il y en a 3 grands types :

  • dépôts clé-valeur : possibilités de requêtage faibles (sauf peut être Redis)
  • clones de BigTable (Google) : dépôts clé-valeur structurés dans lesquels une clé peut avoir plusieurs valeurs regroupées en familles de colonnes (et on peut ajouter des colonnes à tout moment). Il faut voir ça comme un hash à 4 ou 5 dimensions. L'exemple-type est Cassandra développé par Facebook, qui utilise Thrift pour générer une API cliente via des IDLs (fichiers de définition). Il y a aussi Hadoop qui propose un stack complet (et complexe) semblable aux outils Google.
  • bases de données orientées documents : CouchDB ou MongoDB. L'API de CouchDB est RESTful, et utilise JSON pour l'échange de données.

On notera que chaque solution a son propre type d'API, il y a donc un lien fort entre l'outil et l'appli développée (contrairement aux BD classiques qui ont le SQL même si ce n'est pas si simple). La conception de l'appli nécessite d'ailleurs de penser différemment, en particulier avec les dépôts clé-valeur.

Concernant l'espace disque, certes il faut multiplier le stockage N fois pour les N instances, mais c'est toujours moins cher (une instance = 1 serveur low-cost) que des équipements de type baie de disque à partager entre les N instances d'une BD relationnelle. La consistance des données entre les différents serveurs n'est pas garantie, mais des ajustements sont possibles (considérer les données comme OK dès que répliquées sur au moins N instances). Ces solutions sont amenées à prendre de l'ampleur avec l'orientation "Cloud" du marché.

En conclusion, ces solutions sont destinées à une utilisation TRES spécifique. Facebook notamment ne l'utilise que pour la recherche dans les inbox, et utilise encore intensivement MySQL.