Ziel
Unser Ziel ist es, Apache httpd so einzurichten, dass es als Proxy vor dem Apache Tomcat-Anwendungscontainer arbeitet.
Betriebssystem- und Softwareversionen
- Betriebssystem: Red Hat Enterprise Linux 7.5
- Software: Apache httpd, Apache Tomcat
Anforderungen
Privilegierter Zugriff auf das System
Schwierigkeit
EINFACH
Konventionen
- # – erfordert, dass bestimmte Linux-Befehle mit Root-Rechten ausgeführt werden, entweder direkt als Root-Benutzer oder durch Verwendung von
sudoBefehl - $ – gegebene Linux-Befehle, die als normaler nicht-privilegierter Benutzer ausgeführt werden sollen
Einführung
Die Verwendung von Apache httpd als Proxy für einen Apache Tomcat-Anwendungscontainer ist eine gängige Einrichtung. Es gibt viele Anwendungsfälle, der trivialste ist das Bereitstellen statischer Inhalte von httpd , während Dienste bereitgestellt werden, die umfangreiche Geschäftslogik aus einer in Java geschriebenen Anwendung implementieren, die sich im Tomcat-Container befindet.
Durch die Erstellung eines Proxys können wir eine Art Front-End für die Anwendungsschicht erstellen, wo wir Sicherheitsmaßnahmen in den Webserver einführen, Lastenausgleich anwenden, bedingte Weiterleitung verwenden oder andere vom Webserver bereitgestellte Funktionen nutzen können. Auf diese Weise müssen wir keine dieser Funktionen in unserer Anwendung implementieren und können ihre Fähigkeiten auf den Dienst selbst konzentrieren. Wir werden den Benutzern einen Webserver mit vollem Funktionsumfang präsentieren, einige der URLs werden stillschweigend an den Anwendungscontainer weitergeleitet, auf den möglicherweise nicht selbst zugegriffen werden kann. Die Antworten der Anwendung werden an die Clients zurückgeschickt, die nicht wissen, dass sie etwas anderes als den Webserver gesprochen haben – das heißt, wenn wir darauf achten, keine Informationen (wie nicht behandelte Fehlermeldungen) von der Anwendung preiszugeben, die sie vermuten lassen, dass es mehr gibt als eine Schicht.
Wir werden das AJP-Protokoll verwenden, das zwischen Webservern und Java-basierten Anwendungscontainern verwendet werden kann, um die Möglichkeit zu bieten, die Last zwischen mehreren Anwendungsservern auszugleichen – die Einrichtung eines Lastenausgleichs ist jedoch nicht Gegenstand dieses Tutorials.
Wir werden unser Setup auf Red Hat Linux 7.5 konfigurieren, aber der Apache-Webserver, das AJP-Modul und der Apache Tomcat-Anwendungscontainer sind überall verfügbar, und daher ist dieses Setup mit kleinen Anpassungen wie Dateisystempfaden oder Dienstnamen portierbar.
Erforderliche Software installieren
Zuerst müssen wir die Dienste installieren, die wir verwenden werden. In einem Load-Balancing-Setup können sich Tomcat-Server auf verschiedenen Computern befinden, und oft stellen sie eine Farm von Containern bereit, die einen Dienst aufbauen.
# yum install httpd tomcat tomcat-webapps
Wir installieren die tomcat-webapps Zu Testzwecken enthält dieses Paket eine Beispiel-Webanwendung, die bei der Installation auf unserem Tomcat-Server bereitgestellt wird. Wir verwenden diese Anwendung, um zu testen, ob unser Setup wie vorgesehen funktioniert.
Jetzt können wir unseren Tomcat-Server aktivieren und starten:
# systemctl enable tomcat
# systemctl start tomcat
Und unser Webserver:
# systemctl enable httpd
# systemctl start httpd
Der Standard httpd Installation enthält die Proxy-Module, die wir brauchen. Um das zu überprüfen, können wir den Webserver mit apachectl abfragen :
# apachectl -M | grep ajp
proxy_ajp_module (shared)
Hinweis:1.x-Apache-Versionen verwenden mod_jk Modul anstelle von proxy_ajp .
httpd-Konfiguration
Die in Tomcat bereitgestellten Beispiel-Webanwendungen werden nach der Installation standardmäßig unter server-url:8080/examples veröffentlicht . Wir werden Anfragen, die an den Port 80 des Servers (den Standard-HTTP-Port) kommen, weiterleiten und etwas von der server-url/examples anfordern durch die examples bedient werden Webanwendung, die in Tomcat bereitgestellt wird. Anfragen, die an eine andere URL auf dem Server kommen, werden vom Webserver bedient. Wir richten einige statische Inhalte ein, um diese Funktionalität zu zeigen.
In unserem Beispiel heißt der Server ws.foobar.com . Damit der Proxy funktioniert, erstellen Sie eine Textdatei mit Ihrem bevorzugten Editor im Drop-In-Konfigurationsverzeichnis des Webservers, das /etc/httpd/conf.d ist auf Red Hat Flavors, mit der Erweiterung .conf . Unser Setup benötigt Tomcat nicht, um direkt erreichbar zu sein, also verwenden wir localhost als Zielhost in /etc/httpd/conf.d/example_proxy.conf Datei:
<VirtualHost ws.foobar.com:80>
ServerName ws.foobar.com
ProxyRequests Off
ProxyPass /examples ajp://localhost:8009/examples
ProxyPassReverse /examples ajp://localhost:8009/examples
</VirtualHost>
Sicherheitshalber können wir vor der Anwendung mit apachectl überprüfen, ob unsere Konfiguration korrekt ist :
# apachectl configtest
Syntax OK
Wenn der Konfigurationstest einen Fehler wie den folgenden zurückgibt:
Could not resolve host name ws.foobar.com -- ignoring!
Wenn bedeutet, dass unser ServerName Direktive ist ungültig, da sie vom Webserver nicht aufgelöst werden kann. Entweder müssen wir es im (lokalen oder globalen) DNS registrieren oder eine Zeile in /etc/hosts bereitstellen Datei, die die öffentliche IP-Adresse des Hosts enthält, gefolgt von dem Namen, den wir in der obigen Konfiguration angegeben haben. Wenn die Hosts-Datei die IP bereits mit einem anderen Namen enthält (vielleicht der echte Hostname), können wir den Servernamen nach dem/den Hostnamen in derselben Zeile hinzufügen, das Setup funktioniert.
Nach erfolgreichem Test müssen wir die neue Konfiguration anwenden, indem wir den Webserver neu starten:
# systemctl restart httpd
Tomcat-Konfiguration
Bei der Standardinstallation hört der Tomcat-Container AJP-Anfragen auf allen Schnittstellen auf Port 8009 ab. Dies kann in der Hauptkonfigurationsdatei überprüft werden:
# view /usr/share/tomcat/conf/server.xml
[..]
<!-- Define an AJP 1.3 Connector on port 8009 -->
<Connector port="8009" protocol="AJP/1.3" redirectPort="8443" />
[..]
Wenn der Tomcat-Container und die darin enthaltenen Anwendungen nicht für sich selbst erreichbar sein müssen, können wir jeden Connector so einstellen, dass er nur auf localhost lauscht:
Connector address="127.0.0.1" port=..."
Um sich zu bewerben, können wir Tomcat neu starten mit:
# systemctl restart tomcat
In unserem Laborgerät wird dies nicht geschehen, da wir sehen müssen, dass uns auf beiden Ports 80 derselbe Inhalt bereitgestellt wird und 8080 .
Testen
Unser minimales AJP-Proxy-Setup ist abgeschlossen, wir können es testen. Von der Kommandozeile aus können wir die examples aufrufen Anwendung direkt auf Port 8080 :
$ wget http://ws.foobar.com:8080/examples
--2018-09-13 11:00:58-- http://ws.foobar.com:8080/examples
Resolving ws.foobar.com (ws.foobar.com)... 10.104.1.165
Connecting to ws.foobar.com (ws.foobar.com)|10.104.1.165|:8080... connected.
HTTP request sent, awaiting response... 302 Found
Location: /examples/ [following]
--2018-09-13 11:00:58-- http://ws.foobar.com:8080/examples/
Reusing existing connection to ws.foobar.com:8080.
HTTP request sent, awaiting response... 200 OK
Length: 1253 (1.2K) [text/html]
Saving to: 'examples'
100%[=========================================================================================================================================================================>] 1,253 --.-K/s in 0s
2018-09-13 11:00:58 (102 MB/s) - 'examples' saved [1253/1253]Und sehen Sie sich die bereitgestellten Inhalte an:
$ tail examples
<h3>Apache Tomcat Examples</H3>
<p></p>
<ul>
<li><a href="servlets">Servlets examples</a></li>
<li><a href="jsp">JSP Examples</a></li>
<li><a href="websocket/index.xhtml">WebSocket (JSR356) Examples</a></li>
<li><a href="websocket-deprecated">WebSocket Examples using the deprecated
Apache Tomcat proprietary API</a></li>
</ul>
</body></html>Und wenn wir dieselbe Anwendung über unseren AJP-Proxy aufrufen, sollten wir auch eine Antwort erhalten, obwohl sich im Dokumentenstamm des Webservers kein Inhalt befindet:
$ wget http://ws.foobar.com/examples
--2018-09-13 11:01:09-- http://ws.foobar.com/examples
Resolving ws.foobar.com (ws.foobar.com)... 10.104.1.165
Connecting to ws.foobar.com (ws.foobar.com)|10.104.1.165|:80... connected.
HTTP request sent, awaiting response... 302 Found
Location: /examples/ [following]
--2018-09-13 11:01:09-- http://ws.foobar.com/examples/
Reusing existing connection to ws.foobar.com:80.
HTTP request sent, awaiting response... 200 OK
Length: 1253 (1.2K) [text/html]
Saving to: 'examples.1'
100%[=========================================================================================================================================================================>] 1,253 --.-K/s in 0s
2018-09-13 11:01:09 (101 MB/s) - 'examples.1' saved [1253/1253]Wenn alles funktioniert, erhalten wir eine Antwort mit demselben Inhalt, da die endgültige Antwort von derselben Anwendung innerhalb des Containers bereitgestellt wird:
$ tail examples.1
<h3>Apache Tomcat Examples</h3>
[...]Wir können unser Setup auch mit einem Browser testen. Wir müssen alle URLs mit dem Namen des Servers als Host aufrufen (zumindest den, der geproxyt wird). Dazu muss der Rechner, auf dem der Browser läuft, in der Lage sein, den Servernamen mittels DNS oder Hosts-Datei aufzulösen.
In unserer Testumgebung haben wir das Abhören von Tomcat auf der öffentlichen Schnittstelle nicht deaktiviert, sodass wir sehen können, was bereitgestellt wird, wenn Sie direkt auf Port 8080 gefragt werden :
Tomcat stellt die Beispielanwendung bereit
Wir können denselben Inhalt über den AJP-Proxy abrufen, der vom Webserver auf Port 80 bereitgestellt wird :
httpd stellt die Beispielanwendung mit AJP-Proxy bereit
Während es als Proxy fungiert, httpd kann beliebige andere Inhalte bereitstellen. Wir können statische Inhalte erstellen, die über eine andere URL auf demselben Server erreichbar sind:
# mkdir /var/www/html/static_content
# echo "<html><body>Static content</body></html>" > /var/www/html/static_content/static.htmlIndem wir unseren Browser auf diese neue Ressource verweisen, erhalten wir den neuen statischen Inhalt.
Statischer Inhalt, bereitgestellt von httpd Wenn der Tomcat-Container nicht erreichbar wäre, wüssten wir nicht, dass die Antwort irgendwo anders als beim Webserver kommt. Da wir nur eine bestimmte Anwendung weitergeleitet haben, ist die standardmäßige ROOT-Anwendung des Containers nicht über den Proxy erreichbar und somit vor allem außerhalb des Webservers verborgen.
Schlussfolgerung
Der Apache-Webserver ist durch Module stark erweiterbar, eines davon ist das AJP-Proxy-Modul. Die obige Anleitung verwendet einen Computer und stellt eine Anwendung mit dem Proxy bereit, aber derselbe Webserver könnte einen einzigen Zugang zu vielen Anwendungen bereitstellen, möglicherweise auf vielen Hosts, auf denen Anwendungscontainer laufen, während er auch andere Webinhalte bereitstellt.
Kombiniert mit anderen Modulen, wie mod_security , können wir unserem Service viele Funktionen hinzufügen, ohne sie innerhalb der Anwendung entwickeln zu müssen, oder den Proxy bei Bedarf mit einer einzigen Ausgabe der Konfigurationsdatei und dem Neuladen des Webservers auf einen anderen Endpunkt umleiten, eine Migration durchführen oder die Einführung des neuen Releases der Anwendung eine Sache von Sekunden. Dasselbe Neuladen kann den Besucher zu einer Seite führen, auf der geplante Ausfallzeiten erklärt werden, während Wartungsarbeiten an den Anwendungsservern durchgeführt werden – die Anwendungsfälle eines AJP-Proxys sind nur durch die Vorstellungskraft des IT-Personals begrenzt.