Varnish unter Plesk samt SSL-Unterstützung

Ein Kunde von uns wollte Varnish in Verbindung mit Plesk betreiben. Er hat sich dafür an die diversen Anleitungen im Internet gehalten, aber die Einrichtung scheiterte. Die meisten Anleitungen basieren darauf, dass man den Frontend-Webserver auf einen alternativen Port setzt und Varnish auf Port 80 platziert. Derartige Vorgehensweisen haben jedoch diverse Nachteile und die SSL-Unterstützung fehlt.

Was ist Varnish und was bringt es?

Varnish kann dynamische und statische Inhalte cachen und verbessert die Webseitenperformance enorm. Varnish wird ausschließlich als Reverse-Proxy betrieben. Man muss also zusätzlich einen Backend-Webserver wie Apache verwenden.
Den Cache lagert Varnish standardmäßig im Arbeitsspeicher aus. Falls dem System wenig Arbeitsspeicher zur Verfügung steht, kann man über die Konfigurationsdatei den Cache in einer Datei auslagern. Allerdings ist der Arbeitsspeicher deutlich schneller und man erreicht damit in der Regel eine bessere Performance.

Zum Vergleich habe ich eine Wordpress-Testinstallation aufgesetzt:

WordPress Ladezeit – ohne Varnish Cache WordPress Ladezeit – mit Varnish Cache
:~$ time curl -s https://wp4.linevast.de/ > /dev/null
real 0m0.942s
user 0m0.044s
sys 0m0.008s
:~$ time curl -s https://wp4.linevast.de/ > /dev/null
real 0m0.330s
user 0m0.040s
sys 0m0.012s
In der linken Spalte wurde die Seite mit geleertem Cache aufgerufen. In der rechten Spalte das Ergebnis mit Cache. Die Ladezeit hat sich durch den Varnish-Cache mehr als halbiert. Für den Test wurde WordPress mit verschiedenen Plugins installiert um realistische Ergebnisse zu erhalten.

Plesk mit Varnish: Vorgehensweise

Diese Anleitung bezieht sich auf ein gewöhnliches Plesk-Setup – sprich Nginx als Frontend und Apache als Backend-Webserver.
Falls das Setup nicht wie gewünscht funktioniert oder man es erst mal nur testen möchte, kann man das gesamte Setup mit wenigen Befehlen rückgängig machen (siehe weiter unten).

Damit SSL-Verbindungen ebenfalls cached werden und es auch keine negativen Auswirkungen in Plesk gibt, platzieren wir Varnish nicht auf dem HTTP Port 80, sondern belassen die standardmäßigen Ports wie sie sind. Stattdessen leiten wir die Verbindungen von nginx auf Varnish um.
Der Verbindungsablauf sieht dann wie folgt aus:

 

1. Installation von Varnish

Varnish ist für diverse Linux-Distributionen verfügbar. In meiner Anleitung verwende ich CentOS 7. Über das EPEL-Repository kann Varnish installiert werden.

Hinweis: Varnish auf anderen Distributionen installieren
Varnish kann auf fast allen Distributionen installiert werden. Hier eine Anleitung für Debian. Die sonstigen Informationen dieses Eintrags gelten für alle Distributionen.

2. Konfiguration von Varnish

1. Damit Varnish weiß, ob es sich um eine HTTP- oder HTTPS-Anfrage handelt, wird Varnish auf zwei Ports gestartet. Ich habe dazu 6081 und 6080 ausgewählt.
Dazu öffnet man die Datei /etc/varnish/varnish.params und ersetzt die Zeile VARNISH_LISTEN_PORT=6081 mit VARNISH_LISTEN_PORT=6081,:6080

2. Damit Varnish die Anfragen richtig bearbeitet, muss man Regeln definieren. Man findet im Internet diverse fertige Regeln, beispielsweise diese hier für WordPress.
Die Regeln müssen in der Datei /etc/varnish/default.vcl festgelegt werden. Damit alles ordnungsgemäß in Verbindung mit Plesk funktioniert, wird ganz oben in der Datei immer folgendes definiert:

Wichtig: 'SERVERIP' ersetzen
Auch hier wieder darauf achten, dass die „SERVERIP“ mit der öffentlichen IP des Servers ersetzt wird. Würde man localhost oder 127.0.0.1 konfigurieren, funktioniert es aufgrund der Vhost-Konfiguration seitens Plesk nicht.
Hinweis: default.vcl Beispiel
Eine angepasste VCL gibt es hier – diese VCL gilt nur als Beispiel und basiert auf dem oben genannten GitHub-Template. In meinem Test funktioniert WordPress und das Caching damit. Ich würde jedoch empfehlen, sich in die Varnish-Konfiguration einzulesen und die VCL selbst zu erstellen (oder zu überarbeiten).

Nachdem die beiden Konfigurationen angepasst wurden, aktivieren wir den automatischen Start von Varnish und starten den Server:

Falls Varnish nicht startet, kann man sich per journalctl -xe das Problem ansehen.

3. Erstellen eines neuen Nginx-Vhosts & SSL-Termination

Nun erstellen wir einen neuen Nginx-Vhost, welcher die Verbindungen von Varnish an Apache weiterleiten wird. Prinzipiell könnte man auf diesen Vhost verzichten und die Verbindungen von Varnish direkt an Apache übergeben. Das hätte allerdings den Nachteil, dass Apache HTTPS Verbindungen nicht mehr erkennen würde. Der Webserver würde alle Anfragen als HTTP verarbeiten. Beispielsweise würden dadurch Umleitungen von HTTP auf HTTPS in einer Endlosschleife enden, sofern per .htaccess oder PHP (wenn PHP als Apachemodul ausgeführt wird) realisiert.

Um den neuen vhost anzulegen, wird folgendes ausgeführt:

Wer möchte, kann die Proxy-Parameter seinen Bedürfnissen entsprechend erweitern. Ein relevanter Parameter wäre beispielsweise client_max_body_size.

Wichtig: proxy_pass Parameter anpassen
Beim Parameter proxy_pass muss die IP des Servers angegeben werden. Sofern mehrere IPs genutzt werden, muss für jede IP ein Vhost angelegt werden.

4. Anpassen des Plesk vhost Templates

Das vhost Template von Plesk werden wir so umkonfigurieren, dass die Anfagen von Nginx an Varnish weitergeleitet werden. Varnish wird die Anfragen anschließend wieder zurück zum zuvor erstellten Nginx-Vhost leiten, welcher wiederum die Anfragen an Apache weiterleitet. Es klingt komplizierter als es ist.

Hinweis: Änderungen im Plesk-Template nachlesen
Die geänderten Stellen wurden kommentiert, sodass man sich in den Dateien ansehen kann, was verändert wurde.

5. Webserverkonfiguration neu erstellen

Damit die Konfigurationsänderungen auf allen bestehenden Domains übernommen werden, lassen wir diese neu erstellen.

Plesk sollte den Webserver automatisch neu starten und somit die neue Webserverkonfiguration übernehmen. Sollte das nicht passieren, kann man die Webserver manuell neu starten:

6. Varnish-Cache testen & leeren

Die Konfiguration ist hiermit abgeschlossen. Ruft jetzt eine Webseite auf und beobachtet die Ausgabe von varnishstat. Relevant sind die Werte MAIN.cache_hit und MAIN.cache_miss. Nach dem ersten Aufruf befindet sich die Seite im Cache. Weitere Aufrufe sollten den Wert von MAIN.cache_hit erhöhen. Dieser Wert gibt an, wie viele Anfragen aus dem Cache geladen wurden. MAIN.cache_miss hingegen gibt an, wie viele Anfragen durch den Backend-Webserver verarbeitet wurden.

Änderungen rückgängig machen – Varnish deaktivieren

Um die Änderungen rückgängig zu machen, reichen einige wenige Befehle: