Tags de cache + Varnish

Varnish Cache est un accélérateur d’applications web, également connu sous le nom de proxy inverse HTTP avec cache. Varnish est utilisé sur des milliers de sites Drupal pour améliorer la vitesse de chargement des pages de 10 à 1000 fois, et il peut être utilisé avec des tags de cache pour faciliter l’invalidation du cache.

Pour une intégration basique des tags de cache, vous devez faire trois choses afin de garantir que Varnish fonctionne bien avec les tags de cache générés par Drupal :

• Mettre à jour le VCL de Varnish pour qu’il gère correctement les requêtes BAN.
• Envoyer l’en-tête des tags de cache (par exemple X-Cache-Tags) avec chaque requête, contenant la liste des tags de cache de la page, séparés par des espaces.
• Envoyer une requête BAN avec les tags de cache correspondants à chaque fois que le contenu ou la configuration est mis à jour, afin d’expirer les pages associées à ces tags.

Mettre à jour le VCL de Varnish

Le paquet Symfony FOSHttpCache fournit une excellente documentation sur les modifications VCL nécessaires pour supporter les tags de cache, mais voici les modifications minimales requises pour commencer (pour Varnish 4.x) :

Dans vcl_recv :

sub vcl_recv {
    ...
    # Autoriser uniquement les requêtes BAN depuis les IPs dans la liste ACL 'purge'.
    if (req.method == "BAN") {
        # Vérification ACL comme ci-dessus :
        if (!client.ip ~ purge) {
            return (synth(403, "Not allowed."));
        }

        # Logique de la ban en utilisant l’en-tête X-Cache-Tags.
        if (req.http.X-Cache-Tags) {
            ban("obj.http.X-Cache-Tags ~ " + req.http.X-Cache-Tags);
        }
        else {
            return (synth(403, "X-Cache-Tags header missing."));
        }

        # Retourne une réponse synthétique pour ne pas aller au backend.
        return (synth(200, "Ban added."));
    }
}

Dans vcl_backend_response :

sub vcl_backend_response {
    # Définir des en-têtes personnalisés pour les ban-lurkers.
    set beresp.http.X-Url = bereq.url;
    set beresp.http.X-Host = bereq.http.host;
    ...
}

Dans vcl_deliver :

sub vcl_deliver {
    # Supprimer les en-têtes personnalisés ban-lurker lors de la livraison au client.
    unset resp.http.X-Url;
    unset resp.http.X-Host;
    # Commentez ces lignes pour faciliter le débogage des tags de cache Drupal en développement.
    unset resp.http.X-Cache-Tags;
    unset resp.http.X-Cache-Contexts;
    ...
}

Veillez à redémarrer Varnish après avoir modifié le VCL !

Envoyer l’en-tête des tags de cache

Vous pouvez activer l’un des modules suivants pour faire en sorte que Drupal émette un en-tête HTTP contenant les tags de cache :

Notez que dans certaines versions antérieures à 8.x-3.0-beta5, le module Purge configurait automatiquement l’en-tête Purge-Cache-Tags, mais cela a été retiré au profit de sous-modules responsables de cette tâche.

Envoyer une requête BAN lors de la mise à jour du contenu ou de la configuration

Avec le module Generic HTTP Purger, vous pouvez aller sur la page de configuration Purge (admin/config/development/performance/purge) et ajouter un purger HTTP.

Entrez les informations de votre serveur Varnish (nom d’hôte, port, chemin, etc.) et dans la configuration des « En-têtes », ajoutez la configuration suivante :

• En-tête : X-Cache-Tags
• Valeur : [invalidation:expression]

Une fois la configuration sauvegardée et la tâche cron configurée pour traiter la file d’attente de purge (drush p-queue-work), Varnish commencera à bannir les pages dès que la file d’attente déclenchera les bannissements !

Certaines notes de cette documentation ont été adaptées des sources suivantes :

• Utiliser les tags Drupal 8 Cache avec Varnish et Purge
• Ajouter la prise en charge des tags de cache dans la configuration Varnish par défaut de Drupal VM