Varnish - Eine Einführung

Allgemeines und Historie zu Varnish

Varnish vereinigt die Funktionalitäten eines Reverse-Proxies, HTTP-Loadbalancers und Cache für über HTTP ausgelieferte Daten.
Die Entwicklung startete ca. 2006 mit Version 0.9 als erstes Release und ist mittlerweile bei 5.1 angelagt.

Varnish ist sowohl in einer freien Community-Version (BSD Lizenz), wie auch in einer Enterprise-Version  mit diversen Zusatzfeatures für z.B. HA, SSL, Web-GUI verfügbar. Mit fastly existiert sogar ein CDN-Anbieter, welcher komplett auf Varnish aufbaut.

Die Community-Version kann keine HTTPS-Anfragen auflösen, weshalb ein SSL-Terminator wie z.B. Nginx oder caddy benötigt wird, welcher die Anfragen als HTTP-Request an Varnish weiterleitet. Auch kann hier natürlich eine bestehende Appliance oder andere vorhandene Infrastruktur genutzt werden. Es wird in der freien Version auch keine SSL-Unterstützung geben, was von Poul-Henning Kamp, einem der Hauptentwickler, ausführlich verargumentiert wird.

Varnish arbeitet intern vereinfacht nach folgendem Prinzip (Details):

1. Eine Anfrage wird vom varnishd angenommen und mit einer ID versehen
2. Diese Anfrage wird an einen Worker-Thread mit der aktuellen VCL weitergeleitet
3. Die Anfrage wird entsprechend bearbeitet und an das Backend gesandt, falls kein gecachter Eintrag verfügbar ist
4. Die Antwort des Backends wird von varnishd entgegen genommen, ebenfalls mit einer ID versehen und nach der VCL verarbeitet
5. Die Antwort wird entsprechend vom varnishd an den Client gesandt

Anfragen via HTTPS gehen hier entsprechend den Weg über den SSL-Proxy.

Mehr zum Begriff VCL im entsprechenden Abschnitt später.

Warum Varnish?

Es gibt mit u.A. Nginx, Apache, HAProxy einige Alternativen zu Varnish. Wie üblich sind hier die persönlichen Anforderungen, Vorlieben und natürlich auch das Know-How ausschlaggebend.

Allerdings ist Varnish auf sein Aufgabengebiet spezialisiert und bietet einige Features, die in den Alternativen nur schwer umzusetzen sind.

Hier wäre z.B. das problemlose Wechseln der Konfiguration zur Laufzeit (in beide Richtungen), die weitreichenden Debuggingmöglichkeiten im Request-Flow und die flexible Konfiguration durch die VCL zu nennen.

Gerade die Konfiguration von sehr vielen Redirects oder URL-Manipulationen in z.B. NGinx werden u.U. schnell unübersichtlich und sind nur mit entsprechendem Know-How wartbar.

Im Endeffekt sind, wie so häufig, im Vorfeld die Anforderungen an das Projekt und die jeweiligen Möglichkeiten zu prüfen.

Installation

Varnish ist in den Repositories der meisten Linux-Distributionen in einer spezifischen Version enthalten.

Eine Übersicht der verfügbaren Versionen zur manuellen Installation findet sich hier .

Genauere Erläuterungen zur Installation finden sich hier

Konfiguration

Varnish besteht aus mehreren Komponenten, welche auch getrennt Konfiguriert werden müssen.

varnishd

Der Daemon, welcher die Anfragen entgegen nimmt und verarbeitet. Die Allgemeine Konfiguration des Daemons funktioniert entweder innerhalb des systemd-Servicefiles, oder in einer separaten Datei unter z.B. /etc/defaults/varnish. Hier werden z.B. die Anzahl der Worker-Threads, die RAM-Limits oder Ports des Daemons konfiguriert.

VCL (Requestverarbeitung)

Die Verarbeitung der Requests oder die Konfigurations der Backends und deren Checks werden in einer separaten Konfiguration durchgeführt. Bei dieser handelt es sich um eine VCL-Datei (initial die default.vcl, welche beim Start des Services geladen wird. z.B: unter /etc/varnish/default.vcl). VCL ist eine Varnish-interne Skriptsprache, welche dem Dienst beschreibt, wie mit den Requests umzugehen ist. Diese wird später automatisch beim Laden in C-Code kompiliert und dem varnishd-Daemon zur VErfügung gestellt. Diese lässt sich auch zur Laufzeit ändern oder auch komplett austauschen.

Später dazu mehr.

Varnishncsa

Der Logging-Daemon von Varnish ähnliche dem Access-Log eines Webservers. Dieser läuft unabhängig vom varnishd, und muss entsprechend auch separat gestartet werden. Die Konfiguration wird entweder im entsprechenden systemd-Servicefile, oder einer separaten Datei wie z.B. /etc/defaults/varnishncsa vorgenommen werden. Das Logformat kann z.B. auch an das gewohnte Apache-Format angeglichen werden.

VCL

Die VCL (Varnish Configuration Language)  ist eine varnish-interne Sprache um das Requesthandling zu steuern.
Diese ist in mehreren Unterfunktionen mit vcl_ Präfix (Builtins) definiert.
Man kann die Konfiguration natürlich um eigene Funktionen ergänzen, jedoch müssen diese in den entsprechenden Builtins aufgerufen werden.
Einige Konfigurationen, wie die Definition der Backends finden ausserhalb der Builtins statt. Mehr dazu im untenfolgenden Beispiel.
Eine komplette Referenz der VCL findet sich hier, sowie eine ausführliche Beschreibung der Builtins hier .

Eine VCL-Konfiguration kann sehr umfangreich ausfallen. Anstatt diese hier komplett einzufügen und entsprechend zu kommentieren, soll auf
die Beispiel-VCL von Matthias Geniar verwiesen werden.

Die dort aufgeführte Konfiguration beinhaltet neben grundlegenden Einträgen wie die Definition von Backends und ACLs auch einige zusätzliche Funktionen bzw. Request-Manipulationen (Websocket-Unterstützung, URI-Manipulation,ESI und weiteres). Natürlich ist dies nur eine allgemeine Konfiguration. Für produktive Zwecke sollte man entsprechend prüfen, welche Anforderungen gestellt sind, und wie diese zu erfüllen sind.

In dieser nicht enthalten, jedoch eine gängige Konfiguration: Wird z.B: Nginx als SSL-Terminator genutzt, so kann dieser gleichzeitig als Notfall-Backend fungieren, um z.B. eine allgemeine Wartungsseite auszuliefern, sollte keines der regulären Backends verfügbar sein. Somit würde Fehlermeldungen an die Besucher entsprechend entfallen.

VMODs

varnish bietet die Möglichkeit innheralb der VCL eignenen C-Code zu integrieren. Dies ist jedoch sehr unhandlich, weswegen die Möglichkeit der VMODs existiert. Es sind zusätzliche, in C implementierte Module, welche die Funktionen von varnish, bzw. dessen VCL erweitern können.
Varnish liefert einige Standardmodule, wie std oder director, direkt zur Installation, jedoch gibt es auch eine Menge bereits veröffnetlicher Module, welche die Funktionalität erweitern.

Eine Liste der gängigsten Module ist hier zu finden.

An dieser Stelle ist natürlich darauf zu achten, dass diese mit der installierten Varnish-Version kompatibel sind. Einige der beliebtesten dürften hier GeoIP und BasicAuth sein.

Eine Beschreibung, wie eigene VMODs implementiert werden können findet sich hier

CLI und andere Binaries

Folgend eine Übersicht der gängigsten Binaries, welche durch das varnish-Paket ausgeliefert werden, und die Administration und/oder das Debugging vereinfachen.

varnishadm

Eine interaktive CLI, welche es ermöglicht in eine laufende Varnish-Instanz zu springen, und z.B. neue VCLs zu laden, eine Übersicht der vewendet Storages zu erhalten, die Konfiguration des varnishd einzusehen oder die Instanz zu beenden. Die CLI kann auch als „One-Shot Command“ genutzt werden, um z.B. eine neue VCL auf kompatibilität zu prüfen. Dazu muss nur z.B. „varnishd -C -f /etc/varnishd/default.vcl“ (bzw. der Pfad zu der zu prüfenden Datei) ausgeführt werden. Gibt es keine Probleme, wird die als C-Code übersetzte VCL ausgegeben, andernfalls eine entsprechende Fehlermeldung.
So kann stets sichergestellt werden, ob die neue Konfiguratin überhaupt funktioniert. Funktionale Fehler werden hier natürlich nicht geprüft.

varnishlog

Varnishlog ist ein sehr mächtiges Tool, mit dem sich der aktuelle Requestflow in Echtzeit aus varnish anzeigen lässt. Da hier sehr viele Daten anfallen können, empfiehlt es sich varnishlog nur zu Debuggingzwecken manuell aufzurufen. Es werden sowohl alle Header des Requests, Timestamp, Varnish-Funktionsaufrufe und Methoden aufgeführt. Es ist damit sehr leicht, ein entsprechendes Request den kompletten Weg vom Empfang bis zum Versand der Antwort zu untersuchen.

Folgend ein paar Beispiele für Aufrufe:

• Logged alle Requests für den Host-Header example.com
  varnishlog -q ‚ReqHeader ~ „Host: example.com“‚
• Logged jeweils die URL und den Referer für alle Anfragen, bei denen der Host-Header auf (www\.)?example\.com matched.
  varnishlog -q ‚ReqHeader ~ „Host: (www\.)?example\.com“‚ -i „ReqURL“ -I „ReqHeader:Referer:“

varnishstat

Zeigt in einer Top-artigen Übersicht alle wichtigen Interna der entsprechenden Varnish-Instanz an. So z.B. die Gesamtanzahl der Requests seit dem Start, die Verfügbarkeit der Backends in den letzten Minuten, Cache Hits/Misses und vieles mehr. Es gibt auch eine One-Shot Funktion, welche einen Snapshot der Daten ausgibt und z.B.für Monitoringzwecke genutzt werden kann.

varnishtop

Dies ist eine Top-Artige Übersicht über das varnishlog. Es werden jeweils die am häufigsten im Log aufgeführten Einträge absteigend nach Auftreten angezeigt.

Ein Beispiel:

3.00 ReqHeader      Cookie:
3.00 ReqUnset       Cookie:
0.75 ReqURL         /
0.75 BerespProtocol HTTP/1.1
0.75 VCL_return     fetch
0.75 VCL_return     deliver
0.75 ReqHeader      Host: localhost

Weitere Themen

Die Möglichkeiten mit Varnish sind sehr vielfältig, und Sie alle in einem Artikel zu beleuchten würde den Rahmen entsprechend sprengen. Sollten Sie noch Fragen/Wünsche zu bestimmten Themen haben, welche in einem Artikel vertieft werden sollten, dann bitte hinterlassen Sie dies in den Kommentaren.