J’aime bien mes collègues de travail, je découvre plein de façons différentes d’appréhender les problèmes, cela ouvre des choix, donc des possibilités d’aller plus rapidement.
Inversement, j’ai une aversion pour le temps que l’on peut perdre en tâches redondantes. Appelez ça une manie d’optimisation propre à l’ingénieur, ou bien une inscription dans l’ère du temps de l’hyper rentabilité… Je vous propose dans cette optique une série de petites optimisations à destination des développeurs web (essentiellement php mais c’est applicable à d’autres langages) qui devraient vous épargner les X tâches de configuration, mais également de pouvoir rentrer dans un processus d’industrialisation. Cela ne révolutionne en rien l’existant, la plupart de ces techniques étant déjà connues / appliquées depuis un certain temps, mais j’en profite pour les rassembler dans cette synthèse
Problèmes de droits
Souvent lors des déploiements et mises à jour, les développeurs sont confrontés à un problème de droits de lecture / écriture très commun : l’utilisateur par lequel ils livrent les sources n’est pas l’utilisateur système qui démarre le service http (et donc l’interpréteur de script ou le serveur d’application). Il en résulte que dès que l’on commence à toucher au backoffice, on est suceptible d’uploader des fichiers que l’on ne pourra bouger ou supprimer. Plus embêtant, bon nombre de CMS ou de progiciels ont un système de mise à jour intégré, et par conséquent ce dernier est inopérant lorsque le user système n’a pas les droits pour écrire / écraser des fichiers déposés par le user de dépose.
Une des solutions les plus communément utilisées consiste à donner des droits globaux en écriture, lecture et exécution « 777 » sur lesdits fichiers, avec en prime le recours à une élévation de privilège (sudo pour les intimes). Non seulement cette pratique ignore l’origine et l’intérêt de tels droits, mais en plus, il faut la répéter régulièrement pour reprendre possession des fichiers créés au fur et à mesure de l’utilisation de l’administration interne au site développé. Et sur le poste de travail d’un développeur web, ces problématiques sont les mêmes. La solution fonctionnellement est simple : il suffit que l’utilisateur http qui éxécute les scripts soit le même que celui qui a ouvert la session utilisateur.
Dans l’implémentation, et si l’on se cantonne à apache, les solutions les plus anciennes sont bien connues de la communauté, à savoir suexec et suphp qui permettent de changer l’utilisateur qui éxécute les scripts, sans changer l’utilisateur http. Ces 2 modules apache présentent toutefois des inconvénients, car ils obligent à passer par un mode cgi, dont les performances et la sécurité sont moindres que celle de modules intégrés. Je vous propose de tester le petit dernier (même s’il a quelques années d’existence derrière lui) : mpm-itk. Il s’agit d’un worker qui remplace ceux par défaut (généralement mpm-prefork quand on utilise php), et qui démarre complètement avec un user spécifié. La cerise sur le gâteau est que la directive est même spécifiable dans un vhost.
Sous Linux, il suffira d’un
sudo apt-get install libapache2-mpm-itk
faire le lien symbolique dans /etc/apache2/mods-enabled (selon la distribution), enlever le mpm-prefork et enfin éditer le virtual host et rajouter
AssignUserId monuser mongroup
Enfin, si on se trouve sur un OS qui n’a pas la chance d’avoir un port de mpm-itk, il est tout simplement possible de modifier le fichier de configuration d’apache pour changer le user qui lance les workers apache, généralement en modifiant les variables d’environnement
export APACHE_RUN_USER=monuser export APACHE_RUN_GROUP=mongroup
Le travail en parallèle sur plusieurs projets
Rares sont les développeurs web qui travaillent sur un seul projet à la fois. La règle est d’avoir un espace de travail dans son environnement de développement intégrés (IDE) fourni d’une vingtaine ou une trentaire de projets sur lesquels le travailleur du web bascule au gré des besoins clients. J’ai alors vu 2 phénomènes parmi les développeurs :
- soit la racine du serveur web est celle de l’espace de travail et le développeur accède à son projet par l’url http://localhost/monnomdeprojet/, mais cela nécessite que les projets puissent se mettre en sous dossier, ce qui n’est pas forcément possible (ou plus long surtout quand on recharge la base de production dans un espace de développement),
- soit le développeur utilise des virtual hosts qui sont plus isolant et plus simple sur le long terme, mais un virtual host est créé à chaque nouveau projet (plus la relance du serveur web) et une entrée dans le fichier hosts est ajoutée.
Il existe, dans le prolongement de la création d’un vhost, deux techniques à mettre en œuvre pour simplifier ces manipulations : l’automatisation des résolution de noms de domaine à l’aide d’un wildcard DNS, et la sélection du bon répertoire selon le nom de domaine fourni.
Pour le premier point, il suffit de configurer un serveur DNS local avec une zone DNS locale qui pointe vers l’adresse IP (que l’on fixera au préalable) de la machine, avec une entrée générique. Par exemple
*.localhost. IN A 192.168.0.35
qui va résoudre *.localhost vers l’ip externe de la machine. Il reste à paramétrer la résolution DNS cliente pour pointer sur le DNS local (dans les paramètres de la carte réseau sous windows dans le /etc/resolv.conf pour les autres). Cela permettra à vos navigateurs de retrouver http://monnomdeprojet.localhost/ sur votre machine.
Dans la pratique, sous Linux :
On fixe son adresse IP, 192.168.0..35 dans notre exemple, mais qu’il faudra adapter à la topologie de votre réseau, à l’aide du network manager ou bien
sudo vi /etc/network/interfaces
Et en saisissant
iface eth0 inet static
address 192.168.0.35
netmask 255.255.255.0
gateway 192.168.0.254
On installe le service qui va bien
sudo apt-get install bind sudo vi /etc/bind/db.local
On colle, la ligne suivante
* IN A 192.168.0.35
Et enfin on indique à la machine locale de résoudre contre le serveur bind local, en rajoutant le serveur 127.0.0.1 dans la configuration du network manager, ou bien via le programme resolvconf, ou encore en rajoutant à la main une ligne dans dans le /etc/resolv.conf
nameserver 127.0.0.1
On vérifie alors que l’installation fonctionne via la commande
dig test.localhost @127.0.0.1
qui doit renvoyer 192.168.0.35
Sous Mac OSX, comme c’est à la base une FreeBSD, la méthode est quasiment similaire
Sous Windows, il suffit d’installer un serveur DNS, par exemple la compilation de bind pour Windows, ou bien un alternatif comme Acrylic dont la configuration semble être beaucoup plus simple, en se rapprochant de la syntaxe d’un hosts file. Il ne faudra pas oublier de changer dans les propriété avancées de la carte réseau le serveur dns pour l’ip locale 127.0.0.1
Ensuite, il reste à paramétrer le serveur http pour qu’il réponde à tous ces noms d’hôtes, et qu’il choisisse le bon projet. Sous apache, cela se fait tout simplement avec la directive VirtualDocumentRoot, qui permet d’utiliser des parties d’url pour retrouver le chemin à partir duquel il trouvera les sources du site web
ServerName projets.local ServerAlias *.local DocumentRoot /home/monuser/workspace VirtualDocumentRoot /home/monuser/workspace/%1/web AssignUserID monuser mongroup
Dans l’exemple fourni la racine est placée dans un sous répertoire web, comme beaucoup de projets SF1 / SF2 / ZF2, il suffira alors de faire un lien symbolique pour faire pointer au bon endroit si cela est nécessaire.
Attention tout de même, si l’on utilise mod_rewrite, il conviendra de spécifier un
RewriteBase /
car mod_rewrite a tendance à s’emmêler les pinceaux avec un VirtualDocumentRoot.
Les tests sur des plateformes autres que son poste de travail
Un dernier phénomène que j’ai pu constater est la difficulté que les gens ont à tester sur du web mobile. En effet, autant l’utilisation d’émulateurs ou de navigateurs différents ne pose généralement pas de soucis au développeur, autant quand ce dernier doit regarder sur un support natif (le dernier iPhone en date par exemple), il faut qu’il reprenne sa configuration pour la mettre sur le virtual host par défaut et changer plein d’entrées en base de donnée. Là encore la solution réside dans le fait que le device externe puisse résoudre le nom de domaine. Soit il est possible de modifier la configuration de l’appareil pour le faire pointer sur le serveur DNS de la machine, soit il est possible (avec la collaboration d’un gentil administrateur système) de mettre cette résolution sur le serveur DNS du réseau local. Cette dernière technique offre même l’avantage de permettre aux autres utilisateurs du réseau de venir voir son travail et ainsi de partager les bonnes pratiques. De plus la configuration d’un serveur DNS dédié au réseau permet de se passer d’une configuration propre à chaque poste, qui peut s’avérer fastidieuse.
Le mot de la fin
Ce ne sont que quelques astuces qui permettent d’économiser 20 minutes par ci 10 minutes par là, mais au cumulé, les temps ne sont pas négligeables. Et vous, qu’avez-vous trouvé pour aller plus vite ?
