Heute beschäftigen wir uns dem Einsatz eines Apache als Reverse-Proxy für Confluence und welche Vorteile dieses Setting bietet.
Ein Reverse-Proxy vor einem Confluence-Server bietet einige Vorteile. Deswegen werde ich mich in dem heutigen Beitrag mit diesem Setting, seinen Vorteilen und wie man es konfiguriert beschäftigen.
Alles hier gemachten Angaben beziehen sich auf die folgende Konfiguration. Sollten sie andere Produkte oder Versionen einsetzen, müssen sie wahrscheinlich an der einen oder anderen Stelle etwas von meinen Beispielen abweichen.
- Betriebssystem: Linux MINT 17.2 Cinnamon
- Java 1.7.0
- Atlassian Confluence in der Version 5.8.10
- Apache Webserver in Version 2.4.7
Welche Vorteile bietet der Einsatz eines Reverse-Proxy
Bevor wir uns mit der Konfiguration beschäftigen, will ich erste einmal darauf eingehen, welche Vorteile dieses Setting bringt:
- Zusätzliches Logging
- Zusätzliches Caching
- Ausliefern statischer Inhalte
- Behandlung der SSL-Terminierung
- Sperren von URL’s
Im Apache lässt sich relativ einfach und mit geringen Einbußen bei der Performance z.B. die Response-Zeiten der Seitenabrufe loggen. Dies beinhaltet allerdings nur die Aufrufzeit für die Seite selbst. Zusätzliche Seiteninhalte, wie Bilder oder Skripte, die separat geladen werden, sind in dem Wert nicht enthalten.
Es besteht die Möglichkeit Inhalte zusätzlich zu Cachen oder statische Inhalte komplett aus Confluence herauszunehmen und über Apache auszuliefern. Dies bietet sich z.B. bei Skripten und Bildern an, die häufig verwendet werden, wie z.B. ein Seitenlogo. Besonders Bilder und Skripte erzeugen einen spürbaren Overhead, wenn sie etwa als Anhänge in Confluence abgelegt wurden und dann im schlimmsten Fall bei jedem Seitenabruf aus der Datenbank geholt werden müssen, bevor sie ausgeliefert werden können.
Die SSL-Terminierung in Confluence und somit Java zu behandeln, ist teuer und kostet Performance. Apache kann das viel besser und schneller.
Einer der weiteren Vorteile von Apache ist, dass sich die Konfiguration ohne Neustart ändern lässt (Stichwort graceful restart). Dadurch lassen sich z.B. kritische Seiten oder Aufrufe der Rest-Schnittstelle, die Confluence blockieren im Betrieb blockieren. Gerade in Umgebungen, wo ein Neustart des Servers mit kurzzeitiger Nicht-Verfügbarkeit einem Prozess mit Vorlauf folgen muss, ist das eine Möglichkeit, schnell auf kritische Situationen zu reagieren.
Konfiguration
Im Folgenden gehe ich davon aus, dass Confluence bereits installiert und konfiguriert ist und das Apache bereits auf dem Server installiert wurde.
Den Reverse-Proxy dazwischen hängen
In meinem Fall läuft Confluence unter Port 8090 auf dem Server und ich stelle die Kommunikation über HTTP her. Alternativ könnte man die Kommunikation zwischen Apache und Confluence auch über das AJP-Protokoll herstellen. Man könnte auch HTTPS verwenden, dann verliert man aber den Vorteil des Performance-Gewinns durch die Auslagerung der HTTPS-Terminierung aus Confluence.
Confluence und Apache wurden hier in einer VM auf den gleichen Server installiert. Je nach Infrastruktur und Anzahl an Benutzern macht es Sinn, den Apache Webserver auf einen separaten Server zu installieren. Apache wurde als Paket des Betriebssystems in die üblichen Verzeichnisse installiert. Confluence wurde nach /opt/atlassian/confluence installiert und es wird über einen Service gestartet.
Von außen möchte ich über die standard Ports 80 (HTTP) und 443 (HTTPS) auf Confluence zugreifen.
Als erstes müssen wir die “server.xml” anpassen und dort den Proxy einführen. In unserem Fall finden wir die Datei im Verzeichnis “/opt/atlassian/confluence/conf/”. In der server.xml erweitern wir die Konfiguration um einen Eintrag für den Host (proxyName) und Port (proxyPort) des Proxy.
<Server …> <Service …> <Connector … … proxyName=”localhost” proxyPort=”80” />
Jetzt sind noch ein paar Konfigurationen beim Apache Webserver nötig.
In einem ersten Schritt aktivieren wir die Module Proxy und Proxy-HTTP und passen die Konfiguration für das Proxy Modul an:
# cd /etc/apache2/mods-enabled # ln –s ../mods-available/proxy.load # ln –s ../mods-available/proxy.conf # ln –s ../mods-available/proxy_http.load # vim proxy.conf
<IfModul mod_proxy.c> ProxyRequests Off ProxyPreserveHost On Require all granted ProxyPass / http://localhost:8090/ ProxyPassReverse / http://localhost:8090/ Require all granted
Nach diesen Anpassungen an der Konfiguration sollte Confluence bereits über Apache erreichbar sein.
Graceful Restart
Apache kann nach Änderungen an der Konfiguration über den Befehl „apachectl graceful“ gestartet oder restarted werden. Dabei wird Apache gestartet, falls er noch nicht läuft und restartet, falls er bereits läuft. Beim Restart werden keine bestehenden Verbindungen abgebrochen. Der bestehende Prozess bleibt am Leben, bis er alle Anfragen bearbeitet hat. Vor dem Starten des neuen Prozess werden die Konfigurationsdateien wie bei der Option „configtest“ geprüft. Ein neuer Prozess wird nur gestartet, falls die Konfiguration in Ordnung ist. Andernfalls bleibt der alte Prozess aktiv. Auf diese Art und Weise kann der Apache Web-Server ohne Verlust von Verbindungen oder eine Downtime neu gestartet werden und Änderungen an der Konfiguration können ohne Downtime durchgeführt werden.
Reponse Time Logging
Jetzt führen wir ein neues Log-Format mit erweitertem Inhalt ein. In dem neuen Log-Format sollen die jeweiligen Antwortzeiten für eine Anfrage mit erfasst werden. Aber Vorsicht, die Zeiten für das Laden von Bilder oder Skripten innerhalb einer Seite werden hier nicht gemessen!
Als erstes fügen wir das neue Log-Format „responsetime“ in der apache-Konfiguration hinzu. Am Besten fügen sie es hinter den bereits existierenden LogFormat-Einträgen ein.
# vim /etc/apache2/apache2.conf LogFormat "\"%{%Y-%m-%d %H:%M:%S}t\" %V %m \"%U\" \"%q\" %{Content-Type}o %s %B %O %D" responsetime
Mit dem oben definierten Format enthält jeder Eintrag im Log-file folgende Informationen:
Wert | Formatstring | Bedeutung |
---|---|---|
1 | %Y-%m-%d %H:%M:%S | Zeitstempel gemäß ISO 8601 für einfaches Parsen in Programmen oder Skripten. |
2 | %V | Virtueller Host Name |
3 | %m | Request Methode (z.B. GET, POST, HEAD …) |
4 | „%U | URL Pfad |
5 | %q | Der Query-String der URL |
6 | %{Content-Type}o | Mime-Type des Requests |
7 | %s | HTTP-Status Code |
8 | %B | Größe des Reponse in Bytes (ohne Header) |
9 | %O | Anzahl der gesendeten Bytes (inklusive Header) |
10 | %D | Zeit, die für die Bearbeitung des Request verwendet wurde in Mikrosekunden (reponse time) |
Nun müssen wir das neue Log-Format noch irgendwo verwenden. Sie können z.B. das Format des bereits existierenden Eintrags für das access.log anpassen oder, wie unten gezeigt, ein neues reponsetimes.log einführen.
# vim /etc/apache2/sites-enabled/00-default.conf CustomLog ${APACHE_LOG_DIR}/reponsetimes.log reponsetime
Damit die Änderungen wirksam werden, müssen sie Apache z.B. über „graceful“ (siehe oben) neu starten.
Zusammenfassung und nächste Schritte
Bis hier haben wir den Apache Reverse-Proxy so konfiguriert, dass alle Anfragen an Confluence über den Proxy laufen und die Antwortzeiten von Apache geloggt werden.
Jetzt müssen wir uns noch um die folgenden Punkte kümmern:
- Ausliefern statischer Inhalte
- Zusätzliches Caching
- Behandlung der SSL-Terminierung
- Sperren von URL’s
Die Artikel zu den oben aufgeführten Punkten finden sie demnächst hier.