Maintenant que notre serveur sait communiquer avec Varnish, on va passer ce dernier en « frontal » sur le port http standard (:80). On dira à Apache d’écouter un port secondaire (:8080). Les visiteurs interrogeront donc Varnish, qui ira le cas échéant interroger Apache.
Ultimes vérifications
D’abord, quelques vérifications du bon fonctionnement du système. Un outil indispensable pour vérifier les entêtes est curl
, qu’on va lancer dans une fenêtre shell :
curl -D head http://localhost/spip-2.1/ >/dev/null && cat head
Voici le résultat typique :
Concentrons-nous sur l’entête qui nous intéresse :
On voit ici que SPIP a bien envoyé l’entête destiné à Varnish.
Maintenant, si on regarde la même page telle que servie par Varnish, sur le port temporaire (:6081) :
curl -D head http://localhost:6081/spip-2.1/ >/dev/null && cat head
on obtient :
Concentrons-nous sur les entêtes pertinents :
On voit que Varnish a traité cette requête (qui a pour n° 1133668195), et qu’il est allé demander la ressource à Apache.
Maintenant lançons une deuxième fois la commande ; le bloc ci-dessus devient :
Ici on voit que notre réponse (1133668226) a été servie depuis la mémoire cache de Varnish, qui est allé chercher la ressource qu’il avait obtenue lors de la requête 1133668195 ; la ressource date d’il y a 10 secondes.
Continuons à surveiller X-Varnish-Age:
en lançant la commande de manière répétitive :
watch "curl -D head http://localhost:6081/spip-2.1/ >/dev/null 2>/dev/null && cat head"
On voit toutes les deux secondes que l’âge de la page demandée augmente de deux secondes… tout va bien. Maintenant via le navigateur allons modifier un contenu, ou recalculer une page, via l’URL d’origine (port :80). On constate que la page n’est pas rafraichie. En effet le système ne se purge que lorsque la modification de contenu passe par Varnish.
Allons maintenant modifier le contenu en nous connectant à travers Varnish (sur la port :6081) : on constate que l’âge de la ressource retombe à zéro à chaque fois qu’on fait une modification.
Installer Varnish en frontal
Désormais il ne reste plus qu’à installer Varnish sur le port :80 ; pour cela il faut :
— configurer Apache pour qu’il écoute le port :8080 à la place du port :80 (probablement en éditant /etc/apache2/ports.conf
).
— configurer Varnish pour qu’il aille chercher les ressources sur 127.0.0.1:8080
; c’est au début du fichier /etc/varnish/default.conf
backend default {
.host = "127.0.0.1";
.port = "80";
...
}
— relancer Apache puis lancer Varnish sur le port 80 ; sur Debian, on va modifier la variable VARNISH_LISTEN_PORT=6081
dans /etc/default/varnish
, puis relancer.
On peut ensuite répéter les tests ci-dessus, en remplaçant les numéros de ports par :80 (pour Varnish) et :8080 (pour Apache).
Fignoler
Fermer l’accès direct à Apache. Si le serveur Apache répond à tout l’Internet sur le port :8080, il est probable que Google le repérera et viendra lui parler directement, indexant ainsi deux fois les sites (sur chacun des ports), et allant à l’encontre du but visé. Il faut donc configurer Apache pour qu’il ne réponde que sur localhost (127.0.0.1
).
Obtenir l’IP du client en aval. Désormais le « client » que voit Apache est toujours Varnish, donc une même machine ayant un seul numéro IP. Ce n’est pas génial ni pour les logs, ni pour des logiciels qui peuvent vouloir faire du contrôle d’accès ou de la géolocalisation à partir du numéro IP. Pour résoudre ce problème, le plus simple est d’installer l’extension pour Apache nommée mod_rpaf
(http://stderr.net/apache/rpaf/) : celle-ci permet de « faire croire » à Apache que le numéro IP est bien celui du client en aval. Ainsi la manipe est totalement transparente pour les applications, qui du coup n’ont pas besoin d’être modifiées ni configurées.
2 Messages de forum