… En fait, cela aurait dû être “le tour de Varnish en 80 jours” … cela s’est avéré trop long, nous nous sommes donc repliés sur 30 minutes !

Varnish, j’en entends parler régulièrement, surtout quand il s’agit de gros, de très gros sites. Mais jusqu’à présent, je ne savais pas vraiment ce que c’était. La présentation que nous a fait Dridi Boukelmoune chez Zenika nous a éclairé sur la bête.

Varnish, c’est quoi ?

C’est un cache HTTP. Plus exactement un reverse proxy cache HTTP. Ce n’est ni le premier, ni le seul. Pourquoi donc l’évoquer ? Comme je l’ai dit, on trouve Varnish dans les grosses, les très grosses infrastructures Internet. Car outre sa remarquable stabilité, ce sont ses performances très élevées qui ont fait la réputation de Varnish. Bien qu’issue de Varnish Software (la partie commerciale de Varnish), cette petite Vidéo fait un bon résumé de la situation.

Bref, Varnish, c’est un cache HTTP très performant car travaillant au plus près de la pile TCP/IP. 

Pas d’IHM sexy pour configurer la bête. Varnish est fait pour les admmins sys barbus et se configure à l’aide d’un DSL : le VCL.

Configurer Varnish avec VCL

VCL c’est plus qu’un script de configuration, c’est un DSL qui est ensuite compilé en C. Pré-compilé, devrais-je dire, car bien sûr ce code C est lui même compilé ! Nous l’avons évoqué, Varnish est focalisé sur la performance, et on ne fait pas de choses performantes avec des mécanismes dynamiques ! Malgré tout, le changement de configuration peut être opéré à chaud.

Time to live

De base, Varnish gère son cache en TTL, mais on peut y inclure certaines variantes:

• En fonction de l’encoding
• En fonction du navigateur utilisé
• En fonction de la compression

Les règles par défaut

Tout ne doit pas aller en cache ! Le VCL permet d’ajuster ces règles, mais par défaut Varnish stipule que :

• Il n’y a pas de mise en cache d’une ressource si elle est liée à un cookie.
• Pas de mise en cache si il y a des informations d’authentification.
• Seules les requêtes GET et HEAD sont mises en cache. Les requêtes POST ne le sont pas.
• Varnish gère les “variantes” en s’appuyant sur l’en-tête HTTP vary qui permet d’indiquer explicitement un élément à associer à la décision de cache.

 Invalidation ou prolongation

Au-delà de la règle de fonctionnement de Varnish, qu’il s’agisse des règles par défaut ou d’une configuration qui s’en écarte, il est possible d’exclure des ressources du cache à l’aide de plusieurs mécanismes.

L’invalidation des ressources est possible, que ce soit sur une base individuelle ou suivant une expression régulière. Elle peut être opérée en ligne de commande ou via le VCL.

L’option la plus radicale d’invalidation est la purge. La ressource est retirée du cache, il n’y a plus moyen de la ressusciter une fois cela fait.

Varnish possède aussi une notion de ban. Il permet d’invalider un objet du cache, mais sans en entrainer son nettoyage.

A contrario on peut prolonger une ressource au-delà de ce que prévoit initialement les règles de Varnish,  avec la notion de “grâce” qui permet de prolonger un contenu à priori périmé. Ce mécanisme peut s’avérer utile en cas de défaillance du back-end.

Mais comment ça fonctionne le VCL ?

Ecrire du VCL, c’est presqu’écrire du C (c’est probablement pour cela que c’est facile à compiler…). Varnish propose un certains nombre de “looks”, des template méthodes qui sont appelées par Varnish si elles sont implémentées. Il suffit alors d’implémenter la fonction en question pour s’insérer dans le cycle de vie du cache, et d’y utiliser les fonctions que Varnish met à notre disposition pour bannir un objet, par exemple.

Bien sûr, il faut pour cela connaitre le cycle de vie des objets

Et voici ce à quoi peut ressembler un bout de configuration Varnish :

sub vcl_recv {
        if (req.request == "PURGE") {
                if (!client.ip ~ purgers) {
                        error 405 "Method not allowed";
                }
                return (lookup);
        }
}

Comme on peut l’imaginer, cet élément de configuration vient “hooker” l’état recv, en suivant le pattern “template method”.

Au-delà de la configuration

Director : Varnish fait du load balancing !

Enfin, pas tout à fait du load balancing, mais presque !

Un director est un groupe de back-ends clusterisés pour lesquels on établit une stratégie de redirection. Le but premier n’est pas de faire du load balancing, mais plutôt de maximiser les chances d’obtenir une ressource.

Maintenant, on peut aussi s’en servir pour faire du load balancing !

Etendre Varnish avec les modules

Outre la possibilité qu’offre le VCL d’y introduire du code en C, la méthode la plus élégante d’étendre Varnish est d’utiliser les modules, ce qui est possible depuis la version 3 de l’outil.

Dridi a d’ailleurs écrit un article (sinon l’article de référence) sur ce sujet, sur le Blog de Zenika.

Administrer l’outil

La console

On n’est pas chez les touristes. Ici de base, l’administration c’est la ligne de commande avec varnishadm ! Certaines des opérations que l’on peut faire avec sont même scriptables pour être intégrées dans un sh. Du classique pour les admins, donc.

Le bundle commercial de Varnish propose la Vanish Administration Console (VAC) qui est un outil Web. Mais comme toujours dans ces cas là, on ne peut quand même faire l’impasse sur la ligne de commande.

La gestion des logs

C’est un sujet d’attention particulier. Le loge peuvent rapidement ralentir terriblement les traitements. Varnish a pris une option radicale à cet égard : les logs sont en mémoire et sont en binaire ! Et Varnish propose un ensemble d’outils pour y accéder et les exploiter (varnishlog, varnishncsa)

Vers l’infini et au-delà…

En résumé

Le point essentiel, celui qui fait choisir Varnish, c’est qu’il s’agit d’un cache HTTP ultra-performant à même de décharger efficacement le back-end dans le cas de sites à très fort trafic. C’est LE cas d’utilisation. Pour un site n’ayant pas un très fort trafic, Varnish sera de très peu (et plus probablement d’aucun) intérêt.

Varnish en 5 étapes

Voici la démarche condensée de mise en oeuvre que nous propose Dridi :

1. Cacher le contenu statique
2. Configurer la compression
3. Cacher le contenu semi-statique
4. Automatiser l’invalidation
5. Améliorer le back-end

Les autres fonctions de Varnish

Bien que sa fonction essentielle soir le cache HTTP, on ne peut ignorer ce que Varnish sait faire d’autre :

• Gérer le streaming
• Utiliser des ACL
• Structurer des architectures multi-tenant.
• Tester son architecture, c’est à dire en pratique tester sa configuration VCL, avec le framework de test qui fait partie de la distribution.
• Gérer le Edge Side Include (ESI)

Bien entendu, nous l’avons évoqué, Varnish peut servir de reverse proxy, bien que ce ne soit pas sa vocation première.

Merci Dridi !

Dridi n’est pas seulement un excellent collègue chez Zenika, son intérêt et sa maitrise croissante sur Varnish l’ont amené à en devenir un contributeur ! Il est entre autre chose l’auteur du module QueryString.

La présentation dont Dridi nous a gratifié fera partie de sa présentation des petits déjeunes planifiés sur Lyon et Paris, consacrés à Varnish. J’avoue que cette présentation en 30 minutes (30 minutes et 18 secondes, précisément) était un peu ardue pour moi, car faite un peu sans concession. C’est mon seul reproche. Elle présente clairement les fonctions et possibilités de l’outil et l’enthousiasme, la passion devrais-je dire de Dridi pour ce projet open-source font beaucoup au plaisir que j’ai eu à l’écouter.

La présentation de Dridi est accessible ici.

En épilogue, je vous propose de jeter un coup d’oeil au manuel de référence de l’outil.