Cíl
Naším cílem je nastavit Apache httpd tak, aby fungoval jako proxy před aplikačním kontejnerem Apache Tomcat.
Verze operačního systému a softwaru
- Operační systém: Red Hat Enterprise Linux 7.5
- Software: Apache httpd, Apache Tomcat
Požadavky
Privilegovaný přístup do systému
Obtížnost
SNADNÉ
Konvence
- # – vyžaduje, aby dané linuxové příkazy byly spouštěny s právy root buď přímo jako uživatel root, nebo pomocí
sudopříkaz - $ – dané linuxové příkazy, které mají být spouštěny jako běžný neprivilegovaný uživatel
Úvod
Použití Apache httpd jako proxy pro kontejner aplikací Apache Tomcat je běžné nastavení. Přichází s mnoha případy použití, nejtriviálnější je poskytování statického obsahu z httpd a zároveň poskytuje služby implementující těžkou obchodní logiku z aplikace napsané v jazyce Java, která je umístěna v kontejneru Tomcat.
Vytvořením proxy můžeme vytvořit jakýsi front-end k aplikační vrstvě, kde můžeme zavádět bezpečnostní opatření na webserveru, aplikovat load balancing, používat podmíněné přesměrování nebo využívat jakoukoli jinou funkcionalitu poskytovanou webovým serverem. Tímto způsobem nepotřebujeme implementovat žádnou z těchto funkcí v naší aplikaci a můžeme její schopnosti zaměřit na samotnou službu. Pro uživatele budeme mít k dispozici plnohodnotný webový server, některé adresy URL budou tiše předány do kontejneru aplikace, který nemusí být sám o sobě dostupný. Odpovědi aplikace jsou předávány zpět klientům, kteří nebudou vědět, že mluvili jinak než webovým serverem – tedy pokud dáme pozor, abychom neodhalili žádné informace (např. neošetřené chybové zprávy) z aplikace, které by je mohly přimět hádat, že je jich více. než jedna vrstva.
Použijeme protokol AJP, který lze použít mezi webovými servery a aplikačními kontejnery založenými na Javě, abychom zajistili možnost vyrovnat zátěž mezi více aplikačními servery – nicméně nastavení nástroje pro vyrovnávání zátěže je mimo rozsah tohoto tutoriálu.
Naše nastavení nakonfigurujeme na Red Hat Linux 7.5, ale webový server Apache, modul AJP a aplikační kontejner Apache Tomcat jsou k dispozici všude, a proto je toto nastavení přenosné s malými úpravami, jako jsou cesty souborového systému nebo názvy služeb.
Instalace požadovaného softwaru
Nejprve musíme nainstalovat služby, které budeme používat. V nastavení s vyváženým zatížením mohou být servery Tomcat na různých počítačích a často jsou, poskytující farmu kontejnerů, které vytvářejí službu.
# yum install httpd tomcat tomcat-webapps
Nainstalujeme tomcat-webapps pro účely testování je v rámci tohoto balíčku ukázková webová aplikace nasazená na náš server Tomcat při instalaci. Tuto aplikaci použijeme k testování, zda naše nastavení funguje tak, jak bylo zamýšleno.
Nyní můžeme povolit a spustit náš server Tomcat:
# systemctl enable tomcat
# systemctl start tomcat
A náš webový server:
# systemctl enable httpd
# systemctl start httpd
Výchozí httpd instalace obsahuje proxy moduly, které potřebujeme. Abychom ověřili, že tomu tak je, můžeme se na webový server dotázat pomocí apachectl :
# apachectl -M | grep ajp
proxy_ajp_module (shared)
Poznámka:Verze 1.x Apache používají mod_jk modul namísto proxy_ajp .
Konfigurace httpd
Příklady webových aplikací nasazených do Tomcatu jsou po instalaci standardně publikovány na server-url:8080/examples . Budeme proxy požadavky přicházející na serverový port 80 (výchozí port http) požadující něco z server-url/examples které mají být poskytovány pomocí examples webová aplikace nasazená do Tomcatu. Požadavky přicházející na jakoukoli jinou adresu URL na serveru obslouží webový server. Pro zobrazení této funkce vytvoříme nějaký statický obsah.
V našem příkladu se server jmenuje ws.foobar.com . Aby server proxy fungoval, vytvořte textový soubor pomocí svého oblíbeného editoru v konfiguračním adresáři webového serveru, což je /etc/httpd/conf.d na příchutích Red Hat s příponou .conf . Naše nastavení nepotřebuje, aby byl Tomcat přímo dosažitelný, takže používáme localhost jako cílový hostitel v /etc/httpd/conf.d/example_proxy.conf soubor:
<VirtualHost ws.foobar.com:80>
ServerName ws.foobar.com
ProxyRequests Off
ProxyPass /examples ajp://localhost:8009/examples
ProxyPassReverse /examples ajp://localhost:8009/examples
</VirtualHost>
Abychom byli na bezpečné straně, můžeme před použitím ověřit, zda je naše konfigurace správná, pomocí apachectl :
# apachectl configtest
Syntax OK
Pokud test konfigurace vrátí chybu, jako je tato:
Could not resolve host name ws.foobar.com -- ignoring!
If znamená, že naše ServerName direktiva je neplatná, protože ji webový server nedokáže vyřešit. Buď jej musíme zaregistrovat v (místním nebo globálním) DNS, nebo poskytnout řádek v /etc/hosts soubor, který obsahuje veřejnou IP adresu hostitele následovanou názvem, který jsme zadali ve výše uvedené konfiguraci. Pokud soubor hosts již obsahuje IP s jiným názvem (možná skutečným názvem hostitele), můžeme přidat název serveru za název hostitele do stejného řádku, nastavení bude fungovat.
Po úspěšném testu musíme použít novou konfiguraci restartováním webového serveru:
# systemctl restart httpd
Konfigurace Tomcat
Při výchozí instalaci bude kontejner Tomcat naslouchat požadavkům AJP na všech rozhraních na portu 8009. To lze ověřit v hlavním konfiguračním souboru:
# 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" />
[..]
Pokud nepotřebujeme, aby byl kontejner Tomcat a aplikace v něm samy dosažitelné, můžeme nastavit každý konektor tak, aby naslouchal pouze na localhost:
Connector address="127.0.0.1" port=..."
Chcete-li použít, můžeme restartovat Tomcat pomocí:
# systemctl restart tomcat
V našem laboratorním stroji to neuděláme, protože potřebujeme vidět, že se nám na obou portech 80 zobrazuje stejný obsah a 8080 .
Testování
Naše minimální nastavení proxy AJP je dokončeno, můžeme jej otestovat. Z příkazového řádku můžeme volat examples aplikace přímo na portu 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]A podívejte se na poskytnutý obsah:
$ 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>A pokud zavoláme stejnou aplikaci prostřednictvím našeho proxy AJP, měli bychom také dostat odpověď, zatímco v kořenovém adresáři dokumentu webového serveru není žádný obsah:
$ 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]Pokud vše funguje, dostaneme odpověď se stejným obsahem, protože konečnou odpověď poskytuje stejná aplikace v kontejneru:
$ tail examples.1
<h3>Apache Tomcat Examples</h3>
[...]Můžeme také vyzkoušet naše nastavení pomocí prohlížeče. Potřebujeme volat všechny adresy URL s názvem serveru jako hostitele (alespoň toho, který je proxy). K tomu musí být počítač s prohlížečem schopen přeložit název serveru pomocí DNS nebo souboru hostitelů.
V našem laboratorním prostředí jsme nezakázali naslouchání Tomcatu na veřejném rozhraní, takže můžeme vidět, co je poskytováno, když se zeptáme přímo na portu 8080 :
Tomcat poskytuje příklady aplikace
Stejný obsah můžeme získat prostřednictvím proxy AJP poskytovaného webovým serverem na portu 80 :
httpd poskytující příklady aplikace s proxy AJP
Zatímco funguje jako proxy, httpd může sloužit jakémukoli jinému obsahu. Můžeme vytvořit statický obsah, který je dostupný na jiné adrese URL na stejném serveru:
# mkdir /var/www/html/static_content
# echo "<html><body>Static content</body></html>" > /var/www/html/static_content/static.htmlNasměrováním našeho prohlížeče na tento nový zdroj získáme nový statický obsah.
Statický obsah poskytuje httpd Pokud by kontejner Tomcat nebyl dosažitelný, neznali bychom odpověď, která přichází jinde než na webovém serveru. Vzhledem k tomu, že jsme za proxy použili pouze konkrétní aplikaci, výchozí ROOT aplikace kontejneru není přes proxy dosažitelná, takže je skryta všemu mimo webový server.
Závěr
Webový server Apache je vysoce rozšiřitelný pomocí modulů, jedním z nich je proxy modul AJP. Výše uvedená příručka používá jeden počítač a zpřístupňuje jednu aplikaci s proxy, ale stejný webový server by mohl poskytovat jediný záznam pro mnoho aplikací, možná na mnoha hostitelích s aplikačními kontejnery, a zároveň poskytovat další webový obsah.
V kombinaci s dalšími moduly, jako je mod_security , můžeme do naší služby přidat mnoho funkcí, aniž bychom je museli vyvíjet v rámci aplikace, nebo v případě potřeby přesměrovat proxy na jiný koncový bod pomocí jediné edice konfiguračního souboru a znovu načíst webový server, provést migraci resp. představení nové verze aplikace otázkou sekund. Stejné opětovné načtení může návštěvníka přivést na stránku vysvětlující plánovanou odstávku, zatímco na aplikačních serverech probíhá údržba – případy použití AJP proxy jsou omezeny pouze představivostí IT personálu.