xip.io en clair
Posté le 2 avril 2016 dans Développement
L’année dernière, j’avais twitté à propos d’un service obscur du nom de xip.io qui permet, je me cite, de “tester la responsivité de vos sites sur un iPhone / Android / etc sur votre machine de développement sans rien configurer”.
Je pense que ce service - gratuit de surcroît - mérite un article dédié afin qu’un maximum de développeurs (front ou back) en comprennent son utilité et puissent ensuite l’utiliser pour se simplifier la vie à fond.
Si les explications ne vous intéressent pas et que vous souhaitez juste le mettre en place, scrollez directement plus bas.
Mise en situation¶
Prenons une situation courante que nous connaissons tou.te.s.
Votre poste de développement possède l’IP 192.168.0.5 sur votre réseau local. Dans la liste des hosts de votre ordi, vous avez très certainement une ligne du style :
monprojetquidechire.dev 127.0.0.1
Un serveur web local écoute certainement sur le port 80 avec un virtual host qui traite toutes les requêtes HTTP à destination de monprojetquidechire.dev et les redirige vers le dossier /var/www/monprojetquidechire/public.
Du coup, sur votre poste à vous, quand vous allez sur monprojetquidechire.dev, vous arrivez sur votre projet hébergé sur votre propre machine. Normal 🙂
Quelqu’un d’autre veut accéder à votre projet¶
A un moment donné, vous souhaitez que d’autres personnes puissent accéder à votre projet (avec un smartphone, pc portable, tablette, whatever), par exemple pour tester la “responsivité” de votre projet.
Et là c’est le drame.
- Il tape http://monprojetquidechire.dev sur son navigateur : DNS Error. Évidemment : il n’y a que votre poste qui sait résoudre cette adresse ;
- Il tape votre IP locale (http://192.168.0.5) sur son navigateur : il arrive sur… la page par défaut de votre serveur web, et non pas votre projet. Ben oui : pour votre serveur web local, 192.168.0.5 n’appartient à aucun virtual host, et vous redirige donc vers son virtual host “localhost” (127.0.0.1) défini par défaut sur la plupart des serveurs web. Dans le pire des cas, la requête n’aboutira pas ;
- Il tape http://192.168.0.5/monprojetquidechire/public (parce qu’il est malin le bougre) correspondant au répertoire root de votre projet. Si votre projet a obligatoirement besoin d’un vrai virtual host pour fonctionner correctement (URLs des assets et des liens hypertexte, etc) : PAF, les pages seront dégueu ou afficheront une grosse erreur 404. Pire, il se peut que, sous nginx, les scripts PHP ne soient carrément pas exécutés car souvent le pont entre nginx et PHP-FPM est défini au niveau du virtual host lui-même. Comme vous ne taperez pas dessus, nginx s’en foutra royalement.
A ce moment, plusieurs solutions s’offrent à vous :
- Demandez à votre collègue de rajouter cette ligne à son fichier hosts :
monprojetquidechire.dev 192.168.0.5 # L'IP de votre poste de dev
Votre poste doit être configuré en IP statique, sinon il faudra qu’il modifie régulièrement cette ligne. SAUF QUE : comment faire avec un smartphone ? Une tablette ? AHAH !
- Configurer un proxy HTTP manuel pour le forcer à taper sur 192.168.0.5:80
Du coup, TOUTES les requêtes HTTP effectuées arriveront sur votre machine de dev. Il ne pourra donc plus qu’accéder à monprojetquidechire.dev, tout le reste des internets s’arrêtera de fonctionner. Il faudra donc qu’il désactive cette configuration une fois qu’il aura fini : ça peut vite devenir chiant à faire (c’est la solution que j’ai utilisée à mon boulot jadis).
- Installer un serveur DNS local du style Dnsmasq
A kind of magic¶
Ne cherchez plus. Comme son slogan l’indique (wildcard DNS for everyone), xip.io permet de faire des résolutions DNS spéciales qui redirigent toujours vers une IP arbitraire (je sais, ça fait un peu marketeux comme je vous le présente mais vous gagnerez un temps fou). Mais comment est-ce possible ?
D’après leur site, ils utilisent un serveur DNS perso couplé à un serveur web qui traite un certain format d’URL :
domainelocal.xx.xx.xx.xx.xip.io
domainelocal: habituellement votre domaine de développement. Ça peut être monprojet, monprojet.dev, mon.projet, etc, pourvu qu’il soit bien configuré sur votre poste de dev ;xx.xx.xx.xx: l’IP locale de la machine qui héberge votre projet.
Dans notre exemple, si je vais sur monprojetquidechire.dev.192.168.0.5.xip.io en étant connecté sur votre réseau local, ça me redirigera toujours vers votre poste (192.168.0.5), et comme xip.io supporte le header HTTP Host, votre serveur web saura où diriger ma requête pour finalement atterrir sur votre projet hébergé sous monprojetquidechire.dev.
Comment le mettre en place¶
J’ai un peu menti tout à l’heure, il y a un petit paramètre de configuration à rajouter dans votre virtual host. Mais tout petit hein. Le voici en fonction du serveur web utilisé.
Apache¶
Rajoutez une directive ServerAlias. Dans notre cas :
ServerAlias monprojetquidechire.dev.*.xip.io
Nginx¶
Rajoutez, dans votre directive server_name, tout ce qui existe après le tilde inclus (~) :
server_name monprojetquidechire.dev ~^monprojetquidechire\.dev\.\d+\.\d+\.\d+\.\d+\.xip\.io$;
lighttpd¶
J’ai un peu cherché comment faire mais vu la gueule de ses fichiers de config j’ai vite abandonné (ça explique peut-être pourquoi je ne l’ai jamais utilisé). Faites moi savoir si vous savez comment faire.
Pour finir¶
N’oubliez pas de recharger la configuration de votre serveur après modifications. Puis allez sur http://monprojetquidechire.dev.192.168.0.5.xip.io, et ça devrait fonctionner.
xip.io est finalement une solution plutôt simple à mettre en place, mais notez que :
- Si vous n’avez plus internet ou si xip.io est mort : ça ne fonctionnera plus ;
- Vous devez configurer votre poste de dev avec une IP statique, sinon l’IP dans l’URL devra être à chaque fois modifiée.