Obiettivo
Il nostro obiettivo è configurare Apache httpd in modo che funzioni come proxy davanti al contenitore dell'applicazione Apache Tomcat.
Sistema operativo e versioni software
- Sistema operativo: Red Hat Enterprise Linux 7.5
- Software: Apache httpd, Apache Tomcat
Requisiti
Accesso privilegiato al sistema
Difficoltà
FACILE
Convenzioni
- # – richiede che i comandi linux dati vengano eseguiti con i privilegi di root direttamente come utente root o usando
sudocomando - $ – dati comandi linux da eseguire come un normale utente non privilegiato
Introduzione
L'utilizzo di Apache httpd come proxy per un contenitore di applicazioni Apache Tomcat è una configurazione comune. Viene fornito con molti casi d'uso, il più banale è la pubblicazione di contenuti statici da httpd , fornendo al contempo servizi che implementano una logica aziendale pesante da un'applicazione scritta in Java che risiede nel contenitore Tomcat.
Creando un proxy, possiamo creare una sorta di front-end per il livello dell'applicazione, dove possiamo introdurre misure di sicurezza nel server web, applicare il bilanciamento del carico, utilizzare il reindirizzamento condizionale o utilizzare qualsiasi altra funzionalità fornita dal server web. In questo modo non abbiamo bisogno di implementare nessuna di queste funzionalità nella nostra applicazione e possiamo concentrare le sue capacità sul servizio stesso. Avremo un server web completo presentato per gli utenti, alcuni degli URL inoltrati silenziosamente al contenitore dell'applicazione che potrebbe non essere accessibile da solo. Le risposte dell'applicazione vengono inoltrate ai client che non sapranno di aver parlato nient'altro che il server web, ovvero se facciamo attenzione a non esporre alcuna informazione (come messaggi di errore non gestiti) dall'applicazione che possa far loro intuire che ci sono più di uno strato.
Utilizzeremo il protocollo AJP che può essere utilizzato tra server Web e contenitori di applicazioni basati su Java per fornire la possibilità di bilanciare il carico tra più server di applicazioni, tuttavia, la configurazione di un bilanciamento del carico non rientra nell'ambito di questo tutorial.
Configurare la nostra configurazione su Red Hat Linux 7.5, ma il server web Apache, il modulo AJP e il contenitore dell'applicazione Apache Tomcat sono disponibili ovunque, quindi questa configurazione è portabile con piccole modifiche come i percorsi del filesystem o i nomi dei servizi.
Installazione del software richiesto
Per prima cosa dobbiamo installare i servizi che utilizzeremo. In una configurazione con bilanciamento del carico, i server Tomcat potrebbero trovarsi su macchine diverse e spesso lo sono, fornendo una farm di contenitori che creano un servizio.
# yum install httpd tomcat tomcat-webapps
Installiamo le tomcat-webapps a scopo di test, all'interno di questo pacchetto è presente un'applicazione Web di esempio distribuita nel nostro server Tomcat al momento dell'installazione. Utilizzeremo questa applicazione per verificare che la nostra configurazione funzioni come previsto.
Ora possiamo abilitare e avviare il nostro server Tomcat:
# systemctl enable tomcat
# systemctl start tomcat
E il nostro server web:
# systemctl enable httpd
# systemctl start httpd
Il valore predefinito httpd l'installazione contiene i moduli proxy di cui abbiamo bisogno. Per verificare che sia così, possiamo interrogare il server web con apachectl :
# apachectl -M | grep ajp
proxy_ajp_module (shared)
Nota:le versioni 1.x di Apache usano mod_jk modulo invece di proxy_ajp .
Configurazione httpd
Gli esempi di applicazioni Web distribuite in Tomcat vengono pubblicati dopo l'installazione per impostazione predefinita su server-url:8080/examples . Inoltraremo le richieste che arrivano alla porta 80 del server (la porta http predefinita) richiedendo qualcosa da server-url/examples essere servito dagli examples applicazione web distribuita in Tomcat. Le richieste che arrivano a qualsiasi altro URL sul server verranno servite dal server web. Imposteremo alcuni contenuti statici per mostrare questa funzionalità.
Nel nostro esempio il server si chiama ws.foobar.com . Affinché il proxy funzioni, crea un file di testo con il tuo editor preferito nella directory di configurazione del server web, che è /etc/httpd/conf.d su versioni di Red Hat, con estensione .conf . La nostra configurazione non richiede che Tomcat sia raggiungibile direttamente, quindi utilizziamo localhost come host di destinazione nel /etc/httpd/conf.d/example_proxy.conf file:
<VirtualHost ws.foobar.com:80>
ServerName ws.foobar.com
ProxyRequests Off
ProxyPass /examples ajp://localhost:8009/examples
ProxyPassReverse /examples ajp://localhost:8009/examples
</VirtualHost>
Per sicurezza, possiamo verificare che la nostra configurazione sia corretta prima di applicare con apachectl :
# apachectl configtest
Syntax OK
Se il test di configurazione restituisce un errore simile al seguente:
Could not resolve host name ws.foobar.com -- ignoring!
Se significa che il nostro ServerName la direttiva non è valida, in quanto non può essere risolta dal server web. O dobbiamo registrarlo nel DNS (locale o globale) o fornire una riga nel /etc/hosts file che contiene l'indirizzo IP pubblico dell'host seguito dal nome che abbiamo fornito nella configurazione precedente. Se il file hosts contiene già l'IP con un altro nome (forse il nome host reale), possiamo aggiungere il nome del server dopo i nomi dell'host nella stessa riga, l'installazione funzionerà.
Dopo il successo del test dobbiamo applicare la nuova configurazione riavviando il server web:
# systemctl restart httpd
Configurazione Tomcat
Con l'installazione predefinita, il container Tomcat ascolterà le richieste AJP su tutte le interfacce sulla porta 8009. Questo può essere verificato nel file di configurazione principale:
# 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" />
[..]
Se non abbiamo bisogno che il contenitore Tomcat e le applicazioni all'interno siano raggiungibili da soli, possiamo impostare ogni connettore in modo che sia in ascolto solo su localhost:
Connector address="127.0.0.1" port=..."
Per candidarci possiamo riavviare Tomcat con:
# systemctl restart tomcat
Nel nostro laboratorio la macchina non lo farà, poiché dobbiamo vedere che ci viene servito lo stesso contenuto su entrambe le porte 80 e 8080 .
Test
La nostra configurazione minima del proxy AJP è completa, possiamo testarla. Dalla riga di comando possiamo chiamare gli examples applicazione direttamente sulla porta 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]E guarda i contenuti forniti:
$ 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>E se chiamiamo la stessa applicazione tramite il nostro proxy AJP, dovremmo anche ottenere una risposta, mentre non c'è alcun contenuto nella radice dei documenti del server web:
$ 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]Se tutto funziona, otterremo una risposta con gli stessi contenuti, poiché la risposta finale è fornita dalla stessa applicazione all'interno del contenitore:
$ tail examples.1
<h3>Apache Tomcat Examples</h3>
[...]Possiamo anche testare la nostra configurazione con un browser. Dobbiamo chiamare tutti gli URL con il nome del server come host (almeno quello che è proxy). Per questo la macchina che esegue il browser deve essere in grado di risolvere il nome del server, tramite DNS o file hosts.
Nel nostro ambiente di laboratorio non abbiamo disabilitato l'ascolto di Tomcat sull'interfaccia pubblica, quindi possiamo vedere cosa viene fornito quando richiesto direttamente sulla porta 8080 :
Tomcat che fornisce l'applicazione di esempio
Possiamo ottenere lo stesso contenuto tramite il proxy AJP fornito dal server web sulla porta 80 :
httpd che fornisce l'applicazione di esempio con proxy AJP
Mentre funge da procuratore, httpd può servire qualsiasi altro contenuto. Possiamo creare contenuto statico raggiungibile su qualche altro URL sullo stesso server:
# mkdir /var/www/html/static_content
# echo "<html><body>Static content</body></html>" > /var/www/html/static_content/static.htmlPuntando il nostro browser su questa nuova risorsa, ci viene fornito il nuovo contenuto statico.
Contenuto statico fornito da httpd Se il container Tomcat non fosse raggiungibile, non sapremmo che la risposta arriverà da qualche parte diversa dal server web. Poiché abbiamo inviato un proxy solo a un'applicazione specifica, l'applicazione ROOT predefinita del contenitore non è raggiungibile tramite il proxy, quindi nascosta da tutto ciò che è al di fuori del server web.
Conclusione
Il server web Apache è altamente estensibile tramite moduli, uno di questi è il modulo proxy AJP. La guida precedente utilizza una macchina ed espone un'applicazione con il proxy, ma lo stesso server Web potrebbe fornire una singola voce a molte applicazioni, possibilmente su molti host che eseguono contenitori di applicazioni, fornendo anche altri contenuti Web.
Combinato con altri moduli, come mod_security , possiamo aggiungere molte funzionalità al nostro servizio senza la necessità di svilupparle all'interno dell'applicazione, oppure, se necessario, reindirizzare il proxy su un altro endpoint con un'unica edizione del file di configurazione e il ricaricamento del webserver, effettuando una migrazione o l'introduzione della nuova versione dell'applicazione è una questione di secondi. La stessa ricarica può portare il visitatore a una pagina che spiega i tempi di inattività pianificati, mentre la manutenzione viene eseguita sui server delle applicazioni:i casi d'uso di un proxy AJP sono limitati solo dall'immaginazione del personale IT.