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:

6 Gedanken zu „Varnish unter Plesk samt SSL-Unterstützung“

  1. Hallo,

    erstmal vielen Dank für diesen tollen Beitrag!

    Einen Punkt habe ich aber leider nicht ganz nachvollziehen können:
    Warum wird nach den Varnish nochmal der nginx geschaltet? Da der Apache auf den SSL-Ports auch wieder SSL entschlüsselt könnte man doch auch direkt auf den Apache weiterleiten und somit eine Schicht einsparen.

    1. Hallo,

      bitte entschuldigen Sie die verspätete Antwort.

      Der Grund wird im 3. Punkt beschrieben:

      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.

      Sofern sich in Ihrem Setup keine Probleme ergeben, wenn die Anfragen von Varnish direkt auf Apache umgeleitet werden, ist das auch in Ordnung. Für die große Masse, oder wenn mehrere unterschiedliche Webseiten betrieben werden, würde ich es jedoch wie beschrieben empfehlen.

      Der Overhead durch den zusätzlichen Layer wird kaum messbar sein. nginx kann gut mit vielen gleichzeitigen Verbindungen umgehen. Voraussetzung dafür ist natürlich, dass nginx korrekt konfiguriert wurde. Wenn viele gleichzeitige Verbindungen zu erwarten sind, sind insb. die Parameter worker_processes und worker_connections relevant.

      Leider ist die standardmäßige nginx Konfiguration von Plesk nicht ideal (sowie die meisten anderen Konfigurationsdateien, wie z.b. von MySQL / MariaDB). Deshalb die Erwähnung der beiden relevanten Parameter.

      Grüße!

  2. Hallo,

    danke für diese Anleitung. Vielleicht noch als Ergänzung: in Plesk->Websites&Domains->php-Einstellungen muss PHP ausführen als „FPM-Anwendungen von nginx bedient“ eingestellt werden.

    Leider kommt es zu mehrfachen badrequestes. Haben Sie eine Idee warum?

    Gruß Matze

    PS @Boris Günther: der Grund wird unter Punkt 3 beschrieben. 😉

    1. Hallo,

      >Leider kommt es zu mehrfachen badrequestes. Haben Sie eine Idee warum?

      Leider fällt mir dazu spontan keine Ursache ein. Ich vermute aber, dass die Logs des Webservers etwas zum Problem hergeben.
      Kommt die Fehlermeldung von Varnish, oder von nginx?

      Grüße!

  3. Hallo, vielen Dank für die ausführliche Beschreibung, eine Frage hätte ich noch, meinen Server läuft unter Ubuntu 16.04, Plesk 17.5, nach allen Konfigurationsschritten, die Sie beschrieben haben, bekomme ich in Plesk die folgende Fehlermeldung:

    New configuration files for the Apache web server were not created due to the errors in configuration templates: Template processing failed: file = /opt/psa/admin/conf/templates/custom/nginxDomainVhostIpDefault.php, error = Template_Exception: Template domain/service/nginxWordpress.php doesn’t exists file: /opt/psa/admin/plib/Template/Processor.php line: 28 code: 0 Previous error: Template_Exception: Template domain/service/nginxWordpress.php doesn’t exists file: /opt/psa/admin/plib/Template/Processor.php line: 28 code: 0 Previous error: Template_Exception: Template domain/service/nginxWordpress.php doesn’t exists file: /opt/psa/admin/plib/Template/Finder.php line: 25 code: 0. Detailed error descriptions were sent to you by email. Please resolve the issues and click here to generate broken configuration files once again or here to generate all configuration files. See the details in Configuration Troubleshooter

    Woran kann es liegen? Vielen Dank für jede Hilfe.

    1. Hallo,

      die Datei „nginxDomainVhostIpDefault.php“ wird in dieser Anleitung nicht erstellt.
      Ich würde empfehlen, dass Sie den Inhalt der beiden Dateien vergleichen und entsprechend anpassen:

      diff /usr/local/psa/admin/conf/templates/default/nginxDomainVhostIpDefault.php /opt/psa/admin/conf/templates/custom/nginxDomainVhostIpDefault.php

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.