Im Beitrag vorher wurde Varnish installiert und eine Konfig erstellt, die auf WordPress passen sollte. Nun geht es darum, die Konfig-Templates von Plesk 11.x so anzupassen, dass der Varnish zwischen dem NGinx und dem Apache läuft. Entsprechend der Konfig dann Seiten vom Apache abfragt oder eben aus dem eigenen Cache beantwortet.
Plesk auf vServer oder Root-Server bietet jede Menge Vorteile, zwingt den Nutzer aber auch, gewisse Freiheiten bei der Konfiguration des Servers auf zu geben. Als Beispiel werden die Apache- und NGinx-Konfigurationen aus der Datenbank in Templates gefüllt. Um hier eine permanente Änderung zu platzieren, muss man direkt die Templates ändern. Immerhin gibt einen Zauber, der diese Anpassungen vor unabsichtlichen Zerstörungen durch Updates von Plesk schützt. Unter CentOS leben die Templates im Verzeichnis
/usr/local/psa/admin/conf/templates
Dort gibt es ein Verzeichnis „default“. Das muss man komplett umkopieren in ein Verzeichnis „custom“. Zum Beispiel mittels
cp -r default custom
Dann müssen die Templates „nginxDomainVhost.php“ und „nginxDomainVhost.php“ geändert werden. Der Plan lautet hier, dass der „Backendport“ von dem Port, den Apache bei einer NGinx->Apache-Konfiguration bekommt auf den Port vom Varnish umgebogen wird. Vorher greift NGinx direkt auf den Apachen als Backend zu, nachher wird er auf den Varnish zu greifen, der wieder, wenn nötig auf den Apachen zugreift. In den 2 Daten findet man jeweils die Konfig für https und http. Wichtig ist, dass man nur die für http ändert. In beiden Dateien gehört die Zeile geändert:
nginxDomainVhost.php: 'backendPort' => $VAR->server->webserver->httpPort, nginxDomainVhost.php: 'backendPort' => '6081',
und genauso:
nginxDomainForwarding.php: 'backendPort' => $VAR->server->webserver->httpPort, nginxDomainForwarding.php: 'backendPort' => '6081',
Dann gehört noch einiges in der nginx.php geändert. Vorher wird kein Alias für den Backend-Server definiert. Das holen wir nach und bringen gleich eine Art Failsafe-Konfig unter.
Vorher:
<?php echo AUTOGENERATED_CONFIGS; ?>
<?php /** @var Template_VariableAccessor $VAR */ ?>
<?php foreach ($VAR->server->ipAddresses->all as $ipAddress): ?>
server {
listen <?php echo "{$ipAddress->escapedAddress}:{$VAR->server->nginx->httpPort}" ?> default_server <?php if ($ipAddress->isIpV6) echo 'ipv6only=on'; ?>;
location / {
proxy_pass http://<?php echo $ipAddress->proxyEscapedAddress . ':' . $VAR->server->webserver->httpPort ?>;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}
}
<?php endforeach; ?>
<?php /* Next block used for watchdog */ ?>
<?php if (!$VAR->server->ipAddresses->hasIpV4Address): ?>
server {
listen 127.0.0.1 default_server;
return 200;
}
Dort werfen wir einen Alias für das Backend ab, unter der ersten Zeile:
upstream backend {
server 127.0.0.1:6081;
server 127.0.0.1:7080 backup;
}
Damit haben wir einen upstream-Server namens „backend“ erklärt, normal der Server am Port 6081, das ist der Varnish, wenn der nicht ansprechbar sein sollte, dann kommt der Server am Port 7080 zum Zuge. Das ist der Apache direkt, der dient also als Failover wenn der Varnish aus einem Grund nicht läuft. Dann gibt man diesen Upstream-Server in der Zeile an, wo es um den Reverse-Proxy geht:
proxy_pass http://proxyEscapedAddress . ':' . $VAR->server->webserver->httpPort ?>; proxy_pass http://backend;
Das ganze schaut also nun so aus:
<?php echo AUTOGENERATED_CONFIGS; ?>
upstream backend {
server 127.0.0.1:6081;
server 127.0.0.1:7080 backup;
}
<?php /** @var Template_VariableAccessor $VAR */ ?>
<?php foreach ($VAR->server->ipAddresses->all as $ipAddress): ?>
server {
listen <?php echo "{$ipAddress->escapedAddress}:{$VAR->server->nginx->httpPort}" ?> default_server <?php if ($ipAddress->isIpV6) echo 'ipv6only=on'; ?>;
location / {
proxy_pass http://backend;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}
}
<?php endforeach; ?>
<?php /* Next block used for watchdog */ ?>
<?php if (!$VAR->server->ipAddresses->hasIpV4Address): ?>
server {
listen 127.0.0.1 default_server;
return 200;
}
<?php endif ?>
Damit haben wir also einen laufenden Varnish mit einer Konfig für den Blog. Dazu eine angepasste Konfig für Plesk. Es ist an der Zeit, das Ganze zu aktivieren. Dazu aktiviert man in Plesk den NGinx-Reverse-Proxy-Dienst. Wenn er schon aktiv war, dekativiert man ihn und aktiviert ihn dann wieder. Das sorgt dafür, dass alle Konfigs neu geschrieben werden. Man findet diese Einstellung in Plesk unter Start->Tools&Einstellungen->Verwaltung von Services im Segment „Serververwaltung“.
Die Aktion veranlasst den Plesk-Dienst den Port vom Apachen zu ändern auf 7080, den NGinx zu starten und am Port 80 lauschen zu lassen. Es werden die geänderten Templates benutzt und alle (!) Domains bekommen die Sandwich-Konfig, Anfragen gehen zuerst an den NGinx, der liefert Dateien direkt aus, wenn er sie auf der Platte findet. Das gilt für alle statischen Dateien. Fragen nach *.php gibt er dem Backend weiter. Das ist nun der Varnish. Dieser entscheidet, ob er Daten aus seinem Cache liefert oder ob er den Apache befragt. Stellt der NGinx fest, dass der Varnish nicht antwortet, fragt er den Apachen direkt. Soweit so gut.
An sich sollte alles wie vorher funktionieren. Auf Domains die von der Varnish-Konfig aus dem Schritt ein nicht erfasst wurden, sieht man folgende Zeilen in den Headern:
HTTP/1.1 200 OK Server: nginx Age: 0 Via: 1.1 varnish X-Cache: MISS
Entscheidend sind die Zeilen die uns sagen dass der Server NGinx ist, dass es Via Varnish ging und (bei Domains die nicht durch den Varnish geliefert werden sollen) dass die Datei ein Alter von 0 hat und es ein MISS war. Alles ist gut. Bei der Domain, die den Varnish auch richtig nutzt, schaut es idealer Weise so aus:
HTTP/1.1 200 OK Server: nginx Age: 86555 Via: 1.1 varnish X-Cache: HIT
Bei WordPress sind ein paar andere Header noch mit dabei. Man kann sehen, die Daten haben ein Alter von 86555 Sekunden, was etwas über 24h sind. Zu dem Zeitpunkt wurde diese Seite das letzte Mal vom Apache und damit PHP und generell WordPress generiert. Seit dem liefert der Varnish eine statische Version dieser Seite aus. Und das in Millisekunden statt mehreren Sekunden die WordPress brauchen würde. Nun stellt sich die Frage: Was tun, wenn man in den letzten 24h die Seite geändert hat? Wie bekommt man den Varnish dazu, die Seite neu in seinen Cache zu laden bei Änderungen innerhalb der Gültigkeitsdauer? Damit befasst sich der Schritt 3.
Schreibe einen Kommentar