Was steckt wirklich dahinter? Alles nur ein Hype oder hat Varnish zu Recht einen so guten Ruf?

Was ist überhaupt ein Reverse Proxy?
Ich vergleiche einen Reverse Proxy gerne mit einer Chefsekretärin, welche im realen Leben ähnliche Aufgaben übernimmt und auch sehr oft unterschätzt wird.

Eine gute Chefsekretärin sollte folgende Eigenschaften besitzen:

• sie nimmt alle Anfragen an den Chef entgegen und filtert unerwünschte Anfragen raus.
• sie weiß, welche Anfragen direkt an den Chef weitergeleitet werden müssen.
• sie bespricht sich mindestens ein oder zweimal am Tag mit ihrem Chef über wichtige Angelegenheiten und kennt somit deren Stand.
• sie kann viele Anfragen selbst beantworten, ohne den Chef fragen zu müssen.
• sie kann Anfragen so umformulieren, dass sie auch der Chef versteht.
• sie kann ihren Chef auch mal kurz vertreten oder zumindest entschuldigen.
• ist sie mal krank oder im Urlaub, ist der Chef völlig überfordert.

Kurzum, entlastet sie ihren Chef und kann ihn sogar stellenweise vertreten.

Das sind alles Aufgaben, die ein Reverse Proxy auch übernehmen sollte. Er ist also eine Art Filter, Zwischenspeicher und Vertreter eines anderen Servers – meist Webservers.

Ein guter Reverse Proxy kann also,

• unerwünschte Anfragen an den Server abwehren, z.B. Spam oder Brutforce Attacken,
• Anfragen an bestimmte Webseiten, z.B. die sehr aktuell sein müssen oder mit Nutzer bezogenen Daten, direkt weiterleiten,
• bereits angefragte Seiten zwischenspeichern und somit selbst ausliefern,
• die zwischengespeicherten Seiten nach einer bestimmten Zeit wieder mit dem Webserver abgleichen,
• Anfragen modifizieren und z.B. einen HTTP Header umschreiben,
• eigene Fehlerseiten ausliefern, wenn der Webserver oder bestimmte Seiten nicht mehr erreichbar sind.

Genau das und noch viel mehr kann Varnish Cache. Er zeichnet sich durch seine Stabilität,  einfache Konfiguration und  enorme Geschwindigkeit aus.

Er läuft und läuft und läuft…
Der Projektleiter von Varnish, Poul-Henning Kamp ist u.a. Core Entwickler bei FreeBSD und er versteht was von moderner Prozessentwicklung unter Linux. Das merkt man auch Varnish an. Nicht nur, dass Varnish ressourcensparend und schnell arbeitet, er ist zudem sehr stabil und lässt sich nicht so einfach aus dem Konzept bringen. Varnish überwacht sich sozusagen selbst und ein spezieller Prozess hat nur die Aufgabe den Kernprozess von Varnish am laufen zu halten.

Das Herz von Varnish ist VCL (Varnish Configuration Language)
Poul-Henning Kamp ist gebürtiger Däne und vielleicht ist das der Grund, warum Varnish eine eigene Konfigurationssprache (VCL) besitzt. Bekanntlich mögen Dänen ja solche Konfigurationssprachen um Systeme zu beeinflussen – siehe die von Kasper Skaarhoj entwickelte Konfigurationssprache „Typoscript“ bei TYPO3.
Wie auch immer, mit VCL kann man das Caching-Verhalten von Varnish nach Herzenslust beeinflussen und sich seinen Anforderungen entsprechend anpassen.

Dank VCL ist es z.B. kein Problem bestimmte URLs aus dem Caching auszunehmen oder Mediadateien eine andere Cachedauer (TTL)  zu verpassen. Man kann den Request vor und nach dem Weiterleiten an das Backend (Webserver) manipulieren, ACL (Access Control Lists) anlegen, spezifische Fehlerseiten erzeugen oder auch rudimentäres Load-Balancing einrichten und vieles mehr.
Die Syntax von VCL ist an C und Perl orientiert und daher für PHP Entwickler relativ einfach zu erlernen. Der Funktionsumfang hält sich auch noch in Grenzen und man kann mit wenigen Zeilen Code eine Menge auf die Beine stellen. Generell aber gilt bei VCL die Regel: „keep it simple“.

Wie gut wird meine Seite gecached?
Varnish bringt einige Möglichkeiten mit, sich die Effizienz des Caching darstellen zu lassen. Der Klassiker ist “varnishtop”, welcher ähnlich wie das bekannte Linux “top”, eine textbasierte Statistik aufzeigt, die u.a.  aktuelle Cache-Hit-Ratios aufführt. Im Klartext heißt das, wie viel Prozent der Anfragen gecached ausgeliefert werden konnten. Schöner ist es allerdings, sich das bekannte Server Statistik Tool “Munin” zu installieren, für das es auch ein fertiges Varnish Modul gibt und einem so schicke Grafiken u.a. über die Hit-Ratio ausliefert.

Fazit
Varnish hat somit den Einstellungstest mit Bravour bestanden. Auch wenn man vielleicht ein wenig Einarbeitungszeit investieren muss, ist er letztendlich der nahezu perfekte Sekretär: Er ist schnell, flexibel, merkt sich viel und fällt sehr selten aus.

Ausblick
Nach dieser sehr allgemeinen Einführung in das Thema, möchte ich demnächst ein paar Praxisbeispiele vorstellen. Vor allem der Einsatz von Varnish im TYPO3 Umfeld und dessen Stolperfallen.

Weiterführende Links

• Varnish Website
• Varnish Wiki
• Varnish und TYPO3 Experten (engl.)
• Poul-Henning Kamp auf der T3CON10 (Video)
• Munin

Voraussetzungen

• Internetanschluss
• Shell Zugang mit Root Rechten auf den Ubuntu 10.04 Server, z.B. mit putty
• Basic IT Know-How

Werkzeuge (OpenSource only)

• Ubuntu Server ISO Image
• TYPO3 Source Paket
• Shell Zugriff via putty
• Optional: VM-Box

Ziel

• Eine lauffähige TYPO3 Version auf einem Ubuntu Server
• Verständnis für Basis TYPO3 Administration

Nicht-Ziel

• Nicht geeignet für eine Kommerzielle Live-Umgebung, da auf sicherheitsrelevante Aspekte nicht eingegangen wird

1. Server aufsetzen

Die einfachste Methode ist natürlich, wenn man sich einen fertigen Server mietet. Hier kann ich uneingeschränkt die V-Pakete von Hosteurope empfehlen. Ein V-Server mit L Paket für 12,99 EUR/Mon ist völlig ausreichend und bei der Bestellung kann man gleich Ubuntu 10.04 als Betriebssystem auswählen. Bitte ohne Plesk installieren, da ich Plesk in der Anleitung nicht verwende.

Wem das zu teuer ist, kann zum Üben auch einen Virtuellen Server mit Virtual Box lokal aufsetzen.  (Siehe Werkzeuge.) Mike erklärt in seinem Blog recht vernünftig, wie man einen Ubuntu Server auf einer VM-Box aufsetzt. Wenn man kein Linux als OS hat, nimmt man eben die Windows Version von Virtualbox und installiert es ganz normal.

Während der Installation des Ubuntu Servers solltet man die bevorzugten Ländereinstellungen wählen und ohne LVM installieren – tut aber auch nicht weh, wenn es installiert ist. Aber es reicht auch aus, die Platte mit einer kleinen Swap- und einer Ext4-Partition anzulegen. Später bei der Paketauswahl sollte man den Open-SSH Server gleich mit installieren, damit man sich anschließend mit einem SSH Client verbinden kann. (Eine nachträgliche Installation ist natürlich auch möglich.)

2. Mit dem Server verbinden

Bei der V-Box Variante kann man sich nun mit dem Benutzer, welcher während der Installation vergeben wurde, an Ubuntu anmelden. Nach der Anmeldung sollte man sich erstmal dauerhaft Root Rechte geben, ansonsten muss man jedes mal den “sudo” Befehl vor administrativen Befehlen setzen und das kann nerven…

Anschließend ist man “allmächtig” – zumindest auf eurem virtuellen Ubuntu Server. Num sollte man die IP Adresse seines Systems herausfinden, damit man sich per SSH von “außen” verbinden kann.

Somit ist die IP 2.38.218.65 und nun kann man sich z.B. mit putty auf dem System verbinden. Dazu starten wir putty und tragen wie folgt die IP Adresse ein.

Putty Einstellung

Nun muss man sich mit dem Benutzer und Passwort am Server anmelden. Anschließend sich gleich wieder Root-Rechte verpassen. (sudo -s)

3. Pakte installieren

Nun benötigen wir noch einige Pakte damit TYPO3 läuft. Erstmal einen Apache Webserver (gerne auch ngnix – gehe ich aber in diesem Tutorial nicht darauf ein), PHP5, MySQL und ein paar Helfertools wie Graphicksmagic oder eAccelerator.

Also erstmal die Paketlisten aktualisieren:

Jetzt die Pakete installieren

Während der Installation von MySQL_Server muss man ein Root Passwort vergeben Durch Aufruf der Server-Ip im Browser sehen wir nun, das Apache läuft und dieser uns mit ein “It works!” begrüßt.

Im nächsten Teil wird ein V-Host konfiguriert und TYPO3 Leben eingehaucht.