(!) Sysadmins will want VarnishMaintenance.

Migrer un site vers Varnish (cache.koumbit.net)

Procédure rapide

Cette procédure ne semble pas trop bien fonctionner avec d7. l'option "unset" sur conf['caching'] + config dans l'interface web fonctionne, mais pas celle où on force la configuration de caching dans local.settings.conf

A revoir.

http://drupal.stackexchange.com/questions/83315/difference-between-minimum-cache-lifetime-and-expiration-of-cached-pages

Procédure avec benchmark avant la mise en prod

L'idée est d'utiliser un domaine différent du site en production qui servira à tester Varnish.

Tester

URL

Statistiques du serveur Varnish de Koumbit:

Utiliser Varnish pour un site sur HAG

Préparer la conf sur les serveurs de caching

elseif (req.http.host ~ "^(.*\.)?domaine.tld$") {
    # Configured on YYYY.MM.DD to alleviate pressure on hag webnodes
    set req.backend_hint = hag_73.backend();
  }

profile::apache::externally_cached_sites:
  domain.tld:
    cluster: cache.koumbit.net
    tls_cert: '/var/alternc/letsencrypt/live/domain.tld/fullchain.pem'
    tls_key: '/var/alternc/letsencrypt/live/domain.tld/privkey.pem'

Rouler puppet sur hector (le cas échéant), puis cache0 et cache1.

Pointer le site vers le serveur de caching

define('FORCE_SSL_ADMIN', true);
// in some setups HTTP_X_FORWARDED_PROTO might contain 
// a comma-separated list e.g. http,https
// so check for https existence
if (strpos($_SERVER['HTTP_X_FORWARDED_PROTO'], 'https') !== false) {
  $_SERVER['HTTPS']='on';
}

Vérifier que le site réponde correctement. S'il est en https, s'assurer que la redirection se fait bien et que le certificat est correctement envoyé. Un curl en http devrait retourner quelque chose comme:

~$ curl -I domain.tld
HTTP/1.1 301 Moved Permanently
...
Location: https://domain.tld/
X-Hostname: hector.koumbit.net
...
Via: 1.1 varnish (Varnish/6.1)
...

Utiliser Varnish pour un site de la CSN

Procédure à suivre :

  if (req.http.host ~ ".*\.frontcommun\.org") {
    set req.backend_hint = macaron;
  }

profile::icinga2::extra_host_vars:
  https_vhosts:
    app.secteurpublic.quebec: {}
    app-staging.secteurpublic.quebec: {}
    www.frontcommun.org: {}

La raison est expliquée dans 32024 : il peut y avoir une erreur où le certificat du backend n'est pas copié correctement dans les caches. Ça ajoute un check icinga qui nous avertit du problème avant que les users aillent sur le site et voient le message de certificat invalide.

// For Varnish Caching to work
define('FORCE_SSL_ADMIN', true);
// in some setups HTTP_X_FORWARDED_PROTO might contain 
// a comma-separated list e.g. http,https
// so check for https existence
if (strpos($_SERVER['HTTP_X_FORWARDED_PROTO'], 'https') !== false) {
  $_SERVER['HTTPS']='on';
}

C'est très important parce qu'une partie de la communication entre Varnish et le backend doit se faire en HTTP. Si Varnish force HTTP et AlternC force HTTPS il se fait une boucle qui affiche un message d'erreur "Too Many Redirects" ou "The page isn't redirecting correctly", voir : https://www.varnish-software.com/developers/tutorials/avoid-http-to-https-redirect-loops-varnish/

Retirer Varnish d'un site

Pour désactiver Varnish et revenir à une configuration normale:

Troubleshooting

Modules that break caching and how to fix them

Purger la cache de varnish

Comme utilisateur, il est impossible de purger la cache de varnish. Seulement les sysadmins peuvent faire cette opération, par défaut (voir VarnishMaintenance#Flusher_la_cache_de_Varnish pour cela).

La bonne procédure est de réduire le temps de vie de la cache *avant* de faire des changements. Réduire le réglage Expiration of cached pages avant de faire des changements au site, attendre la durée de temps qui était présente avant de faire les changements, faire les changements puis les changements devraient être déployés après la durée de temps choisie.

Exemple:

  1. Expiration of cached pages avant: 3h

  2. mettre 5 minutes
  3. attendre 3 heures
  4. faire le changement
  5. attendre 5 minutes pour vérifier que le changement est bon
  6. retourner à l'étape 4 si d'autres changements sont nécessaires
  7. remettre le Expiration of cached pages à la valeur originale

(Pour une bonne explication des différents paramètres de cache, voir ce post.)

Il est également possible d'automatiser la purge de la cache varnish telle qu'opérer par les sysadmins avec le module varnish, mais ceci demande un accès extérieur à l'interface d'administration, généralement avec un mot de passe. Le serveur Varnish doit doit donc être modifié pour permettre ce genre d'opération. De plus, en permettant l'accès à l'interface d'administration de Varnish, on donne des accès administrateur au serveur varnish, permettant par exemple d'arrêter le serveur complètement où de purger toute la cache, donc un enjeu de sécurité grave. Ceci n'est donc pas permis sur les serveurs partagés de Koumbit.

Meilleure méthode, recommendée

Le module purge est beaucoup plus flexible car il utilise la méthode plus portable et sécuritaire PURGE pour indiquer à Varnish (mais aussi à Nginx, Squid, etc) de retirer un élément de la cache qui a été modifié. Ceci permet d'indiquer à varnish de conserver les éléments en cache pour plusieurs semaines pour réduire à un stricte minimum les requêtes au serveur web "backend" sans que des modifications au contenu ne subissent de délai d'affichage.

Par contre cette méthode ne permet pas l'authentification (seulement besoin d'envoyer une requête de type PURGE pour une URL en particulier pour enlever un élément de la cache, sans vérification). Elle n'est donc pas permise pour les environnements partagés, car elle permet de purger la cache d'autres sites.

References

Drupal is tricky to cache. A basic performance optimisation job should be done on the site even before putting it in Varnish, see the DrupalPerformance guide.

Drupal-specific caching issues

A good start is those indymedia docs.

Other references and alternatives


CategoryGuide

VarnishGuide (last edited 2024-02-07 19:18:15 by mathieul)