Varnish est un reverse-proxy HTTP. Il se met typiquement devant des serveurs HTTP et garde en cache les réponses autant que possible. Il gère également (un peu) le load-balancing entre les serveurs HTTP.
Le fichier `/etc/default/varnish` [n'est plus utilisé en Debian 8 avec Systemd](https://bugs.debian.org/749272). Malheureusement cela provoque un bug : le script `/usr/share/varnish/reload-vcl` l'utilise toujours... pour éviter toute confusion, on supprime */etc/default/varnish* et l'on remplace *ExecReload=* par un script minimal.
*`-a` : spécifie *IP*:*port* sur lequel Varnish écoute pour les requêtes HTTP. On peut ainsi spécifier une IP secondaire pour coexister avec un autre service HTTP (Apache, Nginx) sur le port 80 (*-a 192.0.2.1:80*) ou faire écouter Varnish uniquement en local (*-a 127.0.0.1:8080*) ou alors le faire écouter de partout (*-a 0.0.0.0:80*) ou même spécifier plusieurs IP (*-a 0.0.0.0:80,127.0.0.1:81*)
*`-T` : spécifie l'interface d'admin de Varnish, accessible avec `varnishadm`
Par défaut, Varnish n'écrit pas ses logs dans un fichier, mais dans un segment mémoire, ce qui permet d'augmenter grandement les performances. Quand l'espace est plein, Varnish réécrit par dessus en repartant de l'origine, ce qui fait que la mémoire allouée pour les logs n'augmente pas. On peut voir des logs en direct avec les outils varnishstat (stats de Varnish), varnishtop (*top* pour Varnish), varnishlog (logs verbeux) ou varnishnsca (logs au format NCSAcomme Apache) :
~~~
# varnishstat
# varnishtop -i ReqURL
# varnishlog
# varnishnsca
~~~
Des filtres peuvent être appliqués sur ces commandes, voici des exemples pratiques pour le debug :
Il est aussi possible d'écrire ces logs dans des fichiers en lançant varnishlog et varnishnsca en mode démon (lancés par défaut sous Debian 8). Ce démon est indépendant de *varnishd*, ce qui a l'avantage de ne pas ralentir les performances ; *varnishd* n'attend pas que la ligne de log soit écrite dans le fichier avant de servir la page : il l'inscrit en mémoire, et c'est ensuite *varnishlog* ou *varnishncsa* qui se chargera de copier la ligne dans le fichier sur le disque.
La syntaxe VCL est complexe mais puissante. On découpe un fichier VCL en plusieurs sous-routines dans lesquelles on définit des actions/comportements en fonction de certaines conditions. Les sous-routines principales sont *vcl_recv* et *vcl_backend_response* :
* **vcl_recv** est appelé AVANT le début de la requête au backend. On peut donc choisir vers quel backend renvoyer la requête. On peut aussi modifier la requête (modifier des entêtes HTTP, supprimer des demandes de cookies, etc.). Seules les actions `set req.` sont possibles.
* **vcl_backend_response** (remplace **vcl_fetch** depuis Varnish 4) est appelé APRÈS la réception de la réponse du backend. Les actions `set bereq.` (équivalentes à `set req.` dans *vcl_recv*) sont possibles, mais aussi `set beresp.` (pour *backend response*).
Attention, Varnish charge [ses propres sous-routines par défaut](#configuration-par-défaut) et si on veut changer son comportement il est impératif de copier la sous-routine par défaut (voir [#configuration-par-défaut]()) puis de la modifier !
Voyons un exemple simple :
~~~
sub vcl_recv {
if (req.http.host ~ "(www\.example\.com|example\.com)") {
Par défaut Varnish respecte le comportement standard d'un reverse-proxy : pas de cache en présence de cookie, respect des entêtes HTTP envoyés par le client et backend : sa configuration par défaut devrait convenir pour les sites codés correctement ! L'avantage est que l'on peut facilement intervenir sur ce comportement standard pour ajouter des exceptions... si le code d'un site est incorrect.
Le temps de mise en cache par défaut peut être défini avec l'option `-t` à [#varnishd](). Par défaut il est à 120 secondes. On peut le changer avec `set beresp.ttl` :
Grâce aux règles VCL on peut vraiment définir finement la mise en cache ou pas, en complément des entêtes de cache renvoyés par le code. On peut ainsi mettre en cache même si certains cookies sont présents, en les supprimant de la requête.
Varnish ne permet pas de lister le contenu de son cache. En revanche, pour savoir si la taille du cache est correctement dimensionnée on peut se baser sur certaines valeurs retournées par la commande *varnishstat*, en particulier *MAIN.n_lru_nuked* qui est incrémentée à chaque fois qu'un objet est expulsé du cache pour pouvoir en cacher un autre :
~~~
# varnishstat -1 -f MAIN.n_lru_nuked
~~~
## Load-balancing
Si vous avez plusieurs serveurs web, Varnish gère le load-balancing : il permet de mettre plusieurs serveurs en backend et d'y accéder avec du round-robin. On peut également configurer une vérification de chaque backend, en précisant la page qui sert à la vérification et les paramètres (timeout, intervalle, etc.).
Voici un exemple avancé :
~~~
backend www00 {
.host = "192.0.2.6";
.port = "80";
.connect_timeout = 1s;
.first_byte_timeout = 3s;
.between_bytes_timeout = 2s;
.max_connections = 50;
.probe = {
.request = "GET / HTTP/1.1"
"Host: www.example.com"
"User-Agent: test Varnish"
"Connection: close"
"Accept-Encoding: text/html" ;
.timeout = 1000ms;
.interval = 5s;
.window = 8;
.threshold = 6;
}
}
backend www01 {
.host = "127.0.0.1";
.port = "80";
.probe = {
.url = "/"
.timeout = 800ms;
.interval = 10s;
.window = 8;
.threshold = 6;
}
}
director baz round-robin {
{ .backend = www00; }
{ .backend = www01; }
}
~~~
Une fois les backends ou directors définis, il faut les utiliser dans les règles. Par exemple :
* Gestion d'un poids pour chaque backend ? Oui, depuis Varnish 2.1.4 on peut préciser des poids pour chaque backend.
* Gestion du maximum de connexions pour un backend ? via le paramètre *.max_connections*
* Gestion d'un backend de secours ? via des règles VCL du type `if (!req.backend.healthy) { set req.backend = default; }`
* Gestion d'un mode sticky (par IP, URL ou user agent) ? cela se fait en remplaçant *round-robin* par client dans la définition du *director*. On peut ensuite définir quel est le paramètre à prendre en compte : `sub vcl_recv { set req.backend = baz; set client.identity = req.ip; /* ou client.url ou req.http.user-agent */ }`
Si besoin, on pourra aussi utiliser en complément le logiciel <http://trac.evolix.net/infogerance/wiki/HowtoHaproxy>
Varnish a une "killer feature" : le *grace mode*. En cas de backend HS, le contenu en cache continuera à être délivré pendant un certain temps même si il est sensé être expiré. Exemple de configuration :
Note : le *saint mode* (qui permet de laisser tranquille pendant un temps définir un backend qui aurait une erreur 500) n'existe plus avec Varnish 4.0... une nouvelle implémentation sera disponible en version 4.1 !
On peut se servir du retour de la commande *varnishadm* pour s'assurer du bon état de santé du démon. Ce plugin Nagios utilise ce principe : <http://exchange.nagios.org/directory/Plugins/Websites%2C-Forms-and-Transactions/check_varnish_health/details>.
La taille maximum d'un objet en cache ne semble limitée que par la taille du cache lui-même. Cela n'est malheureusement pas configurable comme avec Squid.
### Comment prendre en compte un changement de configuration / règles ?
Quand un client HTTP interroge Varnish, il va le mettre en attente afin d'interroger le serveur HTTP final (si l'objet n'est pas caché). Pendant que le serveur HTTP final renvoie l'objet demandé à Varnish, le client HTTP est toujours mis en attente, le contenu lui sera renvoyé seulement une fois l'objet reçu à 100% par Varnish. Cela peut poser différents problèmes : dans le cas d'une grosse vidéo le démarrage sera lent, si le timeout du client HTTP est bas il peut fermer la connexion trop tôt, etc. Pour contourner ce problème, on peut utiliser le return *(pipe)* :