relecture du Howto Varnish avant TP :)
This commit is contained in:
Gregory Colpart
parent
e4f070b3d5
commit
4a3ee69453
|
|
@ -17,7 +17,7 @@ Tableau supporte uniquement Ubuntu, nous installons donc un conteneur LXC :
|
|||
|
||||
# lxc-attach --name tableau
|
||||
|
||||
lxc# apt install ./tableau-server-2022-1-7_amd64.deb
|
||||
lxc# apt install ./tableau-server-2022-1-7_amd64.deb ./tableau-postgresql-odbc_09.06.0501_amd64.deb
|
||||
[…]
|
||||
Il est nécessaire de prendre 112 Mo/2 959 Mo dans les archives.
|
||||
Après cette opération, 20,7 Go d'espace disque supplémentaires seront utilisés.
|
||||
|
|
|
|||
|
|
@ -3,8 +3,9 @@ title: Howto Varnish
|
|||
categories: web HA cache
|
||||
...
|
||||
|
||||
* Documentation : <https://www.varnish-cache.org/docs/6.1/>
|
||||
* Documentation : <https://www.varnish-cache.org/docs/6.5/>
|
||||
* VCL Reference (basé sur un fork de Fastly) : <https://developer.fastly.com/reference/vcl/>
|
||||
* Statut de cette page : stable / buster
|
||||
|
||||
[Varnish](https://www.varnish-cache.org/) 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.
|
||||
|
||||
|
|
@ -43,7 +44,7 @@ ExecStart=/usr/sbin/varnishd -F -a 0.0.0.0:80 -T localhost:6082 -f /etc/varnish/
|
|||
-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 de [varnishd](http://www.varnish-cache.org/docs/6.1/reference/varnishd.html) :
|
||||
Détails de certaines options de [varnishd](http://www.varnish-cache.org/docs/6.5/reference/varnishd.html) :
|
||||
|
||||
* `-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`
|
||||
|
|
@ -72,6 +73,8 @@ Détails de certaines options de [varnishd](http://www.varnish-cache.org/docs/6.
|
|||
|
||||
Les règles Varnish définissent la mise en cache en utilisant une syntaxe particulière : le VCL (*Varnish Configuration Language*).
|
||||
|
||||
Ces règles sont définies dans le fichier `/etc/varnish/default.vcl` et peuvent contenir des `include`.
|
||||
|
||||
Il faut au minimum configurer le backend :
|
||||
|
||||
~~~
|
||||
|
|
@ -81,10 +84,12 @@ backend default {
|
|||
}
|
||||
~~~
|
||||
|
||||
On écrit ensuite ses règles au sein de sous-routines avec [la syntaxe VCL](syntaxe-vcl).
|
||||
|
||||
Pour vérifier ses règles (ceci est fait par défaut lors d'un redémarrage) :
|
||||
|
||||
~~~
|
||||
# varnishd -Cf /etc/varnish/default.vcl > /dev/null
|
||||
# sudo -u varnish varnishd -Cf /etc/varnish/default.vcl > /dev/null
|
||||
~~~
|
||||
|
||||
> *Note* : on peut ignorer le message du type :
|
||||
|
|
@ -102,7 +107,6 @@ Pour visualiser les règles "builtin" (les règles par défaut si l'on ne change
|
|||
# varnishd -x builtin | less
|
||||
~~~
|
||||
|
||||
|
||||
### 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) :
|
||||
|
|
@ -132,7 +136,7 @@ on peut aussi faire comme ceci (pour filtrer tout ce qui provient d'une IP donn
|
|||
|
||||
## Syntaxe VCL
|
||||
|
||||
* <https://www.varnish-cache.org/docs/4.0/reference/vcl.html> (attention, la documentation n'est pas à jour, notamment la partie "Variables")
|
||||
* <https://www.varnish-cache.org/docs/6.5/reference/vcl.html> (attention, la documentation n'est pas à jour, notamment la partie "Variables")
|
||||
* Outil de test en ligne de la syntaxe VCL : <https://www.vclfiddle.net/>
|
||||
|
||||
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* :
|
||||
|
|
@ -140,6 +144,8 @@ La syntaxe VCL est complexe mais puissante. On découpe un fichier VCL en plusie
|
|||
* **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*).
|
||||
|
||||
On peut définir plusieurs les sous-routines, permettant ainsi de surcharger la configuration et d'utiliser astucieusement les `include` et les conditions `if` : une requête s'arrêtera de parcourir la sous-routine dès qu'elle tombe sur un `return`.
|
||||
|
||||
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 :
|
||||
|
|
@ -169,19 +175,10 @@ sub vcl_backend_response {
|
|||
~~~
|
||||
|
||||
|
||||
### Vérifier la configuration
|
||||
|
||||
S'il y a une erreur dans la configuration, Varnish échouera à redémarrer et cela risque d'impacter tous les sites qu'il cache. Il est donc indispensable de tester la configuration après toute modification.
|
||||
|
||||
Varnish compile la configuration en code C, il est donc possible de vérifier s'il y a des erreurs de compilation de la manière suivante :
|
||||
|
||||
~~~
|
||||
sudo -u varnish varnishd -Cf /etc/varnish/default.vcl
|
||||
~~~
|
||||
|
||||
|
||||
### Configuration par défaut
|
||||
|
||||
Voici les règles par défaut de Varnish visualisables via `varnishd -x builtin` :
|
||||
|
||||
~~~
|
||||
sub vcl_recv {
|
||||
if (req.method == "PRI") {
|
||||
|
|
@ -351,7 +348,7 @@ if (req.http.Cache-Control ~ "no-cache")
|
|||
# Condition sur le temps de mise en cache (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)
|
||||
if (beresp.status == 404 || beresp.status == 503 || beresp.status == 500)
|
||||
~~~
|
||||
|
||||
Voici un certain nombre d'actions possibles :
|
||||
|
|
@ -369,13 +366,13 @@ 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";
|
||||
set beresp.http.expires = "Mon, 1 Jan 2007 00:00:01 GMT";
|
||||
set beresp.http.X-foo = "bar";
|
||||
# Renvoyer une erreur HTTP
|
||||
return(synth(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) :
|
||||
Enfin, voici les principaux [comportements possibles](https://www.varnish-cache.org/docs/6.5/users-guide/vcl-built-in-subs.html) :
|
||||
|
||||
~~~
|
||||
# Renvoie vers le backend (pas de cache)
|
||||
|
|
@ -622,7 +619,7 @@ Si besoin, on pourra aussi utiliser en complément le logiciel <http://trac.evol
|
|||
|
||||
## Grace mode
|
||||
|
||||
<https://www.varnish-cache.org/docs/4.0/users-guide/vcl-grace.html>
|
||||
<https://www.varnish-cache.org/docs/6.5/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 :
|
||||
|
||||
|
|
@ -881,7 +878,7 @@ sub vcl_deliver {
|
|||
### hit_for_pass
|
||||
|
||||
Lorsque Varnish interroge un serveur de backend pour une URL donnée, il fait patienter les
|
||||
autres clients qui demandent la même URL… ce qui est optimisé SAUF si l'URL n'est finalement
|
||||
autres clients qui demandent la même URL… ce qui est optimisé SAUF si l'URL n'est finalement
|
||||
pas cachable ! Une manière de permettre la parallélisation de ces requêtes vers une ressource
|
||||
pas cachable est que Varnish crée une note "hit_for_pass" pour retenir cela. Ça se fait
|
||||
en mettant un TTL et en forçant une requête à ne pas être cachable :
|
||||
|
|
|
|||
Loading…
Reference in a new issue