Cache-Tags + Varnish

Varnish Cache ist ein Webanwendungs-Beschleuniger, auch bekannt als HTTP-Cache-Proxy-Server. Varnish wird auf Tausenden Drupal-Websites eingesetzt, um die Seitenladeleistung um das 10- bis 1000-fache zu steigern, und kann mit Cache-Tags verwendet werden, um das Leeren des Caches zu vereinfachen.

Für die grundlegende Integration von Cache-Tags müssen Sie drei Dinge tun, um sicherzustellen, dass Varnish gut mit den von Drupal generierten Cache-Tags zusammenarbeitet:

• Aktualisieren Sie die Varnish VCL, damit BAN-Anfragen korrekt verarbeitet werden.
• Senden Sie den Cache-Tags-Header (z. B. X-Cache-Tags) mit jeder Anfrage, der eine durch Leerzeichen getrennte Liste aller Cache-Tags der Seite enthält.
• Senden Sie bei jeder Aktualisierung von Inhalt oder Konfiguration eine BAN-Anfrage mit den entsprechenden Cache-Tags, sodass Seiten mit diesen Cache-Tags invalidiert werden.

Varnish VCL aktualisieren

Das Symfony-Paket FOSHttpCache enthält eine ausgezeichnete Dokumentation zu den notwendigen VCL-Anpassungen für Cache-Tags. Hier sind die minimal erforderlichen VCL-Änderungen für den Einstieg (für Varnish 4.x):

Innerhalb von vcl_recv:

sub vcl_recv {
    ...
    # BAN-Anfragen nur von IP-Adressen im 'purge' ACL erlauben.
    if (req.method == "BAN") {
        # Gleiche ACL-Prüfung wie oben:
        if (!client.ip ~ purge) {
            return (synth(403, "Not allowed."));
        }

        # Logik für BAN mit Verwendung des X-Cache-Tags-Headers.
        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."));
        }

        # Synthetische Antwort, damit die Anfrage nicht ans Backend geht.
        return (synth(200, "Ban added."));
    }
}

Innerhalb von vcl_backend_response:

sub vcl_backend_response {
    # Setze ban-lurker freundliche Custom-Header.
    set beresp.http.X-Url = bereq.url;
    set beresp.http.X-Host = bereq.http.host;
    ...
}

Innerhalb von vcl_deliver:

sub vcl_deliver {
    # Entferne ban-lurker freundliche Custom-Header vor Auslieferung an den Client.
    unset resp.http.X-Url;
    unset resp.http.X-Host;
    # Kommentarzeilen für einfacheres Debugging der Drupal Cache-Tags in der Entwicklung.
    unset resp.http.X-Cache-Tags;
    unset resp.http.X-Cache-Contexts;
    ...
}

Starten Sie Varnish unbedingt neu, nachdem Sie die VCL entsprechend angepasst haben!

Cache-Tags-Header senden

Sie können eines der folgenden Module aktivieren, damit Drupal den HTTP-Header mit Cache-Tags ausgibt:

Beachten Sie, dass in einigen Versionen vor 8.x-3.0-beta5 das Purge-Modul den Header Purge-Cache-Tags automatisch setzte, dies jedoch entfernt wurde, da entschieden wurde, dass diese Verantwortung bei den Submodulen liegen sollte.

BAN-Anfrage beim Ändern von Inhalt oder Konfiguration senden

Mit dem Modul Generic HTTP Purger können Sie auf der Konfigurationsseite für Purge (admin/config/development/performance/purge) einen HTTP-Purger hinzufügen.

Geben Sie die Daten Ihres Varnish-Servers ein (Hostname, Port, Pfad usw.) und konfigurieren Sie unter „Header“ einen Header mit folgender Konfiguration:

• Header: X-Cache-Tags
• Wert: [invalidation:expression]

Sobald Sie diese Purge-Konfiguration speichern und einen Cron-Job einrichten, um die Purge-Warteschlange zu verarbeiten (drush p-queue-work), sollte Varnish Seiten sperren, sobald die Warteschlange Verbote auslöst!

Einige Hinweise in dieser Dokumentation wurden aus folgenden Quellen adaptiert:

• Verwenden von Drupal 8 Cache-Tags mit Varnish und Purge
• Cache-Tags-Unterstützung in der Standard-Konfiguration von Drupal VM Varnish hinzufügen