evolix/wiki
22
0
Fork 0
Code Releases Activity

init

Browse source
This commit is contained in:
gcolpart 2016-10-29 23:47:52 +02:00
parent a0a2348435
commit f4c5f46a0d
1 changed files with 738 additions and 0 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

738
HowtoVarnish.md Normal file
View file

@ -0,0 +1,738 @@
---
title: Howto Varnish
categories: web HA cache
...
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.
<https://www.varnish-cache.org/docs/4.0/>
## Installation
~~~
# aptitude install varnish
# varnishd -V
varnishd (varnish-4.0.2 revision bfe7cd1)
Copyright (c) 2006 Verdens Gang AS
Copyright (c) 2006-2014 Varnish Software AS
~~~
## Configuration de base
### varnishd
<http://www.varnish-cache.org/docs/4.0/reference/varnishd.html>
`/etc/default/varnish` :
~~~
umask 022
DAEMON_OPTS="-a 0.0.0.0:80 \
-T localhost:6082 \
-f /etc/varnish/default.vcl \
-S /etc/varnish/secret \
-s malloc,2G \
-p thread_pools=<Nombre de cores CPU> \
-p thread_pool_add_delay=2 \
-p thread_pool_min=500 \
-p thread_pool_max=5000"
~~~
Détails de certaines options :
* `-a` : spécifie {IP,port} sur lequel Varnish écoute pour les requêtes HTTP. On peut ainsi spécifier une IP secondaire pour cœxister avec un autre service HTTP (Apache, Nginx) sur le port 80 (*-a 192.0.2.1:80*) ou alors faire écouter Varnish uniquement en local (*-a 127.0.0.1:8080*) ou encore le faire écouter de partout (*-a 0.0.0.0:80*)
* `-s` : spécifie où est stocké le cache. Cela peut être en mémoire (*-s malloc,2G*) et/ou dans un fichier (*-s file,varnish_storage.bin,8G*)
* `-T` : spécifie l'interface d'admin web de Varnish
* `-f` : spécifie le fichier des règles Varnish au format VCL (*Varnish Configuration Language*)
### default.vcl
Les règles Varnish définissent la mise en cache en utilisant une syntaxe particulière : le VCL (*Varnish Configuration Language*).
Il faut au minimum configurer le backend :
~~~
backend default {
.host = "127.0.0.1";
.port = "8080";
}
~~~
Pour vérifier ses règles :
~~~
# varnishd -Cf /etc/varnish/default.vcl
~~~
### Gestion des logs
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 NCSA comme Apache) :
~~~
# varnishstat
# varnishtop -i ReqURL
# varnishlog
# varnishnsca
~~~
Des filtres peuvent être appliqués sur ces commandes, voici des exemples pratiques pour le debug :
~~~
# varnishlog -q 'TxHeader eq MISS' -q "ReqHeader ~ '^Host: example\.com$'" |grep RxURL
# varnishncsa -q "ReqHeader eq 'X-Cache: MISS'"
~~~
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.
## Syntaxe VCL
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 de modifier la requête (modifier des entêtes HTTP, supprimer des demandes de cookies, etc.). Seul 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 req.` 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)") {
set req.backend = default;
}
if (req.url ~ "^/images") {
unset req.http.cookie;
}
}
sub vcl_backend_response {
if (req.url ~ "\.(png|gif|jpg)$") {
unset beresp.http.set-cookie;
set beresp.ttl = 3600s;
}
}
~~~
### Configuration par défaut
~~~
sub vcl_recv {
if (req.method == "PRI") {
/* We do not support SPDY or HTTP/2.0 */
return (synth(405));
}
if (req.method != "GET" &&
req.method != "HEAD" &&
req.method != "PUT" &&
req.method != "POST" &&
req.method != "TRACE" &&
req.method != "OPTIONS" &&
req.method != "DELETE") {
/* Non-RFC2616 or CONNECT which is weird. */
return (pipe);
}
if (req.method != "GET" && req.method != "HEAD") {
/* We only deal with GET and HEAD by default */
return (pass);
}
if (req.http.Authorization || req.http.Cookie) {
/* Not cacheable by default */
return (pass);
}
return (hash);
}
sub vcl_pipe {
return (pipe);
}
sub vcl_pass {
return (fetch);
}
sub vcl_hash {
hash_data(req.url);
if (req.http.host) {
hash_data(req.http.host);
} else {
hash_data(server.ip);
}
return (lookup);
}
sub vcl_purge {
return (synth(200, "Purged"));
}
sub vcl_hit {
if (obj.ttl >= 0s) {
// A pure unadultered hit, deliver it
return (deliver);
}
if (obj.ttl + obj.grace > 0s) {
// Object is in grace, deliver it
// Automatically triggers a background fetch
return (deliver);
}
// fetch & deliver once we get the result
return (fetch);
}
sub vcl_miss {
return (fetch);
}
sub vcl_deliver {
return (deliver);
}
sub vcl_synth {
set resp.http.Content-Type = "text/html; charset=utf-8";
set resp.http.Retry-After = "5";
synthetic( {"<!DOCTYPE html>
<html>
<head>
<title>"} + resp.status + " " + resp.reason + {"</title>
</head>
<body>
<h1>Error "} + resp.status + " " + resp.reason + {"</h1>
<p>"} + resp.reason + {"</p>
<h3>Guru Meditation:</h3>
<p>XID: "} + req.xid + {"</p>
<hr>
<p>Varnish cache server</p>
</body>
</html>
"} );
return (deliver);
}
sub vcl_backend_fetch {
return (fetch);
}
sub vcl_backend_response {
if (beresp.ttl <= 0s ||
beresp.http.Set-Cookie ||
beresp.http.Surrogate-control ~ "no-store" ||
(!beresp.http.Surrogate-Control &&
beresp.http.Cache-Control ~ "no-cache|no-store|private") ||
beresp.http.Vary == "*") {
/*
* Mark as "Hit-For-Pass" for the next 2 minutes
*/
set beresp.ttl = 120s;
set beresp.uncacheable = true;
}
return (deliver);
}
sub vcl_backend_error {
set beresp.http.Content-Type = "text/html; charset=utf-8";
set beresp.http.Retry-After = "5";
synthetic( {"<!DOCTYPE html>
<html>
<head>
<title>"} + beresp.status + " " + beresp.reason + {"</title>
</head>
<body>
<h1>Error "} + beresp.status + " " + beresp.reason + {"</h1>
<p>"} + beresp.reason + {"</p>
<h3>Guru Meditation:</h3>
<p>XID: "} + bereq.xid + {"</p>
<hr>
<p>Varnish cache server</p>
</body>
</html>
"} );
return (deliver);
}
sub vcl_init {
return (ok);
}
sub vcl_fini {
return (ok);
}
~~~
### Listes des conditions/actions/comportements
Voici un certain nombre de conditions possibles :
~~~
# Condition sur l'entête HTTP Host:
if (req.http.host ~ "^regex$")
# Présence d'un cookie
if (req.http.cookie) {
# Condition sur l'URL demandée
if (req.url ~ "^/regex$")
# Si le backend est accessible
if (req.backend.healthy)
# Présence entête Accept-Encoding
if (req.http.Accept-Encoding)
# Condition sur la requête faite
if (req.request != "GET" && req.request != "HEAD")
# Présence de l'entête X-Forwarded-For
if (req.http.x-forwarded-for)
# Condition sur les entêtes envoyés
if (req.http.Authorization || req.http.Cookie)
# Condition
if (req.http.Cache-Control ~ "no-cache")
# Si la réponse du backend permet la mise en cache
if (beresp.cacheable)
# Condition sur le temps de mise (Cache-Control: max-age a priori)
if (beresp.ttl < 120s)
# Condition sur le statut des réponses
if (obj.status == 404 || obj.status == 503 || obj.status == 500)
~~~
Voici un certain nombre d'actions possibles :
~~~
# Renvoyer vers un backend
set req.backend = baz;
# Supprimer les cookies dans la requête
unset req.http.cookie;
remove req.http.cookie;
# Supprimer un certain nombre d'entêtes HTTP
remove req.http.X-Forwarded-For;
remove req.http.Accept-Encoding;
# Positionner un certain nombre d'entêtes HTTP pour la requête
set req.http.X-Forwarded-For = client.ip;
set req.http.Accept-Encoding = "gzip";
set req.http.Accept-Encoding = "deflate";
# Positionner un certain nombre d'entêtes HTTP pour la réponse
set obj.http.expires = "Mon, 1 Jan 2007 00:00:01 GMT";
set obj.http.X-foo = "bar";
# Renvoyer une erreur HTTP
error 404 "Page not found";
~~~
Enfin, voici les principaux [comportements possibles](https://www.varnish-cache.org/docs/4.0/users-guide/vcl-built-in-subs.html) :
~~~
# Renvoie vers le backend (pas de cache)
return (pass);
# Renvoie la version en cache (si possible)
return (lookup);
return (deliver);
# Renvoie "directement" vers le backend sans inspection du contenu
return (pipe)
# Redémarre la demande au backend (et incrémente le compteur de restarts)
return (restart);
~~~
## Gestion du cache
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` :
~~~
sub vcl_backend_response {
set beresp.ttl = 1800s;
#unset beresp.http.expires;
set beresp.http.cache-control = "max-age=1800";
set beresp.http.magicmarker = "1";
}
sub vcl_deliver {
if (resp.http.magicmarker) {
unset resp.http.magicmarker;
set resp.http.age = "0";
}
}
~~~
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.
~~~
sub vcl_recv {
if (req.http.Authorization) {
return (pass);
}
if (req.http.Cookie ~ "(VARNISH|DRUPAL_UID)") {
return (pass);
}
}
sub vcl_backend_response {
if (beresp.status == 403 || beresp.status == 404 || beresp.status == 503 || beresp.status == 500) {
set beresp.ttl = 10s;
set beresp.cacheable = true;
}
if (!obj.cacheable) {
set obj.http.X-Cacheable = "NO";
return (pass);
}
}
sub vcl_deliver {
if (obj.hits > 0) {
set resp.http.X-Cache = "HIT";
set resp.http.X-Cache-Hits = obj.hits;
} else {
set resp.http.X-Cache = "MISS";
}
}
~~~
### Purge du cache
On peut purger le cache en ligne de commande.
Purge en une seule ligne :
~~~
# varnishadm -S /etc/varnish/secret -T 127.0.0.1:6082 'ban req.url ~ .'
~~~
Il est recommandé d'utiliser le CLI Varnish (on obtiendra ainsi un code de retour *200*) :
~~~
# varnishadm -S /etc/varnish/secret -T 127.0.0.1:6082
varnish> ban req.url ~ ".png$"
200
varnish> ban req.http.host == www.example.com
200
varnish> ban req.http.host ~ .
200
~~~
On peut aussi purger avec une requête HTTP **PURGE** :
~~~{.bash}
$ curl -X PURGE http://www.example.org/foo.txt
~~~
Il faut alors configurer Varnish pour accepter cette requête :
~~~
acl local {
"localhost";
"192.0.2.12";
}
sub vcl_recv {
# placer cette directive en premier, sinon une autre risque de matcher avant et la purge ne sera jamais effectuée
if (req.request == "PURGE") {
if (client.ip ~ local) {
return(lookup);
}
}
}
sub vcl_hit {
if (req.request == "PURGE") {
set obj.ttl = 0s;
error 200 "Purged.";
}
}
sub vcl_miss {
if (req.request == "PURGE") {
error 404 "Not in cache.";
}
}
~~~
### Taille du cache
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 :
~~~
sub vcl_recv {
if (req.http.host ~ "^.*$") {
set req.backend = baz;
}
~~~
Pour finir, quelques informations sur le load-balancing avec Varnish
* 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>
#### Cache ESI
<http://www.varnish-cache.org/trac/wiki/ESIfeatures>
## Grace mode
<https://www.varnish-cache.org/docs/4.0/users-guide/vcl-grace.html>
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 :
~~~
sub vcl_recv {
if (!req.backend.healthy) {
set req.grace = 4h;
}
}
sub vcl_fetch {
set beresp.grace = 12h;
}
~~~
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 !
## Monitoring
### Nagios
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>.
### Munin
~~~
# apt install libxml-parser-perl
# cd /etc/munin/plugins
# ln -s /usr/share/munin/plugins/varnish_ varnish_expunge
# ln -s /usr/share/munin/plugins/varnish_ varnish_hit_rate
# ln -s /usr/share/munin/plugins/varnish_ varnish_memory_usage
# ln -s /usr/share/munin/plugins/varnish_ varnish_objects
# ln -s /usr/share/munin/plugins/varnish_ varnish_request_rate
# ln -s /usr/share/munin/plugins/varnish_ varnish_threads
# ln -s /usr/share/munin/plugins/varnish_ varnish_transfer_rates
# ln -s /usr/share/munin/plugins/varnish_ varnish_uptime
~~~
## Exemples de règles VCL
### Exemple pour Wordpress
Voici un exemple de règles pour un site utilisant WordPress :
~~~
backend default {
.host = "127.0.0.1";
.port = "80";
}
sub vcl_recv {
set req.backend = default;
# Compatiblity with Apache log
remove req.http.X-Forwarded-For;
set req.http.X-Forwarded-For = client.ip;
# Normalize Content-Encoding
if (req.http.Accept-Encoding) {
# Compress a compressed format is silly
if (req.url ~ "\.(jpg|jpeg|png|gif|gz|tgz|bz2|lzma|tbz|zip|rar)(\?.*|)$") {
remove req.http.Accept-Encoding;
}
# use gzip when possible, otherwise use deflate
if (req.http.Accept-Encoding ~ "gzip") {
set req.http.Accept-Encoding = "gzip";
} elsif (req.http.Accept-Encoding ~ "deflate") {
set req.http.Accept-Encoding = "deflate";
} else {
# unknown algorithm, remove accept-encoding header
unset req.http.Accept-Encoding;
}
}
# Ignore cookies de Google Analytics
if (req.http.cookie) {
set req.http.Cookie = regsuball(req.http.Cookie, "__utm.=[^;]+(; )?", "");
if (req.http.cookie ~ "^ *$") {
remove req.http.cookie;
}
}
# Remove cookies and query string for real static files
if (req.url ~ "^/[^?]+\.(jpeg|jpg|png|gif|ico|js|css|txt|gz|zip|lzma|bz2|tgz|tbz|html|htm)(\?.*|)$") {
unset req.http.cookie;
}
# Remove query string for some files (exclude js and css)
#if (req.url ~ "^/[^?]+\.(jpeg|jpg|png|gif|ico|txt|gz|zip|lzma|bz2|tgz|tbz|html|htm)(\?.*|)$") {
# set req.url = regsub(req.url, "\?.*$", "");
#}
# Pas de cache pour l'interface d'administration de WordPress ni les connectes
if(req.url ~ "^/wp-(login|admin)" || req.http.Cookie ~ "wordpress_logged_in_" ) {
return(pass);
}
# Grace mode
if (req.backend.healthy) {
set req.grace = 30s;
} else {
set req.grace = 1h;
}
}
sub vcl_backend_response {
if (beresp.cacheable) {
# do not use the header Expires sent by backend but this value instead:
# we can't use a high value since the cache is not purged
# (only for dynamic files with a final / or the home page
# Other files (css...) will use the Expires header
if (req.url ~ "/$") {
set beresp.ttl = 60s;
} elsif (beresp.ttl < 120s) {
set beresp.ttl = 120s;
}
}
set beresp.grace = 4h;
}
~~~
### Autre exemple
~~~
sub vcl_recv {
remove req.http.X-Forwarded-For;
set req.http.X-Forwarded-For = client.ip;
# Normalize Content-Encoding
if (req.http.Accept-Encoding) {
# Compress a compressed format is silly
if (req.url ~ "\.(jpg|jpeg|png|gif|gz|tgz|bz2|lzma|tbz|zip|rar)(\?.*|)$") {
remove req.http.Accept-Encoding;
}
# use gzip when possible, otherwise use deflate
if (req.http.Accept-Encoding ~ "gzip") {
set req.http.Accept-Encoding = "gzip";
} elsif (req.http.Accept-Encoding ~ "deflate") {
set req.http.Accept-Encoding = "deflate";
} else {
# unknown algorithm, remove accept-encoding header
unset req.http.Accept-Encoding;
}
}
if (req.http.cookie) {
set req.http.Cookie = regsuball(req.http.Cookie, "__utm.=[^;]+(; )?", "");
if (req.http.cookie ~ "^ *$") {
remove req.http.cookie;
}
}
if (req.url ~ "^/[^?]+\.(jpeg|jpg|png|gif|ico|js|css|txt|gz|zip|lzma|bz2|tgz|tbz|html|htm)(\?.*|)$") {
unset req.http.cookie;
}
if (req.url ~ "^/[^?]+\.(jpeg|jpg|png|gif|ico|txt|gz|zip|lzma|bz2|tgz|tbz|html|htm)(\?.*|)$") {
set req.url = regsub(req.url, "\?.*$", "");
}
if (req.backend.healthy) {
set req.grace = 30s;
} else {
set req.grace = 4h;
}
}
sub vcl_backend_response {
set beresp.ttl = 1800s;
set beresp.grace = 12h;
if (beresp.status == 403 || beresp.status == 404 || beresp.status == 503 || beresp.status == 500) {
set beresp.ttl = 10s;
set beresp.cacheable = true;
}
if (!beresp.cacheable) {
set beresp.http.X-Cacheable = "NO";
return (pass);
} else {
set beresp.http.cache-control = "max-age=1800";
}
}
sub vcl_deliver {
if (obj.hits > 0) {
set resp.http.X-Cache = "HIT";
set resp.http.X-Cache-Hits = obj.hits;
} else {
set resp.http.X-Cache = "MISS";
}
}
~~~
## FAQ
### Taille maximum d'un objet en cache ?
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 ?
Un reload ne suffit parfois pas, un restart sera nécessaire dans certains cas. De plus, il faut vider du cache les éventuels objects concernés.
### Temps d'attente du client HTTP ?
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)*.