Créer rapidement des sites en local

Un petit article très technique, qui pourra être utile à des développeurs Web qui veulent créer rapidement des sites en local sans se prendre la tête.

Je ne sais pas pour vous, mais j’ai souvent besoin de créer des sites qui me servent à prototyper des développements ou à tester des évolutions sur mon framework. Habituellement, cela se passe en plusieurs étapes :

  1. Je crée une entrée dans le fichier /etc/hosts, pour que le nom de domaine du site pointe sur la machine locale.
  2. Je crée un fichier pour configurer le “virtual host” dans Apache.
  3. Je redémarre Apache.
  4. Enfin, je peux créer le site lui-même.

Ce n’est pas grand-chose à faire, mais multiplié par le nombre de sites, c’est un peu pénible. En plus, quand on veut coder un truc vite fait, on n’a vraiment pas envie de perdre du temps à faire tout ça. En ce qui concerne mes projets personnels, je développe mes “vrais” projets sur un serveur distant ; par contre, je préfère coder les petits trucs rapides en local.

Dans mon entreprise, on a en partie contourné le soucis, mais on continue à créer des fichiers de configuration Apache (on ne fait pas de «projets-kleenex»). Je vais vous expliquer comment je fais pour gérer mes projets personnels.

Nom de domaine

La première chose à faire, c’est de pouvoir facilement se connecter au serveur web du poste local. Si on veut créer un petit site de test, on a envie de pouvoir taper «http://sitedetest.com» dans son navigateur, sans se prendre la tête à modifier le fichier /etc/hosts ou à gérer un serveur DNS.

J’ai donc utilisé le nom de domaine «ordi.org», que je possède depuis un paquet d’années sans rien en faire. J’ai configuré le DNS de ce nom de domaine pour qu’il retourne l’adresse IP 127.0.0.1 (qui correspond toujours à la machine locale, j’espère que je ne vous l’apprend pas), quel que soit le nom de machine demandé. Ainsi, si je saisi «http://sitedetest.ordi.org», «http://site1.pouet.ordi.org» ou «http://site2.pouet.ordi.org», ça me renverra systématiquement vers la machine sur laquelle je suis.

C’est simple, c’est pratique. Vous pouvez l’utiliser si vous voulez. Je ne garantis pas que ce fonctionnement restera ainsi éternellement, mais vu que je l’utilise de cette manière pour mon propre usage, vous pouvez y aller assez sereinement.

La seule chose un peu chiante, c’est lorsque je développe sans être connecté à Internet (sur mon ordinateur portable dans le train, par exemple). Dans ce cas-là, la résolution DNS ne fonctionne pas. Il serait possible de configurer un serveur DNS local − auquel cas choisissez Dnsmasq, qui est bien plus simple et léger que Bind − mais ça reste un peu un gros canon pour écraser une petite mouche. Comme il m’arrive rarement de travailler sur beaucoup de sites en parallèle, je préfère encore modifier temporairement le fichier /etc/hosts…

Configuration Apache

Les «virtual hosts dynamiques» sont des petites merveilles qui simplifient la vie comme pas possible. À une époque, je créais un fichier de configuration pour chaque nouveau site que je développais.

Voici un exemple de fichier /etc/apache2/sites-available/default comme on peut en trouver sur une distribution Linux Debian/Ubuntu standard, modifié par mes soins pour permettre le chargement automatique de tous les sites locaux que l’on souhaite :

UseCanonicalName Off
LogFormat "%V %h %l %u %t \"%r\" %s %b" vcommon
CustomLog logs/access_log vcommon
VirtualDocumentRoot /opt/http/%0/www

(suivant les outils utilisés − notamment le framework − vous aurez peut-être besoin d’ajouter des directives supplémentaires)

Hop, juste 4 petites lignes et ça marche. Et encore, il y a 2 lignes qui sont là pour configurer le fichier de log, on pourrait éventuellement s’en passer (ça ne serait pas une bonne idée, mais c’est possible).

Pour chaque connexion locale, le serveur Apache ira chercher dans le répertoire spécifié par la directive «VirtualDocumentRoot», en remplaçant la chaîne «%0» par le virtual host demandé.
Si on prend l’exemple du site «sitedetest.ordi.org», il faudra créer un répertoire /opt/http/sitedetest.ordi.org qui devra contenir un sous-répertoire www qui sera la racine du site.

Le tout combiné me permet, pour chaque nouveau site, d’avoir simplement à créer deux répertoires. Et comme j’ai des scripts qui me permettent de générer automatiquement l’arborescence des projets basés sur mon framework, la création d’un site local se résume à l’exécution d’une commande.

13 commentaires pour “Créer rapidement des sites en local

  1. Ou alors développer en rails qui propose son propre serveur web pour tester en local (ah c’est vendredi, jour de sortie des trolls 😈 )

  2. Ouaip, je m’attendais à ce genre de troll 😉
    Justement, j’ai du mal à voir en quoi Pow est un truc si incroyable…

    Parce que bon, pour moi ça donne simplement :
    1. apt-get install apache2 mysql-server php5 php5-mysql
    2. Création du virtual host dynamique

    Et ça y est, c’est fini ! Au passage, utiliser la même plate-forme qu’en production (Apache et MySQL) permet d’éviter les surprises le jour où on monte les développements en prod…

  3. Très bonne astuce que je ne connaissais pas.

    Cependant je vois pas en quoi passé par un serveur DNS plutôt que /etc/hosts cela simplifie l’opération ?
    Car si tu as besoin de 2 noms de domaines, tu dois en crée 2 sur le DNS ce qui n’est pas forcément plus simple qu’un ajout dans /etc/hosts.

    Tu dis que tu développes directement sur des serveurs distants. Tu utilise SSHFS ou autre pour ca ?(Avec quel éditeur ?)

    Personnellement, même quand je développe sur un serveur distant je modifie mon /etc/hosts et celui du serveur pour ajouter le nom de domain du projet.
    Ca évite qu’un visiteur/client tombe dessus par hasard et puisse avoir acces à un site en développement et par la même occasion à des données qui ne devrait pas être rendu « publique ».

  4. Et bien son serveur DNS n’a besoin que d’être configuré une fois pour toutes, alors que la modif de /etc/hosts doit être faite à chaque fois …

    perso j’ai opté pou un script qui modifie le fichier hosts, copie un VHost modèle dans les sites-availables, fais le lien dans sites-enabled (je ne connaissais pas a2ensite), crée une base mysql avec un compte login:mdp correspondant au nom du site.

  5. @Paul : Imagine que tu travailles sur 25 sites en local. Il faut ajouter 25 entrées dans ton fichier /etc/hosts. Alors que dans là, il suffit que tes sites s’appellent «quelquechose.ordi.org» et tu n’as rien à configurer ! J’ai ajouté dans le DNS une directive qui fait pointer «*.ordi.org» vers l’adresse 127.0.0.1. Plus besoin de toucher au fichier /etc/hosts.
    Le seul soucis, comme je disais, c’est lorsque la machine locale n’est pas connectée à Internet, et donc que la résolution DNS n’est pas accessible.

    Sinon, je code directement sur mon serveur distant en utilisant autant de connexions SSH que nécessaire, avec un éditeur vi ouvert dans chaque terminal.

  6. @niahoo : Oui, j’ai aussi fonctionné avec ce genre de scripts. Mais là, avec les vhosts dynamiques et le DNS adapté, c’est encore plus rapide !

  7. Ah je n’avais pas compris que tu avais mis un « *.ordi.org » c’est pour ca que je ne comprenais pas.

    VI ? VI gère-t-il facilement les mélanges HTML/CSS/JS/PHP (présent dans les vue) ?
    Il peut faire aussi de la complétion sur les méthodes de classes & co ?

  8. Non, pas de complétion de code. Mais avec de la documentation PHPDoc à côté, je code plus vite avec vi que mes développeurs sous Eclipse. J’ai souvent au moins 5 onglets ouverts dans mon terminal, chacun avec un vi qui édite un fichier différent. Dans un autre écran virtuel, j’ai d’autres terminaux ouverts sur les fichiers de log et la base de données. Un autre écran virtuel contient le navigateur web. Avec tout ça je suis productif.

    Pour les vues, on utilise des templates Smarty, et vi gère très bien la coloration syntaxique.

  9. Oui, je sais bien. Sauf que tu ne peux avoir qu’un seul virtual host répondant au nom “localhost”. Comment fais-tu lorsque tu veux travailler sur plusieurs sites en parallèle ? (ce qui est quand même le cas la plupart du temps)

  10. ben sous-domaine.localdomain ou sous-domaine.localhost non ?

  11. Non, sauf si tu ajoutes sous-domaine.localhost et sous-domaine.localdomain dans ton fichier /etc/hosts.

    Tu n’as qu’à essayer de faire un ping sur ces adresses. Tu obtiendras «unkown host sous-domaine.localhost».

  12. Exact, cela ne permet d’un seul domaine si on utilise localhost.

    Enfin, quand je développe en local, j’ai quand même un serveur pas bien loin.. Et la modification du fichier hosts est assez rapide à vrai dire.

    Le seul soucis, c’est que j’oublie parfois de re-modifier le fichier hosts, et du coups je n’ai plus acces à certains sites.. Moment de panique en général 😀

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Notifiez-moi des commentaires à venir via email. Vous pouvez aussi vous abonner sans commenter.