Reverse Proxy Apache e Domino - Gzip e non solo...

Per diverse realtà con le quali collaboro sono sorte diverse esigenze tipo:

• Non voglio esporre il server domino HTTP pubblicamente per questioni di security. E' possibile mettere un'interfaccia Domino front-end che risponda alle richieste sull'http e reindirizzi le chiamate al mio/miei server domino interno/i?
• E' anche possibile fare un modo che posso esporre l'HTTP di più server Domino su un unico IP?
• E' possibile comprimere in GZIP i contenuti CSS,JS, Pagine e Form delle mie applicazioni Domino in modo da consumare meno banda e diminuire la latenza di loading del browser?
• E' possibile trovare una soluzione valida per velocizzare ulteriormente il carimento delle applicazioni web?

Queste richieste sono esigenze sempre più frequenti in realtà in cui mi trovo ad implementare soluzioni intranet / extranet / internet (ovviamente fatte in Domino) e non essendo Domino in grado di esaudirle nativamente tutte quante le richieste ho deciso di fare un testing interno installando un Apache HTTP server configurato come reverse proxy.

Ho scelto la soluzione Apache per quattro semplici ragioni:

a) è open
b) è leggerlo
c) è robusto
d) Si installa / configura facilmente ( installato e configurato in 5 minuti su OS windows 2003)


Un reverse-proxy è un server Web pubblico in grado di rispondere pubblicamente alle richieste HTTP e dirottare la richiesta internamente in funzione di determinate regole impostate.








Un reverse-proxy ha notevoli vantaggi tra i quali ricordo:

• Sicurezza: nel caso venga "bucato" tale server non si potrà accedere ovviamente ai dati presenti sul server domino
• Caching delle risorse: è possibilie decidere cachare le risorse statiche ( immagini per esempio)
• Compressione: è possibile decidere in base al content-type della risorsa che deve essere servita, se attivare o meno la compressione GZIP e con quale ratio
• ed altro ancora...

Ma veniamo alla mia configurazione nello specifico.

Ipotetizziamo di avere internamente due server Domino che fanno a capo di un unico IP address pubblico.

SVILUPPO\DOMINOPOINT              che risponde all'IP  192.168.1.1
PRODUZIONE\DOMINOPOINT      che risponde all'IP  192.168.1.2

Attualmente digitando sia prod.dominopoint.it  e dev.dominopoint.it dall'esterno risponde (sempre ipoteticamente) lo stesso IP pubblico che sarà nattato tramite firewall verso il server PRODUZIONE\DOMINOPOINT il quale tramite apposite configurazioni degli internet site direziona la chiamata verso un database o l'altro presenti all'interno della macchina.

Installando un reverse-proxy voglio fare in modo che in base all'hostname richiesto la chiamata venga dirottata su uno o l'altro server in maniera trasparente ( poi sarà compito degli internet site decidere a cosa far puntare)...

Avendo solamente due server Domino disponibili, l'unica strada percorribile è quella di installare su uno dei dei server Apache e Domino in contemporanea configurando Apache per rispondere sulla porta 80 e domino sulla porta 81 per quanto riguarda l'HTTP di quel server.

Di conseguenza sul server PRODUZIONE\DOMINOPOINT cambio la porta di ascolto di Domino mettendola su 81



Fatto questo riavvio il task http (Tell http restart da console domino) per far prendere a domino questa modifica.

Scarico Apache http a seconda della distribuzione del mio sistema operativo ( Windows o Linux) e la installo sul mio server in produzione
L'installazione è molto semplice ( ho lasciato tutto di default) e sono semplici NEXT-->NEXT-->NEXT....

Una volta installato Apache il server dovrebbe essere pronto a rispondere sulla porta 80 dal servizio HTTP di Apache.
Per fare un test basta lanciare un TELNET hostname/IP 80 e facedo la medesima cosa sulla 81 dovrebbe rispondere l'HTTP di domino.

Una volta lanciato Apache (o come servizio e dai programmi ) sulla task-bar di Windows apparità l'icona corrispondente ( significa che Apache è in su)



La configurazione di Apache è tutta basata su un file di configurazione httpd.conf all'interno del quale c'è tutta una sintassi particolare ( XML) che definisce la configurazione


Tramite Notepad o qualsiasi editor ASCII è possibile editare il file di configurazione:


Abbiamo quasi terminato ed ora manca solamente da capire come attivare il reverse proxy e ridirezionare le chiamate.
Seguendo la guida di Apache per attivare il reverse proxy è necessario innanzitutto decommentare ( e quindi caricare) le librerie necessarie.

Nel nostro caso basta decommentare la libreria affinche funzioni ( l'attivazione è semplice basta eliminare #) :
#LoadModule mod_proxy

fatto ciò è ora necessario definire i redirect necessari in questa modalità

--------------------------------------

NameVirtualHost *:80

<VirtualHost *:80>
ServerName prod.dominopoint.it
ProxyPass / http://192.168.1.2:81/
ProxyPassReverse / http://192.168.1.2:81/
ProxyPreserveHost On
</VirtualHost>

<VirtualHost *:80>
ServerName dev.dominopoint.it
ProxyPass / http://192.168.1.1:80/
ProxyPassReverse / http://192.168.1.1:80/
ProxyPreserveHost On
</VirtualHost>

--------------------------------------

Fatto ciò e restartando Apache i redirect dovrebbero funzionare e Domino dall'esterno risponde corrattamente con una o con l'altra macchina fisica.


A questo punto per passare alla seconda richiesta di GZIPPARE i contenuti delle form, delle pagine, dei css, e JS è necessario proseguire come segue:

Attivare le librerie:

#LoadModule mod_deflate

ed aggiungere nel virtual host appena creato la seguente sintassi

--------------------------------------
AddOutputFilterByType DEFLATE text/html text/plain text/javascript text/css
DeflateCompressionLevel 9
--------------------------------------

una volta fatto ciò e restartato Apache dovrete verificarne il funzionamento tramite Firebug notando che sulle risorse di content-type sopra definito il content-encoding è diventato GZIP. ( sopratutto notando che la dimensione della risorsa è diminuta)
Il DefalteCompressionLevel è un valore che può anche essere omesso, e rappresenta il livello di compressione GZIP (9 è il max occhio però alla CPU del server )



Vi ricordo anche che il GZIP sui vecchi browser non è supportato correttamente e da qualche problema.
E' per questo che è possibile inserire istruzioni condizionali a seconda del browser collegando affinchè i contenuti debbano o no essere serviti in GZIP tramite sintassi simili:

# Netscape 4.06-4.08 have some more problems
BrowserMatch ^Mozilla/4\.0[678] no-gzip

Ulteriori dettagli possono essere trovati sulla guida ufficiale di apache


Un ultima chicca di non poca importanza è quella di far cachare determinati contenuti al browser.

Tale funzionalità è stata implementata poichè tramite il tool Yslow che analizza le problematiche reali di lentezza sui siti web mi sono accorto che spesso appariva  questa indiricazione di aggiungere gli expired header alle risorse statiche.


Sostanzialmente questa cosa può tranquillamente essere fatta anche da Domino tramite le rules presenti nella configurazione degli internet sites. Ma visto e considerando che può essere riprodotta anche con Apache eccovi le indicazioni per attivarla.

Attivare la libreria

#LoadModule expires_module modules/mod_expires.so

e nel virtual host di riferimento inserire le seguenti istruzioni
--------------------------------------
ExpiresActive On
ExpiresByType image/gif A604800
ExpiresByType image/png A604800
ExpiresByType image/jpeg A604800
--------------------------------------
In questo modo tutte le risorse immagini vengono mantenute nella cache del browser per 1 settimana

Ulteriori informazioni sono reperibili a questo link

Ora dopo un restart di Apache con Firebug dovreste notare sulle risorse immagini il record di Expired:









Conclusioni:

A livello di security credo che ci siamo anche se mi "sfondassero" il server Apache non riuscirebbero ad entrare sui server applicativi Domino.
Grazie all'expired e GZIP le applicazioni Web sono diventate un fulmine in quanto i dati che transitano tra server e broweser si sono ridotti notevolmente (un peso di notevole importanza sono le immagini)
Direi che i vantaggi sono notevoli rapportando il costo implementativo della soluzione e le funzionalità ottenute.

Mi auguro che questo tutorial possa essere uno spunto per configurazioni decisamente più spinte e per mostrare quanto può essere fatto se si conoscono bene gli strumenti che abbiamo a disposizione.