Table des matières
Durant votre carrière de développeur, ou ne serait-ce qu'en amateur, vous apprendrez un jour où l'autre comment utiliser des Hôtes Virtuels (Virtuals Hosts). L'idée derrière ce terme est d'héberger plusieurs noms de domaines sur la même adresse IP locale. Ces domaines sont configurés pour votre serveur Web, et bien que le nom puisse différer, par soucis de consistence, nous utiliserons la terminologie Apache.
Pour cette annexe, nous allons voir comment créer un nom de domaine local, nommé "helloworld.tld", dont l'URL sera http://helloworld.tld. Le principe est quasiment identique pour les noms de domaines publics, la principale différence étant que ceux-ci nécessitent un brin de configuration au niveau des entrées de votre DNS, pour pointer vers le nouveau nom de domaine. Pour des domaines locaux, cela dit, au lieu d'utiliser des entrées DNS, nous pouvons simplement ajouter le nouveau nom de domaine au fichier hosts de votre système, qui est disponible sur la plupart des systèmes d'exploitation, Windows inclu.
La raison pour laquelle nous utilisons des domaines locaux pour le développement est relativement simple : cela nous permet de créer de nouveaux domaines pour chaque projets, et supprime le fait de devoir tous les conserver comme des sous-répertoires de localhost. C'est aussi quelque chose d'extrêmement simple à mettre en place, à partir du moment où vous l'avez déjà fait une première fois, puisque c'est toujours le même principe qui est réutilisé pour chaque domaine : les seuls points qui changent sont le nom du serveur, le chemin vers la racine du projet, et les quelques options de configuration spécifiques dont vous pourriez avoir besoin pour celui-ci.
Pour créer un nouveau domaine local, il vous faut commencer par configurer Apache. Comment cela s'effectue pour les Virtual Hosts dépend des systèmes, donc considérons que vous travaillez sur une machine sous Ubuntu ; et nous verrons quelques notes alternatives, plus particulièrement destinées aux systèmes sous Windows.
Ubuntu utilise une installation standardisée pour les Virtual Hosts Apache et les modules, qui est assez pratique lorsqu'il s'agit de configuration : les Virtual Hosts sont définis dans des fichiers enregistrés dans /etc/apache2/sites-available et nommés de la manière dont vous le souhaitez (bien que, de toute évidence, utiliser un nom de fichier en rapport avec le nom du domaine soit préférable - j'utilise généralement le nom du domaine lui-même). Ce découpage de la configuration en de nombreux fichiers permet de mieux les gérer, unitairement. Nombre d'autres systèmes ont plutôt tendance à n'utiliser que le fichier de configuration principal, httpd.conf ou apache2.conf, ou un unique fichier de configuration pour tous les Virtual Hosts, comme httpd-vhosts.conf.
Le fichier de configuration d'un Virtual Hosts basic, que nous utiliserons, est le suivant :
# Setup Listening Port NameVirtualHost *:80 # Ensure "localhost" is preserved unchanged pointed # to the default document root for our system. <VirtualHost *:80> ServerName localhost DocumentRoot /var/www </VirtualHost> # Setup "helloworld.tld" Virtual Host <VirtualHost *:80> ServerName helloworld.tld DocumentRoot /home/padraic/www/helloworld/public <Directory /home/padraic/www/helloworld/public> Options Indexes FollowSymLinks Includes AllowOverride All Order allow,deny Allow from all </Directory> </VirtualHost>
Sous Ubuntu, nous implémenterions cette configuration en commençant par éditer le fichier /etc/apache2/ports.conf de manière à ce qu'il contienne ceci :
# Setup Listening Port NameVirtualHost *:80
Puisque, par défaut sous Ubuntu, localhost est défini avec un DocumentRoot pointant sur /var/www dans le fichier de configuration /etc/apache2/sites-available/default, la seule chose que nous ayons besoin de réaliser est la création d'un nouveau fichier, /etc/apache2/sites-available/helloworld.tld, qui contiendra la configuration du domaine helloworld.tld :
# Setup "helloworld.tld" Virtual Host <VirtualHost *:80> ServerName helloworld.tld DocumentRoot /home/padraic/www/helloworld/public <Directory /home/padraic/www/helloworld/public> Options Indexes FollowSymLinks Includes AllowOverride All Order allow,deny Allow from all </Directory> </VirtualHost>
Sous Windows, en utilisant XAMPP par exemple, vous éditeriez le fichier C:/xampp/apache/conf/extra/http-vhosts.conf, puisqu'il n'y a pas de fichier de configuration séparé pour les ports ou les domaines spécifiques. Pour être certain que le fichier de vhosts soit chargé, le fichier de configuration principal de XAMPP, http.conf, devrait inclure la ligne suivante :
# Virtual hosts Include conf/extra/httpd-vhosts.conf
Et voici un exemple de configuration pour XAMPP pour Windows :
# Setup Listening Port NameVirtualHost *:80 # Ensure "localhost" is preserved <VirtualHost *:80> ServerName localhost DocumentRoot "C:\xampp\htdocs" </VirtualHost> # Setup "helloworld" Virtual Host <VirtualHost *:80> ServerName helloworld.tld DocumentRoot "C:\projects\helloworld\public" <Directory "C:\projects\helloworld\public"> Options Indexes FollowSymLinks Includes AllowOverride All Order allow,deny Allow from all </Directory> </VirtualHost>
Toute autre variation sous Windows ressemblera à quelque chose de ce type. Si vous êtes bloqué, cela dit, ajoutez simplement vos entrées de configuration à la fin du fichier de configuration principal d'Apache.
La configuration présentée ci-dessus crée deux noms de domaine : localhost, et helloworld.tld. Recréer localhost peut sembler un peu étrange, mais c'est nécessaire pour assurer qu'il reste intacte et utilisable comme nom de domaine reconnu par Apache lorsque nous utilisons des Virtual Hosts. La section après la configuration de localhost crée un nouveau Virtual Host avec un nom de serveur égal à "helloworld.tld", qui devrait indiquer à Apache quel DocumentRoot utiliser, à partir du moment où nous saisirons http://helloworld.tld dans notre navigateur. Puisque nous travaillons avec Zend Framework, le DocumentRoot est toujours le répertoire /public de l'application. Notez aussi que celle-ci peut être enregistrée à peu près n'importe où, ce qui vous donne une plus grande flexibilité sur l'endroit où vous choisissez d'enregistrer les fichiers la composant. Vous pourriez tout à fait utiliser des sous-répertoires de votre Home sous Linux, comme /www ou /public_html, ou un répertoire /www sur votre disque C: sous Windows. En fait, le nom du répertoire est sans importance : c'est juste une convention permettant de rapidement savoir à quoi il correspond... Mais libre à vous de l'appeler ChariotsDeFeu si vous le souhaitez !
L'étape finale est d'ajouter une entrée de configuration nommée Directory pour le DocumentRoot du nouveau VirtualHost. Cela permet de s'assurer qu'Apache peut servir des fichiers depuis ce répertoire, en fournissant les permissions appropriées. Apache ne servira pas de fichier depuis un répertoire si les droits d'accès nécessaires n'ont pas été définis. Par défaut, les options sont fortement restrictives, pour empécher tout accès non autorisé depuis le Web, donc ajoutez bien ceci, pour permettre aux fichiers d'être servis depuis le DocumentRoot. Les options que j'utilise ici sont celles qu'Apache applique généralement au DocumentRoot correspondant à localhost ; elles sont dans l'ensemble plutôt permissives, et permettent d'utiliser des fichiers .htaccess, de façon à ce que les utilisateurs puissent accèder aux options de configuration d'Apache à l'exécution.
Pour activer le VirtualHost sous Ubuntu, nous devons exécuter la commande qui suit, pour créer un lien symbolique vers le nouveau fichier de configuration, qui le rende accessible depuis /etc/apache2/sites-enabled/helloworld.tld :
sudo a2ensite helloworld.tld sudo /etc/init.d/apache2 reload
Si vous êtes sous Windows ou une autre variante de Linux, redémarrer Apache devrait suffir, puisqu'il est probable que vous n'utilisiez pas la même organisation de répertoires pour ces systèmes. La méthode retenue par Ubuntu permet de mettre un site hors-ligne en utilisant la commande opposée : a2dissite.
Il existe des commandes similaires, comme a2enmod et a2dismod pour activer/désactiver des modules plus facilement qu'en éditant manuellement des fichiers de configuration.
Nous n'avons pas encore tout à fait terminé : il reste le problème de faire correspondre le nouveau domaine "helloworld" à la bonne adresse IP locale. Cela se fait facilement, en ajoutant le nouveau nom de domaine au fichier HOSTS de votre système, qui fait la correspondance entre des domaines définis localement et leurs adresses IP.
Sous Ubuntu, le fichier est accessible à /etc/hosts, et vous pouvez l'éditer en utilisant quelque chose de ce genre :
sudo nano /etc/hosts
Nous pouvons alors faire en sorte que notre système reconnaisse le domaine local que nous voulons utiliser pour la configuration de notre nouveau Virtual Host, en modifiant ce fichier en quelque chose de ce style :
127.0.0.1 localhost 127.0.0.1 helloworld.tld 127.0.1.1 padraic-desktop # The following lines are desirable for IPv6 capable hosts ::1 ip6-localhost ip6-loopback fe00::0 ip6-localnet ff00::0 ip6-mcastprefix ff02::1 ip6-allnodes ff02::2 ip6-allrouters ff02::3 ip6-allhosts
Rien d'autre n'est
nécessaire - ajoutez juste l'association de notre domaine et de l'adresse
IP locale. Sous Windows, vous remarquerez que ce fichier n'est
généralement éditable que par un Administrateur, ce qui peut signifier, au
moins sous Windows Vista, qu'il sera peut-être nécessaire d'ajuster vos
niveaux de permissions de façon temporaire, ou d'ouvrir un éditeur avec
des droits d'Administrateur pour l'éditer. Sinon, le principe est
globalement le même ; et vous pouvez trouver le fichier en suivant le
chemin suivant :
C:\Windows\System32\drivers\etc\hosts
et modifier son
contenu en vous inspirant de ceci :
# Copyright (c) 1993-2006 Microsoft Corp. # # This is a sample HOSTS file used by Microsoft TCP/IP for Windows. # # This file contains the mappings of IP addresses to host names. Each # entry should be kept on an individual line. The IP address should # be placed in the first column followed by the corresponding host name. # The IP address and the host name should be separated by at least one # space. # # Additionally, comments (such as these) may be inserted on individual # lines or following the machine name denoted by a '#' symbol. # # For example: # # 102.54.94.97 rhino.acme.com # source server # 38.25.63.10 x.acme.com # x client host 127.0.0.1 localhost 127.0.0.1 helloworld.tld ::1 localhost
Dans les deux cas, nous voyons que le domaine helloworld.tld correspond à l'adresse 127.0.0.1 (la même IP que localhost, mais Apache verra la différence, et utilisera le bon VirtualHost, en fonction du nom utilisé). Ne vous inquiètez pas à propos de la référence ::1 que vous voyez là, c'est un schéma d'adresse IPv6 auquel nous ne toucherons pas pour l'instant. Je vous suggère au passage de vous documenter un peu plus au sujet du fichier HOSTS, afin de comprendre les différentes options qui s'offrent à vous, comme l'utilisation de plusieurs IPs locales.
Au cours de cette annexe, nous avons vu comment créer et activer des Virtual Hosts pour nos domaines locaux. Il n'y absolument rien d'effrayant dans cette idée ! Créer de nouveaux hosts est une pratique habituelle et simple, une fois que vous vous êtes fait à l'idée de ne plus regoruper vos projets sous le DocumentRoot par défaut d'Apache. Avec un peu de pratique, vous pourrez mettre à la place non seulement des domaines, mais aussi leurs sous-domaines ; ce qui vous permettra de répliquer parfaitement les conditions d'hébergement auxquelles vous ferez face une fois le projet déployé en production. Cela vous permet de tester des techniques d'optimisation de performances comme l'hébergement d'images statiques, CSS, et Javascript sur un ensemble de sous-domaines pour contourner les limites de connexions simultanées des navigateurs récents (un goulot d'étranglement fréquent lors du téléchargement de pages Web), et vous donne un véritable domaine avec lequel travailler, plutôt qu'un quelconque sous-répertoire où un chemin doit être utilisé en préfixe de tous les fichiers à charger. Je suis certain que vous trouverez un grand nombre d'usage possibles, et ce que vous avez appris ici est aussi applicable sur vos serveurs de production, où créer des Virtual Hosts pour vos domaines enregistrés et hébergés est non seulement commun, mais aussi nécessaire, du moins si vous n'utilisez pas un outil d'administration intermédiaire.
Tout au long du livre, nous ferons allusion à d'autres options de configuration que vous pourrez ajouter à votre Virtual Host, puisque nous n'avons abordé ici que les premiers quelques points absolument nécessaires.