Un service de réservation en ligne qui tient sous une charge normale peut s’effondrer le jour où une émission de télévision mentionne le restaurant : ce scénario, déjà vécu par plusieurs établissements, justifie de tester le comportement du cache avant qu’un pic réel ne survienne. Ajouter Varnish à l’environnement de développement local, via Lando, permet d’observer ce comportement avant la mise en production, sans configurer Varnish à l’aveugle directement sur le serveur final.
Lando ne propose pas Varnish parmi ses services préconfigurés par défaut, mais son système de services personnalisés permet de l’ajouter facilement à un projet WordPress existant.
Étape 1 : ajouter le service Varnish au fichier Lando
Le fichier .lando.yml du projet accueille un nouveau service, positionné devant le service web existant pour intercepter les requêtes avant qu’elles n’atteignent PHP :
services:
varnish:
type: varnish:7.4
ssl: false
port: 6081
depends_on:
- appserver
overrides:
environment:
VARNISH_BACKEND_HOST: appserver
VARNISH_BACKEND_PORT: 80
proxy:
varnish:
- restaurant.lndo.siteÉtape 2 : écrire une configuration Varnish minimale
Un fichier default.vcl minimal suffit pour observer un comportement de cache réaliste, en évitant de mettre en cache les pages sensibles au contexte utilisateur, comme le panier de réservation en cours :
vcl 4.1;
backend default {
.host = "appserver";
.port = "80";
}
sub vcl_recv {
if (req.url ~ "^/reservation" || req.http.Cookie ~ "wordpress_logged_in") {
return (pass);
}
}
sub vcl_backend_response {
if (beresp.http.Cache-Control !~ "no-cache") {
set beresp.ttl = 5m;
}
}Étape 3 : vérifier les en-têtes de cache
Une fois l’environnement relancé (lando rebuild), l’observation du comportement passe par l’inspection des en-têtes de réponse HTTP, qui indiquent si Varnish a servi la page depuis son cache ou l’a transmise au serveur d’application :
curl -I https://restaurant.lndo.site/menu/ | grep -i "X-Varnish\|Age"Une valeur d’Age supérieure à zéro confirme que la réponse provient bien du cache Varnish plutôt que d’un nouvel appel à WordPress, information précieuse pour vérifier que les pages critiques (menu, page d’accueil) sont effectivement mises en cache avant le pic attendu.
Étape 4 : simuler une charge avant le vrai pic
Un outil de test de charge simple, exécuté contre l’environnement local, permet de comparer le nombre de requêtes tenues avec et sans Varnish activé, en désactivant temporairement le service pour établir une base de comparaison :
- Mesurer le nombre de requêtes par seconde supportées sans Varnish, service désactivé.
- Réactiver Varnish et relancer la même mesure dans les mêmes conditions.
- Comparer l’écart, qui donne une idée du gain attendu en production, sans en être une garantie stricte.
Ce que ce test local ne prouve pas
- Les ressources d’une machine locale ne reproduisent jamais fidèlement la charge réseau d’un pic de trafic réel.
- La configuration Varnish testée localement devra être adaptée aux spécificités du serveur de production, notamment le comportement du cache face à un CDN éventuellement déjà en place.
- Ce test valide un comportement fonctionnel, pas une capacité de charge absolue : il rassure sur le fait que les pages sensibles ne sont pas mises en cache par erreur, sans dispenser d’une vraie configuration de production, sujet distinct qui mérite sa propre préparation.
Tester le cache en local ne remplace pas la production, mais cela évite de découvrir en production qu’une page de réservation sensible au contexte était mise en cache pour tout le monde.
En résumé
Ajouter Varnish à un environnement Lando permet d’observer, avant un pic de réservations attendu, si les pages critiques d’un site de restauration se mettent en cache correctement et si les pages sensibles au contexte utilisateur restent bien exclues. La configuration Varnish en production, avec ses propres contraintes de purge et de dimensionnement, reste un chantier séparé à préparer une fois ce comportement validé localement.
