Semaine 7 · Laboratoire

Varnish
devant Apache

Une nouvelle instance, une cache en avant du web, et des chiffres qui fondent : le laboratoire 2 de l'Application distribuée.

420-5A4-MT · Acte 6 · L'essaimage

La mission du jour

À la fin de la séance, vous aurez :

Une instance varnish30 qui offre le service de cache Varnish en avant de votre serveur HTTP.
L'URL d'accès de WordPress modifiée pour utiliser l'adresse du serveur Varnish.
Le montage mesuré au test de charge BRUTAL (partie 3 du tableau).
Le tout dans GitHub : /votre-nom/laboratoire2/

Prérequis : l'ensemble mysql10 + http20 de la semaine 6, fonctionnel. Minimum 2 commits pertinents en classe cette semaine.

Étape 1

La nouvelle instance et Varnish

# une instance varnish30 selon votre infrastructure (reference : 192.168.56.30)

sudo apt update

sudo apt install varnish net-tools

sudo netstat -tulpn | grep varnishd

# varnishd ecoute pour l'instant sur son port par defaut (6081)

Rappel clonage : nouvelle adresse MAC, nouveau nom d'hôte (varnish30), nouvelle adresse IP. Un clone qui garde l'identité de son parent sème le chaos sur le réseau.

Étape 2

Varnish prend le port 80

sudo systemctl edit varnish.service

[Service]

ExecStart=

ExecStart=/usr/sbin/varnishd -j unix,user=vcache -F -a ADRESSE_DE_VARNISH30:80 -T localhost:6082 -f /etc/varnish/default.vcl -S /etc/varnish/secret

sudo systemctl daemon-reload

sudo systemctl restart varnish.service

Le pare-feu de varnish30 s'ouvre au strict nécessaire : le port 80 pour les visiteurs, le 22 pour vous.

Étape 3

Le backend, et Apache qui se replie

# sur varnish30 : declarer le fournisseur

sudo nano /etc/varnish/default.vcl

backend default { .host = "ADRESSE_DE_HTTP20"; .port = "80"; }

# sur http20 : ecouter seulement sur sa propre adresse

sudo nano /etc/apache2/ports.conf

sudo nano /etc/apache2/sites-enabled/000-default.conf

sudo systemctl restart apache2.service

Étape 4

WordPress déménage officiellement

Modifier l'URL d'accès de WordPress pour utiliser l'adresse du serveur Varnish : c'est elle, la nouvelle adresse publique du site.
Tester depuis le navigateur de l'hôte : le site répond par l'adresse de varnish30.
Rechargez la même page plusieurs fois, puis regardez varnishstat : les hits grimpent, Apache se repose.

sudo varnishstat -1 | grep -i cache

MAIN.cache_hit 412

MAIN.cache_miss 37

Étape 5

La preuve par les chiffres

Test de charge BRUTAL avec JMeter, visant l'adresse de Varnish.
Captures top en SSH de TOUTES les instances actives : performances_partie_3_10secondes.png et performances_partie_3_60secondes.png
Remplir la ligne 3 du tableau : id de mysql10, http20 et varnish30, temps moyen JMeter.
Comparez avec la partie 2 : le temps moyen fond, et le processeur de http20 respire. Expliquez pourquoi dans votre guide.

Avant de partir

Livrables et devoir

Dans GitHub : guide d'installation, fichiers de configuration (varnish.service, default.vcl, ports.conf), tableau, captures.
Les trois instances restent fonctionnelles pour la suite.
Devoir : terminer le laboratoire avant le cours de la semaine 8.

La semaine prochaine, l'acte 7 : tout passe par une seule cache, un seul chemin. On double tout - deux Varnish, deux HAproxy, une IP virtuelle - et on éteindra le maître en pleine charge pour voir le site survivre.

Version de départ · ce diaporama va s'enrichir

Varnishdevant Apache