Jean-Luc Petit

La virtualisation en environnement de développement

Tous ceux qui ont travaillé avec moi savent que je suis un adepte des machines virtuelles en environnement de développement. Je fais du PHP quasi tous les jours et cependant sur mes machines physiques personnelles et professionnelles, cela doit faire près de 3 ans que je n’ai installé ni PHP ni même de serveur Apache. Je suis accro aux VM… Oui mais pourquoi ?

Simuler au plus près l’environnement final

En théorie tout se passe bien. Oui mais ça c’est la théorie. Combien de fois n’ai-je pas entendu : « ouais mais sur mon PC ça marchait bien » ! Là on se dit que notre interlocuteur connaît un peu son métier, on commence donc à chercher dans le code source et au bout d’un quart d’heure (dans le meilleur des cas) on se rend compte que le gars bosse sur du PHP 5.4 en local et que son serveur fonctionne en version 5.2.

Un autre exemple qui m’est arrivé récemment. J’avais besoin de créer des fichiers CSV avec des caractères non latins. L’environnement d’exécution du script final était en PHP 5.3.3. Or il se trouve qu’avec certains encodages (dans mon cas en_US.UTF-8), la fonction fputscsv() n’arrive pas à écrire les mots uniques (où il n’y a pas de caractère d’encadrement). Je n’ai constaté ce bug qu’avec des mots utilisant l’alphabet cyrillique et l’alphabet arabe.
DotDeb est venu à ma rescousse : j’ai upgradé la version de PHP (de souvenir 5.3.26) et cela a fonctionné. Outre Dotdeb, ce qui m’a permis de prévenir cette anomalie c’est d’avoir utilisé un environnement similaire à l’environnement d’exécution du script final.

Partez toujours du principe qu’il faut parer à toute éventualité et donc plus votre environnement sera identique à l’environnement final moins vous rencontrerez de surprises.

La multiplicité des projets

C’est encore plus vrai aujourd’hui du fait du nombre de projets qui passe sur mon PC. Une partie non négligeable de mon temps professionnel est consacré à faire de l’audit de code quant à son caractère multilingue. Il y a quelques mois, il m’est arrivé d’avoir à auditer les sources de 4 projets en moins d’un mois, projets qui se chevauchaient au gré des retours des différents interlocuteurs, sans compter les projets internes. Bref, sans organisation et délimitation des environnements on court à la catastrophe.

Qui dit différents projets dit différents besoins. Et tout ne peut être résolu par un fichier de configuration Apache ou autre. Au fil du temps, je me suis fait mon petit parc de machines virtuelles vierges de tout projet que je clone (car il faut générer un nouvel UUID) au besoin.

Gérer les ressources de la machine physique

Rappelez vous de ce projet foireux hyper lourd (souvent pour un résultat médiocre) où vous retrouviez de la redondance de code en veux-tu en voilà, des fichiers CSS et bibliothèques JS incluses 42 fois dans la même version, avec une conception en amont prévue dans le meilleur des cas en post-projet… Tout cela en plus a tendance à faire ralentir non seulement votre navigateur mais aussi toute votre machine physique, du fait que tout tourne sur des ressources partagées : serveur Apache, SAPI PHP, IDE, Navigateur, Photoshop (on m’a dit de la rajouter, pardonnez-moi mes pairs parce que j’ai péché un magicarpe). J’ai souvenir d’avoir bossé sur deux projets mémorables de ce type où certains développeurs saisissaient leurs lignes de code sur leur clavier pour les voir apparaître 5 à 10 secondes plus tard.

En cela, la virtualisation apporte une vraie solution car elle permet d’allouer à l’environnement d’exécution une partie limitée des ressources de la machine physique. Il est vrai qu’il faut tout de même avoir une configuration assez robuste pour se permettre d’allouer des ressources suffisantes à l’environnement virtuel.

Transférer/archiver un projet

Un autre avantage non négligeable de la virtualisation est de pouvoir transférer simplement son projet. Finis les phrases du style :

  • « Tu m’as envoyé les sources de l’application, par contre le dump de la base de donnée il est où ? »
  • « Et la valeur du memory_limit ? »
  • « Comment qu’on fait pour installer Tomcat ? Et Solr ? »

Bref, les machines virtuelles c’est un gain de temps pour transférer son projet d’un poste à un autre ou tout simplement pour l’archiver.

Pour terminer

C’est vrai qu’au début c’est un peu déroutant, il y a une phase d’apprentissage où il faut savoir répondre efficacement : comment accéder à mes fichiers (je préconise sshfs), les types de connexions réseau de la VM, etc… Mais au final, une fois qu’on a pris le coup de main, c’est easy les fois suivantes et c’est plus propre en terme d’organisation.

Debian : Vim comme éditeur par défaut.

Pour avoir Vim comme éditeur par défaut sous Debian (et dérivés je suppose), il suffit de lancer la commande suivante précédée de sudo si besoin.

update-alternatives --set editor /usr/bin/vim.basic

Enjoy!

Cacher la version de PHP et d’Apache des en-têtes

Pour savoir quelles sont les technologies utilisées par des sites Internet, j’utilise Wappalyzer. Très pratique en effet, pour voir d’un coup d’œil si un site est propulsé par Drupal, s’il utilise Apache, etc…

Wappalyzer vous affiche également la version de PHP, celle d’Apache. Ces informations sont situées dans l’en-tête de la réponse HTTP délivrée par votre serveur. En terme de sécurité, je ne trouve pas ça terrible. J’ai donc cherché à cacher ces informations et en fait ce n’est pas si compliqué.

Pour cacher la version de PHP, il suffit de passer la directive expose_php de votre fichier php.ini à Off.

expose_php = Off

Pour cacher la version d’Apache, il faut ajouter/modifier les lignes suivantes à votre fichier de configuration Apache :

ServerTokens ProductOnly
ServerSignature Off

N’oubliez pas de redémarrer Apache et de vous référez à la doc PHP et à celle d’Apache pour en apprendre plus.

Installer Composer et le mettre à disposition de tous

Pour rappel Composer est un gestionnaire de dépendances pour PHP. Son utilisation est très répandue. On peut s’en servir par exemple pour télécharger Symfony2 ainsi que ses Vendors.

  • Système d’exploitation : Debian 7.0 Squeeze
  • Prérequis : PHP (SAPI cli) et CURL

Télécharger Composer

Placer vous dans le répertoire de votre choix. On va ensuite exécuter le script se trouvant à l’URL https://getcomposer.org/installer avec PHP

curl -s https://getcomposer.org/installer | php

Le mettre à disposition de tous

Pour que tout un chacun puisse s’en servir nous allons déplacer l’archive composer.phar dans /usr/bin

mv ./composer.phar /usr/bin/composer

On aurait pu lancer le téléchargement directement dans /usr/bin. Mais étant donné que c’est un dossier sensible, il vaut mieux anticiper des problèmes éventuels en travaillant dans un répertoire quelconque. Maintenant nous allons donner les droits d’exécution à tout le monde.

chmod +x /usr/bin/composer

Vous pouvez adapter le CHMOD et modifier le propriétaire et le groupe au besoin. Normalement maintenant vous devriez pouvoir utiliser la commande composer.phar

Enjoy!